On 6 March 2013 14:34, Ryan Sleevi <[email protected]> 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
