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

Carl Wallace <> Wed, 17 October 2012 18:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61EAF21F8681 for <>; Wed, 17 Oct 2012 11:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xxWs8BuAOlPd for <>; Wed, 17 Oct 2012 11:08:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6ABA721F84D3 for <>; Wed, 17 Oct 2012 11:08:13 -0700 (PDT)
Received: by with SMTP id fl11so9190008vcb.31 for <>; Wed, 17 Oct 2012 11:08:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=4d4OnzSVGCVR3eZbk2/lhlTv5TAZ6EsUdgN1zPupmvQ=; b=pOT6gOysRvb9X/chXbrAjZNzItLubu+PEjLfv5BRe+iRYPizwTG18P9qaB4e0W/1ni /KeDc6e3SmM0BAY5cAM233nfGtzOoDvHkMSikMsy3XOdHICcNv9ietiEo+EfIz6ZKH8m 3iaqOMsP8rM4vjYZkls1LRGQHleILC2GCVKhUWXePgij6Wcj/DEkg73FkIksknV7WHIQ +JuZwxTBeuzYFN9Wi3/8IvsC4wnQUn8CDS1GrS+0Jgeg/uIik2MQOYICkDL0Avux3uHe TSZZ3drGeH6vck+huSrPYnCiondGfNXs446uamQlFof4vF/J1Nz4MpHck5HSRoiTl3sQ Ievg==
Received: by with SMTP id r5mr8702986vdw.25.1350497286123; Wed, 17 Oct 2012 11:08:06 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id rx5sm1555363vec.11.2012. (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 11:08:05 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Wed, 17 Oct 2012 14:07:48 -0400
From: Carl Wallace <>
Message-ID: <>
Thread-Topic: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Gm-Message-State: ALoCoQmUX5h3MVqUpF+BAq7jPQ0SUOqf7pk3qHhBTOR0KQhJZn6QhIfT031PfxMUIo3T3e/k/pjl
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 18:08:14 -0000

On 10/17/12 1:52 PM, "Ryan Sleevi" <> wrote:

>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
>> >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
>>  needs to know where its certificate chains against public stuff and
>>  check that independently.  This should come close to relegating the
>>  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.

Why do you care what certificates exist vs. what certificates are
generally available (via AIAs and such)?  The certificates available from
most AIAs are constant for most people.  I'm not suggesting that a tool
would be a 100% solution, but it'd be a good first shot vs. collecting
data from some (manually run?) user tool after a problem is observed.

>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

There would be some homework to collect the full set of trust anchors that
may be encountered.  This shouldn't be that hard to maintain if a
collective effort focused on it.  It'd make no difference if the set used
to harvest public keys was too large.

>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.

What is a user report but a "point in time" evaluation?

>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

Monitoring is necessary to keep track of changes.  It sucks, but it's the
way it is.  

>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)

I don't doubt any of this, but still think a crawler tool would be
sufficient in many (if not most) cases.  It'd probably be instructive to
run for the site operators in the worst case.  Note, I did not suggest
that a user report feature was not a good or necessary thing, only that a
builder tool for the site operator to run without bothering any users
would be nice to have in the toolbox too.  Thinking about it, they may
well be the same tool if the user reporting tool is aggressive enough.