[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Ryan Sleevi]

On Mon, Nov 5, 2018 at 3:10 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> In my interpretation, direct reference to Regulation 910/2014 (eIDAS) for
> eSeals and QWACs provides the legal basis. Does it directly mandate a
> specific implementation? I think it does. It says "use whatever you have
> for eSeals and web authentication under eIDAS and use it for PSD2". We can
> try to re-invent the wheel but eSeals and QWACs as described by ETSI EN 319
> 411-2 and the various ETSI EN 319 412-x profiles (which are European Norms)
> are currently used as the defacto implementation of eSeals and QWACs linked
> to eIDAS. If you don't think this is reasonable enough, then this
> discussion will likely become very legally-oriented and will move away from
> the technical elements.
>
I'm very confused by your reasoning. You first posed it as a matter of
legal requirement, yet you also seem to acknowledge with respect to the
eIDAS regulation that it remains technology neutral nor does it require the
use of PTCs. So it sounds like we're in agreement that the existence of
PSD2 does not somehow trigger the BRs exception process, correct?

> Now, to your question, yes, the CAR would be against a hierarchy that is
> orthogonal to/separate from the PTC hierarchy, and reflect inclusion on the
> qTSL, which the TPP is already having to integrate with in order to achieve
> compliance with PSD2 if adopting the eIDAS context for the delivery of that
> information. This is similar to root programs' existing requirements
> regarding the separation of roots or intermediates for purpose. The TSP may
> be operating multiple trust services - some qualified, some non-, some PTC,
> some not - and creating hierarchies appropriate for those cases.
>
>
> As stated above, PSD2 and eIDAS are directly coupled, so PSD2 adopts the
> eIDAS context. Regulation 389/2018 is clear.
>

Yes, and eIDAS adopts a technology-neutral approach, and thus does not
mandate the use of PTCs, and thus does not trigger 9.16.3 as you previously
suggested.

But I'm afraid that a TSP won't be able to get a clean audit report for
> ETSI EN 319 411-2 under QCP-w, even if this is not intended to be used by a
> publicly-trusted browser, because the standard has a direct reference to
> the EV Guidelines which currently doesn't allow the *organizationIdentifier
> *attribute in subjectDN. So, we're back where we started.
>

I hope we agree that it's functionally not necessary for a TSP to get
audited against ETSI EN 319 411-2 under QCP-w in order to be recognized as
qualified, both with regards to PSD2 and in general. EN 319 411-2 is but
one factor that the NAB/SB may consider in its recognition of qualification.

But again, I think we're in agreement here - EN 319 412-4 specifies a
particular profile, which is incorporated by 319 411-1 and 319 411-2. TS
119 495 adopted a profile that is itself in conflict with 319 412-4, and
thus also 319 411-1 and 319 411-2. This was entirely avoidable within the
ETSI context.

If we don't agree that this is a bug within the ETSI specification process,
I'm hoping you can clarify what steps the ESI group took to identify and
resolve profile conflicts.

It seems to resolve this, now the Forum is being asked to modify itself so
that ETSI does not have to update any of its documents, at a minimum.
Whether or not such certificates functionally need to interoperate with
PTCs is unclear - no presentation or specification gives effects to that,
and indeed, both common sense and security best practice provide ample
evidence that such interoperability is a net-negative for the goals of
PSD2. Thus, the requirement to update the documents for PTCs, for something
that don't need to be PTCs, in order to avoid having ETSI need to update
its documents (either those specifying PSD2 or those specifying QCP-w)
seems... confusing, at best. PSD2 or QCP-w could be specified in a way that
avoids any incompatibilities with PTCs, by not attempting to be PTCs and
instead separating out the requirements. If they want to be PTCs, it's not
unreasonable to expect them to not conflict with PTCs.


> Separate from all of this is recognizing that SDOs make mistakes from time
> to time, and the existence of a standard from a blessed organization -
> whether ETSI, IETF, or even the CA/Browser Forum - does not immediately
> compel the force of law. Perhaps I'm mistaken here, but every discussion
> I've seen of qualified PSD2 certificates in the context of the ETSI
> specification are merely that the ETSI document is one attempt to frame the
> (technology-neutral) requirements of PSD2 with the (technology-neutral)
> requirements of eIDAS into a specific technical profile (X.509
> certificates). It may be bugged, but that doesn't mean that PSD2 or eIDAS
> are somehow bugged or flawed - just the application of that specific
> technical profile failed to consider the technical interoperability
> necessary for PTCs.
>
>
> I can't speak about interoperability issues of PTCs and the recommendation
> to add *organizationIdentifier *in the subjectDN. This would be a very
> interesting discussion and would be great if all browser members were to
> present their views of potential risks and problems they see in their
> platforms, if this attribute was added in the subjectDN of EV Certificates.
>

Given that there were concerns raised about the far more benign DNQualifier
with respect to the X.500 semantics, which would have facilitated greater
and more widespread use of TLS by resolving the continued issue with common
names, I'm not sure what you're expecting here. I'm going to push back on
this approach, because there's fundamental issues at play here that haven't
been addressed or resolved.

There already had been given alternative paths forward to resolve this, and
it seems the goal is to avoid having to change any ETSI documents by
changing the BRs. Alternative paths included the avoidance of the X.500
specific attribute with defined (and different) semantics than being used
here, making use of a subjectAltName here, since, functionally, the PSD2
identifier is quite literally that - an alternative name representation of
the entity. Concerns were pointed out with the structured string form of
the identifier - itself going against best-practices with respect to ASN.1
specifications in that it encodes semantic meaning within unstructured
(string) data, rather than expressing it semantically - something EN 319
412-5 managed to get right with QcEuLimitValue. Even using an alternative
extension would have avoided this conflict of profile.

TS 119 495 adopted a document that ignored several decades of industry best
practice, inherently created a conflict within its own relevant standards
(319 412-4 specifically, and thus transitively to 319 411-1 and 319 411-2),
and is proposing that the resolution for that be that such a definition be
incorporated into either the BRGs or EVGs, so that neither 319 412-4 nor
319 411-2 need to be updated. Such a decision is the inverse of how the
decision making process goes, and it's entirely unclear at this point why
the matter of TS 119 495 cannot be resolved by ETSI itself.

Can you clarify more about why the Forum should resolve this, given both
the technical and policy issues? Why the relevant ETSI documents cannot be
updated as appropriate, given that these ETSI documents are themselves in
conflict with eachother? And can you clarify what steps are being taken, if
any, to prevent future issues in which activities in which the Forum is
expected to correct issues created by other SDOs?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181105/9bb88b16/attachment-0001.html>