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 ________________________________ From: Acme <[email protected]> on behalf of Roland Shoemaker <[email protected]> Sent: Wednesday, March 22, 2017 2:08 PM To: [email protected]; Salz, Rich; Ted Hardie Subject: [Acme] Possible IETF meeting agenda item: reducing effects of key-compromise Internally at LE we have been having discussions around how the spec can most effectively reduce the harm of account key compromise and it seems like it could be a good topic to bring up at the upcoming IETF meeting. We've come up with two distinct but not mutually exclusive ideas on this topic: * Deactivating authorizations on key roll-over, summarized here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_acme_current_msg01747.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=iGd1H6LLa6yZ1eailcLMJAatf_sYvR9g1BIAcBmsQig&e= * Only allowing a single valid authorization per name to exist at the same time, summarized here: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_acme_current_msg01661.html&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=UbH6UN-99PK6TbADeVA6J3Yvf72wYVyKd7NoK5IKNEk&e= Both of these proposals would be relatively large changes to the current follow and introduce certain issues for both individual users and large service integrators and could definitely use some public discussion before the spec is finalized. It would also be good to hear if there are any other thoughts from other implementors/contributors as to how we can best reduce the damage done by key compromise in general. -- Roland Bracewell Shoemaker Software Engineer Linux Foundation / Internet Security Research Group _______________________________________________ Acme mailing list [email protected] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwICAg&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=BmiI-FcQEZIzAmQ9cl9VVp_QYsKukJB0PtSfizZuYdY&s=DIKow_UF52PW12xZNcT5yhSFtlsjhnjM4W1wNPgMOvc&e=
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
