Enterprise edizione

Firma: PAdES B-LT / B-LTA, DSS, marche temporali del documento

In sintesi

NextPDF Enterprise aggiunge un produttore a lungo termine sopra la firma Cryptographic Message Syntax (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 PDF Advanced Electronic Signatures (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.

Disponibilità e licenze

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

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. Anche NextPDF Pro produce 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. 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. Ciò corrisponde alla tabella delle edizioni pubblicata nella pagina di sicurezza Pro.

Installazione

composer require nextpdf/enterprise

nextpdf/enterprise dipende da nextpdf/core e nextpdf/pro. Risolvere il pacchetto con le credenziali della licenza NextPDF su Private Packagist.

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 Online Certificate Status Protocol (OCSP) e le liste di revoca dei certificati (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 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 il materiale di 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 sia aggiornato tale stato — RFC 6960 §4.2. Se OCSP non è disponibile, ricorre a una CRL. Il produttore percorre la catena dal firmatario verso 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 (TSA). La richiesta restituisce un valore Time Stamp Information (TSTInfo) — RFC 3161 §2.4.1 — il cui genTime è l’istante Coordinated Universal Time (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. Il flusso seguente mostra tale sequenza del produttore.

Diagram

Perché funziona così

La validità a lungo termine ha un’unica regola d’ordine inderogabile: la marca temporale del documento deve coprire il materiale di convalida. Perciò il DSS viene sempre scritto per primo e la marca temporale B-LTA viene apposta sullo stato del file che già lo include. Invertendo tale ordine, la marca temporale non protegge nulla di ciò che un verificatore legge anni dopo — i certificati, OCSP e CRL resterebbero fuori dalla sua copertura. Il produttore incorpora quindi il materiale e lo ancora nel tempo, ma si ferma prima di asserire un esito attendibile; quella decisione spetta al verificatore e ai suoi trust anchor. Fallire in modo chiuso quando manca il materiale di revoca significa che un documento che dichiara un livello a lungo termine non viene mai distribuito senza l’evidenza che ne supporta la dichiarazione. Il risultato è una firma che un terzo può riverificare molto tempo dopo la scadenza del certificato di firma, senza contattare i responder originali.

Approfondimento di progettazione: Convalida a lungo termine.

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 per 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

<?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;
}

La configurazione di firma trasporta il livello. 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

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Core\Document;
use NextPDF\Exception\NextPdfException;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\SignatureLevel;
use NextPDF\Security\Timestamp\TsaClient;
use Psr\Http\Client\ClientInterface;
use Psr\Log\LoggerInterface;

/**
 * Produce a PAdES B-LTA signature through the high-level Document seam, which
 * drives the Core PadesOrchestrator and the Enterprise long-term producer in the
 * load-bearing order: sign, write the DSS (LtvManager::enableLtv), then add the
 * /DocTimeStamp over the state that already includes it (::addDocumentTimestamp).
 */
final readonly class LongTermSigner
{
    public function __construct(
        private TsaClient $tsa,         // RFC 3161 TSA client (required for B-T and above).
        private ClientInterface $http,  // PSR-18 client that fetches OCSP/CRL for the DSS.
        private LoggerInterface $logger,
    ) {}

    /**
     * Sign at B-LTA and return the long-term-signed PDF bytes; requesting B-LTA
     * without the nextpdf/enterprise producer fails closed rather than downgrading.
     *
     * @throws NextPdfException Fail-closed: enterprise producer absent
     *                          (SignatureLevelUnreachableException), no HTTP client
     *                          (SignatureException), or missing material (LtvException).
     */
    public function sign(CertificateInfo $certInfo): string
    {
        try {
            $document = Document::createStandalone();
            $document->addPage();
            $document->setSignature($certInfo, SignatureLevel::PAdES_B_LTA, $this->tsa, $this->http);

            return $document->getPdfData();
        } catch (NextPdfException $e) {
            $this->logger->error('long-term B-LTA 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, e ciò ancora nel tempo il materiale di convalida stesso.

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 è facoltativo (opt-in) e solo-avviso.
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, il produttore non effettua alcun recupero OCSP/CRL né alcuna richiesta TSA; usa 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

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

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/nextUpdate e delle 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 impedisce che una dichiarazione a lungo termine 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)

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

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 i byte OCSP/CRL incorporati come contenuto del documento, non come contenuto di log.

Comportamento in modalità FIPS

Il profilo di crypto-policy Federal Information Processing Standards (FIPS) 140-3 è una capacità Enterprise documentata con il modulo di sicurezza. Il produttore a lungo termine non aggiunge alcuna primitiva crittografica propria 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

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à

Dichiarazione	Standard	Clausola
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.

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; richiederli senza nextpdf/enterprise fallisce 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.

Confine di pubblicazione

Questa pagina documenta solo il comportamento osservabile dall’esterno e la superficie API pubblica supportata. Percorsi di namespace interni, classi di supporto, tabelle di meccanismi, nomi di file di runbook e prefissi di ticket sono fuori ambito.

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

In una distribuzione solo-Pro, il percorso di firma supportato è 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 key management service (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

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

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

Riguarda la firma crittografica e la convalida a lungo termine. 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

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.
Firma (riferimento Enterprise) — il riferimento API di DSS, VRI e marca temporale del documento per questa capacità.
Mappatura della baseline PAdES — B-B, B-T, B-LT, B-LTA tra le edizioni.
PAdES · DSS · VRI · LTV — termini del glossario.