[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Dimitris Zacharopoulos (HARICA)]

On 12/11/2018 9:59 μμ, Ryan Sleevi wrote:
>
>
> On Tue, Nov 6, 2018 at 2:01 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>     Hopefully Nick Pope and other ETSI members can best answer this.
>     In my interpretation of EVGs, as I already expressed it at the
>     London F2F, per 9.2.8 (2) allows other subjectDN attributes as
>     long as they are properly validated by the CA. This interpretation
>     is also aligned with the BRs 7.1.4.2.2 (j) which is written more
>     clearly.
>
>     In any case, I don't think ETSI thought there was any profile
>     conflict between their requirements and the PTC requirements
>     because they have the same interpretation, again, as expressed at
>     the London F2F meeting.
>
>
> I think we have to go back to the 'context' here to understand the 
> 'conflict'.
>
> Nick's slides are at 
> https://de.slideshare.net/ArnoFiedler/etsi-cabf-plenary-20180607-org-identification 
> based on the London meeting minutes, and the previous discussion was 
> captured on the Validation list at 
> https://cabforum.org/pipermail/validation/2018-June/000922.html
>
> That relates to the previous discussion at 
> https://cabforum.org/pipermail/public/2018-May/013531.html , and the 
> conflict with the EVGLs was explicitly enumerated in 
> https://cabforum.org/pipermail/validation/2018-June/000928.html
>
> You made your case for why you think it should be permitted, but did 
> not and have not addressed the concerns where it is prohibited, which 
> multiple browser members have highlighted as a concern (and thus 
> disagreed with your interpretation to ignore 9.2.8)
>
> To summarize: EVGLs 9.2.8 explicitly prohibits adding additional 
> fields to the Subject of an EV certificate, except for those otherwise 
> explicitly detailed.
>
> That doesn't prevent adding other metadata to certificates, such as 
> QCStatements - but treats the Subject as an area of particular 
> sensitivity, at least with respect to EV. Put differently, EV 
> certificates being issued with organizationIdentifier (e.g. as used 
> within EN 319 412-1 for a broad profile of NCP/LCP certificates not 
> necessarily QWACs, and which AFAICT map to OV/IV certs) are in 
> violation of the EVGLs 9.2.8 and are misissued.
>
> The 'conflict' created re: PSD2 is that it requires QWACs, which 
> require qualified and consistent with the EVGLs, and thus have a 
> conflict of profiles. There are many ways to resolve it.
>
> Nick's initial proposal was to explicitly add/recognize PSD2 (but, 
> more broadly, the profile of 319 412-1) in the context of the EVGLs; 
> that is, to give special standing in the EVGLs for a document that has 
> no fundamental relationship with EV certificates or browsers more 
> generally. There are technical issues with that, related to both the 
> design and the implementation, and there are policy issues related to 
> that, in terms of specializing fields.
>
> In addition to / separate from those issues related from creating 
> profiles that are in conflict, the other portion of the documented 
> motivation is because other, non-qualified CAs may, under the BR 
> sections you mentioned, be seen as being permitted to issue OV/IV with 
> an organizationIdentifier whose syntax conflicts with that of 319 
> 412-1. That is, by using a generic field (and not one of, say, an 
> ETSI-defined OID), a conflict was created in which relying parties 
> cannot be sure whether the organizationIdentifier is using the 319 
> 412-1 syntax or using another syntax, without also looking at 
> secondary sources (such as the policy OIDs or the CA's status as a 
> qualified TSP, which implicitly brings with it some qualified status). 
> Thus the ballot proposes to *restrict* organizationIdentifier to only 
> what ETSI has defined.
>
> The resolution of that conflict is functionally similar to the 
> resolution of the profile conflict; the use of a dedicated OID would 
> have avoided that issue, by virtue of 7.1.2.4 of the BRs. There would 
> have been no need to normatively update the BRs or the EVGs, had such 
> an approach been used (by 319 412-1 and/or by TS 119 495), as the 
> non-qualified, non-European CAs would have been prohibited from 
> asserting that OID outside of the context of 319 412-1.
>
>     I think it's a very different problem. The DNQualifier didn't pass
>     because some members were confused by the contents if that field.
>
>
> No, that's not entirely accurate. Some members objected on the basis 
> that the dnQualifier's proposed semantics were distinct from the 
> organizationIdentifier's proposed semantics. The choice of dnQualifier 
> was for purposes of interoperability with legacy systems - which would 
> not be applicable in the case of PSD2.
>
>     To the contrary, I think ETSI preferred to use the
>     organizationIdentifier which is clearly described in the X.500
>     scheme instead of creating new custom attributes. They don't
>     enforce different semantics for this attribute. They only offer an
>     optional semantics representation (specific to ETSI), if it is
>     asserted via a qcStatements declaration. IMHO this doesn't use the
>     attribute differently.
>
>
> That's not entirely accurate. Semantics are being enforced, and the 
> qcStatements declaration is proposed as insufficient by at least some 
> of the past discussions. Custom attributes *are* preferable, and the 
> avoidance of them, or the stuffing of metadata in the subjects more 
> broadly, subverts many of the goals and purposes of the naming scheme.
>
> I am by no means an X.500 purist, but the entire point of structured 
> OIDs is to allow flexible extensibility within a defined namespace and 
> without having to assert interdependencies as being done.
>
>     The current language in EVG is ambiguous enough to have one
>     interpretation (Google's) that including the
>     /organizationIdentifier /in an EV Certificate will be treated as a
>     violation of EVG and a misissuance, and others that interpret this
>     as being allowed under 9.2.8(2). Please correct me if this is not
>     the case.
>
>
> As you can see through the past minutes and links provided, the 
> framing that this is somehow an interpretation 'unique' to Google is 
> mendacious and unhelpful.

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.

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.

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.

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.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181113/125ce04e/attachment-0001.html>