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

Wed Oct 27 11:37:54 UTC 2021

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>