[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