> Does anyone else feel strongly? Can we aim for consensus for > Monday?
Update four days later: one additional +1 for removal from Josh Soref. Are the maintainers comfortable merging https://github.com/ietf-wg-acme/acme/pull/244 ? On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <[email protected]> wrote: > > 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
