Convalidare una firma nel modo corretto

Spec: RFC 5280, §6 Spec: RFC 6960 Spec: RFC 5652 Evidence: Test-backed

In sintesi

«La firma è valida» in genere significa che è stata controllata una sola cosa: i conti quadrano. Una convalida corretta verifica almeno cinque elementi indipendenti, e uno qualsiasi di essi può fallire rendendo privo di significato un segno di spunta verde. Questa pagina presenta l’insieme completo dei controlli e spiega perché una risposta parziale è una risposta pericolosa.

Perché è importante

Un singolo valore booleano è l’output più pericoloso in tutto questo ambito. Induce chi legge a trattare «valida» come «affidabile», mentre «valida» potrebbe significare soltanto che i byte non sono stati alterati e che la firma è verificabile con una chiave associata a un certificato scaduto da tre anni, revocato il mese scorso e non concatenabile ad alcuna autorità riconosciuta. Ognuno di questi è un controllo a sé. Un software che riporta un solo valore booleano ha deciso in silenzio quali controlli fossero rilevanti, e lo ha deciso al posto di chi lo usa. In un contesto regolamentato o contrattuale, «lo strumento ha detto valida» non è una difesa se lo strumento ha verificato solo il controllo meno oneroso.

In breve

Una convalida completa risponde a cinque domande distinte. Sono indipendenti: superarne una non dice nulla sulle altre:

Integrità — l’hash dei byte firmati corrisponde ancora a ciò che la firma copre? (Ricalcolare il digest dell’intervallo di byte e confrontarlo.)
Autenticità — la firma crittografica è verificabile con la chiave pubblica nel certificato di firma, sugli attributi firmati?
Percorso del certificato — quel certificato si concatena a un’ancora di fiducia scelta da chi convalida, con ogni anello valido?
Tempo — il certificato era nel suo periodo di validità al momento rilevante, e quel momento è attendibile anziché auto-dichiarato?
Revoca — il certificato non era revocato in quel momento, secondo prove (OCSP/CRL) effettivamente ottenibili o incorporate?

Una risposta «valida» che non ha eseguito tutti e cinque i controlli è una risposta incompleta che sembra completa.

Come l’affronta NextPDF

NextPDF considera ogni domanda distinta e richiede che ciascuna riceva una risposta esplicita. Una domanda non viene mai ridotta a un unico flag ottimistico, né saltata in silenzio perché il controllo era scomodo da eseguire. Ciò è imposto dai test. È per questo che questa pagina è contrassegnata come supportata da test anziché da standard: il comportamento è vincolato dalla suite, non solo argomentato a partire da una clausola.

Integrità e autenticità sono testate end-to-end. Un certificato noto firma una vera struttura di attributi firmati, e la suite verifica la firma con la chiave pubblica corrispondente su diversi vettori temporali. Così una modifica che rompe la struttura canonica fa fallire il test. La convalida del percorso del certificato è vincolata da test che alterano deliberatamente un byte della firma e verificano che il risultato non sia valido con una motivazione strutturata: non un’eccezione scartata, ma un fallimento registrato esplicitamente. La verifica del token di marca temporale è suddivisa in passi distinti — decodifica, informazioni sul firmatario, attributi firmati, message digest, associazione del certificato, utilizzo della chiave, firma, produced-at — e ogni passo è testato a sé; quindi «la marca temporale è verificata» significa che ogni passo è stato verificato. Il soft-failure della revoca (un responder irraggiungibile) è distinto, nel codice e nei test, da un «revocato» definitivo. I due non vengono mai confusi nella stessa risposta.

Integrity Recompute the byte-range digest and compare it to the value the signature covers.
Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Le cinque domande indipendenti a cui risponde una corretta convalida di una firma PDF, in ordine. Ciascuna è distinta: il superamento di una non dice nulla sulle altre, e saltarne una qualsiasi rende incompleto il risultato complessivo.

Cosa dicono le prove

Evidence: Test-backed Il comportamento è ancorato ai test, che implementano ciò che gli standard richiedono.

L’integrità è Spec: ISO 32000-2, §12.8.1 : il digest viene ricalcolato sull’intervallo di byte e confrontato con il valore memorizzato; qualsiasi differenza rende la firma non valida. L’autenticità sugli attributi firmati è coperta da un test di integrazione che firma un vero insieme di attributi firmati e lo verifica con la chiave pubblica corrispondente su diversi vettori temporali. La domanda sul percorso del certificato è Spec: RFC 5280, §6.1 : i percorsi validi partono da un’ancora di fiducia, e Spec: RFC 5280, §6.2 stabilisce che l’algoritmo definisce le condizioni minime perché un percorso sia valido; un test unitario verifica che una firma alterata produca valid = false con una motivazione esplicita, mai un’accettazione silenziosa.

Per la revoca, l’ordine corretto è Spec: RFC 6960, §3.2 : prima che un client accetti come valida una risposta di revoca firmata, DEVE confermare che la firma della risposta stessa sia valida e che il firmatario sia attualmente autorizzato — e Spec: RFC 6960, §4.2.2.2 definisce tale autorizzazione come una delega id-kp-OCSPSigning emessa direttamente dalla CA in questione. Quindi una risposta di revoca che non è stata essa stessa convalidata rispetto a un firmatario autorizzato e verificabile non ha significato. Il controllo di associazione del certificato è Spec: RFC 5035, §5.4.2 : se l’hash del certificato nell’attributo firmato signing-certificate-v2 non corrisponde al certificato usato per verificare la firma, la firma deve essere considerata non valida. Ciò chiude la falla della sostituzione, in cui una firma risulta verificabile rispetto a un certificato scelto da un attaccante. Il token di marca temporale stesso viene verificato in stile Spec: RFC 5652 come oggetto CMS, passo per passo, ogni passo testato a sé.

Esempio pratico

La parte istruttiva non è una chiamata API. Sono le domande a cui si deve saper rispondere prima di agire su un risultato. Va trattata come la checklist a cui una revisione sottoporrà il risultato.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Se una qualsiasi riga è «non lo so», lo stato onesto non è «valida». È «non ancora determinato» — e trattare i due esiti come equivalenti è l’errore che questa pagina esiste per prevenire.

Idea sbagliata comune

La trappola è equiparare «crittograficamente valida» ad «affidabile». Integrità e autenticità insieme provano solo che questi byte sono stati firmati dal detentore di questa chiave. Non dicono nulla sul fatto che il certificato della chiave fosse attendibile, attuale o non revocato. Un documento firmato con un certificato autogenerato può essere «crittograficamente valido» e non avere alcun valore. La trappola inversa è trattare un controllo di revoca indeterminato (responder offline) come un superamento — oppure come un fallimento. Non è né l’uno né l’altro. È sconosciuto, e un validatore corretto lo riporta come sconosciuto senza scegliere arbitrariamente una direzione o l’altra. Un segno di spunta verde che nasconde quali dei cinque controlli sono stati effettivamente eseguiti non è un risultato di convalida. È una decisione presa da qualcun altro.

Limiti e confini

NextPDF esegue e testa i controlli strutturali e crittografici. Non sceglie le ancore di fiducia né garantisce la policy applicata sopra quei controlli. Quali certificati ritenere attendibili è una decisione di deployment che il motore non può prendere. Una catena validata fino a un’ancora che non si sarebbe dovuta ritenere attendibile resta una convalida su cui non si può fare affidamento. Le prove di revoca possono essere controllate solo se sono ottenibili o incorporate. Un responder offline produce «indeterminato»; trasformarlo in un verdetto è una scelta di policy, non del motore. Questa pagina descrive l’insieme dei controlli, non la sufficienza giuridica. Se una firma convalidata abbia un determinato effetto giuridico dipende dal certificato, dal firmatario, dalla giurisdizione e dall’obbligo. Il modo in cui le prove incorporate mantengono questi controlli rispondibili nel tempo è trattato in Convalida a lungo termine; il meccanismo dell’intervallo di byte alla base del controllo di integrità è in Come le firme risiedono in un PDF.

Disponibilità per livello della superficie di convalida:

Signature validation checks — edition availability
Edition	Availability
Core	Integrità e autenticità sugli attributi firmati, più la convalida del percorso del certificato RFC 5280 §6 rispetto a un’ancora di fiducia fornita.
Pro	Aggiunge la verifica del token di marca temporale RFC 3161 — la domanda sul tempo attendibile, scomposta in passi controllati indipendentemente.
Enterprise	Aggiunge la valutazione della revoca (OCSP/CRL) e la convalida rispetto al materiale a lungo termine incorporato, con gli esiti indeterminati distinti da quelli definitivi.

Documenti correlati

Convalida a lungo termine — come le prove incorporate permettono di rispondere ai controlli su tempo e revoca anche anni dopo.
Come le firme risiedono in un PDF — il meccanismo dell’intervallo di byte ricalcolato dal controllo di integrità.
Marche temporali e tempo attendibile — ciò che permette di rispondere alla domanda sul «tempo» con qualcosa di diverso dall’orologio del firmatario.

Glossario

Controllo di integrità — ricalcolo del digest dell’intervallo di byte e confronto con il valore coperto dalla firma.
Controllo di autenticità — verifica della firma crittografica rispetto alla chiave pubblica del certificato di firma, sugli attributi firmati.
Attributi firmati — gli attributi CMS autenticati (content-type, message-digest, signing-time, signing-certificate-v2) su cui la firma è effettivamente calcolata.
Convalida del percorso del certificato — costruzione e verifica della catena dal certificato di firma a un’ancora di fiducia scelta (RFC 5280 §6).
Ancora di fiducia — un’autorità di certificazione che si è deciso di ritenere attendibile; la radice di un percorso accettabile.
Controllo di revoca — verifica per determinare se un certificato è stato revocato al momento rilevante, tramite OCSP o una CRL.
Indeterminato — un esito di revoca che non è né «buono» né «revocato» perché le prove non si sono potute ottenere; non un superamento e non un fallimento.