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

[Ryan Sleevi]

On Tue, Sep 24, 2019 at 12:59 PM Doug Beattie <doug.beattie at globalsign.com>
wrote:

> Yea, that’s what I thought, but your last email [1] seemed to imply the
> opposite.
>
>
>
> [1] https://cabforum.org/pipermail/validation/2019-September/001336.html
>

Yeah, sorry for making things confusing.

The PSD2 information is *temporarily* allowed in certificates, whether
we're discussing in the subject or in an extension. This is not seen as a
permanent practice.

This information, whether PSD2 or LEI, is *not appropriate* and *actively
harmful* to the security of the various Browser PKIs, as has been noted
(and hopefully Wayne's summary of positions helps clarify this further).
This is obviously a point of contention, for some, but reflects the years
of experience in protecting users and ensuring a robust root program that
can respond to a variety of challenges, while maintaining
interoperability *between
browsers*.

While I cannot speak for other browsers, the choice to allow the PSD2
information was, for us, *temporary*. This is as we continue to work with
the Commission with respect to the eIDAS Regulation, and with ETSI ESI, to
help define an X.509 certificate profile that does not conflict with nor
create security risks for the various Browser PKIs. There are many
technological approaches, as noted in the reply to Stephan, that truly
embrace technology neutrality, that improve trust, and that do not harm
agility.

The same concerns for LEI apply to PSD2. The only difference was that PSD2
has impending dates, and ETSI ESI had taken too long to mitigate the harm
about to be caused by misusing certificates in this manner. It was a
professional courtesy, in order to help reduce the risk of CAs needing to
be distrusted until the matter could be sorted, and to demonstrate that
we're willing to help engage and find meaningful solutions.

The same concerns about use cases exist for PSD2 as do for LEI, as do the
same harms caused by deployment in non-browser cases, such as
server-to-server financial services transactions. The choice to require an
extension, rather than a Subject attribute, was to use the most technically
suited solution for that problem. It was something that was repeatedly
suggested to ETSI ESI, not as a means to resolve the conflict with Browser
PKIs, but as a means to avoid implementation and deployment issues with the
technology itself.

Does that help clarify?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190924/02534ec7/attachment-0001.html>