[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] XRD Examples (and Trust)
See inline. > -----Original Message----- > From: Will Norris [mailto:will@willnorris.com] > Sent: Tuesday, June 16, 2009 12:53 PM > To: XRI TC > Subject: Re: [xri] XRD Examples (and Trust) > > So to add to this a bit more... I've been thinking about this stuff > more the last couple of days and talking with some folks, and I'm > beginning to question whether we need TargetAuthority either. I > remember that it was added to the discussion during the face to face > after IIW. But looking at things now, I'm not entirely clear what it > buys us. > > Given a scenario where we have a link relationship between two > resources described by XRD documents: > > - In order to guarantee the integrity of the first XRD document, it > must be signed. In order to trust the signature, it must be generated > with a certificate that we trust, or that was issued by a CA that we > trust. > > - In order to guarantee the integrity of the second XRD document, it > must be signed. In order to trust the signature, it must be generated > with a certificate that we trust, or that was issued by a CA that we > trust. > > - Why does the first XRD document need to assert anything about the > signature of the second document? What does it buy us? Ensuring that > the two CN values match does nothing for trust, since the only way we > can trust the signature of the second document is to follow the cert > chain to a trusted CA. It's not "the only way" if you use the XRD docs themselves as the trust chain, as you describe (and I further respond) below. > - Having the first XRD document assert the CN value for the > certificate used to sign the second XRD document actually limits the > flexibility of the publisher of the second document, while doing > nothing to enhance trust. > > > I'm fairly certain that the only thing necessary to establish trust > between two XRD documents is simply to sign them both with trusted > certs. TargetAuthority does nothing to enhance that trust, and only > adds the potential for hindering flexibility. Or am I just forgetting > something about why we added it in the first place? Your assumption only holds for conventional cert-based trust chains. See below. > It's worth noting that the only thing that *would* be of value is to > have the first XRD assert the actual public key that should be used to > verify the signature of the second XRD. But that is introducing a > whole other set of problems, and is *not* something I am actually > proposing we do. What's ironic is that this scenario is exactly what the XRI Resolution 2.0 specification already accomplished. 18 months ago. It enabled a chain of XRD documents to be used as a trust chain in addition to the option of using conventional certs and a CA-based trust chain. Since there is a great deal of interest, at least among the hard-core XRI and XDI community, in the XRD-based trust chain model, and all it takes to support it is the <XRD:TargetAuthority> element (which was the <XRD:Service:ProviderID> element in XRI Resolution 2.0) and the <ds:keyInfo> element (that is already defined in XML dSig and exactly what was used in XRI Resolution 2.0), I see no reason to go backward and remove this functionality. In short, XRD 1.0 can support both a conventional cert-based trust chain (in which case <XRD:TargetAuthority> is not needed) or an XRD-based trust chain (in which case <XRD:TargetAuthority> is needed). I'm also not convinced that <XRD:TargetSubject>, while perhaps not required, is not still helpful for security reasons, but I need to think about it some more. We'll definitely put this on the agenda for Thursday's call. =Drummond > > On Jun 15, 2009, at 2:10 PM, Will Norris wrote: > > > So I finally sat down and sketched out a number of example XRDs that > > demonstrate the major use cases I could identify. A few major > > takeaways: > > > > - I've modified the "delegate an entire domain" flow a bit from > > Dirk's example he presented at IIW9... I'm really curious to see if > > this flow will work for what Google wants to do. > > > > - I've proposed dropping the <TargetSubject> element > > > > It's a bit long, but should definitely be read in order, as most > > sections build on previous ones: > > http://wiki.oasis-open.org/xri/XrdOne/XRDExamples > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]