[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Ryan Sleevi]

On Mon, Nov 5, 2018 at 11:40 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> I see you did not comment my other references for consideration of the *organizationIdentifier
> *in QWACs regardless of the PSD2 directive. I hope the validation
> subcommittee will give them some thought and at least consider them for
> Publicly-Trusted EV Certificates.
>

I would rather deal with the fairly significant mistatements up front, to
make sure that we're making effective use of members' precious and valuable
time. There's no need getting worked up about a potential conflict if, in
fact, there isn't a conflict or a mandate.


> Getting back to the PSD2 directive, it is required by Law  (European
> Member States are forced to implement Local National Laws to implement the
> Directive) and Adriano sent us the legal references. However, one of your
> arguments is that these don't have to be "Publicly-Trusted" Certificates,
> in the sense that the CA/B Forum is using this term at least. I would like
> to expand on that so please help me play out how you envision this because
> I'm afraid we will end-up in the same situation.
>
>    1. A QTSP creates a "private PKI" hierarchy labeled "QWACs for PSD2"
>    2. The TSP adds the necessary information in the CP/CPS and necessary
>    attributes as mandated by the various ETSI documents for PSD2, including
>    *organizationIdentifier*
>    3. The TSP gets a Conformance Assessment Report (CAR) that includes
>    this hierarchy, and is audited against ETSI EN 319 411-2 with QCP-w in scope
>    4. The CAR is sent to the supervisory body and assuming everything is
>    OK, this hierarchy is added in the EU Trust List
>
> The publicly-trusted browsers don't trust these certificates but they can
> be used by banks and merchants as envisioned by the EU. Is this close to
> what you have in mind?
>
I think there's a few misstatements here as well that deserve being called
out.

As you know, both eIDAS and PSD2 take technology-neutral approaches with
respect to what constitutes qualified and, in the case of PSD2, what
constitutes appropriate information.

First, in the context of EN 319 411-2 and eIDAS, that is but one technical
specification for a means of accomplishing the requirements set forth by
eIDAS in the context of X.509 certificates. It is possible to imagine that
other forms can exist, as to be further specified through Implementing
Acts.

Second, in the context of PSD2, the approach is similarly technologically
neutral. Indeed, if you examine various proposals and efforts to provide
standards-guidance for implementing the requirements of PSD2 for a variety
of technological needs and modalities, you see that X.509 certificates are
but one way of representing this information. If you look at the various
proposals for TPP/ASPSP integration, whether AISP, PISP, or PIISP, you can
see a variety of technological approaches are being discussed (for example,
through the use of JSON exchanges or through the use of OAuth2-based
flows). This is the value of technological neutrality, but it's equally
important to highlight that such service exchanges are fundamentally
backend-systems, not with respect to the provision of services to the PSU,
but with regards to how the PSU authorizes the TPP.

Third, in the context of PSD2 and eIDAS combined, as has been discussed,
the requirements for the qualified status - including that of QWACs - are
separate from and slightly orthogonal to the respective requirements for
issuing PTCs. That is, the Supervisory Body (if established) or the MS is
responsible with regards to notification of qTSPs and the modification
of/management of the MS's qTSL. Thus, we have already established that, in
the context of eIDAS qualified certificates, a separate and complementary
management authority with respect to the legal obligations exists beyond
those of the technical, and that management authority MAY ALSO establish
its own set of technical requirements for the participation on the MS's
qTSL.

Fourth, in the context of PSD2 using eIDAS certificates, the TPP is already
going to have to integrate with the qTSL in order to recognize the
qualified status of the certificates, which in this context, is a necessary
part of achieving the compliance with PSD2. That is, if we say that you can
achieve PSD2 using qualified certificates, it's necessary for a TPP to make
use of the qTSL in order to ensure that the certificate is meeting the
requirements re: qualified. So any use of a separate notion of PTC is to
merely introduce additional complexity into a system that already has a
hermetic definition.

Fifth, in the context of PSD2 and the PSU, there's not a requirement that
the TPP make use of a QWAC in the context of browser-initiated
communications, no more than there is a requirement in the context of PSD2
to make use of particular HTML tags or the use of ActiveX. Any discussion
to date has been with regards to the "wouldn't it be nice", without
acknowledging the fundamental risks and incompatibilities.


If it may help, an apt-comparison might be made to the foundational model
of browser security, the Same-Origin Policy, and technology such as CORS -
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS. If a Web
application wishes to instruct a browser to make a particular request with
particular headers, such as IBM's Open Banking APIs
https://open-banking-sandbox.developer.eu.apiconnect.ibmcloud.com/node/377
use of 'psu-accept', then the user agent requires there be a CORS Preflight
to ensure that the recipient application is willing to allow arbitrary
application control of that header. The fact that IBM's API makes use of
this header does not mean we need to 'change' CORS, it just means there are
constraints that exist for that API to be used in the modality of a
user-agent. But that's OK, since that API is not intended (necessarily) for
UA-mediated activity, but for PISP/TPP integrations.

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.

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