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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9826221F8673 for <>; Wed, 17 Oct 2012 10:52:55 -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 faD78Tgcad0X for <>; Wed, 17 Oct 2012 10:52:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9981D21F8639 for <>; Wed, 17 Oct 2012 10:52:54 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 21662350079; Wed, 17 Oct 2012 10:52:54 -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=ifqme3Jz6HQ5yh0nu9YljA0quoU=; b=KU0+gWDorHxER/zrM hRoz0T7zAWTvT9Xk8ljX3T3+WBnLovSindRS7CeiDH2H2Q+INa4minx1jbaiN5Qp KN8tJqGr9bIBO1LxhZAoFLiq31ortjst5x1XQOXDbNl3sGTWqAs5G/bO5Fc9eRTT t/JmwhVU5mwMvKjqFzS7x4U1ZQ=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 7FF75350058; Wed, 17 Oct 2012 10:52:53 -0700 (PDT)
Received: from (proxying for (SquirrelMail authenticated user by with HTTP; Wed, 17 Oct 2012 10:52:52 -0700
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Wed, 17 Oct 2012 10:52:52 -0700
From: Ryan Sleevi <>
To: Carl Wallace <>
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 17:52:55 -0000

On Wed, October 17, 2012 10:04 am, Carl Wallace wrote:
>  On 10/17/12 12:36 PM, "Ryan Sleevi" <> wrote:
> ><large snip>
> >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.
>  A tool that builds all possible paths that the site operator can run
>  without involving any users would be good too.  The site operator mainly
>  needs to know where its certificate chains against public stuff and could
>  check that independently.  This should come close to relegating the user
>  report tool to oddball instances.

The problem in general with such tools (and I'm sure this will be a
talking point during the WPKOPS and CERTTRANS BOFs) is that it's actually
a rather hard problem to know exactly what certificates exist.

Beyond the issues such as "What user agents have what behaviour" and "what
intermediates are baked into what platforms," one of the more problematic
areas is related to the AIA chasing that is functionally and fundamentally
necessary to maintain parity and access to a depressingly vast majority of

When the site operator installs their cert, they may only install on their
HTTPS server (Site_Cert, Intermediate). This is because CA_Bob and the
site operator are assuming that CA_Bob can be omitted, since it's the root
of trust.

For clients that don't trust CA_Bob, Intermediate has an AIA to a URL that
contains CA_Bob, which is cross-certified by CA_Alice.

So the possible chains are:
Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained
Site_Cert (via TLS) -> Intermediate (via TLS) -> CA_Bob (obtained via AIA)
-> CA_Alice (obtained out of band)

Now what if CA_Bob goes out of business/is acquired? Well, one common
trick is to update the URL of Intermediate to point to a new version,
signed by CA_Charles. When the path building for Intermediate (via TLS)
fails, user agents may "unwind" their depth search, and attempt the AIA
fetch from Site_Cert, leading to a new chain.

Site_Cert (via TLS) -> Intermediate (via AIA) -> CA_Charles (obtained

Or CA_Bob may decide they want to sever ties with CA_Alice, and go with
CA_Charlene. They simply replace the AIA URL used to serve up the
cross-certified CA_Bob.

This is all well and good for "point in time" evaluation - but the added
crux on this is that the site operator may be noticing all these
shenanigans, and now explicitly configure their server to send a
particular chain they believe is accurate/optimal. Also, clients may be
caching intermediates as well.

So it's "Very Hard" to actually know what *all* possible paths are,
because the possible paths change over time, and some paths may no longer
be knowable by such a tool when the certificate is being evaluated,
because the old certificates served at URL X are now replaced with newer

You may think I'm just grasping at edge cases, but unfortunately every
situation I just described above has been done by major CAs, including
some that might be considered of the "Too big too fail" variety. So it's
definitely an issue, and that's some from of client reporting seems
necessary (with transparency + disclosure to make it easier to write such
tools in the future)