Subject: Proposed Changes to RFC 3280

From: Massimiliano Pala <[email-masked]>
Date: Sat, 11 Dec 2004 04:32:23 +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: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 11 Dec 2004 09:13:52 -0800

>CRL repository upon CRL expiration.

"Could", yes, but so far, we have not heard that this is a problem in 
current deployments.

>So my idea is very simple, indeed. I would suggest to leave the field

Maybe I'm misunderstanding the proposal, but it seems like this would 
cause *massive* problems for currently-deployed systems that expect 
and rely on the nextUpdate field.

>soon as a certificate is revoked

That may be true for some systems, but it certainly isn't true for others.

>  - why being forced to issue a new

Because it is cheap for the CA to do.

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

Please consider my worry above about currently-deployed software. If 
I'm wrong, no problem, but if I'm right, then I can't imagine that 
the benefits of this kind of change would outweigh the difficulties 
for current systems.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sat, 11 Dec 2004 09:13:52 -0800

--Paul Hoffman, Director
--VPN Consortium

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 14 Dec 2004 12:18:21 +0100

Paul Hoffman / VPNC wrote:
[...]
> "Could", yes, but so far, we have not heard that this is a problem in 

This is true, anyway also you said it "Could" lead to problems, therefore
we should change this, I guess.

[...]
> cause *massive* problems for currently-deployed systems that expect and 
> rely on the nextUpdate field.

I don't see these *massive* problems for applications here, indeed as
the ASN.1 states it is an OPTIONAL parameter, an application should
already check the existence of the field before relying on its value...
... I guess these are the basis for good code writing.

Moreover the nextUpdate field (as it is described) carries information
on the date by which the next CRL will be issued, anyway new revocation
data could be made available any time sooner... this means that if I want to
be sure about updated revocation data, I should look at the repository for
new CRLs, nevertheless what the nextUpdate filed value is.

I guess this is not a big change in current software. Indeed there are
examples of software which lets the user to decide when to check for new
CRLs (e.g. once per day).

> Because it is cheap for the CA to do.

This is true. My proposal wants to let CAs establish whether or not to put
the nextUpdate field into CRLs. This will obviously not touch currently
deployed policies (and applications) if the chosen behaviour is to put the
nextUpdate field into CRLs.

By stating the nextUpdate field as optional, I don't want to force CAs not
to use the field.

Please let me know if you have any new comments or objections to the
proposal.

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [email-masked]
                                                 Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: +39 (0)347 7222 365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------