[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Ryan Sleevi]

On Tue, Nov 6, 2018 at 2:01 AM Dimitris Zacharopoulos (HARICA) <
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181112/110a28c6/attachment.html>