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

Tom Ritter <> Thu, 07 March 2013 02:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 68BF011E80F0 for <>; Wed, 6 Mar 2013 18:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.758
X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 27eKbbK4ZGKQ for <>; Wed, 6 Mar 2013 18:50:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7C01D11E80E9 for <>; Wed, 6 Mar 2013 18:50:03 -0800 (PST)
Received: by with SMTP id k1so5201917vck.38 for <>; Wed, 06 Mar 2013 18:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=mIBmUmv0dhob2r+sMikCHlDV0LTy+Dtj8lJsCu+Ei1OOAOY7zwPqmk5fdKastWnX+e VH29kkYU743iFO8c6ubYG/ddnTJEktOYumKhE9WnA9onR1DAiFABo2eON8cq5Qnv9c/E oU/I/O+MVmCvLkkYZNbzph94/TAYevBrM+oA8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=rkl1g/uAYPurfnExCgfNgYayecFKxhSoMXEBQ3YayAM=; b=ZmoZPfgGiEkr6aV5J4txbvXXc+wCUFSo1fhy4laYzuvbOaS7BHByNh35nFnJtiy5kE pT3zANmSe+ITIiW9stXCxQUdNGCpzqDFyDKIJUJFE7gwCEftbBzn9ecIVFVXBOufFYKW zAihIBWgbYclmYWHWcDSz7WcZql+6nqk1/jjIH1hjJAL05/jZ9MpOyILBbMwzJNOJl+u 7JIPif2/zUtxWpEad66S2j5VSUljFtm5vOPVqOH9bhNEImFW8/VsuknKYATTjfTDMsVS WmOdDN0xkoxrl8UqwpZt+wQUfiD+xubzYDSbkV0mm3NIroPj9GxtoJF4/96F/Znxe/Y9 aavQ==
X-Received: by with SMTP id v6mr12676910vem.45.1362624602766; Wed, 06 Mar 2013 18:50:02 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 6 Mar 2013 18:49:42 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Tom Ritter <>
Date: Wed, 6 Mar 2013 21:49:42 -0500
Message-ID: <>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlmJm2ApiED3Fh5Gb05AWIY/KC40r8GyX94EyA5pEODuhbnX1qHZ3KOUyIgHq+Q5lY1znD1
Subject: Re: [websec] Issue 55 - Key pinning should clarify that the newest pinning information takes precedence
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Mar 2013 02:50:04 -0000

On 6 March 2013 14:34, Ryan Sleevi <> 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.