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/

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.

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. In most cases, a TrustDomain implementation will be able to call mozilla::pkix::VerifySignedData for signature verification. The TrustDomain implementation used by PSM is mozilla::psm::NSSCertDBTrustDomain. See security/certverifier/NSSCertDBTrustDomain.h and NSSCertDBTrustDomain.cpp. NSSCertDBTrustDomain uses mozilla::psm::OCSPCache as an in-memory revocation cache. See security/certverifier/OCSPCache.h and OCSPCache.cpp.

The core of BuildCertChain consists of the path-building logic in security/pkix/lib/pkixbuild.cpp. That code makes a number of checks as implemented in security/pkix/lib/pkixcheck.cpp. This is where, for instance, key usages are examined and enforced.

To verify OCSP responses, the library provides mozilla::pkix::VerifyEncodedOCSPResponse (declared in security/pkix/include/pkix/pkix.h). The implementation is in security/pkix/lib/pkixocsp.cpp.

To decode OCSP responses and other DER-encoded data, there is a minimal DER decoding implementation in security/pkix/lib/pkixder.h and pkixder.cpp

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 some of 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
4. OCSP responders should not include a responseExtensions consisting of an empty SEQUENCE (e.g. A2 02 30 00 - see http://tools.ietf.org/html/rfc6960#section-4.2.1 under ResponseData for reference). RFC 3280 defines Extensions as SEQUENCE SIZE (1..MAX) OF Extension, so the empty SEQUENCE is not a valid encoding. Instead of using an empty SEQUENCE, the OCSP responder should just omit the responseExtensions in the ResponseData.
   • Related Bugs: bug 991898
5. According to RFC 5280: "In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation." So, in mozilla::pkix we will not be checking this, but we would like to remind CAs that they are supposed to do this.
   • Related Bugs: bug 991823, bug 997917
6. EV treatment will not be given when the OCSP response for the intermediate certificate is more than 10 days old.
   • Related Bugs: bug 991815

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