Re: [Anima] [Acme] Long-lived certificates, but frequently renewed certificates

[Michael Richardson <[e-mail]>]

Jacob Hoffman-Andrews <[e-mail]> wrote:
    > Roland Shoemaker sent a proposal a while back for ACME Renewal Info (ARI)
    > with the goal of solving both "impending revocation" and "expressing
    > suggested renewal times."
    > https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/. We
    > at Let's Encrypt hope to develop this idea further and implement it soon.

Ah, thank you for the reminder.
I was confused, because 20 Mar 2021 isn't here yet, but then I realized it
was 2020 :-)
I found the email via IMAP, and I see two replies.  One of them mine.
I didn't even remember thinking about this before.

Managing this through an OCSP infrastructure seems like it is probably the
right thing a Web Scale.

Within an Enterprise/Building/Residence, dealing with a (probably) private
CA, and with rather low energy networks... OCSP is a non-starter, I'd say.
In many cases, a session key (OSCORE) is derived from AKE and then kept for
months at a time.  No certificate operations are done at intervals frequent
enough for OCSP to be terribly useful.

{An example is a window smash sensor, that basically is primed "once",
and once the window is smased, it exhausts its battery.  Do we even care if
the certificate that was used for setup is expired?  Possibly not.  So maybe
this not a good example of a constrained device that cares}

So what I think I'd like is a signal that can be session layer multicast.
So it would be flood filled through unicast communications that happen to
already be occuring.   ("And they tell two friends, and so on, and so on...")
I think that a CRL fits within the constraints.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide