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

On 14 Feb 2011, at 19:59, peter williams wrote:

> Conflating DNSsec with DANE seems strange. DANE and DNSsec are very
> different.... in themselves.

Don't think anyone is conflating DNSsec with DANE. How do you come to that 
conclusion?

> 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.

RR=Resource Record
yes

> 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.

Dane is defined in detail here
http://datatracker.ietf.org/wg/dane/charter/

(I just updated this issue and the foaf+ssl/FAQ with this link which is 
much more useful that the mailing list)

[[
Objective:

Specify mechanisms and techniques that allow Internet applications to
establish cryptographically secured communications by using information
distributed through DNSSEC for discovering and authenticating public 
keys which are associated with a service located at a domain name.
]]

by service they mean simply the hostname:port pair.
that's what the SRV_ID type is for in SAN and IAN fields of X.509

[[
Problem Statement:

Entities on the Internet are usually identified using domain names and
forming a cryptographically secured connection to the entity requires
the entity to authenticate its name. For instance, in HTTPS, a server
responding to a query for is expected to
authenticate as "www.example.com". Security protocols such as TLS and
IPsec accomplish this authentication by allowing an endpoint to prove
ownership of a private key whose corresponding public key is somehow
bound to the name being authenticated. As a pre-requisite for
authentication, then, these protocols require a mechanism for bindings
to be asserted between public keys and domain names.
]]

Yup, very similar to what we are doing. Just we are binding URIs to 
public keys, and we publish things RESTfully on the Web, which makes it
a lot more flexible. But of course since we (partially) rely on DNS 
any improvements there, helps us too.

Btw, this is an argument for why we should not try to be so general
as to encompass all possible ways of applying this. Each implementation
is just a special case of a generic philosophical/logical low. It would
be somewhat comical if we tried to make a Dane version of our spec.

> 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.

yes, as we are. The problem is that ldap does not give you a global naming
space. DNS is one key element in making global names possible. Well DNS is
the global naming technology, and most useful URIs are built on it. (XRIs too
for example)

> 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.

Most URIs that are useful for WebID use domain names. 
But yes, when we work at the semantic level, we are working at a level
where the ground concepts are URIs. Just like chemists, don't usually
need to use vocabulary from the quantum level, even though chemistry depends
(supervenes) on the lower level.

> For all it matters I can be http://29.45.62.12/peter#me, 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.

I have opened an issue for this question. It occurred to me a few months
ago on the foaf-protocols list, but we did not look into it in any depth.

Henry

> 
> 
> -----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
> 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   
> [snip]

Social Web Architect
http://bblfish.net/

Received on Tuesday, 15 February 2011 12:54:44 UTC