> 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
