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

[Stephen Davidson]

Thanks Russ!

 

For the policy identifier, I can see this being true for the Strict profile.  Might be harder for the Multipurpose and Legacy – which may require an additional OID.

 

For the other name, will fix.

 

Best regards, Stephen

 

 

From: Russ Housley <housley at vigilsec.com> 
Sent: Thursday, October 7, 2021 5:13 PM
To: Stephen Davidson <Stephen.Davidson at digicert.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>
Subject: Re: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles

 

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 <mailto: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/54d19a4b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4999 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211007/54d19a4b/attachment-0001.p7s>