Describe the issue
The System Application cryptography abstraction does not currently support ECDSA signatures.
The public SignatureAlgorithm enum exposes RSA, DSA and RSASSA-PSS, but does not expose ECDSA.
This prevents AL applications from signing or verifying data using EC-backed X.509 certificates through the native Business Central cryptography APIs, even though the underlying .NET cryptography stack provides ECDSA support.
This is an interoperability problem for applications that need to consume or produce digital signatures created with EC certificates.
A particularly relevant use case is EU electronic-signature interoperability: qualified certificates and signatures are not restricted to RSA, and ECDSA is used by European trust-service ecosystems.
The issue is not that ECDSA itself defines a qualified signature.
QES status also depends on the certificate, trust-service status, signing device/service, signature format and validation policy.
The missing capability is the lower-level cryptographic primitive needed to handle legitimate ECDSA-backed signatures from AL.
SignatureAlgorithm is not extensible, so an extension cannot add an ECDSA implementation to the existing abstraction independently.
Expected behavior
The System Application cryptography APIs should support ECDSA signing and verification in the same general way that RSA and other currently supported signature algorithms are exposed.
SignatureAlgorithm should include an ECDSA implementation backed by the underlying System.Security.Cryptography.ECDsa functionality.
At minimum, ECDSA should support:
and EC certificates using commonly deployed curves such as:
- NIST P-256 / secp256r1
- NIST P-384 / secp384r1
- NIST P-521 / secp521r1
Support for the commonly used Brainpool curves would also be valuable for European interoperability:
- brainpoolP256r1
- brainpoolP384r1
- brainpoolP512r1
For verification, the curve should normally be obtained from the X.509 certificate/public key rather than requiring the AL caller to select the curve manually.
Existing SignData / VerifyData-style APIs should be usable with EC keys and certificates where appropriate.
Steps to reproduce
-
Obtain or create an X.509 certificate containing an EC public key.
-
In AL, attempt to select an ECDSA signature algorithm using the System Application cryptography APIs.
-
Observe that SignatureAlgorithm exposes the currently supported algorithms such as RSA, DSA and RSASSA-PSS, but there is no ECDSA option.
-
Attempt to verify an ECDSA signature using the public System Application signing/verification abstractions.
-
Observe that there is no supported native AL path for performing the ECDSA verification operation.
The same limitation affects signing when an EC private key is available to Business Central.
A practical example is a CMS/CAdES or XMLDSIG signature whose signer certificate contains an EC public key and whose signature algorithm is ECDSA with SHA-256.
The surrounding signature structure can be parsed in AL, but the actual cryptographic signature verification cannot be completed using the current System Application abstraction.
Additional context
The underlying .NET cryptography platform already exposes ECDSA through System.Security.Cryptography.ECDsa and EC curves through ECCurve.
X.509 certificates can expose their EC public keys directly, so this should primarily require exposing the existing platform capability through System Application rather than implementing elliptic-curve cryptography in AL.
The strongest requirement is verification.
Business Central applications may receive documents or signatures generated by external citizens, companies, trust-service providers, HSMs or remote signing services using ECDSA.
Without native ECDSA verification, an AL extension must rely on an external service solely to perform a cryptographic primitive already available in the underlying runtime.
This also affects remote-signing integrations.
An external signer can return a valid ECDSA signature together with its signer certificate, but Business Central cannot currently verify the returned signature locally before embedding it into a CAdES, XAdES or PAdES structure.
Adding ECDSA support would therefore benefit both:
- verification of incoming signatures;
- verification of externally produced signatures before completing a document-signature container.
This request is intentionally limited to the cryptographic primitive.
It does not imply that an ECDSA signature alone is a qualified electronic signature under eIDAS; qualification and trust validation are separate
concerns.
I would be willing to contribute the System Application implementation and tests if this change is considered appropriate.
I will provide a fix for a bug
Describe the issue
The System Application cryptography abstraction does not currently support ECDSA signatures.
The public SignatureAlgorithm enum exposes RSA, DSA and RSASSA-PSS, but does not expose ECDSA.
This prevents AL applications from signing or verifying data using EC-backed X.509 certificates through the native Business Central cryptography APIs, even though the underlying .NET cryptography stack provides ECDSA support.
This is an interoperability problem for applications that need to consume or produce digital signatures created with EC certificates.
A particularly relevant use case is EU electronic-signature interoperability: qualified certificates and signatures are not restricted to RSA, and ECDSA is used by European trust-service ecosystems.
The issue is not that ECDSA itself defines a qualified signature.
QES status also depends on the certificate, trust-service status, signing device/service, signature format and validation policy.
The missing capability is the lower-level cryptographic primitive needed to handle legitimate ECDSA-backed signatures from AL.
SignatureAlgorithm is not extensible, so an extension cannot add an ECDSA implementation to the existing abstraction independently.
Expected behavior
The System Application cryptography APIs should support ECDSA signing and verification in the same general way that RSA and other currently supported signature algorithms are exposed.
SignatureAlgorithm should include an ECDSA implementation backed by the underlying System.Security.Cryptography.ECDsa functionality.
At minimum, ECDSA should support:
and EC certificates using commonly deployed curves such as:
Support for the commonly used Brainpool curves would also be valuable for European interoperability:
For verification, the curve should normally be obtained from the X.509 certificate/public key rather than requiring the AL caller to select the curve manually.
Existing SignData / VerifyData-style APIs should be usable with EC keys and certificates where appropriate.
Steps to reproduce
Obtain or create an X.509 certificate containing an EC public key.
In AL, attempt to select an ECDSA signature algorithm using the System Application cryptography APIs.
Observe that SignatureAlgorithm exposes the currently supported algorithms such as RSA, DSA and RSASSA-PSS, but there is no ECDSA option.
Attempt to verify an ECDSA signature using the public System Application signing/verification abstractions.
Observe that there is no supported native AL path for performing the ECDSA verification operation.
The same limitation affects signing when an EC private key is available to Business Central.
A practical example is a CMS/CAdES or XMLDSIG signature whose signer certificate contains an EC public key and whose signature algorithm is ECDSA with SHA-256.
The surrounding signature structure can be parsed in AL, but the actual cryptographic signature verification cannot be completed using the current System Application abstraction.
Additional context
The underlying .NET cryptography platform already exposes ECDSA through System.Security.Cryptography.ECDsa and EC curves through ECCurve.
X.509 certificates can expose their EC public keys directly, so this should primarily require exposing the existing platform capability through System Application rather than implementing elliptic-curve cryptography in AL.
The strongest requirement is verification.
Business Central applications may receive documents or signatures generated by external citizens, companies, trust-service providers, HSMs or remote signing services using ECDSA.
Without native ECDSA verification, an AL extension must rely on an external service solely to perform a cryptographic primitive already available in the underlying runtime.
This also affects remote-signing integrations.
An external signer can return a valid ECDSA signature together with its signer certificate, but Business Central cannot currently verify the returned signature locally before embedding it into a CAdES, XAdES or PAdES structure.
Adding ECDSA support would therefore benefit both:
This request is intentionally limited to the cryptographic primitive.
It does not imply that an ECDSA signature alone is a qualified electronic signature under eIDAS; qualification and trust validation are separate
concerns.
I would be willing to contribute the System Application implementation and tests if this change is considered appropriate.
I will provide a fix for a bug