Suppose an account key gets compromised. To prevent abuse, the owner can delete the account: https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account However, people having the key can simply change it without any effort: https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over
What happens if the attacker does so before the owner can react, or even before the owner notices anything of the breach? I suggest changing tha specs (and implementation) to keep old keys after changes for while. More specifically: * When an account key is rolled over, the old key is kept for eg. 30 days. * Multiple changes within this 30 days mean that there are multiple old keys. * Account deletion is possible with any of the saved keys, be it old or new. * Everything else (other than account deletion) only accepts the new (newest) key. Related: The owner has no possibiliy to revoke certificates issued by the attacker. For proper uses, nuking all certs when deleting the account might be not what the users like, but for the attack scenarion... Related 2 (yeah, it's getting bothersome) If there is an "optional" certificate nuking when deleting accounts, the attacker could issue certificates and then delete the accountwithout destroying the certificates(the attacker!), to prevent the real owner from destroying the certificates. Meaning, a "partially" deleted account has to stay around for ... as long as there are non-expired certificates?, just for the possibility that someone wants to delete the rest too. (But without being useful for anything else other than deleting) ... I'm rather new to the Let'sEncrypt internals, so if I missed the fact that there is a solution already, please forgive me. Otherwise, sorry, I know spec'ing and implementing this would be annoying. But without this, the possibility for deleting an account key is not particularly useful. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
