- From: Stephen Kent <kent@bbn.com>
- Date: Mon, 21 Feb 2011 21:00:14 -0500
- To: Henry Story <henry.story@bblfish.net>
- Cc: WebID Incubator Group WG <public-xg-webid@w3.org>, keyassure@ietf.org
At 12:49 AM +0100 2/22/11, Henry Story wrote: >... > > >> 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 I don't think that most users, who often can't even tell if they have contacted a TLS-secured site, would think of a public key as part of the identity for the service. I also don't think that most of them think about the port either. >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. once the TLS session has been established, it is symmetric crypto, using a key delivered or derived using a public key (or pair thereof) that provides the data origin authentication and connection-oriented integrity guarantees to which you allude. > > 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. right. Steve
Received on Tuesday, 22 February 2011 17:25:24 UTC