Re: [websec] Certificate Pinning via HSTS

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 13 September 2011 12:42 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9121F8841 for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 05:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlPOw-VCEUDy for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 05:42:26 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7540221F8B03 for <websec@ietf.org>; Tue, 13 Sep 2011 05:42:26 -0700 (PDT)
Received: from [192.168.13.75] (lair.fifthhorseman.net [216.254.116.241]) by che.mayfirst.org (Postfix) with ESMTPSA id 9B74AF970; Tue, 13 Sep 2011 08:44:28 -0400 (EDT)
Message-ID: <4E6F5056.800@fifthhorseman.net>
Date: Tue, 13 Sep 2011 08:45:10 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110807 Icedove/5.0
MIME-Version: 1.0
To: Chris Palmer <palmer@google.com>
References: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com>
In-Reply-To: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com>
X-Enigmail-Version: 1.2.1
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enigF91C2957B85ADD49AB4697C8"
Cc: Chris Evans <cevans@google.com>, websec@ietf.org
Subject: Re: [websec] Certificate Pinning via HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: websec@ietf.org
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 12:42:27 -0000

Thanks for publishing this spec, Chrises!

On 09/12/2011 05:56 PM, Chris Palmer wrote:

> (Sites can pin to one or more public keys in end entity, subordinate
> CA, and/or root CA certificates, for flexibility and disaster
> recovery.)


I think more discussion about the relative consequences of pinning EE
vs. intermediate CA vs. root CA certs would be useful.

From my perspective, i see no advantage to pinning any of the CAs -- if
your EE is compromised, you're sunk.  And since the mechanism provides a
mechanism (and nice instructions, thanks) for transition to an emergency
offline backup EE key+cert, that is all handled well.

What advantage would a site gain from pinning to an intermediate or root
CA?  It seems that all this would do is expose the site operators to
(limited, thankfully) extortion from the CA in question.

The only situation where i can see it being useful is to ease deployment
in a situation where the operating organization operates their own CA.
If this is the only circumstance where it is advisable to pin a CA cert
instead of an EE cert, that should probably be added to the
documentation explicitly.

Or is there some other circumstance that it would be actually useful
that  i'm missing?

	--dkg