[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Wed Nov 14 10:49:10 MST 2018

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181114/08ae013c/attachment.html>