A Report Must Stay Readable Longer Than the Software That Created It
GMP documentation is retained for years, often for decades. A PDF displayed correctly today must still look identical when the font used is no longer installed, the colour profile of the screen of the time no longer available and the reader then in use long superseded. That is precisely what PDF/A exists for – a format that makes no assumptions about its environment.
What PDF/A Is – and What Level 3b Means
PDF/A is defined in the ISO 19005 series of standards; part 3 – ISO 19005-3 – describes PDF/A-3. Within each part there are conformance levels: level "b" (basic) guarantees faithful visual reproduction, while level "a" (accessible) additionally requires the document to be fully structured logically for accessibility. For a measurement report whose purpose is the unaltered reproduction of evidence, level "b" is the established route – and that is exactly what Moqlero produces: PDF/A-3b.
What Happens Inside the Document
Archivability does not come from a label but from concrete properties of the document. Five things are therefore ensured when a report is created:
- Embedded colour profile: an sRGB ICC profile is stored in the document as an output intent. Only this makes device-dependent colour spaces admissible at all, and it keeps colour reproduction defined independently of the output device.
- Embedded fonts: every font used is embedded in the document. The document therefore does not rely on the font being present on the displaying system – the most common reason why old PDFs suddenly break differently.
- No inadmissible image properties: properties that PDF/A prohibits at every level are removed – such as the interpolation flag that the rendering engine sets on images and their transparency masks during generation.
- PDF/A identification in the metadata: the XMP metadata carry the identification for part and conformance level. Title, producer and timestamps are kept synchronous between XMP and the info dictionary, because PDF/A requires equality for properties held in both places.
- Attachments are permitted: unlike PDF/A-1 and PDF/A-2, the third edition allows arbitrary files to be embedded as attachments. That is the formal basis for carrying supporting documents directly with the report instead of filing them alongside it.
The Signature Becomes Visible
Until now every report was cryptographically signed, but the signature field itself remained invisible within the document – without a position and without an appearance. A visible signature field is now created at a defined position, with its own appearance and the Moqlero logo. It is clickable in the reader and opens the signature validation dialogue directly. This is not only more convenient, it is also required by the standard: a form field without an appearance stream is not permitted in PDF/A.
Order Matters: PDF/A First, Then Sign
The PDF/A preparation is the last complete write operation before signing. That is not a detail but a necessity: merging several partial documents and adding page numbers each create a new document catalogue, and the metadata and output intent are attached to that catalogue – set too early, they would be lost along the way. Signing then happens incrementally, so the already archivable content stays untouched and the signature secures exactly that state. The report server certificate and private key come from the database, and validation is performed against the stored root certificate.
From Exception to Default
The second change is a change of default: PDF/A-3b is now the standard case for report generation. Previously, without explicit configuration an ordinary PDF was produced; a report only became archivable if someone had remembered to configure it. That order has been reversed – a report without PDF/A is now only reachable through an explicit configuration entry. The preparation is meanwhile implemented entirely within report generation and therefore needs no additional external tool on the server, which makes the route platform-independent and operations simpler.
Archivably Readable Is Not the Same as Permanently Verifiable: LTV
PDF/A ensures that a document will still be displayed the same way in ten years. It says nothing about whether the signature can then still be automatically demonstrated to be valid. There is a separate term for that: LTV – long term validation. It means that all the information needed to validate a signature is carried inside the document itself: the complete certificate chain, the revocation status of the certificates involved from an OCSP response or revocation list, and a timestamp from an independent time source. In a PDF this information resides in a dedicated area of the document, the document security store; the corresponding signature profiles are described by the ETSI PAdES series of standards in levels B-LT and B-LTA.
Why This Matters Particularly in GMP Environments
The reason is mundane and nevertheless consequential: retention periods are longer than certificate lifetimes. A signing certificate is typically valid for one to three years, while GMP documentation is retained for a decade and more. Without embedded validation information, a viewer can later only establish that the document has not changed since it was signed – but not that the certificate used was valid and not revoked at the time of signing. It is this second statement that gives a signature its evidential weight. The timestamp adds to this: without it, the signing time shown rests on the clock of the signing system; with it, on an independent source.
Where Moqlero Stands Today
The building blocks are in place and in use: every report is signed with the report server certificate, validation is performed against the stored root certificate, and a dedicated OCSP responder is operated in the Moqlero environment to establish the revocation status of certificates. What is not embedded in the report itself so far is this validation information together with a timestamp. The signature is therefore verifiable as long as the certificate infrastructure is reachable; embedding to PAdES-LTV is the next development step and not a delivered feature today. We state this explicitly because "signed" and "permanently verifiable" are readily treated as the same thing in specifications – and the difference tends to surface exactly when it can no longer be remedied.
What PDF/A Delivers – and What It Does Not
PDF/A secures the reproducibility of the document – no more and no less. It replaces neither the signature strategy, as the previous section shows, nor the audit trail: who created, released or regenerated the report is still recorded there and not in the document. What PDF/A guarantees is the basis for everything else – that what was signed can still be read exactly that way later on.
Data integrity does not end at creation – it has to outlast the retention period!