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

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Thu Mar 10 11:45:50 UTC 2022



On 10/3/2022 1:34 μ.μ., Henschel, Andreas wrote:
>
> Hey Dimitris,
>
> in a first step, pseudonyms could be allowed in sponsored profiles. 
> From an external point of view, those entities have the same accepted 
> validation level as certificates with an organisation profile as the 
> organisation is properly validated anyway.
>

Hi Andreas,

Why should they be allowed if we cannot describe the rules for it? Do 
you believe it is ok to have a sponsored profile that allows a natural 
person associated with a company to use any value in the subjectDN of 
the certificate? I believe the risks for allowing such a practice are 
not acceptable.


Best regards,
Dimitris.
>
> Kind regards,
>
> Andreas
>
> *Von:* Smcwg-public <smcwg-public-bounces at cabforum.org> *Im Auftrag 
> von *Dimitris Zacharopoulos (HARICA) via Smcwg-public
> *Gesendet:* Donnerstag, 10. März 2022 12:25
> *An:* Juan Ángel Martín <martin_ja at camerfirma.com>; SMIME Certificate 
> Working Group <smcwg-public at cabforum.org>
> *Betreff:* Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents
>
> On 10/3/2022 1:14 μ.μ., Juan Ángel Martín wrote:
>
>     Dimitris,
>
>     One use case of pseudonyms that I know of is the need for the
>     police to sign certain messages, e.g. traffic tickets, with a
>     qualified eIDAS certificate.
>
>     But the police officers do not want their name, surname and
>     personal identification document number to appear on the
>     certificate, which signs the traffic ticket for unavoidable legal
>     reasons in Europe.
>
>     I think it would be desirable to give an answer to this need in
>     the CABF requirements for SMIME certificates.
>
>
> Thank you Juan Ángel,
>
> We all agree with the end goal but we can't address the concerns 
> without answering some questions regarding the validation process. For 
> example, what do those traffic tickets look like in terms of the 
> signer? Does it only have a random identifier as described in the 2nd 
> bullet of my previous letter? Does it say something like "Officer 
> John"? It is important to get some transparency on this so the SMCWG 
> can develop validation rules that would support this feature.
>
>
> Best regards,
> Dimitris.
>
>
>     Thanks,
>
>     Juan Ángel
>
>     *De:* Smcwg-public <smcwg-public-bounces at cabforum.org>
>     <mailto:smcwg-public-bounces at cabforum.org> *En nombre de *Dimitris
>     Zacharopoulos (HARICA) via Smcwg-public
>     *Enviado el:* jueves, 10 de marzo de 2022 10:40
>     *Para:* Wiedenhorst, Matthias <M.Wiedenhorst at tuvit.de>
>     <mailto:M.Wiedenhorst at tuvit.de>; SMIME Certificate Working Group
>     <smcwg-public at cabforum.org> <mailto:smcwg-public at cabforum.org>
>     *Asunto:* Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents
>
>     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):
>
>      1. 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?
>      2. Can the pseudonym be a name/value that the CA decides, e.g.
>         "Pseudonym-482733812"? How is that helpful for Relying Parties?
>      3. 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>
>         <mailto: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>
>         <mailto:pfuentes at WISEKEY.COM>; SMIME Certificate Working Group
>         <smcwg-public at cabforum.org>
>         <mailto:smcwg-public at cabforum.org>; Dimitris Zacharopoulos
>         (HARICA) <dzacharo at harica.gr> <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/82999005/attachment-0001.html>


More information about the Smcwg-public mailing list