Summary

Business Central System Application already provides useful cryptographic primitives, including X.509 certificate handling, hashing, signing, verification, and XML digital-signature functionality.

However, Business Central does not currently expose a reusable abstraction for standardized signed-document formats such as CMS/PKCS#7, CAdES, XAdES, and potentially PAdES.

This creates a gap for extensions that need to receive, inspect, verify, extract, or create digitally signed business documents.

We propose adding reusable digital-signature format support to System Application, initially focused on CMS/CAdES and XMLDSIG/XAdES, while designing the abstraction so that formats such as PAdES can be added later.

This proposal is suitable for open-source contribution through BCApps, and we would be willing to contribute the implementation and automated tests.

Problem

A Business Central extension may need to consume or create documents carrying electronic signatures.

Examples include:

XML documents containing XMLDSIG/XAdES signatures;

CMS/PKCS#7 SignedData containers;

CAdES documents such as .p7m;

XML documents that must be signed using XAdES;

and, in the future, PDF documents carrying PAdES signatures.

Business Central exposes many of the underlying cryptographic primitives, but no reusable application-level abstraction for these signed-document formats.

Extensions must therefore implement format-specific processing themselves, depend on external services, or create application-specific workarounds around functionality that is fundamentally generic security and document-processing infrastructure.

Example Scenario 1: Electronic Document Exchange

A practical example is Italian electronic invoicing.

Invoices exchanged through Sistema di Interscambio may be received as XML documents wrapped in a CAdES/CMS container, typically using the .xml.p7m extension.

Before processing the invoice XML, an extension may need to:

recognize the CMS/CAdES document;

extract the original embedded payload without modifying it;

inspect signer and certificate information;

verify the cryptographic signature.

Electronic-document scenarios may also require Business Central to produce XML documents carrying XAdES signatures before transmission to an authority, service, or business partner.

These requirements are not specific to Italian invoicing. CAdES and XAdES are used in electronic document exchange, e-government, regulated workflows, and integrations across multiple countries and industries.

Example Scenario 2: Signed Business Documents

Another generic scenario is associating a digitally signed document with a Business Central record, such as a:

sales quote or order;

posted invoice;

purchase document;

project;

contract;

approval or other business record.

The document could be a CAdES signed file or, with future PAdES support, a signed PDF.

A consuming application could use the common signature API to determine:

the signature format;

whether the signed content was modified;

which certificate was used;

signer identity information available from the certificate;

and whether the cryptographic signature is valid.

This enables workflows around signed contracts, accepted quotations, project documents, approvals, and other legally or commercially relevant records without every application reimplementing signature processing.

In the European Union, such workflows may also involve qualified electronic signatures (QES), which under eIDAS have the equivalent legal effect of handwritten signatures.

Determining whether a particular signature is a valid QES requires additional trust and qualification validation, including certificate status, trust-service information, and Trusted Lists. That higher-level regulatory validation should be separate from the core format and cryptographic layer.

Proposed Capability

We suggest introducing a generic, stream-based digital-signature abstraction in System Application.

The exact API could be determined together with the Business Central engineering team, but intended capabilities would include:

detecting supported signature formats;

enumerating signatures where applicable;

exposing signature, signer, and certificate metadata;

verifying cryptographic signatures;

detecting modification to signed content;

extracting embedded content for encapsulating formats such as CMS/CAdES;

creating signatures for supported formats;

supporting both locally performed and externally performed signing operations;

operating on InStream and OutStream values.

Conceptually, inspection and verification could provide operations equivalent to:

GetFormat(InputStream, Format)

GetSignatures(InputStream, Signatures)

GetSignatureInfo(InputStream, Signature, SignatureInfo)

Verify(InputStream, Signature, VerificationResult)

For encapsulating formats:

ExtractContent(InputStream, OutputStream)

For signature creation:

PrepareSignature(InputStream, SignatureOptions, SigningRequest)

CompleteSignature(SigningRequest, SignatureValue, OutputStream)

A convenience operation could also perform signing directly when Business Central has access to an appropriate signing key.

The separation between PrepareSignature and CompleteSignature is important because Business Central should not assume it has custody of the private key.

External Signing

In many real-world scenarios, especially for qualified or centrally managed signatures, the private key may be held by:

a remote signing service;

a qualified trust service provider;

an HSM;

a centralized corporate signing service;

or another external cryptographic provider.

Business Central may instead construct the appropriate AdES structure, calculate or prepare the exact data that must be signed, send that information to the external signing provider, receive the resulting cryptographic signature, and then complete the AdES document.

This allows the same format layer to support both:

local signing, where Business Central can perform the private-key operation; and

external signing, where the private-key operation is performed elsewhere.

The format implementation should remain responsible for canonicalization, signed attributes, XML structures, or other format-specific preparation so that remote signing integrations do not need to understand the internal construction rules of XAdES, CAdES, or future PAdES implementations.

Suggested Initial Scope

The initial implementation could include:

CMS/PKCS#7 SignedData detection;

CAdES detection;

lossless extraction of encapsulated CMS/CAdES content;

basic signer and certificate information;

CMS/CAdES cryptographic verification where supported by existing Business Central primitives;

XMLDSIG/XAdES detection and verification;

XAdES signature creation;

XAdES creation using either a local signing operation or an external signing workflow;

modification detection;

automated tests using reproducible or generated test vectors.

Including XAdES creation in v1 ensures that the public abstraction supports both signature consumption and creation from the beginning.

XAdES is also a practical first format for testing the creation API because Business Central already provides much of the required XML digital-signature and cryptographic functionality.

Future Extensibility

The abstraction should allow additional capabilities without changing consuming applications.

Potential later additions include:

CAdES signature creation;

PAdES parsing, verification, and creation;

timestamped profiles such as XAdES-T and CAdES-T;

long-term-validation and archival profiles;

timestamp authority integration;

additional signed and unsigned properties;

HSM-backed and qualified remote signing providers.

PAdES is deliberately not proposed as part of the initial implementation because it also requires PDF-format parsing and signature-aware PDF processing.

However, generic operations such as format detection, signature enumeration, metadata inspection, verification, and creation should be designed so that a future PAdES provider can implement the same abstraction.

Trust and Regulatory Validation

The core format provider should establish technical and cryptographic facts such as:

whether the signature structure is valid;

whether the signed digest matches;

whether the cryptographic signature verifies;

whether signed content has been modified;

which certificate and signer information are present.

Higher-level questions can require external and jurisdiction-specific information, for example:

certificate validity and revocation status;

trust-service provider status;

certificate qualification;

QES qualification;

timestamp validity;

long-term validation status.

These decisions should not be hard-coded into the document-format layer.

For example, a separate eIDAS-oriented extension could consume the signature and certificate information exposed by System Application and combine it with EU/EEA Trusted Lists and the appropriate validation policy.

Why System Application

This functionality is not specific to a business process, localization, document type, or jurisdiction.

It belongs conceptually alongside the existing security and cryptography functionality in System Application.

A common implementation could be reused by:

localization and E-Document extensions;

document and contract management solutions;

approval and workflow applications;

public-sector integrations;

regulatory-validation extensions;

partner applications.

This avoids multiple extensions independently parsing or constructing the same standard signature formats.

Contribution

We are currently designing a standalone AL implementation of this capability for real-world electronic-document integration scenarios.

Our intention is to keep it independent of the Italian localization and structure it as a reusable digital-signature module with automated tests.

The initial work would focus on:

the generic signature abstraction;

CMS/CAdES detection and payload extraction;

signature inspection and verification;

XAdES verification;

XAdES creation with both local and external signing flows;

automated interoperability and regression tests.

We would be happy to contribute the generic implementation to BCApps if Microsoft considers this functionality appropriate for System Application.

We are also happy to adapt the API, architecture, and scope to Microsoft's preferred System Application design.

We therefore request that this idea be considered for open-source contribution.