Pro Edition

Sicherheit

Auf einen Blick

NextPDF Pro ergänzt eine Sicherheitsoberfläche auf NextPDF Core: Inhaltsmaskierung zur Erzeugungszeit, Textebenen-PII-Erkennung, Remote- und Cloud-KMS-Signierstrategien sowie mehrparteiisches sequenzielles Signieren. NextPDF Core erzeugt die PAdES-Stufen B-B und B-T; Pro erzeugt dieselben Stufen und ergänzt diese Signier-Workflows darüber (für B-T eine B-B-Signatur plus einen RFC 3161 signature-time-stamp auf dem Signaturwert). Diese Seite ist auf Verhaltensebene. Sie nennt, was jeder Teil tut, was er nicht tut und wo die Enterprise-Grenze beginnt.

Verfügbarkeit & Lizenzierung

Diese Funktion wird in NextPDF Pro (nextpdf/pro) ausgeliefert und aktiviert sich mit einer Lizenzhülle der Pro-Stufe. Ein Deployment ohne diese Berechtigung lädt die Klassen der Funktion nicht. Editionen vergleichen und Lizenz erwerben.

Core liefert den Software-CMS-Signierer, den RFC 3161-Zeitstempel-Client, die RFC 5280-Pfadvalidierung sowie die OCSP- und CRL-Sperrprüfung. Pro ergänzt die Maskierung, die PII-Erkennung und die Remote-/Cloud-KMS-/sequenziellen Signier-Workflows; diese Workflows erzeugen über den Core-RFC 3161-Stack dieselben Core-Stufen B-B und B-T (für B-T einen signature-time-stamp auf dem Signaturwert). Ein Deployment ohne aktive Pro-Berechtigung lädt diese Klassen nicht; der Core-Signiervertrag funktioniert weiterhin unverändert.

Installation

composer require nextpdf/pro:^3

Konzeptioneller Überblick

Die Maskierungs-Engine wendet eine geordnete Regelliste auf Text an, bevor die Seite geschrieben wird. Jede Regel matcht einen regulären Ausdruck. Eine Regel ersetzt einen Treffer auf eine von drei Weisen: eine BlackBox-Füllung, die den Text aus dem Content-Stream entfernt, einen Sternchen-Lauf gleicher Zeichenanzahl oder ein festes Label wie [REDACTED]. Die Engine entfernt die zugrunde liegenden Textobjekte für den BlackBox-Modus, wie getestet; sie sichert nicht zu, dass jede Form sensibler Inhalte gefunden wird. Die Erkennung hängt von den Regeln ab, die Sie konfigurieren.

Die PII-Oberfläche ist ein Erkennungswerkzeug, keine Redaktionsgarantie. Sie extrahiert die Textebene und wendet dann eingebaute Muster für E-Mail-Adressen, Telefonnummern, US-amerikanische Social-Security-Nummern und Kreditkartennummern an. Sie gibt eine maskierte Ansicht des Texts und eine Trefferanzahl zurück. Sie überschreibt nicht die gerenderten Glyphen im Seitenbild. Eine gescannte Seite ohne Textebene liefert keine Treffer. Behandeln Sie das Ergebnis als mustergesteuerte Erkennung der konfigurierten Typen, nicht als vollständige Entfernung personenbezogener Daten.

Die Signieroberfläche ergänzt Remote- und asynchrone Workflows auf dem Core-Signierer. Eine Sitzung berechnet den Dokument-Digest, baut die signierten CMS-Attribute und übergibt die Signierte-Attribute-Bytes an eine Signierstrategie. Eine Strategie kann ein Cloud-KMS, ein verzögerter externer Signierer oder ein Ingest-Pfad sein, der eine bestehende CAdES- oder XAdES-Signatur umhüllt. Die Sitzung baut dann die CMS-SignedData zusammen und speichert sie DER-codiert im Eintrag Contents des Signatur-Dictionarys — ISO 32000-2 §12.8.1. Das SignerInfo trägt die signierten Attribute content-type und message-digest; der Prozess der Message-Digest-Berechnung ist RFC 5652 §5.4. Ein Prüfer darf sich nicht auf vom Aussteller berechnete Digests verlassen; er berechnet den Inhalts-Digest unabhängig neu und vergleicht ihn mit dem message-digest-Attribut, und der Vergleich muss übereinstimmen, damit die Signatur gültig ist — RFC 5652 §5.6 Signaturverifikationsprozess.

NextPDF Core erzeugt die PAdES-Stufen B-B und B-T; NextPDF Pro erzeugt dieselben Stufen und ergänzt seine Signier-Workflows darüber. Für B-B baut die Sitzung eine CMS-SignedData mit dem B-B-signierten Attributsatz zusammen und wendet keinen Zeitstempel an. Für B-T fügt die Sitzung genau einen RFC 3161 signature-time-stamp als unsigniertes CMS-Attribut auf dem Signaturwert hinzu: Ein signature-time-stamp ist ein unsigniertes Attribut, das ein Zeitstempel-Token trägt, das auf dem digitalen Signaturwert für einen Unterzeichner berechnet wurde — ETSI EN 319 122-1 §5.3, und sein MessageImprint ist ein Hash des SignerInfo-Signaturfeldwerts, identifiziert durch die OID id-aa-timeStampToken — RFC 3161 Appendix A. Die Zeitstempel-genTime ist der UTC-Zeitpunkt, zu dem das Token erstellt wurde — RFC 3161 §2.4.2. Weil der Zeitstempel ein unsigniertes Attribut ist, bleiben der signierte B-B-Digest, der SignerInfo-Signaturwert und der PDF-/ByteRange unverändert; nur die CMS wächst. Das RFC 3161-Token wird von einem konfigurierten Zeitstempelanbieter bezogen (dem standardmäßigen Core-RFC 3161-Client oder einem vom Aufrufer bereitgestellten Anbieter); B-T verwendet auf dem Standardanbieterpfad einen SHA-256-Message-Imprint. NextPDF Pro implementiert PAdES-B-T-Signierunterstützung gemäß ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 und RFC 5816; dies ist fixture-verifiziert. NextPDF Pro behauptet keine unabhängige ETSI EN 319 142-1-Zertifizierung und behauptet keine rechtliche Dokumentgültigkeit. B-LT und B-LTA fügen einen Document Security Store und Dokument-Zeitstempel für die Langzeit-Archivierungsvalidierung hinzu — ETSI EN 319 142-2 §5.5; diese Stufen sind eine Enterprise-Fähigkeit (nextpdf/enterprise) und werden nicht von Pro erzeugt. Siehe Enterprise-Grenze unten.

Warum es so funktioniert

Die Signieroberfläche übergibt die Signierte-Attribute-Bytes an eine SigningStrategy, statt einen privaten Schlüssel zu halten. Diese eine Entscheidung ist tragend. Ein Cloud-KMS, ein verzögerter externer Signierer oder ein CAdES-/XAdES-Ingest-Pfad erfüllen alle denselben Vertrag, sodass der aufrufende Code identisch bleibt und das Schlüsselmaterial nie in NextPDF gelangt. Die Aufteilung der Sitzung in RemoteSigningSession::prepare() und RemoteSigningSession::complete() lässt die Signatur asynchron zurückkehren, weil der Digest feststeht, bevor der Schlüssel überhaupt erreicht wird. Der Zeitstempel wird als unsigniertes CMS-Attribut angehängt, sodass B-T additiv bleibt: Der signierte B-B-Digest, der SignerInfo-Signaturwert und der /ByteRange bleiben unberührt. Jede Naht ist fail-closed, denn ein Signierpfad, der stillschweigend herabstuft, ist schlimmer als einer, der anhält. Design-Hintergrund: Signieren im großen Maßstab, ohne Kompromiss.

API-Oberfläche

Typ	Art	Rolle	Stabilität	Seit
`RemoteSigningSession`	class	Zweiphasige Remote- oder asynchrone Signiersitzung	stable	1.9.0
`RemoteSigningConfig`	class	Immutable Sitzungskonfiguration, einschließlich PAdES-Stufe	stable	1.9.0
`SequentialSigner`	class	Mehrparteiisches sequenzielles Signieren mit DocMDP-Unterstützung	stable	1.9.0
`SigningStrategy`	interface	Der Signiermechanismus-Vertrag, den eine Sitzung aufruft	stable	1.9.0
`PadesWrapper`	class	Umhüllt eine bestehende CAdES- oder XAdES-Signatur für die PAdES-Einbettung	stable	1.9.0
`KmsSignerInterface`	interface (SPI)	Vertrag für Drittanbieter-HSM- und KMS-Treiber	stable	2.1.0
`GenerationTimeMasker`	class	Regelgesteuerte Maskierung, angewendet bevor die Seite geschrieben wird	stable	1.9.0
`MaskingConfig` / `MaskingRule` / `MaskingMode`	types	Maskierungskonfiguration, -regel und Ersetzungsmodus	stable	1.9.0

RemoteSigningConfig trägt ein PAdES-Stufenfeld, dessen Enum das Core-SignatureLevel ist. Der Pro-Signierpfad erzeugt die B-B-Baseline und die B-T-Stufe: Konfigurieren Sie RemoteSigningConfig::default()->withLevel(SignatureLevel::PAdES_B_T) (oder verwenden Sie SequentialSigner::withTimestamping()) und stellen Sie einen Zeitstempelanbieter bereit, dann fügt die Sitzung das unsignierte RFC 3161-signature-time-stamp-Attribut hinzu. Der für B-T reservierte /Contents-Platz wird automatisch angehoben, damit das Token hineinpasst; ein zu klein konfigurierter Platz scheitert fail-closed mit einem typisierten Konfigurationsfehler, statt zu truncieren. Eine in der Konfiguration getragene Stufe oberhalb von B-T (B-LT oder B-LTA) ist ein vorwärts-deklarierter Wert, nach dem Pro nicht handelt; dieser Langzeit-Erzeuger wird zur Laufzeit über den Core-Vertrag aufgelöst und im Paket nextpdf/enterprise ausgeliefert.

Codebeispiel — Schnellstart

<?php

declare(strict_types=1);

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

use NextPDF\Pro\Security\Signing\RemoteSigningSession;
use NextPDF\Pro\Security\Signing\SigningStrategy;

/**
 * Produce a signed PDF using any signing strategy.
 *
 * @param string          $pdfWithPlaceholder PDF bytes with a signature placeholder.
 * @param SigningStrategy  $strategy           A cloud-KMS, deferred, or ingest strategy.
 *
 * @return string The signed PDF bytes.
 */
function signWithStrategy(string $pdfWithPlaceholder, SigningStrategy $strategy): string
{
    $session = RemoteSigningSession::create($pdfWithPlaceholder);

    $session->prepare(
        certDer: $strategy->getCertificateDer(),
        chainDer: $strategy->getCertificateChainDer(),
        algorithmOid: $strategy->getSignatureAlgorithmOid(),
        digestAlgorithm: $strategy->getDigestAlgorithm(),
        contentsHexStart: 0,
        contentsHexEnd: 0,
    );

    return $session->complete($strategy);
}

Der Aufrufer hängt vom Vertrag SigningStrategy ab. Eine Cloud-KMS-Strategie und eine CAdES-Ingest-Strategie erfüllen ihn beide, sodass sich dieser Code zwischen den Strategien nicht ändert.

Codebeispiel — Produktion

<?php

declare(strict_types=1);

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

use NextPDF\Pro\Security\Signing\SequentialSigner;
use NextPDF\Pro\Security\Signing\SigningStrategy;
use Psr\Log\LoggerInterface;

final readonly class ApprovalWorkflow
{
    public function __construct(private LoggerInterface $logger) {}

    /**
     * Sign a PDF with two parties in sequence.
     *
     * @param string          $pdfData   The PDF bytes to sign.
     * @param SigningStrategy  $approver  The first-party strategy.
     * @param SigningStrategy  $reviewer  The second-party strategy.
     *
     * @return string The signed PDF bytes.
     */
    public function run(string $pdfData, SigningStrategy $approver, SigningStrategy $reviewer): string
    {
        try {
            $result = SequentialSigner::create($pdfData)
                ->addSigner($approver, 'Approver', reason: 'Approved')
                ->addSigner($reviewer, 'Reviewer', reason: 'Reviewed')
                ->sign();

            $this->logger->info('Sequential signing complete', [
                'signatures' => $result->signatureCount,
            ]);

            return $result->pdfData;
        } catch (\Throwable $e) {
            $this->logger->error('Sequential signing failed', ['error' => $e->getMessage()]);

            throw $e;
        }
    }
}

Jeder Unterzeichner ist eine separate inkrementelle Revision. Der Catch-Block protokolliert und wirft erneut; er verschluckt den Fehler nicht, was den Signierpfad fail-closed hält.

Sonderfälle & Fallstricke

Eine erzeugte Signatur ist keine verifizierte Signatur. Die Pfadvalidierung läuft beim Prüfer mit den Vertrauensankern dieses Prüfers — RFC 5280 §6.1. Der Erzeuger kann das Ergebnis nicht zusichern.
Die Maskierungserkennung hängt von den konfigurierten Regeln ab. Ein Regelsatz, der einen Wert nicht matcht, maskiert ihn nicht. Die Engine sichert nicht zu, dass alle sensiblen Inhalte gefunden werden.
Die PII-Erkennung erfolgt nur auf der Textebene. Eine gescannte Seite ohne Textebene liefert keine Treffer. Das Werkzeug überschreibt nicht die gerenderten Seiten-Glyphen.
Die CMS-Struktur muss in den reservierten Contents-Platz passen. Die B-B-SignedData mit einer vollständigen Zertifikatskette hat eine Größe; bemessen Sie den reservierten Platz entsprechend, andernfalls löst die Sitzung einen Overflow-Fehler aus.
Eine Cloud-KMS-Strategie hängt von der Netzwerkerreichbarkeit und der Anbieterverfügbarkeit ab. Ein Netzwerk- oder Anbieterfehler löst eine typisierte Ausnahme aus; die Sitzung erzeugt nicht stillschweigend ein unsigniertes Dokument.
OCSP unknown ist nicht good. Behandeln Sie unknown als Nicht-Entscheidung — RFC 6960 §2.2.

Performance

Eine Software-Signatur liegt im einstelligen Millisekundenbereich. Eine Cloud-KMS-Signatur fügt einen Netzwerk-Roundtrip zum Anbieter hinzu. Eine B-T-Signatur fügt zusätzlich zur Signieroperation einen Roundtrip zum konfigurierten Zeitstempelanbieter hinzu. Das Wall-Clock-Budget von 1500 ms deckt eine einzelne B-B-Signatur mit einem Remote-Anbieter auf einer warmen Verbindung ab. Die Maskierungskosten skalieren mit der Regelanzahl und der Textlänge. Das Reproduzierbarkeitsprofil ist structural: Die B-B-signierten Attribute betten den Signierzeitpunkt ein, und eine B-T-Signatur bettet zusätzlich ein Zeitstempel-Token ein, sodass sich zwei Läufe in den Signierzeit- und Zeitstempel-Bytes unterscheiden, während die signierte Struktur identisch ist.

Sicherheitshinweise

Dies ist eine kryptografische Grenze, daher ist das Bedrohungsmodell explizit. Der Byte-Bereich wird von der Engine berechnet und niemals vom Aufrufer übernommen. Der Signierpfad ist fail-closed: Ein Primitiv-Fehler oder eine Capability-Lücke löst eine typisierte Ausnahme aus und stuft niemals stillschweigend auf einen schwächeren Algorithmus herab. Eine Cloud-KMS-Strategie ist ein Integrationspunkt, kein Schlüsselspeicher. Der Schlüsselschutz hängt von der Schlüsselbehandlung, dem konfigurierten KMS und dem Deployment ab; NextPDF Pro hält den privaten Schlüssel für eine KMS-Strategie nicht. Pro arbeitet in einem FIPS-kompatiblen Modus, wenn es gegen ein FIPS-validiertes KMS oder HSM konfiguriert ist; NextPDF Pro ist selbst kein FIPS-validiertes kryptografisches Modul. Diese Seite betrifft kryptografisches Signieren; jede normative Quelle ist paraphrasiert und keine wird wiedergegeben.

Datenresidenz & PII-Minderungen

Die Maskierungs- und PII-Oberflächen laufen in-process. Für die Maskierung oder PII-Erkennung verlässt kein Dokumentinhalt den Host. Eine Cloud-KMS-Strategie sendet den Signierte-Attribute-Digest, nicht das Dokument, für die Signieroperation an den Anbieter. Die PII-Erkennung erfolgt mustergesteuert auf den konfigurierten Typen und entfernt die zugrunde liegenden Textobjekte für den BlackBox-Modus, wie getestet; sie ist keine vollständige Garantie zur Entfernung personenbezogener Daten und keine Aussage zur regulatorischen Compliance.

Sichere Telemetrie & Log-Bereinigung

Die Bibliothek löst typisierte Ausnahmen mit strukturellen Meldungen aus. Sie schreibt keinen Dokumentinhalt und keine erkannten PII-Werte in Ausnahmemeldungen oder Logs. Ein Deployment, das rund um den Signierpfad protokolliert, sollte die im Produktionsbeispiel gezeigten strukturellen Felder protokollieren, nicht die Dokument-Bytes.

Verhalten im FIPS-Modus

Pro wählt den Algorithmus aus dem konfigurierten Signaturalgorithmus und der Strategie. Wenn gegen ein FIPS-validiertes KMS oder HSM konfiguriert, läuft die kryptografische Operation in dieser validierten Grenze. NextPDF Pro selbst führt strukturelle Zusammenstellung und Digest-Berechnung durch; es ist kein FIPS-validiertes Modul und erhebt keinen FIPS-Zertifizierungsanspruch.

Enterprise-Grenze

NextPDF Pro erzeugt die B-B-Baseline und die B-T-Stufe. B-T fügt einen RFC 3161 signature-time-stamp als unsigniertes CMS-Attribut auf dem Signaturwert hinzu, berechnet auf dem digitalen Signaturwert für einen Unterzeichner — ETSI EN 319 122-1 §5.3. NextPDF Pro implementiert dies gemäß ETSI EN 319 122-1 §5.3, RFC 3161, RFC 5652 und RFC 5816; es ist fixture-verifiziert. NextPDF Pro behauptet keine unabhängige ETSI EN 319 142-1-Zertifizierung und behauptet keine rechtliche Dokumentgültigkeit.

Die Stufen B-LT und B-LTA sind Enterprise-Fähigkeiten und werden nicht von Pro erzeugt. B-LT und B-LTA fügen einen Document Security Store und Dokument-Zeitstempel für die Langzeit-Archivierungsvalidierung hinzu — ETSI EN 319 142-2 §5.5. Eine Konfiguration, die einen Document Security Store oder die Langzeit-Archivierungsschleife anfordert, löst diesen Erzeuger zur Laufzeit über den Core-Vertrag auf; dieser Erzeuger wird im Paket nextpdf/enterprise ausgeliefert. 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. Pro erzeugt keinen Document Security Store, kein VRI-Dictionary, keinen Dokument-Zeitstempel und keine Archivierungsschleife und erhebt keinen Langzeitvalidierungsanspruch (LTV). Auch die Verwahrung von Schlüsseln in Hardware über PKCS#11 sowie das FIPS 140-3-Kryptorichtlinienprofil sind Enterprise-Fähigkeiten.

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

Verhaltensvertrag

Die Maskierung wendet konfigurierte Regeln an, bevor die Seite geschrieben wird, und entfernt die zugrunde liegenden Textobjekte für den BlackBox-Modus, wie getestet.
Die PII-Erkennung extrahiert die Textebene, wendet die konfigurierten Muster an und gibt eine maskierte Ansicht und eine Trefferanzahl zurück. Sie überschreibt nicht die gerenderten Glyphen.
Das Remote-Signieren ist zweiphasig: prepare berechnet den Digest und baut die signierten Attribute; complete baut die CMS zusammen und bettet sie ein.
Pro erzeugt die B-B-Baseline und die B-T-Stufe. Für B-T fügt die Sitzung einen RFC 3161 signature-time-stamp als unsigniertes CMS-Attribut auf dem Signaturwert hinzu; der signierte B-B-Digest und der /ByteRange bleiben unverändert. Eine B-T-Anforderung ohne Zeitstempelanbieter oder mit einem zu klein konfigurierten Contents-Platz scheitert fail-closed mit einem typisierten Konfigurationsfehler. Eine Anforderung von B-LT oder B-LTA ohne das Enterprise-Paket scheitert fail-closed mit einem benannten Fehler.
Eine Cloud-KMS-Strategie erhält den Signierte-Attribute-Digest, nicht das Dokument, und gibt die rohen Signatur-Bytes zurück.

Konformität

Anspruch	Standard	Klausel
Die CMS-Signatur wird DER-codiert im Eintrag `Contents` des Signatur-Dictionarys gespeichert.	ISO 32000-2	§12.8.1
Der Prozess der Message-Digest-Berechnung; signierte Attribute tragen content-type und message-digest.	RFC 5652	§5.4
Der Prüfer darf sich nicht auf vom Aussteller berechnete Digests verlassen; er berechnet unabhängig neu und vergleicht (Signaturverifikationsprozess).	RFC 5652	§5.6
Ein PAdES-B-T-signature-time-stamp ist ein unsigniertes Attribut, das ein auf dem digitalen Signaturwert für einen Unterzeichner berechnetes Zeitstempel-Token trägt (Pro erzeugt B-T).	ETSI EN 319 122-1	§5.3
Der `MessageImprint` des signature-time-stamp-`id-aa-timeStampToken`-Tokens ist ein Hash des SignerInfo-Signaturfeldwerts.	RFC 3161	Appendix A
Auf der Prüfseite bindet NextPDF den `MessageImprint` eines signature-time-stamp an den SignerInfo-Signaturwert und scheitert fail-closed bei einer Nichtübereinstimmung, einem fehlenden/duplizierten Token oder einem SHA-1-Imprint (strikte Verifikation, keine Zertifizierung).	RFC 3161	Appendix A
Ein B-T-Zeitstempel-Token trägt eine UTC-genTime, die der Zeitpunkt ist, zu dem das Token erstellt wurde.	RFC 3161	§2.4.2
Die Zertifizierungspfadvalidierung prüft Basic Constraints und Pfadeingaben bis zu einem Vertrauensanker.	RFC 5280	§6.1
OCSP meldet certStatus als good, revoked oder unknown.	RFC 6960	§2.2
B-LT und B-LTA fügen einen Document Security Store und Dokument-Zeitstempel für die Langzeitvalidierung hinzu (Enterprise-Grenze).	ETSI EN 319 142-2	§5.5

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder. Konsultieren Sie die veröffentlichten Standards für den verbindlichen Wortlaut. NextPDF Pro implementiert PAdES-B-T-Signierunterstützung gemäß ETSI EN 319 122-1 §5.3 (signature-time-stamp), RFC 3161, RFC 5652 und RFC 5816 und ist fixture-verifiziert. ETSI EN 319 142-1 (der Teil zu den PAdES-Baseline-Stufen) liegt außerhalb der zitierten Evidenzmenge; NextPDF Pro behauptet daher keine unabhängige ETSI EN 319 142-1-Zertifizierung, -Konformität oder -Compliance und behauptet keine rechtliche Dokumentgültigkeit. Diese Seite nennt die erzeugte Struktur, die Standards, die die B-T-Unterstützung implementiert, und die Enterprise-B-LT/B-LTA-Grenze, nicht eine zertifizierte Konformitätsstufe.

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

Siehe auch

Sicherheit — Tiefenreferenz — die Tiefenreferenz für diese Pro-Sicherheitsoberfläche.
Core signing — der CMS-Signierer, RFC 3161-Zeitstempel, RFC 5280-Pfadvalidierung, OCSP und CRL.
PAdES clause map — B-B, B-T, B-LT, B-LTA über alle Editionen.
NextPDF Pro — die vollständige Pro-Funktionsoberfläche.
Core security — Verschlüsselung und die weitere Signaturoberfläche.
CMS · PAdES · RFC 3161 timestamp · KMS · DSS — Glossarbegriffe.