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)


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]