Why do we not require websites to have several independent certificates?

Question

It is often cited as a primary point of concern that a single compromised CA can make for significant damage, as all websites (and other entities) that rely on this CA cannot be trusted anymore.

Pardon my ignorance, but why do we not require websites to be validated by, say, 3 certificates of independent CAs? Only if a majority of the certificates agrees on the websites validity, it would be considered acceptable. This seems to solve the above problem to a large degree.

• If a certificate is issued without proper justification by a single CA, this would not make a website accepted. Only two compromised CAs at the same time could do this.
• If a CA is not trusted anymore, websites which rely on it still work, as they are validated by two other CAs apart from the one that fell off. This means it is easier to revoke trust in a CA without 'breaking the internet'.

Obviously, such an idea would lead to additional work. But seeing as time and money spent do not increase linearly, this could be acceptable.

It is also easy to run this pattern in parallel to traditional infrastructure, as websites could specify either one or three certificates, and the new rules (and bonuses) would only apply to them.

Answer 1

why do we not require websites to be validated by, say, 3 certificates of independent CAs?

Here are a few reasons:

1. Cost. Purchasing certificates is already somewhat expensive*; tripling that expense - and forcing purchasers to wade deeper into the pool of potential CAs, where they usually start at the cheap end - would not be welcomed.

2. Complexity. Currently, if a certificate expires, the site is offline or degraded until IT can scurry around and fix it. It happens surprisingly often given that expiration dates are known and can be planned for. Your proposal would triple the number of certificates that need to be installed correctly, that need to be replaced before expiration, that need correct certificate chains... Some of this stuff is hard enough today with just one CA!

3. Compatibility. The TLS protocols do not specify a method of operation where multiple certificates must be validated, so you'd have to update or replace the protocol being used, which will take years. There's no way to specify to the client that this particular server requires multi-certificate validation, so downgrade attacks are trivial - again, you'd need to create a method, and then wait years for support to percolate out.

4. Certificate Pinning. Your idea says "Let's assume the CA model is broken, and as a solution increase our dependence upon the CA model." If one CA can be compromised, why not two (assuming a 2/3 majority wins in your model)? At that point you'll start saying, "Well, obviously we want to trust Entrust more than the Consolidated Republik of Tadpolistan" - at which point you've reached Certificate Pinning, which is already a thing.

5. WoT else? The other natural conclusion you'll reach, when you decide that some CAs are more trustworthy than others, is that there should be a method of incorporating reputability. This is called the Web of Trust, and is a competing model to the Centralized Trust of CAs today. One implementation of the WoT method is the Perspectives Project, which is an interesting approach to the same problem you describe (and which works in complement to, and in compatibility with, the existing CA model).

* Before someone jumps up and says "Startcom!" or "Let's Encrypt," please remember that businesses drive the CA model today. They pay significant amounts of money, and some of them purchase thousands of certs annually. The cost impact needs to be considered against all players. (And even on the low end, if you want a free cert, now you would have to find 3 reputable free providers, when finding one was already a challenge.)

Answer 2

RTLS neither supports multiple leaf certificates for a single session nor X509 supports multiple issuers for a single certificate. This means there will be changes necessary on the protocol. But lets just ignore the effort to make such changes and look how much more security we get with your proposal. Lets have a look how a bad certificate might get issued, in which situations your proposal helps and how it compares to existing proposals.

How the attacker can get a certificate

A bad certificate can be issued if the CA is compromised by the attacker, i.e. is buggy, hacked or if the CA employs untrustworthy people. In this case your proposal would help because you hope that not all of the multiple CA's have these problems at the same time. Of course this is not that simple, because you better make sure that the different CA's are actually controlled by different entities and run different code, i.e. that a single hack is not actually a hack of multiple CA.

But an attacker can also get a certificate by compromising the domain validation process. This process works similar for all CA and if the attacker gets access to the mail of the domain owner or the server he might manage to get a certificate for the same server from multiple CA's. In this case your proposal would not help at all. But of course in this case the hacker would only get access to a few certificates for badly secured domains, while in the case of a CA compromise he might get lots of certificates even for domains with good security.

What alternative proposals exist

With certificate or public key pinning (HPKP) a domain owner can make sure, that the certificate uses a specific public key. With HPKP is effect the attacker would need to get access to the private key of the existing certificate, i.e. hack the server. This protects domains with good security against misuse of certificates the attacker created by compromising a CA. The nice thing about HPKP is that it is cheap and easy to roll out and that it is already supported by major browsers.

Certificate transparency is a public log which can be used to find out if a CA issued a certificate which it should not and if a CA is aware that it issued a specific certificate. This can be used by the domain owner to check for rogue certificates. While not all CA's have such logs yet the number is growing because the browser vendors push the support as a requirement to be a trusted CA. For now Chrome requires all EV certificates (green bar) to be covered by such a log and some other CA are also required to issue such logs since they showed to have insecurities in the past. The nice thing is that supporting browsers like Chrome know which CA should have such a log and can check against it.

DANE makes it possible for the domain owner to publish its own certificate in the DNS without the need for CA. Of course this has to be somehow protected against DNS spoofing so it needs DNSSec. DANE can be used both with self-signed certificates instead of using a public CA or with CA signed certificates as an additional protection. While not currently implemented in the browsers it is already used for mail by several providers and support in this area is growing.

Summary

While your proposal would be useful to increase the security it needs major changes to the existing TLS protocol (serve multiple leaf certificates) or X509 model (multiple issuers for a single certificate). But at least optional multiple certificates are probably possible to implement with the help of TLS extensions, so we don't need to new TLS version for this. It will increase the data transferred in the full handshake though (lots of leaf certificates and chain certificates) which slows down the handshake.

The alternative proposals don't need such protocol level changes since they work outside the TLS protocol. Also, in the case of HPKP and DANE they provide more control over the certificate to the domain owner than your proposal.

But at the end all of these ideas could in theory be used together to increase the security. And while your proposal would increase the security it is probably more disruptive than the others and would cause more costs, and that's why the others are preferred for now.

Answer 3

What you propose would indeed increase security, but at an increased administrative cost and technical complexity. I think CA compromises are simply too rare events to justify those costs. Also, if a similar scheme will be put in practice, it will probably be more elaborated than simple 2 out of 3 voting. For example, having only two certificates, one valid and one aged away, should be enough to confirm the identity while protecting against single CA compromises.