Revocation for certificates with multiple names

The documentation on revoking certificates says

If someone issued a certificate after compromising your host or your DNS, you’ll want to revoke that certificate once you regain control. In order to revoke the certificate, Let’s Encrypt will need to ensure that you control the domain names in that certificate (otherwise people could revoke each other’s certificates without permission)!

Shouldn't control of only one name be sufficient? If someone is able to get a certificate for both mydomain.com and evil.com, I would be unable to have it revoked, since I only control mydomain.com.

When having a certificate issued, proof of control over every domain name covered by that certificate is required. If someone legitimately loses control over one of those domain names, they now have a certificate for a domain name they don't control. My thought is that if someone can't have a certificate re-issued, that certificate should be able to be revoked, so I agree with you.

Revoking using the private key should be possible any time IIRC?

How would you have the private key that was issued to someone else?

I also agree: One bad apple should spoil the whole bunch!

I was thinking about the compromised host situation, assuming the private key would perhaps also be stored on said compromised host.

Just to offer a counter argument, certificates with multiple SANs are also used by hosting providers. Allowing a single domain owner to revoke such a certificate would deny service to the other domains.

Of course a hosting provider could renew the certificate before the old certificate's revocation was published or use a single domain per certificate.

This is a topic we have discussed many times internally. We agree that it would simplify many things if only control of a single identifier was required for revocation. But as mentioned above, it would also open the door to a denial-of-service attack against customers of providers that use agglomerated certs.

We had plans to address exactly this issue this year, but those plans were displaced by faster timelines for post-quantum Merkle tree certificates. Hopefully we'll have time to return to solving this problem next year.