[Smcwg-public] [EXTERNAL]-Re: Common Name contents
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu Mar 10 08:06:35 UTC 2022
But here we are developing an /industry/ standard that - as such - need
not be eIDAS-compliant.
Besides, Article 5 (2) of eIDAS refers to transactions, not certificates.
In fact, eIDAS mention pseudonyms only with reference to /qualified/
electronic signature certificates, which are not the subject of the SMCWG .
Some CA may also want to issue S/MIME certificates containing
pseudonyms, and be succesfully audited against eIDAS and the relevant
ETSI norms, but in such a case they should not declare a policy
referring to the CABF requirements we are developing here.
Adriano
Il 10/03/2022 08:05, Wiedenhorst, Matthias via Smcwg-public ha scritto:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/435366eb/attachment-0001.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/20220310/435366eb/attachment-0001.p7s>
More information about the Smcwg-public
mailing list