[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