I’ll have to go look back, but I’m
fairly sure that the canonicalization won’t support this sort of two-way extraction
and reinsertion without issues.
But you could be right… I find
xml-dsig to be excruitiatingly painful, esp with the things like enveloped
signature transformations and the interactions with namespace declarations,
etc.
From:
markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Wednesday, October 24, 2007
12:01 PM
To: Gabe
Wachob
Cc: Tan, William; Drummond Reed;
OASIS XRI TC
Subject: Re: [xri] ED07 Issue #3:
Status element and SAML signatures
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> 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]
> 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
---------------------------------------------------------------------
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
|