[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