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

Re: Proposed Changes to RFC 3280


Massimiliano,

The main reason that the nextUpdate field is needed is that CRLs are distributed through untrusted mechanisms.

If I get a CRL from a directory, Web server, or whatever, I can verify the signature on the CRL to ensure that the CRL was really issued by the proper authority, but there are still two possibilities:

(1) I have obtained the most recently issued CRL; or

(2) The CRL that I have obtained is not the most recent one (an attacker, by some means, has caused me to get an older CRL).


Since a CRL issuer can publish a new CRL at any time, I can never be certain that I have obtained the most recent CRL. However, if the CRL includes a nextUpdate time and the current time is after the specified nextUpdate time, then I can be certain that I DO NOT have the most recent CRL. So, if a CRL issuer always included a nextUpdate time that was 24 hours after the thisUpdate time, an attacker could never trick me into using a CRL that is more than 24 hours out of date.

If a CRL did not include a nextUpdate time and the issuer only published a new CRL when the revokedCertificates list changed, an attacker could trick me into using an old CRL, no matter how much time had passed since the CRL issuer had published a newer CRL.

As to your other concern, technically the nextUpdate field is not an expiration time. The nextUpdate field indicates that a new CRL will be published no later than the specified time. A CRL issuer may publish a new CRL before the nextUpdate time. However, the CRL issuer promises that if the nextUpdate time has passed, then a newer CRL will have been published. Even if the relying party knows, from the nextUpdate time, that a newer CRL must be available, the relying party can continue to use the older CRL.

If you are worried about the the possibility that the repository will be overloaded with requests from clients when the nextUpdate time in a CRL is reached, there are tricks that you can use to avoid this problem. In "A Model of Certificate Revocation (see http://csrc.nist.gov/pki/PKImodels/welcome.html), I describe a technique that I call over-issued CRLs that helps to address this problem.

Dave


Stefan Santesson wrote:

Massimiliano,

There seem to be some confusion with your proposal.

The NextUpdate field certainly don't force clients to get a new CRL when
they expire. It is perfectly compliant already to wait to get a new CRL
when you have a certificate to validate.

Effective revocation need the NextUpdate field to know if a cashed CRL
is still valid and CAs must make sure that there is a valid CRL
available.

However there is another problem for those systems that wants to
pre-fetch CRLs. Because the NextUpdate field is actually used as the
expiry date there is no real possibility within the standard to express
when a new CRL is available if there is an overlap between CRL expiry
and CRL update.

This is why Microsoft has added support for a private optional extension
(CRL Next publish with OID 1.3.6.1.4.1.311.21.4) which indicates when a
new CRL is scheduled to be published (prior to expiry of old CRL).

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)




-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx


On Behalf Of Massimiliano Pala
Sent: den 10 december 2004 19:32
To: ietf-pkix@xxxxxxx
Subject: Proposed Changes to RFC 3280

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