RE: [keyassure] publishing the public key

i dont think of a domain-name as ip:port. I think of domain name as a named container, for such as service records, DNAMES, NAPTRs,.... 
 
A sequence of certs in a chain, a sequence of signed XRDs indicating meta-relationships in google-land, a sequence of signed zones in IANA land ... are all essentially the same thing. 
 
What is interesting is that the DNS and zone signing doesnt seem to be being used to replace cert chaining handoffs - but to qualify a given cert - starting with the rnm-cert known as a trust anchor. the issuer of the DNS record (the zone authority) is essentially making statements about a cert/key, inviting the verifier to override the cert's own statement with the statements of the "qualifying agent". If I read between the lines, in the usual dominance relationship of cert chains, if the topmost cert/trust-anchor is invalid (becuase a DNS record asserts it so, once the TTL expires of the record copy), then so is the EE cert at the end of the chain.
 
keyassure makes some sense for a trust anchor for an n-element cert chain - in which the DNS record's various properties are inherited by the trust anchor (encoded in a self-signed cert package). Should its properties then control the validity of a chain of assertions? 
 
We didnt go there in webid land, todate. WE simply said, there exist trust anchors (self-signed cert) that can authenticate an EE using a combination of the SSL client authn procedure plus the openid thesis (about controlling the identity document...). Rather than then discover and walk a chain of authority certs, one discovers and then walks a linked data network in RDF land. To authenticate each RDF document that is an element of that linked data graph, one uses https and server certs as normal so that the https channel speaks authoritatively for that RDF document's integrity and data origin authentication - in the style of Lampson's theorem that has an (authorized) channel speak for the revocation of a cert by either release or not releasing that cert as content on the channel.
 
 
> From: henry.story@bblfish.net
> Date: Tue, 22 Feb 2011 00:49:38 +0100
> CC: public-xg-webid@w3.org; keyassure@ietf.org
> To: kent@bbn.com
> Subject: Re: [keyassure] publishing the public key
> 
> 
> 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/
> 
>