Re: [keyassure] publishing the public key

Paul Hoffman <paul.hoffman@vpnc.org> Sun, 20 February 2011 23:31 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 405BB3A6F1C for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 15:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.332
X-Spam-Level:
X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=0.714, 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 gLb+upQi6Ryf for <keyassure@core3.amsl.com>; Sun, 20 Feb 2011 15:31:35 -0800 (PST)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7ED733A6DDA for <keyassure@ietf.org>; Sun, 20 Feb 2011 15:31:35 -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 p1KNWEE2024351 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Feb 2011 16:32:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D61A47E.7090603@vpnc.org>
Date: Sun, 20 Feb 2011 15:32:14 -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: Paul Wouters <paul@xelerance.com>
References: <E1PqbpT-0000pd-Kz@login01.fos.auckland.ac.nz> <alpine.LFD.1.10.1102201747370.26752@newtla.xelerance.com> <4D619C94.8090702@vpnc.org> <alpine.LFD.1.10.1102201812560.26752@newtla.xelerance.com>
In-Reply-To: <alpine.LFD.1.10.1102201812560.26752@newtla.xelerance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: keyassure@ietf.org
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: Sun, 20 Feb 2011 23:31:36 -0000

On 2/20/11 3:16 PM, Paul Wouters wrote:
> On Sun, 20 Feb 2011, Paul Hoffman wrote:
>
>> On 2/20/11 2:51 PM, Paul Wouters wrote:
>>> The whole point is we do not want to identify a cert. We want to
>>> identify a key.
>>
>> That's not the case currently, at least for many of us.
>
> I'm unclear if you mean "currently with CAs" or "currently within the
> DANE draft".

Neither: I mean "currently with the WG, as far as this discussion has gone".

>> Given that the only thing that can be used in TLS to identify the
>> server is a certificate, most of us want to identify that certificate
>> (or a trust anchor that the certificate chains to).
>
> You confuse me here too. We have an RRlabel, which replaces the
> validated CN=
> and the key (blob or hash) that replaces the public key part of the cert.

Quite true. But we don't have any text that says that.

>> As one of the document editors, if the WG says that it also wants to
>> have keys as targets, I will also need (a) a rationale for why this is
>> wanted and (b) text explaining how to make a certificate association
>> between the key and the certificate that comes from the TLS server. I
>> have asked a few times for these, with no luck so far. I don't know
>> that the WG can actually decide to add bare keys without knowing how
>> they will be used.
>
> I will get that to you before Prague.

Ah! So we will. If someone comes up with text before then, great, but if 
not, can we put this discussion on hold until we have something concrete 
to discuss?