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)


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



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