CA/BR Audit Guidance: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
m (Protected "CA/BR Audit Guidance" ([Edit=Allow confirmed users only] (indefinite) [Move=Allow confirmed users only] (indefinite)))
 
(47 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Baseline Requirements (BRs) =
The [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum's Baseline Requirements] provide a foundation for best practices across the industry by defining a single, consolidated set of essential standards for all SSL/TLS certificates. The initial Effective Date of the BRs was 1 July 2012. Refer to the Document History section of the BRs for further information about BR Effective Dates and Relevant Compliance Dates.
[https://wiki.mozilla.org/CA:CertificatePolicyV2.1 Version 2.1] of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] added the requirement that SSL certificate issuance also be audited according to the BRs. This means that CAs with a root certificate included in Mozilla's Program that has the websites (SSL/TLS) trust bit enabled must have their SSL certificate issuance and operations audited annually according to the BRs. Additionally, any Certificate Authority being considered for root inclusion must have a Baseline Requirements audit performed if the websites trust bit is to be enabled for the new root certificate.
This page provides further information about Mozilla's expectations regarding CA compliance with the BRs, and auditing according to the BRs.
= BR Audits =
As with the other audits required of CAs in Mozilla's Program, the BR Audit statement must be a '''public-facing''' document. Section 6 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] says: "We require that all CAs whose certificates are distributed with our software products:
... publicly disclose information about their policies and business practices (e.g., in a Certificate Policy and Certification Practice Statement);
... provide '''*public attestation*''' of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the CA’s internal operations."
As [[CA:CertificatePolicyV2.1#Baseline_Requirements | previously stated]], it is acceptable for an audit statement to list the BRs that the CA is not yet fully in compliance with. However, this may result in an auditor providing information in the BR audit statement that the CA considers sensitive (e.g. subordinate CA specifics, RA information, customer information, or security sensitive information). Each CA must work with their auditor to create a public-facing BR audit statement that does not have information in it that the CA considers sensitive, but that sufficiently lists the BRs that the CA is still working to conform with.
Here are some examples of the level of information that should be included in the BR audit statement in regards to BRs that the CA is not yet fully conforming to.
* BR 9.5 – 1024-bit certs with validity beyond 2013 (in order to support legacy customer apps)
* BR 13.2.6 - OCSP giving status “good” for unknown serial numbers.
* BR 16.5 - multi-factor authentication for '''all''' accounts capable of directly causing certificate issuance
* BR 17.5 - The audit period for the Delegated Third Party SHALL NOT exceed one year
* BR 17.8 –  audits on at least a quarterly basis against a randomly selected sample of the greater of one certificate or '''at least three percent''' of the Certificates issued by it during the period commencing immediately after the previous self-audit sample was taken
* BR 11.2 – re-verifying identity for cert renewal requests
== RFC 5280 ==
A BR audit must include checks to verify that the root, intermediate, and SSL certificates conform to [http://tools.ietf.org/html/rfc5280 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: "Valid Certificate: A Certificate that passes the validation procedure specified in RFC 5280."
BR Appendix B:
* "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."
== Whole-Population Audit of Intermediate Certs ==
== Whole-Population Audit of Intermediate Certs ==


Line 42: Line 6:
Auditing of root and intermediate certificates must include checking compliance with the BRs and with [http://tools.ietf.org/html/rfc5280 RFC 5280]. For example:
Auditing of root and intermediate certificates must include checking compliance with the BRs and with [http://tools.ietf.org/html/rfc5280 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.
* 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.
* Cryptographic algorithm and key sizes must meet BR Appendix A. (section 6.1.5 in BR version 1.3)
* Certificate Extension must comply with BR Appendix B.
* 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 [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] and [https://cabforum.org/baseline-requirements-documents/ BR sections 9.7 and 17].
* Intermediate certificates must either be technically constrained or publicly disclosed and audited as described in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] and [https://cabforum.org/baseline-requirements-documents/ 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.
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.


== WebTrust BR Audit Statement ==
[[File:BR-Audit-Scope.png | BR Audit Scope]]
Mozilla accepts the following BR Criteria provided by [http://www.webtrust.org WebTrust]:
* Principles and Criteria - SSL Baseline Requirements Version 1.1. (Amended) (Superseded)
* WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2


The audit statement must specify the dates over which the BR audit was performed, and that the audit was based on the "AICPA/CICA WebTrust for Certification Authorities – SSL Baseline Requirements Audit Criteria" or the "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security". It is recommended that the audit statement include the version of the criteria that was used.
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 BR audit statement may be included in the same pdf file as the WebTrust for Certification Authorities audit statement.
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.


The BR audit statement may list BRs that the CA is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved.
== RFC 5280 ==


== ETSI BR Audit Statement/Certificate ==
A BR audit must include checks to verify that the root, intermediate, and SSL certificates conform to [http://tools.ietf.org/html/rfc5280 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.
According to section 11 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy], when the websites trust bit is enabled, the only ETSI criteria that is acceptable to Mozilla is  ETSI TS 102 042 V2.3.1 or later (as applicable to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies). ETSI TS 101 456 audit criteria is '''not''' sufficient for CA whose root certificate has the websites (SSL/TLS) trust bit enabled; ETSI TS 101 456 may only be used for email and code signing certificates.  


For an ETSI TS 102 042 certificate to be accepted as a BR audit statement, the certificate must include PTC-BR and must be of version 2.3.1 or later. Note: PTC-BR stands for "Publicly Trusted Certificates - Baseline Requirements"
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."


Mozilla also requires evidence of annual surveillance audits, as required in order to keep the ETSI certificate valid. The statement of annual surveillance audit must include the dates over which the audit was performed, and the version of the audit criteria that was used.
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..."


ETSI Information/Resources:
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."
* http://www.etsi.org/index.php/technologies-clusters/technologies/security/certification-authorities-and-other-trust-service-providers
* http://portal.etsi.org/TBSiteMap/ESI/TrustServiceProviders.aspx


== BR Point in Time Readiness Assessment (BR PITRA) ==
== Checking BR Compliance ==
We [[CA:CertificatePolicyV2.1#Time_Frames_for_included_CAs_to_comply_with_the_new_policy | previously said]]:
"Any Certificate Authority being considered for root inclusion after February 15, 2013 must comply with Version 2.1 or later of Mozilla's CA Certificate Policy. This includes having a Baseline Requirements audit performed if the websites trust bit is to be enabled. '''*Note that the CA's first Baseline Requirements audit may be a Point in Time audit.*'''"
 
There are two cases when a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used:
# The CA has created a new root certificate, which is not yet in operation producing real certificates. In this case a BR PITRA prior to inclusion may be used, but the next annual audit after inclusion would need to be a full performance audit. Note: If the inclusion process spans more than one annual audit cycle, then more than one BR PITRA may be used, until the root certificate has been included or the root certificate is put into operation producing real certificates, whichever comes first.
# The CA did not know about the BRs, so did not get audited according to the BRs during their previous audit cycle. However, the CA does have a current valid audit statement indicating compliance with WebTrust Principles and Criteria for Certification Authorities or ETSI TS 102 042.
#* The BR PITRA option was initially provided for CAs to use for their first BR audit, so they would not have to go through another full audit until their next regularly scheduled annual audit.
#* The BR PITRA shall include a performance audit covering at least one month, or more as determined by the auditor.
#* However, it means that an untold number of the previously issued certificates might not conform to the BRs. This could be serious, depending on which BRs the CA did not previously comply with.
#* The CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with.
#* The CA's next annual audit must include a full BR performance audit.
 
== Audit Mistakes ==
*'''This is a proposal only, to be discussed in the mozilla.dev.security.policy forum.'''
 
During evaluation of a CA's root inclusion or change request, Mozilla uses public audit statements to help confirm that the CA is in compliance with the stated verification requirements, the BRs, and Mozilla's policy. Therefore, when members of Mozilla's community find a problem with certificates in the CA's hierarchy that should have been noted in the audit statement (as an exception or point of non-compliance), the CA may need to be re-audited to confirm that the problem has been resolved.
 
When egregious mistakes were overlooked by the auditor or there are a significant number of oversights, then the CA must resolve the issues and be re-audited. For the re-audit the CA can '''either''' get re-audited by a ''different'' auditor, '''or''' have the current auditor provide an immediate plan for correction and compliance, and then present a mid-term partial audit following that plan. Non-compliance to the following policies are examples of mistakes that auditors should '''not''' overlook.
* BR Appendix A for Root and Sub CA certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
* BR Appendix B for Root and Sub CA certs – Certificate Extensions (Normative) -  This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ 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.
 
There are other types of mistakes that could potentially not be found by an auditor doing sampling of end-entity certificates. If the auditor did not note this type of mistake in the audit statement, then the CA must fix the mistake(s) and be re-audited to confirm that the problem has been resolved. The CA may use the ''same'' auditor that issued the previous audit statement. Examples of this type of mistake include non-compliance with the following:
* BR 9.2.1 - Subject Alternative Name Extension - SSL certs must contain at least one entry
* BR 9.2.2 - 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 - 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 for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
* BR Appendix B for Subscriber certs – Certificate Extensions (Normative) -  This appendix specifies the requirements for Certificate extensions for Certificates generated after the Effective Date.
 
Finally, there are a type of mistakes that may be found during the evaluation of a root inclusion/change request, and resolved by the CA without requiring a re-audit. If someone reports this type of mistake, then the CA must fix the mistake and provide examples to demonstrate that the problem has been resolved. Examples of this type of mistake include non-compliance with the following.
* BR 13.2.2 - Repository  -- CRL and OCSP max expiration time, GET
* BR 3.2.5 OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ 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).
 
= CA Conformance to the BRs =
The CA's CP or CPS documents must include a commitment to comply with the BRs, as described in BR section 8.3.
 
BR section 8.2.1 says: "The CA SHALL develop, implement, enforce, and annually update a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these Requirements."


It is '''not''' sufficient to simply reference section 11 of the CA/Brower Forum's Baseline Requirements (BR). BR #11.1.1 lists several ways in which the CA may confirm that the certificate subscriber owns/controls the domain name to be included in the certificate. Simply referencing section 11 of the BRs does not specify which of those options the CA uses, and is insufficient for describing how the CA conforms to the BRs. The CA's CP/CPS must include a reasonable description of the ways the CA can verify that the certificate subscriber owns/controls the domain name(s) to be included in the certificate.
== Checking BR Compliance ==
Problems to look for when analyzing data of existing sites chaining up to roots being considered for inclusion.
Problems to look for when analyzing data of existing sites chaining up to roots being considered for inclusion.
* BR Appendix A 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 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 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.
* 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.
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ 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:  
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ 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;
** ASN.1 DER encoding errors;
Line 127: Line 53:
** 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
** 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.
** cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists.
* BR 9.2.1 - Subject Alternative Name Extension - SSL certs must contain at least one entry
* 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 - 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.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 - 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 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 for Subscriber certs - Cryptographic Algorithm and Key Requirements (Normative) - Certificates MUST meet the following requirements for algorithm type and key size.
* 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 - CAs SHOULD generate non-sequential Certificate serial numbers that exhibit at least 20 bits of entropy.
* 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 - Repository  -- CRL and OCSP max expiration time, GET
* 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 OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.  
* BR 3.2.5 (section 4.9.9 in BR version 1.3)  OCSP Signing -- OCSP responses MUST conform to RFC2560 and/or RFC5019.  
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ 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).
* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/ 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 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
* The concerns listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
== Monitoring BR Compliance ==
* '''TO DO'''
Process for what happens when it is found that a CA is not complying with the BRs.
{{Bug|1029147}} - (BR-Compliance) Bug for Tracking BR Compliance Issues
http://www.roeckx.be/certificates/ -- overview of how well CAs are complying with the various standards like the CA/Browser forum baseline requirements and RFC 5280.
For different types of issues, may need different dates and seriousness ratings for the issue.
BR 13.1.5 - Reasons for Revoking a Subscriber Certificate - The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ... 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
BR 13.1.6 - Reasons for Revoking a Subordinate CA Certificate - The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs: ... 5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with these Baseline Requirements or the applicable Certificate Policy or Certification Practice Statement;

Latest revision as of 17:56, 24 August 2021

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.allizom.org/index.php?title=CA/BR_Audit_Guidance&oldid=1237520"