Multiple CAs signing a single Cert/CSR?

Question

Just saw this suggested on Slashdot

So I've seen quite a few people wanting a switch to self-signed certs (who IMO mostly don't understand what making that secure actually involves), and an idea to check certs from different network paths (which doesn't work if your only path is compromised, and how do you secure the communication to the service that does the check for you?).

So here's an alternative idea: Require multiple CAs.

Instead of doing it the "extended validation" way which is more money for not a whole lot more service from the same provider, it'd be much better to have multiple CA signatures on a single cert.

Compromising multiple CAs in the same timeframe to create a cert would be considerably harder than creating one. More importantly, it'd make revoking large CAs much easier.

Let's say that the new norm is to have a site's cert is signed by 5 different CAs, and that the minimum acceptable amount is 3 signatures.

Then, if Verisign gets compromised there's no problem with pulling their cert: you're down to 4 valid signatures on your certificate, which is still fine. That should put considerably more pressure on CAs to perform better.

Even Verisign wouldn't be able to trust that their security problems would be let go due to their popularity, as even the largest CAs would be completely expendable without the end users needing to care much. The site would just go with a different 5th CA to return back to the full strength.

It sounds like this would work (although you'd get a security rating as opposed to binary cert validates/doesn't validate). What about viability? Could it be done within existing standards? I can't comprehend if one would issue the same CSR to multiple CAs, then provide a whole bunch of certs to the browser...of if you'd just have one cert signed in sequence by multiple CAs.

Answer 1

On changes to SSL/TLS: the SSL/TLS protocol sends certificates as anonymous blobs which can have any size, up to about 16 MB (which is ludicrous). The protocol itself needs not be changed if one wants to use some new certificate formats.

SSL/TLS implementations expects the blobs to be encoded X.509 certificates. Such a certificate has room for a single issuer (the CA name is written in it) and a single signature. So you cannot have a "multi-signed certificate" within the bounds of the existing X.509 standard. You could get several certificates, with the same public key in each, and then you would only need some sort of convention so that the SSL client software does not mind receiving more than one certificate for the server, and checks them all.

About issuing the certificates: a certificate request is just a vessel for the requester public key, and his intended name, and any kind of information which the CA is free to replicate, or not, in the issued certificate. There is no theoretical problem in having several certificates, even from distinct CA, which all contain your name and your public key; actually, any CA could issue such a certificate without needing any interaction with you. They could all use the same certificate request. In practice, it would require some changes, because existing CA issue certificates as part of Web-based scenarios, where the buyer's browser is instructed to generate a new key pair, and send the public part to the CA without any interaction with the human buyer. Since the idea of having each server own at least 3 certificates basically triples the market of server certificates, I am quite sure that commercial CA would be willing to implement the relevant tweaks to their platform.

On the soundness of the idea: requesting multiple validation is a sound idea (the OpenPGP format already does it, mostly to deal with the inherent unreliability of a web-of-trust CA) but it may backfire: if having a single rogue or compromised CA does not impact general security, chances are that the next Comodo-like event will receive less publicity, possibly none at all. Multiple validation tends to encourage general leniency and loss of responsibility.

On Convergence: what the slashdot quote talks about is Convergence. This is a new system trying to get a foothold. See this answer for some details and pointers on the protocol.

Answer 2

I actually think this would be a really good idea. But it would require a new version of SSL and TLS to support. Currently everything is designed with the assumption that there is exactly one trust anchor. Which means it will probably never happen. I still have arguments with people who claim we "need" to support Windows 98.

Answer 3

I doubt if this idea would work. The CAs would require an API amongst eachother to automate certificate signing. What would they be checking for? If they don't check each other's requests, then a hacker who obtained access to one CAs API (like in the Comodo and DigiNotar cases) would still win. If they do check inter-CA signing requests, what to check for?

What the multi-CA approach could prevent, is an attacker obtaining certificates for high-profile domains like *.google.com, if a second signing CA would flag those where the first one failed.

Personally however I like moxie's network perspective approach. Especially since it puts the trust decision back in the hands of the user, without making it a techie-only solution.

Answer 4

A better way is already in the works in the form of DNSSEC and DANE. The primary vulnerability in the current system of site certificates is that any of the CAs can issue certificates for any domain name. So, it only takes one bad CA to compromise any domain. Instead, the key that signs site certificates for a certain domain can be specified:

From https://www.rfc-editor.org/rfc/rfc6698 (the DANE specification):

"The public CA model upon which TLS has depended is fundamentally vulnerable because it allows any of these CAs to issue a certificate for any domain name. A single trusted CA that betrays its trust, either voluntarily or by providing less-than-vigorous protection for its secrets and capabilities, can undermine the security offered by any certificates employed with TLS. This problem arises because a compromised CA can issue a replacement certificate that contains a fake key. Recent experiences with compromises of CAs or their trusted partners have led to very serious security problems, such as the governments of multiple countries attempting to wiretap and/or subvert major TLS-protected web sites trusted by millions of users."

Answer 5

I'm probably a few years late but anywasy...
One problem that comes to mind is that a mitm can prevent the client from negotiating for multiple certs and only get the one they hacked from a CA.
The easy solution IMO is to use another port or just make up another protocol name so that the client KNOWS it should get MORE THAN ONE certificate.