[Cryptography] distrusted root CA: WoSign

[Jerry Leichter]

Since Ben has repeated asked "what's the alternative to the existing CA system" - let  me toss out a quick back-of-the-envelope sketch of a possible one.

For backwards compatibility, we'll assume that sites will continue to support the current CA/cert system for some time.  I'll ignore that and discuss only the alternative.

Let's take the "subsequent connection" case first:  I'm connecting to a site I've talked to in the past.  My browser stores a triplet of information for that site:  The URL, a signature verification key, and a signing key generation.  To initiate a connection, I go to the URL and start a DH exchange.  However, I require the site sign its DH message.  It includes the signing generation of the key it's used.  If the signing generation matches and the signature is valid, I proceed with DH.  Otherwise, the connection fails.  There's one built-in recovery:  If the signing generation I received is larger than the one I have, I ask the site for a "roll-forward":  The site sends me a new signature verification key and signing generation, signed with the one I already have.  If I'm satisfied with it (I could do other checks if I wished), I replace my record of the key and generation and try again.

How about the "first connection" case?  Let's take today's overwhelmingly common case:  I've done a web search, and a search engine and I have high confidence that it's found the URL I was intending to locate.  In addition to sending me the URL, it sends me its record of the signature verification key and signing generation.  Note that *it already has these* - it got them when it last connected to the site to scrape it.  It follows the same protocols I do.  How does it get the information the first time it scrapes a site?  Actually, it can pretty much just believe what it gets.  About all it has to do is make sure it's not the subject of a MITM attack - something it had better have ways to check anyway.  It's binding the signature to what it finds at the site - which assuming it's actually talking to the site (no MITM) can't be wrong by its very nature.

Note that the search engine is taking on a new *role*, but fundamentally, it's not taking on any new *responsibilities*.  I trust, today, that the search engine does a really good job of mapping the intent of my search to the appropriate URL.  I have no reasonable way to check a URL I got from a search; and in fact I probably never even see it.  So a cert that tells me that the URL (which I never saw) took me to the site named by that URL is meaningless.

In the new approach, my trust in the search engine is unchanged, except that I now trust that it will return to me the signature verification information that it got from that site.  The search engine isn't promising that that information is valid in any broad sense - it's just passing it along.

Obviously, I can have other sources for signature verification information.  I certainly should have it built into my browser for the search engines I intend to use!  All kinds of techniques applied to certs go over easily - e.g., noticing that different sites are being handed different certs/signing information for what's allegedly the same site.

If you want to trade space for communications, you can store fingerprints of the signature verification keys and ask a site to send you its key as needed.

An obvious extension is to provide client authentication by having the client sign its half of the DH exchange with a signature that the server can check.

                                                        -- Jerry