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

[Ryan Sleevi]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190924/8cb200e7/attachment.html>