RE: nextUpdate

[Sharon Boeyen <sharon.boeyen@entrust.com>]

Hi Paul,

I obviously wasn't clear in my earlier message. The standards are not
claiming to be a higher authority at all. The standards define a process for
path validation with a standard set of inputs and outputs. The process
produces a failure with an error code in the example you cite. This does not
mean that the certificate can't be used. It means the process could not
determine the revocation status of the certificate and therefore that
process failed. The decision on whether or not to use that certificate one
that takes the results of path validation as an input, along with other
inputs. That process is not covered by these standards. 

If path validation did not fail in the example you cite, relying parties
would have no way to know that current revocation status had not been
checked. The same holds true for all other reasons that the process fails. 

Hope this clarifies what I was trying to convey.

Cheers,
Sharon

-----Original Message-----
From: pkits@nist.gov [mailto:pkits@nist.gov] On Behalf Of Friedrichs, Paul
(Contractor)
Sent: Monday, March 01, 2004 11:13 AM
To: Multiple recipients of list
Subject: RE: nextUpdate



Hello Sharon,

> -----Original Message-----
> From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com]
> Sent: Monday, March 01, 2004 9:59 AM
> To: 'FriedriP@ncr.disa.mil'; Multiple recipients of list
> Subject: RE: nextUpdate
> 
> 
> Hello Paul,
> 
> PKITS is testing the path validation procedure and as such it
> is required to
> fail in such a circumstance as dictated by the standards.

I don't understand "as dictated by the standards." Where do the standards
say CRLs must be rejected after nextUpdate? Why would this be a decision for
standards to impose on relying parties?

Even if this were in standards someplace, must the nation's security be
compromised by standards? What makes standards a higher authority than
national security? (This might seem like an exaggeration, but this is
exactly how DoD leadership would view this - and those that I am aware that
know about this already do, although their question is why PKITS would claim
to be a higher authority than national security.) Your argument appears to
be that the only criteria for the correct decision are standards. Is the
only purpose for PKI that it comply with standards?
 
> However, along
> with failure of that process, the relying party (application
> or user) should
> also receive an error message that indicates the reason for 
> the failure
> (e.g. revocation status could not be determined). The relying 
> party then can
> make a decision as to whether they want to use the 
> certificate, even though
> the revocation status could not be checked. In your example, the
> certificates could still be used, however the relying party 
> is making a
> decision to do so knowing that the revocation status could 
> not be accurately
> determined. 

I think we're saying the same thing.

But is the current test criteria in PKITS preventing the possibility that
"certificates could still be used"? PKITS says they must be "rejected." 

> The PKITS test suite is doing what it is supposed to do
> correctly and should
> not be changed.

I don't understand how both of your last two sentences can be true. For
example, how can an SSL server or an SSL client provide the capability
described in your penultimate sentence without failing the current test
criteria? How does PKITS allow the relying party to establish the SSL
session after deciding that it should do so despite the absence of the
latest revocation status information? Wouldn't PKITS-compliant products
prohibit the establishment of SSL? If not, where is the difference in the
way we are saying this capability can or should be provided?

Can a PKITS-compliant product "reject" a certificate, warn the user, and
allow the user to use the certificate anyway? 

Many Thanks,
V/R Paul