feat: Support formatted SignatureValue and lenient verification

[jlucaso1]

Closes #486

This PR resolves an interoperability issue with XML signatures generated by some Java libraries (like javax.xml.crypto.dsig). These libraries often format the <ds:SignatureValue> with line breaks and carriage returns (
), which caused validation failures when checked with the current implementation.

This is addressed with two key changes:

1. Flexible Signature Formatting: A new signatureValueFormatting option has been added to SignedXmlOptions. This allows developers to configure the line length and line endings to match the output of other systems, ensuring compatibility.

   const sig = new SignedXml({
     signatureValueFormatting: {
       lineLength: 76, // Or another desired length
       carriageReturn: true // to use \r\n line endings
     }
   });

2. Resilient Signature Verification: The signature loading logic has been updated to strip all whitespace from the <ds:SignatureValue> during parsing. This ensures that validation succeeds regardless of how the signature is formatted (single-line vs. multi-line).

[srd90]

This PR resolves an interoperability issue with XML signatures generated by some Java libraries (like javax.xml.crypto.dsig).

Out of curiosity: which other java libraries (other than javax.xml.crypto.dsig)?

The way I read (*) content of links (and transitive links) provided at #486 (comment) is that it was java side mistake/regression which is now taken care of. Affected versions listed at https://bugs.openjdk.org/browse/JDK-8264194 are 8u231, 11.0.4-oracle. E.g. Oracle java8 and java11 has reached end of public support ( https://endoflife.date/oracle-jdk ) and e.g. Corretto and Temurin provide only security updates to those ( https://endoflife.date/amazon-corretto and https://endoflife.date/eclipse-temurin ). Furthermore all of those are way past versions 8u231 and 11.0.4

At the time latest java8 seems to be 8u451 and latest java11 11.0.27

So, (if) things have settled down at java side why introduce workaround to xml-crypto side (i.e. more code to be maintained) especially if workaround is for something that is fixed/fixable at java side if those systems are kept running on top of up to date java8/java11/java... (if those systems provide security related services those should be running on top of latest supported 8/11/...)

(*) I am NOT saying that I am 100% sure that I read those correctly.

[srd90]

FWIW, seems that e.g. Keycloak fixed behavioral change of javax.xml.crypto.dsig's internals (Santuario's behavioral change) with this commit: keycloak/keycloak@977cc47 (and backport to 20.x: keycloak/keycloak@8438281 ). Read also commit message.

Have you asked from your counterpart whether it can set com.sun.org.apache.xml.internal.security.ignoreLineBreaks system property to true?

Interesting note at SANTUARIO-482
https://issues.apache.org/jira/browse/SANTUARIO-482?focusedCommentId=16381230&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16381230

[jlucaso1]

Thank you for the research.
Makes sense, adding signatureValueFormatting will increase complexity. What do you think about proceeding with just that focused change to the verification logic (loadSignature to strip all whitespace (/\s/g))? I think this change will be a small risk.

[cjbarth]

@jlucaso1 , I'm with @srd90 on this one. That is a lot of code to deal with what appears to be a straight-forward issue. Your proposal to simply remove whitespace seems a little more reasonable, but one has to wonder, why would there be whitespace in a signature that we trust? Is some library generating signatures with whitespace in them?

[srd90]

@jlucaso1 asked:

What do you think about proceeding with just that focused change to the verification logic (loadSignature to strip all whitespace (/\s/g))?

AFAIK xml-crypto hasn't had any issues with SignatureValues that are splitted to multiple lines as long as extra escaping has not been applied (AFAIK2: \s matched also linebreaks) so why would you add code to force those to oneliner (whats the "business case")?

E.g. xmlsec1 produces multiline SignatureValue (see example e.g. from this unrelated issue's comment: #212 (comment) ) and xml-crypto at least has been able to handle such SignatureValues (see this another comment from same unrelated issue #212 (comment) )