[cabf_validation] Minutes of the Validation subcommittee call on 2020-09-10

[Doug Beattie]

Minutes of the Validation Subcommittee call on 2020-09-10

 

Antitrust statement was read.

 

 

Present

*	Wayne Thayer (Mozilla)  (Leading)
*	Andrea Holland (SecureTrust)
*	Andreas Hentschel (D-TRUST)
*	Ben Wilson (Mozilla)
*	Bruce Morton (Entrust Datacard)
*	Clint Wilson (Apple)
*	Corey Bonnell (SecureTrust)
*	Daniela Hood (GoDaddy)
*	Dean Coclin (Digicert)
*	Dimitris Zacharopoulos (HARICA)
*	Doug Beattie (GlobalSign)
*	Janet Hines (SecureTrust)
*	Johnny Reading
*	Li-Chun Chen
*	Rich Smith
*	Ryan Sleevi (Google)
*	Shelley Brewer (DigiCert)
*	Trevoli Ponds-White (Amazon)
*	Wendy Brown (US Federal PKI Management Authority)

This week we focused on defining some of the attributes in the TLS
Distinguished Names tab of the Profile spreadsheet.  We reviewed Country,
stateOrProvinceName , localityName and StreetAddress.  The goal of this
exercise is to simplify the current wording which combines validation with
the required/optional logic and that makes for difficult reading.  If we
separate the use of the field from the validation, we have an easier to
ready specification.

 

We also discussed the possibility of profiling the SubjectDN per product
(DV, OV, IV, EV)  to simplify things, but that will be addressed during a
future meeting

 

 

Country:

 

Country is required if the subject: organizationName is present and Optional
if the subject: organizationName is not present.  The only case of a Country
when organizationName is not present is DV, and there are rules for how that
is validated in the BRs.  

 

We agreed that we should re-look at changing this requirement to only
include Country when organizationName exists.

 

Ryan raised the point that if we remove country from DV as a supported
field, and with CommonName being deprecated, the SubjectDN could be blank.
That's a discussion for another day, but something we need to revisit. 

 

 

stateOrProvinceName:

 

The rules for State are more complex and the current specification is
confusing to read.  We unwound the current spec into these 4 cases:

 

1) Required when organizationName, givenName, or surName is present and
localityName is absent
2) Optional when organizationName, givenName, or surName is present and
localityName is present
3) Prohibited when organizationName, givenName, and surName are absent
4) Optional if countryName = XX

 

The strict reading of #2 means that the inclusion of state is optional when
you include the locality, even if there is a defined state for that
locality.  This was probably not the intended interpretation and that the
intent was probably that you MUST include the state when a state exists for
the specified locality (which is better defined in the EVGL).  This
clarification is something to be considered in future updates, but for now
the specification will remain unchanged.

 

Ryan and Rich discussed what goes into the state field as this gets
complicated when country=xx, so the validation rules for the content need
make a conditional statement around the value of country.  As it stands,
when country=XX, the CA may include either the State, or <instead> the full
spelling of the Country (where MAY should mean you MUST include one or the
other; but that is not clear from the current spec and there was a
suggestion to put in "instead" which helps in this regard).  This further
ripples into the Locality where the Locality may contain the value of the
State (instead of the locality) when the Country=XX, and State contains
Country.  Ryan said that we might have been better off defining a new field
to put the country name when country-xx instead of pushing the values down a
level as is currently specified.

 

Rich also suggested a future update that we don't ripple down the content
and when country = XX the state field includes both the country and state,
the we leave locality untouched.

 

 

Locality

 

We had a discussion similar to the State discussion above and also ended up
with 4 specific statements about when it's required and optional:

 

1) Required when organizationName, givenName, or surName is present and
stateOrProvinceName is absent
2) Optional when organizationName, givenName, or surName is present and
stateOrProvinceName is present
3) Prohibited when organizationName, givenName, and surName are absent
4) Optional if countryName = XX

 

Currently locality is optional when you have state (even if locality exists
for the region). Like the State discussion above, this probably was not the
intent and is something we should fix.

 

For regions like Singapore or Vatican City  that do not have either a state
or locality, we discussed  putting country in for locality.  This means we
could make locality required.  Twain has a different allocating of regions
and does not follow the traditional State and locality construct.  Rich
recommended that we should require Locality in all cases, and when there is
no real locality, we should specify the Country in the locality field (the
locality is the country in this case).

 

Again any changes to the rules will be applied in a future update once the
profiles for the current version of the BRs is created. 

 

 

StreetAddress

 

Wayne brought up the topic of needing multiple street addresses (street
address 1, street address 2)

*	Rich said that they may include multiple lines of street addresses
*	Since streetAddress is in a "set" construct where order is not
specified, how do you specify the order of the fields to map to street
address 1 and street address 2?
*	The max length for street is 30 characters which may not be enough
to put 2 street address lines into one field
*	In Japan, the order of the address fields is based on the name form
(Romanized or naturalized Japanize form) where the order is reversed.

Ryan asked how we address this in general? If you get geo IP address for 4
countries.  Do you want to add multiple country fields?

*	His view is that we should have only one instance of each field (one
country, one street address, etc.)

Dimitris said ETSI permits multiple instances of given name and surname
because people may have 2 names

 

Dimitris suggested we add guidance or rules about how many of each subject
DN field are permitted

 

Ryan said that if the focus is to make these fields human readable, we use
the current approach, but if we wanted to make these machine readable, we
may want to introduce new attributes vs. re-purposing existing ones.

 

Next meeting we'll pick up here and continue through the remaining fields

 

Doug Beattie

GlobalSign

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200918/7ac17d3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5708 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200918/7ac17d3a/attachment-0001.p7s>