The cert revocation flow specifically allows anyone holding a copy of the key and the cert to revoke the cert. Since certs are publicly available, this implies that holding a copy of the key does in fact convey ownership of the cert. There are also ACME servers (such as Sectigo's) that grant control over a domain to a key through means other than the standard challenge. Both of these together lead to thinking of ownership of the ACME account key implying full control of the certs.
-----Original Message----- From: Acme <[email protected]> On Behalf Of Matt Palmer Sent: Saturday, October 22, 2022 8:38 PM To: [email protected] Subject: Re: [Acme] Potential race condition attack via account pending order lists On Sat, Oct 22, 2022 at 05:48:35PM +0200, Sebastian Nielsen wrote: > I don't see any problem with it since: > 1: It requires possessing a account key with a valid authorization for > the domain in question. > In my eyes, one that posess such a key IS the valid domain owner. That is an extremely odd way of looking at the situation. An account key authorizes operations against an ACME endpoint, it doesn't express (or imply) ownership or control of anything else. A more reasonable position might be that someone who has allowed their ACME account private key to become available to a miscreant has foregone all expectation of protection from any form of attack. A counterpoint to that could be that, at present, possession of an ACME account private key, by itself, allows certain attack vectors (such as denial of service, due to allowing certificate or account revocation requests). However it does not allow (as far as I can determine) straightforward issuance of certificates to an attacker (again, an attacker who *only* has the account private key). To that extent, standardising and implementing a new feature in ACME that suddenly *does* allow that attack to be mounted is a change to the risk profile for the security of the account private key. Someone who setup the protections for their private key in the expectation that it could "only" be used for certain attacks may be somewhat dismayed to discover that it can now be used for a wider range of attacks. > If you can't keep your account key secret, what says you can keep your > certificate keys secret? This is a false equivalence. An account key is a long-lived credential that must remain available and unchanged for an extended period, potentially across multiple devices/services, whereas a certificate key can (and usually does) rotate every few months (or even more frequently) as certificates are re-issued. > 2: A domain whose account key has leaked out, is already compromised > in some way or another. > For example, you could hack into the ACME client server and steal the > key, and then place a trojan which transmits the order ID to you under > the current regime. Sure, but compromise of the ACME client endpoint is far from the only way that an account key could become available to a miscreant. I discover, on average, about three to four Let's Encrypt account keys per week via the operation of pwnedkeys.com, and I can assure you that the methodology used does not include compromising anyone's servers. > Adding a order list still needs you to somehow listen on the victim to > time the attack correctly. > > The only victims that this attack will work on, is victims that let an > authorized order stay for days rather than finalizing it immediately. Days? I think you understate the probabilities rather significantly. - Matt _______________________________________________ Acme mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!OToaGQ!vhh0A8Rg-eJB_lj-OiugguGy5fIhYemXDTTryWxYZ2SZ1m1Se-Qc4a4mG-Al5L_zTJObBfJA2kC_Skc$ _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
