I didn’t know about the blocklist via “keyCompromise” . That’s a great extension to the RFC, and let’s me handle that.
I actually already know that is mandated by ACME! Section 11.1 - https://tools.ietf.org/html/rfc8555#section-11.1
Note that given the requirements of Section 7.3.1, servers will not create accounts with reused keys anyway.
Because ACME accounts are uniquely identified by their account key pair (see Section 7.3.1), the server MUST not allow account key pair reuse across multiple accounts.
So it seems marking an AccountKey as compromised must still be done by alerting the LetsEncrypt service, though a rollover or deactivation would have the same effect of blacklisting it - though it wouldn’t necessarily revoke any outstanding certificates. (I am assuming that my client will not necessarily know of every action tied to a given AccountKey that may require revocation, cleanup, etc).
Sorry for being overly pedantic about this. I designed my client before rollovers were possible, so the
AccountKey is embedded into the
Account in my object model. I’m decoupling it into two discrete objects right now, and have spent the morning sketching out what the interplay of rollover vs deactivation is.