[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs
On Jan 12, 2009, at 11:58 AM, John Bradley wrote: > Eran, > > I have been thinking about this issue of using DNS for a DNS > authority based scheme to delegate responsibility for mapping meta- > data about its resources. > > I feel torn between the practical issues of just doing it in a way > that people will be able to use most easily, and the overall design > principal of authority hierarchy in URIs. > > I agree with some that probably the worst consequence is setting a > bad example for others. > > If I step back a bit and ask the question is DNS the only way a > organization can assert it's authority outside of a scheme, it > struck me that perhaps there is another way that sidesteps the DNS > issue. > > A signing cert from Verisign etc states that you have control over a > domain. Not a URI not a particular scheme like https: for that host > or domain, but the domain itself. > > Given the relative insecurity of DNS (leaving dnssec aside for this > conversation) I would rather trust site-meta if it has been signed > by the domain cert indicating it is authoritative for mailto and or > xmpp rather than looking to DNS. This does not resolve the raised issue with an HTTP resource laying claim to the attributes of an XMPP resource (or any other scheme), does it? Using this method, aren't we simply moving the problem from 'those who make HTTP resources' to 'those who have access to a private key', which in the HTTP world, at least, is often the same entities. Using this approach would also require some thoughts be given to wild- card certs (i've forgotten if we;ve address this elsewhere, but wild- card certs may require special attention to whatever we do here). > > I think if site-meta is signed by the cert of the domain then we > maintain the authority chain though PKI rather than resolution. > I am OK with that. (Mark please speak up if you find this an awful > principal) > > So all schemes SHOULD check the detached sig for site meta, and site- > meta is considered authoritative for all the schemes it has maps for > as long as the authority segment of the scheme matches the CN of the > cert. (Yes we may need to include subjectAltNames where the value > is a DNS name or some other matching rule) > > An alternative though weaker option for the RP is to retrieve the > site-meta over https:. That however is much weaker as an attacker > replacing a single text file on a site is a much easier thing to do > than getting the private key for a site to generate the sig. > > It would be up to the needs of the RP software to choose the > appropriate security. > > If we did something like that I could be persuaded to drop the DNS > check from your proposal. > > Peters DNS resolution proposal is a separate issue. > > Regards > =jbradley > > On 9-Jan-09, at 8:56 PM, Eran Hammer-Lahav wrote: > >> I am happy to adjust it to “some hesitation”... :-) >> >> I added a new section to my draft last night explaining the reasons >> for this DNS workaround. I decided to promote a position I am still >> not fully sold on as a way to solicit feedback. I am actually >> hoping everyone will ask to drop it, but at least it is explicitly >> acknowledged as something people have expressed reservations for. >> >> EHL >> >> >> On 1/9/09 3:33 PM, "David Orchard" <orchard@pacificspirit.com> wrote: >> >> (note, my response will not make it onto the XRI list, hopefully >> JohnB will forward it). >> >> Usually () in TAG minutes indicate side comments that generally are >> informative and to be captured but not formal. It's interesting >> that Dan did not want to make his comment formally. And if you >> interpret his comment formally, I wonder if adding DNS doesn't >> solve his concern. >> >> I'm not convinced that the TAG comments can be called "strong >> resistance". Frankly, I'd give another couple kicks at the can >> before adding such a complex optional feature. I do appreciate >> your sensitivity to pushback and trying to ensure a smooth passage. >> >> Dave >> >> On Fri, Jan 9, 2009 at 3:01 PM, Eran Hammer-Lahav <eran@hueniverse.com >> > wrote: >> From: http://www.w3.org/2001/tag/2008/12/10-minutes >> >> DO: I think the TAG could talk about the issue with Authority. Eran >> has asked me and Jonthan to think about whether the TAG has >> anything to say about whether a file like this can speak >> >authoritatively< for, e.g. a mailto: URI. >> >> <ht> HT acknowledges that his suggestion has a huge problem in the >> legacy/name squatting >> >> <Zakim> skw2, you wanted to suggest that jar also mention the >> metadata-discovery googlegroup >> >> JR: Don't think I want to. >> >> SW: Should we point out the Google Group? >> >> <DanC_lap> (if you want to speak authoritatively for a mailto: URI, >> you have to be the SMTP server. or edit the SMTP standard) >> >> --- >> >> From: http://lists.w3.org/Archives/Public/www-talk/2008NovDec/0012.html >> >> From: Mark Nottingham <mnot@mnot.net <http://mnot@mnot.net> > >> Date: Wed, 3 Dec 2008 11:24:04 +1100 >> >> ... >> >> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make >> any authoritative assertions about mailto:dirk@foobar.com; even >> though >> the authority is the same, the URI scheme is different. >> >> I know this particular issue is an important one to the OpenID folks, >> but there needs to be a very careful and broad discussion of allowing >> policy and metadata from HTTP to be considered *automatically* >> authoritative for other protocols. >> >> --- >> >> So there seems to be some resistance to the idea that an HTTP >> server will be used as the generic provider of discovery >> information for non-HTTP resources. That is what this whole DNS >> proposal is about. Personally, I think the "lack of authority" >> argument is not very interesting, and that it is up to applications >> to decide if they want to accept what an HTTP server has to say >> about a non-HTTP URI. But I rather include something like this and >> make the discovery flow completely generic across URI scheme, than >> limit it to HTTP/S URIs only. >> >> EHL >> >> >> >> >> On 1/9/09 1:27 PM, "David Orchard" <orchard@pacificspirit.com <http://orchard@pacificspirit.com >> > > wrote: >> >> >> >> On Thu, Jan 8, 2009 at 5:17 AM, Peter Davis >> <peter.davis@neustar.biz <http://peter.davis@neustar.biz> > wrote: >> On Jan 7, 2009, at 6:40 PM, Eran Hammer-Lahav wrote: >> >> There seems to be strong resistance in various communities to the >> idea that >> an HTTP server can speak authoritatively for non-HTTP URIs. There >> is also >> strong resistance to using DNS as the entry point for resource >> discovery. At >> the same time, it is clear we need to support non-HTTP URIs and >> there is >> strong desire to include a DNS flavor. >> >> Can you provide any references to where this resistance is occurring? >> >> I would also like to see references for such resistance. I think >> as soon you as you go from HTTP to HTTP + DNS, people are >> rightfully going to start asking about their favourite protocol, >> such as XMPP, BEEP, WS-*, SIP, etc. >> >> I think there needs to be compelling evidence to support such a >> complication. Every thing we can possibly remove from V1 only >> helps achieve interoperability by reducing features, especially >> optional ones. >> >> Cheers, >> Dave >> >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]