John Gardiner Myers <[email protected]> wrote: > On 3/18/21 11:15 AM, Michael Richardson wrote: >> As far as I know, the only signal for when to renew is notAfter. >> Generally, one should renew sometimes after the half-way point. >> (LetsEncrypt policy of 90 days, but discouraged to renew until 60 days) >> >> It seems that a CA ought to be able to express some other kind of renewal >> period directly. Is there any work in this area?
> I would frame this in terms of impending revocation. Consider the case, as
> has happened in the past, where a CA discovers that there is a problem
with
> some or all of the previously issued certificates requiring the CA to
revoke
> said certificates within a few days. How can the ACME client managing
renewal
> learn from the CA of the need to renew prior to the revocation, so to
avoid a
> service interruption?
Would this signal occur at the time of issuance, or are you thinking that it
would occur some time into the validity period?
> I believe this problem is within the scope of the ACME WG's charter, but
> would require someone with CA experience to propose an ACME extension.
In the environments I are talking about, if ACME is involved, it is because
we have a Registrar managing the enrollment (and having access to do the
DNS-01 updates), as described in acme-integrations.
In some cases, the Registrar and the device might communicate using
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/
and so the Registrar can effectively (and asynchronously) push a new
certificate to devices.
In other cases, the Registrar is passive, and so we need to get the devices
to in effect, poll the Registrar frequently enough to be effective, but no so
frequently as to be annoying. We do not have, in RFC7030 or est-coaps, any
kind of clear "go away for a week" message.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
