[Smcwg-public] Common Name contents

[Adriano Santoni]

We do not support pseudonyms, and do not think there is a need for them.

> ...we could even chose to exclude this attribute from the allowed profiles

Yes, that's what we suggest to do: exclude this attribute from the 
allowed profiles.

Adriano


Il 02/03/2022 18:43, Stephen Davidson via Smcwg-public ha scritto:
>
> Hi Doug:
>
> 1. Further to our discussion today, the language in ETSI EN 319 412-2 
> probably has the clearest definition:
>
> The commonName attribute value shall contain a name of the subject. 
> This may be in the subject's preferred presentation format, or a 
> format preferred by the CA, or some other format. Pseudonyms, 
> nicknames, and names with spelling other than defined by the 
> registered name may be used.
>
> NOTE 1: The commonName attribute has a usage purpose that is different 
> from the required choice of pseudonym or givenName/surname. commonName 
> is used for user friendly representation of the person's name, whereas 
> givenName/surname is used where more formal representation or 
> verification of specific identity of the user is required. To maximize 
> interoperability both are considered necessary.
>
> It does not give guidance on the scope for “user friendly 
> representation of the person's name” and as far as I can tell, most 
> TSPs apply either (givenName and surname) or pseudonym in that field.
>
> Notwithstanding this, our previous discussions had been for the 
> commonName to include verified information for the purposes of the 
> S/MIME BR, leading to the options described here 
> <https://github.com/cabforum/smime/blob/preSBR/SBR.md#71422-subject-distinguished-name-fields>.
>
> *_We are interested in hearing perspectives from both Certificate 
> Issuers and Certificate Issuers on this point._*
>
> 2.  The handling of subject:pseudonym is still an unresolved issue – 
> and so text still needs to be tightened up. We are working from the 
> basis that Subject information must be verified, so this would also 
> apply to pseudonym (ie not a self reported name). Pseudonym identity 
> is, by definition, linked to the person’s real identity
>
> ETSI TS 199 461 tries to deal with it by saying:
>
> Although the outcome of the identity proofing can be a pseudonym 
> identity, identity proofing requires identification of the real 
> identity of the person as determined by applicable identity documents, 
> official registers or other authoritative sources.
>
> But as far as I can tell, only Germany provides pseudonym as an 
> information attribute on official identity documents.  Given the lack 
> of clarity, we could even chose to exclude this attribute from the 
> allowed profiles.
>
> *_We’d be interested to hear from Certificate Issuers _ **_what their 
> practices are using the pseudonym in regulated certificate types._*
>
> Best, Stephen
>
> Stephen Davidson
>
> DigiCert Governance, Risk & Compliance
> stephen.davidson at digicert.com
>
> O 1.441.278.2803 | M 1.441.505.4908
>
> ||
>
> *From:* Doug Beattie <doug.beattie at globalsign.com>
> *Sent:* Wednesday, March 2, 2022 1:10 PM
> *To:* Stephen Davidson <Stephen.Davidson at digicert.com>; SMIME 
> Certificate Working Group <smcwg-public at cabforum.org>
> *Subject:* Common Name contents
>
> Hey Stephen,
>
> During the call today it was mentioned that all of the subject info 
> pulled from the certificates and displayed via GUI needs to be 
> validated (no more OU logic). I went back and looked at the options 
> for Sponsor validated certs and it permits the Pseudonym to be present 
> in the CN.
>
> I went to check the rules for validation and found this:
>
> f. *Certificate Field:* |subject:pseudonym| (2.5.4.65)
> *Contents:* The pseudonym attribute MUST NOT be present if the 
> givenName and/or surname attribute are present. If present, the 
> |subject:pseudonym| field field MUST be verified according to Section 
> 3.2.3 
> <https://github.com/cabforum/smime/blob/preSBR/SBR.md#323-authentication-of-individual-identity>.
>
> But I could not find any references to this field in that section, or 
> section 3.2.4 that indicates how this is to be validated.  Are there 
> CA validation rules for this, or can any value be supplied?
>
> Doug
>
>
> _______________________________________________
> 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/20220307/740c7d5e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220307/740c7d5e/attachment.p7s>