RE: RE: CRL sequence issues

["Vittek Robert" <vittek@xxxxxxxx>]

First, I have to make one correction: the verification time (referenced
in validation process) is of course BEFORE the end of validity of the
signer's certificate, even though the verification process itself occurs
later. The problem is the certificate that expired soon after the (time
stamped) signature was made.

Now, to your proposal: Yes, I agree...it is simple and practical in most
of the cases.

But, certificates cost money (significant for some people here). And
someone may insist on being able to use the certificate until its very
end, because he paid for it. At the same time, he might not want to buy
another certificate from CA for whatever reasons. How is any signature
validator (usually the third party) supposed to explain a refused signed
document to the customer (the signer)?

For me, the best solution seems to be the expiredCertsOnCRL extension
(mentioned by Mr. David Cooper). Until CAs do not start to include this
extension in their CRLs, the signature verification systems will have to
mark such controversial signatures as undecidable and let the decision
for human. I admit that this can work in systems that we produce and I
might not be able to cover all use cases.

Robert Vittek


-----Original Message-----
From: Denis Pinkas [mailto:denis.pinkas@xxxxxxxx] 
Sent: Thursday, June 09, 2005 12:21 PM
To: Vittek Robert
Cc: pkix
Subject: Re: RE: CRL sequence issues


>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)?

There is a simple and practical way to deal with this "non-issue".

Signers SHOULD receive their new certificate before their current
certificate expires, and SHOULD use it as soon as they receive that new
one. If they do it, then there is no problem. 

If they don't do it (or if they can't), then electronic signatures
CANNOT be verified anymore, when the verification time is after the end
of validity of the signer's certificate.

There is no need for new extensions.

Denis 

>Best regards,
>Robert Vittek
> 
>
>-----Original Message-----
>From: Denis Pinkas [mailto:denis.pinkas@xxxxxxxx]
>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:denis.pinkas@xxxxxxxx]
>>Sent: Wednesday, June 08, 2005 1:06 PM
>>To: Vittek Robert
>>Cc: ietf-pkix@xxxxxxx
>>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