[cabf_validation] Proposed Update to EV to include OrganisationIdentifier as per ETSI standard

[Ryan Sleevi]

On Wed, Jun 13, 2018 at 7:21 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

> On 13/6/2018 1:20 μμ, Ryan Sleevi wrote:
>
>
>
> [snip]
>>
>>
>>    -
>>
>>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180613/61bab55b/attachment.html>