[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

[Dimitris Zacharopoulos (HARICA)]

On 5/11/2018 5:53 μμ, Ryan Sleevi wrote:
>
>
> On Mon, Nov 5, 2018 at 9:40 AM Dimitris Zacharopoulos (HARICA) via 
> Validation <validation at cabforum.org <mailto:validation at cabforum.org>> 
> wrote:
>
>     On 5/11/2018 11:56 πμ, Ryan Sleevi via Validation wrote:
>>
>>
>>     On Mon, Nov 5, 2018 at 4:38 AM Adriano Santoni via Validation
>>     <validation at cabforum.org <mailto:validation at cabforum.org>> wrote:
>>
>>         Just to provide a wider picture of the implications (to those
>>         who are interested in this topic):
>>
>>         Not only is the organizationIdentifier attribute required by
>>         ETSI TS 119 495 (*): its presence in the QWAC certificate is
>>         also taken for granted by the "Implementation Guidelines"
>>         published by the Berlin Group
>>         (https://www.berlin-group.org/nextgenpsd2-downloads). And I
>>         suppose that several major banks and other fintech companies
>>         are currently developing and/or integrating APIs based on
>>         those guidelines.
>>
>>         So... it looks like a time bomb.
>>
>>         Adriano
>>
>>         (*) Which, to my understanding, technically implements the
>>         requirements of Art. 34 of the COMMISSION DELEGATED
>>         REGULATION (EU) 2018/389 of 27 November 2017.
>>
>>     It seems like participating CA members can flag the profile
>>     incompatibilities. As I mentioned, there's nothing inherent in
>>     the profile that requires the use of publicly-trusted QWACs -
>>     where there exists profile incompatibilities between multiple
>>     technical profiles, it's only natural to recognize you can only
>>     correctly implement one of the profiles. Given that qualified
>>     certificates have their legal value independent of the trust
>>     status of those certificates, and given that PSD2 specifies such
>>     a profile for the purpose of legal value, it seems the value can
>>     be recognized for such server-to-server exchanges without the
>>     necessity for a change in the BRs or EVGs. Indeed, as the SHA-1
>>     issue in the payment services industry has profoundly
>>     demonstrated, the use of separate hierarchies for such payment
>>     processing certificates can be a boon to the system, as such
>>     terminals may not be able to handle the "rapid" change of the
>>     public trust ecosystem.
>>
>
>     Does this only affect Banks in EU or does it also affect
>     credit-card merchants in EU? If it includes credit-card merchants,
>     then we have a significantly greater number of organizations that
>     will soon be requesting such certificates (mandated by a legal
>     requirement) that contains this particular information both in the
>     SubjectDN and the qcStatements that includes the "role" of the
>     Subscriber (PSP_AS, PSP_PI, PSP_AI or PSP_IC).
>
>
> From all of the discussions we've had to date, it affects nobody.
>
> I mean that quite literally - there's no requirement to use these 
> certificates with publicly trusted certificates. In the context of 
> PSD2 for payment processor/provider interoperability, there's no 
> requirement to use publicly trusted certificates.
>
> Every presentation we've had on this matter is that, for some reason 
> yet unspecified and undocumented, 'it would be nice' if these 
> certificates could also be website certificates. There has not, to 
> date, been a demonstration why - with the exception of "Well, maybe 
> browsers could also show special UI indicating this is an 
> EU-recognized banking institution in the UI" - which itself is 
> aspirational at best, but incompatible with UI changes.
>
>     Although the implementing act also accepts Qualified electronic
>     seals, shouldn't the Forum try to accommodate the QWAC solution as
>     well?
>
>
> Why?
>
>     I hate to bring this argument in the discussion but, at least
>     according to the BRs (9.16.3), the Forum is supposed to try to
>     modify the requirements to make it possible for CAs to comply with
>     both the Requirements and the Law simultaneously. EV Guidelines
>     describe it a little differently in section 8.1.
>
>
> That argument is flawed, in as much as it's not required by Law.
>
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.

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?


Dimitris.

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