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
