I think Zach raises a really interesting point, and I think Niklas' response is spot on. To rephrase it a bit: If ACME allowed "any" hostname on a cert to revoke it, a multi-SAN certificate could be revoked by the owner of any domain name on that certificate.
That would effectively prevent hosting providers and CDNs from using multi-SAN certificates with ACME, because it would allow one customer to revoke a certificate in active use by other customers. In theory this problem could be solved by using only single-SAN certificates, but since several hosting providers and CDNs are already using ACME successfully in a multi-SAN use case, that would be a step backwards. Probably it's best to just document this as an issue: An attacker who compromises a web server can request a cert for that web server's hostname, plus an attacker-controlled hostname, preventing automated revocation. In that case, the owner of the web server will need to rely on the CA's certificate problem reporting system to get the certificate revoked. Not ideal, but I don't see a lot of other choices. On 03/23/2017 11:04 AM, Niklas Keller wrote: > 2017-03-23 18:11 GMT+01:00 Zach Shepherd <shephe...@vmware.com > <mailto:shephe...@vmware.com>>: > > Section 7.6, Certificate Revocation, states: "Before revoking a > certificate, the server MUST verify that the key used to sign the > request is authorized to revoke the certificate. The server SHOULD > consider at least the following accounts authorized for a given > certificate: ... an account that holds authorizations for all of > the identifiers in the certificate." > > One way to address this issue would be to replace "all" with > "any". That is, allow an account holding authorization for an > identifier to revoke any certificate issued for that identifier, > even if the certificate is also valid for other identifiers. > > Conceptually, I think this makes sense: the purpose of challenges > is to verify that the an account is authorized for an identifier > only if the account holder is in control of the identifier, and if > the account holder is in control of the identifier, they should be > able to revoke certificates issued for that identifier. > > This does, obviously, have consequences on the security model: > * Currently, an attacker which gains control of an identifier is > able to create or revoke certificates issued for only that > identifier. With this change, they would also be able to revoke > multi-identifier certificates which include the identifier they > have gained control of. > * This successfully reduces the impact of account key compromise; > if an attacker gains control of an account key, any certificates > they create can be revoked. > * This also addresses an additional issue: if an identifier > changes ownership, the new owner can revoke existing certificates > for that identifier, including multi-identifier certificates. > > This would, essentially, be prioritizing confidentiality of each > identifier over availability of all identifiers on a > multi-identifier certificate. By creating a multi-identifier > certificate, users would be "opting in" to this trade-off. To me, > this seems like a reasonable trade-off (especially because > compromise of an identifier is already catastrophic), but perhaps > there are use cases for multi-identifier certificates that I'm not > considering. > > This seems to have minimal impact on the protocol as well as both > client and server implementations. > > Regards, > > Zach Shepherd > > > This might be problematic for services like Cloudflare which use one > certificate for multiple customers. One of them might authorize for > their own domain as well and could then revoke the Cloudflare > certificate, affecting multiple customers. > > On the other hand, requiring all identifiers to be authorized could > result in an attacker with a compromised key to request a certificate > with additional SANs which the original owner doesn't have any control > of, then it's impossible for the original owner to revoke these. > > Regards, Niklas > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
