Roots that are identical except for signature algorithm and serial number
Kathleen Wilson
order for determining which root to use when there are two roots
included that are identical except for signature algorithm and serial
number?
Are there cases when Firefox might see a full cert chain, including
the root (which normally is omitted, at least for SSL/TLS), and NSS
would have a problem if the root presented as part of the cert chain
were not 100% bit-for-bit identical to the pre-loaded root?
Example:
Izenpe (bug #361957) would like to request inclusion into NSS of two
distinct root certificates which are identical with the exception of
Signature Algorithm, Signature Value, Serial Number, SHA-1
Fingerprint, and MD5 Fingerprint.
The two roots are attached to the bug in the following zip file.
https://bugzilla.mozilla.org/attachment.cgi?id=301667
Using the url https://www.ermua.es/ to test…
When I only have the SHA-1 version of the root installed the website
cert chains up to the SHA-1 root.
When I have both the SHA-1 and the SHA-256 versions of the root
installed, the website cert chains up to the SHA-256 root.
In this case, is there any benefit to including both the SHA-1 and the
SHA-256 roots?
Also related, in bug #490895 VeriSign has requested inclusion of the
SHA-1 version of their roots to replace the corresponding old MD5
version of their roots. At the time of inclusion of the SHA-1 version
of the roots, is there any reason to keep the old MD5 version of the
roots in NSS?
Kathleen
Arshad Noor
Key Identifier and the Authority Key Identifier extensions. When
validation code is presented with multiple certificates that have
the same AKIs in the chain, a good programmer will attempt to use
the stronger certificate if it can be successfully verified up to
the root. (If it cannot, he/she will have no choice but to attempt
to chain up the alternate path, if possible).
In the example you've provided, the SHA256 hash on the signature
indicates a stronger signing algorithm than SHA1 (just as SHA1
indicates a stronger signing algorithm than MD5 in the 2nd example).
So, Mozilla correctly chose the right certificate and chain when it
saw the SHA256 hash on one root certificate and SHA1 on the other.
(It will be good to get confirmation from someone on the Mozilla
team that this is a deliberate decision, and not random).
Having both roots in the trust-store enables current and older
operating sytems (pre-SP3 versions of XP, for example, which do not
support SHA256) to chain up to a root successfully. Whether the
browser user should trust a cert-chain based on a specific algorithm
is a subjective decision left up to their own tolerance for risk. If
Mozilla chooses to include only certificates with stronger algorithms
in the NSS database - that's a different policy decision.
Arshad Noor
StrongAuth, Inc.
Kathleen Wilson wrote:
> When processing a cert chain, does Mozilla use a specified algorithm/
> order for determining which root to use when there are two roots
> included that are identical except for signature algorithm and serial
> number?
>
> Are there cases when Firefox might see a full cert chain, including
> the root (which normally is omitted, at least for SSL/TLS), and NSS
> would have a problem if the root presented as part of the cert chain
> were not 100% bit-for-bit identical to the pre-loaded root?
>
> Example:
> Izenpe (bug #361957) would like to request inclusion into NSS of two
> distinct root certificates which are identical with the exception of
> Signature Algorithm, Signature Value, Serial Number, SHA-1
> Fingerprint, and MD5 Fingerprint.
> The two roots are attached to the bug in the following zip file.
> https://bugzilla.mozilla.org/attachment.cgi?id=301667
>
> Using the url https://www.ermua.es/ to test�
Nelson Bolyard
> When processing a cert chain, does Mozilla use a specified algorithm/
> order for determining which root to use when there are two roots
> included that are identical except for signature algorithm and serial
> number?
The algorithm for choosing from among multiple certs with the same
subject name and key ID generally involves picking the "newest" one.
When multiple certs have the same exact notBefore and notAfter dates,
the order is determined by the certs' relative positions in the cert
cache, which is effectively unpredictable. So, for purposes of this
discussion, the short answer to your question is: no.
> Are there cases when Firefox might see a full cert chain, including
> the root (which normally is omitted, at least for SSL/TLS), and NSS
> would have a problem if the root presented as part of the cert chain
> were not 100% bit-for-bit identical to the pre-loaded root?
Yes. Although SSL/TLS servers are not required to send a root cert,
they are not forbidden to do it, either. They may do so. If they send
a root that is different than the root that is known to and trusted by
the client, the client may construct a chain that leads up to the
unknown (and hence untrusted) root, with the result that the chain will
be found to have been issued by an untrusted issuer.
> Example:
> Izenpe (bug #361957) would like to request inclusion into NSS of two
> distinct root certificates which are identical with the exception of
> Signature Algorithm, Signature Value, Serial Number, SHA-1
> Fingerprint, and MD5 Fingerprint.
> The two roots are attached to the bug in the following zip file.
> https://bugzilla.mozilla.org/attachment.cgi?id=301667
>
> Using the url https://www.ermua.es/ to test…
> When I only have the SHA-1 version of the root installed the website
> cert chains up to the SHA-1 root.
> When I have both the SHA-1 and the SHA-256 versions of the root
> installed, the website cert chains up to the SHA-256 root.
>
> In this case, is there any benefit to including both the SHA-1 and the
> SHA-256 roots?
In the case of this test server, which does not send out a root CA
certificate, there is no benefit. However, due to the possibility that
a server with a cert from that CA might send out a chain with either of
those root CA certs in it, having both of those root certs present and
marked trusted in NSS would avoid the problem I described above, where a
chain is found to be untrusted because it leads to an unknown root.
> Also related, in bug #490895 VeriSign has requested inclusion of the
> SHA-1 version of their roots to replace the corresponding old MD5
> version of their roots. At the time of inclusion of the SHA-1 version
> of the roots, is there any reason to keep the old MD5 version of the
> roots in NSS?
Yes, it solves the same potential problem for Verisign, namely that a
server might send out a chain with the "other" root.
> Kathleen
Eddy Nigg
>
>> Also related, in bug #490895 VeriSign has requested inclusion of the
>> SHA-1 version of their roots to replace the corresponding old MD5
>> version of their roots. At the time of inclusion of the SHA-1 version
>> of the roots, is there any reason to keep the old MD5 version of the
>> roots in NSS?
>
> Yes, it solves the same potential problem for Verisign, namely that a
> server might send out a chain with the "other" root.
>
Kathleen posted in this comment
https://bugzilla.mozilla.org/show_bug.cgi?id=490895#c8 that this is also
a reason to keep a MD2 root in NSS even though a SHA1 root is going to
replace it. I'm not sure if this was the conclusion of this discussion,
but I'd suggest not to do that. Also current discussions elsewhere
indicate that those algorithms should be yanked pretty soonish.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Nelson Bolyard
> On 05/21/2009 03:46 AM, Nelson Bolyard:
>>> Also related, in bug #490895 VeriSign has requested inclusion of the
>>> SHA-1 version of their roots to replace the corresponding old MD5
>>> version of their roots. At the time of inclusion of the SHA-1 version
>>> of the roots, is there any reason to keep the old MD5 version of the
>>> roots in NSS?
>>
>> Yes, it solves the same potential problem for Verisign, namely that a
>> server might send out a chain with the "other" root.
Perhaps I was a bit hasty with that reply. Recall that the problem
originally begin discussed, for Izenpe, was caused by the fact that the
"old" and "new" roots both had identical notBefore and notAfter time stamps.
If that had not been true, and one of them was "obviously" newer than the
other (by virtue of having a later notBefore date, or matching notBefore
dates and a later notAfter date), then NSS would always choose the newer
cert, and there would be no value in retaining both certs.
In Verisign's case, I did not look to see if their "old" and "new" roots
have the same notBefore and notAfter dates. If they do, then I stand by
my original answer. If they do not, then my answer should have been that
there is no point in keeping the older root cert.
> Kathleen posted in this comment
> https://bugzilla.mozilla.org/show_bug.cgi?id=490895#c8 that this is also
> a reason to keep a MD2 root in NSS even though a SHA1 root is going to
> replace it. I'm not sure if this was the conclusion of this discussion,
> but I'd suggest not to do that. Also current discussions elsewhere
> indicate that those algorithms should be yanked pretty soonish.
By itself, the presence of an old hash algorithm in the signature of a
trusted root is not a reason to pull the root. The reason for that is
that we generally do not check the signatures on trusted roots. The fact
that the root is marked trusted means that its signature has already been
checked, and it need not be checked again every time.
At some time in the future, I imagine Firefox will stop honoring signatures
that use MD2 and MD5 altogether. (The code to do this is already in NSS,
but must be enabled by the application or by the user.) Firefox will then
find all such signatures to be invalid. Even when we do that, that will
not necessitate that we pull the trusted roots with those old signatures,
because we never check them. The signatures in trusted roots are simply
irrelevant.
Frank Hecker
> On 2009-05-20 13:58, Kathleen Wilson wrote:
>> When processing a cert chain, does Mozilla use a specified algorithm/
>> order for determining which root to use when there are two roots
>> included that are identical except for signature algorithm and serial
>> number?
>
> The algorithm for choosing from among multiple certs with the same
> subject name and key ID generally involves picking the "newest" one.
> When multiple certs have the same exact notBefore and notAfter dates,
> the order is determined by the certs' relative positions in the cert
> cache, which is effectively unpredictable. So, for purposes of this
> discussion, the short answer to your question is: no.
So, just to clarify: I *think* you're proposing that we do the following
in cases where CAs issue new root certificates with stronger signature
algorithms (e.g., upgrading MD2 or MD5 roots to use SHA-1):
1. We should keep the old root certificates in the root list, at least
for now. Rationale: It does no harm to keep the old roots, since we do
not check signatures on roots, and it may prevent possible errors when
Firefox, Thunderbird, etc., receive a full cert chain that includes the
old root.
2. We should encourage CAs to issue the new replacement roots with
notBefore and notAfter dates that are later than the corresponding dates
for the old roots. Rationale: This ensures that NSS will
deterministically select the newer root in cases where there is a choice
to be made. (Does this include the case when Firefox, etc., receive a
full cert chain that includes the old root?)
Is the above a correct reading of your comments?
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Rob Stradling
I recall that GlobalSign recently refreshed their "GlobalSign Root CA":
https://bugzilla.mozilla.org/show_bug.cgi?id=406794
When the new GlobalSign Root CA certificate (which expires in 2028) was added
to NSS, the old certificate (which expires in 2014) was *removed*:
https://bug449883.bugzilla.mozilla.org/attachment.cgi?id=333011
I presume that GlobalSign have not encountered any problems following the
removal of their old certificate from NSS.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Nelson B Bolyard
I read Frank's message, and thought I sent it, but evidently did not send
it until today.)
Frank Hecker wrote, On 2009-05-22 07:24 PDT:
> So, just to clarify: I *think* you're proposing that we do the following
> in cases where CAs issue new root certificates with stronger signature
> algorithms (e.g., upgrading MD2 or MD5 roots to use SHA-1):
>
> 1. We should keep the old root certificates in the root list, at least
> for now. Rationale: It does no harm to keep the old roots, since we do
> not check signatures on roots, and it may prevent possible errors when
> Firefox, Thunderbird, etc., receive a full cert chain that includes the
> old root.
I recommend that for CAs whose newer root certs bear exactly the same
notBefore and notAfter dates as the older certs. In that case, it may be
necessary to retain all the relevant root certs, all marked trusted.
However, for the more common case where the newer cert does not have
identical notBefore and notAfter dates, but has either
a) a newer/later notBefore date, or
b) the same notBefore date and a newer/later notAfter date,
it is not necessary to retain the older certs.
> 2. We should encourage CAs to issue the new replacement roots with
> notBefore and notAfter dates that are later than the corresponding dates
> for the old roots. Rationale: This ensures that NSS will
> deterministically select the newer root in cases where there is a choice
> to be made.
Yes. I'd recommend a newer notAfter date, even if it only differs from
the previous notAfter date by no more than a single second.
> (Does this include the case when Firefox, etc., receive a
> full cert chain that includes the old root?)
Yes.
Note: above, where I said "date" or "dates", I meant the entire date/time
value, including the time as well as the date.
Frank Hecker
replacement by new roots:
> I recommend that for CAs whose newer root certs bear exactly the same
> notBefore and notAfter dates as the older certs. In that case, it may be
> necessary to retain all the relevant root certs, all marked trusted.
>
> However, for the more common case where the newer cert does not have
> identical notBefore and notAfter dates, but has either
> a) a newer/later notBefore date, or
> b) the same notBefore date and a newer/later notAfter date,
> it is not necessary to retain the older certs.
Thanks for the advice, this answers the question as far as I'm concerned.
Kathleen Wilson
In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
roots expire on 2028-08-02, so the SHA1 roots would take precedence in
NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
MD2 roots should be removed when the SHA1 roots are added.
In the Izenpe case, they are requesting to add both the SHA1 and the
SHA256 roots.
The SHA1 dates are
12/13/2007 5:08:27 AM
12/13/2037 0:27:25 AM
The SHA256 dates are
12/13/2007 5:08:28 AM
12/13/2037 0:27:25 AM
NSS will always pick the SHA256 root, because its NotBefore date is
one second later than that of the SHA1 root.
This means that if the SHA256 root is included, there is no benefit in
also including the SHA1 root.
However, Izenpe may want to consider only including the SHA1 root
because many of their customers may be using operating systems that
don’t yet support SHA256.
Is this correct?
Thanks,
Kathleen
Nelson B Bolyard
> Just to make sure I understand…
>
> In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
> roots expire on 2028-08-02, so the SHA1 roots would take precedence in
> NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
> MD2 roots should be removed when the SHA1 roots are added.
That is also my understanding.
> In the Izenpe case, they are requesting to add both the SHA1 and the
> SHA256 roots.
>
> The SHA1 dates are
> 12/13/2007 5:08:27 AM
> 12/13/2037 0:27:25 AM
>
> The SHA256 dates are
> 12/13/2007 5:08:28 AM
> 12/13/2037 0:27:25 AM
>
> NSS will always pick the SHA256 root, because its NotBefore date is
> one second later than that of the SHA1 root.
Correct. NSS will use the newer root when validating certificates
received from remote peers, and it will send out the newer root in the
event that the user has a cert issued by that CA, and uses that cert
for signing email or performing SSL client authentication.
> This means that if the SHA256 root is included, there is no benefit in
> also including the SHA1 root.
Agreed. Including both roots offers no advantage over including the SHA256
root alone.
> However, Izenpe may want to consider only including the SHA1 root
> because many of their customers may be using operating systems that
> don’t yet support SHA256.
There are two cases to be considered here.
1) The local NSS user is acting as a "relying party" and NSS is verifying a
cert chain received from some other "peer" party.
2) The local NSS user is acting as a "subject party" and NSS is sending out
the cert chain for the local NSS user to some other "peer" party.
When acting as a "relying party", there is no advantage to an NSS user for
NSS to retain Izenpe's SHA1 cert to the exclusion of their SHA256 cert,
because NSS itself can handle both kinds on all supported systems.
When acting as a "subject party", sending out the local user's cert chain,
in some cases, NSS will send out the full chain up to and including the
root CA cert, and in other cases, NSS will send out a partial chain
containing certs up to but NOT including the root CA cert.
In the current NSS releases (3.11.x and 3.12.x) an NSS subject party will
send a PARTIAL chain
- when sending an SSL client's cert chain (performing client auth),
- when sending a signed S/MIME (CMS) message
and will send a FULL chain
- when sending an SSL server's cert chain (acting as an SSL server)
- when constructing a PKCS#12 file containing a private key and cert chain
The type of root cert in NSS's cert store makes no difference in the partial
chain cases. In the full chain cases, it could make a difference.
An SSL server that sends out a full chain with a SHA256 root could
conceivably cause a problem for a remote SSL client that does not understand
SHA256 signatures and that chooses to check the signature on the received
root cert rather than, or in addition to, relying on its own local trusted
copy of the root cert for that CA. However, with respect to usage of NSS
for SSL/TLS, Mozilla software presently does not act as an SSL server, but
only as an SSL client. So, this is not a concern to Mozilla browser users.
Mozilla clients have understood SHA256 signatures for years.
The only remaining case that could possibly be of concern to mozilla users
is the PKCS#12 file creation case. If a mozilla user created a PKCS#12
file with a SHA256 root, and then tried to import that file into some
other program that does not understand certs with SHA256 signatures, that
other program might refuse to import the contents of that file.
I think that covers all the considerations that would go into a decision
of whether to include only a SHA1-based cert, or whether to include a
newer SHA256 cert. I will stop short of making a recommendation for
Izenpe in this case.
/Nelson
Frank Hecker
> An SSL server that sends out a full chain with a SHA256 root could
> conceivably cause a problem for a remote SSL client that does not understand
> SHA256 signatures and that chooses to check the signature on the received
> root cert rather than, or in addition to, relying on its own local trusted
> copy of the root cert for that CA. However, with respect to usage of NSS
> for SSL/TLS, Mozilla software presently does not act as an SSL server, but
> only as an SSL client.
Correct. However this could affect, e.g., NSS used in the context of
mod_nss and the Apache web server, would it not?
Frank Hecker
>> However, Izenpe may want to consider only including the SHA1 root
>> because many of their customers may be using operating systems that
>> don’t yet support SHA256.
> I think that covers all the considerations that would go into a decision
> of whether to include only a SHA1-based cert, or whether to include a
> newer SHA256 cert. I will stop short of making a recommendation for
> Izenpe in this case.
Kathleen, I think the best approach is to present Izenpe with Nelson's
analysis (for which, thanks!) and let them decide. Personally I think
the potential downside from including the SHA-256 root is pretty small.
Robert Relyea
you only include the SHA-1 certificate, then if any server sends the
SHA-256 certificate, FF may not correctly validate the chain (certainly
under the current cert validation code, that will not work). This is
because NSS will chain to the SHA-256 cert which it received from the
server, but would not trust it.
In the case of FF, it seems like the best bet would be to include the
SHA-256 certificate for the greatest compatibility.
bob
Rick Andrews
> On 2009-05-28 10:52 PDT, Kathleen Wilson wrote:
>
> > Just to make sure I understand…
>
> > In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
> > roots expire on 2028-08-02, so the SHA1 roots would take precedence in
> > NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
> > MD2 roots should be removed when the SHA1 roots are added.
>
> That is also my understanding.
Hold on please - we would like the MD2 roots to remain alongside the
SHA1 roots. The reason is that we have issued several intermediate CAs
from the MD2 root which bear the serial number of the MD2 root in
their AKI extension. When we created the SHA1 roots, we added one day
to the validity period and kept the DN and key the same, but we gave
it a different serial number (that is our practice). We discovered too
late that Firefox uses the AKI to find the issuer, and if it's not
found, Firefox does not fall back to other methods (like using the
Issuer DN, as other browsers do). Hence we need the MD2 roots to
remain in Firefox until customers renew and replace their SSL certs
signed by intermediates that contain the AKI extension pointing to the
MD2 root. We expect that might take several years.
-Rick
Nelson B Bolyard
> On May 28, 3:12 pm, Nelson B Bolyard <nel...@bolyard.me> wrote:
>> On 2009-05-28 10:52 PDT, Kathleen Wilson wrote:
>>
>>> Just to make sure I understand…
>>> In the VeriSign case the MD2 roots expire on 2028-08-01, and the SHA1
>>> roots expire on 2028-08-02, so the SHA1 roots would take precedence in
>>> NSS. Therefore, there is no benefit in keeping the MD2 roots, and the
>>> MD2 roots should be removed when the SHA1 roots are added.
>> That is also my understanding.
>> ...
>
> Hold on please - we would like the MD2 roots to remain alongside the
> SHA1 roots. The reason is that we have issued several intermediate CAs
> from the MD2 root which bear the serial number of the MD2 root in
> their AKI extension. When we created the SHA1 roots, we added one day
> to the validity period and kept the DN and key the same,
How about the subject key ID? Did it change?
> but we gave it a different serial number (that is our practice).
Exactly as it should be!
> We discovered too late that Firefox uses the AKI to find the issuer, and
> if it's not found, Firefox does not fall back to other methods (like
> using the Issuer DN, as other browsers do).
The behavior you describe above is true for Firefox 2.0.x and older Mozilla
browsers. It was changed in July 2008, and the change appears in all
these products/versions and their successors:
- FireFox 3.0.0.0
- Thunderbird 2.0.0.21
- SeaMonkey 1.1.15
- Camino 1.6.7
However, the proposed change to the root certs list (adding a new root and
removing an old MD2 root) will only affect new browsers released after this
date, and will not affect the root cert lists in old Mozilla browsers such
as Firefox 2.0.x because Mozilla has no plans to ever release any new
updates to those old releases.
> Hence we need the MD2 roots to remain in Firefox until customers renew
> and replace their SSL certs signed by intermediates that contain the AKI
> extension pointing to the MD2 root. We expect that might take several
> years.
New Mozilla browsers released after this date do not and will not have the
problem you described above. So, it should not be necessary to retain the
MD2 certs in the root list for these new browser products. This change will
have no effect on older browsers that are not updated.
Rick Andrews
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new browser products. This change will
> have no effect on older browsers that are not updated.
OK, thanks for the clarification.
-Rick
Rick Andrews
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new browser products. This change will
> have no effect on older browsers that are not updated.
OK, thanks for the clarification.
-Rick
Rick Andrews
No, it didn't. The key and SKI stayed the same.
...
> New Mozilla browsers released after this date do not and will not have the
> problem you described above. So, it should not be necessary to retain the
> MD2 certs in the root list for these new browser products. This change will
> have no effect on older browsers that are not updated.
OK, thanks for the clarification.
-Rick