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
