[Smcwg-public] [EXTERNAL]-Re: Common Name contents
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Mar 11 09:05:36 UTC 2022
This is very useful, thank you!
So, a Relying Party mainly relies on the organizationName information,
the Pseudonym is generated by the CA as a unique identifier
("pseudonymization" as described by GDPR) but the CA cannot reveal the
real person's identity to the Relying Party. Only proper judicial
authorities may request the link between the pseudonym and the real
identity.
I think this sounds fair and poses no risk to Relying Parties. However,
it must be clear in the policy that this is some sort of an
"Organization Validated" Certificate.
Dimitris.
On 11/3/2022 10:54 π.μ., Juan Ángel Martín wrote:
>
> Thank you Dimitris,
>
> You can incorporate into that pseudonym field something similar to
> what you include in your second bullet.
>
> This pseudonym must be created by the CA, in no case by the
> certificate holder.
>
> Let's bear in mind that the certificate shows the organization to
> which the certificate holder is affiliated.
>
> This organization is something that the relying party must know since
> it is the Police Department and the certificate incorporates the
> verified data of this organization.
>
> This organization's data is public as it appears in the country's
> official registers (in this case Spain) and the relying party can
> check it in these registers cause they are public.
>
> I think the differentiating factor is that the organization, to which
> the certificate holder is affiliated, is listed in the official
> registers as being run by the country's government.
>
> And in case of a judicial requirement is when the CA provides the
> judge with the name and surname of the natural person behind the
> pseudonym.
>
> Best regards
>
> Juan Ángel
>
> *De:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Enviado el:* jueves, 10 de marzo de 2022 12:25
> *Para:* Juan Ángel Martín <martin_ja at camerfirma.com>; SMIME
> Certificate Working Group <smcwg-public at cabforum.org>
> *Asunto:* 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/20220311/429b53c2/attachment-0001.html>
More information about the Smcwg-public
mailing list