Subject: Re: [websec] HPKP: Storing unknown directives and effective pin date

From: Chris Palmer <[email-masked]>
Date: Thu, 6 Feb 2014 10:47:43 -0800

On Mon, Dec 2, 2013 at 12:45 AM, Brian Smith <[email-masked]> wrote:

> 1. Why must a UA store the effective pin date and the max-age
> directive, instead of storing just the calculated expiration time =
> effective pin date + max-age? I think that a UA can do a good enough
> job at making sure it uses the latest available pin data without
> needing to store the two separate items.

I have updated the I-D to address this:

https://code.google.com/p/key-pinning-draft/source/detail?spec=svnda615e6766479ac4ea69549ac56e4884b8169c07&r=da615e6766479ac4ea69549ac56e4884b8169c07

> 2. The requirement to store "future PKP header directives" seems to
> mean that a UA must store directives that it doesn't understand,
> presumably with the intention that it will process those stored
> directives if/when it starts understanding them. This requirement is
> unreasonable because it means that a UA may need to store huge HPKP
> headers full of directives that it will never process. This limits our
> options for efficiently encoding the stored information and also makes
> it unnecessarily difficult for us to calculate storage costs for this
> feature. In general, it seems to me that if it is safe for a UA to
> ignore a directive when it is first received, then it will be safe for
> the UA to ignore that directive until it receives a new HPKP header in
> some future response. If this is not the case, then I recommend
> changing the draft so that it would be safe. Regardless, I think the
> draft should be changed so that implementations are not required to
> store directives that they do not understand.

Agreed. And that change is here:

https://code.google.com/p/key-pinning-draft/source/detail?spec=svn68cf4ca5f25eeab48696561b999311b85cc6acb7&r=68cf4ca5f25eeab48696561b999311b85cc6acb7

I'll be pushing out a new I-D revision (10) in a few minutes with
these and other changes (no more strict, no more SHA-1).