[cabf_validation] OrganisationIdentifier mandated by ETSI TS 119 495

Sun Oct 28 03:45:14 MST 2018

All,

from the past discussion on this topic, it seems to me that the 
inclusion of the the organizationIdentifier attribute (OID 2.5.4.97) in 
the Subject of an EV cert could presently be regarded as a misissuance. 
I am not sure if this was expressly pointed out, but it seems to follow 
from the discussion. This interpretation also seems to be corroborated 
by the current wording in EVGL §9.2.8 ("CAs ... SHALL NOT include any 
Subject Organization Information except as specified in Section 9.2").

That, in turn, implies that QWACs cannot contain the 
organizationIdentifier attribute, lest they do not comply with the EVGLs 
(and therefore are not QWACs).

However the Payment Services Directive 2 (PSD2) requires QWACS, and the 
ETSI TS 119 495 technical specification ("Qualified Certificate Profiles 
and TSP Policy Requirements under the payment services Directive (EU) 
2015/236"), mandates in §5.3 the inclusion of the organizationIdentifier 
attribute in QWACs: "The organizationIdentifier shall be present in the 
Subject's Distinguished Name and encoded with legal person syntax....".

So, If I am not mistaking or overlooking anything, the puzzle pieces do 
not fit together very well...

Now, financial institutions are already experimenting with Open Banking, 
and for the time being they just need test (i.e. untrusted) PSD2 
certificates , so I guess it's not a problem if they contain the 
organizationIdentifier attribute. But in the not too far future, 
production (i.e. trusted) PSD2 certificates will be required.... Somehow 
this inconsistency must be fixed, or CAs will not be able to issue PSD2 
QWACs without infringing the EVGLs.

Maybe the forthcoming update of ETSI TS 119 495 already solves the problem?

Adriano

Il 13/06/2018 16:53, Ryan Sleevi via Validation ha scritto:
>
>
> On Wed, Jun 13, 2018 at 7:21 AM, Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>     On 13/6/2018 1:20 μμ, Ryan Sleevi wrote:
>>
>>
>>     [snip]
>>
>>              o
>>
>>
>>
>>>         Could you indicate why, besides that's not what Nick asked
>>>         for (noting, most importantly, that the status quo does
>>>         *not* apply to PTCs, as clearly stated), you find those
>>>         problematic?
>>>
>>
>>         I am not sure I understand your question about the status quo
>>         not applying to PTCs. Do you mean that mr. Pope said that his
>>         request does not apply to PTCs? I understood the opposite.
>>
>>
>>     The specification, as written, does not apply to PTCs. It is a
>>     private PKI. The request is to change the public PKI so that the
>>     private PKI does not have to change. That's... silly.
>>
>>     Some users are anticipated to want to overlay PTCs with this
>>     private usage. That's functionally bad, period - you should keep
>>     these PKIs separate. However, rather than telling them
>>     (correctly) "No, sorry, this is a bad design" - one that will
>>     cause pain similar to payment terminals and SHA-1 - I'm actively
>>     trying to engage here to find a solution that doesn't blindly
>>     ignore X.520, RFC 5280, or the goal of the BRs. There's no
>>     fundamental requirement to use PTCs - so a "no" vote is an even
>>     better response - but if we are going to permit it, requiring it
>>     be done "right" doesn't seem unreasonable.
>>
>
>     We seem to have a misunderstanding about the "private PKI" vs PTC.
>     I read the proposal as a more general adoption of the
>     organizationIdentifier and not just the payment industry. The
>     referenced ETSI TS 119 412-1 V1.2.1, describes in section 5.1.3
>     semantic guidance for Natural Persons and in section 5.1.4 for
>     Legal persons.
>
>     Quoting from the TS section 5.1.4:
>
>     "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.
>     3) "PSD" for identification based on national authorization number
>     of a payment service provider under
>     Payments Services Directive (EU) 2015/2366 [i.13]. This shall use
>     the extended structure as defined in ETSI
>     TS 119 495 [3], clause 5.2.1. Or
>     4) 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".
>     "
>
>     Note that "PSD" is only one of the available options. My
>     participation in this discussion was never about the "Payment
>     Services" but for the additional unique, unambiguous information
>     of Legal or Natural Entities which is already included in OV/IV/EV
>     PTCs and could be expanded.
>
>
> This was specifically and explicitly framed as related to PSD, as the 
> presentation showed, and as the use cases discussed. It was repeatedly 
> and explicitly stated this was for PSD, and in business-to-business 
> direct endpoints.
>
> The use case for why PTCs matter at all was presented as, to avoid the 
> inappropriate phrasing the speaker presented, "to ensure that less 
> skilled users can notice if they click the EV bar as to who the 
> payment provider is, before providing payment details". Obviously, 
> that's a problematic goal from the get-go, but the only reason we're 
> even still discussing is because we're trying to find an alternative, 
> however misguided the goal is, to avoid conflict with other PKIs.
>
> Let's be clear: The proposed language is effectively "You can only put 
> what ETSI has decided to allow in this field, and what you put in it 
> can be anything and everything, and the relying party is supposed to 
> know that the 4th and 5th octet are indicative of a naming context 
> that may vary highly. That is, BE:GB-FOO != BE:GR-FOO, and the entire 
> value proposition is predicated on human users inspecting certificates 
> to know that B != R (at least, until the completion of Brexit, then 
> we'll get to find other examples)
>
>     I hear your arguments on why you think including different sets of
>     information in one attribute is a bad idea. I suppose this is
>     definitely something mr. Pope should take back to ETSI. Hopefully
>     some brilliant minds came together and wrote these proposals that
>     ended up in official standards, which of course doesn't mean that
>     everything is perfect or flawless.
>
>
> Indeed. But, independent of that analysis, there's no overriding 
> requirement for the use of publicly trusted certificates.
>
> _______________________________________________
> 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/20181028/f885da03/attachment.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/20181028/f885da03/attachment.p7s>