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 <[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 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
