bwesterb
commented
1 year ago Two answers for this
Let me add a few other options:
- When the browser sees a proof from the bad batch, it retries the handshake excluding the CA or with Merkle Certs disabled.
- We completely distrust the CA that screwed up. The CA can then get a new CA id and mint new certs.
You are discussing two different exclusions: excluding CAs from a set and excluding batches from a CA. I think the former is more worthwhile than the latter. Hopefully it's rare that we need to exclude single batches. It'll be much more common that someone wants to exclude a CA completely from a set.
davidben
https://github.com/davidben/merkle-tree-certs/issues/3 discusses how the negotiation scheme really believes in sets of TrustAnchors. That is, the BikeshedCertificate is identified by a TrustAnchor, say (issuer, 950), but the RP sends a single value that means (issuer, 901..1000).
Suppose some batch, (issuer, 975) went wrong. Because our sets have fixed width, we have to wait for the certificate lifetime to pass (i.e. the bad batch falls off the validity window) before RPs can accept anything from the CA again. Because even if the TS can tell the RP "trust (issuer, 901...1000) but skip (issuer, 975)", the RP can't tell the subscriber this. Over-advertising in the ClientHello risks the subscriber picking the bad batch.
Two answers for this:
The second could be interesting. What if we could send an exclusion list somehow? Either an explicit list of TrustAnchors, or some sort of hashing scheme. Structures, like CRLlite's Bloom filter cascade or perfect hashing describe a subset of a finite universe of inputs. If we can make that compact enough, that might be useful...
In particular, in a more traditional PKI mechanism, that would allow RPs to advertise supersets like "CCADB/2023-03-20" and then exclude the entries in there they don't trust.
Also, consider a distrust. Let's say I currently trust "roots-v1" which contains a bunch of CAs, {CA1, CA2, CA3, ...}, but now I need to distrust CA1. I can mint "roots-v2", but until the subscribers all get new alias lists from ACME, they won't understand it. The existing subscribers on CA2, CA3, etc., only know about "roots-v1". But if I advertise "roots-v1", the existing subscribers on CA1 will mistakenly believe their proof is still okay.