> Perhaps we could downgrade to MAY WISH TO > https://tools.ietf.org/html/rfc6919#section-6
This feels a little wishy-washy for something I think we could tie-break without too much delay. Jacob, Clint, and myself all stated support for removing it. You're OK with dropping it. I think Alan is in a similar mid-point camp. (Please weigh in if I'm mis-characterizing) Does anyone else feel strongly? Can we aim for consensus for Monday? On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes <[email protected]> wrote: > > > On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <[email protected]> > wrote: > >> 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? >> > > There's nothing different. The idea here was just to point people to some > mechanisms they could use to guard against mis-issuance. I'm OK dropping > it if people don't like it, but I would kind of like to keep it. > > Perhaps we could downgrade to MAY WISH TO > https://tools.ietf.org/html/rfc6919#section-6 > > > > > >> >> >> 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 >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
