Re: [websec] [saag] Pinning

Tom Ritter <> Sat, 11 August 2012 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E29821F859B for <>; Sat, 11 Aug 2012 13:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CA+Qv671c3Kh for <>; Sat, 11 Aug 2012 13:57:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 66FD921F8599 for <>; Sat, 11 Aug 2012 13:57:59 -0700 (PDT)
Received: by vcbfo14 with SMTP id fo14so2785348vcb.31 for <>; Sat, 11 Aug 2012 13:57:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=U9B6V74B8WleZyW7SFp/ryISkli0NUZBnDYjuoGeEFM=; b=G3qKMup5qswfPRMEFL+JvdxHnijOXZejvoymp5+zMlFtFBAswA5YvGfruYWaop6/6w F3/uttQtvPbCgOlivZ0ahMUvKrKJwaSycqx089MhOIHrj3Mx2RBFQNU3ox+P2CUSKfTC o1nOIN/1X22rT7CZqBu2gI1G6LpzQXa6ZX2Lg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=U9B6V74B8WleZyW7SFp/ryISkli0NUZBnDYjuoGeEFM=; b=GTuamsa3DYONqGotbhHanZw/8BptYxcGQkLYGxX5DK66neaIWZduS3HIjHkBcqwVcY KVIUUgmRbp3ZS+KPoKSgSWO5/i2Y3IareJNIDEUotDxmxCiCuC2VKFkfemnqPN7dDG1x NxiIxiYXd1JKsesEO37PuDg37RHK519GfCUC9f6V6df2s9koZKUZ3tUgIdNruf0YCdnJ SfhHCyge5ewD0ZS9k1EHprBiwzSfXqufDNDixgkXkcT344sXnL2OgXnMzHeL0KFKGoHF zo1n53bsFg021Kt6nMWs1F4sen3GKUWHkCHynhpvmKEqzxfX4Fiqp7azdbp52HhC4GSp OluA==
Received: by with SMTP id ig17mr1897253vcb.15.1344718678513; Sat, 11 Aug 2012 13:57:58 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 11 Aug 2012 13:57:38 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Tom Ritter <>
Date: Sat, 11 Aug 2012 16:57:38 -0400
Message-ID: <>
To: Yoav Nir <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlfpSCGRuQTm/Cdoc/Zdeq5qK1JJKGtRhxfNOHKqruovRhOQ6RPXmDOxYdBF5xboribBjrr
Cc: Chris Evans <>, IETF WebSec WG <>, Paul Hoffman <>, Sean Turner <>, Moxie Marlinspike <>
Subject: Re: [websec] [saag] Pinning
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, 11 Aug 2012 20:58:00 -0000

I don't know IETF procedure for making changes, but one of the
outstanding issues I don't think has been resolved with
draft-ietf-websec-key-pinning-02 is inherited DSA parameters.  I
raised this issue here: with
suggested verbiage.


On 11 August 2012 16:37, Yoav Nir <> wrote:
> Hi Chris
> I've removed SAAG from CC, trimmed most of your message, and re-arranged the rest. Hope you don't mind…
> On Aug 11, 2012, at 1:20 AM, Chris Palmer wrote:
>> Additionally, HPKP and TACK might converge, more or less. I have plans
>> to publish a new HPKP I-D that borrows some of TACK's pin activation
>> and expiration ideas, for example.
> <hat type="chair">
> Just as a reminder, HPKP is now a working group draft. As such, change control is with the WG. Changes that change the rules for activation and expiration should be proposed and discussed on the list first.
> Having said that, we are pretty far from last call on key-pinning, so I think it would be OK to publish a version -03 with such proposed changes, as long as those changes are clearly marked as not being the result of WG consensus.
> </hat>
> As an individual, I understand the limitations of the "spare public key" approach of the current HPKP. It's an administrative hassle to generate n spare keys and keep them safe, and if you have n+1 key compromise events within the max-age time, your site is blocked. But it does have the big advantage that the server side can be deployed *now* with no additional software. Until I see how those borrowed ideas can help with these issues, I prefer HPKP.
>> So ultimately I do think we should decide on either HPKP or TACK, but
>> that we should make that decision after there has been some real-world
>> deployment experience with both (or, sadly, real-world non-deployment
>> of one or both).
> Well, there's WG deciding, and there's the market deciding. The IETF can publish both approaches (as either proposed standard or experimental) and the one (if any) that the market prefers can later be upgraded to standard (or it can stay at proposed anyway)
> Yoav
> _______________________________________________
> websec mailing list