Certificate-chain validation, primarily, works based on the Subject 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… 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
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
