Enterprise edizione

Signature — Riferimento approfondito

In sintesi

Questo è il riferimento approfondito per il produttore a lungo termine di NextPDF Enterprise: come viene assemblata una firma B-LT o B-LTA, come viene raccolto e applicato il materiale di revoca, come la marca temporale del documento ancora il documento e come viene applicato il confine con Pro. È a livello di comportamento e di contratto. I tipi concreti dell’implementazione Enterprise non sono qui nominati di proposito; la pagina riferisce solo il pacchetto pubblico e la superficie di contratto di Core.

Disponibilità e licenza

Questa capacità è inclusa in NextPDF Enterprise (nextpdf/enterprise) e si attiva con un envelope di licenza di tier Enterprise. Una distribuzione priva di tale entitlement non carica le classi della capacità. Confronta le edizioni e ottieni una licenza.

La matrice canonica livello→tier: B-B è la baseline prodotta da Core, Pro ed Enterprise; B-T (con marca temporale) è prodotto da Core, Pro ed Enterprise — Core include il percorso di marca temporale RFC 3161, quindi B-T non richiede un pacchetto premium; B-LT e B-LTA (DSS, VRI, marca temporale del documento) sono prodotti solo da Enterprise. In una distribuzione solo-Pro, la richiesta di B-LT o B-LTA fallisce in modo chiuso: il Core SignatureLevel::isAvailableInEnvironment restituisce false quando il produttore a lungo termine Enterprise è assente, e l’orchestratore di Core solleva un errore nominato anziché degradare silenziosamente il livello.

Livello PAdES	Aggiunge	Edizione del produttore
B-B	Firma CMS con attributi firmati	Core, Pro, Enterprise
B-T	Marca temporale RFC 3161 attendibile sul valore della firma	Core, Pro, Enterprise
B-LT	Document Security Store con materiale di convalida	Solo Enterprise
B-LTA	Marca temporale del documento sul DSS (ciclo di archiviazione)	Solo Enterprise

Modello concettuale

Una firma B-LT è una firma B-T più un Document Security Store. Il DSS è un dizionario a livello di Catalog che contiene i flussi di certificati, risposte OCSP e CRL di cui un verificatore ha bisogno una volta scaduto il certificato di firma — ISO 32000-2 §12.8.4.3. La convalida a lungo termine usa due tipi di dizionario — un DSS e un dizionario di marca temporale del documento — ISO 32000-2 §12.8. La firma CMS stessa è memorizzata con codifica DER in /Contents — ISO 32000-2 §12.8.1.

Una firma B-LTA aggiunge una marca temporale del documento sull’intero stato del documento, incluso il DSS, scritta tramite il dizionario di marca temporale del documento — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 descrive la stessa composizione a lungo termine — §5.5 — e il supporto del gestore — §6.3.3.3.

Flusso di lavoro del produttore

Costruire la catena. Il certificato del firmatario più gli eventuali intermedi forniti dal chiamante formano la catena, dal firmatario per primo verso il trust anchor — RFC 5280 §6.1.
Raccogliere il materiale di revoca. Per ciascun certificato non radice, il produttore interroga prima OCSP. Una risposta OCSP riporta good, revoked o unknown — RFC 6960 §2.2 — ed è delimitata nel tempo da thisUpdate/nextUpdate — RFC 6960 §4.2. Se OCSP non è disponibile, ricorre a una CRL, con supporto per delta-CRL; una CRL base e un delta facoltativo vengono aggiunti come voci DSS separate.
Scrivere il DSS. Certificati, risposte OCSP e CRL vengono scritti come singoli oggetti stream PDF; i duplicati sono deduplicati per hash del contenuto. Il dizionario DSS vi fa riferimento tramite /Certs, /OCSPs, /CRLs.
VRI per ciascuna firma (opt-in). Una voce VRI, indicizzata dall’hash in maiuscolo del valore /Contents della firma, indicizza i certs/OCSP/CRL specifici per quella firma, con una voce di tempo di convalida facoltativa. Il VRI è disattivato per impostazione predefinita: ETSI EN 319 142-1 V1.2.1 §5.4 sconsiglia il VRI nel DSS per i nuovi documenti; alcuni validatori visualizzano comunque meglio lo stato a lungo termine con esso, perciò è abilitabile dal chiamante.
Marca temporale del documento (B-LTA). Dopo che il DSS è stato scritto, un dizionario /DocTimeStamp con /SubFilter /ETSI.RFC3161 viene aggiunto con placeholder per ByteRange e /Contents. Dopo che l’intero file è assemblato, il produttore calcola il digest SHA-256 sul ByteRange, richiede un token RFC 3161 — §2.4.1 — e incorpora il token DER; genTime è l’istante UTC di creazione del token — §2.4.2.

Applicazione della revoca

Il produttore risolve una modalità di applicazione con questa precedenza: una modalità di applicazione strutturata esplicita prevale; altrimenti un booleano esplicito (deprecato) mappa su strict o permissive; altrimenti l’impostazione predefinita è strict (fail-closed).

In applicazione strict, una risposta OCSP mancante e una CRL mancante per qualsiasi certificato non radice sollevano un errore anziché emettere solo un avviso. L’impostazione predefinita fail-closed esiste affinché un PDF «B-LT» non possa essere prodotto senza materiale di revoca nel DSS pur dichiarando il livello a lungo termine. Il flusso di lavoro permissive (solo-avviso) deve essere scelto esplicitamente (opt-in). Con una politica di rete strict-offline, non avviene alcun recupero OCSP/CRL; viene usato solo il materiale incorporato nel DSS e la condizione di materiale mancante è gestita dalla stessa regola di applicazione.

Ciclo di archiviazione

La marca temporale del documento B-LTA è ancorata da un certificato TSA che a sua volta scade. Il ciclo di archiviazione, eseguito prima di tale scadenza, raccoglie materiale di revoca aggiornato per la catena del certificato TSA, riscrive il DSS, aggiunge facoltativamente una voce VRI indicizzata dall’hash del certificato TSA e aggiunge una nuova marca temporale del documento sullo stato aggiornato. Ogni nuova marca temporale copre le precedenti. Eseguire il ciclo nei tempi previsti è un obbligo operativo; il produttore solleva un errore se il ciclo viene richiesto senza alcuna TSA configurata o con politica strict-offline. La superficie di archiviazione completa è documentata nel Riferimento approfondito Archive.

Superficie API (solo contratto pubblico)

Tipo	Genere	Ruolo	Stabilità	Da
`SignerInterface`	interface (`NextPDF\Contracts`)	Il contratto di firma di Core	stable	1.0.0
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	Il contratto del produttore a lungo termine + ciclo di archiviazione risolto in fase di esecuzione	stable	1.0.0
`TsaClientInterface`	interface	Client RFC 3161 TSA che il produttore chiama	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	Selettore e sonda di disponibilità per B-B, B-T, B-LT, B-LTA	stable	1.0.0

SignatureLevel::requiresDss → true per B-LT, B-LTA. requiresDocumentTimestamp → true solo per B-LTA. requiresTimestamp → true per B-T, B-LT, B-LTA. Il codice di produzione dipende da questi contratti; le classi concrete dell’implementazione Enterprise sono interne e non fanno parte dell’API pubblica.

Conformità

Dichiarazione	Standard	Clausola
Firma/marca temporale memorizzata con codifica DER in `/Contents`.	ISO 32000-2	§12.8.1
LTV usa un DSS e un dizionario di marca temporale del documento.	ISO 32000-2	§12.8
Il DSS è il dizionario che è il valore della chiave DSS nel catalogo del documento; contiene Certs, OCSPs, CRLs.	ISO 32000-2	§12.8.4.3
Struttura del dizionario di marca temporale del documento.	ISO 32000-2	§12.8.5
DSS + marche temporali del documento per firme a lungo termine.	ETSI EN 319 142-2	§5.5
Il gestore supporta DSS + marche temporali del documento.	ETSI EN 319 142-2	§6.3.3.3
La richiesta RFC 3161 restituisce TSTInfo; genTime è l’istante UTC di creazione.	RFC 3161	§2.4.1, §2.4.2
OCSP good/revoked/unknown delimitato da thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2
Input di convalida del percorso verso un trust anchor.	RFC 5280	§6.1

Tutte le clausole sono parafrasate. NextPDF non riproduce il testo normativo. NextPDF non avanza alcuna rivendicazione di certificazione PAdES: il produttore scrive strutture allineate ai livelli B-LT e B-LTA 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 l’ancoraggio ETSI citato è EN 319 142-2 e gli ancoraggi ISO/RFC sostengono le rivendicazioni a lungo termine e di marca temporale — la stessa postura di divulgazione del riferimento di firma di Core. Il fatto che una firma prodotta si convalidi è la decisione del verificatore in base ai suoi trust anchor e alla sua politica di freschezza della revoca; il produttore incorpora materiale e non asserisce un esito attendibile.

Casi limite e comportamento in modalità FIPS

Casi limite

Il DSS deve essere scritto prima della marca temporale del documento; una marca temporale scritta prima del DSS non copre il materiale di convalida.
L’applicazione strict (l’impostazione predefinita) solleva un errore quando il materiale di revoca è mancante per un certificato non radice. La modalità permissive è opt-in.
B-LTA senza alcuna TSA configurata solleva un errore anziché produrre B-LT.
Politica strict-offline: nessun accesso di rete OCSP/CRL/TSA; B-LTA non è raggiungibile in strict-offline.
Il token di marca temporale del documento ha uno spazio riservato limitato; un token che lo eccede solleva un errore anziché troncare.

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 aggiunge solo il digest SHA-256 usato per la marca temporale del documento e lo scambio RFC 3161; la primitiva di firma è quella del firmatario di Core. Con il profilo FIPS attivo, vengono prodotte le stesse strutture di DSS, VRI e marca temporale del documento; il vincolo si applica agli algoritmi di firma e di digest, non al layout del DSS. La custodia delle chiavi su hardware tramite PKCS#11 è documentata con il modulo di sicurezza ed è fuori ambito per questa pagina.

Contratto di comportamento

Core produce B-B e B-T (B-T aggiunge la marca temporale RFC 3161 sul valore della firma). Pro produce B-B e B-T tramite lo stesso stack di Core. B-LT e B-LTA sono prodotti solo da Enterprise.
Il produttore scrive il 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 fail-closed di applicazione 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 permissive.
B-LTA richiede una TSA configurata; senza, il passo B-LTA solleva un errore anziché degradare a B-LT.

Fallback Core

In una distribuzione solo-Core, il firmatario software produce PAdES B-B e B-T tramite SignerInterface; Core include il percorso di marca temporale RFC 3161, quindi B-T non necessita di alcun pacchetto premium. Core non ha alcun produttore di DSS, VRI o marca temporale del documento; una richiesta di B-LT o B-LTA fallisce in modo chiuso tramite SignatureLevel::isAvailableInEnvironment che restituisce false.

Fallback Pro

In una distribuzione solo-Pro, il percorso di firma è la baseline B-B/B-T più i flussi di lavoro di firma remoti e cloud-KMS. Pro non produce alcun DSS o marca temporale del documento. RemoteSigningConfig trasporta l’enum Core SignatureLevel, ma un livello a lungo termine (B-LT/B-LTA) è un valore dichiarato in anticipo su cui Pro non agisce; il produttore a lungo termine viene risolto in fase di esecuzione tramite il contratto di Core ed è incluso in nextpdf/enterprise.

Nota sul confine Enterprise

Il dettaglio dei meccanismi interni resta nella documentazione interna del repository sorgente ed è fuori ambito per questo manuale.

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 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 possiede la selezione e la raggiungibilità della TSA, l’accesso ai responder di revoca o il materiale pre-raccolto, la politica di rete e l’esecuzione del ciclo di archiviazione prima che ciascun certificato di marca temporale scada.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie dell’API pubblica supportata. I percorsi di namespace interni, le classi helper, le tabelle dei meccanismi, i nomi di file di runbook e i prefissi di ticket sono fuori ambito.

Confine di conformità legale

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. Il fatto che una firma prodotta si convalidi è la decisione del verificatore in base ai suoi trust anchor e alla sua politica di freschezza della revoca.

Vedere anche

Signature (panoramica della capacità)
Riferimento approfondito Archive — manutenzione DSS/VRI, integrità LTV, ciclo di archiviazione.
Security / Signing (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
Sicurezza Pro — la baseline B-B e il confine Enterprise.
Mappatura della baseline PAdES