Re: [Acme] HPKP in ACME

[Alan Doherty <[e-mail]>]

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