This is a very good point. On Sat, Apr 16, 2016 at 5:30 AM, sheel.at <[email protected]> wrote:
> 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. > These sound like good recommendations to go in the account deletion section. Would you like to draft a PR? > 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... > Something like this? ``` POST /acme/reg/asdf HTTP/1.1 { "delete": { "revokeCerts": true } } ``` 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) > Oof, that is bothersome :) I think there are a couple of mitigations here, though: 1. The CA can allow revocation by a new account that's authorized for the names in the cert 3. The Baseline Requirements require CAs to revoke mis-issued certs, so even if ACME doesn't provide a mechanism, you should be able to use email/phone/fax/etc. On the other side, I can imagine scenarios where the flexibility about nuking would be valuable. Maybe I'm handing over a domain, and I don't want to make my servers stop working right away. One alternative you could consider would be to recommend allowing old account keys to do certificate revocation, just like for account deletion above. That has the disadvantage that you can't truly delete the registration resource, so I think I come away preferring to have a switch in the delete request. --Richard > > ... > 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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
