[Smcwg-public] [EXTERNAL]-Re: Common Name contents

Seo Suchan tjtncks at gmail.com
Thu Mar 10 10:08:17 UTC 2022

while I'm not a a member of this group, how about some stanard-hashed 
version of real id? CN = sha256(real name+salt) ?
it still can't be verifyed by outsider without knowing real id, and it's 
trivial to copy entire CN but if we trust CA then we can sat a same name 
means the same person?
2022-03-10 오후 6:39에 Dimitris Zacharopoulos (HARICA) via Smcwg-public 
이(가) 쓴 글:
> Matthias,
> This is indeed a legal requirement in eIDAS and we need to see its 
> applicability for S/MIME certificates.
> The problem we need to address is the fact that I can validate myself 
> to a CA with my physical presence and my official name (Dimitrios 
> Zacharopoulos), and ask for a Pseudonym to be included in the 
> certificate, but the process is unclear. Here are some 
> questions/concerns (not addressed explicitly to Matthias, anyone can 
> chime-in):
>   * Could I ask that my pseudonym is "Matthias Wiedenhorst" or "Mickey
>     Mouse"? How is THAT information validated so that it is not
>     misleading to Relying Parties?
>   * Can the pseudonym be a name/value that the CA decides, e.g.
>     "Pseudonym-482733812"? How is that helpful for Relying Parties?
>   * Can a Relying Party ask the CA to reveal the real identity of the
>     person behind the pseudonym? If this is the case, how is this
>     protecting the real person for being in danger?
> Thanks,
> Dimitris.
> On 10/3/2022 9:05 π.μ., Wiedenhorst, Matthias via Smcwg-public wrote:
>> Hi all!
>> Article 5 (2) eIDAS reads:
>> /“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 to me it sounds as if prohibiting pseudonyms 
>> could cause problems within the EU.
>> Legitimate use cases that I have heard of from different CAs are for 
>> example persons from the “law enforcement area” that are in danger to 
>> be threatened or even attacked in their private live when their full 
>> real name is known.
>> As already pointed out, a pseudonym certificate is not an anonymous 
>> certificate, but only the CA is able to reveal identity. 
>> Identification of the person has to be performed identically as if a 
>> certificate without pseudonym would be issued.
>> Best regards
>> Matthias
>> *Von:* Smcwg-public <smcwg-public-bounces at cabforum.org> *Im Auftrag 
>> von *Stephen Davidson via Smcwg-public
>> *Gesendet:* Mittwoch, 9. März 2022 15:34
>> *An:* Pedro FUENTES <pfuentes at WISEKEY.COM>; SMIME Certificate Working 
>> Group <smcwg-public at cabforum.org>; Dimitris Zacharopoulos (HARICA) 
>> <dzacharo at harica.gr>
>> *Betreff:* Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents
>> In general, the CA is supposed to validate the true identity of a 
>> holder behind a subject:pseudonym.  This is different from an 
>> anonymous cert.
>> The difficulty we face is that, having chosen to require Subject 
>> identity information to be verified, it would be inconsistent to 
>> allow the freeform use of pseudonyms.
>> As far as I know, only Germany provides the options for alternative 
>> “religious names or pseudonyms” on their national ID: 
>> https://www.consilium.europa.eu/prado/en/DEU-BO-02004/image-344552.html 
>> ... So that significantly narrows the options for verifying pseudonyms!
>> My personal belief is that we should drop the use of pseudonyms from 
>> this draft.  I hope that SMCWG members that disagree with this will 
>> speak up.
>> The Mailbox-validated (MV) profiles are probably more appropriate for 
>> users not wishing “real name” identity to be in their certs.
>> Regards, Stephen
>> *From:*Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf Of 
>> *Pedro FUENTES via Smcwg-public
>> *Sent:* Monday, March 7, 2022 2:35 PM
>> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; SMIME 
>> Certificate Working Group <smcwg-public at cabforum.org>
>> *Subject:* Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents
>> Could it be just acceptable that a pseudonym is freely chosen by a 
>> subscriber?
>> In other words… could it be acceptable to have names in the 
>> subjectName which don’t require validation?
>> We don’t currently use such attributes, but I wonder if this could be 
>> good to reserve certain flexibility for use cases where anonymization 
>> is desired.
>> Pedro
>>     Le 7 mars 2022 à 18:58, Dimitris Zacharopoulos (HARICA) via
>>     Smcwg-public <smcwg-public at cabforum.org> a écrit :
>>      Unless CAs have some clear rules on how to validate pseudonyms,
>>     I also believe we should exclude this attribute from the allowed
>>     profiles which makes this attribute practically not allowed. We
>>     must be explicit about this because other attributes may be allowed.
>>     Dimitris.
>>     On 7/3/2022 9:41 π.μ., Adriano Santoni via Smcwg-public wrote:
>>         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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_smime_blob_preSBR_SBR.md-2371422-2Dsubject-2Ddistinguished-2Dname-2Dfields&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=SikwTyV2nbwaM8CjAAm0ewzVcCUuXH_rrJl0zlNlYwQ&e=>.
>>             *_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>
>>             <mailto:doug.beattie at globalsign.com>
>>             *Sent:* Wednesday, March 2, 2022 1:10 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:* 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|(
>>             *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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cabforum_smime_blob_preSBR_SBR.md-23323-2Dauthentication-2Dof-2Dindividual-2Didentity&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=nliz6I7gIbr8WMy3LZQ94CqxFqzTqVpunO8t0YqxuCo&e=>.
>>             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
>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=M6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg&e=>
>>         _______________________________________________
>>         Smcwg-public mailing list
>>         Smcwg-public at cabforum.org
>>         https://lists.cabforum.org/mailman/listinfo/smcwg-public
>>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwMDaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=M6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg&e=>
>>     _______________________________________________
>>     Smcwg-public mailing list
>>     Smcwg-public at cabforum.org
>>     https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=M6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg&e=
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic&d=DwICAg&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY&m=NCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q&s=M6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg&e=>
>> *______________________________________________________________________________________________________________________* 
>> *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
>> 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
> _______________________________________________
> 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/20220310/ee2540e8/attachment-0001.html>

More information about the Smcwg-public mailing list