I agree. I think that this non-strict behavior is something that UAs will implement anyway, because otherwise the UA doesn't work in any place that has a "next generation firewall" (which is pretty much any firewall these days)
And if they did stick to only strict behavior, pretty much none of the potential servers would use HPKP. I agree that this text represents a middle ground that allows both UAs and servers to deploy the protocol. so, +1. Yoav (with no hats, except maybe a next-generation firewall vendor hat) On May 28, 2013, at 2:35 PM, Tobias Gondrom <tobias.gond...@gondrom.org> wrote: > Hi Chris, > > I think so. (but am not 100% sure.) > Any other comments on this issue before we close it? > > Thanks, Tobias > > > On 25/05/13 02:41, websec issue tracker wrote: >> #53: Clarify status of pin validation when used with private trust anchors >> >> >> Comment (by pal...@google.com): >> >> The current draft has this text: >> >> 578 <t>If the connection has no errors, then the UA will determine >> whether to >> 579 apply a new, additional correctness check: Pin Validation. A UA >> SHOULD >> 580 perform Pin Validation whenever connecting to a Known Pinned Host, >> but MAY >> 581 allow Pin Validation to be disabled for Hosts according to local >> policy. For >> 582 example, a UA may disable Pin Validation for Pinned Hosts whose >> validated >> 583 certificate chain terminates at a user-defined trust anchor, rather >> than a >> 584 trust anchor built-in to the UA. However, if the Pinned Host Metadata >> 585 indicates that the Pinned Host is operating in "strict mode" (see >> 586 <xref target="strict"/>), then the UA MUST perform Pin >> Validation.</t> >> >> I believe this is the result of previous consensus. Is that correct, and >> can I therefore close this issue? >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
