[Plants] Untangling revocation for MTC

[Bas Westerbaan <[e-mail]>]

Hi all!

There are various proposals floating around how to improve revocation with
MTC. Not all of them try to achieve the same goals. I think there are three
independent goals we can untangle:

1. OCSP staple / Rob's MTC revocation status.
https://www.youtube.com/watch?v=278-zrCUGww&t=18740s
I don't think revocation is quite the right framing for this proposal. What
really happens is that certificates get ultra-short lifetimes (1 day,) but
a CA can *extend the lifetime of such a certificate a set number of times
cheaply* (without having to get new entries in the logs.) This makes
ultra-short-lived certificates easier on the transparency ecosystem,
although it's still extra work for the authenticating party and CA ACME
server.

2. *Revocation transparency*. Goal is to make CAs accountable for what they
revoked: any revocation must be transparent and revocations shouldn't be
able to be withdrawn secretly or hidden from certain users. This can be as
straightforward as a new leaf type that lists indices of newly revoked
entries.

3. *More efficient* *revocation* *checking*. CRL & OCSP continue to
function with MTC, but MTC allows them to be made more efficient as we have
sequential indices. This is more relevant for private PKIs. One example
here is to create a big bitmap of all non-expired entries in a log; split
that into chunks of 8000 and create a Merkle tree on top of that and have
the CA sign it. This then allows an OCSP style API that's very cheap to run.

All of these are good to think about.

Best,

 Bas