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

Auf einen Blick

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

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 mit den Zertifikaten, OCSP-Antworten und CRLs, 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 selbst 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 erfolgt über zwei Dictionary-Typen: einen Document Security Store und ein Dokument-Zeitstempel-Dictionary — ISO 32000-2 §12.8. Der Enterprise-Erzeuger schreibt den DSS, der 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, wie aktuell dieser Status ist — RFC 6960 §4.2. Ist OCSP nicht verfügbar, fällt er auf eine CRL zurück. Der Signierer durchläuft die Kette bis zu einem Vertrauensanker, entsprechend den Eingaben der Pfadvalidierung — RFC 5280 §6.1.

Der B-LTA-Dokument-Zeitstempel entsteht durch einen RFC 3161-Austausch mit einer Time-Stamping Authority. Die TSA-Antwort enthält eine TSTInfo — RFC 3161 §2.4.1 —, deren genTime der 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.

Ob eine erzeugte Signatur verifiziert wird, entscheiden der Prüfer sowie die Vertrauensanker und die Sperrrichtlinie, mit denen er konfiguriert ist. 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 des Erzeugers ist unten dargestellt.

Diagram

API-Oberfläche

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

Typ	Art	Rolle	Stabilität	Seit
SignerInterface	interface (NextPDF\Contracts)	Core-Signiervertrag, von dem Aufrufer abhängen	stable	1.0.0
SignatureLevel	enum (NextPDF\Security\Signature)	PAdES-Level-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 verwendet	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

examples/contracts/pades-blt-quickstart.php

<?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 Stufe wird in der Signierkonfiguration festgelegt. Der Core-Orchestrator löst den Langzeit-Erzeuger zur Laufzeit über LtvManagerInterface auf, sodass Anwendungscode keinen Enterprise-Typ referenziert.

Codebeispiel — Produktion

examples/contracts/pades-blt-production.php

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

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 (nur Warnungen) lässt sich optional aktivieren.
• 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 erfolgt kein OCSP-/CRL-Abruf und keine TSA-Anfrage; verwendet wird 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 VRI, 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 Aktualität der Sperrung 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; ihr planmäßiger Betrieb liegt in der Verantwortung des Aufrufers.
• Fail-closed-Standard. Der Standard für die strikte Sperrdurchsetzung besteht, damit kein 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 vom Aufrufer 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 nur für nicht produktive Umgebungen vorgesehenen Ausführlichkeit und bereinigen Sie Responder-URLs, wenn diese interne Infrastruktur preisgeben. Behandeln Sie alle eingebetteten OCSP-/CRL-Bytes als Dokumentinhalt, nicht als Log-Inhalt.

Verhalten im FIPS-Modus

Das 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	reference_id
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.

Editions-Gate

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. Dies entspricht der veröffentlichten Tier-Tabelle auf der Pro-Sicherheitsseite: B-B und B-T werden von Core und Pro erzeugt, B-LT und B-LTA nur von Enterprise. Der B-T-Erzeuger ist strukturell — er setzt den RFC 3161-signature-time-stamp gemäß der zitierten Evidenz aus RFC 3161 / RFC 5652 / ETSI EN 319 122-1 zusammen; damit ist kein zertifizierter ETSI EN 319 142-1-Konformitäts- oder eIDAS-qualifizierter Anspruch verbunden. 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.

Lizenz-Feature-Flag

Der Langzeit-Erzeuger ist Teil der Enterprise-Edition (license_feature_flag: enterprise). Er wird zur Laufzeit über den Core-Vertrag aufgelöst; die öffentliche API bleibt beim Upgrade von Pro auf Enterprise unverändert.

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 die 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.

NDA-Scan-Status

Diese öffentliche Seite beschreibt nur extern beobachtbares Erzeugerverhalten. Sie enthält keine internen Namespace-Pfade, keine internen Klassen- oder Trait-Namen, keine Runbook-Dateinamen und keine internen Ticket-Präfixe. Die konkreten Enterprise-Langzeit-Erzeugertypen werden nur über den öffentlichen Core-Vertrag referenziert (LtvManagerInterface, SignatureLevel). Die detaillierten Interna der DSS-Zusammenstellung und der Archivierungsschleife befinden sich in der zugangsbeschränkten Tiefenreferenz unter NDA.

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-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 und 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 ist mit export_control_class: legal-review-required markiert. Sie betrifft kryptografisches Signieren und Langzeitvalidierung. Eine rechtliche Freigabe ist erforderlich, bevor das publish-Flag gesetzt wird. 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 eigenen Compliance- und Rechtsberater zu Ihren regulatorischen Pflichten.

Siehe auch

• Sicherheit / Signieren (Core) — CMS, RFC 3161, RFC 5280-Pfadvalidierung, OCSP/CRL.
• Pro-Sicherheit — die 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.
• PAdES-Baseline-Zuordnung — B-B, B-T, B-LT, B-LTA über alle Editionen.
• PAdES · DSS · VRI · LTV — Glossarbegriffe.