[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495
Moudrick M. Dadashov
md at ssc.lt
Mon Nov 5 14:13:45 MST 2018
Hi Adriano,
I'd say "The communication between the TPP and the ASPSP must always be
secured by TLS 1.2 or higher, but that doesn't mean QWACs must be used"
(see attached pic).
M.D.
On 11/5/2018 5:40 PM, Adriano Santoni via Validation wrote:
>
> Dimitris' description is correct.
>
> Just a remark on qualified certificates for electronic seals (a
> strange beast to all non-European CAs, I guess), since you mention
> them: they are not provided for as an alternative to QWACs - they are
> (will be) used for different purposes, that is for signing requests by
> the TPP (if so required by the ASPSP) at application level. But QWACs
> will always be required. The communication between the TPP and the
> ASPSP must always be secured by TLS 1.2 or higher, and in that context
> QWACs must be used. At least, this is my understanding, based on
> presentations and papers that I am aware of. The ETSI people involved
> in Open Banking standardization may correct me if I am wrong.
>
> Adriano
>
>
> Il 05/11/2018 15:40, Dimitris Zacharopoulos (HARICA) via Validation ha
> scritto:
>> 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).
>>
>> Although the implementing act also accepts Qualified electronic
>> seals, shouldn't the Forum try to accommodate the QWAC solution as well?
>>
>> 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.
>>
>> Setting aside the technical effectiveness of the proposed syntax and
>> whether this information should be broken in more than one fields or
>> not, under the scheme of ETSI EN 319 412-3, all Legal Entities can
>> have an /organizationIdentifier /which can be used as an "improved
>> version" of the /serialNumber/, which currently has no semantics as
>> recently demonstrated by Daymion at the Shanghai F2F. Why can't we
>> define it properly and use it for all legal entities in EV,
>> regardless of the PSD2 directive?
>>
>> I would like people to consider Wayne's proposals 2 and 3 at the
>> London F2F
>> <https://cabforum.org/2018/06/06/minutes-for-ca-browser-forum-f2f-meeting-44-london-6-7-june-2018/#Subject-information-in-EV-certificates-specified-in-clause-92-of-the-EV-Guidelines-and-whether-this-allows-for-the-inclusion-of-X520-organizationIdentifier>.
>>
>> "Wayne: Seems to reserve this field for ETSI use only. Two ways
>> forward: no, you can’t use this field at all (status quo), or reserve
>> it for ETSI and make sure it is extensible, or reserve it for ETSI
>> and revisit guidelines when/if another request comes along".
>>
>> This is what ETSI suggests in the existing technical documents:
>>
>> From ETSI EN 319 412-3: "The /organizationIdentifier /attribute shall
>> contain an identification of the subject organization different from
>> the organization name. Certificates may include one or more semantics
>> identifiers as specified in clause 5 of ETSI EN 319 412-1".
>>
>> This means that, if a CA wants to use the /organizationIdentifier
>> /attribute with no semantics, (similar to what we have today for the
>> /serialNumber /attribute), they can do that just fine and add entries
>> like "123456789", "SN:123456789". However, if the CA wants to use
>> specific semantics as defined in ETSI EN 319 412-1, then the
>> /organizationIdentifier/ must have the following format:
>>
>> From section 5.1.4 of ETSI EN 319 412-1: "The semantics of
>> /id-etsi-qcs-SemanticsId-Legal/ shall be as follows.
>> When the legal person semantics identifier is included, any present
>> /organizationIdentifier /attribute in the subject field shall contain
>> information using the following structure in the presented order:
>>
>> * 3 character legal person identity type reference;
>> * 2 character ISO 3166 [2] country code;
>> * hyphen-minus "-" (0x2D (ASCII), U+002D (UTF-8)); and
>> * identifier (according to country and identity type reference).
>>
>> The three initial characters shall have one of the following defined
>> values:
>> 1) "VAT" for identification based on a national value added tax
>> identification number.
>> 2) "NTR" for identification based on an identifier from a national
>> trade register. Or
>> 3) Two characters according to local definition within the specified
>> country and name registration authority, identifying a national
>> scheme that is considered appropriate for national and European
>> level, followed by the character ":" (colon).
>>
>> Other initial character sequences are reserved for future amendments
>> of the present document. In case "VAT" legal person identity type
>> reference is used in combination with the "EU" transnational country
>> code, the identifier value should comply with Council Directive
>> 2006/112/EC [i.12] article 215. EXAMPLES: "VATBE-0876866142" and
>> "EI:SE-5567971433".
>> When a locally defined identity type reference is provided (two
>> characters followed by ":"), the nameRegistrationAuthorities element
>> of SemanticsInformation (IETF RFC 3739 [1]) shall be present and
>> shall contain at least a uniformResourceIdentifier generalName. The
>> two letter identity type reference following the ":" character shall
>> be unique within the context of the specified uniformResourceIdentifier."
>>
>> This document was extended via ETSI TS 119 495 (check section 5.2.1
>> of ETSI TS 119 495).
>>
>> This means that when a CA uses this representation of values in the
>> /organizationIdentifier /attribute and asserts compliance with
>> /id-etsi-qcs-SemanticsId-Legal/, then this is reflected in the
>> qcStatements extension as described in section 5.2.1 of ETSI EN 319
>> 412-1.
>>
>> Is it complicated? Of course it is. I kindly ask other members
>> working with these ETSI standards to please correct me if I didn't
>> describe the above information very accurately.
>>
>>
>> Thanks,
>> Dimitris.
>>
>>>
>>> _______________________________________________
>>> Validation mailing list
>>> Validation at cabforum.org
>>> https://cabforum.org/mailman/listinfo/validation
>>
>>
>> _______________________________________________
>> Validation mailing list
>> Validation at cabforum.org
>> https://cabforum.org/mailman/listinfo/validation
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20181105/854b5a16/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital-transformation-through-psd2-and-open-banking-figure1.png
Type: image/png
Size: 18603 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20181105/854b5a16/attachment-0001.png>
More information about the Validation
mailing list