I'm supportive of removing the server pinning headers SHOULD outright. > but how best to word that i don't know
I don't think there's much benefit in the ACME spec discussing pinning from a client perspective. If the clients want to pin there isn't anything about ACME that makes the process different than (for e.g.) using square's okhttp library to pin for any other HTTPS server. Am I overlooking something? On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <[email protected]> wrote: > I would concur that clients should endeavour to support > > (and thusly CAs can consider using in future, when support is available in > wider librarys) > > but because of the risks they should only consider doing so > if/when all their processes are in place to ensure failures can't occur > > but how best to word that i don't know > > At 20:09 13/02/2017 Monday, Clint Wilson wrote: > >I would definitely support removing ", and servers SHOULD emit pinning > headers", especially because of the footgun risk you indicated, but I think > there is some merit in continuing to recommend support for HPKP on the > client side. > > > >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <<mailto: > [email protected]>[email protected]> wrote: > >Martin brought up a section I've been considering removing: > > > >> Clients SHOULD support HTTP public key pinning [RFC7469], and servers > >SHOULD emit pinning headers. > > > >Here's my reasoning: > > > >- Public key pinning isn't implemented in most HTTPS libraries outside > >of browsers, so this is a considerable burden on implementers. > >- Public key pinning carries a fairly high risk of footgunning. The > >consequence of a failed pin for a CA that serves many ACME clients would > >be that some of those clients would fail to renew their certs, causing > >cascading breakage. > >- There is relatively little confidential information conveyed in ACME, > >and there are other defenses built into ACME (like including the account > >key as part of the challenge data), so HPKP is not strongly necessary. > > > >Any objections? > > > >PR to remove: <https://github.com/ietf-wg-acme/acme/pull/244>https:// > github.com/ietf-wg-acme/acme/pull/244 > > > >_______________________________________________ > >Acme mailing list > ><mailto:[email protected]>[email protected] > >https://www.ietf.org/mailman/listinfo/acme > > > >_______________________________________________ > >Acme mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
