De PAdES-niveaus

Stap 7 van de flow geeft je B-B, en B-T als er een tijdstempel in de CMS ging. Dat is geen B-LTA, en dat hoeft ook niet: hoe ver je gaat is een keuze, en voor veel koppelingen is B-T het beoogde niveau. Elke trede omhoog is iets dat aan het bestand wordt toegevoegd; de hash-ondertekening bij Cleverbase is op elk niveau identiek. Dit hoofdstuk zegt wat elke trede in het bestand zet, wat hij bewijst, en wat hij nodig heeft.

Kies een trede om te zien wat hij toevoegt, wat hij bewijst, wat validatie dan nog van buiten nodig heeft, en waar je moet kijken om te zien op welke trede een bestand dat voor je ligt echt staat.

De treden

B-B, de handtekening

In het bestand De CMS met signed attributes en de handtekeningwaarde in /Contents. Bewijst wie wat heeft ondertekend; de tijd is alleen de geclaimde /M. Validatie hangt ervan af of het certificaat nog geldig is en of OCSP of CRL op dat moment online bereikbaar zijn.

B-T, bewezen tijd

In het bestand Een tijdstempeltoken van een TSA over de handtekeningwaarde, als unsigned attribute in dezelfde CMS. Toont aan dat de handtekening bestond voordat het certificaat verliep of werd ingetrokken. Validatie heeft nog steeds online revocatiegegevens nodig. Normaal gedaan bij het ondertekenen; is dat gemist, dan voldoet een documenttijdstempel als latere update ook voor B-T.

B-LT, validatiegegevens in het bestand

In het bestand Een nieuwe incrementele update met een /DSS-dictionary in de catalog, met de certificaten van de keten van de ondertekenaar en die van de TSA, de bijbehorende OCSP-responses of CRL's, en een /VRI per handtekening. Haal de revocatiegegevens na de tijdstempel op, zodat ze van later dateren dan de handtekening. Het bestand is nu offline te valideren; het maakt niet meer uit of de endpoints van de CA nog bestaan.

Certificaten alleen maken geen B-LT. Een DSS met alleen /Certs is de gewone misser: structureel ziet niets er kapot uit, de validator meldt B-T, en Acrobat toont geen "LTV enabled". Kijk in de objectboom van de inspector: de /DSS moet /OCSPs of /CRLs en een /VRI per handtekening dragen, niet alleen certificaten.

B-LTA, de archieftijdstempel

In het bestand Een laatste incrementele update met een onzichtbaar /Sig-veld waarvan de signature dictionary /Type /DocTimeStamp en /SubFilter /ETSI.RFC3161 heeft, en waarvan de ByteRange het hele bestand dekt. Beschermt de handtekening en de validatiegegevens tegen het verzwakken van algoritmen. Eventueel gevolgd door nog een DSS-update en documenttijdstempel om ook de validatiegegevens van de TSA mee te nemen. Onbeperkt te vernieuwen: voordat het TSA-certificaat verloopt of het hash-algoritme verzwakt, herhaal je deze stap.

Een documenttijdstempel op een onvolledige DSS verzegelt B-T, niet B-LTA. Het niveau wordt bepaald door de zwakste trede eronder, dus controleer de DSS voordat je de tijdstempels telt. Bestanden bereiken ons precies in die staat.

Ruimte om te reserveren: de archieftijdstempel is een nieuw handtekeningveld met zijn eigen /Contents, met een TimeStampToken en de keten van de TSA erin, dus 4 tot 8 kB, en elke verlenging voegt er weer een veld bij. Er komt niets bij in de /Contents van de oorspronkelijke handtekening, dus het getal dat je bij stap 0.5 koos hoeft voor LTA niet groter.

Wat er in je code verandert

• B-T: geef de bibliotheek een tijdstempelbron bij het afmaken. DSS: setTspSource op beide services en niveau PAdES_BASELINE_T. pyHanko: een timestamper op PdfSigner. Reserveer meer ruimte in /Contents bij het voorbereiden; het token gaat in de CMS. Die bron kan van ons zijn: Timestamping heeft de hosts, de authenticatie en het beleid, en elke RFC 3161-client spreekt het.
• B-LT: een uitbreidingsstap die OCSP of CRL ophaalt voor elk certificaat in de keten en de tijdstempelketen, en ze in /DSS met /VRI in een nieuwe revisie schrijft. DSS: PAdESService.extendDocument met online revocatiebronnen op de verifier. pyHanko: een validation context die ophaalt, daarna de LTV-update.
• B-LTA: een documenttijdstempel als laatste revisie, en een verlengproces dat er een nieuwe bij zet voordat het certificaat van de vorige tijdstempel verloopt. Dat is een operationele belofte, geen aanroep.

Meerdere ondertekenaars

Eerst alle handtekeningen, elk met zijn eigen B-T, daarna één LT- plus LTA-pas voor het geheel. Elke handtekening apart naar LTA brengen kost minstens twee extra revisies per ondertekenaar en is alleen de moeite als er veel tijd tussen ondertekenaars zit.

Wat het breekt

Eén niet-toegestane wijziging na de eerste handtekening (een veldwaarde, de /NeedAppearances-vlag, een herschreven bestand) maakt die handtekening verdacht en elke tijdstempel die erna volgt. Vandaar: alles uit stap 0 voor de eerste handtekening, en daarna alleen aanvullen.

In de volgende editie

• Een uitgewerkt B-LTA-pad met DSS, inclusief de keuze van de TSA en de revocatiebronnen.
• Hetzelfde met pyHanko.
• Een draaibare sandbox: een container met de referentie-implementatie, gericht op de acceptatieomgeving, zodat een integrator een correct bestand kan zien voordat hij een regel schrijft.
• CAdES voor niet-PDF-bestanden, waar de ondertekende hash hetzelfde is en alleen de container verschilt.