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

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

From: peter williams <home_pw@msn.com>
Date: Mon, 14 Feb 2011 10:59:51 -0800
Message-ID: <SNT143-ds20DA48447A4EB575047C4892D00@phx.gbl>
To: "'Henry Story'" <henry.story@bblfish.net>, "'WebID Incubator Group WG'" <public-xg-webid@w3.org>
Conflating DNSsec with DANE seems strange. DANE and DNSsec are very
different.... in themselves.

DNSsec is fundamentally about protecting the zones of the name servers and
the internal endpoint resolution. Optionally the methods use then provide a
basis for authentication RRs of many types.

DANE wants DNS servers to be making super-statements about X.509 cert blobs,
stored in RRs (rather than being stored in a web file, or a ldap directory
entry, or lotus notes db record, or... ). It then wants the trust between
zones to be specifying what constitutes a trust chain between such certs,
when and only when stored in RRs.

Its all very classical, with swap of technology. They are trying to use DNS
as an authority-resolver. One could be using ldaps equivalently, of https
URI resolvers (in Kingeley's work with http URI to XRD resolvers). Its just
the application of a trusted name server to authority resolvers.

It makes some sense, in HTTP over https for servers, if you see https as
being about domain-names. But, webid is really about the URI as the
identifier, not the domain name.

For all it matters I can be, with no DNS
dependency. After all, its hidden in a cert, and not supposed to be seen by
users. For all anyone knows, that IP address is a tunnel-endpoint, that
routes on to my real IP address that changes every 3 minutes.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Monday, February 14, 2011 8:26 AM
To: WebID Incubator Group WG
Subject: Re: WebID-ISSUE-5 (dnssec): Follow Work in publishing keys in

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 
    bugmenot.com or mailinator.com 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

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

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
> 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_w
> ith_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 19:00:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:41 UTC