[cabf_validation] Neither a suitable stateOrProvinceName or a suitable localityName to be added into the subject name Minutes of the Validation subcommittee call on 2020-09-10
陳立群
realsky at cht.com.tw
Thu Sep 24 07:35:06 MST 2020
Regarding reviewing the concerns about 'what if there is neither a suitable
stateOrProvinceName or a suitable localityName to be added into the subject
name in last meeting:
1. I hereby would like to take this opportunity to express that we are
unhappy with the naming rule that requires either a stateOrProvinceName or a
localityName must be present in the Subject Distinguished Name(DN) of a TLS
Certificate, although we had raised this issue before but in the end the
forum was not willing to modify the naming rule in the BR. Many small
countries like Taiwan are so small that many organizations are established
and exist at the country level. For those country-level organizations, there
is actually neither a suitable stateOrProvinceName or a suitable
localityName to be added into the Subject DN. The purpose of the Subject DN
is to uniquely (or at least as uniquely as possible) identify the
certificate subscriber. In big countries, it is usually necessary and
naturally to have a stateOrProvinceName or at least a localityName to
distinguish an organization from other organizations which might be
otherwise have the same Subject DN. Unfortunately, this is not the case for
small countries. In a small country, the countryName might already be the
geographical division sufficient identify the organization registered in
this country. In addition, there might be no 'state' or 'province' in the
organizational system or autonomous system in a small country. Among the
attributes defined in X.500/LDAP standards, countryName,
stateOrProvinceName, and localityName are geographical attributes that are
intended to be used as a hierarchical naming tool to help creating a Subject
DN to uniquely identify the certificate subscriber. Our question is that if
an officially-registered name of the country-level organization under the
countryName is sufficient to uniquely identify the certificate subscriber,
why it is necessary to compel us to additionally add either a
stateOrProvinceName or a localityName in the Subject DN, whatever the value
of the stateOrProvinceName or localityName is and it might even be a not
meaningful name or a name that actually might cause confusion on the
contrary rather than increase the identifiability of the certificate
subscriber? Let us take a country-level organization named 'National
Information Infrastructure Enterprise Promotion Association' in Taiwan as an
example. To us, the following Subject DN is sufficient to uniquely identify
this country-level organization:
C=TW, O=National Information Infrastructure Enterprise Promotion
Association
With the current naming rule for the OV TLS certificate, we have to
additionally add either a stateOrProvinceName or a localityName into the
Subject DN. The stateOrProvinceName is absolutely not suitable for us.
Therefore, we have no choice but to add a localityName into the Subject DN.
In the end, the Subject DN for this country-level organization in Taiwan
will be:
C=TW, L=Taipei City, O=National Information Infrastructure
Enterprise Promotion Association
Adding the localityName 'Taipei City' in this case neither make the Subject
DN more meaningful or increase the identifiability of the certificate
subscriber. The only reason that we have to add it is because the current
naming rule requires it. We had raised the question regarding why either a
stateOrProvinceName or a localityName must be present in the Subject DN
before. However, no one in the forum can give us a reasonable rationale
behind this name rule. We are unhappy with the rule that requires either a
stateOrProvinceName or a localityName must be present, but we had learned to
live with it. After several years, We have added a localityName into the
subject DN of OV TLS certificates no mater whether it is necessary.
2. Regarding the certificate profile, I have concern about that the
stateOrProvinceName was indicated in the 'Required/Optional/Prohibited'
field as 'Required' for the OV TLS Certificate and the IV TLS Certificate in
“Subscriber TLS” tab in
https://docs.google.com/spreadsheets/d/1G-ADocQbNJE7XoRlbTfQtub6SF7xq34SBoEG
u-wBh_k/edit#gid=0 . This might cause misinterpretation because the
stateOrProvinceName is requires only when organizationName, givenName, or
surName is present and localityName is absent. Therefore, I suggest that as
the attached figure should be added in the 'Notes and comments' field:
Required when organizationName, givenName, or surName is present and
localityName is absent
Li-Chun Chen
From: Validation <validation-bounces at cabforum.org> On Behalf Of Doug Beattie
via Validation
Sent: Friday, September 18, 2020 8:37 PM
To: CA/Browser Forum Validation SC List <validation at cabforum.org>
Subject: [外部郵件] [cabf_validation] Minutes of the Validation subcommittee
call on 2020-09-10
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
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200924/07401ab7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Figure1.jpg
Type: image/jpeg
Size: 509413 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20200924/07401ab7/attachment-0001.jpg>
More information about the Validation
mailing list