At 21:08 22/03/2017 Wednesday, Roland Shoemaker wrote: >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://www.ietf.org/mail-archive/web/acme/current/msg01747.html >* Only allowing a single valid authorization per name to exist at the >same time, summarized here: >https://www.ietf.org/mail-archive/web/acme/current/msg01661.html
i could see potential issues with the second one (for example name.example.tld is used in both https and smtp-tls, https server(reverse proxy) runs its own LE client and obtains a SAN for this and other https names smtp server(mx) runs its own LE client and obtains a different SAN for this and other names used in smtp-tls as both could be running in different parts of an org by different departments (behind the one NAT device) so i would be more in favor of possibly adding (despite the fact it will likely be a LOT more work) an exclusive(y/n) toggle to the name authorization system eg a client account can authorize a name exclusively or non-exclusively (to allow exclusivity for those with only one account, and non-exclusivity for those with other needs) but that said maybe im overthining >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://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
