RE: nextUpdate

["Friedrichs, Paul (Contractor)" <FriedriP@ncr.disa.mil>]

David,

-----Original Message-----
From: David A. Cooper [mailto:david.cooper@nist.gov]
Sent: Wednesday, March 24, 2004 5:15 PM
To: FriedriP@ncr.disa.mil
Cc: pkits@nist.gov
Subject: Re: nextUpdate


Paul,

The PKITS test suite explicitly states:

4.4 Basic Certificate Revocation Tests
The application must be able to retrieve valid revocation data for each
certificate in the path. If the application is unable to retrieve valid 

[Friedrichs, Paul] What does "valid" mean? The third sentence distinguishes
"valid" and "up-to-date."
 
 revocation data for one or more certificates in the path, it must reject
the certification path. 

[Friedrichs, Paul] What is meant by "reject the certification path"? 4.4.11
and 4.4.12 say "the end entity certificate should be rejected." What's the
difference?
 
 In the following tests, it is assumed that if an application is unable to
find valid, up-to-date certificate status information (e.g., a CRL) for each
certificate in the path, that either path validation will fail 

[Friedrichs, Paul] What does "fail" mean?
 
 or the application will display a warning to the user 

[Friedrichs, Paul] This says (apparently contrary to 4.4.11's and 4.4.12's
"the end entity certificate should be rejected") failure is not required,
but it says "display" to a user is required if failure does not occur.
"Display" is required. What does "display" mean? This could be interpreted
by a tester to leave no alternative than failure if there is no user to whom
a warning can be "displayed." 
 
 indicating that the status of the certificate can not be determined.

[Friedrichs, Paul] This isn't relevant. It's a red herring. The CA could
know that a private key has been compromised even if nextUpdate is in the
future. The only relevant security information is time since thisUpdate.
(Transfer of liability might make nextUpdate relevant for business reasons.)
 
So, there is no mandate that all activity stop if one is unable to obtain an
up-to-date CRL. 

[Friedrichs, Paul] The tests themselves say "the end entity certificate
should be rejected." My specific concern with the wording of 4.4 is that
testers will require "failure" and "display." These are means particular to
an assumed solution.
 
In the case of an interactive application,  a warning could be displayed to
the user,

[Friedrichs, Paul] A specific "fail"-or-"display" solution is assumed.
Testers can reject all but the specific solution assumed by the authors as
interpreted by the testers.

who could then make a judgment about how proceed.

[Friedrichs, Paul] Based on what information? 4.4 says nothing other than
"reject the certificate path." 4.4.11 and 1.1.12 say nothing other than "the
end entity certificate should be rejected."  There's no information to
support this judgment. Is it 243 minutes since thisUpdate, or 1,576,800
minutes since thisUpdate? 
 
In other cases, 

[Friedrichs, Paul] 4.4. doesn't say this. There are no cases.
 
 such as when an application can not simply provide user feedback (e.g.,
PKI-based login), the application itself could make a determination of how
to proceed based on the warning returned by the path validation logic and
configuration information provided by the administrator.

[Friedrichs, Paul] So the warning could be "513 minutes since thisUpdate,"
and the configuration could be "accept if less than 600 minutes"? That's
great!  But 4.4.11 and 4.4.12 conflict with your last sentence. They say
"the end entity certificate should be rejected." But if "the application
itself could make a determination of how to proceed based on the warning
returned by the path validation logic and configuration information provided
by the administrator," why couldn't a user similarly configure her software
to do the same? Why must the warning be "displayed" if it can be
anticipated?

Also note that the nextUpdate times in the CRLs in the tests below are
January 1, 2002 and January 1, 1999, so in neither test is it the case that
the CRL is only slightly out-of-date.

[Friedrichs, Paul] That's my concern. It's avoiding the relying party's real
challenge. The test treats 243 minutes after thisUpdate the same as
1,576,800 after thisUpdate, forcing "compliant" products to do the same.
More below....


Dave

Friedrichs, Paul wrote:

Hi Everyone,

It was brought to my attention that
http://csrc.nist.gov/pki/testing/PKITS.pdf in sections 4.4.11 and 4.4.12 on
pages 18-29, says:

  
4.4.11 Invalid Old CRL nextUpdate Test11

In this test the intermediate CA's CRL has a nextUpdate time that 
is in the past, indicating that the CA has already issued updated 
revocation information. Since the information in the CRL is 
out-of-date and a more up-to-date CRL (that should have already 
been issued) can not be obtained, the end entity certificate should 
be rejected due 

[Friedrichs, Paul] Above, you say the application could make this
determination. Here, PKITS is making the determination. The test criterion
is "rejection of the certificate."

 to the lack of sufficiently fresh certificate 
status information.

Procedure: Validate Invalid Old CRL nextUpdate Test11 EE using the 
default settings or open and verify Signed Test Message 6.2.2.28 
using the default settings.

Expected Result: The path should not validate successfully since 
the status of the end entity's certificate can not be determined.
    

and

  
4.4.12 Invalid pre2000 CRL nextUpdate Test12

In this test the intermediate CA's CRL has a nextUpdate time that 
is in 1999 indicating that the CA has already issued updated 
revocation information. Since the information in the CRL is outof-date 
and a more up-to-date CRL (that should have already been issued) can 
not be obtained, the end entity certificate should be rejected due to 
the lack of sufficiently fresh certificate status information.

Procedure: Validate Invalid pre2000 CRL nextUpdate Test12 EE using the 
default settings or open and verify Signed Test Message 6.2.2.29 using 
the default settings.

Expected Result: The path should not validate successfully since the 
status of the end entity's certificate can not be determined.

[Friedrichs, Paul] Am I missing something? Why have 4.4.12 if we have
4.4.11?

[Friedrichs, Paul] Santosh Chokhani sent me the following:
>  Assumptions regarding how application analyzes the data and overrides the
>  anomaly will be the key to practical implementations. In PKIF (the
toolkit
>  we implemented for USMC), we permit three variations: override of the
>  freshness check, accept a CRL with thisUpdate + x , and/or accept a CRL
with
>  nextUpdate + y where x and y are configurable by the RP. 
Would this not pass PKITS compliance? This is "configuration information
provided by the administrator." What if the administrator, the relying
party, were "the user"? Why would anything have to be "displayed"?

Many Thanks,
V/R Paul