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