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

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:

** https://github.com/dotnet/runtime/issues/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

Start at the System Application SignedXml API and reproduce the failure at LoadXml with a signature containing the XPath Filter 2.0 transform. Read the linked dotnet/runtime issue to determine whether the limitation is upstream, then assess what transform support or registration capability the public API can expose. Done means valid signatures using this transform can be loaded and verified, with tests covering the behavior.