[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed Changes to RFC 3280


At 4:50 PM +0100 12/10/04, Massimiliano Pala wrote:
Hello all,

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.

--

C'you,

Massimiliano Pala

The presence of the nextUpdate field allows clients to perform background retrieval of CRLs, in anticipation of later use of these CRLs in verifying certs. That strategy, if properly implemented, reduces the delay seen by the client for cert validation, in a CRL-based system.

I agree that it might be the case that a CRL repository might see increased traffic if every client tried to retrieve a given CRL at the time specified by this field, but whether this proves to be an operational problem is another matter. From what Paul suggested in in message, I gather this has not proven to be the case so far. Also, I am sensitive to Paul's observation that we not adversely affect existing clients who may behave as I noted above. Finally, there is no suggestion in the standard that a CA needs to publish a CRL immediately upon determining that a cert needs to be revoked, so I do not agree with your suggestion that this is normal behavior for CAs today. I know of several very large CAs that definitely do not behave in this fashion; they have set intervals for CRL issuance and they do not issue CRLs in between those times.

Stefan,

The nextUpdate is NOT an expiration time for a CRL. CRLs do not expire; they are superceded by more recent CRLs that provided info that is more current, relevant to a future point in time. This field specifies a time and date by which a CA promises that it will make available a new CRL, even if there have been no new revocation events. As David noted, the field is essential because of the untrusted means by which we distribute CRLs. The field is optional in X.509 because it was not present in v1 CRLs. PKIX mandates its use because lack of the field creates a serious vulnerability.

Steve