On Mar 28, 2022, at 8:56 AM, Michael Richardson <[email protected]> wrote: > I understand. > For mechanisms like BRSKI (and CSP/MATTER, and probably UPC UA) where the end > product of onboarding is a certificate issued to the device, then the > question about when to refresh is mostly given by the notAfter parameter. > In most cases one should start refreshing those credentials at the 50% mark. > > The ACME WG is discussing having the certificate renew point be better > specified (in the ACME protocol), but I think that we will learn from this > and wind up with something in the certificate if the protocol can't carry > additional meta-data.
That's a good chunk of what I'm proposing in my document. There are often existing cert fields which contain the information needed for configuration. It would be nice to use them. > There are advantages of having renewals spread across time, but there are > also disadvantages as it spreads the failure signal across time as well which > makes it harder to see that there is a real problem. Generally if people can't renew, the server should log errors, or the end user device has a real network where it can report errors. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
