[saml-dev] RE: [security-services] XML signature guidelines draft

[Scott Cantor <cantor.2@osu.edu>]

> Issue 1
> =======
> In line 89-90 you write: 
> ?	The algorithm may be applied either at the 
> Signature-wide level, or as a Transform within a Reference.
> 
> This formulation indicates that you mean "or" as "exclusive or". 
> Why not use the canonicalization for both? 

You're right, and after reading closer, I now see the distinction and
why the real issue is the Transform, not the SignedInfo c14n step. I
didn't fully understand the latter until just now.

> Issue 2
> =======
> In lines 137-144 you give an example of XPath 2.0 transformation. 
> I am not familiar with that specification, but the squared 
> backets seem to specify that you want to sign the first 
> "Response" (???).

It's XPathFilter2, which is essentially the new standard for XPath dsig
transforms for most apps.

> My XML toolkit vendor currently does not support XPath 2.0, 
> so I use another method to identify the correct element: It 
> is addressed using the attribute carrying the globally unique 
> ID attribute of the object, i.e. "AssertionID", "RequestID" 
> or "ResponseID". 

That would work, yes. There are even XPath expressions that will work
independently of the ID at all, so it isn't that it can't be done.
Rather, it's more error prone and much slower than the new transform is.

However, I'll make allowance for older implementations.

> Issue 3
> =======
> In line 155-156, you say:
> 
> ?	Exclusive Canonicalization may be used as a Transform, 
> if it cannot be used as the SignedInfo's CanonicalizationMethod.
> 
> Hence, in order to ensure that the references (i.e. the SAML 
> objects) are properly canonicalized before digested, the 
> exclusive canonicalization transformation must always be 
> applied as a transformation (in addition to the "enveloped 
> signature" transform that only cuts out the "ds:Signature" tag).

You're right. I'll correct this.

> In the current 1.0 specification nothing is said about this, 
> and I really wondered about the possible consequences on 
> interoperability. As has come to my knowledge, the SAML 
> interop event did not use signed assertions and so could 
> easily avoid to run into problems arising from XML signature issues.

Yes, that's true. This document is the first step toward correcting
that, but the specification can't really address it fully until version
2.0.

-- Scott