ISSUE-5: Follow Work in publishing keys in DNSSEC - DANE
keyassure
Follow Work in publishing keys in DNSSEC - DANE
- State:
- OPEN
- Product:
- User Interface/Browsers
- Raised by:
- Henry Story
- Opened on:
- 2011-01-27
- Description:
- 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
http://datatracker.ietf.org/wg/dane/charter/
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. - Related Actions Items:
- ACTION-55 on Henry Story to Look into seeing if DANE fits into spec - due 2013-02-08, open
- Related emails:
- Re: Formal WebID Teleconf Friday February 1 2013 15:00UTC (from henry.story@bblfish.net on 2013-02-01)
- Another use case for DANE (from henry.story@bblfish.net on 2011-11-06)
- Re: WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC (from home_pw@msn.com on 2011-02-15)
- Re: WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC (from Pieter.Lange@os3.nl on 2011-02-15)
- Re: WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC (from home_pw@msn.com on 2011-02-15)
- Re: WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC (from henry.story@bblfish.net on 2011-02-15)
- Re: WebID-ISSUE-5 (dnssec): Follow Work in publishing keys in DNSSEC (from henry.story@bblfish.net on 2011-02-15)
- RE: WebID-ISSUE-5 (dnssec): Follow Work in publishing keys in DNSSEC (from home_pw@msn.com on 2011-02-14)
- Re: WebID-ISSUE-5 (dnssec): Follow Work in publishing keys in DNSSEC (from henry.story@bblfish.net on 2011-02-14)
- WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC (from sysbot+tracker@w3.org on 2011-01-27)
Related notes:
The most immediate advantage for browsers is that this could allow people who wish to publish self signed certificates to just place the public key in DNSsec, which should be much easier than getting and paying for a CA based certificate. This could then reduce the number of ugly error messages shown for those sites.
Henry Story, 15 Feb 2011, 17:10:13Some interesting issue arise when publishing keys in DNSSEC, and how this affects firewalls. This is summarized in this mail "firewalls and TLS and DNSsec" with pointers
http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0276.html
Display change log
