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] SimpleSign for estabilishing the authenticity of XRD.


In line.

On 11-Dec-08, at 1:23 PM, Brian Eaton wrote:

On Thu, Dec 11, 2008 at 8:07 AM, John Bradley <jbradley@mac.com> wrote:
The XRI resolver produces a XRD Sequence as its output that XML document
contains the chain of XRD documents resolved.
The client can then verify the signatures of each of the XRDs contained in
the XRDS.
The last XRD in the XRDS is the one with the SEPs that you are interested
in.   The other XRDs in the XRDS provide the audit info for the client to
verify.
This is particularly important where you are doing XRI resolution through a
proxy resolver that you may or may not trust.
The concept of producing a XRD Sequence is not unlike what you are talking
about with delegation.
A XRDS containing all the XRD that the resolver processed could be returned
to the requester for it to audit and verify the signatures or at-least the
delegation chain.

Ah, I think I've got it now...  when you pluck all of the XRDs out of
their original byte streams and drop them into a new XML file, the
signatures on the original would no longer be valid.  Have I
understood the problem?

Yes
One way to deal with this is not to use an XRD resolver service;
instead the client does the XRD resolution itself.  That way the
signatures can be verified locally, and you get to avoid a dependency
on an external service.


I am referring to the existing XRI Resolver lib and proxy service. 

Yes if you are using a local resolver lib, the lib could do all the signature checking and just report back success or failure.

You do loose audibility of the sigs in the XRDS though.  

I suspect at some point there will be a need in XRD to represent a sequence of XRDs as well.

Another mechanism would be use multipart/file for the XRDS resolver to
return the original byte streams for each of the XRDs.

I don't know if it is possible or desirable to change the existing format of the XRDS at this point to support some sort of multipart format.



A third possibility would be to accept that you really want to be able
to move XML elements from document to document, munge them as
necessary, and still be able to verify the signatures.  XML DSIG is
really the right tool for that.

Perhaps though I still think some intermediate path can be found where the XRDS is the concatenated XRDs with the line ends normalized.
There should be a way to validate a single XRD inside the XRDS without full XML DSIG.  But perhaps that is not possible.

=jbradley


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