going through rfc3280 and reading the sections 5, 5.1, 5.1.2.5 about CRLs and nextUpdate field one idea came into my mind. The rfc enforces the use of the nextUpdate field which envisages the idea that new revocation information will be available within the retained time value.
This could lead to some problems because all clients will query the CRL repository upon CRL expiration. Moreover, in practical environment, there is the common thought that the nextUpdate filed carries the time when new revocation data will be available, which (correct me if I am wrong) is not.
So my idea is very simple, indeed. I would suggest to leave the field OPTIONAL (as in ASN.1).
If the field is not present, then compliant applications should check for new CRL when validating a certificate. This is pretty the same way OCSP handles the nextUpdate field within responses, isn't it?
Indeed the default behaviour for today CAs is to issue new CRLs as soon as a certificate is revoked - why being forced to issue a new CRL if no new data is indeed available ?
Let me know your comments, if there are no major objection I will post a possible patch for the document to the list.
--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] madwolf@xxxxxxxxxx
Tel.: +39 (0)59 270 094
http://www.openca.org Fax: +39 178 270 2077
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365University of Modena and Reggio Emilia Certification Authority Informations:
Authority Access Point http://pki.unimo.it Authority's Certificate: http://pki.unimo.it/ca/issuers.html Certificate Revocation List: http://pki.unimo.it/crl/cacrl.crl --o------------------------------------------------------------------------
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature