Re: [websec] I-D Action: draft-ietf-websec-key-pinning-12.txt

[Chris Palmer <[e-mail]>]

On Mon, May 19, 2014 at 11:28 PM, Trevor Perrin <[e-mail]> wrote:

>> PKP vs. PKP-RO:
>> https://code.google.com/p/key-pinning-draft/source/detail?r=994a00dc31bf2cca6f3edea29871a6a4f18090f9
>
> The new text about PKP-RO in 2.5 (quoted below) seems to say that a
> PKP-RO header is only evaluated against the current connection, not
> stored as a pin.  I thought we decided the opposite (which is what I
> think 2.3.2 is saying):
>
> 2.3.2 (existing text):
>   If a Host sets both the Public-Key-Pins header and the Public-Key-
>    Pins-Report-Only header, the UA MUST note and enforce Pin Validation
>    as specified by the Public-Key-Pins header, and SHOULD note the Pins
>    and directives given in the Public-Key-Pins-Report-Only header.

Most recent text
(https://tools.ietf.org/html/draft-ietf-websec-key-pinning-14#section-2.3.2)
FWIW:

"""
   If a Host sets both the PKP header and the PKP-RO header, the UA MUST
   note and enforce Pin Validation as specified by the PKP header, and
   SHOULD note the Pins and directives given in the PKP-RO header.  If
   the UA does note the Pins and directives in the PKP-RO header it
   SHOULD evaluate the specified policy and SHOULD report any would-be
   Pin Validation failures that would occur if the report-only policy
   were enforced.
"""

So, the bug is still present. I will change "note" to "process",
indicating that the UA need not store anything about the PKP-RO
header. Indeed its purpose is ephemeral, and I don't see any reason to
store anything, *except for the purpose of determining that it has
already sent a report for a given policy*. I'll add some text to that
effect.

> 2.5 (new text):
>     The UA SHOULD NOT note any pins or other policy expressed in the PKP-
>     RO response header field.

I'll add the text in this section.

Here's the change:

https://code.google.com/p/key-pinning-draft/source/detail?r=fed01d71c5012137c2fb483b0ccad21b83b5888b