[cabfpub] givenName and surname revived

Mon Aug 22 22:15:35 UTC 2016

What do you mean by definition? I consider IV v. OV well defined because of
the meaning associated with the OID inserted into the cert. Section 7.1.6.1
states “ {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐
browser‐forum(140) certificate‐policies(1) baseline‐requirements(2)
individual‐validated(3)} (2.23.140.1.2.3), if the Certificate complies with
these Requirements and includes Subject Identity Information that is
verified in accordance with Section 3.2.3.” Section 3.2.3 is verification
of an individual whereas Section 3.2.2 is verification of an organization.

Jeremy

From: Bruce Morton [mailto:Bruce.Morton at entrust.com]
Sent: Monday, August 22, 2016 6:11 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com>; public at cabforum.org
Subject: RE: givenName and surname revived

Hi Jeremy,

My apologies, but can you clarify the section where IV certs are well
defined? I see that “individual-validated” is stated twice in sections 1.2
and 7.1.6.1 (the same for domain-validated and organization-validated), but
I can’t find the definition.

Thanks, Bruce.

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
Sent: Saturday, August 20, 2016 10:41 AM
To: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com>
>; public at cabforum.org <mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

Hey Bruce - IV certs are well defined. The goal of the ballot isn’t to
further define IV certs but to permit use of the givenName and surname
fields for IV certs. giveName and surname in the org field would be allowed.
They’d still use the IV OIDs as they were validated under the IV section of
the CP.

From: Bruce Morton [mailto:Bruce.Morton at entrust.com]
Sent: Friday, August 19, 2016 6:41 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com
<mailto:jeremy.rowley at digicert.com> >; public at cabforum.org
<mailto:public at cabforum.org>
Subject: RE: givenName and surname revived

Hi Jeremy,

Would like some clarification. On the call yesterday, it was said that IV
certificates were not defined, so this ballot will help resolve this.

Per 7.1.4.2.2 b, the current BRs allow givenName and surname to be included
in the organizationName field. Will this still be allowed? If so, what would
the certificate type be? OV or IV? I would prefer that these be OV
certificates.

If we do make the changes and the CAs have to meet Microsoft’s requirement
to put a DV, OV, or IV certificate policy in the certificate, I think we
should clearly define each certificate type.

Also, the stateOrProvinceName field appears to currently have an issue as it
does not have any language to address the case where there is no state or
province in the address.

Thanks, Bruce.

From: public-bounces at cabforum.org <mailto:public-bounces at cabforum.org>
[mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Thursday, August 18, 2016 12:09 PM
To: public at cabforum.org <mailto:public at cabforum.org>
Subject: [cabfpub] givenName and surname revived

Looking for two endorsers for the following revisions the baseline
requirements adding support for givenName and surname:

Insert a new (C) under 7.1.4.2.2, renumbering all subsequent bullets.

c. Certificate Field: subject:givenName (2.5.4.42) and subject:surname (2.5.
4.4)

Optional.

Contents:  If present, the subject:givenName field and subject:surname field
MUST contain an natural person Subject’s name as verified under Section
3.2.3. A Certificate containing a subject:givenName field or subject:surname
field MUST contain the (2.23.140.1.2.3) Certificate Policy OID.

d. Certificate Field: Number and street: subject:streetAddress (OID:
2.5.4.9)

    Optional if the subject:organizationName field, subject: givenName
field, or subject:surname field are is present. Prohibited if the
subject:organizationName field, subject:givenName, and subject:surname field
are is absent.

   Contents: If present, the subject:streetAddress field MUST contain the
Subject’s street address information as verified under Section 3.2.2.1.

e. Certificate Field: subject:localityName (OID: 2.5.4.7)

Required if the subject:organizationName field, subject:givenName field, or
subject:surname field are is present and the subject:stateOrProvinceName
field is absent. Optional if the subject:stateOrProvinceName field and the
subject:organizationName field, subject:givenName field, or subject:surname
field are present. Prohibited if the subject:organizationName field,
subject:givenName, and subject:surname field are is absent.

Contents: If present, the subject:localityName field MUST contain the
Subject’s locality information as verified under Section 3.2.2.1. If the
subject:countryName field specifies the ISO 3166‐1 user‐assigned code of
XX in accordance with Section 7.1.4.2.2(g), the localityName field MAY
contain the Subject’s locality and/or state or province information as
verified under Section 3.2.2.1.

f. Certificate Field: subject:stateOrProvinceName (OID: 2.5.4.8)

Required if the subject:organizationName field field, subject:givenName
field, or subject:surname field are is present and the subject:localityName
field is absent. Optional if the subject:localityName field and the subject:
organizationName field, the subject:givenName field, or subject:surname
field are present. Prohibited if the subject:organizationName field,
subject:givenName field , or subject:surname field are is absent. Contents:
If present, the subject:stateOrProvinceName field MUST contain the Subject’
s state or province information as verified under Section 3.2.2.1. If the
subject:countryName field specifies the ISO 3166‐1 user‐assigned code of
XX in accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName
field MAY contain the full name of the Subject’s country information as
verified under Section 3.2.2.1.

g. Certificate Field: subject:postalCode (OID: 2.5.4.17)

Optional if the subject:organizationName, subject:givenName field, or
subject:surname fields are is present. Prohibited if the
subject:organizationName field, subject:givenName field, or subject:surname
field are is absent.

Contents: If present, the subject:postalCode field MUST contain the
Subject’s zip or postal information as verified under Section 3.2.2.1.

h. Certificate Field: subject:countryName (OID: 2.5.4.6)

Required if the subject:organizationName field, subject:givenName , or
subject:surname field is present. Optional if the subject:organizationName
field, subject:givenName field, and  subject:surname field are is absent.

Contents: If the subject:organizationName field is present, the
subject:countryName MUST contain the two‐letter ISO 3166‐1 country code
associated with the location of the Subject verified under Section 3.2.2.1.
If the subject:organizationName, subject:givenName field, and
subject:surname  field are  is absent, the subject:countryName field MAY
contain the two‐letter ISO 3166‐1 country code associated with the Subject
as verified in accordance with Section 3.2.2.3. If a Country is not
represented by an official ISO 3166‐1 country code, the CA MAY specify the
ISO 3166‐1 user‐assigned code of XX indicating that an official ISO 3166‐
1 alpha‐2 code has not been assigned.

i. Certificate Field: subject:organizationalUnitName

Optional.

Contents: The CA SHALL implement a process that prevents an OU attribute
from including a name, DBA, tradename, trademark, address, location, or
other text that refers to a specific natural person or Legal Entity unless
the CA has verified this information in accordance with Section 3.2 and the
Certificate also contains subject:organizationName, subject:givenName,
subject:surname, subject:localityName, and subject:countryName attributes,
also verified in accordance with Section 3.2.2.1.

7.1.6.1

…

If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it
MUST NOT include organizationName, givenName, surname, streetAddress,
localityName, stateOrProvinceName, or postalCode in the Subject field.

…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160822/4b119214/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160822/4b119214/attachment-0001.p7s>