Een bewijspakket zelf controleren, zonder de leverancier

Een bewijspakket is alleen iets waard als u het offline kunt controleren, met gereedschap dat al op de computer staat, tegen een rootcertificaat dat u zelf ophaalt in plaats van een certificaat dat met het pakket meereisde. Werkt die controle niet meer op de dag dat de leverancier ermee ophoudt, dan hebt u geen bewijs in handen. Dan hebt u een abonnement.

Belangrijkste punten

• Een bewijspakket moet een buitenstaander in staat stellen de bewering vanaf nul na te rekenen. Daar zijn vier dingen voor nodig: uw document, het tijdstempeltoken, het pad van de hash van uw document terug naar de gestempelde wortel, en een instructie geschreven voor iemand die dit alles nooit eerder heeft gezien. Alleen het document blijft bij u.

• Een Merkle-boom is eerst een privacykeuze en pas daarna een snelheidskeuze. Bij een platte lijst zou u de hashes moeten overhandigen van elk ander document dat die dag is verankerd, ook die van anderen.

• Op grond van artikel 41 lid 2 eIDAS geniet een gekwalificeerde elektronische tijdstempel het vermoeden dat de aangegeven datum en tijd juist zijn en dat de daaraan gebonden gegevens integer zijn. Dat vermoeden staat in artikel 41, niet in artikel 42.

• De bewaartermijn voor bewijs staat bij PDFen standaard op twintig jaar, apart ingesteld van hoe lang het document zelf wordt bewaard.

• Bewaar de originele bytes precies zoals u ze ontving. Opnieuw opslaan zorgt ervoor dat de hash niet meer klopt, en de Raad van State heeft dat zien gebeuren binnen de eigen keten van de Rechtspraak.

De wederpartij controleert de eigen kopie, nooit die van ons: een pakket met ónze kopie van het document zou alleen iets over onze kopie bewijzen.

Wat hoort er in een bewijspakket, en waarom?

Vier dingen moeten aanwezig zijn voordat een buitenstaander de bewering kan narekenen. Het document zelf. Het token dat een hash aan een moment bindt. Het pad van de hash van dat document omhoog naar de gestempelde wortel. En een geschreven instructie, want een derde die de constructie moet raden, verifieert niets.

Eén van die vier ontbreekt in wat wij versturen, en dat is het document. In het normale geval bevat het pakket vier bestanden: proof.json, README.txt, timestamp.tsr en de tussenliggende certificaten in tsa-chain.pem. De laatste twee verschijnen zodra de ronde daadwerkelijk is gestempeld en de dienstverlener zijn keten heeft geleverd.

De redenering achter het ontbrekende document is ongemakkelijk maar sluitend. Een pakket met ónze kopie zou alleen iets over onze kopie bewijzen. De kopie waar het geschil over gaat ligt bij u op het bureau, en dat is dus de kopie die tijdens de controle naast deze bestanden hoort te liggen. Dat heeft twee neveneffecten: een uitgelekte link geeft geen cliëntmateriaal prijs, en het pakket blijft klein genoeg om als e-mailbijlage te reizen.

proof.json bevat de SHA-256 van het document, de positie in de boom, de zusterhashes met de vermelding of ze links of rechts staan, de wortelhash, de naam van de tijdstempeldienst en een uitgeschreven regel voor de manier waarop bladeren en knopen worden gecombineerd. Dat laatste weegt zwaarder dan het lijkt. Zonder die regel moet een derde raden hoe de boom is opgebouwd, en raden is geen verificatie.

Waarom een Merkle-boom en geen platte lijst?

Vanwege privacy, niet vanwege doorvoersnelheid. Die volgorde is het hele argument.

Stel dat de documenten van een dag als platte lijst werden verankerd, met als wortel een hash over die lijst. Om te bewijzen dat uw contract erin zat, zou u die lijst moeten reproduceren. De hele lijst. Dat betekent dat u de wederpartij de hashes overhandigt van elk ander document dat die dag is gestempeld, inclusief documenten van partijen die niets met uw geschil te maken hebben. U zou een cliëntenlijst lekken om een punt over één PDF te winnen.

Een boom haalt dat probleem weg. U levert alleen de knopen die direct naast uw pad omhoog liggen. Elke verdubbeling van de batch kost precies één zusterhash extra, dus een drukke dag kost een paar regels meer in een JSON-bestand in plaats van een datalek.

Het verankeren gebeurt eenmaal per dag, om 03:00 uur Europe/Amsterdam. Eén ronde, één boom, één aanroep naar de tijdstempeldienst, of die ronde nu vier documenten bevat of vierduizend. Alleen de wortelhash verlaat het pand. Die zuinigheid maakt het mogelijk dat de dagelijkse ronde alles meeneemt wat binnenkwam, in plaats van alleen de documenten die iemand toevallig heeft aangevinkt. Eén specifieke PDF op verzoek stempelen is een aparte, betaalde handeling: de tool voor gekwalificeerde tijdstempels doet dat, één bestand tegelijk.

Waarom blijft het bewijs bestaan als het bestand allang weg is?

Omdat het bewijsrecord en het document twee verschillende dingen zijn met een verschillende levensduur, en wij ze bewust ook zo behandelen.

Een bewijsrecord is een hash, een bladpositie, een korte lijst zusterhashes en een verwijzing naar de ronde waar het bij hoort. Een paar honderd bytes, met opslagkosten die het noemen niet waard zijn. Met het document dat het beschrijft ligt dat anders: dat volgt de gewone bewaartermijn en wordt volgens schema opgeruimd, zoals het hoort.

De bewaartermijn voor bewijs staat hier standaard op twintig jaar, los ingesteld van de bewaartermijn voor bestanden. Het verwijderen van het resultaat wist het hashrecord niet. Vijf jaar nadat een zaak is gesloten, met de PDF allang opgeruimd, klopt de rekensom nog steeds – mits de wederpartij zijn kopie heeft bewaard.

Hier gaan de belangen van een leverancier ongemerkt schuiven. Ligt uw bewijs in het archief van een ander, dan heeft die ander er belang bij dat u voor dat archief blijft betalen, en dan is onbeperkte opslag geen gulheid meer maar het slot op de deur.

Waarom ontbreekt het rootcertificaat met opzet?

Omdat een token valideren tegen een root die in dezelfde envelop zat een integriteitscontrole is, verkleed als vertrouwenscontrole.

Kijk naar wat u toetst. De keten in tsa-chain.pem laat zien dat het token intern consistent is. Prima. Maar consistentie met een root die wij zelf hebben aangereikt, bewijst alleen dat wij consistent zijn met onszelf. Wie het token kan vervalsen, kan de root ernaast net zo goed vervalsen. De controle slaagt, de conclusie is waardeloos, en het geheel ziet eruit als echte verificatie.

De volgorde bestaat daarom uit drie stappen:

1. Haal het rootcertificaat zelf op, uit de eigen publicatie van de tijdstempeldienst of via de EU Trusted List Browser. proof.json noemt de dienstverlener, dus u weet wiens root u zoekt. De onze is Disig a.s. in Slowakije.

2. Bereken de wortelhash opnieuw uit de SHA-256 van uw document en de zusterhashes, volgens de regel die in proof.json is uitgeschreven, en controleer of uw uitkomst gelijk is aan de wortelhash die daar staat.

3. Verifieer het token over die wortelhash:

openssl ts -verify -digest <root_hash> -in timestamp.tsr \

-untrusted tsa-chain.pem -CAfile <root die u zelf hebt opgehaald>

De voor de hand liggende tegenvraag is hoe u weet dat u de juiste root hebt opgehaald. Dat hoeft u vooraf niet te weten: wijst u het commando naar de verkeerde, dan mislukt het in plaats van stilletjes te slagen. Ofwel ondertekent de root de keten achter uw token, ofwel niet.

Dezelfde redenering geldt voor het woord “gekwalificeerd”. Een policy-identifier binnen in een token is een eigen verklaring van degene die dat token heeft gebouwd. De gekwalificeerde status volgt in plaats daarvan uit de vermelding van een dienstverlener op een nationale Trusted List, die openbaar is en zonder ons te lezen valt. De onze staat daar voor TSA/QTST met status granted. Kijkt u zelf.

Waarom raakt het verankeren het bestand zelf nooit?

Omdat de hash over bytes wordt berekend, en het terugschrijven van de uitkomst in het document precies die bytes verandert.

Het is een kleine cirkel waar verrassend veel producten in lopen. Hash het document, verkrijg een anker, en stempel dat anker vervolgens behulpzaam in de PDF zodat de lezer het kan zien. De opgeslagen PDF komt daarmee niet meer overeen met de hash die zojuist is verankerd. Het bewijs haalt zichzelf onderuit op het moment dat het zichzelf aankondigt. Het opgeslagen bestand blijft daarom byte voor byte identiek: er wordt niets in geschreven, niets opnieuw opgeslagen, niets geoptimaliseerd. Het record staat naast het document, nooit erin.

Dezelfde discipline geldt stroomopwaarts. Onder RFC 3161 reist alleen de message imprint naar de dienstverlener, en komt er een ondertekend token over die imprint terug. Bij materiaal dat onder het verschoningsrecht valt, is dat vaak de reden dat het gesprek überhaupt gevoerd kan worden.

Wat moet de ontvangende partij doen, en wat gaat er stuk?

Bewaar het originele document precies zoals het binnenkwam. Sla het niet opnieuw op. Open het niet in Acrobat om het daarna op te slaan. Haal het niet door een converter om het netjes te maken voor het dossier. Een hash over bytes is onverbiddelijk, en opnieuw opslaan herschrijft bytes, ook als er zichtbaar niets is veranderd.

Het Nederlandse procesrecht wijst om eigen redenen dezelfde kant op. Artikel 156a Rv staat toe dat een elektronische akte elektronisch wordt opgeslagen, op voorwaarde dat die opslag een ongewijzigde reproductie van de inhoud mogelijk maakt, gedurende een periode die is afgestemd op het doel. Ongewijzigde reproductie is de norm waaraan uw archiveringsstap moet voldoen. Eén keer goedbedoeld opnieuw opslaan haalt die norm niet, zonder dat iemand het merkt.

Dat is geen theoretisch risico. In ECLI:NL:RVS:2024:4237 probeerde de Afdeling bestuursrechtspraak van de Raad van State een elektronisch ondertekende maatregel van bewaring te valideren en kreeg een foutmelding. Het deskundigenrapport van 3 september 2024 legde uit waarom: nadat elektronisch was ondertekend, stuurde de minister het bestand naar de Rechtspraak, en daar is het omgezet naar een formaat voor digitale archivering. Die omzetting heeft er, in de bewoordingen van de uitspraak, voor gezorgd dat informatie beschadigd is geraakt in het deel van het bestand waar de elektronische handtekening zich bevindt.

Lees die volgorde nog eens. Met de handtekening was niets mis; de deskundige kon hem in het originele bestand wél valideren. De archiveringsstap leverde de beschadigde kopie op, en die beschadigde kopie belandde in het digitale dossier. De uitspraak zegt niet naar welk formaat is omgezet, dus wij ook niet.

De regel voor iedereen die een document met bewijs aangeleverd krijgt: archiveer de ontvangen bytes ongemoeid en werk verder vanuit een kopie. Al overheen opgeslagen? Vraag de afzender om het origineel.

Hoe verhoudt dit zich tot een documenttijdstempel in Adobe Acrobat?

De documenttijdstempel van Acrobat is een echt mechanisme, en een derde kan die controleren. De verschillen gaan over waar het bewijs staat, wie de tijdbron kiest en wat er met het document gebeurt.

Welke Acrobat-edities en -abonnementen welke ondertekenfuncties bevatten, is aan Adobe om te melden, op de eigen prijspagina. Wij gaan geen bedragen noemen die verschuiven.

Geen van beide kolommen is hier de boosdoener. Weet u al welke tijdstempeldienst u vertrouwt en waarom, dan is de ingebouwde route van Acrobat respectabel. De meeste mensen stranden bij dat tweede deel.

Wat bewijst dit pakket niet?

Dat het document uiterlijk bestond op het moment dat in het token staat, en dat het sindsdien niet is gewijzigd. Dat is de hele bewering, en die oprekken is de manier waarop mensen op een zitting hun geloofwaardigheid verliezen.

Het bewijst niet wie het document heeft gemaakt. Er zit geen identiteit in de constructie: geen handtekening, niemand die instaat voor het auteurschap. Auteurschap is een handtekeningvraag, en ons juridisch overzicht zet uiteen waar die grens loopt. Het bewijst evenmin dat de inhoud waar is. Een zorgvuldig verankerde factuur voor werk dat nooit is verricht, blijft een verankerde leugen.

Een anker is een bovengrens, nooit een geboortebewijs. Bestond uiterlijk op. Niet aangemaakt op. Wij houden een lijst bij van formuleringen die in onze eigen teksten verboden zijn, en “aangemaakt op” staat daarop, naast “rechtsgeldig” en “gecertificeerd”. De smalle versie overleeft het contact met een rechtszaal. De marketingversie niet.

Binnen die grenzen is de waarde reëel. Artikel 41 lid 2 verbindt aan een gekwalificeerde tijdstempel het vermoeden dat de tijd juist is en dat de gebonden gegevens integer zijn. In de praktijk legt dat de bewijslast bij degene die de datum wil betwisten.

Veelgestelde vragen

Moet ik mijn document naar de tijdstempeldienst sturen?

Nee. Onder RFC 3161 stuurt de client alleen de message imprint, en dat is een hash. Het document verlaat uw omgeving niet, en daarom blijft dit bruikbaar voor materiaal onder het verschoningsrecht dat u nooit naar een validatiewebsite zou kunnen uploaden.

Kan ik dit nog controleren als PDFen ophoudt te bestaan?

Ja, en daarom bevat het pakket een token en geen link. Alles wat de controle nodig heeft zit in het pakket, plus een root die u bij de dienstverlener of via de Trusted List ophaalt, en het gereedschap is openssl in plaats van onze software. Onze README noemt de verificatiepagina als laatste, uit hoffelijkheid, onder het offline commando.

Kan iemand zomaar de aanmaakdatum in een PDF veranderen?

Ja. Aanmaak- en wijzigingsdatums in een PDF zijn gewone metadatavelden die zonder bijzondere vaardigheid te herschrijven zijn, en de klok van de computer kan worden teruggezet voordat het document überhaupt wordt gemaakt. Een datum waar u op wilt kunnen bouwen, moet dus van buiten het bestand komen, ondertekend door een partij die er geen belang bij heeft.

Ik heb het bestand geopend en opgeslagen. Heb ik het bewijs kapotgemaakt?

Voor die kopie waarschijnlijk wel. Opslaan herschrijft bytes, ook als er zichtbaar niets is veranderd, en de hash dekt bytes. Ga terug naar de kopie precies zoals u die ontving, en is die weg, vraag de afzender hem opnieuw te sturen. Een vergelijking van vingerafdrukken kan nog steeds aangeven of de inhoud is verschoven, al is dat een zwakkere uitspraak dan een hash die byte voor byte klopt.

Waarom zit het rootcertificaat niet in het pakket?

Omdat een root die met het token meereisde niets over dat token bewijst. Daartegen valideren is een integriteitscontrole vermomd als vertrouwenscontrole. Haal de root op bij de dienstverlener of via de EU Trusted List Browser, en verifieer daartegen.

Waar laat dit het document op uw bureau?

Als er over een document ooit discussie kan ontstaan, dan is het nuttige moment nu, zolang er nog niemand discussieert. Leg de bytes vast, laat ze verankeren, houd de ontvangen kopie ongemoeid. Het gesprek verschuift dan van “geloven wij dit bestand” naar “wat staat er in dit bestand”.

Krijgt u een document met bewijs aangeleverd? /nl/verifieer accepteert een bestand, een hash of een verificatiecode, en rapporteert de uitkomsten afzonderlijk in plaats van ze samen te persen tot één groen vinkje. Het is een gemak, en dat staat ook zo op de pagina. Het bewijs zit in de commando's uit het pakket.

Daan van Tongeren is de oprichter van PDFen, waar hij het hier beschreven bewijspakket ontwierp, inclusief de regel in de README die u vertelt de root daarbinnen niet te vertrouwen. Correcties, of een verslag van een zaak waarin dit in de praktijk misging, zijn welkom via de contactpagina.