W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2011

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

From: WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org>
Date: Thu, 27 Jan 2011 18:08:50 +0000
To: public-xg-webid@w3.org
Message-Id: <E1PiWH4-0001vl-ID@lowblow.w3.org>

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 Thursday, 27 January 2011 18:08:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 27 January 2011 18:08:52 GMT