Describe the issue
The public System.IO."PDF Document" API does not expose the PDF digital-signature functionality required to create, inspect, or verify cryptographic signatures.
As a result, extensions cannot implement standards such as PAdES using Business Central's supported PDF infrastructure. They must either depend on an external PDF service or library, or reimplement low-level PDF-signing functionality in AL.
This appears to be a missing capability in the public PDF API rather than a limitation of a specific extension.
The System.IO."PDF Document" API already supports functionality such as:
- loading and inspecting PDFs;
- reading metadata and page counts;
- extracting and adding attachments;
- appending PDF documents;
- document protection;
- PDF rendering configuration.
However, it does not expose APIs for:
- creating a PDF signature field or signature dictionary;
- preparing a PDF for signing;
- calculating or retrieving
/ByteRange;
- embedding an externally generated signature;
- enumerating existing PDF signatures;
- extracting the embedded signature container from
/Contents;
- determining which PDF revision a signature covers.
This prevents extensions from implementing standard PDF-signature operations in a supported and interoperable way.
Expected behavior
The System Application should expose generic PDF digital-signature primitives through System.IO."PDF Document" or another appropriate public abstraction.
The requested functionality should provide generic PDF infrastructure, not a Business Central-specific signing workflow or a provider-specific integration.
The PDF layer should handle PDF-specific structures, while extensions remain responsible for:
- certificate selection;
- CMS/CAdES generation and verification;
- local or remote signing providers;
- trust policies;
- timestamps;
- PAdES profile rules;
- application-specific signing workflows.
Signing
A two-phase signing API would provide the greatest flexibility and support external signing providers without requiring Business Central to access private keys.
Conceptually:
PrepareSignature(
PdfInStream: InStream;
SignatureOptions: ...;
var SigningContext: ...;
var DataToSign: InStream);followed by:
CompleteSignature(
SigningContext: ...;
SignatureValue: InStream;
var SignedPdfOutStream: OutStream);The exact API shape may differ.
The PDF implementation would be responsible for:
- creating the signature dictionary and, where applicable, signature field;
- producing an incremental PDF revision;
- reserving space for
/Contents;
- calculating and writing
/ByteRange;
- returning the exact data or digest that must be signed;
- embedding the resulting signature without modifying the signed byte ranges.
The cryptographic signature could then be produced by:
- a locally available certificate;
- an HSM;
- Azure Key Vault or another key service;
- a remote signing provider;
- an eIDAS trust-service provider.
No private key would need to be passed into the PDF subsystem.
A higher-level convenience API for locally accessible certificates could be added later, but it should not be required for the initial implementation.
Verification
The same module should expose enough information to inspect and verify existing PDF signatures.
Useful functionality would include:
- enumerating digital signatures in a PDF;
- retrieving signature dictionary metadata;
- retrieving the embedded signature container from
/Contents;
- retrieving or reconstructing the bytes covered by
/ByteRange;
- identifying which PDF revision a signature covers;
- determining whether subsequent revisions exist;
- where possible, distinguishing permitted incremental updates from document modification.
The actual CMS/CAdES cryptographic verification could then be performed by System Application cryptography or by consuming extensions.
Conceptually:
PDF
↓
PDF signature parser
├─ signed byte ranges
├─ embedded CMS/CAdES
└─ revision information
↓
cryptographic/AdES verifier
Steps to reproduce
- Create or obtain a PDF using
System.IO."PDF Document".
- Attempt to create a cryptographic PDF signature.
- Attempt to enumerate or inspect existing PDF signatures.
- Attempt to retrieve the signed byte ranges or embedded signature container.
- Observe that no public API is available for these operations.
Additional context
Why this is a missing feature
The public PDF abstraction already provides several document-processing capabilities, and it is backed by Business Central's PDF-processing infrastructure, including types from Microsoft.BusinessCentral.DocumentProcessor.
If the underlying component already supports PDF digital signatures or signature inspection, the issue is that this functionality is not exposed through the public System Application API.
If the underlying component does not currently support these operations, digital-signature support should be added at that layer rather than implemented independently by every extension.
In either case, extensions currently lack a supported way to perform standard PDF-signature operations.
PAdES use case
A primary use case is implementing PAdES in AL.
For a baseline PAdES signature, the PDF contains a CMS/CAdES signature in the PDF signature structure.
The CMS/CAdES portion can be implemented independently using cryptographic APIs. However, the PDF-specific operations cannot reasonably be implemented using standard .NET cryptography APIs alone.
The standard .NET cryptography stack provides primitives such as:
- hashing;
- RSA;
- ECDSA;
- X.509 certificates;
- CMS /
SignedCms.
It does not provide a general-purpose PDF object model or PDF digital-signature writer.
Extensions therefore need support from Business Central's PDF-processing layer for:
- signature dictionaries;
- incremental updates;
- byte-range calculation;
- signature extraction;
- signature embedding;
- revision handling.
Separation of responsibilities
The desired architecture is:
PDF subsystem
────────────────────────────
PDF parsing
signature dictionary
ByteRange
incremental revisions
signature extraction/embedding
Cryptography / AdES subsystem
────────────────────────────
CMS/CAdES
certificate handling
RSA/ECDSA
timestamps
trust validation
PAdES profile policy
external signing providers
This keeps PDF internals out of application extensions while keeping signing-provider and AdES logic extensible.
Existing Business Central PDF infrastructure
System.IO."PDF Document" is implemented on top of Business Central's PDF-processing infrastructure, including Microsoft.BusinessCentral.DocumentProcessor.
Please clarify whether Microsoft.BusinessCentral.DocumentProcessor already contains non-public functionality for:
- creating PDF digital signatures;
- preparing a PDF for external signing;
- embedding a signature value;
- enumerating existing signatures;
- extracting
/Contents and /ByteRange;
- identifying signed PDF revisions.
If such functionality exists, exposing it through System Application would likely resolve this issue without requiring a new PDF implementation.
If it does not exist, this is the appropriate layer in which the functionality should be implemented.
Why this should not be implemented entirely in AL
Implementing generic PDF signing directly in an extension would require implementing a substantial subset of the PDF specification, including:
- cross-reference tables and streams;
- indirect objects;
- incremental revisions;
- signature dictionaries;
- signature fields;
- byte-range calculation;
- placeholder sizing;
- signature extraction;
- revision validation.
This is unrelated to the business logic of an AdES extension and would introduce significant compatibility, maintenance, and security risks.
A focused PDF-signature abstraction in System Application would allow multiple extensions and partners to build standards-based or provider-specific signing solutions on a common supported foundation.
Initial scope
A useful first implementation does not require:
- graphical or visible signature appearances;
- certificate-selection UI;
- signing workflows;
- PAdES-LT/LTA policy implementation.
The minimum useful primitives are:
Signing
PDF → prepare signature → data to sign
signature value → complete signature → PDF
Verification
PDF → enumerate signatures
signature → signed bytes + embedded signature + revision information
These primitives would already enable ordinary PDF digital signatures and PAdES-B-B/PAdES-B-T implementations in extensions.
We would be willing to contribute the System Application API and tests where feasible if the necessary underlying PDF functionality is available.
I will provide a fix for a bug
Describe the issue
The public
System.IO."PDF Document"API does not expose the PDF digital-signature functionality required to create, inspect, or verify cryptographic signatures.As a result, extensions cannot implement standards such as PAdES using Business Central's supported PDF infrastructure. They must either depend on an external PDF service or library, or reimplement low-level PDF-signing functionality in AL.
This appears to be a missing capability in the public PDF API rather than a limitation of a specific extension.
The
System.IO."PDF Document"API already supports functionality such as:However, it does not expose APIs for:
/ByteRange;/Contents;This prevents extensions from implementing standard PDF-signature operations in a supported and interoperable way.
Expected behavior
The System Application should expose generic PDF digital-signature primitives through
System.IO."PDF Document"or another appropriate public abstraction.The requested functionality should provide generic PDF infrastructure, not a Business Central-specific signing workflow or a provider-specific integration.
The PDF layer should handle PDF-specific structures, while extensions remain responsible for:
Signing
A two-phase signing API would provide the greatest flexibility and support external signing providers without requiring Business Central to access private keys.
Conceptually:
followed by:
The exact API shape may differ.
The PDF implementation would be responsible for:
/Contents;/ByteRange;The cryptographic signature could then be produced by:
No private key would need to be passed into the PDF subsystem.
A higher-level convenience API for locally accessible certificates could be added later, but it should not be required for the initial implementation.
Verification
The same module should expose enough information to inspect and verify existing PDF signatures.
Useful functionality would include:
/Contents;/ByteRange;The actual CMS/CAdES cryptographic verification could then be performed by System Application cryptography or by consuming extensions.
Conceptually:
Steps to reproduce
System.IO."PDF Document".Additional context
Why this is a missing feature
The public PDF abstraction already provides several document-processing capabilities, and it is backed by Business Central's PDF-processing infrastructure, including types from
Microsoft.BusinessCentral.DocumentProcessor.If the underlying component already supports PDF digital signatures or signature inspection, the issue is that this functionality is not exposed through the public System Application API.
If the underlying component does not currently support these operations, digital-signature support should be added at that layer rather than implemented independently by every extension.
In either case, extensions currently lack a supported way to perform standard PDF-signature operations.
PAdES use case
A primary use case is implementing PAdES in AL.
For a baseline PAdES signature, the PDF contains a CMS/CAdES signature in the PDF signature structure.
The CMS/CAdES portion can be implemented independently using cryptographic APIs. However, the PDF-specific operations cannot reasonably be implemented using standard .NET cryptography APIs alone.
The standard .NET cryptography stack provides primitives such as:
SignedCms.It does not provide a general-purpose PDF object model or PDF digital-signature writer.
Extensions therefore need support from Business Central's PDF-processing layer for:
Separation of responsibilities
The desired architecture is:
This keeps PDF internals out of application extensions while keeping signing-provider and AdES logic extensible.
Existing Business Central PDF infrastructure
System.IO."PDF Document"is implemented on top of Business Central's PDF-processing infrastructure, includingMicrosoft.BusinessCentral.DocumentProcessor.Please clarify whether
Microsoft.BusinessCentral.DocumentProcessoralready contains non-public functionality for:/Contentsand/ByteRange;If such functionality exists, exposing it through System Application would likely resolve this issue without requiring a new PDF implementation.
If it does not exist, this is the appropriate layer in which the functionality should be implemented.
Why this should not be implemented entirely in AL
Implementing generic PDF signing directly in an extension would require implementing a substantial subset of the PDF specification, including:
This is unrelated to the business logic of an AdES extension and would introduce significant compatibility, maintenance, and security risks.
A focused PDF-signature abstraction in System Application would allow multiple extensions and partners to build standards-based or provider-specific signing solutions on a common supported foundation.
Initial scope
A useful first implementation does not require:
The minimum useful primitives are:
Signing
Verification
These primitives would already enable ordinary PDF digital signatures and PAdES-B-B/PAdES-B-T implementations in extensions.
We would be willing to contribute the System Application API and tests where feasible if the necessary underlying PDF functionality is available.
I will provide a fix for a bug