Re: [xri] xml dsig profile

[John Bradley <jbradley@mac.com>]

Hi Gabe,

This has concerned me as well.

In the initial use case for XRD discovery via URI Eran and others are making the assumption that the signature checking is done on the original byte stream before XML processing.  The only problem with this is that you need to process the XML to find the location of the detached sig.   But keeping the original octet string around is not a huge problem in most cases.

For XRI where we want to construct an XRDS it is more on an issue.   We have discussed base64 encoding the XRD octet string   so that it can be included as an element of the XRDS.  

I don't think we have reached a conclusion on how best to do that with an XRDS.  Questions like do you have both the encoded and decoded version in the XRDS still are outstanding.

Interestingly enough I suspect that the XRDS form may be needed for URI as well if a resolver is walking a chain of URI identifiers following delegations looking for a service.   I am perhaps the only one thinking that though.

We talked about it on the call Thursday.

Think of URI as one subsegment XRI.  If the form of the XRD allows delegation/refs/redirects etc even though you start with a single subsegment you may traverse some number of XRDs to find the service/relationship that you are looking for.

This also means that any URI that has a XRI authority service in its XRD could be a valid subsegment.

A common case might be:

$(boeing.com)*jbradley

Using the URI as the first subsegment via a cross ref make sense.  What URIs mean as other subsegments other than opaque cross-references I don't know.

=jbradley

On 8-Feb-09, at 4:46 PM, Gabe Wachob wrote:

I was pretty unhappy with specifying XML DSig years ago when we
weren't sure that implementations would be out there.

Fast forward a few years, and its clear to me that XML DSig is not
really well implemented and I'm happy to see other signature
mechanisms in place.

One reason that XML DSig canonicalization exists, however, is because
XML defines equality between two fragments where those two fragments
may differ in the way they are serialized. And why allow
serializations to differ? Because many libraries that
input/output/process XML take liberty in rewriting XML as theyprocess
it. Namespaces are the big area where this happens - libraries
frequrently rewrite the namespace qualifier (which is supposed to be
arbitrary within a document anyway). This allows app developers to use
standard libraries to do XML processing, while still being able to
apply signatures -- "cutting and pasting" a block into an XML document
is an example.

AFAICT, alternate signature mechanisms like SimpleSign won't allow for
alternate serializations, which is fine, but lets recognize that this
may make some processing more complicated because application
developers can't have the assurance that the libs they are using will
preserve the octets as the XML is processed (e.g. copied from document
to another, for example).

   -Gabe


On Fri, Feb 6, 2009 at 4:54 PM, Brian Eaton <beaton@google.com> wrote:

On Fri, Feb 6, 2009 at 3:30 PM, Sakimura Nat <n-sakimura@nri.co.jp> wrote:

I would also like to hear an input from people in SSTC on the rational they came up with Simple Sign.

Absolutely.  Peter was going to ping them.  I'm really hoping they can

comment.  I'd like to hear from the authors of XML DSIG as well.

Also, note that XML Dsig implementation on the scripting languages are wrappers on C library, and it may not be feasible to use them in many hostin environment. So, we might want to take this into consideration as well.

Agreed, those libraries are for the truly desperate.

---------------------------------------------------------------------

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

--
Gabe Wachob / gwachob@wachob.com \ http://blog.wachob.com

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

smime.p7s