[Bug]: SignedXml cannot load XML signatures using XPath Filter 2.0 transform

[marcus905]

Describe the issue

The System Application SignedXml codeunit cannot load or verify otherwise valid XMLDSIG/XAdES signatures that use the W3C XPath Filter 2.0 transform:

http://www.w3.org/2002/06/xmldsig-filter2

Calling:

SignedXml.LoadXml(SignatureElement);

for such a signature fails with:

Unknown transform has been encountered.

This transform is used by real-world XAdES signed business documents.

In our interoperability corpus, XAdES signatures using only the standard enveloped-signature transform can be successfully loaded and verified using Business Central SignedXml, while valid XAdES signatures using XPath Filter 2.0 fail during LoadXml.

This prevents extensions from verifying these signatures through the public System Application XML signature API.

Expected behavior

SignedXml should support loading and verifying XMLDSIG references that use the XPath Filter 2.0 transform:

http://www.w3.org/2002/06/xmldsig-filter2

Alternatively, the public API should provide an extensibility mechanism that allows additional XMLDSIG transforms to be registered or supplied by extensions.

The latter could also make the API more future-proof for other standardized XMLDSIG transforms that are not directly implemented by the current wrapper.

Steps to reproduce

1. Obtain or construct an XML digital signature containing a reference with:

   <ds:Transform Algorithm="http://www.w3.org/2002/06/xmldsig-filter2">
   

2. Load the XML document in AL.

3. Locate the ds:Signature element.

4. Initialize the System Application SignedXml codeunit:

   SignedXml.InitializeSignedXml(XmlDocument);
   

5. Call:

   SignedXml.LoadXml(SignatureElement);
   

6. Observe that the call fails with:

   Unknown transform has been encountered.
   

The same code succeeds for comparable XML signatures that use supported transforms such as:

http://www.w3.org/2000/09/xmldsig#enveloped-signature

Additional context

Our immediate use case is generic XAdES verification in Business Central.

We tested a real-world set of electronic business documents and found multiple structurally valid XAdES signatures using XPath Filter 2.0. These cannot currently be verified using the public SignedXml API because LoadXml rejects the transform before signature verification can take place.

This is distinct from the previously reported issues regarding:

• setting Reference.Type for XAdES SignedProperties;
• accessing pre-sign/canonicalized SignedInfo for external signing.

Those affect XAdES creation and external signing. This issue affects verification of existing signatures.

Supporting XPath Filter 2.0, or allowing additional XMLDSIG transforms to be registered with SignedXml, would improve interoperability without requiring consuming extensions to implement their own XML canonicalization and XMLDSIG verification engine.

We would be willing to contribute tests and, where feasible, implementation work if the required underlying transform support can be exposed through System Application.

Additional upstream runtime context

This limitation also exists in the underlying .NET System.Security.Cryptography.Xml.SignedXml implementation.

The dotnet/runtime repository tracks the same interoperability problem in:

** dotnet/runtime#82363: “SignedXml cannot validate signature that contain XPath transforms”**

The reproducer in that issue is an XAdES signature using the same standardized transform:

http://www.w3.org/2002/06/xmldsig-filter2

Therefore, this may currently be an upstream runtime limitation rather than solely a missing Business Central wrapper API.

If XPath Filter 2.0 support is added to System.Security.Cryptography.Xml in the future, it would be valuable for the Business Central System Application SignedXml abstraction to inherit or expose that capability without requiring changes in consuming AL extensions.

In the meantime, if Business Central has access to any lower-level platform implementation of the transform, exposing it through SignedXml would avoid requiring AL extensions to independently implement XPath Filter 2.0 node-set processing and XML canonicalization.

Alternatively, exposing a general transform-registration/extensibility mechanism could allow additional standardized XMLDSIG transforms to be supported without requiring a new System Application API for every transform.

I will provide a fix for a bug

• I will provide a fix for a bug

[github-actions]

🤖 AI triage completed. Product group, please validate the triage report (Microsoft internal access only, use Ctrl+Click to open in new tab).

---

_{Was this triage helpful? React with 👍 or 👎 on this comment to provide feedback.}

[marcus905]

A related architectural point came up while investigating another
unsupported XMLDSIG algorithm, Canonical XML 1.1.

The underlying System.Security.Cryptography.Xml package has a deliberately
limited feature surface, and the runtime team has confirmed that new
features are generally not being accepted there.

That means relying on future .NET support for missing XMLDSIG transforms
does not appear to be a robust long-term solution for Business Central.

I have therefore opened a separate proposal for SignedXml transform
extensibility:

#10221

If extensions could provide transform implementations associated with an
Algorithm URI, XPath Filter 2.0 support could be implemented externally for:

http://www.w3.org/2002/06/xmldsig-filter2

while keeping this issue as the concrete interoperability bug demonstrating
why that extensibility is needed.

I would be willing to contribute the transform implementation once an
appropriate System Application extensibility contract is available.