[Smcwg-public] Stable Draft of S/MIME Certificate Profiles

Russ Housley housley at vigilsec.com
Thu Oct 7 20:12:39 UTC 2021


I have two comments.

1) The Leaf Profile Tab includes:

policyIdentifier - Required	- A policyIdentifier MUST be provided that
                              identifies the policy under which the
                              certificate was issued, and MUST NOT be
                              anyPolicy. MUST include the relevant
                              S/MIME BR reserved OID.

I think this should say that it MUST include one and only one S/MIME BR reserved OID.


2) The Mailbox-validation Tab includes:

subjectAltName - All email addresses in Subject must be in SAN.
                 MUST contain at least one item of type rfc822Name or
                 otherName of type id-on-SmtpUTF8Mailbox. 

                 MUST NOT contain items of type: dNSName, iPAddress,
                 otherName, uniformResourceIdentifier.

                 otherNames of type id-on-SmtpUTF8Mailbox MAY be included
                 and MUST be validated

Obviously, the intent is to allow otherName of type id-on-SmtpUTF8Mailbox, but the middle paragraph does not say that.  It needs to forbid otherName forms other than id-on-SmtpUTF8Mailbox.

Russ


> On Sep 30, 2021, at 4:55 PM, Stephen Davidson via Smcwg-public <smcwg-public at cabforum.org> wrote:
> 
> Hello:
>  
> The S/MIME Certificate Working Group has now completed work on a stable draft of the certificate profiles that will be included in the future S/MIME Baseline Requirements.
>  
> The WG requests that members share this with their product and technical teams seeking feedback as the pace will pick up to turn these worksheets into a draft standard:
> https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit#gid=0 <https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit#gid=0>
>  
> The S/MIME BR will apply to “trusted” leaf certs with emailProtection EKU and at least one email address in Subject / SAN.
>  
> By way of explanation of the worksheet:
>  
> •             SMIME Types – explains the OID structure and cert profile types
> •             Leaf Profile – explains the certificate fields common to the various cert profile types
>  
> There are then 4 major cert profiles showing the major differences in Subject, eKU, keyUsage, and extensions:
> •             Mailbox - The simplest S/MIME, including only email address. The same email control verification methods apply across all S/MIME types.
> •             Organizational - Includes Organization details (legal entity). Example uses include invoice or statement mailers, etc.
> •             Sponsored Individual - Includes personal details (for natural person, which may be validated by Enterprise RA) in association with Organisation details (validated by the CA).
> •             Personal Individual - Includes personal details (for natural person).
>  
> Each of the cert profile types will have three available levels:
> •             Legacy - Allows all public S/MIME to an auditable framework but includes flexibility in allowed field usages and verification.  The intent is that this profile will eventually be sunsetted.
> •             Multipurpose - Aligned with the Strict profile, but with more flexibility in the eKU (primarily to allow overlap with existing use cases such as document signing).
> •             Strict - The final goal profile.  Strict definition and dedicated eKU.
>  
> Discussion is welcomed on list, but we will also dedicate time in our meeting on October 27 for feedback.  Tentatively, we will also start considering CA profiles at that time.
>  
> With kind regards,
> Stephen Davidson
> Chair, S/MIME Certificate Working Group

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211007/66775c10/attachment.html>


More information about the Smcwg-public mailing list