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

Wendy Brown - QT3LB-C wendy.brown at gsa.gov
Thu Oct 7 21:46:31 UTC 2021

Re you suggesting only 1 SMIME BR policy in a given certificate or also
prohibiting the inclusion of a policy oid specific to the issuing CA
defined in their own CP in addition to the specific SMIME BR policy OID?



Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

wendy.brown at gsa.gov
wendy.brown at protiviti.com

On Thu, Oct 7, 2021 at 5:00 PM Russ Housley via Smcwg-public <
smcwg-public at cabforum.org> wrote:

> 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
> 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
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/smcwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211007/b090ea06/attachment-0001.html>

More information about the Smcwg-public mailing list