Re: [websec] the (old) LockFoo ideas: LockCA, LockEV (was: handling STS header field extendability)

=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 11 August 2012 02:53 UTC

Return-Path: <Jeff.Hodges@KingsMountain.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 C861A21F84B9 for <websec@ietfa.amsl.com>; Fri, 10 Aug 2012 19:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.412
X-Spam-Level:
X-Spam-Status: No, score=-101.412 tagged_above=-999 required=5 tests=[AWL=1.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 khRKhA-+ptrl for <websec@ietfa.amsl.com>; Fri, 10 Aug 2012 19:53:14 -0700 (PDT)
Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 2DBC621F84B3 for <websec@ietf.org>; Fri, 10 Aug 2012 19:53:14 -0700 (PDT)
Received: (qmail 24689 invoked by uid 0); 11 Aug 2012 02:52:52 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 11 Aug 2012 02:52:52 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=gO254EX9BSvkegsd6+csOkhsC5JANcYrpA75KrVCKnI=; b=PLjfsLevMLLc3VfcQ0hAaAVTXe0p5wA/gJXmyuFS96Kx7/yB0Tzx5eLpnO+JMElYaKqccFaZ7ZcJiVewM3x5eJIQvBh+vXMjrCghqnyW734pVuhXHx4YdKDbEpPFsO8W;
Received: from [24.4.122.173] (port=42679 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1T01oq-00053V-Dv; Fri, 10 Aug 2012 20:52:52 -0600
Message-ID: <5025C902.3060609@KingsMountain.com>
Date: Fri, 10 Aug 2012 19:52:50 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] the (old) LockFoo ideas: LockCA, LockEV (was: handling STS header field extendability)
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: Sat, 11 Aug 2012 02:53:14 -0000

 > On Thu, Aug 9, 2012 at 3:09 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
 >
 >> The only extensions we'd discussed in the past were the CertPinning,
 >> LockCA, LockEV. We've decided that cert pinning is an intersecting but
 >> orthogonal policy to HSTS, and thus best handled at this point via a
 >> separate header field. Also, the various LockFoo notions should be
 >> addressed in a cert pinning policy context (i mentioned this in the WG
 >> session at IETF-82 Taipei).
 >
 > Please forgive my ignorance,

no worries, these were nascent ideas we discussed in the past in the context of 
HSTS, mostly just at past websec wg sessions.

 > but do LockCA and/or LockEV offer any
 > functionality that you can't already get with public key pinning as
 > currently specified?

probably not (they were mostly off-the-cuff ideas)


 > You can pin to a given CA's public key(s),

Yes, which provides essentially what we were imagining as LockCA functionality

 >  and you can pin to any given EV issuers' public keys.

yep.

I didn't mean to imply that these LockFoo notions would necessarily pose new use 
cases for draft-ietf-websec-key-pinning -- the latter I-D probably already 
addresses them.


HTH,

=JeffH