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

Mon Mar 7 18:46:48 UTC 2022

I would still like to see the OU allowed when it can be verified - for
example when the O by itself is just too broad like in the case of O=US
Government and there is a published list of departments & agencies within
the US Federal government.

And I agree with Doug's earlier email about permitting the enterprise RA to
supply the name details.

thanks,

Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

wendy.brown at gsa.gov
wendy.brown at protiviti.com

On Mon, Mar 7, 2022 at 1:41 PM Martijn Katerbarg via Smcwg-public <
smcwg-public at cabforum.org> wrote:

> While I see the advantage for some in that, is this not exactly why we’re
> banning the OU field in both S/MIME and SSL?
>
>
>
> It opens up for Pseudonym becoming the new OU field.
>
>
>
> Martijn
>
>
>
> *From:* Smcwg-public <smcwg-public-bounces at cabforum.org> *On Behalf Of *Pedro
> FUENTES via Smcwg-public
> *Sent:* Monday, 7 March 2022 19:35
> *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
>
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_cabforum_smime_blob_preSBR_SBR.md-2371422-2Dsubject-2Ddistinguished-2Dname-2Dfields%26d%3DDwMDaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DNCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q%26s%3DSikwTyV2nbwaM8CjAAm0ewzVcCUuXH_rrJl0zlNlYwQ%26e%3D&data=04%7C01%7Cmartijn.katerbarg%40sectigo.com%7C32c6d640337442e8798808da00692fcd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637822750367336498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TFrRek26xNPjTJcniTuIcIURYUDC3o0H6YzdcXu2hS4%3D&reserved=0>
> .
>
>
>
> *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>
> <doug.beattie at globalsign.com>
> *Sent:* Wednesday, March 2, 2022 1:10 PM
> *To:* Stephen Davidson <Stephen.Davidson at digicert.com>
> <Stephen.Davidson at digicert.com>; SMIME Certificate Working Group
> <smcwg-public at cabforum.org> <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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_cabforum_smime_blob_preSBR_SBR.md-23323-2Dauthentication-2Dof-2Dindividual-2Didentity%26d%3DDwMDaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DNCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q%26s%3Dnliz6I7gIbr8WMy3LZQ94CqxFqzTqVpunO8t0YqxuCo%26e%3D&data=04%7C01%7Cmartijn.katerbarg%40sectigo.com%7C32c6d640337442e8798808da00692fcd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637822750367336498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t2hI0Z4izKBpGKLS8RLmCK7LbKep7Qwy8qIpj8bQcWw%3D&reserved=0>
> .
>
>
>
> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic%26d%3DDwMDaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DNCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q%26s%3DM6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg%26e%3D&data=04%7C01%7Cmartijn.katerbarg%40sectigo.com%7C32c6d640337442e8798808da00692fcd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637822750367336498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X%2FG7MmUwwnyiOHHN5Kq02YX9BPNz3mS0m9CJuyNukFw%3D&reserved=0>
>
>
>
> _______________________________________________
>
> Smcwg-public mailing list
>
> Smcwg-public at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/smcwg-public <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.cabforum.org_mailman_listinfo_smcwg-2Dpublic%26d%3DDwMDaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DNCuXVva5JxiZue0JFxEbVTEZS67ltuKPjLakEuBlN-Q%26s%3DM6K8kM_fZBp_w11MPEbpQzwTErczaQV8-qlOhtEiIMg%26e%3D&data=04%7C01%7Cmartijn.katerbarg%40sectigo.com%7C32c6d640337442e8798808da00692fcd%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637822750367336498%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X%2FG7MmUwwnyiOHHN5Kq02YX9BPNz3mS0m9CJuyNukFw%3D&reserved=0>
>
>
> _______________________________________________
> 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=
>
> _______________________________________________
> 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/20220307/61ea17eb/attachment-0001.html>