I am in favor of removing the SHOUL for HPKP. As I said in my WG Last Call comments, I support a SHOULD for OCSP stapling.
Russ > On Feb 21, 2017, at 10:04 AM, Daniel McCarney <c...@letsencrypt.org> wrote: > > > 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 > <https://github.com/ietf-wg-acme/acme/pull/244> ? > > > On Fri, Feb 17, 2017 at 12:28 PM, Daniel McCarney <c...@letsencrypt.org > <mailto:c...@letsencrypt.org>> wrote: > > Perhaps we could downgrade to MAY WISH TO > > https://tools.ietf.org/html/rfc6919#section-6 > > <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 <r...@ipv.sx > <mailto:r...@ipv.sx>> wrote: > > > On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney <c...@letsencrypt.org > <mailto:c...@letsencrypt.org>> 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 > <https://tools.ietf.org/html/rfc6919#section-6> > > > > > > > On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty <i...@alandoherty.net > <mailto:i...@alandoherty.net>> 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:j...@eff.org > ><mailto:j...@eff.org>>j...@eff.org <mailto:j...@eff.org>> 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>>https://github.com/ietf-wg-acme/acme/pull/244 > > <https://github.com/ietf-wg-acme/acme/pull/244> > > > >_______________________________________________ > >Acme mailing list > ><mailto:Acme@ietf.org <mailto:Acme@ietf.org>>Acme@ietf.org > ><mailto:Acme@ietf.org> > >https://www.ietf.org/mailman/listinfo/acme > ><https://www.ietf.org/mailman/listinfo/acme> > > > >_______________________________________________ > >Acme mailing list > >Acme@ietf.org <mailto:Acme@ietf.org> > >https://www.ietf.org/mailman/listinfo/acme > ><https://www.ietf.org/mailman/listinfo/acme> > > _______________________________________________ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > > _______________________________________________ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme> > > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
