[Plants] Re: Untangling revocation for MTC

[Ilari Liusvaara <[e-mail]>]

On Thu, Oct 01, 2026 at 10:35:55AM -0400, David Benjamin wrote:
> 
> That means, in our quest to decrease the revocation upper bound, we need to
> start by asking what is the limiting factor. Is it the authenticating
> party's ability to get a new blob, or is it the PKI infrastructure's
> ability to refresh the blob?
> 
> If the limiting factor is the PKI infrastructure, then it makes sense to
> think about different constructions, and to think about how to deploy
> those. Rob's idea here is pretty neat!
> 
> But if the limiting factor is the authenticating parties, we're not going
> to get anything out of changing the construction. We need to work on things
> like automated certificate renewal, their deployment in practice, etc.,
> until all authenticating parties can meet our target update frequency.

Automated certificate renewal seems like worst case in failure
probability.


> For the applications I'm most connected to (the Web), I think we're much
> more limited by the second right now. That's not to say there isn't benefit
> to thinking about the first one. But I think it means they're much more
> forward-looking for these applications.

I would think the bottleneck is generating the blobs and transporting
those to APs. But that might just be me projecting.

That is, for thing to work:

- PKI infra must generate the blobs in time. While that sounds simple,
  it is not trivial during various kinds of incidents. Especially
  certificate renewal.

- The APs must fetch the blobs in time. And while this also sounds
  simple, there are plenty of failure modes that cause problems reaching
  PKI infra without totally destroying connectivity. Or the PKI infra
  serving the blobs might be down.

  And doing high rate refresh also takes different architecture than
  medium/low rate refresh. E.g., cron (or systemd timer units) does
  not really work.




-Ilari