Describe the issue
The System Application SignedXml abstraction currently depends on the set
of XMLDSIG transforms implemented by the underlying
System.Security.Cryptography.Xml library.
This creates an interoperability limitation for standards-compliant XML
signatures that use transforms not implemented by the .NET runtime.
Two concrete examples already encountered in real XAdES business documents
are:
Both are standardized XML signature algorithms, but neither can currently
be processed through the Business Central SignedXml abstraction.
Waiting for the underlying .NET implementation is not sufficient as a
general solution. In particular, the Canonical XML 1.1 feature request in
dotnet/runtime was closed as not planned because
System.Security.Cryptography.Xml is not accepting new features.
Rather than adding individual transforms directly to System Application,
SignedXml should provide an extensibility mechanism that allows AL
extensions to supply implementations for otherwise unsupported XMLDSIG
transform algorithms.
This would also avoid having to add a new System Application API every time
another valid XMLDSIG transform is encountered.
Expected behavior
SignedXml should allow extensions to provide an implementation for XMLDSIG
transform and canonicalization algorithms that are not implemented by the
underlying runtime.
Ideally, a transform implementation would be associated with its Algorithm
URI and could participate in the XMLDSIG processing pipeline when that URI
is encountered.
The abstraction should account for the fact that XMLDSIG transforms do not
all have the same input/output type:
- some transforms operate on XML node sets;
- canonicalization transforms convert XML node sets to octets;
- subsequent transforms and digest calculation operate on those results.
Alternatively, if plugging custom transforms directly into SignedXml is
not feasible, exposing enough of the XMLDSIG processing pipeline for an
extension to perform unsupported transforms and verification externally
would also solve the problem.
Useful lower-level capabilities could include access to:
- SignedInfo
- CanonicalizationMethod
- SignatureMethod
- SignatureValue
- Reference collection
- Reference URI
- Transform definitions
- DigestMethod
- DigestValue
The important requirement is that an extension should not need to
reimplement the complete XMLDSIG parser merely because one transform is
unsupported by the underlying .NET implementation.
Steps to reproduce
The limitation can currently be reproduced through either of the following
existing interoperability cases.
Case 1 - Canonical XML 1.1
-
Load a valid XMLDSIG document whose SignedInfo or Reference transform
chain uses:
http://www.w3.org/2006/12/xml-c14n11
-
Pass the Signature element to the System Application SignedXml
implementation.
-
Attempt to verify the signature.
-
The signature cannot be processed because the underlying implementation
has no Canonical XML 1.1 transform.
The corresponding dotnet/runtime request was closed as not planned because
System.Security.Cryptography.Xml is not accepting new features.
Case 2 - XPath Filter 2.0
-
Load a valid XMLDSIG/XAdES document containing a Reference transform
using:
http://www.w3.org/2002/06/xmldsig-filter2
-
Pass the Signature element to SignedXml.
-
Attempt to load/verify the signature.
-
SignedXml cannot process the transform.
Both documents are standards-compliant. The failure is caused by the
closed set of transforms available through the current SignedXml stack.
Additional context
This was encountered while implementing generic AdES/XAdES support on top
of the Business Central System Application cryptographic APIs.
Separate issues have already been reported for the two currently known
interoperability cases:
- Canonical XML 1.1:
- XPath Filter 2.0:
Upstream .NET issue for Canonical XML 1.1:
dotnet/runtime#132231
That issue was closed as "not planned"; the maintainer explained that
System.Security.Cryptography.Xml is not accepting new features.
XPath Filter 2.0 is also currently unsupported by
System.Security.Cryptography.Xml.
A generic extensibility mechanism would therefore be preferable to adding
one-off support for each transform to Business Central.
I would be willing to contribute the Business Central-side implementation
and/or concrete transform implementations if an appropriate extensibility
contract is agreed upon.
I will provide a fix for a bug
Describe the issue
The System Application SignedXml abstraction currently depends on the set
of XMLDSIG transforms implemented by the underlying
System.Security.Cryptography.Xml library.
This creates an interoperability limitation for standards-compliant XML
signatures that use transforms not implemented by the .NET runtime.
Two concrete examples already encountered in real XAdES business documents
are:
Canonical XML 1.1
http://www.w3.org/2006/12/xml-c14n11
XPath Filter 2.0
http://www.w3.org/2002/06/xmldsig-filter2
Both are standardized XML signature algorithms, but neither can currently
be processed through the Business Central SignedXml abstraction.
Waiting for the underlying .NET implementation is not sufficient as a
general solution. In particular, the Canonical XML 1.1 feature request in
dotnet/runtime was closed as not planned because
System.Security.Cryptography.Xml is not accepting new features.
Rather than adding individual transforms directly to System Application,
SignedXml should provide an extensibility mechanism that allows AL
extensions to supply implementations for otherwise unsupported XMLDSIG
transform algorithms.
This would also avoid having to add a new System Application API every time
another valid XMLDSIG transform is encountered.
Expected behavior
SignedXml should allow extensions to provide an implementation for XMLDSIG
transform and canonicalization algorithms that are not implemented by the
underlying runtime.
Ideally, a transform implementation would be associated with its Algorithm
URI and could participate in the XMLDSIG processing pipeline when that URI
is encountered.
The abstraction should account for the fact that XMLDSIG transforms do not
all have the same input/output type:
Alternatively, if plugging custom transforms directly into SignedXml is
not feasible, exposing enough of the XMLDSIG processing pipeline for an
extension to perform unsupported transforms and verification externally
would also solve the problem.
Useful lower-level capabilities could include access to:
The important requirement is that an extension should not need to
reimplement the complete XMLDSIG parser merely because one transform is
unsupported by the underlying .NET implementation.
Steps to reproduce
The limitation can currently be reproduced through either of the following
existing interoperability cases.
Case 1 - Canonical XML 1.1
Load a valid XMLDSIG document whose SignedInfo or Reference transform
chain uses:
http://www.w3.org/2006/12/xml-c14n11
Pass the Signature element to the System Application SignedXml
implementation.
Attempt to verify the signature.
The signature cannot be processed because the underlying implementation
has no Canonical XML 1.1 transform.
The corresponding dotnet/runtime request was closed as not planned because
System.Security.Cryptography.Xml is not accepting new features.
Case 2 - XPath Filter 2.0
Load a valid XMLDSIG/XAdES document containing a Reference transform
using:
http://www.w3.org/2002/06/xmldsig-filter2
Pass the Signature element to SignedXml.
Attempt to load/verify the signature.
SignedXml cannot process the transform.
Both documents are standards-compliant. The failure is caused by the
closed set of transforms available through the current SignedXml stack.
Additional context
This was encountered while implementing generic AdES/XAdES support on top
of the Business Central System Application cryptographic APIs.
Separate issues have already been reported for the two currently known
interoperability cases:
Upstream .NET issue for Canonical XML 1.1:
dotnet/runtime#132231
That issue was closed as "not planned"; the maintainer explained that
System.Security.Cryptography.Xml is not accepting new features.
XPath Filter 2.0 is also currently unsupported by
System.Security.Cryptography.Xml.
A generic extensibility mechanism would therefore be preferable to adding
one-off support for each transform to Business Central.
I would be willing to contribute the Business Central-side implementation
and/or concrete transform implementations if an appropriate extensibility
contract is agreed upon.
I will provide a fix for a bug