Re: Current status of CRL validation ?

[Stephen Kent <kent@xxxxxxx>]

Ed,

I really should have asked the context in which you were referring to 
an RP's reliance on revocation status info. If the RP is validating a 
signature for NR purposes, then the RP is nominally protected if he 
waits until the "next" CRL is issued before he acts on the signed 
object. The CRL issuer is the only game in town re authoritative info 
on the revocation status of a cert. AN RP is, by definition, a 
"relying" party and he relies on the cert and CRL issuer(s) to 
provide this status data when they have said it becomes available. if 
the RP cannot tolerate the wait, tough luck. I don't think we need to 
be fancy about this, e.g., "confidence limits."

If the RP is using a signature in an access control context, then the 
problem is often different. For access control purposes, one usually 
will not have the luxury of waiting for the next CRL to determine 
revocation status, and even use of OCSP may not help, as many OCSP 
servers are driven by CRLs. But, this is not an X.509 problem per se. 
If the operator of an access control systems wants to ensure that a 
user's privileges are revoked quickly, then the best way to do that 
is to change the ACLs associated with the resources being protected, 
or to push a hot list to each resource access manager. When certs are 
used to verify identity in support of access control, these general 
rules apply, and they are not fundamentally different than if one had 
chosen to use passwords for user authentication.

	<SNIP>

> 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.

One cannot, in general, make "it impossible to use the cert" but one 
can make a cert unusable in a given context. But that is not 
surprising. In many systems with capability-like properties, 
revocation effected by seizing an access token is often infeasible. 
If I have a keyed padlock on a locker, I can change the lock to 
effect revocation of access privileges for the holders of keys, and 
reissue new keys for the new lock to the folks I want to authorize. 
Do I know that the keys that are out there will not be able to open 
any other padlocks? Not really/ There may have been another padlock 
that would accept the same keys and I don't now, nor can I prevent 
the use of the keys in that padlock.

So, I'm afraid I don't find your clarification helpful. Maybe we're 
still just missing a concisely stated context for the comment.

Steve