[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Mon Nov 5 07:40:32 MST 2018


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

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


More information about the Validation mailing list