[Bug]: SignedXml cannot validate XML signatures using Canonical XML 1.1

[marcus905]

Describe the issue

The System Application SignedXml implementation cannot process XML signatures that use W3C Canonical XML 1.1:

http://www.w3.org/2006/12/xml-c14n11

Canonical XML 1.1 is used by real-world XMLDSIG/XAdES documents, including signed business documents.

When such a signature is loaded through SignedXml, the Canonical XML 1.1 transform cannot be resolved by the current implementation, so the signature cannot be cryptographically verified.

This appears to originate from the underlying System.Security.Cryptography.Xml implementation, which currently does not provide a built-in Canonical XML 1.1 transform.

The upstream .NET issue is:

dotnet/runtime#132231

This is separate from the previously reported XPath Filter 2.0 transform issue in #10215

Expected behavior

SignedXml should be able to load and verify standards-compliant XML signatures using Canonical XML 1.1.

If support depends on the underlying .NET implementation, Business Central should be able to use that support once it becomes available.

Alternatively, the SignedXml abstraction should expose sufficient transform extensibility for consumers to provide an implementation for otherwise unsupported XMLDSIG transforms.

Steps to reproduce

1. Obtain the valid Canonical XML 1.1 XMLDSIG test document referenced in the abovementioned dotnet/runtime issue.

   The test document uses:

   http://www.w3.org/2006/12/xml-c14n11

2. Create a small AL codeunit or test that reads the XML document.

3. Select its XMLDSIG Signature element.

4. Pass that element to the System Application SignedXml implementation.

5. Observe that SignedXml cannot process the signature because
   http://www.w3.org/2006/12/xml-c14n11 is not supported by the current
   implementation.

Additional context

Canonical XML 1.1 is a W3C XML canonicalization standard and is used in
real XML digital-signature ecosystems.

We encountered this while implementing generic XAdES verification support
using the System Application SignedXml abstraction. Documents using the
currently supported canonicalization algorithms can be processed, while
documents using Canonical XML 1.1 cannot.

A public, non-confidential valid XMLDSIG test vector is referenced in the
linked dotnet/runtime issue, so no customer or invoice data is required to
reproduce the problem.

I am willing to contribute a fix on the Business Central side if changes
are required there once the underlying .NET capability is available, or
if exposing generic transform extensibility is considered the preferred
solution.

I will provide a fix for a bug

• I will provide a fix for a bug

[github-actions]

🤖 AI triage could not be completed (the triage agent produced no result). Please remove and re-add the ai-triage label to retry.

[marcus905]

Update after discussing the limitation upstream with the .NET runtime team:

dotnet/runtime#132231 was closed as not planned.

The maintainer clarified that System.Security.Cryptography.Xml is not
accepting new features, so Canonical XML 1.1 support is unlikely to be
added to the underlying runtime.

Because of that, I don't think waiting for runtime support is a viable
resolution for this issue.

I have opened a separate proposal to make the Business Central SignedXml
abstraction extensible for XMLDSIG transforms:

#10221

If such an extensibility point is added, Canonical XML 1.1 could be
implemented by an extension and associated with:

http://www.w3.org/2006/12/xml-c14n11

without requiring System Application itself to implement the algorithm.

I would therefore keep this issue as the concrete C14N 1.1 interoperability
case, with the linked extensibility issue as the proposed general solution.