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"

http://www.ietf.org/mail-archive/web/keyassure/current/msg01719.html

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

http://www.ietf.org/mail-archive/web/keyassure/current/msg01755.html

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 
    bugmenot.com or mailinator.com a service to create short lived or anonymous WebIDs
    I added a FAQ for that 
      http://www.w3.org/wiki/Foaf%2Bssl/FAQ#Could_one_have_throwaway_WebIDs_.3F
  - 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: ( http://www.w3.org/TR/xkms/ 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

   http://www.ietf.org/mail-archive/web/keyassure/current/msg01780.html
  
It turns out that there is a ticket open for that
   
   http://trac.tools.ietf.org/wg/dane/trac/ticket/14

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.


	Henry   


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

> 
> WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC 
> 
> http://www.w3.org/2005/Incubator/webid/track/issues/5
> 
> 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 amazon.com, is amazon.com and not thief.xxx . 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"
> 
> http://esw.w3.org/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_with_FOAF.2BSSL.3F
> 
> 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
> https://www.ietf.org/mailman/listinfo/keyassure
> 
> 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