View source for CA/Transition SMIME BRs

The CA/Browser Forum "Baseline Requirements for the Issuance and Management of Publicly‐Trusted S/MIME Certificates" ("S/MIME Baseline Requirements") introduces several new requirements for CAs capable of issuing working email certificates.  The purpose of this page is to provide guidance for CAs transitioning toward compliance with the S/MIME Baseline Requirements.

== Audit Migration Plan ==

Effective September 1, 2023, Certification Authorities (CAs) must follow the CA/Browser Forum’s Baseline Requirements for S/MIME Certificates ([https://cabforum.org/smime-br/ S/MIME BRs]). 

A CA operator’s CP or CPS must state that it complies with the current version of the S/MIME BRs. 

[https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/smime-certificates_101_final_aoda-compliant.pdf WebTrust audit criteria] and [https://www.etsi.org/deliver/etsi_ts/119400_119499/11941106/01.01.01_60/ts_11941106v010101p.pdf ETSI audit criteria] are already in place for the S/MIME BRs.
 
CA root certificates and subordinate CA certificates that are technically capable of issuing S/MIME certificates that chain up (either directly or transitively) to a root certificate that has the email (S/MIME) trust bit enabled in Mozilla's CA Certificate Program shall be audited with Period-of-Time audits according to the S/MIME BRs between October 30, 2023, and October 29, 2024, and annually thereafter. 

CA operators that already have an email-trust-bit-enabled CA certificate in the root store may maintain their current annual audit cycles and provide the new S/MIME BR audits when they provide their other annual audit reports, even if they are in the process of requesting inclusion of one or more new, email-trust-bit-enabled root CA certificates. For instance, if a CA operator typically provides audit reports in July 2024 and is requesting the inclusion of a new email-bit-enabled root CA, the corresponding S/MIME BR audit encompassing both existing and new email-trust-bit-enabled root CA certificates can be submitted during the annual audit submission in July 2024.

For any new CA operator requesting inclusion of root CA certificate after October 30, 2023, must be audited according to the S/MIME BRs if the email trust bit is to be enabled.

In most cases, the audit period start date for the first S/MIME BR audit will be September 1, 2023.
* CA operators should modify their CP or CPS on or before September 1, 2023, to assert compliance with the S/MIME BRs.
* The first S/MIME BR audit report should include September 1, 2023, until the regularly-scheduled end of the CA's audit period.
** If the CA operator’s existing regular audit period for other audit types ends after October 30, 2023, then we will expect to receive an S/MIME BR audit that covers September 1, 2023, through the end of that audit period (i.e. a Period-of-Time audit). 

* The first S/MIME BR audit for each CA root certificate and subordinate CA certificate may include a reasonable list of non-compliances that the CA operator (or subordinate CA operator) is not yet in compliance with.
** Major non-compliances should be reported in Bugzilla and corrected as soon as possible
** Only one Incident Bug needs to be filed containing the list of the non-compliances in a CA operator’s first S/MIME BR audit.

* Submission of a CA's S/MIME BR audit report during the second year is expected to confirm that the issues that were listed in the first S/MIME BR audit report have been resolved.

== Re-Issuance of Existing Intermediate CA Certificates for S/MIME ==
 
Section 3.1.3 of Mozilla Root Store Policy requires that all CA keys have the appropriate cradle-to-grave key protection audit reports. However, many existing Intermediate Certificates in the S/MIME ecosystem today were created prior to the establishment of this requirement. In order to facilitate the transition of email certificate-issuing Intermediate CAs to the profile specified in the S/MIME Baseline Requirements, the re-issuance of an existing Intermediate CA Certificate that fulfills all the following requirements (even in the absence of audit reports from key creation) is permitted:

# The original Intermediate Certificate directly or transitively chains to a Root Certificate with the email trust bit enabled in the Mozilla Root Program;
# The original Intermediate Certificate has been audited in accordance with section 3.1.3 and has appeared on the CA Operator's latest audit report;
# The original Intermediate Certificate includes no Extended Key Usage extension, contains anyExtendedKeyUsage in the Extended Key Usage extension, or contains id-kp-emailProtection in the Extended Key Usage extension; and
# The original Intermediate Certificate complies with the profile defined in RFC 5280. The following two deviations from the RFC 5280 profile are acceptable: (a) The original Intermediate Certificate contains a Name Constraints extension that is not marked critical; and/or (b) The original Intermediate Certificate contains a policy qualifier of type UserNotice which contains explicitText that uses an encoding that is not permitted by RFC 5280 (i.e., the DisplayText is encoded using BMPString or VisibleString).

If any of the above requirements are not satisfied by the original Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.

If all of the above requirements are met, then the Intermediate Certificate MAY be re-issued, subject to the following requirements:

# The original and re-issued Intermediate Certificate contain the same Subject Distinguished Name and certify the same key;
# The notAfter field value of the re-issued Intermediate Certificate is less than or equal to the value of the notAfter field of the original Intermediate Certificate; 
# The re-issued Intermediate Certificate contains at least one of the following policy identifier types in the Certificate Policies extension: (a) anyPolicy; and/or (b) one or more of the CA/Browser Forum policy OIDs as defined in section 7.1.6.1 of the S/MIME Baseline Requirements. (Additional policy identifiers MAY be present.); and
# The re-issued Intermediate Certificate complies with the profile for S/MIME Intermediate Certificates as defined in section 7 of the S/MIME Baseline Requirements.

If any of the above requirements are not satisfied by the profile of the re-issued Intermediate Certificate, then the CA Organization SHALL NOT re-issue the Intermediate Certificate.