Root CAs and CRL Distribution Points
Julien Vehent
I was following the RSA discussion, and I found myself looking for the
CRLs of the included Root CAs...
And, to my (big) surprise, it seems that many of the included CAs
don't have a X509v3 CRL Distribution Points extensions.
I didn't do an exhaustive check, but, so far, about half of them only
seem to have one...
This is very disturbing to me because the french law imposes such CRL
(Décret n°2001-272 du 30 mars 2001, Article 6 - II - d), and i always
assumed that other countries where doing the same.
Moreover, the Mozilla CA Certificate Policy (Version 1.2) bases itself
on international standards, such as ETSI's Policy requirements, that
require CRL availability.
Thus, my question is: what is mozilla's policy on this ? Isn't there a
validation of the CRL before the certificate is added to NSS ? And
shouldn't a certificate be removed from NSS when a CRL isn't available/
valid anymore ?
Thanks,
Julien
Eddy Nigg
> I was following the RSA discussion, and I found myself looking for the
> CRLs of the included Root CAs...
>
Unfortunately there exists a chicken and egg problem and roots actually
can't issue their own suicide note. A root can revoke itself, but in
case of key compromise it's a useless exercise.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Jipe
> On 04/07/2010 12:16 PM, Julien Vehent:
>
> > I was following the RSA discussion, and I found myself looking for the
> > CRLs of the included Root CAs...
>
> Unfortunately there exists a chicken and egg problem and roots actually
> can't issue their own suicide note. A root can revoke itself, but in
> case of key compromise it's a useless exercise.
CAs could include an Authority Revocation List reference and use
different keys to sign certificates and CRL. If its certificates
signing key is compromised, it could revoke his own with the CRL
signing key. It does not solve the chicken/egg problem, but it helps.
Unfortunately many CA included in NSS (ABA.ECOM, Verisign/Secure
server CA, Certnum, maybe others) do not even specify the Key Usage in
their certificates and if it is critical during the verification.
Moreover, several CA (Equifax Secure CA, Deutsche TeleKom) do not
define the Basic Constraints extension as critical \o/
--
Jipe
Julien Vehent
>
> > I was following the RSA discussion, and I found myself looking for the
> > CRLs of the included Root CAs...
>
> Unfortunately there exists a chicken and egg problem and roots actually
> can't issue their own suicide note. A root can revoke itself, but in
> case of key compromise it's a useless exercise.
>
Well, I see two situations here:
- the root is not compromised and revokes itself... that's ok, we stop
trusting the root.
- the root is compromised and revokes itself... well, we should
definitely stop trusting it RIGHT NOW anyway.
So process is:
1. Verify the CRL's signature...
2. OK, CRL is valid..
3. now, what does it say : "stop trusting me"...
4. ok, I stop trusting you.
5. End of the discussion.
But that a very specific case. My point is different: why is there so
many Root CA that do not announce a CRL distribution point ? Are we
suppose to expect this CRL address to be in the server certificate
instead of the CA Certificate ?
I suppose it should be in both, and if there are several CRLs
Distribution Points in the certification chain (eg. root->intermediate-
>server), then all of the CRLs should be checked.
Now, how much can I trust a Certificate Authority that does not even
provide a list of its revocated certificates ???
Eddy Nigg
> CAs could include an Authority Revocation List reference and use
> different keys to sign certificates and CRL. If its certificates
> signing key is compromised, it could revoke his own with the CRL
> signing key. It does not solve the chicken/egg problem, but it helps
Yes, this is one of the reasons why CAs shouldn't sign directly from the
root, but from intermediate CA certificates. Unfortunately for a root
comprise there is only to yank it from the software, something which
might take some time. On the other hand, an off-line root is supposedly
to be more secure and the possibility of a compromise lower.
Michael Ströder
> On 04/07/2010 12:16 PM, Julien Vehent:
>> I was following the RSA discussion, and I found myself looking for the
>> CRLs of the included Root CAs...
>
> Unfortunately there exists a chicken and egg problem and roots actually
> can't issue their own suicide note. A root can revoke itself, but in
> case of key compromise it's a useless exercise.
One could argue that if the key of the root was compromised it would be a very
friendly action of the unauthorized attacker to issue a CRL with that root CA
cert on it. ;-)
Ciao, Michael.
Julien Vehent
That's also my opinion.
But more globally, I'm concerned about mozilla's position on the
following points:
- Accepting Root (or Intermediates) Certicates that do not provide a
CRL Distribution point.
- Not Activating the CRL check by default in Firefox (and, so far, I
haven't found the function to activate it for all Root/Intermediate
CA, I need to add the CRLs one by one...)
Is there any reasons to justify these two decisions ?
Julien
Erwann Abalea
> On 7 avr, 12:44, Eddy Nigg <eddy_n...@startcom.org> wrote:
>> On 04/07/2010 12:16 PM, Julien Vehent:
>>
>>> I was following the RSA discussion, and I found myself looking for the
>>> CRLs of the included Root CAs...
>> Unfortunately there exists a chicken and egg problem and roots actually
>> can't issue their own suicide note. A root can revoke itself, but in
>> case of key compromise it's a useless exercise.
>
> Well, I see two situations here:
> - the root is not compromised and revokes itself... that's ok, we stop
> trusting the root.
> - the root is compromised and revokes itself... well, we should
> definitely stop trusting it RIGHT NOW anyway.
How do you trust a Root? By verifying it's certificate signature? No. Trust is
conveyed off-band, and can only be removed off-band also.
> So process is:
> 1. Verify the CRL's signature...
> 2. OK, CRL is valid..
> 3. now, what does it say : "stop trusting me"...
> 4. ok, I stop trusting you.
> 5. End of the discussion.
X.509 is the normative reference, and is freely downloadable. Check part 10
"Certification path processing procedure", and more importantly parts:
- 10.1 "Path processing inputs"
which repeats that the Root is in fact a public key, and the self-signed
certificate that contains it only a convenient way to store and communicate
this public key (this is precisely described in part 8.1.5 "Self-issued
certificates")
- 10.5 "Certificate processing"
which starts by repeating that self-signed certificates encountered in the
certification path are ignored (first step of the process contains the
verification that the certificate is not revoked)
> But that a very specific case. My point is different: why is there so
> many Root CA that do not announce a CRL distribution point ? Are we
> suppose to expect this CRL address to be in the server certificate
> instead of the CA Certificate ?
That's precisely what the X.509 standard states.
> I suppose it should be in both, and if there are several CRLs
> Distribution Points in the certification chain (eg. root->intermediate-
>> server), then all of the CRLs should be checked.
>
> Now, how much can I trust a Certificate Authority that does not even
> provide a list of its revocated certificates ???
If you only looked at the Root certificate, you can't say this Root doesn't
provide a CRL, since the necessary cRLDistributionPoints extension used to
validate a certificate is not on its issuer, but on itself.
If you can't find X.509 standard document on itu.int site, you can look at the
functionaly equivalent process described in RFC5280, section 6.1.
--
Erwann
Eddy Nigg
> That's also my opinion.
>
> But more globally, I'm concerned about mozilla's position on the
> following points:
> - Accepting Root (or Intermediates) Certicates that do not provide a
> CRL Distribution point.
>
Roots don't have to have CRLDPs because they are roots. However
intermediate CA certificates should have at least a CRLDP and preferable
an OPCS URI in the AIA extension. That's because NSS (and therefore
Firefox) doesn't know to fetch the CRL via CRLDP. But that's to great
part Mozilla's problem, not the CAs.
> - Not Activating the CRL check by default in Firefox (and, so far, I
> haven't found the function to activate it for all Root/Intermediate
> CA, I need to add the CRLs one by one...)
>
Because it doesn't exist. Firefox will however check the OCSP responders
and indeed some CAs have them.
Julien Vehent
> Julien Vehent a crit :
OK, thanks for the clarification.
I was thinking that the Root CA should contain the CRL Distribution
Point for the certificates it signs. But this information is, in fact,
expected in the signed certificate. I didn't know that.
One remaining question: does mozilla, when evaluating a Root CA to add
in NSS, require the presence of CRL Distribution Point or an OCSP
responder ?
I didn't see this specific requirement in the policy, but the
certificates marked in blue in the pending list seem to all have a
valid CRL.
Julien Vehent
> On 04/08/2010 11:28 AM, Julien Vehent:
>
> > That's also my opinion.
>
> > But more globally, I'm concerned about mozilla's position on the
> > following points:
> > - Accepting Root (or Intermediates) Certicates that do not provide a
> > CRL Distribution point.
>
> Roots don't have to have CRLDPs because they are roots. However
> intermediate CA certificates should have at least a CRLDP and preferable
> an OPCS URI in the AIA extension. That's because NSS (and therefore
> Firefox) doesn't know to fetch the CRL via CRLDP. But that's to great
> part Mozilla's problem, not the CAs.
>
> > - Not Activating the CRL check by default in Firefox (and, so far, I
> > haven't found the function to activate it for all Root/Intermediate
> > CA, I need to add the CRLs one by one...)
>
> Because it doesn't exist. Firefox will however check the OCSP responders
> and indeed some CAs have them.
>
OK, so OCSP is the way to go and there is no plan to make the CRL
check automatically ?
Erwann Abalea
> On 8 avr, 11:51, Eddy Nigg <eddy_n...@startcom.org> wrote:
>> On 04/08/2010 11:28 AM, Julien Vehent:
>>> - Not Activating the CRL check by default in Firefox (and, so far, I
>>> haven't found the function to activate it for all Root/Intermediate
>>> CA, I need to add the CRLs one by one...)
>> Because it doesn't exist. Firefox will however check the OCSP responders
>> and indeed some CAs have them.
>
> OK, so OCSP is the way to go and there is no plan to make the CRL
> check automatically ?
X.509 speaking, a CA don't *have* to provide a CRL or an OCSP service. It could
be anything else.
But in practice, CRLs are well supported, but OCSP is something better (well...).
CRL is clearly defined since X.509v1, and since those objects are defined by the
same standard as the identity certificates (X.509, that is), one can expect any
SSL toolkit to be able to support it. But it has some weaknesses. Consider a
large population, with a large revocation rate (you're french? I'm clearly
thinking about the DGI CAs, with 4 CRLs of about 85MB each). In order to load
such a CRL to find if a certificate is revoked, the software needs to "explode"
it, and it takes roughly 10* the size of the raw CRL. Pretty costly operation.
Another example, if you want to sign a document, and include the actual CRL in
it, in order to prove in the future that at the time of the signature, your
certificate was still valid, that a 85MB added to it. Again, for a 300kB
document (by example), that's large.
OCSP, in turn, replaces those big objects by small signed ones, effectively
replacing client load by server load (this can be dealt with). There exist some
bad things also (nothing's perfect), for example in the request, the CA is
identified by 2 hashes, one of it's public key, and one of it's name. The hash
algorithm can be choosen by the client, and is also specified in the request.
That's not in the "spirit" of X.509, because a CA is a name, not a key, this
name can be expressed in different encodings (but X.509 gives precise comparison
rules, a hash can't deal with this); and the fact that the hash algorithm can be
unknown by the OCSP server can be a problem. These things can also be dealt
with, but that's unnecessary work.
From a client side, OCSP is still a better option.
--
Erwann
Nelson B
> On 04/08/2010 11:28 AM, Julien Vehent:
>> That's also my opinion.
>>
>> But more globally, I'm concerned about mozilla's position on the
>> following points:
>> - Accepting Root (or Intermediates) Certicates that do not provide a
>> CRL Distribution point.
>>
>
> Roots don't have to have CRLDPs because they are roots. However
> intermediate CA certificates should have at least a CRLDP and preferable
> an OPCS URI in the AIA extension.
Agreed.
> That's because NSS (and therefore Firefox) doesn't know to fetch the CRL
> via CRLDP.
Not true. NSS does know how to fetch CRLs. It will do so when the program
that is using it asks it to do so. This feature was added to NSS
last year. Firefox now uses it for checking EV certs but not for other
certs.
> But that's to great part Mozilla's problem, not the CAs.
Agreed: the fact that Firefox uses NSS's feature to fetch CRLs as needed
for all EV cert chains, but not for non-EV cert chains, is Mozilla's problem.
>> - Not Activating the CRL check by default in Firefox (and, so far, I
>> haven't found the function to activate it for all Root/Intermediate
>> CA, I need to add the CRLs one by one...)
It may help you to separate the concepts of checking certs against CRLs
that are locally stored, from the concept from fetching CRLs from remote
locations to put them into local stores. NSS has always done the first
of those. It has not always done the second. You could manually start
the process of periodically fetching CRLs from remote URLs, so that your
CRL cache would be kept up to date. Then the CRL check would more
frequently find an up-to-date CRL to check when it wanted to do a check.
> Because it doesn't exist.
Rather, Firefox doesn't enable it for non EV certificate chains.
> Firefox will however check the OCSP responders
> and indeed some CAs have them.
Correct.
Nelson B
> OK, so OCSP is the way to go
OCSP is preferred. Yes.
> and there is no plan to make the CRL check automatically ?
NSS now has the capability to do CRL checks automatically. Mozilla has
enabled them in Firefox only for EV certificate chains. I am not aware
of any plan within Mozilla to do that for non-EV certificate chains.
Eddy Nigg
Thanks for updating us on the newer features....I think I'm getting old :-)
Anyways...how about fetching the CRL in case no OCSP responder exists
and/or no OCSP responder could be contact but a CRLDP exists and this
for all certificates... ?
One of the scenarios for failing OCSP responders and also due to lag
time for disaster recover or other recovery, is usually a static CRL
which gets updated less frequently. It would be good to know that in
such a case Firefox is still able to check the revocation status on
behalf of the relying parties.
Julien Vehent
> On 04/08/2010 11:19 PM, Nelson B:
>
> > On 2010/04/08 05:21 PDT, Julien Vehent wrote:
>
> >> OK, so OCSP is the way to go
>
> > OCSP is preferred. Yes.
>
> >> and there is no plan to make the CRL check automatically ?
>
> > NSS now has the capability to do CRL checks automatically. Mozilla has
> > enabled them in Firefox only for EV certificate chains. I am not aware
> > of any plan within Mozilla to do that for non-EV certificate chains.
>
> Thanks for updating us on the newer features....I think I'm getting old :-)
>
> Anyways...how about fetching the CRL in case no OCSP responder exists
> and/or no OCSP responder could be contact but a CRLDP exists and this
> for all certificates... ?
>
> One of the scenarios for failing OCSP responders and also due to lag
> time for disaster recover or other recovery, is usually a static CRL
> which gets updated less frequently. It would be good to know that in
> such a case Firefox is still able to check the revocation status on
> behalf of the relying parties.
>
That would be a very nice feature. Maybe this could be done as an
extension ?
is there a database somewhere that keep trace of which CA is OCSP
enabled and which isn't ?
Julien Vehent
(I couldn't find the Distribution Point for the DGI's CRL, do you
have it somewhere).
I believe this 85MB CRL is an exception. Verisign CRL's are rather
small:
http://crl.verisign.com/
But you are obviously right, Firefox cannot use the bandwidth to
download a 90MB CRL once a week, users are going to get crazy,
especially if it blocks the SSL handshake !
Two ideas out of the blue:
- Automatic CRL download could be done for CRL smaller than, let's
say, 1MB.
- bandwidth usage could be limited, like first 100KB at max speed,
then 10% of download speed only.
> OCSP, in turn, replaces those big objects by small signed ones, effectively
> replacing client load by server load (this can be dealt with). There exist some
> bad things also (nothing's perfect), for example in the request, the CA is
> identified by 2 hashes, one of it's public key, and one of it's name. The hash
> algorithm can be choosen by the client, and is also specified in the request.
> That's not in the "spirit" of X.509, because a CA is a name, not a key, this
> name can be expressed in different encodings (but X.509 gives precise comparison
> rules, a hash can't deal with this); and the fact that the hash algorithm can be
> unknown by the OCSP server can be a problem. These things can also be dealt
> with, but that's unnecessary work.
>
> From a client side, OCSP is still a better option.
From my memory, the OCSP check blocks the SSL Handshake. Therefore,
even if I agree this is much better than downloading a CRL, isn't
there a risk of heavily reducing connexion speed when OCSP's checks
are done on every connexion ?
CRL download is asynchronous, and can be done once a day/week and then
stored in NSS., thus reducing handshake duration
.
Eddy Nigg
> That would be a very nice feature. Maybe this could be done as an
> extension ?
> is there a database somewhere that keep trace of which CA is OCSP
> enabled and which isn't ?
>
The OCSP URI in the AIA extension will tell you. Obviously that's in the
end-user and sub-ordinate CA certificates.
Eddy Nigg
> From my memory, the OCSP check blocks the SSL Handshake. Therefore,
> even if I agree this is much better than downloading a CRL, isn't
> there a risk of heavily reducing connexion speed when OCSP's checks
> are done on every connexion ?
>
No, checks are done once a day for every certificate (multiple sites may
have the same certificate).
> CRL download is asynchronous, and can be done once a day/week and then
> stored in NSS., thus reducing handshake duration
>
Which obviously reduces the accuracy of the tracked revocations.
Incidentally, revocations are many times most important when they are new...
Julien Vehent
> On 04/09/2010 11:38 AM, Julien Vehent:
>
> > That would be a very nice feature. Maybe this could be done as an
> > extension ?
> > is there a database somewhere that keep trace of which CA is OCSP
> > enabled and which isn't ?
>
> The OCSP URI in the AIA extension will tell you. Obviously that's in the
> end-user and sub-ordinate CA certificates.
>
Found it, it's also here : http://www.mozilla.org/projects/security/certs/included/
Erwann Abalea
> On 8 avr, 18:50, Erwann Abalea <erwann.aba...@keynectis.com> wrote:
>> Julien Vehent a écrit :
>>
>>> On 8 avr, 11:51, Eddy Nigg <eddy_n...@startcom.org> wrote:
>>>> On 04/08/2010 11:28 AM, Julien Vehent:
>> [...]
> have it somewhere).
Sure, since the CAs are operated by us :)
Locate your own DGI certificate, you'll find the CRLdP inside.
http://crl.certificat.com/DGI/DGI_Usager{B,C}.crl
http://crl.certificat2.com/DGI/DGI_Usager{D,E}.crl
covering the 4 CAs.
Their size has diminished a lot, since last time I checked. They're about 40MB
large, now.
> I believe this 85MB CRL is an exception. Verisign CRL's are rather
> small:
> http://crl.verisign.com/
I was talking about a large population, and even more with DGI certificates,
with a high revocation rate (about 40% a year, for 3 years certificates).
From memory, US DoD has/had a CA, with a big population, and producing also a
large CRL.
But I agree, those are exceptions.
> But you are obviously right, Firefox cannot use the bandwidth to
> download a 90MB CRL once a week, users are going to get crazy,
> especially if it blocks the SSL handshake !
>
> Two ideas out of the blue:
> - Automatic CRL download could be done for CRL smaller than, let's
> say, 1MB.
How can you determine the CRL size before downloading it?
[...]
>> From a client side, OCSP is still a better option.
>
> From my memory, the OCSP check blocks the SSL Handshake. Therefore,
That's normal. The check of the revocation status of the web server certificate
blocks the SSL handshake. But this check needs a much lower load (both from
client and server), the OCSP response can be cached, etc.
--
Erwann