enveloped-signature must go first for verification to work properly

[joeesteves]

Hi, i was dealing with a verifying problem. [ 'invalid signature: for uri #_0 calculated digest is I6QnT6OKRlqeJXVGIb/UIiV1k/ArtW5/fAJkjGoxP8Y= but the xml to validate supplies digest 3g7fAmI5/vWlkDLK4zlU3/GSmjdFOlOCGs+pNMNqSVM=' ] The calculated digest when verifying was different from the generated when signing. The problem i had was the order of the transform algorithm. Have to change mi code from

beforeChanges :

sig.addReference("//*[local-name(.)='CFE']", [ "http://www.w3.org/2001/10/xml-exc-c14n#","http://www.w3.org/2000/09/xmldsig#enveloped-signature"])

afterChanges: 
sig.addReference("//*[local-name(.)='CFE']", ["http://www.w3.org/2000/09/xmldsig#enveloped-signature", "http://www.w3.org/2001/10/xml-exc-c14n#"])

The problem with the first code, was that exclusive-canonicalization algorithm returns a string and enveloped-signature can't find signature form string, it must recibe node format to work ok. This can be repaired adding one line of code on enveloped-signature.js

EnvelopedSignature.prototype.process = function (node) {
  node = new Dom().parseFromString(node)  // new line
  var signature = xpath(node, ".//*[local-name(.)='Signature' and namespace-uri(.)='http://www.w3.org/2000/09/xmldsig#']")[0];
  if (signature) signature.parentNode.removeChild(signature);
  return node;
};

Not sure if it would be wright to support both transformation orders ([ "http://www.w3.org/2001/10/xml-exc-c14n#","http://www.w3.org/2000/09/xmldsig#enveloped-signature"] or [ "http://www.w3.org/2000/09/xmldsig#enveloped-signature","http://www.w3.org/2001/10/xml-exc-c14n#"])

[markstos]

I think you are on the right track based on this spec: https://www.w3.org/TR/xmldsig-core/ in 6.6.3 XPath Filtering

Each signature must omit itself from its own digest calculations, but it is also necessary to exclude the second signature element from the digest calculations of the first signature so that adding the second signature does not break the first signature.

[joeesteves]

Yes @markstos I agree with that. The doubt I have is, say you have this code

<xmltosign>
<data>....</data>
<signature>....</signature>
</xmltosign>

When verifying, the envelope-signature transformation indicates to remove signature node to before calculate the document digest, and the second transformation will indicate to normalize to exc-c14n document. I think this is the correct order and in fact it's what works properly with this library. But what I can't confirm is if it is a regulated thing by the standard (can't find it in the official documentation) or it's simple the logical order. To sum up xml-crypto works fine with first order of transformation and fails to verify with the second order. If the order is a standardized thing perhaps an error message would save lot of time for those that get stuck on this.

I've already revolve the verifying stage but I have a hard time figuring the errors I was making and any error message would have been useful.

I'd be glad to help if is a valid requirement.

[cjbarth]

@ponyesteves , if you'd be willing to contribute a PR with a test suite, even if that PR is just a better error message, we'd love to have it. Please consider helping the community in this way.