[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|(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
>>>
>>> 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
>> _______________________________________________
>> 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