[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Kirk Hall]

Thanks for introducing the idea of an amendment to EV 9.2.8 – I know we would support that.  I think the best approach is NOT to add specific language for each new attribute that can be included in an EV cert SubjectDN, but instead follow the approach of BR7.1.4.2.2(i)  which basically says the CA can include other information just so long as it has been confirmed and is unambiguously identified.  Who knows what other attributes we will want to add over time.

BTW – a close read of EVGL 9.2 shows that OU fields are not specifically authorized in EV certs…  Does this mean that EV certs with OU fields are misissued?  (OU fields ARE mentioned in the BRs.)

Also, my understanding is that DigiCert is issuing EV certs with GLEIF LEI numbers inside – along with the LEI OID.  Is this also misissuance under Ryan’s interpretation?

The EVGL haven’t really been overhauled in 10 years – maybe the Validation Subcommittee should start a specific “EV Guidelines Comprehensive Review” project, starting with Sec. 9.2…

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Dimitris Zacharopoulos (HARICA) via Validation
Sent: Monday, November 12, 2018 10:39 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [EXTERNAL]Re: [cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

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/6ca67a12/attachment-0001.html>