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

[Russ Housley]

Stephen:

I agree that there can be more than one policy OID, but I cannot see a case where there is more than one S/MIME BR reserved OID in the list.

Russ

> On Oct 7, 2021, at 4:57 PM, Stephen Davidson <Stephen.Davidson at digicert.com> wrote:
> 
> 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 <mailto:housley at vigilsec.com>>
> Sent: Thursday, October 7, 2021 5:13 PM
> To: Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto: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/36167930/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211007/36167930/attachment.sig>