[Cryptography] New SSL/TLS certs to each live no longer than 47 days by 2029

[Jerry Leichter]

> Most of the CA nonsense is because the commercial CA model was broken from the start. The original X.500 model assumed one authoritative CA per country. In the IETF context, only domain registrars should ever have been root level CAs, and they should only ever have issued intermediate CA certs
> to the domains under their authority. Domain owners should have been responsible for issuing their own certs for entities in their own domain.
Let's analyze the situation from the ground up.

I want to use my browser to security connect to foo.com.  What do I have to trust?  Well, to being with I have to trust my hardware.  Attacks on hardware are (a) pretty unlikely unless my opponent is at a nation-state level; (b) so far removed in levels of abstraction that an attack on my specific connection seems not to be worth discussion; (c) not something I can do much about anyway.

So let's move beyond that.  Obviously, I need to trust my OS, as it has access to everything I do.  And then I need to trust my browser, as it has access to everything I do when I form my connection to foo.com, and thereafter.  That's software - who are the actual people/organizations?  If I'm using Windows and Edge, or MacOS and Safari, the people/organization cover both the OS and the browser level, which is nice.  It's ironic that I can't get the same collapsing of trusted parties for any other general-purpose OS or browser, even if I chose my OS and browser for their security.  (Tails is an alternative.)

If I somehow had access to foo.com's key, I wouldn't have to go any further.  But given the way we've built things, I have to open my trust circle wide and trust every damn CA on the planet.  The X.500 model, as it's actually been implemented, expands my trust circle to several times the size it would seem to have to be.  Something that's supposed to be adding to my security has broadened my attack surface by a large factor.

Now consider, thinking in these terms, what short-lived certificates do.  On the one hand, yes, they protect against stolen certificates.  They might seem to protect against certificates that were incorrectly (by chance or by attack) granted - but realistically since all this stuff is automated anyway, if I can get a CA to improperly grant me a certificate for a site, they'll probably keep renewing it for me - they are not going to keep re-checking even if they did some actual checking the first time around.  And there are two other factors to consider:  Every renewal is an opportunity for something to go wrong, or for someone to mount an attack.  At the same time, they prevent me from using a simple defense:  Certificate continuity.  If I make repeated connections to foo.com, as long as they present the same cert each time, I can at least be sure that it's the same foo.com as the last time.

Pulling this all together:  Why aren't any browser makers also CA's?  From the point of view of minimizing the third parties that need to be trusted, this is clearly best.  Yes, it means that sites would have to get certs from a few CA's, but there are only a few browser makers and there are way more browser users than there are sites - so why should the (trust) burden of accepting a huge number of CA's fall on users?

Going beyond that ... why do we need certs at all?  Certs were a solution to the problem of it not being practical to simply give everyone the public keys of all the sites they might want to connect to - they could get them from sites as needed.  But given the size of modern browser distributions (huge) and, due to things like ECC, the size of keys (much smaller than they were when RSA was what we had) equipping a browser with the public keys for the top 10,000 sites - with a fallback to securely querying a site based on a key on this list - would be quite practical.  The initial connections could then be even faster.
                                                        -- Jerry