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

Adriano Santoni adriano.santoni at staff.aruba.it
Thu Mar 10 08:47:08 UTC 2022

Okay, I agree that should be worded differently, but you see my point.

Il 10/03/2022 09:37, Pedro FUENTES ha scritto:
> I see a potential issue with the last comment…
> “not declare a policy referring to the CABF requirements” could become 
> in the future a mis issuance if the certificate contains the secure 
> email EKU… as it happens now with the serverAuth EKU and the CABF OIDs 
> for TLS
>> On 10 Mar 2022, at 09:06, Adriano Santoni via Smcwg-public 
>> <smcwg-public at cabforum.org> wrote:
>> 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 oftheSMCWG .
>> 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
>>>             describedhere
>>>             <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 toSection 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://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=ULc5Jdp4kKodPGmf6wR-qODz69T6Jixie11c-lJ0Z8k&s=EMtpfcJxjrDCBAs1tu81rjE1KJNrvIZfY1DaO7B1uUM&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=ULc5Jdp4kKodPGmf6wR-qODz69T6Jixie11c-lJ0Z8k&s=EMtpfcJxjrDCBAs1tu81rjE1KJNrvIZfY1DaO7B1uUM&e=>
> *
> WISeKey SA
> *
> *Pedro Fuentes
> *CSO - Trust Services Manager
> Office: + 41 (0) 22 594 30 00
> Mobile: + 41 (0) 791 274 790
> Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland
> *Stay connected with WISeKey <http://www.wisekey.com>
> *
> *THIS IS A TRUSTED MAIL*: This message is digitally signed with a 
> WISeKey identity. If you get a mail from WISeKey please check 
> the signature to avoid security risks
> *CONFIDENTIALITY: *This email and any files transmitted with it can be 
> confidential and it’s intended solely for the use of the individual or 
> entity to which they are addressed. If you are not the named addressee 
> you should not disseminate, distribute or copy this e-mail. If 
> you have received this email in error please notify the sender
> *DISCLAIMER: *WISeKey does not warrant the accuracy or completeness of 
> this message and does not accept any liability for any errors or 
> omissions herein as this message has been transmitted over a public 
> network. Internet communications cannot be guaranteed to be secure or 
> error-free as information may be intercepted, corrupted, or contain 
> viruses. Attachments to this e-mail are checked for viruses; 
> however, we do not accept any liability for any damage sustained by 
> viruses and therefore you are kindly requested to check for viruses 
> upon receipt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/7579c370/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/7579c370/attachment-0001.p7s>

More information about the Smcwg-public mailing list