[Smcwg-public] [EXTERNAL]-Re: Common Name contents
Adriano Santoni
adriano.santoni at staff.aruba.it
Thu Mar 10 13:51:54 UTC 2022
+1
Il 10/03/2022 14:16, Pedro FUENTES via Smcwg-public ha scritto:
> While I still think that we should have available placeholders to put
> “free” information that can be safely ignored by the relying parties,
> I consider that in particular the CN is not such an adequate
> placeholder, because this is the most visible field (i.e. what most
> email clients will show as the signer of a message), and therefore we
> are opening the door to phishing or MITM issues.
>
> P
>
>> On 10 Mar 2022, at 13:22, Doug Beattie via Smcwg-public
>> <smcwg-public at cabforum.org> wrote:
>>
>> *From:*Smcwg-public <smcwg-public-bounces at cabforum.org>*On Behalf
>> Of*Dimitris Zacharopoulos (HARICA) via Smcwg-public
>> *Sent:*Thursday, March 10, 2022 6:46 AM
>> *To:*Henschel, Andreas <a.henschel at d-trust.net>; SMIME Certificate
>> Working Group <smcwg-public at cabforum.org>
>> *Subject:*Re: [Smcwg-public] [EXTERNAL]-Re: Common Name contents
>>
>> On 10/3/2022 1:34 μ.μ., Henschel, Andreas wrote:
>>
>> Hey Dimitris,
>> in a first step, pseudonyms could be allowed in sponsored
>> profiles. From an external point of view, those entities have the
>> same accepted validation level as certificates with an
>> organisation profile as the organisation is properly validated
>> anyway.
>>
>>
>> Hi Andreas,
>>
>> Why should they be allowed if we cannot describe the rules for it? Do
>> you believe it is ok to have a sponsored profile that allows a
>> natural person associated with a company to use any value in the
>> subjectDN of the certificate? I believe the risks for allowing such a
>> practice are not acceptable.
>> Values in surname and givenname must be validated, yes, but let’s
>> continue to permit the enterprise RA to specify the CN, OU
>> andPseudonym like we do today. Focus on email validation rules and
>> limit the subject DN validation to C, S, L and O. If there are
>> usecases that demand more, then let’s let them define those rules and
>> policy OIDs to be used in the certificates on top of the profiles
>> we’re defining here.
>>
>>
>> Best regards,
>> Dimitris.
>>
>> Kind regards,
>> Andreas
>> *Von:*Smcwg-public<smcwg-public-bounces at cabforum.org>
>> <mailto:smcwg-public-bounces at cabforum.org>*Im Auftrag
>> von*Dimitris Zacharopoulos (HARICA) via Smcwg-public
>> *Gesendet:*Donnerstag, 10. März 2022 12:25
>> *An:*Juan Ángel Martín<martin_ja at camerfirma.com>
>> <mailto:martin_ja at camerfirma.com>; SMIME Certificate Working
>> Group<smcwg-public at cabforum.org> <mailto:smcwg-public at cabforum.org>
>> *Betreff:*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
>> 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=JaIplWyETjJd_oEwxnhfHcbbS0ufTY3HiF_OODBFgHM&s=FMDlYi95pwd2P5C2LcCsctga9934yXeALSAGwj0OwPY&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=JaIplWyETjJd_oEwxnhfHcbbS0ufTY3HiF_OODBFgHM&s=FMDlYi95pwd2P5C2LcCsctga9934yXeALSAGwj0OwPY&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.
>
>
> _______________________________________________
> 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/836e0b45/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/836e0b45/attachment-0001.p7s>
More information about the Smcwg-public
mailing list