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

Thu Mar 10 08:37:09 UTC 2022

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 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> <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 <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 <mailto: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 <mailto:dzacharo at harica.gr>>; SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto: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 <mailto: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 <mailto: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 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 <mailto: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 <mailto: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 <mailto: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 <mailto:Smcwg-public at cabforum.org>
>> https://lists.cabforum.org/mailman/listinfo/smcwg-public <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
> _______________________________________________
> Smcwg-public mailing list
> Smcwg-public at cabforum.org <mailto: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/904c8774/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3398 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220310/904c8774/attachment-0001.p7s>