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

[Ryan Sleevi]

I'll warn you ahead, it's a long response, but I think it's important to be
clear and to highlight there are many possibilities and futures here, when
we work together to bring the best of both worlds together :)

On Wed, Sep 25, 2019 at 8:54 AM Stephan Wolf via Validation <
validation at cabforum.org> wrote:

> So far, this group  has been discussing TLS certs with LEIs only in the
> context of browser2server communication. Please note, the HTTPS protocol is
> widely used in server2server communication. As an example, R3 uses TLS
> certs for securely connecting nodes in the Corda Blockchain application. No
> user nor a browser is involved. In GLEIF’s opinion, the relevance of TLS
> certs for the entire Internet even more suggests embedding LEIs in order to
> help participants in transactions verifying the identity behind the server.
> Just looking at browser eco systems might not be broad enough.
>
Thanks, this is much clearer, and very helpful.

Combining this and your point about the security harm: As Wayne
highlighted, anything that reduces the agility or increases the challenges
in obtaining certificates is a detriment to the security of browser users,
if that's not used by browsers or to fulfill browser security requirements.
Note that TLS in browsers is much more complex than server-to-server
connections - A single Web page loads resources from many domains, and to a
single domain, may make many connections. Some of these connections may be
further shared with entirely different domains or by different operating
entities.

>From Google's perspective, and I believe many of the browser members share
this view (but I'll allow them to speak for themselves), is that it's not
an explicit goal to interoperate with these server-to-server PKIs. PKIs
were designed to be independent, tailored to their specific communities.
For example, there's no requirement that an Istio implementation use the
same PKI as browsers: the needs and constraints of an Istio client are
different than a browser client.

While not wanting to make a broad statement for all browsers, I think one
of the most common problem in the security of browsers has been the lack of
agility of CAs, and their clients.

As a specific example: The removal of SHA-1 was challenging because:
1) Certificate lifetimes were too long, thus making it difficult to do
timely changes to the ecosystem
2) While browsers supported SHA-256 certificates, many other devices did
not. A specific example of payment terminals, using services that would
never be accessed by a browser, required SHA-1 certificates, and required
them from the same CA used by browsers. This fundamental incompatibility
means either breaking those payment terminals or accepting the security
risk as the browser.
3) Setting aside those issues, the replacement of certificates itself was
seen as challenging, because those replacement certificates had to be
tested with non-browser applications before they could be turned on in
production. This delayed replacement.

A similar issue existed with the removal of trust of Symantec. It was
demonstrated that Symantec's PKI did not and had not met the
requisite security challenges, and introduced real risk: e.g. fraudulent
google.com certificates, a lack of domain validation.

However, some servers and services built assumptions that a given API
endpoint would always work in both browser and non-browser cases. An
example is a Large Media Streaming company had a number of set-top boxes
which only supported Symantec certificates. Replacing those certificates,
in order to continue to be trusted in browsers, meant breaking those
set-top boxes.

The correct answer, which aligns with industry best practices, is that
separate API endpoints should be used for these different cases. Using
{device-manufacturer}.example.com and {browser}.example.com - ensuring that
these services don't have to use the same certificates, so that if/when
browsers change, these services aren't impacted.

This isn't something unique to browsers - this is quite literally one of
the design goals of the PKI. In the "original" model, as discussed in the
ABA PKI Assessment Guidelines and in the contemporary IETF discussions, the
notion was that you would assert different policies for different
communities and requirements. The audit simply says "The CA does what they
say they do", but that the CA would assert as many policy OIDs as were
required for their different uses. A user using certificates for
server-to-server TLS to payment processors would assert a different policy
OID. It would be up to each community to decide whether or not to
interoperate (e.g. using policy mappings).

>From the perspective of the browser, it's up to each browser to choose
whether or not they should interoperate with the server-to-server payment
terminal TLS connections. And the answer is that it's not good to
interoperate, just like browsers choose not to interoperate with the IoT
devices that only speak SSL 3 or the websites that require the use of the
<object> tag and plugins.

*2. Identity in or out*
>
> From the comments made by Ryan and Wayne, I have come to the believe that
> a bigger question is in stake. Should identity be included in certs or not?
> Obviously, only with EV certs this is currently given. This might has not
> been perfect in all cases, but served the world a great deal. This opens up
> two scenarios:
>
>
>
> A. Taking identity out of certs, e.g. just use DV certs for securing the
> transmission between servers and browsers.
>
> B. Leave identity in EV certs
>

This is, indeed, a core question, and it's good to flag. In a world of
hindsight, we would likely say that it's better to keep these separate, but
complementary. This ensures the agility the ecosystem needs, while also
allowing the benefits to be provided.

EV certificates are about legal identity; that's very much the jurisdiction
of, well, jurisdictions. The eIDAS Regulation is a good example of an
attempt to provide a legal framework for just that. The Regulation does not
require the use of TLS certificates; that's an implementation decision by
one set of standards that can be (presumably) used to meet the Regulation,
but not a requirement of law.

If we were to sit back, knowing what we know about browsers, and users, and
the ecosystem, how might EV be redesigned? One way you could imagine is
expressing this information in DNS itself. For example, the use of SRV/TXT
records to say "Here's information about the domain". DMARC/DKIM do this,
to great success - providing information to facilitate the authenticated
delivery of e-mail. _ev.example.com could have a TXT record that points to
a URL for the EV certificate. _eidas.example.com could have a TXT record
that points to a URL for the eIDAS certificate. _lei.example.com could have
a TXT record that points to a URL for the LEI certificate. None of these
certificates would have to use the same CA root certificates; indeed, it'd
be ideal to keep them separate (just like the Wi-Fi Alliance does for
Hotspot 2.0, for example).

Of course, that's just one technical implementation. You could also do a
.well-known registration, if you're only concerned about HTTPS -
/.well-known/eidas could refer to the eIDAS certificate. /.well-known/ev
could refer to the EV certificate.

There's huge benefits here: the CA issuing the EV certificate, the eIDAS
certificate, the LEI certificate, wouldn't need to worry about the CA/B
Forum rules, nor would they even have to worry about domain validation.
Those certificates could sign the server's certificate - a choice the
Subscriber would make (and thus could add or remove domains) - rather than
requiring the CA to do so. The CA would just focus on the legal identity
validation, empowered whether by GLEIF (which is why I asked about a
GLEIF-run/contracted CA), the List of Trusted Lists (in the case of eIDAS),
or by industry bodies (e.g. for EV certificates).

You wouldn't even have to make these "certificates" X.509 certificates.
Again, you can look at IETF, and see work like TLS Delegated Credentials
doing just this. This model is "like" certificates, but "replaces"
certificates with short-term assertions. That is, you have a TLS Delegated
Credentials certificate (X.509, classic TLS certificate but w/ an extra
extension to indicate this technical capability). This certificate signs
not-certificates: encoded structures that use the TLS wire format to create
short-term credentials. These short-term credentials are what's used to
actually make the TLS connection (i.e. you don't use the key in the
certificate for the TLS handshake, but the key in the delegated
credential). You can read more about this at
https://tools.ietf.org/html/draft-ietf-tls-subcerts

This is why use cases are so key. Is it better to use /.well-known/ or DNS?
Well, that depends on the use case. Maybe neither work, but we should talk
about why not.

With respect to EV in TLS server certificates, yes, we are seeing problems
with this. Again, using Symantec as an example, we saw huge challenges in
allowing clients to transition to non-Symantec CAs in a timely fashion. One
of these reasons was because these clients expected or required EV
certificates, which meant that the receiving CA - whether DigiCert (who
acquired Symantec's business and customer base) or other CAs - had to do
all the validation work, which is time and labor intensive.

We know that every additional validation requirement decreases agility, so
each introduces risk that we need to demonstrate significant value to
overcome. For EV, it was long thought that the added benefit (presumed) was
worth the risk and challenges. However, much of the peer-reviewed,
top-tier, industry-recognized research, and the related security incidents
and issues, show it's not well-aligned with improving user security. That
doesn't mean we do away with the notion of EV, but it does suggest we
should revisit some of those early decisions, eventually, to separate out
the EV hierarchy and the TLS hierarchy, so that they can be complementary
instead of combined.

This is also huge when we look at things like DANE, which wholly replaces
TLS certificates with information based on DNS (i.e. the server's key is
publicized in DNS, allowing clients to look up and establish secure
connections). The work on Encrypted SNI - e.g.
https://tools.ietf.org/html/draft-ietf-tls-esni - are one example of
publishing security information in DNS, usable by browsers and non-browsers
alike, that shows the idea works.

There are still other ways you can go, such as multiple certificates in a
TLS handshake. Again, if you look at the IETF,
https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs shows
an example of a protocol to do that within HTTPS/2 specifically. This
allows a single TLS connection - that presented one identity - to assert
multiple different identities that can be used by clients to create more
secure, more efficient connections.

There's another benefit from this, which may not be obvious: As more and
more users are behind anti-virus or corporate firewalls that intercept
traffic and terminate with their own certificates, a model like this allows
the information to still be communicated to users. Several CA members of
the Forum, and at least one Browser member, work at companies that develop
TLS interception devices for local or enterprise security. Approaches like
I described above all work to allow this information to be communicated
out-of-band, regardless of the connection termination, which make it easier
to use, easier to deploy, and easier to separately evolve and improve.

So going back to the original question: LEIs are fantastic, undoubtedly.
I've repeatedly shared that privately and publicly. There's great stuff
that can and should be done. But, from a technology perspective, placing
them in TLS certificates is not only not technologically necessary, but
actively harmful to the agility.

In 2019, we know the things that help keep users most secure online is to
ensure there is ubiquitous encryption, protecting users traffic from
interception, manipulation, or inspection from hostile parties on the
network. We should be working to ensure TLS server certificates, as used by
browsers, are easy to obtain, automated, ephemeral, and constantly
improving. If the desire is to express additional information, about a
domain (which works for browsers and non-browsers alike) or about a
connection (which, as I mentioned, has a number of problems in browsers,
but still), there are a lot of technological options that better facilitate
this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190925/55ae45f7/attachment-0001.html>