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.
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
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
