SecurityEngineering/mozpkix-testing

mozilla::pkix

Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, OCSP, PKIX, and other security standards.

NSS currently has two code paths for doing certificate verification. "Classic" verification has been used for verification of non-EV certificates, and libPKIX has been used for verification of EV certificates.

As many of you are aware, the NSS team has wanted to replace the "classic" verification with libPKIX for a long time. However, the current libPKIX code was auto-translated from Java to C, and has proven to be very difficult to maintain and use. Therefore, Mozilla has created a new certificate verification library called mozilla::pkix.

Request for Testing

Replacing the certificate verification library can only be done after gaining sufficient confidence in the new code by having as many people and organizations test it as possible. So we ask that all of you help us test this new library as follows.

1. Download Firefox 31 or later
   • Browse to ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/
   • Scroll down to mozilla-central-<platform>-debug and select the folder that matches the platform you are working on.
   • Select the most recent build in the list.
   • Download by selecting the .tar.bz2 (Linux), .dmg (Mac), or .exe (Windows) file.
   • After downloading, extract and run this debug browser, which will be called FirefoxNightlyDebug.
2. mozilla::pkix should be enabled by default. Ensure that it is by doing the following:
   • Open about:config in Firefox
   • Locate the preference "security.use_mozillapkix_verification"
   • If it is true, nothing more needs to be done
   • If it is false, set it to true
   • If it is not present, update to a more recent FirefoxNightlyDebug build
   • Clear your browser cache if you are going to browse to a site you visited with mozilla::pkix off
3. Browse to various websites with known valid and expired/revoked/etc SSL certificates.
4. If you don't get the expected result, then try again without using mozilla::pkix to see if the unexpected result is actually due to mozilla::pkix.
   • In about:config toggle "security.use_mozillapkix_verification" to false
     • Or switch to a previously released version of Firefox
   • Clear your browser cache if you are going to browse to a site you visited with mozilla::pkix on
5. If you find an issue, please file a Bugzilla bug.

Request for Code Review

We will greatly appreciate your help in reviewing the new code, which may be found here:

• mozilla::pkix: https://mxr.mozilla.org/mozilla-central/source/security/pkix/
• trust domain: https://mxr.mozilla.org/mozilla-central/source/security/certverifier/

High level description of folders/files/classes

The main entry-point for verification is mozilla::pkix::BuildCertChain in security/pkix/include/pkix/pkix.h. This function takes a number of required arguments, including an implementation of a mozilla::pkix::TrustDomain, the certificate to verify, the time at which to verify, and whether this is an end-entity certificate or a CA certificate. Additionally, the caller may specify some required properties of some extensions if present. A known-in-advance OCSP response may be included as well. The function returns SECSuccess upon successful verification and SECFailure upon failure (in which case it sets an error code that can be obtained by calling PR_GetError()). The function will optionally return the trusted certificate chain found.

mozilla::pkix::TrustDomain is declared in security/pkix/include/pkix/pkixtypes.h. An implementation of a TrustDomain is responsible for deciding the trust level of a given certificate, finding potential issuers of a given certificate, verifying the signature of a certificate, and determining the revocation status of a certificate. The TrustDomain implementation used by PSM is mozilla::psm::NSSCertDBTrustDomain. See security/certverifier/NSSCertDBTrustDomain.h and NSSCertDBTrustDomain.cpp.

more information to come

If you find an issue, please file a Bugzilla bug (https://bugzilla.mozilla.org/enter_bug.cgi) with Product=Core, Component=Security:PSM, and put "(mozilla::pkix)" at the beginning of the Summary.

For reference, the NSS certificate verification code is here:

• NSS Classic Verification: https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/certhigh/
• NSS LibPKIX Verification: https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/libpkix/

What To Report

We are especially interested in finding errors that cause the following to happen:

1. SSL connections succeed when they should fail, and they did fail in previous releases.
2. EV treatment is given when it should not be given, and was not being given in previous releases.
3. An SSL connection fails when it should have succeeded.
4. EV treatment is not given when it should be.
5. An SSL connection gives a different error than expected.
6. SSL connections succeed when they should fail, and they did not fail in previous releases. For example, see the Things for CAs to Fix section below.
7. EV treatment is given when it should not be given and was being given in previous releases. For example, see the Future Considerations section below.
8. Code Signing certificates do not work as expected.

Mozilla::pkix Bug list

• List OPEN mozilla::pkix bugs
• List ALL mozilla::pkix bugs

Things for CAs to Fix

Workarounds were implemented to allow mozilla::pkix to handle the following situations. We will be asking CAs to immediately stop issuing new certificates with these issues, and we will identify dates for removing these workarounds.

1. Stop using the "Netscape Server Gated Crypto (2.16.840.1.113730.4.1)" (SGC) EKU. For all new certificate issuance, use the "TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)" EKU instead of the SGC EKU.
   • Related Bugs: bug 982292, bug 982932, bug 982936
2. Default values in a SEQUENCE must not be explicitly encoded. We found end-entity certificates that have the value cA:false explicitly encoded.
   • 11.5 of X.690 - "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."
   • Related Bugs: bug 988633, bug 989516, bug 989518
3. Basic constraints: pathLenConstraint must not be included if cA is false
   • RFC 5280 section 4.2.1.9: "CAs MUST NOT include the pathLenConstraint field unless the cA boolean is asserted and the key usage extension asserts the keyCertSign bit."
   • Related Bugs: bug 982878, bug 985021, bug 985025

Future Considerations

While testing mozilla::pkix, we noticed the following things that we would like to consider.

1. In mozilla::pkix we won't accept any OCSP responses that are more than 10 days old, even for intermediate certificates. So EV treatment will not be given when an OCSP response is older than 10 days. The BRs currently say: "For the status of Subordinate CA Certificates: The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate." We should change this. If a CA with an intermediate OCSP nextUpdate six months in the future actually revokes that intermediate today because an attacker got its private key, then an attacker could still MitM users for 6 months from today. We need to require intermediate OCSP nextUpdate values to be 10 days from thisUpdate or less.
   • Related Bugs: bug 991815#c4
2. EV treatment should not be given when the end-entity cert is signed directly by the root cert. The EV Guidelines say: "Root CA Private Keys MUST NOT be used to sign EV Certificates." We should programmatically enforce this.
   • Related Bugs: bug 991921
3. Consider only giving EV treatment when the intermediate and end-entity certs in the chain have the specific EV policy OID that we are expecting; in other words, don’t give EV treatment when the intermediate certificate has the anyPolicy OID. To make this change, would need to change the CAB Forum’s EV Guidelines to also require the EV policy OID in intermediate certs (section 9.3.4 says the subordinate CA certificate may contain anyPolicy OID 2.5.29.32.0).
   • Related Bugs: bug 986156