Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

[Chris Palmer <[e-mail]>]

On Fri, Oct 19, 2012 at 7:29 AM, Tom Ritter <[e-mail]> 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.