[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495
Adriano Santoni
adriano.santoni at staff.aruba.it
Tue Nov 6 00:28:35 MST 2018
Hi Moudrick,
Article 34 of COMMISSION DELEGATED REGULATION (EU) 2018/389 of 27
November 2017 reads:
"For the purpose of identification, as referred to in Article 30(1)(a),
payment service providers *shall *rely on qualified certificates"
I do not think that this wording allows using non qualified certs, but
please correct me if I am wrong.
Adriano
Il 05/11/2018 22:13, Moudrick M. Dadashov ha scritto:
> 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/20181106/9741d775/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3849 bytes
Desc: Firma crittografica S/MIME
URL: <http://cabforum.org/pipermail/validation/attachments/20181106/9741d775/attachment-0001.p7s>
More information about the Validation
mailing list