OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xri] XRD Examples (and Trust)


Both trust elements provide narrowing of the authority scope. This is needed because subjects and authorities can change during the discovery process or via delegation. Google can use a single certificate to sign all their XRDs which means without the ability to be explicit about what subject to expect on the other side, an attacker can manipulate the reply and issue a 307 to someone else's (perfectly valid and signed) XRD hosted by Google (which is likely to be their own legitimate but customized XRD).

TargetAuthority allows an XRD to be signed by something other than the authority of the XRD subject. TargetSubject allows an XRD to spell out what XRD it deems trusted following a link.

EHL


> -----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.
> 
>   - 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?
> 
> 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.
> 
> 
> -will
> 
> 
> 
> 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]