On Fri, Oct 19, 2012 at 7:29 AM, Tom Ritter <t...@ritter.vg> wrote: >>>>> > The UA MUST observe these conditions when noting a host: > > o The UA MUST note the pins if and only if it received the > Public-Key-Pins response header field over an error-free TLS > connection. If the host is a Pinned Host, this includes the > validation added in Section 2.4 > > o The UA MUST note the pins if and only if the TLS connection was > authenticated with a certificate chain containing at least one of > the SPKI structures indicated by at least one of the given > fingerprints. (See Section 2.4.) > > o The UA MUST note the pins if and only if the given set of pins > contains at least one pin that does NOT refer to an SPKI in the > certificate chain. (That is, the host must set a Backup Pin; see > Section 3.1.) > > If the Public-Key-Pins response header field does not meet all three > of these criteria, the UA MUST NOT note the host as a Pinned Host. > A Public-Key-Pins response header field that meets all these critera is > known as a Valid Pinning Header. > > The UAs MUST ignore Public-Key-Pins response header fields received on > connections that do not meet the first criteria. If the UA recives > a Public-Key-Pins header from a Pinned Host that meets the first > criteria, but not the following two, the UA MUST discard any previously > set Pinning Metadata for that host in its non-volatile store. > <<<<
Thanks again, Tom. I've adopted this in my copy. By the way, people can follow my copy here: https://code.google.com/p/key-pinning-draft >> (a) simply have the validity time be the same as for HSTS; >> (b) the same as HSTS but with a 30-day maximum; >> (c) the current attempt to mirror TACK, except clarified and with examples; >> or >> (d) something else. >> >> Of these, I think I currently like (b) best. Thoughts? > > I think A. I believe (without evidence) there are institutions that > would eventually like to use this that have customers that work with > them on a quarterly or annual basis. Likewise, I believe (without > evidence) that a institution who was risk adverse would mitigate that > risk by pinning to several large CA roots, not by saying "Oh well our > customers can't access us for the next 30 days, but it's only 30 days > who cares - but 60, that would be unacceptable!" Makes sense. Any other votes? > I do like TACK's notion of 'growing' out pins but only in a "That > sounds like a feature we're anticipating people wanting" way. If > people actually hold off on deploying this because of that and that > alone, it SHOULD be possible to add a new directive, ignored by older > browsers who don't implement it. Makes sense. > Public-Key-Pins: max-age=600; grow-to=86400; > pin-sha1="4n972HfV354KP560yw4uqe/baXc="; > > The spec should probably note that directives not understood should be > ignored, and not invalidate the header, to allow for future expansion. > Right? Yes. In fact Chrome's implementation does do that. I thought I had specified it in this I-D, but apparently not. I propose this parapgrah: <t>For forward compatibility, the UA MUST ignore any unrecognized Public-Key-Pins header directives, while still processing those directives it does recognize. <target xref="header-syntax" /> specifies the two directives max-age and pins, but future specifications and implementations might use additional directives.</t> at the end of the Noting Pins section. _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
