[websec] Certificate Pinning via HSTS

Chris Palmer <palmer@google.com> Mon, 12 September 2011 21:55 UTC

Return-Path: <palmer@google.com>
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 D2D8C21F8E89 for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 14:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 twlAZOjpA+mK for <websec@ietfa.amsl.com>; Mon, 12 Sep 2011 14:55:00 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EEA3E21F8E88 for <websec@ietf.org>; Mon, 12 Sep 2011 14:54:59 -0700 (PDT)
Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p8CLuxIx008774 for <websec@ietf.org>; Mon, 12 Sep 2011 14:56:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315864619; bh=A7FUpMZNWhlhGHVyjmDWX7ReOUo=; h=MIME-Version:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=Sw5IQ7aREgnAKh28lVVFAx782oR7XVf3XRKF706BHEUMEQPc86m5+pvwigv83mGNR jBwQY8RB5tCmencREqfYQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:date:message-id:subject:from:to:cc: content-type:x-system-of-record; b=pkHDfJ1fMyIm5n1D1azl7hPAr3w3j6L0IIMb9yP0MdFtro/4ZhRufJhsmQ8/t3qCN VrKmupU/IBApnYH2Mb8LA==
Received: from wwf22 (wwf22.prod.google.com [10.241.242.86]) by wpaz17.hot.corp.google.com with ESMTP id p8CLucig012047 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <websec@ietf.org>; Mon, 12 Sep 2011 14:56:57 -0700
Received: by wwf22 with SMTP id 22so1979921wwf.1 for <websec@ietf.org>; Mon, 12 Sep 2011 14:56:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4RkjJt3YrBKO6SnIaaTJVjqGzPnjFrooQ6uZ37PxFb0=; b=tOiDEEjlgMlZN91Hu/urztxEcD9ceF5LwhoaantR2FZKgOQZjnYms/6FkK0DOcQWIC YaCa866eyOdh+ZYtJ6gg==
Received: by 10.216.23.72 with SMTP id u50mr700356weu.34.1315864617090; Mon, 12 Sep 2011 14:56:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.23.72 with SMTP id u50mr700345weu.34.1315864616436; Mon, 12 Sep 2011 14:56:56 -0700 (PDT)
Received: by 10.216.61.16 with HTTP; Mon, 12 Sep 2011 14:56:55 -0700 (PDT)
Date: Mon, 12 Sep 2011 14:56:56 -0700
Message-ID: <CAOuvq22p2qNnXRsK=PS=mxknnq4MrCWt0Np-N8su-iHXaWHqpg@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: websec@ietf.org
Content-Type: multipart/mixed; boundary=0016364d27f109070004acc59bdb
X-System-Of-Record: true
Cc: Chris Evans <cevans@google.com>
Subject: [websec] Certificate Pinning via HSTS
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Mon, 12 Sep 2011 21:55:00 -0000

Hi all,

Chris Evans and I work at Google on the Chrome security team. We have
devised this specification for a new extension to Strict Transport
Security to allow site operators to "pin" certificates: UAs will
require that TLS connections be validated with at least one of the
public keys identified in the new "pins" directive in the HSTS header.
(Sites can pin to one or more public keys in end entity, subordinate
CA, and/or root CA certificates, for flexibility and disaster
recovery.)

We hope that this mechanism opens up the benefits of certificate
pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
and certificate pins for sites, but the mechanism for doing this
(email us!) does not scale.

We eagerly anticipate your comments, questions, concerns, et c. As you
can see from the Ideas section, there are some unanswered questions
about the behavior of UAs and hosts, and possible extensions to the
policy.