[Cryptography] distrusted root CA: WoSign

[Jerry Leichter]

>> So if you want alternatives to the *real* problem of secure connections on the Internet, not the pseudo-problem of secure introductions, there are at least two:
>> 
>> a.  I've previously on this list worked the numbers and shown that it would be perfectly possible for browser vendors - or others who want to provide an equivalent service - to regularly distribute the public keys of, say, the top 100,000 sites on the Internet.  Once you get beyond those, there's frankly not much to be gained in knowing that SocksRUs.com really is SocksRUs.com.
> 
> Once more, all you are doing here is renaming "CA" to "browser vendor".
I can't avoid trusting the browser vendor, short of writing my own browser.  But why would I want to add a *second* trusted party - in the reported NSA sense of "someone who can break my security" - when I don't have to?

>> b.  As I outlined above - people don't really use URL's, they use searches.  Fortunately, the top search engines are pretty good - actually, *really* good - at returning URL's that match the *intent* of the search.  Why can't they extend that so that if you click on the link they offer, you can trust that you got to the *intended* site?  A CA doesn't help here *because it establishes trust in a URL, and the URL is not what I intended to reach!*
> 
> Isn't that exactly what CT does? Implemented, btw, by one of the top
> search engines.
> 
> i.e. the search engine returns the URL, CT ensures that the
> corresponding cert is actually the one the owner of the URL intended.
> The CA does the paperwork.
What exactly did the CA add to the process?  The search engine knows that macys.com is the right address for answers to certain queries not because of the certificate that macys.com presented, but because of a large number of signals of what the site is and why it's trustworthy.  (Yes, for all I know, the cert is one of the signals used.  I highly doubt it's the only one.)

Look, I'm not criticizing cert pinning or CT.  They are good partial solutions.  What I'm saying is that the better they become, *the less you need CA's in the first place.*

Lynn Wheeler used to make the same point here in a more general framework (for payment systems and such).  We haven't heard from him in over a year (I hope he and Anne are OK) - ironically, the last message to this group I see from him (May 7, 2015) was on exactly this topic:  "The CA industry had sold the wonders of digital signatures (along with requiring digital certificates) to the financial industry for "safe" financial transactions.... I would also make the point that the relying-party-only certificates were redundant and superfluous ... since the financial institution (relying party) already had the public key on file in the account record. I also made a point that a typical credit card transaction payload size was 60-80 bytes. Appending digital certificates to every transaction would add 6kbyte-12kbytes to every transaction ... a factor of 100 times size bloat (for something that was redundant and superfluous)."

My point is that CA's and the entire CA infrastructure collect a considerable tax from every site on the Web - while adding pretty much nothing significant.  We shouldn't be looking for work-arounds to allow certs to do the job they theoretically are there to do - we should get rid of them entirely and rely on the much better mechanisms we could put into place.  The transition strategy isn't even all that hard:  Simply deploy the new mechanisms in parallel with the old, and once they are in place and have gained sufficient trust, stop relying on CA certificates and let the CA businesses fade to nothing.
                                                        -- Jerry