Subject: Proposed Changes to RFC 3280

From: Massimiliano Pala <[email-masked]>
Date: Fri, 10 Dec 2004 16:50:20 +0100

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

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               [email-masked]
                                                 Tel.:   +39 (0)59  270  094
http://www.openca.org                           Fax:    +39   178  270 2077
http://openca.sourceforge.net                   Mobile: +39 (0)347 7222 365

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Dec 2004 07:20:23 -0500

>post a possible patch for the document to the list.

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

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Dec 2004 07:20:23 -0500

Stefan,

Steve