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

Sat Sep 28 07:01:24 MST 2019

Hi Ryan, et.al.,

Your mail was helpful. I believe we are close to a conclusion where we agree and disagree. 

We agree that

- the LEI is a useful identifier for all kinds of uses cases, e.g. S/Mime, Code Signing etc. (I very much hope for your support when we tackle these).

- For TLS certificates, the LEI added as an extension (which was as well your recommendation several months ago) doesn’t cause any harm in terms of technical security, crypto algo, processing time, loopholes etc. 

We disagree

- whether the LEI causes harm in the longer term. Wayne and you used the example of lowered agility for future developments or higher burden for obtaining a cert. In contrast, I am of the opinion that the LEI adds agility especially in those cases described in my last email. If used by CAs the way we discussed, it also doesn’t slow them down.

- I understand your mails also as an expression of concern that the industry, and the browser vendors in particular, become dependent on an external source. I do not believe that such a dependency exists. However, even in case you feel this way please acknowledge that the LEI is the trusted identifier by the G20, the FSB, over 80 regulators and embedded in over 150 laws globally.

Please allow me not to comment any more on all arguments triggered by past issues. Neither the SHA nor the Symantec example fit here. For me this is more an expression of a general discomfort. 

For any future architecture – and I appreciate your DNS example as well as I support Google’s desire to use DNS only via HTTPS - this will take time. I am not sure what the future holds and which standards will be developed and implemented; however, I know this will not change the Internet overnight. The LEI is a reality now and so are EV certs. 

I believe it is now for the Forum to decide. GLEIF will certainly respect any decision / ballot result. 

However, in case the Forum votes “pro LEI in TLS certs”, I do not believe that you would have sufficient justification to block these certs, to declare them invalid or untrusted.

Best,

Stephan

Von: Validation <validation-bounces at cabforum.org> im Auftrag von Ryan Sleevi via Validation <validation at cabforum.org>
Antworten an: Ryan Sleevi <sleevi at google.com>, CA/Browser Forum Validation WG List <validation at cabforum.org>
Datum: Mittwoch, 25. September 2019 um 16:32
An: Stephan Wolf via Validation <validation at cabforum.org>
Betreff: Re: [cabf_validation] [EXTERNAL]Re: Including LEIs as extensions in EV certificates

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/20190928/3ae893c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5394 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20190928/3ae893c8/attachment-0001.p7s>