All, Our normal process when working with major proposals of the CA/B Forum is to circulate them to this list for discussion and to gather feedback. The purpose of this email is to make you aware that Mozilla is in support of the CA/B Forum’s S/MIME Certificate Working Group <https://cabforum.org/working-groups/smime-certificate-wg/>’s (SMCWG) draft requirements for issuers (Certification Authorities) of publicly-trusted S/MIME certificates. (“S/MIME Baseline Requirements” or “SBRs”). See https://github.com/cabforum/smime/blob/preSBR/SBR.md. (The SMCWG was chartered several years ago to discuss, adopt, and maintain policies, frameworks, and standards for the issuance and management of Publicly-Trusted S/MIME Certificates.) In the next week or so, the SMCWG will be outlining its adoption timeline (i.e. public announcement, public review and discussion, voting period, 60-day IPR review period, and effective date(s)).
As of August 2022, SMCWG membership includes six Certificate Consumers (maintainers of root certificate trust stores and S/MIME software), 30 Certificate Issuers, and 11 non-voting Interested Parties and Associate Members (which include other standards organizations, audit bodies, and bridge CAs, among others). The proposed SBRs will: · define an S/MIME Certificate as any Certificate with the id-kp-emailProtection (OID: 1.3.6.1.5.5.7.3.4) EKU and the inclusion of a rfc822Name or an otherName of type id-on-SmtpUTF8Mailbox in the subjectAltName extension in the Certificate; · address verification of control over email addresses, identity validation for natural persons and legal entities, key management and certificate lifecycle, certificate profiles for S/MIME Certificates and Issuing CA Certificates, as well as CA operational and audit practices; · only apply to issuers of S/MIME certificates that chain up to a root CA certificate in the root store of a Certificate Consumer (they would not apply to the issuance or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only); · specify methods by which Certificate Issuers may verify control over mailbox addresses to be included in certificates--these draw upon experience gained in the TLS Baseline Requirements, and create an additional method to confirm control of a delegated SMTP FQDN; and · define four main Certificate Profiles for the type of validated contents in the Subject DN: Mailbox, Organization, Sponsored, and Individual. o The Sponsored Certificate Profile is commonly used for Enterprise “employee certificates”. o Each main Certificate Profile has three sub-categories: Legacy, Multipurpose, and Strict. § Legacy is meant to encompass existing reasonable practices into an audited regime, and is intended to be deprecated in the future. § Multipurpose is to accommodate existing document-signing practices that often accompany a certificate with the emailProtection EKU (until such time as an independent document signing EKU can be established to properly separate use cases). § Strict presents the long-term target of the S/MIME Certificate Profile. Thanks. Ben Wilson Mozilla Root Store Program Manager -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtabyX%2BjOQ0jRCKRg%3Dd%2BOwmMK8JpKDrpBVAzPxzquVKgznQ%40mail.gmail.com.
