CA/BR Audit Guidance

From MozillaWiki
< CA
Jump to: navigation, search

Whole-Population Audit of Intermediate Certs

BR Audits must always include the whole-population audit of intermediate certificates that are capable of issuing SSL certs. The CA's roots and all of their intermediate certificates (that are capable of issuing SSL certs) must always be audited for conformance to the stated standards. In the BR audit, sampling can be used only for end-entity certificates.

Auditing of root and intermediate certificates must include checking compliance with the BRs and with RFC 5280. For example:

  • Intermediate certificates must be checked for duplicate serial numbers, which is forbidden by section 4.1.2.2 of RFC 5280.
  • Cryptographic algorithm and key sizes must meet BR Appendix A. (section 6.1.5 in BR version 1.3)
  • Certificate Extensions must comply with BR Appendix B. (section 7.1.2 in BR version 1.3)
  • Intermediate certificates must either be technically constrained or publicly disclosed and audited as described in Mozilla's CA Certificate Inclusion Policy and BR sections 9.7 and 17. (sections 7.1.5 and 8.1 in BR version 1.3)

Definition: An intermediate certificate that does not have an Extended Key Usage (EKU) extension, has id-kp-serverAuth extended key usage, or has the anyExtendedKeyUsage KeyPurposeId is considered capable of issuing SSL certificates.

BR Audit Scope

All root and intermediate certificates must be audited according to the Baseline Requirements, and end entity certificates may be audited on a sample basis. For the above diagram:

  • 'Public Root CA' must be audited
  • 'Issuing CA 1' issues SSL certificates so it would be subject to audit, PLUS its end-entity certificates would need to be audited at least on a sample basis
  • 'Issuing CA 2' has an EKU that allows SSL certificates, so it would be subject to audit, PLUS its end-entity certificates as well to verify that no SSL certificates have been issued.
  • 'Sub CA 3', operated by ABC Corp, is subject to audit
  • 'Sub CA 3a' PLUS its end-entity certs are subject to audit
  • 'Sub CA 3b' is subject to audit, but not its end-entity certificates because the EKU restricts to SMIME only
  • 'Sub CA 4', operated by XYZ Corp, is subject to audit, but not its end-entity certificates because Sub CA 4 is technically constrained in line with BRs

The colors in the above diagram represent the following:

  • Green -- All green certificates are in full scope, must be audited. End-entity certs may be sampled.
  • Yellow -- The subordinate CA certificate is in scope of audit, but the certificates below it are not in scope.
  • Red -- The certificates that are not in scope of audit.
  • Blue -- The blue certificates should not be in scope, but since the subordinate CA certificate did not have the EKU to prevent SSL certificate issuance, the auditor must perform procedures to confirm that there are no SSL certificates.

RFC 5280

A BR audit must include checks to verify that the root, intermediate, and SSL certificates conform to RFC 5280. Given that the BRs normatively incorporate RFC 5280, auditors MUST be checking compliance in order to evaluate whether or not a given certificate conforms to the BRs.

BR section 4 (section 1.6.1 in BR version 1.3): "Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280."

BR Appendix B (section 7.1.2.4 in BR version 1.3):

  • "All other fields and extensions MUST be set in accordance with RFC 5280."
    • Note: "fields" includes non-extension fields.
  • "Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used..."

RFC 5280 is clear as a profile of what constitutes a 'valid' PKIX X.509 certificate. Fields that fail to adhere to the technical requirements do not conform to the BRs. For example, RFC 5280 Section 4.1.2.2: "The serial number MUST be a positive integer assigned by the CA to each certificate. It MUST be unique for each certificate issued by a given CA (i.e., the issuer name and serial number identify a unique certificate). CAs MUST force the serialNumber to be a non-negative integer."

Checking BR Compliance

Problems to look for when analyzing data of existing sites chaining up to roots being considered for inclusion.

  • BR Appendix A (section 6.1.5 in BR version 1.3) for Root, Sub CA, and Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size...
  • BR Appendix B (section 7.1.2 in BR version 1.3) for Root, Sub CA certs, and Subscriber certs – Certificate Extensions (Normative) - This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
  • Mozilla CA Certificate Inclusion Policy section 4: We reserve the right to not include a particular CA certificate in our software products. ... CAs that issue certificates that have:
    • ASN.1 DER encoding errors;
    • invalid public keys (e.g., RSA certificates with public exponent equal to 1);
    • duplicate issuer names and serial numbers;
    • incorrect extensions (e.g., SSL certificates that exclude SSL usage, or authority key IDs that include both the key ID and the issuer’s issuer name and serial number); or
    • cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
  • BR 9.2.1 (section 7.1.4.2.1 in BR version 1.3) - Subject Alternative Name Extension - SSL certs must contain at least one entry
  • BR 9.2.2 (section 7.1.4.2.2 in BR version 1.3) - Subject Common Name Field - If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate’s subjectAltName extension
  • BR 9.4.1 (section 6.3.2 in BR version 1.3) - Subscriber Certificates - Subscriber Certificates issued after the Effective Date (1 July 2012) MUST have a Validity Period no greater than 60 months. (exceptions allowed)
  • BR Appendix A (section 6.1.5 in BR version 1.3) for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
  • BR 9.6 (section 7.1 in BR version 1.3) - CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.
  • BR 13.2.2 (section 4.9.10 in BR version 1.3) - Repository -- CRL and OCSP max expiration time, GET
  • BR 3.2.5 (section 4.9.9 in BR version 1.3) OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.
  • Mozilla CA Certificate Maintenance Policy section 9: all new end-entity certificates must contain at least 20 bits of unpredictable random data (preferably in the serial number).
  • The problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes
  • The concerns listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/BR_Audit_Guidance&oldid=1237520"