[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|(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://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
>>
>> *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
>
>
> _______________________________________________
> 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