S/MIME BR Transition Wiki Page

505 views
Skip to first unread message

Ben Wilson

unread,
Jul 19, 2023, 1:01:36 PM7/19/23
to dev-secur...@mozilla.org

All,

I have created a wiki page (https://wiki.mozilla.org/CA/Transition_SMIME_BRs) to address miscellaneous issues that might arise for CAs in their transition toward compliance with the CA/Browser Forum’s Baseline Requirements for S/MIME Certificates (S/MIME BRs). (The wiki page is for items that are not directly explained in the upcoming version 2.9 of the Mozilla Root Store Policy.)

The first issue addressed in the wiki page relates to the re-issuance of existing intermediate CAs used for issuing S/MIME certificates. Based on language provided by Corey Bonnell, the wiki page explains how Mozilla expects S/MIME CA re-issuance to occur. 

We may add explanations about other items of concern to the wiki page in the future, and if so, I’ll advise you accordingly.

Thanks,

Ben

Ben Wilson

unread,
Jan 2, 2024, 2:52:39 PMJan 2
to dev-secur...@mozilla.org
All,

I am editing the S/MIME Baseline Requirements transition guidance wiki page (https://wiki.mozilla.org/CA/Transition_SMIME_BRs) slightly to make it more clear that existing CA operators are to submit their S/MIME BR audit reports consistent with their existing audit cycles. Right now, the language on the wiki page says, "For CA operators to maintain their current annual audit cycles, new S/MIME BR audits should be provided when they provide their other annual audits."  This seems pretty straightforward.  But then it says, "Any root CA certificate being considered for inclusion after October 30, 2023, must be audited according to the S/MIME BRs if the email trust bit is to be enabled, and the CA operator’s CP or CPS must state that they follow the current version of the S/MIME BRs."  

This latter sentence might be inferred to mean that an earlier, out-of-cycle audit would be required for new root CA certificates created by existing CAs. I am recommending that we change this to make it clear that if an existing CA operator has an email-trust-bit-enabled CA certificate in the root store, then it can submit its S/MIME BR audit (that will include new, email-enabled root CAs) when it provides its other regularly-scheduled, other audits. For example, if a CA operator in the Mozilla root program usually submits their audits in July, and they are requesting the inclusion of a new email-enabled root CA, then that S/MIME BR audit can be submitted in July, too. 

Here are my suggested revisions:

For CA operators that already have an email-trust-bit-enabled CA certificate in the root store to may maintain their current annual audit cycles and provide, the new S/MIME BR audits should be provided 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 a Any root CA certificate being considered for inclusion after October 30, 2023, the root CA must be audited according to the S/MIME BRs if the email trust bit is to be enabled.

A , and the CA operator’s CP or CPS must state that they follow the current version of the S/MIME BRs.

Are there any comments or suggestions?

Thanks,

Ben

 
Reply all
Reply to author
Forward
0 new messages