Re: [websec] #56: Specify includeSubdomains directive for HPKP

"Ryan Sleevi" <> Sat, 08 December 2012 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26ABA21F859D for <>; Fri, 7 Dec 2012 21:58:11 -0800 (PST)
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 PTJMNmXKGQNX for <>; Fri, 7 Dec 2012 21:58:10 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5645721F854E for <>; Fri, 7 Dec 2012 21:58:10 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id C90536B0070; Fri, 7 Dec 2012 21:58:09 -0800 (PST)
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=jUH8krW3IcfPtbOG5u5iTk8Wt+c=; b=GRJsqQDYe26+hvsdg Vry6egr2yVeTflPV6LKuIfJBDXzmSCUJoh6QhceUEC47zJhJ78Ld7SQYtm7assgm +DQVaHK3Ctzu/WLUr2tuFgSkjL1xq57FhN/mMW+BzZj1fvj7hlJxK5SzV6O6f6+x cw0tOsdQt5i9WIm9ic0iiVr79Y=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 848506B0059; Fri, 7 Dec 2012 21:58:09 -0800 (PST)
Received: from (proxying for (SquirrelMail authenticated user by with HTTP; Fri, 7 Dec 2012 21:58:06 -0800
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 07 Dec 2012 21:58:06 -0800
From: Ryan Sleevi <>
To: Yoav Nir <>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [websec] #56: Specify includeSubdomains directive for HPKP
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: Sat, 08 Dec 2012 05:58:11 -0000

On Fri, December 7, 2012 2:17 pm, Yoav Nir wrote:
>  On Dec 7, 2012, at 11:31 PM, Chris Palmer <> wrote:
> > On Thu, Nov 8, 2012 at 2:01 PM, websec issue tracker
> > <> wrote:
> >
> >> #56: Specify includeSubdomains directive for HPKP
> >>
> >> Ticket URL: <>
> >
> > Do people agree that draft -04 resolves this issue?
>  Sort of. I see that includeSubdomains is included, but I couldn't find the
>  discussion about resolving conflicts between a superdomain (such as
> that has the includeSubdomain directive, and a subdomain (such
>  as that has a different key in its PKP directive. This
>  question is asked in the ticket.
>  I'm also not sure how that could ever work.  Suppose I go to,
>  and get the pin with the includeSubdomain directive.
>  Next, I go to, and the pin doesn't match the TLS handshake.
>  Wouldn't the UA immediately terminate the connection, with no opportunity
>  to ever receive any HTTP header? How will the more specific pin ever get
>  set?
>  Yoav

So, let's say the workflow is:
You first visit "" (or, through whatever U-A specific means
exist, you have a pre-loaded pin for "").
It has a PKP directive that asserts Pin(A) and Pin(B), along with
The validated cert chain contains Pin(A), so the PKP is accepted, and (and all of its subdomains through all levels) are set to
Pin(A) and Pin(B)

You now visit

IF is not valid for Pin(A), fail the connection. That is
the only acceptable path.

IF IS valid for Pin(A), it MAY assert a different pin.
Since, as noted above, it MUST be valid for Pin(A), the only possible
pinning that would be to Pin to a more narrow scope of
authority than A.

For example, assume that Pin(A) refers to a root cert/trust anchor. may wish to Pin(C), which is a specific subordinate CA
certificate beneath A - such as an OV CA, rather than a DV CA.

Further, may wish to assert includeSubdomains as well, and
all domains beneath should pin to Pin(C) instead.

This equally applies to the Enterprise PKI scenario, where you may have a
DNS hierarchy that reflects an organizational layout -
divisiona.mycorp.example and divisionb.mycorp.example. mycorp.example may
chain to the MyCorp trust anchor, but divisiona and divisionb may assert
pins to their respective Division A CA (which is cross-certified by the
MyCorp root) and Division B CA (which is cross-certified by the MyCorp
root). In this case, Division A CA will NOT be able to issue certificates
for any name under divisionb.mycorp.example

This latter case is a bit contrived, I admit - name constraints function
much better for the enterprise PKI case - but hopefully it demonstrates
how you can, at each level, further scope the trust anchors to the minimal
acceptable set.

You may have an PKP that asserts trust for 4 different,
distinct root CAs, but that subdomains individually limit to specific root
CAs (or specific intermediates - such as EV, DV, OV, or however the root
CA is configured)

Finally, it may simply be the case that an entity like "" wants
to assert a single pinning directive for ALL their subdomains - that is,
they do not care about restricting trust as much as simply being able to
have a single unified policy - and includeSubDomains (obtained dynamically
through the header or through a-priori crawling, much like HSTS has been
done) is one way to do that.

However, it sounds like all of this needs more clarification, so if the
description above matches peoples expectations, I'll work to draft text to
concisely explain these rules in the spec.