Firma: PAdES B-LT / B-LTA, DSS, marche temporali del documento
In sintesi
Sezione intitolata “In sintesi”NextPDF Enterprise aggiunge il produttore a lungo termine sopra la firma CMS di Core: un Document Security Store (DSS), informazioni di convalida per ciascuna firma (VRI) e marche temporali del documento. Queste strutture portano una firma baseline PAdES da B-B a B-LT e quindi a B-LTA. Questa pagina descrive il comportamento: indica ciò che il produttore scrive, ciò che non decide e dove inizia il confine con Pro.
Installazione
Sezione intitolata “Installazione”composer require nextpdf/enterprisenextpdf/enterprise dipende da nextpdf/core e nextpdf/pro. Risolvere il pacchetto con le credenziali della licenza NextPDF su Private Packagist.
Panoramica concettuale
Sezione intitolata “Panoramica concettuale”Una firma baseline PAdES prevede quattro livelli. Ogni livello aggiunge materiale a quello precedente. B-B è una firma CMS con attributi firmati. B-T aggiunge una marca temporale RFC 3161 attendibile sul valore della firma. B-LT aggiunge un DSS che contiene i certificati, le risposte OCSP e le CRL necessari a un verificatore dopo la scadenza del certificato di firma. B-LTA aggiunge una marca temporale del documento sull’intero stato del documento, incluso il DSS, così che il materiale di convalida resti a sua volta ancorato nel tempo.
Core costruisce il CMS SignedData e lo memorizza con codifica DER nella voce Contents del dizionario della firma — ISO 32000-2 §12.8.1. La convalida a lungo termine si basa su due tipi di dizionario: un document security store e un dizionario di marca temporale del documento — ISO 32000-2 §12.8. Il produttore Enterprise scrive il DSS che contiene certificati, OCSP e CRL — ISO 32000-2 §12.8.4.3 — e, per B-LTA, il dizionario di marca temporale del documento — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 descrive la stessa struttura a lungo termine: voci DSS più marche temporali del documento per le firme a lungo termine — §5.5 — supportate dal gestore di firma — §6.3.3.3.
Il produttore raccoglie il materiale di revoca per ciascun certificato della catena. Interroga prima un responder OCSP; una risposta OCSP riporta good, revoked o unknown — RFC 6960 §2.2 — e i campi thisUpdate e nextUpdate delimitano quanto tale stato sia aggiornato — RFC 6960 §4.2. Se OCSP non è disponibile, ricorre a una CRL. La catena viene percorsa dal firmatario fino a un trust anchor seguendo gli input di convalida del percorso — RFC 5280 §6.1.
La marca temporale del documento B-LTA è uno scambio RFC 3161 con una Time-Stamping Authority. La richiesta restituisce un TSTInfo — RFC 3161 §2.4.1 — il cui genTime è l’istante UTC in cui il token è stato creato — RFC 3161 §2.4.2. Il token viene incorporato in un dizionario /DocTimeStamp con /SubFilter /ETSI.RFC3161 che copre l’intero file.
È il verificatore a decidere se una firma prodotta si convalida, in base ai trust anchor e alla politica di revoca con cui è configurato. Il produttore incorpora materiale; non asserisce un esito attendibile. Questo confine viene ribadito nei punti pertinenti più avanti.
L’ordine è determinante: il DSS deve essere scritto prima della marca temporale del documento B-LTA, perché la marca temporale deve coprire lo stato del documento che già contiene il materiale di convalida. Di seguito è mostrato il flusso del produttore.
Superficie API
Sezione intitolata “Superficie API”Il produttore a lungo termine Enterprise viene usato tramite il contratto di Core. Il codice di produzione dipende dal contratto, non dal tipo concreto dell’implementazione Enterprise.
| Tipo | Genere | Ruolo | Stabilità | Da |
|---|---|---|---|---|
SignerInterface | interface (NextPDF\Contracts) | Contratto di firma di Core da cui dipendono i chiamanti | stable | 1.0.0 |
SignatureLevel | enum (NextPDF\Security\Signature) | Selettore di livello PAdES: B-B, B-T, B-LT, B-LTA | stable | 1.0.0 |
LtvManagerInterface | interface (NextPDF\Contracts) | Contratto del produttore di convalida a lungo termine risolto in fase di esecuzione | stable | 1.0.0 |
TsaClientInterface | interface | Client RFC 3161 TSA che il produttore chiama per le marche temporali del documento | stable | 1.0.0 |
SignatureLevel::requiresDss() è true per B-LT e B-LTA; SignatureLevel::requiresDocumentTimestamp() è true solo per B-LTA. Il metodo Core SignatureLevel::isAvailableInEnvironment() restituisce false per B-LT e B-LTA quando il produttore a lungo termine Enterprise non è installato; l’orchestratore di Core fallisce quindi in modo chiuso. Le classi concrete del produttore Enterprise sono interne e non fanno parte dell’API pubblica; dipendere da LtvManagerInterface e dall’enum.
Esempio di codice — Avvio rapido
Sezione intitolata “Esempio di codice — Avvio rapido”<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Security\Signature\SignatureLevel;
/** * Select the PAdES level for a long-term signature. * * B-LT embeds a DSS. B-LTA also adds a document timestamp. * Both require the nextpdf/enterprise long-term producer at runtime. * * @return SignatureLevel The requested PAdES baseline level. */function longTermLevel(): SignatureLevel{ return SignatureLevel::PAdES_B_LTA;}Il livello viene trasportato nella configurazione di firma. L’orchestratore di Core risolve il produttore a lungo termine tramite LtvManagerInterface in fase di esecuzione, così che il codice applicativo non faccia riferimento al tipo Enterprise.
Esempio di codice — Produzione
Sezione intitolata “Esempio di codice — Produzione”<?php
declare(strict_types=1);
require_once __DIR__ . '/../../vendor/autoload.php';
use NextPDF\Contracts\LtvManagerInterface;use NextPDF\Contracts\SignerInterface;use NextPDF\Exception\NextPdfException;use Psr\Log\LoggerInterface;
final readonly class LongTermSigner{ public function __construct( private SignerInterface $signer, private LtvManagerInterface $ltv, private LoggerInterface $logger, ) {}
/** * Sign, then embed the DSS and the B-LTA document timestamp. * * The order matters: the DSS is written first, then the document * timestamp is taken over the document state that already includes it. * * @param string $byteRange The PDF byte range to sign. * * @throws NextPdfException When revocation material is missing under the * fail-closed enforcement default, or when no TSA * is configured for B-LTA. */ public function sign(string $byteRange): string { try { $contents = $this->signer->sign($byteRange)->toHex(); // The orchestrator drives DSS collection and the document // timestamp through the resolved LtvManagerInterface; revocation // freshness and TSA reachability are operational inputs. return $contents; } catch (NextPdfException $e) { $this->logger->error('long-term signing failed', ['reason' => $e->getMessage()]); throw $e; } }}Il DSS deve essere scritto prima della marca temporale del documento. La marca temporale B-LTA copre l’intero file, incluso il DSS, ed è ciò che rende il materiale di convalida a sua volta ancorato nel tempo.
Casi limite e insidie
Sezione intitolata “Casi limite e insidie”- In assenza di materiale di revoca, il produttore fallisce in modo chiuso per impostazione predefinita. Quando non è impostata alcuna modalità di applicazione, il produttore tratta una risposta OCSP mancante e una CRL mancante per qualsiasi certificato non radice come un errore, non come un avviso. Questo impedisce che un documento che dichiara un livello a lungo termine venga scritto senza materiale di revoca nel DSS. Il flusso di lavoro permissivo (solo-avviso) è facoltativo (opt-in).
- B-LTA richiede una TSA. Una marca temporale del documento è un round trip RFC 3161. Senza un client TSA configurato, il passo B-LTA solleva un errore anziché produrre silenziosamente B-LT.
- L’ordine è determinante. Aggiungere la marca temporale del documento solo dopo che il DSS è stato scritto. Una marca temporale apposta prima del DSS non copre il materiale di convalida.
- Esecuzioni in ambiente isolato (air-gapped). Con una politica di rete strict-offline, non viene effettuato alcun recupero OCSP/CRL né alcuna richiesta TSA; viene usato solo il materiale già incorporato nel DSS. B-LTA, che richiede un token TSA aggiornato, non è raggiungibile in strict-offline.
- Il VRI è facoltativo (opt-in). Il VRI per ciascuna firma non è scritto per impostazione predefinita. Alcuni validatori visualizzano meglio lo stato a lungo termine quando il VRI è presente; abilitarlo quando lo richiede un verificatore di destinazione.
Prestazioni
Sezione intitolata “Prestazioni”Il costo di assemblaggio del DSS cresce con la lunghezza della catena e con il numero di risposte di revoca recuperate. Ogni recupero OCSP o CRL è un round trip di rete; il materiale pre-raccolto o memorizzato in cache elimina tali round trip. Un’esecuzione B-LTA aggiunge un round trip TSA per la marca temporale del documento. Il budget wall di 1500 ms copre una singola firma a lungo termine con connessioni OCSP/CRL e TSA a caldo; i responder lenti o a freddo dominano il tempo wall. Il profilo di riproducibilità è structural: le marche temporali incorporano gli istanti di firma e di marcatura, quindi due esecuzioni differiscono in quei byte mentre la struttura del documento resta identica.
Note di sicurezza
Sezione intitolata “Note di sicurezza”- La fiducia è una decisione del verificatore. Il produttore incorpora certificati, OCSP e CRL. Il fatto che la firma si convalidi dipende dal verificatore, dai suoi trust anchor e dalla sua politica di freschezza della revoca. NextPDF non include alcun elenco di fiducia integrato.
- La freschezza della revoca è limitata nel tempo. Le finestre di validità di OCSP
thisUpdate/nextUpdatee CRL delimitano per quanto tempo il materiale incorporato resta utile. Il ciclo di archiviazione riappone la marca temporale prima che il certificato della marca temporale scada; gestirlo nei tempi previsti è responsabilità del chiamante. - Impostazione predefinita fail-closed. L’impostazione predefinita di applicazione rigorosa della revoca esiste affinché una dichiarazione a lungo termine non venga fatta senza il materiale che la supporta.
- Vedere la sezione sul modello di minaccia Enterprise e Archivio: DSS, VRI, integrità LTV.
Residenza dei dati e mitigazioni dei dati personali (PII)
Sezione intitolata “Residenza dei dati e mitigazioni dei dati personali (PII)”Il recupero di OCSP e CRL contatta i responder indicati in ciascun certificato; tali endpoint e la TSA vedono i metadati della richiesta. In una distribuzione con vincoli di residenza dei dati, pre-raccogliere il materiale di revoca ed eseguire con la politica strict-offline, così che nessun responder o TSA sia contattato al momento della firma. I certificati trasportano l’identità del soggetto. Il produttore incorpora i certificati necessari alla convalida e non aggiunge identità oltre la catena; non rimuove i campi del soggetto da un certificato fornito dal chiamante.
Telemetria sicura e sanificazione dei log
Sezione intitolata “Telemetria sicura e sanificazione dei log”I messaggi diagnostici del produttore riportano il livello, la posizione nella catena e la condizione di materiale mancante. Non registrano chiavi private né corpi completi dei certificati. Quando si collega un logger PSR-3, mantenere i log diagnostici a una verbosità non di produzione per i flussi di firma e sanificare gli URL dei responder se rivelano infrastruttura interna. Trattare qualsiasi byte OCSP/CRL incorporato come contenuto del documento, non come contenuto di log.
Comportamento in modalità FIPS
Sezione intitolata “Comportamento in modalità FIPS”Il profilo di crypto-policy FIPS 140-3 è una capacità Enterprise documentata con il modulo di sicurezza. Il produttore a lungo termine non aggiunge primitive crittografiche proprie oltre al digest SHA-256 usato per la marca temporale del documento e allo scambio RFC 3161; la primitiva di firma è quella del firmatario di Core. Quando il profilo FIPS è attivo, vengono prodotte le stesse strutture di DSS e di marca temporale del documento; il vincolo si applica agli algoritmi sottostanti di firma e di digest, non al layout del DSS.
Modello di minaccia
Sezione intitolata “Modello di minaccia”| Asset | Avversario | Rischio | Mitigazione |
|---|---|---|---|
| Materiale di revoca del DSS | Accettazione di materiale obsoleto | Un verificatore si fida di dati di revoca scaduti | I campi di freschezza OCSP/CRL delimitano la validità; il ciclo di archiviazione riappone la marca temporale prima della scadenza |
| Marca temporale del documento B-LTA | Compromissione della TSA o TSA irraggiungibile | Nessun ancoraggio temporale attendibile | TSA scelta dal chiamante; B-LTA fallisce in modo chiuso quando non è configurata alcuna TSA |
| Dichiarazione a lungo termine | Materiale mancante senza segnalazione | Un PDF «a lungo termine» senza dati di revoca | L’impostazione predefinita di applicazione fail-closed solleva un errore anziché un avviso |
| Verifica della firma | Fiducia del verificatore configurata in modo errato | Validità apparente che il verificatore non dovrebbe asserire | Il produttore dichiara di incorporare solo materiale; la decisione di fiducia è del verificatore |
Conformità
Sezione intitolata “Conformità”| Dichiarazione | Standard | Clausola | reference_id |
|---|---|---|---|
Il valore della firma (o il token di marca temporale) è memorizzato con codifica DER in /Contents. | ISO 32000-2 | §12.8.1 | |
| La convalida a lungo termine usa un DSS e un dizionario di marca temporale del documento. | ISO 32000-2 | §12.8 | |
| Il DSS contiene certificati, risposte OCSP e CRL. | ISO 32000-2 | §12.8.4.3 | |
| La marca temporale del documento usa un dizionario di marca temporale del documento. | ISO 32000-2 | §12.8.5 | |
| Le voci DSS e le marche temporali del documento supportano le firme a lungo termine. | ETSI EN 319 142-2 | §5.5 | |
| Il gestore di firma supporta le voci DSS e le marche temporali del documento. | ETSI EN 319 142-2 | §6.3.3.3 | |
| Un token di marca temporale trasporta un genTime UTC che è l’istante in cui è stato creato. | RFC 3161 | §2.4.2 | |
| OCSP riporta good, revoked o unknown, delimitato da thisUpdate/nextUpdate. | RFC 6960 | §2.2, §4.2 | , |
Tutte le clausole sono parafrasate. NextPDF non riproduce il testo normativo; consultare gli standard pubblicati per la formulazione autorevole. NextPDF non avanza alcuna rivendicazione di certificazione PAdES. Le strutture qui descritte sono allineate ai livelli B-LT e B-LTA come definiti in ETSI EN 319 142; non si rivendica alcun risultato di test di conformità né alcuna attestazione di terze parti. La parte ETSI EN 319 142-1 relativa ai livelli baseline è al di fuori dell’insieme di evidenze citate, quindi questa pagina indica la struttura prodotta e il confine Pro/Enterprise, non un livello di conformità certificato. L’evidenza ETSI citata è EN 319 142-2; gli ancoraggi ISO e RFC sostengono le rivendicazioni a lungo termine e di marca temporale, esattamente come fa il riferimento di firma di Core.
Gate di edizione
Sezione intitolata “Gate di edizione”NextPDF Core produce i livelli baseline PAdES B-B e B-T: Core include il firmatario CMS software e il percorso di marca temporale RFC 3161, così che una firma B-T (con marca temporale) sia una capacità di Core e non richieda Enterprise. NextPDF Pro produce a sua volta B-B e B-T: Pro compone lo stack RFC 3161 di Core per aggiungere l’attributo non firmato signature-time-stamp sul valore della firma (PadesBtTimestamper, verificato tramite fixture). I livelli B-LT e B-LTA — il produttore di DSS, VRI e marca temporale del documento — sono una capacità Enterprise e non sono prodotti da Core o Pro. Ciò corrisponde alla tabella dei livelli pubblicata nella pagina di sicurezza Pro: B-B e B-T sono prodotti da Core e Pro, mentre B-LT e B-LTA solo da Enterprise. Il produttore B-T è strutturale — compone l’RFC 3161 signature-time-stamp secondo le evidenze citate RFC 3161 / RFC 5652 / ETSI EN 319 122-1; non è una rivendicazione di conformità ETSI EN 319 142-1 certificata né qualificata eIDAS. In una distribuzione solo-Pro, la richiesta di B-LT o B-LTA fallisce in modo chiuso con un messaggio che nomina il componente Enterprise mancante, perché SignatureLevel::isAvailableInEnvironment() restituisce false quando il produttore a lungo termine Enterprise è assente.
| Livello PAdES | Aggiunge | Edizione del produttore |
|---|---|---|
| B-B | Firma CMS con attributi firmati | Core, Pro, Enterprise |
| B-T | RFC 3161 signature-time-stamp sul valore della firma (strutturale; non qualificata eIDAS) | Core, Pro, Enterprise |
| B-LT | Document Security Store con materiale di convalida | Solo Enterprise (nextpdf/enterprise) |
| B-LTA | Marche temporali del documento per validità di archiviazione | Solo Enterprise (nextpdf/enterprise) |
Questa è la matrice canonica livello→edizione: B-B è la baseline prodotta da ogni edizione; B-T (con marca temporale) è prodotto anche da Core e Pro (Pro compone lo stack RFC 3161 di Core); B-LT e B-LTA sono solo Enterprise. Il produttore B-T è strutturale — non è una rivendicazione di conformità ETSI EN 319 142-1 certificata né qualificata eIDAS.
Flag di funzionalità della licenza
Sezione intitolata “Flag di funzionalità della licenza”Il produttore a lungo termine fa parte dell’edizione Enterprise (license_feature_flag: enterprise). Viene risolto in fase di esecuzione tramite il contratto di Core; l’API pubblica non cambia con l’aggiornamento da Pro a Enterprise.
Contratto di comportamento
Sezione intitolata “Contratto di comportamento”- Sia Core sia Pro producono B-B e B-T (B-T aggiunge l’RFC 3161 signature-time-stamp; Pro compone lo stack RFC 3161 di Core). B-LT e B-LTA sono un confine Enterprise; una richiesta di questi livelli senza
nextpdf/enterprisefallisce in modo chiuso con un errore nominato. - Il produttore scrive un DSS (B-LT) e una marca temporale del documento sul DSS (B-LTA). Incorpora materiale di convalida; non asserisce un esito di verifica attendibile.
- L’impostazione predefinita di applicazione fail-closed della revoca solleva un errore quando il materiale di revoca è mancante per un certificato non radice, a meno che il chiamante non opti per il flusso di lavoro permissivo.
- B-LTA richiede una TSA configurata; senza, il passo B-LTA solleva un errore anziché degradare a B-LT.
Stato della scansione NDA
Sezione intitolata “Stato della scansione NDA”Questa pagina pubblica descrive solo il comportamento del produttore osservabile dall’esterno. Non contiene percorsi di namespace interni, nomi di classi o trait interni, nomi di file di runbook, né prefissi di ticket interni. I tipi concreti del produttore a lungo termine Enterprise sono riferiti solo tramite il contratto pubblico di Core (LtvManagerInterface, SignatureLevel). I dettagli interni di assemblaggio del DSS e del ciclo di archiviazione si trovano nel riferimento approfondito riservato (gated) sotto NDA.
Fallback di Core
Sezione intitolata “Fallback di Core”In una distribuzione solo-Core, il firmatario software produce PAdES B-B e B-T con una chiave locale o una chiave fornita tramite il contratto di strategia di firma di Core. Core include il percorso di marca temporale RFC 3161, così che B-T sia raggiungibile senza alcun pacchetto premium. Core non ha alcun produttore di DSS, VRI o marca temporale del documento; la richiesta di B-LT o B-LTA fallisce in modo chiuso con un errore nominato. Vedere Sicurezza / Firma (Core).
Fallback di Pro
Sezione intitolata “Fallback di Pro”In una distribuzione solo-Pro, il percorso di firma supportato comprende la baseline B-B di Pro e il livello B-T di Pro (Pro compone lo stack RFC 3161 di Core per aggiungere l’attributo non firmato signature-time-stamp), oltre alle sue strategie di firma remote e cloud-KMS. Pro non produce alcun DSS, VRI o marca temporale del documento. Una configurazione che richiede B-LT o B-LTA in una distribuzione solo-Pro fallisce in modo chiuso con un messaggio che nomina il componente Enterprise mancante. Vedere Sicurezza Pro per la superficie di firma di Pro.
Nota sul confine Enterprise
Sezione intitolata “Nota sul confine Enterprise”Il produttore di DSS, VRI e marca temporale del documento è descritto solo a livello di comportamento. La logica interna di ordinamento dell’assemblaggio del DSS, i dettagli interni della chiave del VRI per ciascuna firma e i dettagli interni di pianificazione del ciclo di archiviazione sono fuori ambito per la superficie pubblica e non sono qui riprodotti.
Confine di distribuzione
Sezione intitolata “Confine di distribuzione”NextPDF Enterprise incorpora materiale di convalida; si integra con responder OCSP/CRL forniti dal chiamante e con una TSA RFC 3161. Non gestisce, ospita né garantisce esso stesso la disponibilità di tali responder o della TSA. La validità a lungo termine dipende dai responder, dalla TSA, dalla pianificazione del ciclo di archiviazione e dall’operatore — non da NextPDF Enterprise da solo. L’operatore è responsabile della selezione e raggiungibilità della TSA, dell’accesso ai responder di revoca o al materiale pre-raccolto, della politica di rete e dell’esecuzione del ciclo di archiviazione prima che ciascun certificato di marca temporale scada.
Confine di conformità legale
Sezione intitolata “Confine di conformità legale”Questa pagina è contrassegnata con export_control_class: legal-review-required. Riguarda la firma crittografica e la convalida a lungo termine. L’approvazione legale è richiesta prima che il flag publish venga impostato. L’allineamento alle strutture B-LT e B-LTA definite in ETSI EN 319 142 è una dichiarazione strutturale, non un parere legale e non una certificazione. NextPDF non avanza alcuna rivendicazione di certificazione PAdES. Consultare i propri consulenti legali e di conformità per i propri obblighi normativi.
Vedere anche
Sezione intitolata “Vedere anche”- Sicurezza / Firma (Core) — CMS, RFC 3161, convalida del percorso RFC 5280, OCSP/CRL.
- Sicurezza Pro — baseline B-B e confine Enterprise.
- Archivio: DSS, VRI, integrità LTV — archiviazione a lungo termine e integrità LTV.
- Verifica della firma — il lato della verifica: verifica crittografica CMS / della marca temporale, TSA-at-genTime e convalida della catena di archiviazione.
- Mappatura della baseline PAdES — B-B, B-T, B-LT, B-LTA tra le edizioni.
- PAdES · DSS · VRI · LTV — termini del glossario.