[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Dimitris Zacharopoulos (HARICA)]

On 5/11/2018 7:05 μμ, Ryan Sleevi wrote:
>
>     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.
>
> [...]
>

I really do try to be as much to the point as possible in order to save 
member's valuable time.

Regulation 389/2018 
(https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018R0389&from=EN) 
in article 34

"

1.   For the purpose of identification, as referred to in Article 
30(1)(a), payment service providers shall rely on qualified certificates 
for electronic seals as referred to in Article 3(30) of Regulation (EU) 
No 910/2014 or for website authentication as referred to in Article 
3(39) of that Regulation.

2.   For the purpose of this Regulation, the registration number as 
referred to in the official records in accordance with Annex III (c) or 
Annex IV (c) to Regulation (EU) No 910/2014 shall be the authorisation 
number of the payment service provider issuing card-based payment 
instruments, the account information service providers and payment 
initiation service providers, including account servicing payment 
service providers providing such services, available in the public 
register of the home Member State pursuant to Article 14 of Directive 
(EU) 2015/2366 or resulting from the notifications of every 
authorisation granted under Article 8 of Directive 2013/36/EU of the 
European Parliament and of the Council (4) 
<https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018R0389&from=EN#ntr4-L_2018069EN.01002301-E0004> 
in accordance with Article 20 of that Directive.

3.   For the purposes of this Regulation, qualified certificates for 
electronic seals or for website authentication referred to in paragraph 
1 shall include, in a language customary in the sphere of international 
finance, additional specific attributes in relation to each of the 
following:

(a)

	

the role of the payment service provider, which maybe one or more of the 
following:

(i)

	

account servicing;

(ii)

	

payment initiation;

(iii)

	

account information;

(iv)

	

issuing of card-based payment instruments;

(b)

	

the name of the competent authorities where the payment service provider 
is registered.

4.   The attributes referred to in paragraph 3 shall not affect the 
interoperability and recognition of qualified certificates for 
electronic seals or website authentication."

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.


> 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.

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.

> 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.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181105/e2c85b88/attachment.html>