Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence

[Tom Ritter <[e-mail]>]

On 6 March 2013 14:34, Ryan Sleevi <[e-mail]> wrote:
> I think the real answer should be that preloading shouldn't be part of the
> spec, as it really is an implementation-specific behaviour. Certainly,
> it's based on our experiences in Chrome/Chromium, and it does provide an
> additional measure of security for the initial connection, but it doesn't
> really tie into the semantics of the header at all.
>
> Different applications - including such like Firefox - have already
> expressed interest in pursuing different schemes for preloading and the
> maintenance of such lists. Certainly, we've looked at alternatives
> ourselves. Our thinking is that we should avoid baking such behaviours
> into a spec, and instead focus solely on the header and observation
> aspects.
>
> Unlike the header - which is presumably provided to all user agents and
> uniform implementation expected - preloading is (at least, today) about a
> relationship between the site operator and individual user agents, so
> there's already a communication channel. If other implementations pursue
> different schemes - eg: such as crawling and noting pins - then they may
> have vastly different needs/requirements, but the overall semantics of the
> header itself remains the same.


Fair enough. I hope a browser will be willing to fiddle with their
preloading mechanism if it's found to cause pain, and I hope any site
owner would not put in preloaded pins with a browser that couldn't
amend them easily.

I'll only mention for consideration rewording the line to say "the
newest information available for the host":

UAs MUST use the newest information available for the host -- built-in
or set via Valid
   Pinning Header -- when performing Pin Validation.

This may guide things better without being overly restrictive.

-tom