From Stephen.Davidson at digicert.com  Thu Oct  7 20:57:58 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Thu, 7 Oct 2021 20:57:58 +0000
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <7B3CF8D5-9976-42A0-BCAC-1E7A6E2BE4BD@vigilsec.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
 <7B3CF8D5-9976-42A0-BCAC-1E7A6E2BE4BD@vigilsec.com>
Message-ID: <BL1PR14MB5143340163D0BF152F5147D8E5B19@BL1PR14MB5143.namprd14.prod.outlook.com>

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>

From housley at vigilsec.com  Thu Oct  7 20:12:39 2021
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 7 Oct 2021 16:12:39 -0400
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
Message-ID: <7B3CF8D5-9976-42A0-BCAC-1E7A6E2BE4BD@vigilsec.com>

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>

From wendy.brown at gsa.gov  Thu Oct  7 21:46:31 2021
From: wendy.brown at gsa.gov (Wendy Brown - QT3LB-C)
Date: Thu, 7 Oct 2021 17:46:31 -0400
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <0100017c5c8d767b-758bb15f-05bf-47ad-9381-317420ab1d2d-000000@email.amazonses.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
 <0100017c5c8d767b-758bb15f-05bf-47ad-9381-317420ab1d2d-000000@email.amazonses.com>
Message-ID: <CADw9x2t0pSBOLLCFL7h7N44Jg_KyQ4BQ9QVS-Q4wvZsEnJ=C8A@mail.gmail.com>

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
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>

From housley at vigilsec.com  Thu Oct  7 22:20:23 2021
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 7 Oct 2021 18:20:23 -0400
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <BL1PR14MB5143340163D0BF152F5147D8E5B19@BL1PR14MB5143.namprd14.prod.outlook.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
 <7B3CF8D5-9976-42A0-BCAC-1E7A6E2BE4BD@vigilsec.com>
 <BL1PR14MB5143340163D0BF152F5147D8E5B19@BL1PR14MB5143.namprd14.prod.outlook.com>
Message-ID: <08547412-80C0-4ED5-B162-3919353CA4FE@vigilsec.com>

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>

From housley at vigilsec.com  Thu Oct  7 22:21:55 2021
From: housley at vigilsec.com (Russ Housley)
Date: Thu, 7 Oct 2021 18:21:55 -0400
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <CADw9x2t0pSBOLLCFL7h7N44Jg_KyQ4BQ9QVS-Q4wvZsEnJ=C8A@mail.gmail.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
 <0100017c5c8d767b-758bb15f-05bf-47ad-9381-317420ab1d2d-000000@email.amazonses.com>
 <CADw9x2t0pSBOLLCFL7h7N44Jg_KyQ4BQ9QVS-Q4wvZsEnJ=C8A@mail.gmail.com>
Message-ID: <77E55528-EFF7-47D2-A6C5-562A8653E567@vigilsec.com>

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>

From Stephen.Davidson at digicert.com  Thu Oct  7 23:07:39 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Thu, 7 Oct 2021 23:07:39 +0000
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <08547412-80C0-4ED5-B162-3919353CA4FE@vigilsec.com>
References: <0100017c387dd415-7a1865b2-605d-41b0-9dcf-cfc3814293cb-000000@email.amazonses.com>
 <7B3CF8D5-9976-42A0-BCAC-1E7A6E2BE4BD@vigilsec.com>
 <BL1PR14MB5143340163D0BF152F5147D8E5B19@BL1PR14MB5143.namprd14.prod.outlook.com>
 <08547412-80C0-4ED5-B162-3919353CA4FE@vigilsec.com>
Message-ID: <B0DF491A-93F2-4C8C-9EA9-C20E5C5D08C2@digicert.com>

Aha!  Understood!
Thanks for pointing that out; willfix.
best, Stephen

On Oct 7, 2021, at 7:20 PM, Russ Housley <housley at vigilsec.com> wrote:

?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<mailto: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

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/19a4cabb/attachment-0001.html>

From M.Wiedenhorst at tuvit.de  Tue Oct 26 07:20:58 2021
From: M.Wiedenhorst at tuvit.de (Wiedenhorst, Matthias)
Date: Tue, 26 Oct 2021 07:20:58 +0000
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <0100017c387dd56a-790bb90b-4a4f-4636-9f58-0ae6444be1e7-000000@email.amazonses.com>
References: <0100017c387dd56a-790bb90b-4a4f-4636-9f58-0ae6444be1e7-000000@email.amazonses.com>
Message-ID: <9d15a90935c14782b926e4c08733a59b@tuvit.de>

Hi Stephen, all,

a few points regarding the profiles from my perspective.

My understanding was that the ?Sponsored Individual? profile was to be a merge of the ?Org-validation? and the ?Personal Individual? profiles. While that is true for the Organization part, it is not for the Individual part. Givenname und Surname are mandatory in the Strict and Multipurpose Personal Individual Profile, but only a ?may? in the Sponsored Individual.
Pseudonym is forbidden (see separate remark below) in Personal Individual, but a ?may? in Sponsored Individual.
Is there any reason for this?
If someone would issue a Sponsored Individual certificate and an Org-validation cert that include only the mandatory DN fields (O, C, orgIdentifier), than this two would be identical in profile.


With regard to pseudonym:
In the ?Personal Individual?-profile the use of ?pseudonym? is declared as ?must not?. However, the European eIDAS regulation states in Article 5 No.2 :? Without prejudice to the legal effect given to pseudonyms under national law, the use of pseudonyms in electronic transactions shall not be prohibited.? I am not a lawyer, but it seems that this ?must not? might be in conflict with law in Europe.

Best regards
Matthias


Von: Smcwg-public <smcwg-public-bounces at cabforum.org> Im Auftrag von Stephen Davidson via Smcwg-public
Gesendet: Donnerstag, 30. September 2021 22:56
An: smcwg-public at cabforum.org
Betreff: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles

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


______________________________________________________________________________________________________________________
Sitz der Gesellschaft/Headquarter: T?V Informationstechnik GmbH * Am T?V 1 * 45307 Essen, Germany
Registergericht/Register Court: Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 176132277 * Steuer-Nr./Tax No.: 111/57062251
Gesch?ftsf?hrung/Management Board: Dirk Kretzschmar



T?V NORD GROUP
Expertise for your Success


Please visit our website: www.tuv-nord.com<http://www.tuv-nord.com>
Besuchen Sie unseren Internetauftritt: www.tuev-nord.de<http://www.tuev-nord.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211026/444d9625/attachment.html>

From Stephen.Davidson at digicert.com  Tue Oct 26 17:12:33 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Tue, 26 Oct 2021 17:12:33 +0000
Subject: [Smcwg-public] Draft SMCWG agenda - Wednesday, October 27, 2021
Message-ID: <BL1PR14MB5143ECACB0A0ED09F8EA64CAE5849@BL1PR14MB5143.namprd14.prod.outlook.com>


SMCWG Agenda


Draft SMCWG agenda - Wednesday, October 27, 2021 at 11:00 am Eastern Time


Here is a draft agenda for the teleconference described in the subject of this message. Please review and propose changes if necessary.


1.            Roll Call


2.            Read Antitrust / Compliance Statement


3.            Review Agenda


4.            Approval of minutes from teleconference of Oct 14


5.            Discussion
- Continuation of discussion of validity period
- Discussion of version 1.0


6.            Any other business


7.            Next call: Wednesday, November 10, 2021 at 11:00 am Eastern Time


                Adjourn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211026/7a0f87ff/attachment.html>

From Stephen.Davidson at digicert.com  Tue Oct 26 18:11:14 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Tue, 26 Oct 2021 18:11:14 +0000
Subject: [Smcwg-public] Approved Minutes of SMCWG September 29, 2021
Message-ID: <BL1PR14MB5143B404C9FB666B1A7EADF0E5849@BL1PR14MB5143.namprd14.prod.outlook.com>


Minutes of SMCWG


September 29, 2021



These are the Approved Minutes of the Teleconference described in the subject of this message. Corrections and clarifications where needed are encouraged by reply.


Attendees


Ali Gholami (Telia Company), Andrea Holland (SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba  (GlobalSign), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Kemmerer  (SSL.com), Clint Wilson (Apple), Corey Bonnell  (DigiCert), David Kluge (Google), Don Sheehy (WebTrust), Eusebio Herrera (Camerfirma), Inigo Barreira (Sectigo), Joanna Fox (TrustCor), Mads Henriksveen  (BuyPass), Matthias Wiedenhorst (ACAB'c), Mauricio Fernandez (TeleTrust), Miguel Sanchez (Google), Morad Abou Nasser (TeleTrust), Mrugesh Chandarana (IdenTrust), Patrycja Tulinska (PSW), Rebecca Kelley (Apple), Renne Rodriguez (Apple), Sebastian Schulz (GlobalSign), Stefan Selbitschka (rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust Systems), Thomas Connelly (Federal PKI), Tim Crawford (WebTrust), Tsung-Min Kuo  (Chunghwa Telecom), Wendy Brown (Federal PKI)


1. Roll Call


The Roll Call was taken.


2. Read Antitrust Statement


The Antitrust/Compliance Statement was read.


3. Review Agenda


4. Approval of minutes from last teleconference


The minutes of the September 15 teleconference were approved.


5. Discussion


A reminder was made of the informal poll on adoption of ECC. A link has been sent to the Management list, seeking Certificate Issuer feedback by October 8.



The declaration of participation of existing CABF member PrimeKey as an Interested Party member of SMCWG was confirmed.



Ben Wilson discussed the work of the NetSec subcommittee of the Server Cert WG. The NetSec requirements are referred to in several of the existing BRs and are likely to be included in the SMIME BR. Ben is polling feedback from members regarding the possibility of moving NetSec to become a WG in its own right. Stephen Davidson noted that some requirements were originally developed as part of the TLS BR -and lingering references to TLS sometimes complicated their being incorporated by reference in other standards.  He supported the idea of some of these topics being pulled into separate documents.  NetSec is one, audit might be another.  The idea is that some WG would focus on cert types and others on CA topics.  Ben clarified this would be a CABF ballot, requiring a WG charter, but is gaging enthusiasm at this time.



It was decided at the face-to-face that the WG would discuss the validity periods for the SMIME profiles.  Some groups have proposed a default of 398 days, the gmail policy was set at 27 months, and 3 years appears to be the most common validity in use today.  Any member with a position on this topic should contact Stephen, laying out the pros and cons of different proposals.



Discussion turned to the certificate profiles.  Stephen noted that the WG has completed its drafting of the certificate profiles.  He requested that Certificate Issuers to share these with their product and technical teams, as the next step will be to begin transforming these working papers into a draft SMIME BR.



It was noted that the approach to some fields, like OU and Pseudonym may change when we address the verification requirements, however the profiles are now considered stable.



https://docs.google.com/spreadsheets/d/1gEq-o4jU1FWvKBeMoncfmhAUemAgGuvVRSLQb7PedLU/edit#gid=0




6. Any Other Business




None


7. Next call


Next call: CABF Virtual F2F Oct 12-14, detailed agenda to follow


Adjourned




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211026/ff6118af/attachment-0001.html>

From dzacharo at harica.gr  Wed Oct 27 11:37:54 2021
From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA))
Date: Wed, 27 Oct 2021 14:37:54 +0300
Subject: [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
In-Reply-To: <0100017cbb796fce-e5ce5f6d-f3c0-4dd4-b311-db7dbde21ac5-000000@email.amazonses.com>
References: <0100017c387dd56a-790bb90b-4a4f-4636-9f58-0ae6444be1e7-000000@email.amazonses.com>
 <0100017cbb796fce-e5ce5f6d-f3c0-4dd4-b311-db7dbde21ac5-000000@email.amazonses.com>
Message-ID: <2fe37ac4-6ca1-442b-cdb3-fffcfc387c30@harica.gr>


Hi Matthias,

I agree that forbidding "pseudonym" is a conflict with eIDAS and I 
believe the WG might consider lifting this restriction provided we were 
able to document good validation practices to support it.

On a separate matter, S/MIME Certificates do not need to be 
"eIDAS-compatible" but I can relate to TSPs that want to combine 
multiple trust schemes.


Dimitris.



On 26/10/2021 10:21 ?.?., Wiedenhorst, Matthias via Smcwg-public wrote:
>
> Hi Stephen, all,
>
> a few points regarding the profiles from my perspective.
>
> My understanding was that the ?Sponsored Individual? profile was to be 
> a merge of the ?Org-validation? and the ?Personal Individual? 
> profiles. While that is true for the Organization part, it is not for 
> the Individual part. Givenname und Surname are mandatory in the Strict 
> and Multipurpose Personal Individual Profile, but only a ?may? in the 
> Sponsored Individual.
>
> Pseudonym is forbidden (see separate remark below) in Personal 
> Individual, but a ?may? in Sponsored Individual.
>
> Is there any reason for this?
>
> If someone would issue a Sponsored Individual certificate and an 
> Org-validation cert that include only the mandatory DN fields (O, C, 
> orgIdentifier), than this two would be identical in profile.
>
> With regard to pseudonym:
>
> In the ?Personal Individual?-profile the use of ?pseudonym? is 
> declared as ?must not?. However, the European eIDAS regulation states 
> in Article 5 No.2 :?/Without prejudice to the legal effect given to 
> pseudonyms under national law, the use of pseudonyms in electronic 
> transactions shall not be prohibited./? I am not a lawyer, but it 
> seems that this ?must not? might be in conflict with law in Europe.
>
> Best regards
>
> Matthias
>
> *Von:* Smcwg-public <smcwg-public-bounces at cabforum.org> *Im Auftrag 
> von *Stephen Davidson via Smcwg-public
> *Gesendet:* Donnerstag, 30. September 2021 22:56
> *An:* smcwg-public at cabforum.org
> *Betreff:* [Smcwg-public] Stable Draft of S/MIME Certificate Profiles
>
> 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
>
> *______________________________________________________________________________________________________________________* 
> *Sitz der Gesellschaft/Headquarter:* T?V Informationstechnik GmbH * Am 
> T?V 1 * 45307 Essen, Germany *Registergericht/Register Court:* 
> Amtsgericht/Local Court Essen * HRB 11687 * USt.-IdNr./VAT No.: DE 
> 176132277 * Steuer-Nr./Tax No.: 111/57062251 
> *Gesch?ftsf?hrung/Management Board:* Dirk Kretzschmar
>
> *T?V NORD GROUP*
> Expertise for your Success
> *Please visit our website: www.tuv-nord.com <http://www.tuv-nord.com> 
> Besuchen Sie unseren Internetauftritt: www.tuev-nord.de 
> <http://www.tuev-nord.de>*
>
> _______________________________________________
> 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/20211027/32369ff2/attachment.html>

From Stephen.Davidson at digicert.com  Wed Oct 27 18:08:31 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Wed, 27 Oct 2021 18:08:31 +0000
Subject: [Smcwg-public] Informal poll on ECC
Message-ID: <BL1PR14MB51437213DE3691A8F99D07A4E5859@BL1PR14MB5143.namprd14.prod.outlook.com>

*       Only 16 CAs responded to the informal poll regarding the use of ECC.
*       6 of the 16 CAs currently issue end-entity S/MIME certificates containing ECC public keys (although a majority indicated plans to do so).
*       Of those CAs who currently issue ECC S/MIME, the following curves were supported:

   *    6 CAs support ECDSA P-256
   *    5 CAs support ECDSA P-384
   *    3 CAs support ECDSA P-521
   *    Other: 1 CA supports Brainpool

*       No CAs reported current support for the Royal-Holloway key escrow scheme (keyUsages of encipherOnly and decipherOnly).



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211027/8ca74654/attachment.html>

From bwilson at mozilla.com  Wed Oct 27 20:13:48 2021
From: bwilson at mozilla.com (Ben Wilson)
Date: Wed, 27 Oct 2021 14:13:48 -0600
Subject: [Smcwg-public] Informal poll on ECC
In-Reply-To: <0100017cc2f0973d-5583e01b-2036-4b55-8da5-d2104b356843-000000@email.amazonses.com>
References: <0100017cc2f0973d-5583e01b-2036-4b55-8da5-d2104b356843-000000@email.amazonses.com>
Message-ID: <CA+1gtaapQpYXxTD1HgZEGiRTcqEo5n3DymPMg4jYtEyB+GBSsA@mail.gmail.com>

Thanks, Stephen.  I've forwarded this to our Thunderbird team.

On Wed, Oct 27, 2021 at 12:08 PM Stephen Davidson via Smcwg-public <
smcwg-public at cabforum.org> wrote:

>
>    - Only 16 CAs responded to the informal poll regarding the use of ECC.
>    - 6 of the 16 CAs currently issue end-entity S/MIME certificates
>    containing ECC public keys (although a majority indicated plans to do so).
>    - Of those CAs who currently issue ECC S/MIME, the following curves
>    were supported:
>       - 6 CAs support ECDSA P-256
>       - 5 CAs support ECDSA P-384
>       - 3 CAs support ECDSA P-521
>       - Other: 1 CA supports Brainpool
>    - No CAs reported current support for the Royal-Holloway key escrow
>    scheme (keyUsages of encipherOnly and decipherOnly).
>
>
> _______________________________________________
> 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/20211027/d17afe06/attachment.html>

From Stephen.Davidson at digicert.com  Fri Oct 29 19:02:37 2021
From: Stephen.Davidson at digicert.com (Stephen Davidson)
Date: Fri, 29 Oct 2021 19:02:37 +0000
Subject: [Smcwg-public] Cert Consumer guidance on keyUsage
Message-ID: <BL1PR14MB5143FE26132B631A9BE12AB5E5879@BL1PR14MB5143.namprd14.prod.outlook.com>

Hi all:

We've had some useful discussion in the group lately about areas where the S/MIME BR may deviate from existing guidance from root programs or Cert Consumer software.

For example the gmail profile currently stipulates for keyUsage:

Bit positions must be set for either: digitalSignature and/or nonRepudiation/ contentCommitment

Bit positions may be set for: dataEncipherment and/or keyEncipherment

Other bit positions must not be set.

Under this profile, the use of split (separate signing and key management) keys would not be allowed.  Split keys are a common S/MIME deployment.

We'd like to verify the reach of the Cert Consumer profiles where the draft S/MIME BR deviates from existing texts.  We've gone through detailed work to incorporate the existing guidance but, for example, the draft S/MIME BR will allow the use of split keys:

For signing only, bit positions MUST be set for: digitalSignature
Bit positions MAY be set for:nonRepudiation/ contentCommitment

For key management only, bit positions MUST be set for: keyEncipherment
Bit positions MAY be set for: dataEncipherment

For dual use, bit positions MUST be set for: keyEncipherment and digitalSignature
Bit positions MAY be set for: nonRepudiation/contentCommitment and/or dataEncipherment

Other bit positions MUST NOT be set.

Do we have agreement from the Cert Consumers on this approach?

Best regards, Stephen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20211029/b3fef479/attachment.html>