[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Ryan Sleevi sleevi at google.com
Mon Nov 5 08:53:34 MST 2018


On Mon, Nov 5, 2018 at 9:40 AM Dimitris Zacharopoulos (HARICA) via
Validation <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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181105/37860f79/attachment.html>


More information about the Validation mailing list