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

Re: Proposed Changes to RFC 3280



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.

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.

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

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

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]      massimiliano.pala@xxxxxxxxx
                                                 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------------------------------------------------------------------------

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature