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

[Russ Housley]

Wendy:

I think there will be more than one policy OID, except in the mailbox-validation case.  However, I cannot see a case where more than one S/MIME BR reserved OID is in the list.

Russ

> On Oct 7, 2021, at 5:46 PM, Wendy Brown - QT3LB-C <wendy.brown at gsa.gov> wrote:
> 
> Russ 
> 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?
> 
> Thanks,
> Wendy
> 
> Wendy Brown
> Supporting GSA FPKI
> Protiviti Government Services
> 
>  703-965-2990 (cell)
> 
> wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov>
> wendy.brown at protiviti.com <mailto:wendy.brown at protiviti.com>
> 
> On Thu, Oct 7, 2021 at 5:00 PM Russ Housley via Smcwg-public <smcwg-public at cabforum.org <mailto: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 <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
> 
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public <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/821a716c/attachment-0001.html>