Subject: RE: Proposed Changes to RFC 3280

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 13 Dec 2004 18:53:34 -0000

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: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Massimiliano Pala
> Sent: den 10 december 2004 19:32
> To: [email-masked]
> 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
> 
>
--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: Massimiliano Pala <[email-masked]>
Date: Tue, 14 Dec 2004 17:40:42 +0100

> is still valid and CAs must make sure that there is a valid CRL

Are you sure about this ? The nextUpdate field states that a new
CRL will be made available within that date, but it does not state
that a new CRL will not be made available BEFORE that date.
This means, you should check the repository to be sure the cached
CRL is the most updated one.

Unfortunately there is no way to be sure about the time a new CRL
is issued. But this is another issue, i guess.

> when a new CRL is available if there is an overlap between CRL expiry

This is true, but please notice that in many PKIs new CRLs are issued as
soon as a certificate is revoked. I guess a new field should be added to
address this problem and it should carry the minimum time required for
a new CRL to be publish. This could solve the problem - online CAs could
use a very small timeframe (e.g. 5mins) - while offline CAs could use
a wider timeframe (e.g. 1 day or 1 week).

But this is a bigger change and will break compatibility with existing
applications.

> new CRL is scheduled to be published (prior to expiry of old CRL).

As I just written, this is another problem not covered by the proposal.

Anyway I don't think the use of a *private* extension is the solution.
I would prefer the usage of a non-private extension or (but would
require more work) the definition of a new CRL format (v3?) with the
additional field in the TBSCertList to address this issue.

-- 

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

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 14 Dec 2004 12:08:44 -0500

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

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 14 Dec 2004 19:19:49 +0100

> distributed through untrusted mechanisms.
[...]
> the CRL issuer had published a newer CRL.

You are right, the problem exists. But I think this is a repository-related
problem, not CRL-related. The problem raises from the lack of trust when
distributing CRLs.
To avoid the possibility for an attacker to provide old CRLs, some sort
of trusted channel should be used (e.g. an SSL/TLS channel - if I can
verify the CRL, then I should be able to establish such a channel) for
CRL retrieving.

Anyway, if I am worried about the attack you are envisaging above and
I do not want to use trusted distribution channels, then I still can use
the nextUpdate field - by making it optional it does not mean it is not
possible to use it, right?

> As to your other concern, technically the nextUpdate field is not an 
[...]
> that a newer CRL must be available, the relying party can continue to 

This is something that I never understood, and I think everyone is trying
to avoid in its own PKIs (but this is a personal vision about CRLs).

> that I call over-issued CRLs that helps to address this problem.

I will take a look at this, thanks for the pointer. Anyway, the fact you
have written the paper indicates that the possibility of an overload of the
repository does exist, right?

-- 

Best Regards,

	Massimiliano Pala