Hoe toon ik aan wanneer een document is ontstaan?

Om aan te tonen dat een document op een bepaalde datum bestond, hash je het document en stuur je die hash naar een betrouwbare Timestamp Authority, die een ondertekend token teruggeeft waarin de hash aan een tijdstip wordt gekoppeld dat zij bevestigt. Dat token is bewijs dat een derde kan controleren zonder jou te hoeven geloven. Een datum in je eigen bestandssysteem, database of documentmetadata is geen bewijs, want die beheer je zelf.

Hoe je aantoont dat een document op een bepaalde datum bestond

Het probleem met je eigen datums

Elke datum die je over je eigen document kunt produceren, is door jou geproduceerd. De tijdstempel van het bestandssysteem, de aangemaakt-op-kolom in je database, de datum op pagina één, de metadata in de pdf: ze staan allemaal onder beheer van de partij die wil dat ze geloofd worden.

Dat is geen verwijt, het is de vorm van het probleem. Een auditor, een wederpartij of een rechter kan een eerlijke datum niet onderscheiden van een goed uitkomende datum als beide uit dezelfde bron komen. Geschillen over voorgebruik, ingangsdata van contracten, opzegtermijnen, startdata van bewaartermijnen en aanspraken op intellectueel eigendom draaien hierop, en ze draaien erop jaren na dato.

Hoe een betrouwbare tijdstempel dat oplost

RFC 3161 beschrijft een klein protocol met een groot gevolg.

Hash het document. Een cryptografische hashfunctie maakt een vingerafdruk van vaste lengte. Elke wijziging in het document, al is het één byte, levert een volledig andere vingerafdruk op.
Verstuur alleen de hash. Het verzoek gaat naar een Timestamp Authority, een derde partij die een ondertekendienst draait. Het document zelf verlaat je systemen nooit, dus dit werkt ook voor materiaal dat je niet mag delen.
Ontvang een ondertekend token. De Timestamp Authority stuurt een token terug met jouw hash en het tijdstip, ondertekend met haar eigen sleutel.
Bewaar het token bij het document.

Wat het token vaststelt is precies, en het is de moeite waard om het precies te zeggen: deze exacte inhoud bestond uiterlijk op dat moment, en is sindsdien niet veranderd. Dat is een eenzijdige grens. Het bewijst dat het document niet jonger is dan de tijdstempel. Het bewijst niet dat het niet ouder is.

Zorgen dat het over tien jaar nog werkt

Dit is het deel dat de meeste implementaties overslaan, en het faalt geruisloos.

Een tijdstempeltoken wordt geverifieerd tegen het certificaat van de Timestamp Authority. Certificaten zijn één tot drie jaar geldig. Om in 2035 een token uit 2026 te verifiëren, heeft een strikte verificatie drie dingen nodig die vandaag bestaan en dan niet meer: de volledige certificaatketen zoals die was, de intrekkingsstatus op het moment van ondertekenen, en een algoritme dat dan nog als deugdelijk geldt.

Bewaar het verificatiemateriaal dus naast het token, op het moment dat je het aanmaakt. Periodiek opnieuw tijdstempelen met een actueel algoritme, voordat het vorige verzwakt, verlengt de levensduur van de hele keten. Geen van beide kan met terugwerkende kracht.

Waar SealDoc past

SealDoc vraagt standaard voor elk document dat het verwerkt een RFC 3161-tijdstempel aan, legt een SHA-384 hashketen en een chain-of-custody-registratie vast, en levert het resultaat als een PDF/A-3B-bestand, met per document een bewijspakket op aanvraag. Alleen de hash gaat naar de Timestamp Authority, dus het document blijft binnen Europese infrastructuur.