Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers

up vote 9 down vote accepted

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.

share|improve this answer
    
Exactly what I was looking for to help me understand. Thank you, and if there is a "Perfect Answer" medal (is there?) this deserves it! –  scuzzy-delta Sep 8 '11 at 23:36
    
w.r.t. Multiple validation tends to encourage general leniency and loss of responsibility. Does this occur when cross signing PKIs? (Qualified subordination) –  makerofthings7 Jan 18 '13 at 15:33
1  
@makerofthings7: nominally, no. Cross-signing PKI is trust delegation; the blame is still pinpointed. Here, we are rather talking about having several paths leading to several distinct roots with no cross-signing at all. –  Thomas Pornin Jan 18 '13 at 15:38
add comment

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.

share|improve this answer
2  
Certificate validation is not the job of TLS. The protocol would work just fine. –  Steve Dispensa Sep 8 '11 at 2:36
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.