Signatur — Ausführliche Referenz

Auf einen Blick

Dies ist die Tiefenreferenz für den Langzeit-Erzeuger von NextPDF Enterprise: wie eine B-LT- oder B-LTA-Signatur zusammengesetzt wird, wie Sperrmaterial erfasst und durchgesetzt wird, wie der Dokument-Zeitstempel das Dokument verankert und wie die Pro-Grenze durchgesetzt wird. Sie ist auf Verhaltens- und Vertragsebene angesiedelt. Konkrete Enterprise-Implementierungstypen werden hier bewusst nicht benannt; die Seite referenziert ausschließlich das öffentliche Paket und die Core-Vertragsoberfläche.

Verfügbarkeit & Lizenzierung

Diese Fähigkeit wird in NextPDF Enterprise (nextpdf/enterprise) ausgeliefert und aktiviert sich mit einer Lizenzhülle der Enterprise-Stufe. Ein Deployment ohne diese Berechtigung lädt die Klassen der Fähigkeit nicht. Editionen vergleichen und eine Lizenz erhalten.

Die kanonische Stufe→Tier-Matrix: B-B ist die von Core, Pro und Enterprise erzeugte Baseline; B-T (mit Zeitstempel) wird von Core, Pro und Enterprise erzeugt — Core liefert den RFC 3161-Zeitstempelpfad, sodass B-T kein Premium-Paket erfordert; B-LT und B-LTA (DSS, VRI, Dokument-Zeitstempel) werden nur von Enterprise erzeugt. In einem Pro-only-Deployment scheitert die Anforderung von B-LT oder B-LTA fail-closed: Das Core-SignatureLevel::isAvailableInEnvironment gibt false zurück, wenn der Enterprise-Langzeit-Erzeuger fehlt, und der Core-Orchestrator löst einen benannten Fehler aus, statt die Stufe stillschweigend herabzustufen.

PAdES level	Adds	Producer edition
B-B	CMS-Signatur mit signierten Attributen	Core, Pro, Enterprise
B-T	Vertrauenswürdiger RFC 3161-Zeitstempel auf dem Signaturwert	Core, Pro, Enterprise
B-LT	Document Security Store mit Validierungsmaterial	Nur Enterprise
B-LTA	Dokument-Zeitstempel über den DSS (Archivierungsschleife)	Nur Enterprise

Konzeptionelles Modell

Eine B-LT-Signatur ist eine B-T-Signatur plus einem Document Security Store. Der DSS ist ein Dictionary auf Catalog-Ebene, das die Zertifikats-, OCSP-Antwort- und CRL-Streams enthält, die ein Prüfer benötigt, sobald das Signaturzertifikat abgelaufen ist — ISO 32000-2 §12.8.4.3. Die Langzeitvalidierung nutzt zwei Dictionary-Typen — einen DSS und ein Dokument-Zeitstempel-Dictionary — ISO 32000-2 §12.8. Die CMS-Signatur selbst wird DER-codiert in /Contents gespeichert — ISO 32000-2 §12.8.1.

Eine B-LTA-Signatur fügt einen Dokument-Zeitstempel über den gesamten Dokumentzustand einschließlich des DSS hinzu, geschrieben über das Dokument-Zeitstempel-Dictionary — ISO 32000-2 §12.8.5. ETSI EN 319 142-2 beschreibt dieselbe Langzeit-Zusammensetzung — §5.5 — und die Handler-Unterstützung — §6.3.3.3.

Erzeuger-Ablauf

1. Die Kette aufbauen. Das Signiererzertifikat plus etwaige vom Aufrufer bereitgestellte Intermediate-Zertifikate bilden die Kette, Signierer zuerst, hin zum Vertrauensanker — RFC 5280 §6.1.
2. Sperrmaterial erfassen. Für jedes Nicht-Wurzelzertifikat fragt der Erzeuger zuerst OCSP ab. Eine OCSP-Antwort meldet good, revoked oder unknown — RFC 6960 §2.2 — und ist durch thisUpdate/nextUpdate zeitlich begrenzt — RFC 6960 §4.2. Ist OCSP nicht verfügbar, fällt er auf eine CRL zurück, mit Delta-CRL-Unterstützung; eine Basis-CRL und eine optionale Delta-CRL werden als separate DSS-Einträge hinzugefügt.
3. Den DSS schreiben. Zertifikate, OCSP-Antworten und CRLs werden als einzelne PDF-Stream-Objekte geschrieben; Duplikate werden per Inhalts-Hash dedupliziert. Das DSS-Dictionary referenziert sie über /Certs, /OCSPs, /CRLs.
4. VRI pro Signatur (optional aktivierbar). Ein VRI-Eintrag, indiziert über den Großbuchstaben-Hash des /Contents-Werts der Signatur, indiziert die spezifischen Certs/OCSP/CRLs für diese Signatur, mit einem optionalen Validierungszeit-Eintrag. VRI ist standardmäßig deaktiviert: ETSI EN 319 142-1 V1.2.1 §5.4 empfiehlt für neue Dokumente, auf VRI im DSS zu verzichten; manche Validatoren stellen den Langzeitstatus damit dennoch besser dar, daher ist es vom Aufrufer aktivierbar.
5. Dokument-Zeitstempel (B-LTA). Nachdem der DSS geschrieben ist, wird ein /DocTimeStamp-Dictionary mit /SubFilter /ETSI.RFC3161 samt ByteRange- und /Contents-Platzhaltern angehängt. Nach dem Zusammenbau der vollständigen Datei berechnet der Erzeuger den SHA-256-Digest über die ByteRange, fordert ein RFC 3161-Token an — §2.4.1 — und bettet das DER-Token ein; genTime ist der UTC-Zeitpunkt der Token-Erstellung — §2.4.2.

Sperrdurchsetzung

Der Erzeuger löst einen Durchsetzungsmodus mit dieser Präzedenz auf: Ein expliziter strukturierter Durchsetzungsmodus gewinnt; andernfalls bildet ein expliziter (veralteter) Boolean auf strikt oder permissiv ab; andernfalls ist der Standard strikt (fail-closed).

Unter strikter Durchsetzung lösen eine fehlende OCSP-Antwort und eine fehlende CRL für jedes Nicht-Wurzelzertifikat einen Fehler aus, statt nur eine Warnung auszugeben. Der Fail-closed-Standard besteht, damit kein „B-LT“-PDF ohne Sperrmaterial im DSS erzeugt werden kann, während es weiterhin die Langzeitstufe ausweist. Der permissive Workflow (nur Warnungen) muss explizit aktiviert werden. Unter einer strikten Offline-Netzwerkrichtlinie erfolgt kein OCSP-/CRL-Abruf; verwendet wird nur DSS-eingebettetes Material, und die Bedingung für fehlendes Material wird von derselben Durchsetzungsregel behandelt.

Archivierungsschleife

Der B-LTA-Dokument-Zeitstempel wird durch ein TSA-Zertifikat verankert, das selbst abläuft. Die Archivierungsschleife, ausgeführt vor diesem Ablauf, erfasst frisches Sperrmaterial für die TSA-Zertifikatskette, schreibt den DSS neu, fügt optional einen über den TSA-Zertifikats-Hash indizierten VRI-Eintrag hinzu und fügt einen neuen Dokument-Zeitstempel über den aktualisierten Zustand hinzu. Jeder neue Zeitstempel deckt die vorherigen ab. Das planmäßige Ausführen der Schleife ist eine operative Pflicht; der Erzeuger löst einen Fehler aus, wenn die Schleife ohne konfigurierte TSA oder unter strikter Offline-Richtlinie angefordert wird. Die vollständige Archivierungsoberfläche ist in der Archiv-Tiefenreferenz dokumentiert.

API-Oberfläche (nur öffentlicher Vertrag)

Type	Kind	Role	Stability	Since
SignerInterface	interface (NextPDF\Contracts)	Der Core-Signiervertrag	stable	1.0.0
LtvManagerInterface	interface (NextPDF\Contracts)	Der zur Laufzeit aufgelöste Vertrag des Langzeit-Erzeugers + der Archivierungsschleife	stable	1.0.0
TsaClientInterface	interface	RFC 3161-TSA-Client, den der Erzeuger aufruft	stable	1.0.0
SignatureLevel	enum (NextPDF\Security\Signature)	B-B-, B-T-, B-LT-, B-LTA-Selektor und Verfügbarkeitssonde	stable	1.0.0

SignatureLevel::requiresDss → true für B-LT, B-LTA. requiresDocumentTimestamp → nur für B-LTA true. requiresTimestamp → true für B-T, B-LT, B-LTA. Produktionscode hängt von diesen Verträgen ab; die konkreten Enterprise-Implementierungsklassen sind intern und nicht Teil der öffentlichen API.

Konformität

Claim	Standard	Clause
Signatur/Zeitstempel DER-codiert in /Contents gespeichert.	ISO 32000-2	§12.8.1
LTV nutzt einen DSS und ein Dokument-Zeitstempel-Dictionary.	ISO 32000-2	§12.8
Der DSS ist das Dictionary, das der Wert des DSS-Keys im Dokumentkatalog ist; enthält Certs, OCSPs, CRLs.	ISO 32000-2	§12.8.4.3
Struktur des Dokument-Zeitstempel-Dictionarys.	ISO 32000-2	§12.8.5
DSS + Dokument-Zeitstempel für Langzeitsignaturen.	ETSI EN 319 142-2	§5.5
Der Handler unterstützt DSS + Dokument-Zeitstempel.	ETSI EN 319 142-2	§6.3.3.3
Die RFC 3161-Anfrage gibt eine TSTInfo zurück; genTime ist der UTC-Erstellungszeitpunkt.	RFC 3161	§2.4.1, §2.4.2
OCSP good/revoked/unknown, begrenzt durch thisUpdate/nextUpdate.	RFC 6960	§2.2, §4.2
Eingaben der Pfadvalidierung zu einem Vertrauensanker.	RFC 5280	§6.1

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder. NextPDF erhebt keinen PAdES-Zertifizierungsanspruch: Der Erzeuger schreibt Strukturen, die an den in ETSI EN 319 142 definierten Stufen B-LT und B-LTA ausgerichtet sind; 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 der zitierte ETSI-Anker EN 319 142-2 ist und die ISO-/RFC-Anker die Langzeit- und Zeitstempelansprüche tragen — dieselbe Offenlegungshaltung wie die Core-Signierreferenz. Ob eine erzeugte Signatur verifiziert wird, entscheidet der Prüfer anhand seiner Vertrauensanker und seiner Richtlinie zur Aktualität der Sperrung; der Erzeuger bettet Material ein und sichert kein vertrauenswürdiges Ergebnis zu.

Sonderfälle & FIPS-Modus-Verhalten

Sonderfälle

• Der DSS muss vor dem Dokument-Zeitstempel geschrieben werden; ein vor dem DSS geschriebener Zeitstempel deckt das Validierungsmaterial nicht ab.
• Die strikte Durchsetzung (der Standard) löst einen Fehler aus, wenn Sperrmaterial für ein Nicht-Wurzelzertifikat fehlt. Permissiv ist Opt-in.
• B-LTA ohne konfigurierte TSA löst einen Fehler aus, statt B-LT zu erzeugen.
• Strikte Offline-Richtlinie: kein OCSP-/CRL-/TSA-Netzwerkzugriff; B-LTA ist strikt offline nicht erreichbar.
• Das Dokument-Zeitstempel-Token hat einen begrenzten reservierten Platz; ein Token, das ihn überschreitet, löst einen Fehler aus, statt abzuschneiden.

FIPS-Modus-Verhalten

Das FIPS 140-3-Kryptorichtlinienprofil ist eine Enterprise-Fähigkeit, die mit dem Sicherheitsmodul dokumentiert ist. Der Langzeit-Erzeuger fügt nur den für den Dokument-Zeitstempel und den RFC 3161-Austausch verwendeten SHA-256-Digest hinzu; das Signaturprimitiv ist das des Core-Signierers. Unter dem FIPS-Profil werden dieselben DSS-, VRI- und Dokument-Zeitstempel-Strukturen erzeugt; die Einschränkung gilt für die Signier- und Digest-Algorithmen, nicht für das DSS-Layout. Die Hardware-Schlüsselverwahrung über PKCS#11 ist mit dem Sicherheitsmodul dokumentiert und liegt außerhalb des Umfangs dieser Seite.

Verhaltensvertrag

• Core erzeugt B-B und B-T (B-T fügt den RFC 3161-Zeitstempel auf dem Signaturwert hinzu). Pro erzeugt B-B und B-T über denselben Core-Stack. B-LT und B-LTA werden nur von Enterprise erzeugt.
• Der Erzeuger schreibt den 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.

Core-Fallback

In einem Core-only-Deployment erzeugt der Software-Signierer PAdES B-B und B-T über SignerInterface; Core liefert den RFC 3161-Zeitstempelpfad, sodass B-T kein Premium-Paket benötigt. Core hat keinen Erzeuger für DSS, VRI oder Dokument-Zeitstempel; eine B-LT- oder B-LTA-Anforderung scheitert fail-closed, indem SignatureLevel::isAvailableInEnvironment false zurückgibt.

Pro-Fallback

In einem Pro-only-Deployment ist der Signierpfad die B-B/B-T-Baseline plus Remote- und Cloud-KMS-Signier-Workflows. Pro erzeugt keinen DSS und keinen Dokument-Zeitstempel. RemoteSigningConfig trägt das Core-SignatureLevel-Enum, aber eine Langzeitstufe (B-LT/B-LTA) ist ein vorab deklarierter Wert, auf den Pro nicht reagiert; der Langzeit-Erzeuger wird zur Laufzeit über den Core-Vertrag aufgelöst und in nextpdf/enterprise ausgeliefert.

Hinweis zur Enterprise-Grenze

Interne Mechanismusdetails verbleiben in der internen Dokumentation des Quell-Repositorys und liegen außerhalb des Umfangs dieses Handbuchs.

Deployment-Grenze

NextPDF Enterprise bettet Validierungsmaterial ein; es integriert sich mit vom Aufrufer bereitgestellten OCSP-/CRL-Respondern und einer RFC 3161-TSA. Es betreibt oder hostet diese Responder oder die TSA nicht 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 besitzt 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.

Publikationsgrenze

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

Grenze der rechtlichen Compliance

Die Ausrichtung an den in ETSI EN 319 142 definierten Strukturen B-LT und B-LTA ist eine strukturelle Aussage, kein Rechtsgutachten und keine Zertifizierung. NextPDF erhebt keinen PAdES-Zertifizierungsanspruch. Ob eine erzeugte Signatur verifiziert wird, entscheidet der Prüfer anhand seiner Vertrauensanker und seiner Richtlinie zur Aktualität der Sperrung.

Siehe auch

• Signature (Fähigkeitsüberblick)
• Archiv-Tiefenreferenz — DSS/VRI-Wartung, LTV-Gesundheit, Archivierungsschleife.
• Sicherheit / Signieren (Core) — CMS, RFC 3161, RFC 5280, OCSP/CRL.
• Pro-Sicherheit — die B-B-Baseline und die Enterprise-Grenze.
• PAdES-Baseline-Zuordnung