Subject: RE: CRL sequence issues

From: "Vittek Robert" <[email-masked]>
Date: Wed, 8 Jun 2005 14:07:21 +0200

Yes, that's it! The problem is if the signer's certificate is close to
expiration.

RFC 3280 states that:
An entry MUST NOT be removed
from the CRL until it appears on one regularly scheduled CRL issued
beyond the revoked certificate's validity period.

This CRL may be crucial for the validation process, hence I MUST NOT
miss it.
I ask if there are any means to check (in CRLs themselves) that I did
not miss any previous CRL.
The crlNumber extension does not seem to be sufficient, since it allows
some numbers to be skipped
and I do not see any other.

I looked at the previous contributions to this mailing list and I have
found that there were attempts to address this problem
by the "retention period" back in 2001
http://www.imc.org/ietf-pkix/old-archive-01/thrd2.html#02198 (Removing
expired certificates from CRL).
The retention period may decrease the probability of missing revocation
information of recently expired certificate to the acceptable limit.

Has this been standardized already? In what RFC (or perhaps ETSI
document)?

Best regards,
Robert Vittek

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Wednesday, June 08, 2005 2:41 PM
To: Vittek Robert
Cc: pkix
Subject: Re: CRL sequence issues

>Dear Mr. Pinkas,
>I really appreciate that at least you replied to my contribution but, 
>please, try to pay a little more attention to what I am concerned
about.

>The Complete Revocation Refs attribute (described in 4.2.2) references 
>the full set of the CRL or OCSP responses that HAVE BEEN used in the 
>validation of the signer and CA certificates used in ES with Complete 
>validation data.

>My question relates more to the initial phase of the validation 
>process, when I am still collecting various validation data (e.g. CRLs)

>to be able to perform the full validation. For various reasons, I may 
>not be able to obtain some CRL at the time it was issued from CA. So, I

>need to perform some automatic checks regularly to make sure that my 
>local CRL cache (on the basis of which I compose and later fully 
>validate ES-C) is complete and up-to-date. The point is, that I MUST
NOT miss any CRL.

Unless the signer's certificate is close to expiration, you MAY miss
some CRLs since later CRLs will continue to advertise already revoked
certificates.

If this does not answer your question, please reformulate it completely.

Denis

>Do CRLs themselves (or any other PKIX objects) provide any means to 
>ensure this?
>
>With hope that my question will be addressed, Robert Vittek
>
>
>-----Original Message-----
>From: Denis Pinkas [mailto:[email-masked]]
>Sent: Wednesday, June 08, 2005 1:06 PM
>To: Vittek Robert
>Cc: [email-masked]
>Subject: Re: RE: CRL sequence issues
>
>
>> I went through the  rfc 3126, but it does not address the problem I
>was asking about.
>
>> I will try to make it more simple:
>> How can I check (automatically) using only CRL extensions that I have

>> all needed CRLs in my local cache. It may be crucial in some cases 
>> not
>to miss any single CRL.
>
>RFC 3126 uses revocation status information references.
>The crlHash may be used to make sure that the information is in the 
>cache.
>See section. "4.2.2  Complete Revocation Refs Attribute Definition".
>
>Denis

Regards,

Denis Pinkas

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 09 Jun 2005 12:50:21 +0200

Vittek Robert wrote:

>[...]
I'd say that with it you *know* that you have the information or that 
you don't have it, so you quit the current state of uncertainty, and 
it's not just decreasing a probability.

>Has this been standardized already? In what RFC (or perhaps ETSI
It has been standardized in OCSP. It's the Archive Cutoff extension. RFC 
2560/&4.4.4

Not including an equivalent for CRL was an amazing oversight.

I'm 100% for porting that extension from OCSP to 3280bis's CRL profile, 
the only question is if we keep the same OID, which would a bit 
illogical there : "id-pkix-ocsp 6"