The events in Rainbows End depend upon revocation being effective, in particular revocation of a root CA, and very rapidly.
For one thing, "revoking" a root CA isn't a thing, the root's signature is mostly a convenience (it's self-signed) and perhaps in another world roots would exist as distinct documents not as X509 certificates signed by themselves. So there isn't anybody to "revoke" it like other certificates. You can distrust them though.
In the real world lots of systems would never become aware of the revocation/ distrust at all, and there are gatekeepers for many other systems that could become aware (e.g your copy of Chrome or Firefox can learn that a root CA is no longer trusted but it would not do so without humans at Google or Mozilla deciding this was a necessary course of action).
It's necessary to the plot of Rainbows End that this happens unrealistically quickly, Rabbit must be disabled or it will certainly interfere with subsequent events, and it seems Vinge (unlike me) isn't sure exactly what Rabbit is, so this vague technical intervention seems like an effective way to stall Rabbit without thinking too hard about that question.
You don't revoke the root cert, no. You revoke a cert that signed a lot of certs, which is often one degree of separation from the root cert. I don't recall if he stated it wrong and I glossed over it because I knew what he meant, or the character was dumbing it down for the rest of them.
Revoking a signing cert, breaking the cert chain, would indeed make a mess for everyone using those certs.
OK, consider revoking, since we're talking about them, Let's Encrypt's R3 issuer. In a sense only they (ISRG, the organisation behind Let's Encrypt) can do that, since the revocation would need to come in the form of an updated CRL (Certificate Revocation List) from ISRG's root. So you'll be making a late night phone call to key people from ISRG to demand (persuade?) an immediate revocation.
How often do you suppose most systems examine that CRL?
If you guessed anything other than "never" you're wrong. Almost nothing you use will ever notice.
But that's not enough anyway - R3 is also trusted via a cross signature from Identrust's DST Root CA X3. So their organisation also needs to be woken and persuaded to perform an unprecedented middle-of-the-night revocation of some certificate they've seen no evidence is a problem.
Now, you've disturbed all these nice people, with your very urgent problem of... you want to stop something you can't discuss happening that involves some confidential things and a bunch of other confidential things and they must never speak of it to anybody - in the morning they're going to be doorstopped by a thousand tech journalists wondering why they broke everything - or they could just hang up. But we'll suppose you did that, as I said it doesn't have any effect. Oops. Rabbit will notice, no doubt, but it isn't disabled.
OK, so what can you do that will actually have some impact? Well, you can get Microsoft, Google and Mozilla to use their out-of-band "kill switch" functionality. Each works differently. Microsoft's has the advantage that it's entirely a closed door process, if you can get the ear of the right person you can make any change you want. Unfortunately the latency is one calendar month. Rabbit is causing you a problem today? By April we can fix that. Oh, you need something sooner? Too bad.
Google are more promising, they can tell most Chrome installs to distrust R3 without any independent confirmation and the updates will typically take only a day or so to have effect. Rabbit will be out of your hair before tomorrow's evening news can run the story about your resignation or arrest. They will probably tell everybody why though...
Mozilla likewise can react quickly, perhaps in just a single day. However unfortunately Mozilla deliberately makes these decisions in public. You're going to need to tell a bunch of random people who don't even work for Mozilla about your urgent need to shut down this issuing CA. They're going to have questions. You probably don't even want to read the questions, never mind answer them. Oh dear.
If I'm installing an app, running a credit card transaction, or logging into my brokerage, nobody is checking the CRL, because they're running OCSP to check the cert chain. That's what my code did. That's what a coworker's code did, and that's what (I'm told) browser TLS implementations do.
If a countersigned certificate is revoked by one signer, is it still safe to use? I hope your answer is 'no'. Otherwise, as you say, I can revoke the certificate in Europe but have to wait for the Americans to get out of bed.
Why did they including both certs in the chain if everyone trusts the same CA? They are including them because people cherry-pick. My app is likely not checking both roots, but picking one as the one I trust and seeing what it says, in many if not all implementations. Because I'm looking for a chain that I understand, then seeing if it's valid, and one of the chains I don't understand.
DOS attacks are not an all or nothing thing. Often it serves the attacker's motives if only most of the traffic is blocked, or specific traffic is unlikely to succeed. Taking out a particular person or "just" 75% of users could be desirable.
> that's what (I'm told) browser TLS implementations do.
Unlike "your code" and that of your co-worker who ever that might be, I can tell you exactly what browsers do and you're wrong, though I haven't any idea who (if anybody) "told" you that they check OCSP to "check the cert chain".
Chrome doesn't have OCSP fetching code. It uses CRLsets, controlled by Google, which I described previously.
Safari does do OCSP... if Apple's backend tells the client this certificate was revoked. Why then? Ask Apple, makes very little sense to me, but that's their policy. Again you'll need to liase with Apple HQ to figure out how to get their backend to report all these certificates revoked or nothing happens.
So in the modern world that leaves Firefox, which does have OCSP fetching code, but it's default off and they recommend you leave it that way. Why? Because it's privacy infringing. OCSP sends the CA information about which subscriber certificates you relied on recently. Why were you relying on the certificate for Porn Hub? Exactly.
--
> If a countersigned certificate is revoked by one signer, is it still safe to use? I hope your answer is 'no'.
There's no such thing as a "countersigned certificate" in X.509 thus PKIX and the Web PKI. There can be multiple CA certificates with the same subject, which is what we call a "cross signed" CA.
There's no reason you should treat a certificate differently based on the existence of other certificates with the same subject which have been revoked, and indeed the software you use does not (on the whole) treat them differently. It's likely that you've used such trust chains especially if you're an American because a public CA (not Let's Encrypt) signed the Federal Bridge CA mistakenly at one point, which implicitly imports this huge hierarchy of other signature chains, some of which are revoked.
> Why did they including both certs in the chain if everyone trusts the same CA?
I guess you're talking about the existence of R3 signed by DST Root CA X3 and R3 signed by ISRG Root X1. But those aren't a chain, and so they aren't "including both certs in the chain". They're two certificates for the same entity, and so there are two completely different chains offered by Let's Encrypt.
For one thing, "revoking" a root CA isn't a thing, the root's signature is mostly a convenience (it's self-signed) and perhaps in another world roots would exist as distinct documents not as X509 certificates signed by themselves. So there isn't anybody to "revoke" it like other certificates. You can distrust them though.
In the real world lots of systems would never become aware of the revocation/ distrust at all, and there are gatekeepers for many other systems that could become aware (e.g your copy of Chrome or Firefox can learn that a root CA is no longer trusted but it would not do so without humans at Google or Mozilla deciding this was a necessary course of action).
It's necessary to the plot of Rainbows End that this happens unrealistically quickly, Rabbit must be disabled or it will certainly interfere with subsequent events, and it seems Vinge (unlike me) isn't sure exactly what Rabbit is, so this vague technical intervention seems like an effective way to stall Rabbit without thinking too hard about that question.