2017-03-23 18:11 GMT+01:00 Zach Shepherd <[email protected]>: > 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 [email protected] https://www.ietf.org/mailman/listinfo/acme
