[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Wed Nov 14 12:11:38 MST 2018
I just realized that some CA/B Forum members have EV-supported sites
with Certificates that include the OU field in the subjectDN.
OrganizationalUnitName is not listed in 9.2. Just listing a few of them:
* https://www.digicert.com
* https://www.comodo.com
* https://www.bundesdruckerei.de
* https://www.certum.eu
I hope the entire validation subcommittee can realize the urgency of
clarifying this ambiguity in 9.2.8.
Thanks,
Dimitris.
On 14/11/2018 7:49 μ.μ., Dimitris Zacharopoulos (HARICA) via Validation
wrote:
>
>
> On 13/11/2018 6:31 μ.μ., Ryan Sleevi wrote:
>>
>>
>> On Tue, Nov 13, 2018 at 1:39 AM Dimitris Zacharopoulos (HARICA)
>> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>>
>> I'm sorry you thought I was singling out Google, you took it the
>> wrong way. I searched through past minutes and the archives
>> trying to find the position of other browsers and was
>> unsuccessful. Of course, I might have missed something but in the
>> public archives I didn't find a clear statement from other browsers.
>>
>>
>> Those past minutes show, for example, Mozilla supportive of the concerns.
>>
>> I understand your position and interpretation of 9.2.8 and the
>> fact that you claim in
>> "https://cabforum.org/pipermail/validation/2018-June/000928.html"
>> that this is the correct read of the section. In the London
>> meeting we agreed that it was ambiguous to the very least and
>> that there were different interpretations even between Native
>> English speakers in the room. In my plain (non-native) English
>> read of the section, the part where it says "except as specified
>> in Section 9.2" seems to include the part which allows optional
>> sub fields.
>>
>>
>> Note that locality information is optional.
>>
>> If the intent was to only include the specified subjectDN
>> attributes, why does it have (1) and (3) to *restate* that the
>> optional subfields must be verified by the CA? It seems very
>> redundant because for each one of these specified Subject fields,
>> the EV Guidelines describe EXACTLY how the CA must verify the
>> information.
>>
>>
>> Locality fields.
>
> I see. So, you are referring to attributes listed in 9.2.7 of the
> EVGs, and point to the Baseline Requirements.
>
>> I don't know how we can move forward with this. Would members
>> support a ballot that attempts to add the organizationIdentifier
>> with language specific to ETSI? This might need to be a majority
>> vote as we clearly see conflicting opinions.
>>
>> In any case, HARICA would support a ballot that clarifies 9.2.8
>> either way (to explicitly disallow or allow other subjectDN
>> attributes), regardless of the organizationIdentifier issue. I
>> think the risk of CAs being confused by the current language is
>> high enough that might lead to mis-issuances and must be dealt
>> with some urgency.
>>
>>
>> There are a variety of options here. Much as we would approach the
>> situation if OASIS, ITU, ISO, ANSI, or some other
>> limited-membership/pay-for-play SDO attempted to define something
>> contradictory, we need to acknowledge that ETSI's documents are not
>> immutable - finding a solution necessarily involves finding a
>> compromise. Just because ETSI - a pay-for-play SDO that does not
>> regularly solicit the CA/Browser Forum for feedback, despite the
>> ongoing participation by the ESI vice-chairs - wrote it in a document
>> doesn't mean it's inviolate truth.
>>
>> I disagree that the situation requires urgency in resolving; CAs
>> always have a path here, which is when in doubt, don't issue. As
>> we've seemingly agreed on, there's no fundamental need for PTCs here,
>> so the concerns to the CA/Browser Forum regarding urgency are, at
>> best, misstated.
>>
>
> All I said in my last email is that HARICA would support a ballot that
> clarifies 9.2.8, to unambiguously describe one way or another.
> Apparently, the current wording has mislead CAs into thinking that
> they can add subjectDN attributes that are not specifically listed in
> 9.2 so long as the information is verified. I think we need to fix
> that particular issue soon. That's regardless of the other issues
> about ETSI and PSD2 that we talked about. They should be considered
> separately.
>
>
>> We do not support attempts to normatively specify the ETSI documents
>> through the Baseline Requirements or EV Guidelines. These documents
>> are not designed with the Internet community in mind, nor are they
>> developed in a manner that permits participation through that broader
>> community. In short, attempting to specify normative guidance on
>> particular fields, except those as specified either through the IETF
>> or the CA/Browser Forum, is something we are fundamentally concerned
>> with, and believe that all members concerned with openness and
>> transparency should be similarly concerned.
>>
>> Further, given the particular problem of the ETSI specification for
>> organizationIdentifier fully 'squatting' the format and name space,
>> there's no path to compromise that would allow other uses of the
>> organizationIdentifier in a compatible way. That's because 319 412-1
>> (and 119 412) 'squat' all interpretations of the first three
>> characters and define semantics around them that are specific to the
>> ETSI case. This is, at best, disruptive towards an Internet-wide
>> interoperability. In the case of private PKIs, I take no issue with
>> this approach from a policy perspective - after all, private PKIs
>> exist for such - but I do take significant issue with developing it
>> behind closed doors and attempting to require it / squat on it for
>> the Internet. There are technical issues with that approach, which
>> I've seen repeatedly from past professional experiences attempting to
>> define string identifiers with structured semantics (rather than
>> using ASN.1 as intended), but frankly, given we have no interest in
>> validating such, it's not particularly compelling to try to specify
>> in a way to avoid those issues.
>>
>> Of the options that remain, we can see variations on "The CA/Browser
>> Forum change the rules for the Internet based on closed door
>> negotiations at ETSI" and "ETSI adapts to harmonize its profiles to
>> better interoperate with PTCs". Obviously, I have a preference, but
>> for completeness, we can consider some of the following as "options":
>>
>> 1) Permit arbitrary inclusion of Subject information in EV
>> certificates, similar to the BRs
>> Pro: ETSI can now add whatever other fields to the Subject information
>> Con: The premise and value of EV certificates having a consistent
>> profile, particularly in Subject, is meaningfully undermined.
>> Presented with two certificates from two different CAs, both
>> representing the same field, users can no longer be assured that the
>> vetting is consistent.
>
> This is already the case with serialNumber. It doesn't have a specific
> or consistent representation, as Daymion presented at the last F2F. Is
> there any major harm to that? Isn't this just additional validated
> information that Relying Parties can check manually if they want to
> verify the Organization?
>
> May I suggest two more options?
> 4) Specifically permit the /organizationIdentifier /field, and add
> vetting rules no how to verify this information. These would be
> similar rules as the serialNumber for Legal Entities.
> Pro: ETSI can now use an "approved" attribute that contains
> consistently vetted information and can suggest optional semantics via
> the semanticsIdentifier in the qcStatements extension which is already
> allowed and acceptable by the Browsers.
> Con: Some CAs that will not choose the ETSI semantics, will add this
> registry information with various representations just like it happens
> today with the serialNumber field.
> Con: Relying Parties might see the same information in 2 different
> fields (serialNumber and organizationIdentifier)
>
> 5) Specifically permit the /organizationIdentifier /field, add vetting
> rules no how to verify this information (similar rules as the
> serialNumber for Legal Entities) and add a requirement to mandatory
> include either /serialNumber /or /organizationIdentifier/, since they
> both have the same information value.
> Pro: ETSI can now use an "approved" attribute that contains
> consistently vetted information and can suggest optional semantics via
> the semanticsIdentifier in the qcStatements extension which is already
> allowed and acceptable by the Browsers.
> Con: Some CAs that will not choose the ETSI semantics, will add this
> registry information with various representations just like it happens
> today with the serialNumber field.
>
> Option #5 is a bit bolder but considering the fact that the
> /serialNumber /and /organizationIdentifier/ contain some unique
> registry identifiers that are vetted in a similar way, it sounds
> reasonable to me to request one or the other.
>
>
> Dimitris.
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181114/ce8f891b/attachment.html>
More information about the Validation
mailing list