RE: [keyassure] publishing the public key

Of course the cert format is a distraction (all format wars are distractions). But one still has to authenticate the key. There is a seperation between making a realtime security claim using the private key, and verifying the (identity) claim using offline authenticated keys. So "cert" is just a name for "authenticated key", distinguishing between the online and offline acts. 
 
Now, ignore certs and their formats (and their erstwhile CA-based chains). Its just a name for that offline thing that a online security protocol needs to leverage, so its not spoofed.
 
What I like about webid is that its yet another variant of what we used to call validation authorities - which added semantic context to a cert. There have been othe VAs. If the verifier sees an OCSP server URI in a cert, the validator could seek out the http web services of the validation authority thus referenced - which would contextualize the act of verification by its (signed) response. In a third example, if the cert points to a DNS server instread of an OCSP, the DNS server is the validation authority, authenticating its responses using such as IPsec AH. The ISO resolver for oid URIs will be a fourth.
 
IETF in its OCSP work added something that webid folks yet struggle with - the topic of assurance and authority. IETF ensured for OCSP VAs that the authority making "statements about" others could be tied into a control system managed by the original cert maker. Or not; depending on preferences of the deployment community. Sometimes you want the maker and the abouter to be independent; and often you want them linked.
 
What IETF and W3C might hamonize here is the sequencing of the activities of the 2 VAs, for 1 cert. They can be mutually supportive, that is.
 
Lets say keyassure wanted to also address client certs. And said client certs have no DNS SAN field, only the URI field (per webid worldview). Lets remember that the authority subfield in a URI is typically an domain name, little different to the domain name in the DNS SAN field used in keyassure SSL server cert centric worldview.
 
What Henry wants, I suspect, is that when webid verifiers use the webid protocol to talk to a foaf-agent acting as a VA and making statements-about URIs, they can ALSO talk to another *independent* VA called a DNS server, that speaks-about just the authority component of that URI (=webid). The resulting compendium of (2) facts goes into the verification engine of the relying party, which may even demand 3 independent facts before acting (since it require 3 independent VAs, the third of which MUST be located using a trust anchor in a locallu trustesd store, and never from self-signed client certs).
 
 

> From: henry.story@bblfish.net
> Date: Mon, 21 Feb 2011 16:29:30 +0100
> CC: keyassure@ietf.org; public-xg-webid@w3.org
> To: paul.hoffman@vpnc.org
> Subject: Re: [keyassure] publishing the public key
> 
> (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. That this comes in a certificate is a distraction, which ends up creating a lot of mail on formats and makes it difficult to concentrate on the key point.