View source for CA/BR Audit Guidance

= 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 ==

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 [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.
* Cryptographic algorithm and key sizes must meet BR Appendix A.
* Certificate Extension must comply with BR Appendix B.
* 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].

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 ==
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.

The BR audit statement may be included in the same pdf file as the WebTrust for Certification Authorities audit statement.

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.

== ETSI BR Audit Statement/Certificate ==
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"

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.

ETSI Information/Resources:
* 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

== A CA's First BR Audit ==
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.*'''"

To clarify, if the root certificate is '''not yet in production and is not yet issuing certificates to customers''', then a Point in Time Readiness Assessment of BR compliance (BR PITRA) may be used. 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 certificates for customers, whichever comes first.

On the other hand, if the root certificate '''is in production and has issued certificates to customers''', then the first BR audit must be a full performance audit showing BR compliance over at least 60 days. This situation occurs when a CA applying for inclusion 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. This shorter period-of-time audit is intended for CAs to use for their first BR audit, so they will not have to go through another full-year audit until their next regularly scheduled annual audit.

In the situation where a CA has been issuing certificates to customers before they knew about the BRs, 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 number of BRs the CA did not previously comply with, and the quantity of such certificates issued. Depending on the situation, the CA may be asked to create a new root certificate for inclusion. Therefore, the CA and/or auditor shall provide a list of the BRs that the previously issued certificates did not comply with.

== 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.
* 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 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.
* [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.
* 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 9.6 - 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 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).
* 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

== 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;