[cabf_validation] [EXTERNAL]Re: Including LEIs as extensions in EV certificates

[Wayne Thayer]

I'd like to emphasize a couple of the points that Ryan has made that
reflect the different perspectives on this issue. First off is "why versus
why not". Some advocates of placing LEIs in certs are working under the
premise that they should be permitted unless someone can prove that they
are a threat. Since it's effectively impossible to envision all possible
security threats, I support the notion that we should be viewing the
addition of any data skeptically, asking why should we include it?

That leads to the second disconnect, about what constitutes a valid purpose
for including an LEI. Here we've been presented with notions that CAs and
their customers think it would be a good idea. Unfortunately, that's not at
all relevant for user agents who want to know how their users will benefit
from including this data. Here is where the use cases come into play. So
far what I've heard is a single browser use case in which a user opens the
certificate viewer and locates the LEI, then uses that to look up the
company in question in some other database? Why would anyone ever do that?
Can anyone articulate, from the perspective of a typical browser user, the
benefit they will be able to gain from having an LEI in an EV cert?

Understanding the value that relying parties will gain is key because that
could show there is more value than risk. This leads to the third
disconnect, which is the assessment of the risk induced by including LEIs
in certificates. The notion that there is no risk is popular, but I believe
there are at least two significant risks:
* The risk of further reducing the agility of EV certificates by adding
another piece of validated information. If any significant number of EV
certificates require revalidation to remediate an incident, we already have
a serious problem given the tedious EV validation process. Adding another
validated field just makes it worse. Of course, one can currently argue
that LEI is an optional field that could be excluded, but...
* The risk of non-browser certificate consumers becoming dependent on EV
certificates containing LEIs. We've seen repeated harms when certificates
are used in multiple "trust frameworks" - e.g. browsers and payment
terminals. Adding LEIs to EV certificates creates a new risk that those
certificates will be used in non-browser use cases that require the LEI but
that don't share other characteristics with the browser trust frameworks,
such as the need for high agility.

Hopefully this helps everyone to understand some of the concerns I have
with this proposal.

Also, the subject of this thread, and Kirk's last message state that LEIs
would be added as an extension, but Tim's last ballot and my prior
understanding of the proposal was that they are to be an option for the
Subject:organizationIdentifier. Has that changed?

- Wayne

On Tue, Sep 24, 2019 at 12:30 PM Ryan Sleevi via Validation <
validation at cabforum.org> wrote:

> Inline
>
> On Tue, Sep 24, 2019 at 3:17 AM Kirk Hall via Validation <
> validation at cabforum.org> wrote:
>
>> We have already covered the purposes for including LEIs as extensions in
>> EV certificates on our Sept. 12 Validation Subcommittee call, and other
>> places – see excerpts from below.
>>
>
>>
>> https://cabforum.org/pipermail/validation/2019-September/001317.html
>>
>
> I can understand that the technical discussion may be difficult to follow,
> but it's important.
>
> None of the quoted discussion (snipped, to ensure the comments aren't
> missed), nor the overall phone call, discussed LEIs in certificates
> specifically. It's important to understand that this isn't simply a
> conversation about LEIs, which are quite useful, but specifically about
> LEIs in certificates and how they are used.
>
> The closest we got was in a server-to-server authentication scenario, a
> desire to record the LEI within an authentication database. But that is
> clearly not a browser use case, and the machine readable aspect of the LEI
> has no benefit to the use of browser TLS.
>
> Perhaps to ensure a productive discussion, it would be reasonable to ask
> you not to repeat points which have, so far, been quite off-topic to the
> question at hand? After all, if the responses had addressed the question,
> we wouldn't still be having conversation, or it wouldn't be necessary to
> say the same thing with no new information.
>
>
>> In addition, ETSI would like to include LEIs as optional extensions in
>> QWAC and PSD2 certificates.  See ETSI TS 119 495 at Sec. C.6:
>>
>>
>>
>> “In case there is no PSD2 Authorization Number, other forms of
>> registration recognized by the NCA can be used in place of a PSD2
>> Authorization Number. If necessary to ensure uniqueness the authorization
>> number can contain a prefix including the type of institution, as listed in
>> PSD2 [i.2] article 1.1: Credit institution - CI, Payment institution - PI,
>> Electronic money institution (or e-money institution) - EMI, Account
>> information service provider exempted under Article 33 of PSD2 (they have
>> only the AIS role) - RAISP.
>>
>>
>>
>> “*In other cases the unique identification number presented in the
>> certificate is e.g. Legal Entity Identifier* [LEI], VAT number or
>> National Trade Register number. The identification number is required to be
>> one recognized under ETSI EN 319 412-1 [1] / ETSI TS 119 412-1 [2].”
>>
>>
>>
>> So the reasons for including LEIs in EV certificates are adequately
>> specified by the CAs who are proposing this ballot.  This is not something
>> that GLEIF needs to prove to anyone.
>>
>
> This is not correct. Entrust DataCard has not demonstrated at all the
> inclusion of LEIs in certificates in their purpose for browser
> authentication. GLEIF, in advocating for this, needs to demonstrate.
>
> If GLEIF is not advocating this, and it is instead CAs like Entrust
> DataCard wishing to sell a new product to an unsuspecting market, one which
> may harm the security and stability of the browser TLS ecosystem, then
> Entrust DataCard bears the burden of proof to demonstrate the value. Unless
> and until that can be done, it's very clear and evident that much harm will
> be done.
>
> 1) A failure to describe how to properly validate this information
> 2) A failure to describe how this information will be used within browsers
> 3) A failure to describe how such information will be used in non-browser
> clients, which will impair the ability to timely respond to browser concerns
>
>
>> The Server Certificate Working Group certainly didn’t require more when
>> we allowed PSD, VAT, and NTR identifiers to be added to EV certificatesas
>> extensions in Ballot SC17 last May, and at that time when Google objected
>> to including any of those additional identifier numbers in the Subject DN,
>> you said “but you can include any extra data you want in a certificate as
>> an extension”.  Remember that statement?
>>
>
> This is an interesting rewriting of history occurring. You may not have
> realized it, but many of the same conversations happened. The *only* reason
> that the PSD, VAT, and NTR issues were accepted were related to PSD2, and
> specifically as a temporary solution to allow continued collaboration with
> ETSI ESI on how it is technologically inappropriate and harmful to use
> X.509 and TLS certificates to express this information. Luckily, the eIDAS
> Regulation and PSD2 are technology neutral in this regard, and we're
> confident that alternative solutions, or modifications to the profile of
> ETSI ESI, can better address the technological needs of the market and
> provide stronger assurances.
>
> There are ample ways to communicate domain binding information, which are
> more flexible than the use of TLS, but provide just as much if not greater
> assurance. The inclusion of assertions within domain name records, or
> well-known URIs, are two approaches actively used by a number of modern
> technologies. Both of these have the benefit of being independent from TLS
> certificates, thus not impairing things like automation or CA incident
> response, while also allowing them to be leveraged with more technologies,
> including DANE and alternative PKI trust models. These technologically
> superior solutions are useful to explore, and promote greater machine
> readability.
>
> Of course, having a productive conversation requires a discussion of use
> cases.
>
> I do hope you will allow GLEIF to respond, and not disrupt such responses
> as on our prior call.
> _______________________________________________
> 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/20190924/02104f70/attachment-0001.html>