Re: [keyassure] publishing the public key

[Henry Story <[e-mail]>]

On 22 Feb 2011, at 03:00, Stephen Kent wrote:

> 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.

I was not speaking to most users but to this group of security specialists during a discussion on a protocol. The public key is a definite description that uniquely identifies the agent for the purpose of computers, not for the general public.

> 
>> 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.

I am aware of symmetric cryptography's role. But it is public key cryptography that is core in authenticating the server, and setting up the symmetric crypto channel. Symmetric cryptography is used because it is less cpu intensive.

> 
>> > 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

Social Web Architect
http://bblfish.net/