Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

"Ryan Sleevi" <> Wed, 17 October 2012 16:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 760EB21F86A3 for <>; Wed, 17 Oct 2012 09:36:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iG2cMhnMmzeV for <>; Wed, 17 Oct 2012 09:36:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CC9A21F8698 for <>; Wed, 17 Oct 2012 09:36:45 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 0E3121F0084; Wed, 17 Oct 2012 09:36:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s=; bh=DaQqwk//p0+0mpUWcQpmHO2r6Oo=; b=qrs0dZLp389bcjrs3 s0GXdRZE7Y03XcDlZdmYNvryQdyMMNiG9MEP33iDFezJSay+1+53zZKIpuiGg4GV yH4M5L9RxTARCkW9BvaDpnMMZaU4Iijmhc7yUU61iXJJIupIrQiqNL3pbJMKVWc1 877229tOkYlH8WQHYgtW0x+QUA=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id ABEA91F001E; Wed, 17 Oct 2012 09:36:44 -0700 (PDT)
Received: from (proxying for (SquirrelMail authenticated user by with HTTP; Wed, 17 Oct 2012 09:36:43 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 17 Oct 2012 09:36:43 -0700
From: Ryan Sleevi <>
To: Tom Ritter <>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IETF WebSec WG <>
Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
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: Wed, 17 Oct 2012 16:36:46 -0000

On Wed, October 17, 2012 7:23 am, Tom Ritter wrote:
>  Section 2.4: "Validating Pinned Connections":
>     For the purposes of Pin Validation, the UA MUST ignore
>     certificates who SPKI cannot be taken in isolation and superfluous
>     certificates in the chain that do not form part of the validating
>     chain.
>  I know I just modified this, but the second phrase just hit me.
>  Because path construction is non-standard, could a client wind up in a
>  situation where the site pinned to CA_Alice, with the intended path
>  CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
>  trusted, the ultimate validating chain was simply CA_Bob ->
>  Intermediate -> Leaf?  I'm not sure what the right way to counteract
>  that would be...

Yes. This is one of the troubling areas of the current draft, and that has
been particularly challenging when implementing within Chromium.

It's not clear whether your case was demonstrative of the
inter-organizational cross-signing relationships (a new CA getting
cross-certified by an existing, established CA) or whether it was an
intra-organizational relationship, such as a SHA-1 root cross-signing the
SHA-2 root, until such a time as the SHA-2 root is included in the trust

In the case of inter-organizational, where CA_Alice and CA_Bob are two
distinct entities, it's generally seen as unlikely that the "site" would
pin to CA_Alice, since their business relationship is almost certainly
with CA_Bob (by virtue of CA_Bob having certified Intermediate). So if the
site were to pin to CA_Bob, their issue would be mitigated.

However, for the intra-organizational scenario, where intermediates and
roots are changed or re-issued more commonly than site operators may
realized or be re-configuring, I agree that this is a very real problem.

The mitigation for this has been to make the pins an appropriate
cross-section of both root and intermediates - intermediates in the event
of new roots being issued, and roots in the event of the CA issuing new
intermediates (and serving them up via AIA, as the common case is)

This leaves the broader question of "How does the site operator know about
CA_Alice and CA_Bob to begin with". One possible solution for this is a
report-but-unenforced mode, where user agents could describe their
observed chains to the site. As unseemly as this is, it's very likely that
many site operators - even Very Large, High Value sites - may not have a
full understanding of the PKI that they're a participant in.

Another solution is to rely on policy changes in root stores, such as
Mozilla's recent proposed CA Certificate Store requirements change, which
would encourage (by requiring, with only one acceptable alternative) the
public disclosure of such CA hierarchies. As a result of such changes,
there would be knowledge of the relationship between CA_Alice and CA_Bob,
which under today's model, is actually quite hard for site operators to

Because pinning permits multiple entries, and is considered satisfied so
long as at least one SPKI appears in the client validated chain, the issue
here is largely not a technical challenge, but an operational one, and
that's why this issue is not critical, but remains very important.