Re: [keyassure] publishing the public key

Henry Story <henry.story@bblfish.net> Mon, 21 February 2011 23:49 UTC

Return-Path: <henry.story@bblfish.net>
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 D74293A6452 for <keyassure@core3.amsl.com>; Mon, 21 Feb 2011 15:49:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.127
X-Spam-Level:
X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
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 2Vp97nNe839K for <keyassure@core3.amsl.com>; Mon, 21 Feb 2011 15:49:01 -0800 (PST)
Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by core3.amsl.com (Postfix) with ESMTP id 565BA3A63CA for <keyassure@ietf.org>; Mon, 21 Feb 2011 15:49:01 -0800 (PST)
Received: by bwz12 with SMTP id 12so3123615bwz.27 for <keyassure@ietf.org>; Mon, 21 Feb 2011 15:49:43 -0800 (PST)
Received: by 10.204.77.196 with SMTP id h4mr1869190bkk.89.1298332182941; Mon, 21 Feb 2011 15:49:42 -0800 (PST)
Received: from bblfish.home (ALagny-751-1-8-99.w86-218.abo.wanadoo.fr [86.218.107.99]) by mx.google.com with ESMTPS id 12sm4119416bki.7.2011.02.21.15.49.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Feb 2011 15:49:42 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <p06240803c98892e88fc4@[59.188.192.152]>
Date: Tue, 22 Feb 2011 00:49:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FAB667F-44F9-4349-B11B-F4FECD51BB81@bblfish.net>
References: <E1PqbpT-0000pd-Kz@login01.fos.auckland.ac.nz> <alpine.LFD.1.10.1102201747370.26752@newtla.xelerance.com> <4D619C94.8090702@vpnc.org> <93E9FABD-A84A-4A4E-AF96-6E101604F8B4@bblfish.net> <p06240803c98892e88fc4@[59.188.192.152]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1082)
Cc: WebID Incubator Group WG <public-xg-webid@w3.org>, 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: Mon, 21 Feb 2011 23:49:03 -0000

On 21 Feb 2011, at 23:10, Stephen Kent wrote:

> At 4:29 PM +0100 2/21/11, Henry Story wrote:
>> (Just a summary of what I understood of this thread, and a few new ideas)
>> 
>> On 20 Feb 2011, at 23:58, 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. 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).
>> 
>> One needs to go beyond appearances a little here. My argument is that what identifies a server in TLS is a public key.
> 
> Do you mean "identifies" or "authenticates?" I think most folks view the DNS name (or URL) as the identity of the web site.

Partly. The DNS domain name is a name that one could think of as referring to a set of services, each of those having a name of the form name:port. The relation between the service name and the public key forms an identifying description, or I should say  a definite description  as it is known in philosophy. I used the following example:

  name:port knowsPrivateKeyof pubK 

That sentence does not authenticate, it describes. But it is part of the TLS authentication protocol. Authentication is the process that uses that information to prove the authorship of the messages sent down a socket.

> We're debating the mechanics of how to enable a client to verify that the asserted identity matches the client's expectations, based on the content of a series of DNS records.

Yes, that is what the next part of my e-mail was describing the logic of. Now in the case of server identity the client knows what it wants the server's identity to be, since it initiated the call, went to DNS, found the ip address, and connected. The clienet can then use the public key found in DNS (or returned  by the server) to authenticate the service it is connected to.

> 
> Steve

Social Web Architect
http://bblfish.net/