Re: Current status of CRL validation ?

[Ed Gerck <egerck@xxxxxxx>]

Stephen Kent wrote:
> 
> At 3:52 PM -0800 3/30/04, Ed Gerck wrote:
> >Julien,
> >
> >Yes, a PKIX cert is either revoked or not. Yes, this is strictly enforceable
> >in X.509 because: (a) a cert has only one issuer and, (b) only that issuer of
> >the cert can revoke the cert. However, X.509 is unable to allow a RP to
> >measure with any desired confidence (i.e., desired by the RP) whether a cert
> >is revoked or not.
> 
> Each CRL issuer sets the time frame for CRL issuance with the Next
> Update value, so it is true that the RP is not capable of deciding
> what level of confidence he wants re revocation status, IF that
> includes a timeliness constraint.

Yes. But IF a timeliness constraint is NOT included, the RP cannot
even assign confidence limits (a statistical measure) to the decision 
wheter the cert is revoked or not. Moreover, I'm not aware of any
limit field stating the maximum time lapse that is warranted between
a revocation communication being received from the subscriber and the 
publication of that information in the CRL. We may hope that anything
received between now and the Next Update value will be published at
that time, but it may not. Clearly, there is a cut-off and it may
involve more than one update cycle. Perhaps you could clarify this.
 
> >This is due to several unsolvable problems in the X.509/PKIX framework [1].
> >For example, there may be a considerable delay (no warranties on the CAs
> >CPSs can be found on upper limits for such delays) between the actual need
> >to revoke a certificate and the reflection of this need in a certificate
> >chain with different CAs. Further, the major X.509 security application
> >today, SSL, still does not check revocation lists or any other revocation
> >mechanisms -- so they are near to useless. Also, the user is not able to
> >check server certificates (and certificates in the CA chains) against
> >revocation lists.
> 
> of course this comment about SSL/TLS is not a critique of X.509 or
> PKIX standards, but rather an observation about implementation
> practice.

First, nothing that I said above is a critique of X.509 or PKIX
standards. We shall not require perfection. That said, even if a SSL
implementation would include CRLs and OCSPs, the other problems 
mentioned above would still exist and prevent that SSL implementation
(no matter how clever) from effectively providing an answer that 
the RP could measure with any desired confidence.

> 
> >Moreover, PKIX/X.509 revocation is a "will" to revoke but not an actual
> >revocation. Few recognize, as you have now hit, that cert revocation
> >in PKIX/X.509 is a solution to a non-existent problem ... while the real
> >problem is left utterly unsolved. The non-existent problem solved by
> >PKIX/X.509 cert revocation is how to communicate that a certificate is no
> >longer valid ... because if a certificate were really no longer valid
> >(as it should be) then no one would need to find the cert revocation to
> >know about it.
> 
> was there some part of the preceding paragraph that was supposed to
> make technical sense?

We have struggled with this passage before. Thanks for helping me
clarify it now. In short, I mean that revocation by reference (i.e., a 
X.509 reference that X is revoked) does not revoke anything. Actual 
revocation, OTOH, would make it impossible to use the cert -- even if 
a reference about its revocation is not available. 

Cheers,
Ed Gerck