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

["Gabe Wachob" <gabe.wachob@amsoft.net>]

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