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)



On Jun 16, 2009, at 10:10 PM, Drummond Reed wrote:

>> 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).

Ah, wasn't aware that the XRI community was already doing this.  I  
have no problem with keeping it around in that case.  But since  
TargetAuthority only makes sense when doing XRD-based trust chaining,  
would it make sense to simply use ds:KeyInfo inside of the Link?  I'm  
not sure if we can just cherry pick elements out of the DSig schema  
like that and reuse them in XRD, but I think it should be okay.  Or at  
the very least, should TargetAuthority be renamed to something more  
descriptive and its type changed to base64Binary like ds:X509Data has?


> 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.

would love to hear a use-case for it... None of us on the call last  
week could come up with one.

-will



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