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

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

> Right now, we have a mandate for SAML implementers to provide support
> for signing SAML with the original "inclusive" XML C14N spec. The
> purpose of C14N is to convert an XLM input "node set" to an 
> octet stream
> to be fed into the digest computation. The algorithm used in a signing
> operation is included in the ds:Signature content, so all that matters
> in terms of security is that both sides support the algorithm.
...
> In general, I think the SAML spec should avoid mandating the 
> use of any
> particular algorithm, and simply suggest use of exclusive C14N or at
> least highlight the potential problems.

I think that in the persuit of interoperability we should make 
exclusive a MUST implement, at least on the 'accept' side. 
IMNSHO the original C14N was simply broken.

also I think we can fairly mandate clients to accept C14N encodings
that they generate.

I am much less wary of putting requirements onto services than onto 
clients. Our experience with XKMS is that it is no big deal to
support service variations on a service but clients have real
problems if they have to support a bigspec.


> 2. How to verify what's been signed?

The only way that I am happy with is the 'take the octets you input
to the C14N algorithm, reparse them and use the resulting XML tree.'


		Phill