[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Changes to RFC 3280
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
[mailto: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
>
>
--o---------------------------------------------------------------------
--
> -
> Massimiliano Pala [OpenCA Project Manager]
> madwolf@xxxxxxxxxx
> 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---------------------------------------------------------------------
--
> -