Hi all,
So, I’ve read the draft a couple of times recently and am happy to review. Generally I think the technical content is sound and effectively does what it says it’s trying to do. I also think it’s clearly explained and easy to follow.
I do have two comments that I’d like to make (apologies if I’m a little late to the party on some of this).
Firstly, I’m not sure I buy the argument in the intro about changing certificate lifetimes and renewing at issuedcert.not_after – x. From my experience the most recent couple of changes to certificate lifetimes made via root store policy changes have only affected certs issued after a date in the future and not certs that have already been issued. If a subscriber gets a new cert a week before their current one expires then that approach would continue to work even if the lifetime of new certs was changed. I’ll admit though that it’s less resistant to changes of certificate lifetimes than renewing x% through the lifetime of the current cert.
That being said, I wonder if a second justification for ARI might be scheduled revocation (which is a change of the certificate lifetime but would cause problems for all three of the use cases in the intro so I assume it was validity periods mentioned there). The new Mozilla Root Store Policy changes included a requirement for cascading revocation (even between subscribers) in one of the keyCompromise use cases. I wonder if ARI might be useful in the situation where customer a has revoked for keyCompromise with proof-of-possession and then customer b using the same key can be notified that they need a new certificate within the next 24 hours. Happy to try and write something if it would help.
Secondly, I think the key words around client action and the suggested renewal window are a bit inconsistent. If the renewal window is in the future then one MUST uniformly pick a random time in the window to renew but if you’ve already missed it then the guidance is you SHOULD attempt to renew immediately. Then if the window is before you’d poll ARI again then you MAY attempt to renew immediately.
I don’t mind the latter two as much but I wonder if the “MUST” is a little strong and if it would be better to downgrade it to a “SHOULD” or to “It is RECOMMENDED that conforming clients select a uniform random…”. In this I’m mainly considering the case where checking ARI is integrated into a notification system that tells a person to renew the cert using their ACME client rather than when the entire thing is automated. Again, can open a PR for this if there is agreement.
Best Regards, Rob
From: Acme <[email protected]> on behalf of Sipos, Brian J. <[email protected]>
All, I haven’t seen any reviews of the last draft version -09. I hope that the closer alignment with RFC 8823 makes its understanding and analysis easier.
From: Acme <[email protected]> On Behalf Of Deb Cooley
Did we ever get reviews on the updated draft? If not, can we get some (or revive the) volunteers?
Deb Cooley
On Mon, Mar 21, 2022 at 7:12 AM Deb Cooley <[email protected]> wrote:
|
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
