Re: WebID-ISSUE-5 (dnssec): Follow Work in publishing keys in DNSSEC

Last Wednesday I started a thread on the keyassure group to introduce
our work here in a thread called "WebID at W3C and keyassure"

My initial presentation was way to terse, but I think I managed to explain
myself clearly in the third mail, at which point I had also found the spec, 
which was very much along the lines of what I was expecting

I was trying to show how both protocols are very similar, though I am not
sure yet how many people I convinced of that.

Of course all the usual WebID issues pop up:
  - why is it going to work if OpenId was no success
  - Is this not a big brother system? Could one have something or a service to create short lived or anonymous WebIDs
    I added a FAQ for that
  - the anonymity issue comes up. A really important feature for browser to provide.

I also discovered from this thread that the W3C has the  XKMS specification as Phillip Hallam-Baker pointed out: ( I suppose)

We already have a Web Service that is designed to serve as a key centric distribution mechanism for per-user data and it happens to be a W3C recommendation - XKMS. 

Not sure yet what we can do with that, but worth looking at.

As we are publishing only the public key in WebId Profiles I noticed that they are publishing the whole certificate in DNS, so today I asked on a separate thread if they had thought of just publishing the public key
It turns out that there is a ticket open for that

and they will look at that later.  I am a bit surprised that some think they need a new
TLS profile to allow this....

  Ok, that's all on that front.


On 27 Jan 2011, at 19:08, WebID Incubator Group Issue Tracker wrote:

> WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC 
> Raised by: Henry Story
> On product: 
> By placing a public key in DNS one can do the same trick WebID is doing for client
> certificates, but for server certificates. Let me explain this from a WebID perspective.
> When someone connects to a server what they wish to know is that the
> server, say, is and not . The WebID
> in the server cert should therefore be a Fully Qualified Domain Name (FQDN).
> Now FQDNs are global names that have their own canonical lookup protocol. This 
> protocol is known as DNS. The exact same logical lookup we are doing with 
> WebID can therefore be done with FQDNs.
> This is what I described on the FAQ in the section 
> "How does Secure Authentication work with Foaf+SSL"
> So if one could look up the public key of the server via DNS then one would not need
> a certificate authorities - or one would not need them for this task at least. But DNS
> is not secure. Oh wait: it WAS not secure. It is now with DNSSEC (or whatever technology ends
> up filling that extremely important role). So once you allow
> DNSSEC you can place public server keys there. There are a number of RFCs that are 
> dealing with that: RFC3498, RFC4255, and the  Keyassure IETF working group
> We should follow what the keyassure working group are doing, as we are working conceptually
> in the same space. This is also a place for browser vendors to help make https much more easy 
> to deploy.

Received on Monday, 14 February 2011 16:27:58 UTC