Which is the proper XML exclusive canonicalization?

Question

I'm using xmlseclibs to try and sign a SOAP document, but it does not seem to canonicalize things in the same way depending on whether I'm signing or validating.

I'll give you an example. This is the XML I am trying to sign:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"&gt;
<soapenv:Header/>
<soapenv:Body>
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" IssueInstant="2010-02-04T15:27:43Z" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester"/>
</samlp:Status>
</samlp:Response>
</soapenv:Body>
</soapenv:Envelope>

I got some code working in PHP to sign it using a combination of public key and private key certificates, and it seemed to work. It added the <ds:Signature> element with all the proper stuff, and it looked great. But then I tested it by immediately trying to validate it after signing it, again with xmlseclibs (and the public key certificate), but the validation failed. So the exact same code library is doing both the signing and validating, but the two processes don't agree for some reason.

I added some debugging code to xmlseclibs to find out what it's doing, and I realized that the reason the signing key it comes up with and the validation key it comes up with are different are because it canonicalizes things differently in the two situations. When I tell it to sign the <samlp:Response> element, this is the canonical form it signs (I've added newlines here for readability):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>

However when it goes to validate the signature, this is the canonical form it computes to validate against (again, I've added newlines here):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester">
</samlp:StatusCode>
</samlp:Status>
</samlp:Response>

So as you can see, this version omits the xmlns:saml attribute from the <samlp:Response> element, while the first does not. (Note that this is different from the xmlns:samlp attribute, which is included in both.) This seems pretty clearly like a bug in xmlseclibs, but nonetheless it's one I'd be happy to fix myself if I just knew which canonical form was the correct one. Should that attribute be omitted by exclusive canonicalization? Or should it be included? Which one is the correct exclusive canonical form?

Answer 1

Neither are the correct canonical-form!

The signing XML has a namespace declaration that comes after the non-namespace attributes, which breaks the Document Order rule:

Namespace nodes have a lesser document order position than attribute nodes.

The verification XML is missing the saml namespace node completely. Canonicalisation doesn't remove namespace nodes merely because there is no child content that references them. It only removes redundant namespace nodes (ie. namespaces that were already in effect on the parent).

I don't know enough about xmlseclibs to say why this is happening, but it's definitely wrong on both counts. FWIW the c14n function on my DOM here says:

<samlp:Response xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant="2010-02-04T15:27:43Z" MajorVersion="1" MinorVersion="1" ResponseID="pfxe85313e6-e688-299a-df06-30f55e24f65a">
<samlp:Status>
<samlp:StatusCode Value="samlp:Requester"></samlp:StatusCode>
</samlp:Status>
</samlp:Response>

eta: I just looked at xmlseclibs.php in the SVN, and there's not an easy fix for this as its current approach is fundamentally flawed. It tries to create a “canonicalised” DOM and then serialises it with plain old saveXML(). As there are C14N serialisation rules about attribute order and character escapes that saveXML does not promise to follow, there is no way this can possibly work.

Answer 2

You are creating the DOM document improperly and trying to use the invalid in-memory tree. Either serialize and use the serialized result or properly create the namespace declarations in the tree before trying to sign. See the bug report for more information: http://code.google.com/p/xmlseclibs/issues/detail?id=6