Enterprise Edition

Signatur: PAdES B-LT / B-LTA, DSS, Dokument-Zeitstempel

Auf einen Blick

NextPDF Enterprise ergänzt die Cryptographic Message Syntax (CMS)-Signatur von Core um einen Langzeit-Erzeuger: einen Document Security Store (DSS), validierungsbezogene Informationen pro Signatur (VRI) und Dokument-Zeitstempel. Diese Strukturen heben eine PAdES-Baseline-Signatur (PDF Advanced Electronic Signatures) von B-B auf B-LT und anschließend auf B-LTA. Diese Seite beschreibt das Verhalten. Sie benennt, was der Erzeuger schreibt, was er nicht entscheidet und wo die Pro-Grenze beginnt.

Verfügbarkeit & Lizenzierung

Diese Fähigkeit ist in NextPDF Enterprise (nextpdf/enterprise) enthalten und wird mit einem Lizenz-Envelope der Enterprise-Stufe aktiviert. Ein Deployment ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. Editionen vergleichen und eine Lizenz erwerben.

NextPDF Core erzeugt die PAdES-Baseline-Stufen B-B und B-T: Core liefert den Software-CMS-Signierer sowie den RFC 3161-Zeitstempelpfad, sodass eine B-T-Signatur (mit Zeitstempel) eine Core-Fähigkeit ist und Enterprise nicht erfordert. NextPDF Pro erzeugt ebenfalls B-B und B-T: Pro setzt den Core-RFC 3161-Stack zusammen, um das unsignierte Attribut signature-time-stamp auf dem Signaturwert hinzuzufügen (PadesBtTimestamper, fixture-verifiziert). Die Stufen B-LT und B-LTA — der Erzeuger für DSS, VRI und Dokument-Zeitstempel — sind eine Enterprise-Fähigkeit und werden nicht von Core oder Pro erzeugt. In einem Pro-only-Deployment scheitert die Anforderung von B-LT oder B-LTA fail-closed mit einer Meldung, die die fehlende Enterprise-Komponente benennt, weil SignatureLevel::isAvailableInEnvironment() false zurückgibt, wenn der Enterprise-Langzeit-Erzeuger fehlt.

PAdES-Stufe	Fügt hinzu	Erzeuger-Edition
B-B	CMS-Signatur mit signierten Attributen	Core, Pro, Enterprise
B-T	RFC 3161-signature-time-stamp auf dem Signaturwert (strukturell; nicht eIDAS-qualifiziert)	Core, Pro, Enterprise
B-LT	Document Security Store mit Validierungsmaterial	Nur Enterprise (`nextpdf/enterprise`)
B-LTA	Dokument-Zeitstempel für Archivierungsgültigkeit	Nur Enterprise (`nextpdf/enterprise`)

Dies ist die kanonische Stufe→Tier-Matrix: B-B ist die von jeder Edition erzeugte Baseline; B-T (mit Zeitstempel) wird ebenfalls von Core und Pro erzeugt (Pro setzt den Core-RFC 3161-Stack zusammen); B-LT und B-LTA sind Enterprise-only. Der B-T-Erzeuger ist strukturell; er begründet keinen zertifizierten ETSI EN 319 142-1-Konformitäts- oder eIDAS-qualifizierten Anspruch. Dies entspricht der veröffentlichten Tier-Tabelle auf der Pro-Sicherheitsseite.

Installation

composer require nextpdf/enterprise

nextpdf/enterprise hängt von nextpdf/core und nextpdf/pro ab. Lösen Sie das Paket mit Ihren NextPDF-Lizenz-Anmeldedaten über Private Packagist auf.

Konzeptioneller Überblick

Eine PAdES-Baseline-Signatur umfasst vier Stufen. Jede Stufe ergänzt Material gegenüber der vorherigen. B-B ist eine CMS-Signatur mit signierten Attributen. B-T fügt einen vertrauenswürdigen RFC 3161-Zeitstempel über den Signaturwert hinzu. B-LT ergänzt einen DSS, der die Zertifikate, Online Certificate Status Protocol (OCSP)-Antworten und Zertifikatssperrlisten (CRLs) enthält, die ein Prüfer nach Ablauf des Signaturzertifikats benötigt. B-LTA fügt einen Dokument-Zeitstempel über den gesamten Dokumentzustand einschließlich des DSS hinzu, sodass das Validierungsmaterial zeitlich verankert bleibt.

Core erzeugt die CMS-SignedData und speichert sie DER-codiert im Eintrag Contents des Signatur-Dictionarys — ISO 32000-2 §12.8.1. Die Langzeitvalidierung nutzt zwei Dictionary-Typen: einen Document Security Store und ein Dokument-Zeitstempel-Dictionary — ISO 32000-2 §12.8. Der Enterprise-Erzeuger schreibt den DSS, der das Zertifikats-, OCSP- und CRL-Material enthält — ISO 32000-2 §12.8.4.3 — und für B-LTA das Dokument-Zeitstempel-Dictionary — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 beschreibt dieselbe Langzeitstruktur: DSS-Einträge plus Dokument-Zeitstempel für Langzeitsignaturen — §5.5 —, unterstützt vom Signatur-Handler — §6.3.3.3.

Der Erzeuger erfasst Sperrmaterial für jedes Zertifikat der Kette. Er fragt zuerst einen OCSP-Responder ab; eine OCSP-Antwort meldet good, revoked oder unknown — RFC 6960 §2.2 — und die Felder thisUpdate und nextUpdate begrenzen die Aktualität des Status — RFC 6960 §4.2. Ist OCSP nicht verfügbar, fällt er auf eine CRL zurück. Der Erzeuger durchläuft die Kette vom Signierer bis zu einem Vertrauensanker gemäß den Eingaben der Pfadvalidierung — RFC 5280 §6.1.

Der B-LTA-Dokument-Zeitstempel ist ein RFC 3161-Austausch mit einer Time-Stamping Authority (TSA). Die Anfrage liefert einen Time Stamp Information (TSTInfo)-Wert zurück — RFC 3161 §2.4.1 —, dessen genTime der Coordinated Universal Time (UTC)-Zeitpunkt ist, zu dem das Token erstellt wurde — RFC 3161 §2.4.2. Das Token wird in ein /DocTimeStamp-Dictionary mit /SubFilter /ETSI.RFC3161 eingebettet, das die gesamte Datei abdeckt.

Der Prüfer entscheidet anhand seiner konfigurierten Vertrauensanker und Sperrrichtlinie, ob eine erzeugte Signatur verifiziert wird. Der Erzeuger bettet Material ein; er sichert kein vertrauenswürdiges Ergebnis zu. Diese Grenze wird unten überall dort erneut genannt, wo sie eine Rolle spielt.

Die Reihenfolge ist entscheidend: Der DSS muss vor dem B-LTA-Dokument-Zeitstempel geschrieben werden, weil der Zeitstempel den Dokumentzustand abdecken muss, der das Validierungsmaterial bereits enthält. Der Ablauf unten zeigt diese Erzeuger-Sequenz.

Diagram

Warum das so funktioniert

Die Langzeitgültigkeit kennt eine unverrückbare Reihenfolgeregel: Der Dokument-Zeitstempel muss das Validierungsmaterial abdecken. Deshalb wird der DSS immer zuerst geschrieben, und der B-LTA-Zeitstempel wird über den Dateizustand erstellt, der ihn bereits enthält. Kehrt man diese Reihenfolge um, schützt der Zeitstempel nichts, was ein Prüfer Jahre später liest — die Zertifikate, OCSP und CRLs lägen außerhalb seiner Abdeckung. Der Erzeuger bettet daher Material ein und verankert es zeitlich, sichert aber kein vertrauenswürdiges Ergebnis zu; diese Entscheidung liegt beim Prüfer und seinen Vertrauensankern. Das Fail-closed-Verhalten bei fehlendem Sperrmaterial bedeutet, dass ein Dokument, das eine Langzeitstufe beansprucht, niemals ohne die Evidenz ausgeliefert wird, die diesen Anspruch untermauert. Das Ergebnis ist eine Signatur, die ein Dritter noch lange nach Ablauf des Signaturzertifikats erneut prüfen kann, ohne die ursprünglichen Responder zu kontaktieren.

Design-Hintergrund: Langzeitvalidierung.

API-Oberfläche

Sie konsumieren den Enterprise-Langzeit-Erzeuger über den Core-Vertrag. Produktionscode hängt vom Vertrag ab, nicht vom konkreten Enterprise-Implementierungstyp.

Typ	Art	Rolle	Stabilität	Seit
`SignerInterface`	interface (`NextPDF\Contracts`)	Core-Signiervertrag für Aufrufer	stable	1.0.0
`SignatureLevel`	enum (`NextPDF\Security\Signature`)	PAdES-Stufen-Selektor: B-B, B-T, B-LT, B-LTA	stable	1.0.0
`LtvManagerInterface`	interface (`NextPDF\Contracts`)	Zur Laufzeit aufgelöster Vertrag des Langzeitvalidierungs-Erzeugers	stable	1.0.0
`TsaClientInterface`	interface	RFC 3161-TSA-Client, den der Erzeuger für Dokument-Zeitstempel aufruft	stable	1.0.0

SignatureLevel::requiresDss() ist true für B-LT und B-LTA; SignatureLevel::requiresDocumentTimestamp() ist nur für B-LTA true. Das Core-SignatureLevel::isAvailableInEnvironment() gibt false für B-LT und B-LTA zurück, wenn der Enterprise-Langzeit-Erzeuger nicht installiert ist; der Core-Orchestrator bricht dann fail-closed ab. Die konkreten Enterprise-Erzeugerklassen sind intern und nicht Teil der öffentlichen API; verwenden Sie LtvManagerInterface und das Enum als Abhängigkeiten.

Codebeispiel — Schnellstart

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

Die Signierkonfiguration trägt die Stufe. Der Core-Orchestrator löst den Langzeit-Erzeuger zur Laufzeit über LtvManagerInterface auf, sodass Anwendungscode keinen Enterprise-Typ referenziert.

Codebeispiel — Produktion

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

Der DSS muss vor dem Dokument-Zeitstempel geschrieben werden. Der B-LTA-Zeitstempel deckt die gesamte Datei einschließlich des DSS ab und verankert damit das Validierungsmaterial selbst zeitlich.

Sonderfälle & Fallstricke

Fehlendes Sperrmaterial scheitert standardmäßig fail-closed. Ist kein Durchsetzungsmodus gesetzt, behandelt der Erzeuger eine fehlende OCSP-Antwort und eine fehlende CRL für jedes Nicht-Wurzelzertifikat als Fehler, nicht als Warnung. Dadurch wird verhindert, dass ein Dokument, das eine Langzeitstufe beansprucht, ohne Sperrmaterial im DSS geschrieben wird. Der permissive Workflow ist optional aktivierbar und gibt nur Warnungen aus.
B-LTA benötigt eine TSA. Ein Dokument-Zeitstempel ist ein RFC 3161-Roundtrip. Ist kein TSA-Client konfiguriert, löst der B-LTA-Schritt einen Fehler aus, statt stillschweigend B-LT zu erzeugen.
Die Reihenfolge ist entscheidend. Fügen Sie den Dokument-Zeitstempel erst hinzu, nachdem der DSS geschrieben ist. Ein vor dem DSS erstellter Zeitstempel deckt das Validierungsmaterial nicht ab.
Air-Gap-Läufe. Bei einer strikten Offline-Netzwerkrichtlinie führt der Erzeuger keinen OCSP-/CRL-Abruf und keine TSA-Anfrage durch; er verwendet nur Material, das bereits im DSS eingebettet ist. B-LTA, das ein frisches TSA-Token erfordert, ist strikt offline nicht erreichbar.
VRI ist optional aktivierbar. VRI pro Signatur wird standardmäßig nicht geschrieben. Manche Validatoren stellen den Langzeitstatus besser dar, wenn VRI vorhanden ist; aktivieren Sie es, wenn ein Ziel-Prüfer es benötigt.

Performance

Der Aufwand für die DSS-Zusammenstellung skaliert mit der Kettenlänge und der Anzahl der abgerufenen Sperrantworten. Jeder OCSP- oder CRL-Abruf ist ein Netzwerk-Roundtrip; vorab erfasstes oder zwischengespeichertes Material vermeidet diese Roundtrips. Ein B-LTA-Lauf fügt einen TSA-Roundtrip für den Dokument-Zeitstempel hinzu. Das Wall-Clock-Budget von 1500 ms deckt eine einzelne Langzeitsignatur mit warmen OCSP-/CRL- und TSA-Verbindungen ab; kalte oder langsame Responder dominieren die verstrichene Zeit. Das Reproduzierbarkeitsprofil ist structural: Zeitstempel enthalten die Signier- und Stempelzeitpunkte, sodass sich zwei Läufe in diesen Bytes unterscheiden, während die Dokumentstruktur identisch ist.

Sicherheitshinweise

Vertrauen ist die Entscheidung des Prüfers. Der Erzeuger bettet Zertifikate, OCSP und CRLs ein. Ob die Signatur validiert wird, hängt vom Prüfer, seinen Vertrauensankern und seiner Richtlinie zur Sperr-Aktualität ab. NextPDF liefert keine eingebaute Vertrauensliste aus.
Die Aktualität der Sperrung ist zeitlich begrenzt. OCSP-thisUpdate/nextUpdate und CRL-Gültigkeitsfenster begrenzen, wie lange eingebettetes Material verwendbar bleibt. Die Archivierungsschleife stempelt erneut, bevor das Zeitstempelzertifikat abläuft; Sie sind für ihren planmäßigen Betrieb verantwortlich.
Fail-closed-Standard. Der Standard für die strikte Sperrdurchsetzung verhindert, dass ein Langzeitanspruch ohne das Material erhoben wird, das ihn untermauert.
Siehe den Abschnitt zum Enterprise-Bedrohungsmodell und Archiv: DSS, VRI, LTV-Gesundheit.

Datenresidenz & PII-Minderungen

Der OCSP- und CRL-Abruf kontaktiert die in jedem Zertifikat benannten Responder; diese Endpunkte und die TSA sehen Anfrage-Metadaten. Erfassen Sie in einem Deployment mit Datenresidenzbeschränkungen Sperrmaterial vorab und betreiben Sie das System unter der strikten Offline-Richtlinie, sodass zum Signierzeitpunkt kein Responder und keine TSA kontaktiert wird. Zertifikate tragen die Subjektidentität. Der Erzeuger bettet die für die Validierung erforderlichen Zertifikate ein und fügt keine Identität über die Kette hinaus hinzu; er entfernt keine Subjektfelder aus einem von Ihnen bereitgestellten Zertifikat.

Sichere Telemetrie & Log-Bereinigung

Die Erzeugerdiagnose meldet Stufe, Kettenposition und die Bedingung für fehlendes Material. Sie protokolliert keine privaten Schlüssel und keine vollständigen Zertifikatskörper. Halten Sie beim Anschließen eines PSR-3-Loggers die Diagnoseprotokolle für Signierabläufe auf einer nicht produktiven Ausführlichkeit und bereinigen Sie Responder-URLs, wenn diese interne Infrastruktur preisgeben. Behandeln Sie eingebettete OCSP-/CRL-Bytes als Dokumentinhalt, nicht als Log-Inhalt.

Verhalten im FIPS-Modus

Das Federal Information Processing Standards (FIPS) 140-3-Kryptorichtlinienprofil ist eine Enterprise-Fähigkeit, die mit dem Sicherheitsmodul dokumentiert ist. Der Langzeit-Erzeuger fügt über den für den Dokument-Zeitstempel und den RFC 3161-Austausch verwendeten SHA-256-Digest hinaus kein eigenes kryptografisches Primitiv hinzu; das Signaturprimitiv ist das des Core-Signierers. Wenn das FIPS-Profil aktiv ist, werden dieselben DSS- und Dokument-Zeitstempel-Strukturen erzeugt; die Einschränkung gilt für die zugrunde liegenden Signier- und Digest-Algorithmen, nicht für das DSS-Layout.

Bedrohungsmodell

Asset	Angreifer	Risiko	Minderung
DSS-Sperrmaterial	Akzeptanz veralteten Materials	Ein Prüfer vertraut abgelaufenen Sperrdaten	OCSP-/CRL-Aktualitätsfelder begrenzen die Gültigkeit; die Archivierungsschleife stempelt vor Ablauf erneut
B-LTA-Dokument-Zeitstempel	Kompromittierung der TSA oder nicht erreichbare TSA	Kein vertrauenswürdiger Zeitanker	Vom Aufrufer gewählte TSA; B-LTA scheitert fail-closed, wenn keine TSA konfiguriert ist
Langzeitanspruch	Stillschweigend fehlendes Material	Ein „langfristiges“ PDF ohne Sperrdaten	Der Fail-closed-Durchsetzungsstandard löst einen Fehler statt einer Warnung aus
Signaturverifikation	Falsch konfiguriertes Prüfervertrauen	Scheinbare Gültigkeit, die der Prüfer nicht zusichern sollte	Der Erzeuger erklärt, dass er nur Material einbettet; die Vertrauensentscheidung liegt beim Prüfer

Konformität

Anspruch	Standard	Klausel
Der Signaturwert (oder das Zeitstempel-Token) wird DER-codiert in `/Contents` gespeichert.	ISO 32000-2	§12.8.1
Die Langzeitvalidierung nutzt einen DSS und ein Dokument-Zeitstempel-Dictionary.	ISO 32000-2	§12.8
Der DSS enthält Zertifikate, OCSP-Antworten und CRLs.	ISO 32000-2	§12.8.4.3
Der Dokument-Zeitstempel nutzt ein Dokument-Zeitstempel-Dictionary.	ISO 32000-2	§12.8.5
DSS-Einträge und Dokument-Zeitstempel unterstützen Langzeitsignaturen.	ETSI EN 319 142-2	§5.5
Der Signatur-Handler unterstützt DSS-Einträge und Dokument-Zeitstempel.	ETSI EN 319 142-2	§6.3.3.3
Ein Zeitstempel-Token trägt eine UTC-genTime, die der Zeitpunkt ist, zu dem es erstellt wurde.	RFC 3161	§2.4.2
OCSP meldet good, revoked oder unknown, begrenzt durch thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder; konsultieren Sie die veröffentlichten Standards für den verbindlichen Wortlaut. NextPDF erhebt keinen PAdES-Zertifizierungsanspruch. Die hier beschriebenen Strukturen sind an den in ETSI EN 319 142 definierten Stufen B-LT und B-LTA ausgerichtet; es wird kein Ergebnis eines Konformitätstests und keine Drittanbieter-Attestierung beansprucht. Der Baseline-Stufen-Teil ETSI EN 319 142-1 liegt außerhalb der zitierten Evidenzmenge, sodass diese Seite die erzeugte Struktur und die Pro-/Enterprise-Grenze nennt, nicht eine zertifizierte Konformitätsstufe. Die zitierte ETSI-Evidenz ist EN 319 142-2; die ISO- und RFC-Anker stützen die Langzeit- und Zeitstempelansprüche, wie es auch die Core-Signierreferenz tut.

Verhaltensvertrag

Core und Pro erzeugen beide B-B und B-T (B-T fügt den RFC 3161-signature-time-stamp hinzu; Pro setzt den Core-RFC 3161-Stack zusammen). B-LT und B-LTA bilden eine Enterprise-Grenze; eine Anforderung dafür ohne nextpdf/enterprise scheitert fail-closed mit einem benannten Fehler.
Der Erzeuger schreibt einen DSS (B-LT) und einen Dokument-Zeitstempel über den DSS (B-LTA). Er bettet Validierungsmaterial ein; er sichert kein vertrauenswürdiges Verifikationsergebnis zu.
Der Fail-closed-Standard für die Sperrdurchsetzung löst einen Fehler aus, wenn Sperrmaterial für ein Nicht-Wurzelzertifikat fehlt, sofern der Aufrufer sich nicht für den permissiven Workflow entscheidet.
B-LTA erfordert eine konfigurierte TSA; ohne eine solche löst der B-LTA-Schritt einen Fehler aus, statt auf B-LT herabzustufen.

Publikationsgrenze

Diese Seite dokumentiert nur extern beobachtbares Verhalten und die unterstützte öffentliche API-Oberfläche. Interne Namespace-Pfade, Hilfsklassen, Mechanismus-Tabellen, Runbook-Dateinamen und Ticket-Präfixe liegen außerhalb des Umfangs.

Core-Fallback

In einem Core-only-Deployment erzeugt der Software-Signierer PAdES B-B und B-T mit einem lokalen Schlüssel oder einem über den Core-Signierstrategie-Vertrag bereitgestellten Schlüssel. Core liefert den RFC 3161-Zeitstempelpfad, sodass B-T ohne Premium-Paket erreichbar ist. Core hat keinen Erzeuger für DSS, VRI oder Dokument-Zeitstempel; die Anforderung von B-LT oder B-LTA scheitert fail-closed mit einem benannten Fehler. Siehe Sicherheit / Signieren (Core).

Pro-Fallback

In einem Pro-only-Deployment ist der unterstützte Signierpfad die B-B-Baseline von Pro und die B-T-Stufe von Pro (Pro setzt den Core-RFC 3161-Stack zusammen, um das unsignierte Attribut signature-time-stamp hinzuzufügen), zuzüglich der Remote- und Cloud-Key-Management-Service (KMS)-Signierstrategien. Pro erzeugt keinen DSS, kein VRI und keinen Dokument-Zeitstempel. Eine Konfiguration, die B-LT oder B-LTA in einem Pro-only-Deployment anfordert, scheitert fail-closed mit einer Meldung, die die fehlende Enterprise-Komponente benennt. Siehe Pro-Sicherheit zur Pro-Signier-Oberfläche.

Hinweis zur Enterprise-Grenze

Der Erzeuger für DSS, VRI und Dokument-Zeitstempel wird nur auf Verhaltensebene beschrieben. Die interne Logik der Reihenfolge bei der DSS-Zusammenstellung, die Interna der VRI-Schlüsselableitung pro Signatur und die Interna der Archivierungsschleifen-Planung liegen außerhalb des Umfangs der öffentlichen Oberfläche und werden hier nicht wiedergegeben.

Deployment-Grenze

NextPDF Enterprise bettet Validierungsmaterial ein; es arbeitet mit vom Aufrufer bereitgestellten OCSP-/CRL-Respondern sowie einer RFC 3161-TSA zusammen. Es betreibt oder hostet diese Responder oder die TSA nicht selbst und garantiert deren Verfügbarkeit nicht. Die Langzeitgültigkeit hängt von den Respondern, der TSA, dem Zeitplan der Archivierungsschleife und dem Betreiber ab — nicht von NextPDF Enterprise allein. Der Betreiber ist verantwortlich für die Auswahl und Erreichbarkeit der TSA, den Zugriff auf Sperr-Responder oder vorab erfasstes Material, die Netzwerkrichtlinie und die Ausführung der Archivierungsschleife, bevor jedes Zeitstempelzertifikat abläuft.

Grenze der rechtlichen Compliance

Diese Seite betrifft kryptografisches Signieren und Langzeitvalidierung. Die Ausrichtung an den in ETSI EN 319 142 definierten Strukturen B-LT und B-LTA ist eine strukturelle Aussage, keine rechtliche Stellungnahme und keine Zertifizierung. NextPDF erhebt keinen PAdES-Zertifizierungsanspruch. Konsultieren Sie Ihre Compliance- und Rechtsberater zu Ihren regulatorischen Pflichten.

Siehe auch

Sicherheit / Signieren (Core) — CMS, RFC 3161, RFC 5280-Pfadvalidierung, OCSP/CRL.
Pro-Sicherheit — B-B-Baseline und die Enterprise-Grenze.
Archiv: DSS, VRI, LTV-Gesundheit — Langzeit-Archivierung und LTV-Gesundheit.
Signaturverifikation — die Prüfseite: kryptografische CMS-/Zeitstempel-Verifikation, TSA-bei-genTime und Validierung der Archivierungskette.
Signatur (Enterprise-Referenz) — die API-Referenz für DSS, VRI und Dokument-Zeitstempel dieser Fähigkeit.
PAdES-Baseline-Zuordnung — B-B, B-T, B-LT, B-LTA über alle Editionen.
PAdES · DSS · VRI · LTV — Glossarbegriffe.