> On 13 Feb 2017, at 19:33, 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?
I was the person who initially suggested adding HPKP, that was more than two years ago. People get HPKP headers wrong constantly and thus lock themselves or their users out of services, missing library support is - as you point out - a problem and I don't see much interest within the community to add HPKP. By now I consider HPKP failed tech. to be honest. +1 on removing the section entirely. Aaron > > PR to remove: https://github.com/ietf-wg-acme/acme/pull/244 > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
