Marche temporali e tempo attendibile

Spec: RFC 3161 Spec: RFC 5816 Spec: ISO 32000-2, §12.8.5 Evidence: Standard-backed

In sintesi

Una marca temporale non registra «quando questo è stato firmato.» Dimostra qualcosa di più circoscritto e più solido: che uno specifico dato esisteva prima di uno specifico istante, attestato da una parte diversa dal firmatario. Questa distinzione è l’intero valore del tempo attendibile, ed è spesso fraintesa.

Perché è importante

L’ora di firma presente in una firma è quella dichiarata dal computer del firmatario. Un orologio può essere sbagliato per errore o per scelta. Se l’unica prova del quando è la dichiarazione dello stesso firmatario, il firmatario può antedatare o postdatare un documento a piacimento. Una firma con un certificato revocato ieri può essere fatta apparire come apposta l’anno scorso. Il «quando» non è un dettaglio: decide se una firma apposta con un certificato ora scaduto o ora revocato conti ancora. E se il tempo attendibile è errato, crolla ogni argomento di validità a lungo termine costruito su di esso.

In breve

L’ora di firma dichiarata dal firmatario stesso è un’affermazione, non una prova. È falsificabile con estrema facilità.
Una marca temporale RFC 3161 è un token firmato emesso da una Time-Stamp Authority (TSA) che lega un hash dei tuoi dati al tempo attestato dalla TSA.
Ciò che dimostra è preciso: i dati esistevano prima del tempo dichiarato dalla TSA. Non l’esatto momento di creazione, ma un limite superiore.
Il token riporta lo stesso nonce e la stessa message imprint, quindi non può essere un replay né riferirsi a dati diversi.
Una marca temporale di documento applica lo stesso meccanismo all’intero PDF, ancorando tutto ciò che copre — la firma e le sue prove di validazione incorporate — a un istante attendibile.

Come lo affronta NextPDF

NextPDF tratta una marca temporale come qualcosa da verificare, non semplicemente da ottenere. Richiedere un token è solo la parte meno importante del lavoro. Il principio del motore è che un token non verificato non costituisce una prova.

Quando il motore appone una marca temporale a una firma, invia alla TSA un hash dei dati e un nonce casuale nuovo, mai i dati stessi. Il token restituito viene quindi confrontato con l’insieme completo delle proprietà che lo rendono significativo: lo stato dell’autorità era «granted», il nonce nel token corrisponde a quello inviato, la message imprint nel token corrisponde all’hash inviato, la firma crittografica propria del token si verifica, il tipo di contenuto del token è quello di marca temporale e il tempo dichiarato rientra in una tolleranza accettabile. Qualsiasi divergenza è un errore irreversibile con un motivo tipizzato. Non esiste un percorso «abbastanza simile». Una marca temporale di documento segue la stessa regola, applicata all’intero file anziché al valore di una singola firma.

Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

Come si ottiene una marca temporale attendibile e che cosa dimostra: un hash più un nonce vengono inviati alla TSA, la TSA restituisce un token firmato che lega quell'hash al proprio tempo e il verificatore conferma il legame prima di trattarlo come prova che i dati esistevano prima di quel tempo.

Cosa dicono le prove

Evidence: Standard-backed La definizione è precisa. Spec: ISO/IEC 18014-2, §3 definisce un servizio di marcatura temporale come un servizio che fornisce prova che un elemento di dati esisteva prima di un certo punto nel tempo — un limite superiore, non un istante di creazione. Spec: ISO/IEC 18014-2, §7 definisce il contenuto del token TSTInfo: una message imprint (l’hash dei dati), un tempo di generazione, un numero di serie e un nonce opzionale. Spec: ISO/IEC 18014-2, §6 enuncia la conclusione che un verificatore può trarre in caso di successo: che l’elemento di dati esisteva prima del tempo indicato nel token — nulla di più e nulla di meno.

Per il PDF, Spec: ISO 32000-2, §12.8.5 specifica la marca temporale di documento: l’intervallo di byte copre l’intero file esclusi i valori di Contents, quell’hash viene inviato a una Time-Stamp Authority e il token RFC 3161 restituito — così come aggiornato da Spec: RFC 5816 — viene collocato in Contents. È la stessa disciplina degli intervalli di byte di una firma, applicata al tempo anziché all’identità. E Spec: RFC 6960, §4.4.4 spiega perché questo conta per la longevità: il tempo attendibile è ciò che consente a un validatore di dimostrare che una firma era affidabile il giorno in cui è stata prodotta anche dopo che il certificato è scaduto.

Il motore di NextPDF invia un hash e un nonce, mai i dati, e verifica il token restituito rispetto a stato, nonce, message imprint, firma del token, tipo di contenuto e tolleranza temporale prima di trattarlo come prova.

Esempio pratico

Non si assembla a mano un token di marca temporale. Ciò che conta è il punto in cui si innesta la fiducia. Una TSA va configurata e protetta, perché il suo tempo diventa la prova su cui si fa affidamento.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

Il punto da notare è che il motore invia un hash, non il documento, quindi la TSA non vede mai il contenuto del documento. E verifica la risposta. Una TSA che non si può autenticare non è tempo attendibile. È solo un altro orologio.

Equivoco comune

La trappola è leggere una marca temporale come «questo è stato firmato esattamente alle 14:32 di questa data.» Non è un cronometro applicato all’evento di firma. Dimostra che i dati esistevano non più tardi del tempo della TSA, che è un limite superiore fissato da un terzo. La creazione potrebbe essere avvenuta in qualsiasi momento precedente. Una seconda trappola è presumere che qualunque server di marcatura temporale fornisca tempo attendibile. Un token la cui firma non si può verificare, o la cui autorità non è considerata attendibile, non dimostra nulla. È un orologio a cui non c’è alcun motivo di credere. Il tempo attendibile proviene da una TSA che si può autenticare e da un token verificato, non dall’atto di chiedere un numero a un server.

Limiti e confini

NextPDF costruisce la richiesta, invia solo un hash e verifica il token restituito. Non garantisce l’affidabilità dell’autorità che vi sta dietro. L’accuratezza della TSA, la validità del suo certificato e la sua affidabilità sono proprietà del servizio e della configurazione del deployment, non del motore. Una marca temporale lega un hash a un tempo. Non dice nulla sul significato dei dati, sull’identità del firmatario o sul fatto che il certificato del firmatario fosse valido. Si tratta di controlli distinti, trattati in Validare correttamente una firma. Il motore non può rendere affidabile una TSA non affidabile. Questa pagina inoltre non asserisce alcun peso giuridico specifico per una marca temporale; ciò dipende dallo stato della TSA e dalla giurisdizione. Il modo in cui il tempo attendibile viene riutilizzato per mantenere una firma verificabile per decenni è trattato in Validazione a lungo termine.

Disponibilità della marcatura temporale per livello:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability
Edition	Availability
Core	Not in this edition
Pro	PAdES B-T — una marca temporale RFC 3161 verificata sul valore della firma, rispetto a una TSA fornita dal deployment.
Enterprise	Aggiunge la marca temporale di documento usata da B-LT e B-LTA per ancorare le prove di validazione incorporate e per guidare il ciclo di rinnovo archivistico.

Documenti correlati

Validazione a lungo termine — come la marca temporale di documento sigilla le prove incorporate e viene rinnovata nel tempo.
Profili baseline PAdES — dove la marca temporale di firma (B-T) e la marca temporale di documento (B-LTA) si collocano nella progressione dei livelli.
Firme qualificate, spiegate — dove una marca temporale qualificata si inserisce nel quadro di fiducia eIDAS.

Glossario

Marca temporale (RFC 3161) — un token firmato emesso da una TSA che lega un hash dei dati al tempo della TSA, dimostrando che i dati esistevano prima di quel tempo.
Time-Stamp Authority (TSA) — il servizio attendibile che emette i token di marca temporale.
TSTInfo — la struttura del contenuto del token: message imprint, tempo di generazione, numero di serie e nonce opzionale.
Message imprint — l’hash dei dati marcati temporalmente, riportato nel token.
Nonce — un valore casuale nuovo inviato con la richiesta e riportato nel token, in modo che la risposta non possa essere un replay.
Marca temporale di documento — una marca temporale RFC 3161 sull’intero PDF (così come aggiornata da RFC 5816), che ancora la firma e le sue prove a un istante attendibile.