Hi Trevor The issue on the tracker is about the interaction of dynamic pins with pre-loaded pins. The authors have written section 2.7 to address this.
So let's bring back your points: * Preloaded pin stores will be periodically updated, which means browsers will need to handle "backdated" pins, i.e. pins that are received *after* other HPKP observations but have an "Effective Pin Date" which is earlier. To handle these in accordance with 2.7 requires browsers to remember "un-pinning" observations (expired pins, max-age=0, or nonexistent HPKP headers). This is sufficiently complex that the spec needs some treatment of it. * 2.7 mandates that the most recent observation from any source MUST take priority. Browsers would not be allowed to implement other priority rules, such as prioritizing one source over another, prioritizing fail-open or fail-closed behavior, or anything else. I believe this is overly restrictive. Some browsers might prefer different policies, e.g. simpler policies that don't require tracking "un-pinning" data. Section 2.7 is pasted below my sig. Yoav 2.7. Interactions With Preloaded Pin Lists UAs MAY choose to implement additional sources of pinning information, such as through built-in lists of pinning information. Such UAs SHOULD allow users to override such additional sources, including disabling them from consideration. UAs that support additional sources of pinning information MUST use the most recently observed pinning information when performing Pin Validation for a host. The most recently observed pinning information is determined based upon the most recent Effective Pin Date, as described in Section 2.3.2 . If the result of noting a Valid Pinning Header is to disable pinning for the host, such as through supplying a max-age directive with a value of 0, UAs MUST allow this new information to override any other pinning data. That is, a host must be able to un-pin itself, even in the presence of built-in Pins. Example: A UA may ship with a pre-configured list of Pins that are collected from past observations of Valid Pinning Headers supplied by hosts. In such a solution, the pre-configured list should track when the Valid Pinning Header was last observed, in order to permit site operators to later update the value by supplying a new Valid Pinning Header. Updates to such a pre-configured list should not update the Effective Pin Dates for each host unless the list vendor has actually observed a more recent header. This is to prevent situations where updating the Effective Pin Date on a pre-configured list of Pins may effectively extend the max-age beyond the site operator's stated policy. Example: A UA may ship with a pre-configured list of Pins that are collected through out-of-band means, such as direct contact with the site operator. In such a solution, the site operator accepts responsibility for keeping the configured Valid Pinning Header in sync with the vendor's list, allowing the UA vendor to have each update to the list be treated as as an update of the Effective Pin Date. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
