Massimiliano,[...]
The main reason that the nextUpdate field is needed is that CRLs are distributed through untrusted mechanisms.
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.
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 use the older CRL.
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).
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.
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?
--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 365Politecnico 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