- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 22 Feb 2011 00:49:38 +0100
- To: Stephen Kent <kent@bbn.com>
- Cc: WebID Incubator Group WG <public-xg-webid@w3.org>, keyassure@ietf.org
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/
Received on Monday, 21 February 2011 23:50:15 UTC