Re: [xri] ED07 Issue #3: Status element and SAML signatures

["Markus Sabadello" <markus.sabadello@xdi.org>]

I recently experimented a bit with XML Signature in Java.. When I signed an XML document, I had to pass the canonicalization method as a parameter. However, when I later verify the signature, I don't specify any canonicalization at all. The library seems to assume the document didn't change it any way.

So it really doesn't seem like a good idea to mess with a signed XML document.

So given that we all don't know how this really works, Drummond's proposal is probably best... An application should either rely on the resolver to verify the signature, or - if it wants to verify it itself - fetch the XRD on its own.

Markus

On 10/24/07, Tan, William <William.Tan@neustar.biz> wrote:

I think I understand the issue now..

You need to canonicalize the XML so as to sign the serialized byte content.
So, if an application really wishes to do it, it needs to remove the
node, then canonicalize the serialized tree before verifying the signature.
However, that may mean that application will have to call some
canonicalization function in the xmldsig libraries and then hook it into
an otherwise pre-packaged function that just verifies the signature in a
single step.

In any case, I too agree that applications shouldn't have to worry about
verifying the signature themselves.

=wil

Markus Sabadello wrote:
> Hmm?.
>
> XML Signature involves a step called canonicalization, i.e. before
> computing the hash and the signature, the document is normalized, to
> make sure the signature is actually applied on the logical document,
> not on the serialization. See
> http://en.wikipedia.org/wiki/XML_Signature#XML_Canonicalization
>
> So in theory what Wil is saying should work (i.e. remove the element
> before verifying the signature).
>
> Or am I missing something here?
>
> However, I also agree applications shouldn't have to worry about
> verifying the signature themselves.
>
> Markus
>
> On 10/24/07, * Gabe Wachob* < gabe.wachob@amsoft.net
> <mailto:gabe.wachob@amsoft.net>> wrote:
>
>     Snipped from my email to Drummond:
>
>     The problem with removing and adding is that there are potential
>     whitespace
>     issues - the digsig stuff is a signature on bytes, and not on the
>     information content of the XML - so if a consuming application gets:
>
>
>
>     <signature>
>
>         <status>blah</status>
>
>         <othersigelement/>
>
>     </signature>
>
>
>
>     That application can't tell between the two following legal xml
>     snippets,
>     each of which is signed differently (because in signatures, every
>     byte,
>     including whitespace, counts):
>
>
>
>     <signature>
>
>         <othersigelement/>
>
>     </signature>
>
>
>
>     And:
>
>     <signature><othersigelement/>
>
>     </signature>
>
>
>
>     In other words, there's no way a consuming application can
>     reconstruct an
>     XML document once a intermediate party has messed with it. outside of
>     setting up some painful, very non-xml-ish rules about exactly how
>     the bytes
>     of the XML are modified when inserting and removing <status> elements.
>
>
>
>
>
>                 -Gabe
>
>
>     > -----Original Message-----
>     > From: Tan, William [mailto:William.Tan@neustar.biz
>     <mailto:William.Tan@neustar.biz>]
>     > Sent: Tuesday, October 23, 2007 3:31 PM
>     > To: Drummond Reed
>     > Cc: 'OASIS XRI TC'
>     > Subject: Re: [xri] ED07 Issue #3: Status element and SAML
>     signatures
>     >
>     > I'm not familiar with SAML so I don't understand why can't an
>     > application remove the Status element before getting the SAML
>     library to
>     > verify the signature.
>     > I mean, I agree that most likely applications aren't going to
>     want to
>     > verify the signature itself. I just don't understand the concern.
>     >
>     > =wil
>     >
>     > Drummond Reed wrote:
>     > >
>     > > In his comments on ED06, Gabe brought up another issue:
>     > >
>     > > Line 2871 - here's the major problem - screwing around with
>     the SAML
>     > > enclosed element signature profile is a recipe for implementation
>     > > disaster - I think most of the libraries out there do the saml
>     > > signature stuff and that's it - modifying the way signatures
>     are done
>     > > seems to me like a potential disaster. One solution might be
>     to move
>     > > the Status element inside the SAML element that is removed by the
>     > > enclosed signature transform (I forget the details). But the
>     way it is
>     > > now is that we'll have to rewrite saml libraries to remove the
>     Status
>     > > element - blech. I'm worried about implementation of SAML
>     digsig stuff
>     > > in lots of languages in the first place (like Ruby, Python, etc)
>     > >
>     > > ************
>     > >
>     > > I discussed this with Gabe. The practical issue is this: how
>     many apps
>     > > are going to want to do SAML signature checking on an XRD
>     themselves
>     > > vs. having an XRI resolver they trust do it for them?
>     > >
>     > > If the answer is "very few or none" (which I what I believe
>     will be
>     > > the case), then this becomes a non-issue, because the XRI
>     resolver
>     > > will check the signature based on exactly the XRD it receives back
>     > > from the server, and only afterwards will it add the Status
>     element.
>     > > The consuming application isn't going to care; it just knows
>     it asks
>     > > for saml=true on the request and accepts a response where the
>     Status
>     > > code="100".
>     > >
>     > > Therefore I propose we sidestep the whole issue as follows:
>     > >
>     > > 1) Recommend that consuming applications use a trusted XRI
>     resolver to
>     > > check SAML signatures, and simply rely on the output of the XRI
>     > > resolver in the Status element that is added AFTER signature
>     > > verification is complete.
>     > >
>     > > 2) If for any reason a consuming application wants to verify
>     an XRD
>     > > signature itself, it should take the outcome of the trusted
>     resolver
>     > > and do its own call to the authority server for each XRD it
>     wants to
>     > > independently verify. That way the result will not have any
>     additional
>     > > Status element added by the resolver.
>     > >
>     > > ************
>     > >
>     > > I'm going for the presumptive close on this issue: please post
>     if you
>     > > DO NOT agree with this solution. Otherwise I'll write it into
>     ED07.
>     > >
>     > > =Drummond
>     > >
>     >
>     >
>     >
>     ---------------------------------------------------------------------
>     > To unsubscribe from this mail list, you must leave the OASIS TC that
>     > generates this mail.  You may a link to this group and all your
>     TCs in
>     > OASIS
>     > at:
>     >
>     https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>     < https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this mail list, you must leave the OASIS TC that
>     generates this mail.  You may a link to this group and all your
>     TCs in OASIS
>     at:
>     https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>