4 ms·
I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that p
by ademarre 9y ago
I think the point there is that if Chrome doesn't trust that CA, then the servers will need to be updated to use a different CA, which will break clients that pinned the old CA.
- Manishearth 9y agoIirc you can have certs signed by multiple roots though, right? In which case these sites can just get their cert signed by the pinned symantec root and a real still-valid root. Nobody's stopping symantec from signing new certs, they just won't work in Chrome (and likely other browsers) Or maybe I've misunderstood the situation.
- wnoise 9y agoUnfortunately, you can't keep multiple chains in a single X.509 certificate. While you can have a given key signed by multiple CAs, AIUI, this just lets you switch easily, not tell a client about both, and just work if they trust either CA.
- Manishearth 9y agoHuh, okay. Surprised that's not possible. IIRC letsencrypt did something like this to bootstrap but I guess you can have a root sign a root, but not have two roots sign something and have both in the same cert. I've always been of the opinion that the rogue/careless CA problem can be solved by mandating N root sigs and recommending M>N. In a system with multiple independent LetsEncrypt like entities this is doable. If a CA needs to be revoked you can do it in a much easier way here, since it's still ok to transitively allow sites with N-1 certs and one now-disallowed cert signed by that CA. Doesn't fix all the problems but it certainly removes the inertia behind kicking out bad CAs. Looks like we'd need a x509 extension to do this then. :/