OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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


Subject: RE: [security-services] XML Sig issues w/ SAML



> > So what we really should be using is some mechanism that 
> > ensures that every prefix is expanded out to the URI it 
> > references. This would not be well formed XML but it would be 
> > cannonical and the inclusive / exclusive bit would be solved.
> 
> Why not go the extra yard and define a c14n algorithm that expands the
> prefixes, and then reassigns them when generating the bytes 
> so that you
> end up with well-formed XML? Then you don't need a new parser.

The disadvantage of that mode is that it assumes that your
information flow is :

source -> canonicalizer -> verifier
source -> processor

I prefer to use an information flow:

source -> canonicalizer
canonicalizer -> verifier
canonicalizer -> processor

Of course what you could do is:

source -> canonicaltree
canonicaltree -> serializer -> verifier
canonicaltree -> processor

Which I guess would be provably secure against a substitution attack.

> That loosely equates with option (1) I proposed, fixing the Transforms
> element in SAML so that verification doesn't require re-examining the
> input node set. To avoid XPath, we have to support ID and XLink.

I think that can work, provided we are confident that we really 
understand the transformation.

This is something that ws-security will have to consider.


		Phill


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


Powered by eList eXpress LLC