Re: [keyassure] publishing the public key

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 19 February 2011 18:41 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3FD3A6DF7 for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 10:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.234
X-Spam-Level:
X-Spam-Status: No, score=-101.234 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ3rmfeDAFkH for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 10:41:14 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 977E53A6D2A for <keyassure@ietf.org>; Sat, 19 Feb 2011 10:41:14 -0800 (PST)
Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p1JIfoCG037323 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <keyassure@ietf.org>; Sat, 19 Feb 2011 11:41:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D600EEE.4010509@vpnc.org>
Date: Sat, 19 Feb 2011 10:41:50 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: keyassure@ietf.org
References: <E1PqbYp-0008EI-Dx@login01.fos.auckland.ac.nz> <A2CF8378-6577-4AF2-9CD5-4992EE9B13B8@bblfish.net> <AANLkTinVzkSa=ELhzWka7FH3=ErswbfjDgVKvk7Qu1mi@mail.gmail.com>
In-Reply-To: <AANLkTinVzkSa=ELhzWka7FH3=ErswbfjDgVKvk7Qu1mi@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [keyassure] publishing the public key
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Feb 2011 18:41:15 -0000

On 2/19/11 9:09 AM, Phillip Hallam-Baker wrote:
> The problem with this approach is that it means that we are going to at
> best be exercising new code paths in existing code. At worst we are
> going to force people to write new code.

Fully agree on both. I have yet to see what I asked for early on, which 
is any text that explains how a TLS client who gets a bare key would use 
it in TLS.

If there is later a standards-track extension to TLS that handles bare 
public keys, that format can be added to TLSA at that time. It would use 
the exact same format so that clients can do exact matching without 
having to process either the key data from TLSA/DNS or the key data from 
the TLS handshake.

I'm still open to hearing *why* adding bare keys would help TLSA, but I 
would also want to see text about how the processing would go so that I 
could weigh the benefit against the cost.