Signaturprüfung: kryptografische AdES-/PAdES-Verifikation

Auf einen Blick

NextPDF Enterprise verifiziert digitale Signaturen kryptografisch. Die Verifikationsseite liest ein CMS-SignedData oder ein RFC 3161-Zeitstempel-Token aus dem PDF, berechnet die Digests neu, prüft die Signaturen, bindet jede Signatur an ihr Signaturzertifikat und validiert die Zertifikatskette — einschließlich der Zertifikatsrichtlinienverarbeitung — gegen einen vom Aufrufer bereitgestellten Trust-Anchor-Store. Diese Seite ist auf Verhaltensebene angesiedelt. Sie beschreibt, was verifiziert wird, was fail-closed abgelehnt wird, welche Algorithmen unterstützt werden und wo die Vertrauensgrenze liegt.

Abzugrenzen ist dies von Validation, das schreibgeschützte strukturelle Richtlinienprüfungen durchführt und bewusst keine Kryptografie ausführt. Außerdem ist diese Seite das verifikationsseitige Gegenstück zum Signaturerzeuger, der PAdES B-LT- / B-LTA-Strukturen schreibt.

Installation

composer require nextpdf/enterprise:^3

Konzeptioneller Überblick

Die Verifikation ist evidenzbasiert und fail-closed: Eine Prüfung, die nicht positiv nachgewiesen werden kann, liefert kein positives Ergebnis. Die folgenden Bausteine ergeben zusammen ein Ergebnis, das in einem ValidationReport abgebildet wird.

Kryptografische Verifikation von CMS- / Zeitstempel-Token. Ein eigenständiger, strikter DER-Stack parst das CMS-SignedData und das RFC 3161-Zeitstempel-Token mit definiter Länge. Ein Token wird nur akzeptiert, wenn es genau ein SignerInfo trägt, sich seine signierten Attribute strikt parsen lassen, das Signaturzertifikat aufgelöst wird, das message-digest-Attribut mit dem neu berechneten Digest übereinstimmt, die obligatorische Signing-Certificate-Bindung (ESS signing-certificate-v2) hält und die SignerInfo-Signatur über die neu getaggten signierten Attribute verifiziert. Die Digest-Abgleichsregel ist das Verifikationsmodell aus RFC 5652 §5.6 / §5.4: Der Empfänger berechnet den Inhalts-Message-Digest neu, und die Signatur ist nur dann gültig, wenn dieser Wert dem signierten Attribut messageDigest entspricht — ein Verifizierer vertraut niemals einem vom Erzeuger bereitgestellten Digest.

TSA-Zertifikatsvalidierung zum genTime. Der genTime des Zeitstempels ist der UTC-Zeitpunkt, zu dem das Token erstellt wurde (RFC 3161 §2.4.2). Das TSA-Signaturzertifikat wird zu genau diesem Zeitpunkt validiert, nicht zum aktuellen Zeitpunkt: Seine erweiterte Schlüsselverwendung muss ein einzelnes, kritisches id-kp-timeStamping sein (RFC 3161 §2.3), und sein Gültigkeitsfenster, seine Kette, seine Trust-Anchor-Verankerung und sein Sperrstatus werden sämtlich gegen genTime ausgewertet. Eine Kette, die strukturell wohlgeformt ist, aber keinen konfigurierten Trust Anchor erreicht, kann niemals zu einem positiven Ergebnis führen.

Losgelöste (detached) PAdES-Basis-Dokumentsignaturen. Ein dedizierter Extraktor führt für eine losgelöste Dokumentsignatur echte AdES- / PAdES-Basisverifikation durch: Der Message-Digest wird über den signierten Byte-Bereich neu berechnet und verglichen, die Signatur wird verifiziert, und die Signing-Certificate-Bindung ist obligatorisch. Dies ersetzt den früheren rein strukturellen Fallback. Der Zeitstempel-Verifizierer und der Dokumentsignatur-Extraktor verwenden gemeinsam einen ESS-Issuer-and-Serial-Validator, sodass sie beim Parsen der Zertifikatsbindung nicht voneinander abweichen können.

Archivierende DocTimeStamp-Abdeckungskette. validateArchivalTimestampChain() validiert eine Kette vertrauenswürdiger DocTimeStamp-Token über die PDF-Byte-Bereiche als B-LTA-Archivnachweis. Der Imprint jedes Tokens ist an die tatsächlichen ByteRange-Bytes gebunden, die es abdeckt; die Kette folgt der strikten ETSI-Reihenfolge, die TSA-Kette jedes Tokens ist trust-anchored, und die Kette muss die Datei bis zu ihrer End-of-File-Markierung abdecken. Ein vollständig bestandenes Ergebnis wird nur für eine vollständige, trust-anchored, EOF-abdeckende Kette erreicht.

Zertifikatsrichtlinienverarbeitung (RFC 5280 §6.1.4). Die Pfadvalidierung wendet die vollständige Zertifikatsrichtlinienverarbeitung an: einen knotenstrukturierten Richtlinienbaum, Policy-Mapping mit dem anyPolicy-Fallback sowie das Falten von policyConstraints / inhibitAnyPolicy, unterstützt durch einen fail-closed Policy-Extension-DER-Reader. Die Pfadverarbeitungs-Zustandsvariablen explicit_policy und inhibit_anyPolicy (RFC 5280 §6.1.2) steuern, ob ein nicht leerer Valid-Policy-Baum erforderlich ist; der Abschlussschritt schneidet den Valid-Policy-Baum mit dem User-Initial-Policy-Set (RFC 5280 §6.1.4). Sind keine Richtlinien erforderlich und wird anyPolicy akzeptiert, bleibt die Verarbeitung unbeschränkt — das ist der Standard und entspricht dem früheren Verhalten.

Unterstützte Algorithmen

Die Verifikationsseite akzeptiert die folgende Algorithmenmenge und schlägt fail-closed fehl bei allem außerhalb davon: Ein nicht unterstützter Algorithmus führt zu einer abgelehnten Verifikation, niemals zu einem stillen Durchwinken.

Familie	Unterstützt	Anmerkungen
RSA (PKCS#1 v1.5)	rsaEncryption mit SHA-2 und die sha*WithRSAEncryption-OIDs	Akzeptiert
ECDSA	Kurven P-256, P-384, P-521	Akzeptiert
RSASSA-PSS	—	Nicht unterstützt → fail-closed
EdDSA	—	Nicht unterstützt → fail-closed
SHA-3-Digests	—	Nicht unterstützt → fail-closed
SHA-1	—	Schwach: Eine Basissignatur, die unter SHA-1 verifiziert, wird zu einem Krypto-Constraints-Fehler herabgestuft; sie gilt nicht als bestanden

API-Oberfläche

Die Verifikationsseite wird über die öffentliche Engine und die Core- / Pki-Verträge genutzt. Konkrete Strategieklassen sind intern.

Typ	Art	Rolle
AdESValidationEngine	Klasse	Der Einstiegspunkt der Verifikationsseite: Signatur- und Archivkettenvalidierung.
AdESValidationEngine::validateArchivalTimestampChain()	Methode	Validiert eine vertrauenswürdige DocTimeStamp-Abdeckungskette über die PDF-Byte-Bereiche.
ValidationReport	Ergebnis	Das strukturierte Ergebnis: Gesamtstatus plus Befunde je Prüfung.
PathValidatorInterface	Interface (NextPDF\…\Pki)	Die SPI zur Zertifizierungspfad-Validierung, von der die Engine abhängt.
PathValidationOptions	Value Object	Steuerungen der Richtlinienverarbeitung: requireExplicitPolicy, inhibitAnyPolicy, inhibitPolicyMapping, maxPolicyFanout.
TrustAnchorStoreInterface	Interface	Die vom Aufrufer bereitgestellte Menge vertrauenswürdiger Anker, gegen die die Kette ausgewertet wird.

Die Archivkettenmethode hat diese Signatur:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

Sie erreicht ein vollständig bestandenes Ergebnis nur dann, wenn die DocTimeStamp-Kette vollständig verifiziert und trust-anchored ist sowie die Datei bis zu ihrer EOF-Markierung abdeckt.

CertificateChainValidator::validate() nimmt eine Initial-Policy-Menge entgegen (das RFC 5280-User-Initial-Policy-Set). Der Standard ist anyPolicy — unbeschränkt —, sodass eine gewöhnliche Kette unbeeinflusst bleibt; übergeben Sie eine explizite Menge oder setzen Sie requireExplicitPolicy, wenn ein nicht leerer Valid-Policy-Baum erforderlich sein soll.

Codebeispiel — Schnellstart

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Codebeispiel — Produktion

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Verhaltensänderungen & Upgrade-Hinweise

Die Verifikationsseite ist von struktureller / temporaler Akzeptanz zu vollständiger kryptografischer Verifikation übergegangen. Wer sich auf das ältere, nachsichtigere Verhalten verlässt, sollte diese Änderungen prüfen.

• Fail-closed bei einem erkennbaren, aber nicht verifizierbaren Zeitstempel. Ein DocTimeStamp oder Archiv-Token, das zuvor auf struktureller und temporaler Grundlage bestand, erfordert nun vollständige kryptografische Verifikation — Signatur, message-digest und die Signing-Certificate-Bindung. Ein Token, das sich nicht verifizieren lässt, liefert keinen positiven Existenznachweis mehr; es wird auf ein unbestimmtes oder fehlgeschlagenes Ergebnis abgebildet.
• SHA-1-Basissignaturen werden herabgestuft, nicht bestanden. Eine Basis-Dokumentsignatur, die verifiziert, aber SHA-1 verwendet, wird als Krypto-Constraints-Fehler statt als vollständiges Bestanden gemeldet.
• Die Zertifikatsrichtlinienverarbeitung nach RFC 5280 §6.1.4 wird erzwungen. Eine Kette, deren explicit_policy mit einem leeren Valid-Policy-Baum null erreicht, schlägt nun fehl — auch dann, wenn ein ketteninternes policyConstraints requireExplicitPolicy dies auslöst. Standardmäßige, unbeschränkte Ketten (keine erforderlichen Richtlinien, anyPolicy akzeptiert) bleiben unbeeinflusst.
• Änderung der Konstruktorsignatur (BC-Break). AdESValidationEngine::__construct() typisiert seinen Parameter $chainValidator nun als die Pki\PathValidatorInterface-SPI, mit Lazy-Voreinstellung auf Pki\CertificateChainValidator::withDefaults(). Zuvor war dies das konkrete Ltv\CertificateChainValidator. Ein Aufrufer, der den konkreten LTV-Validator injiziert hat, muss stattdessen die Pki-SPI-Implementierung injizieren. Der Pki-Validator umschließt dieselbe strukturelle Pfad-Engine und fügt Name-Constraints und Richtlinienverarbeitung hinzu; für konforme Standardeingaben ist er ein No-op.

Randfälle & Fallstricke

• Nicht unterstützter Algorithmus ≠ ergebnisoffen. RSASSA-PSS, EdDSA und SHA-3 werden fail-closed abgelehnt, nicht zurückgestellt. Wenn Ihre Signierer diese verwenden, liefert diese Verifikationsseite dafür kein positives Ergebnis.
• Vertrauen ist anker-relativ. Die Verifikation erfolgt stets relativ zum Trust-Anchor-Store, den Sie bereitstellen. Eine leere oder falsche Ankermenge liefert unabhängig von der kryptografischen Korrektheit ein Nicht-vertrauenswürdig-Ergebnis.
• genTime, nicht jetzt. Das TSA-Zertifikat wird zum genTime des Tokens beurteilt. Ein TSA-Zertifikat, das seither abgelaufen ist, kann ein Token, das während seiner Gültigkeit erstellt wurde, weiterhin tragen; ein Zertifikat, das zum genTime noch nicht gültig ist, kann das nicht.
• EOF-Abdeckung. Die Archivkette muss das Dokument bis zu seiner EOF-Markierung abdecken. Ein Zeitstempel, der nur ein Präfix der Datei abdeckt, weist keine Abdeckung des gesamten Dokuments nach.
• Nicht als gesperrt nachgewiesen ist nicht Good. Ein Valid-Urteil benötigt einen schlüssig nicht gesperrten Status. Wenn sowohl OCSP als auch CRL als Unknown oder Unavailable zurückkommen, wird selbst eine kryptografisch einwandfreie, kettengültige, trust-anchored Signatur zu Indeterminate aufgelöst — stellen Sie eingebettetes OCSP-/CRL-Good-Material für das Signaturzertifikat bereit, um Valid zu erreichen.

Performance

Die Verifikation erfolgt prozessintern über die bereitgestellten PDF-Bytes und das eingebettete Validierungsmaterial; die Kosten skalieren mit der Kettenlänge und der Anzahl der Zeitstempel. Während der Verifikation werden keine Netzwerk-Roundtrips durchgeführt — Sperr- und Vertrauensmaterial werden aus dem entnommen, was der Aufrufer bereitstellt oder was im Dokument eingebettet ist. Die Verifikation ist deterministisch: Dieselben Eingaben und dieselben Trust Anchors erzeugen denselben Report.

Sicherheitshinweise

• Fail-closed ist der Standard. Jeder Akzeptanzschritt lehnt Material ab, das er nicht positiv verifizieren kann. Dies verhindert, dass ein Dokument eine Gültigkeit ankündigt, die die Engine nie nachgewiesen hat.
• Append-after-Timestamp wird durch die EOF-Abdeckung vereitelt. Da der Imprint jedes Archivzeitstempels an die tatsächlichen ByteRange-Bytes gebunden ist und die Kette EOF erreichen muss, ist Inhalt, der nach einem Zeitstempel angehängt wird, von diesem nicht abgedeckt und erlangt nicht dessen Beweiskraft.
• Behandeln Sie die Eingabe als feindlich. PDF-Bytes, eingebettetes CMS und Zeitstempel-Token aus nicht vertrauenswürdigen Quellen werden von einem strikten DER-Reader mit definiter Länge geparst, der fehlerhafte oder Indefinite-Length-Codierungen ablehnt.

Datenresidenz & PII-Minderungsmaßnahmen

Die Verifikation erfolgt prozessintern und lokal ohne Netzwerk-I/O. Zertifikate und Signaturen enthalten Subjektidentität; wenden Sie Ihre eigenen Aufbewahrungs- und Minimierungskontrollen auf Reports und alle extrahierten Zertifikatsdaten an.

Sichere Telemetrie & Log-Bereinigung

Befunde enthalten Prüfkennungen und Status. Manche Diagnosen können Zertifikats-Subjektnamen oder Seriennummern ausgeben; bereinigen oder schwärzen Sie diese Felder, bevor Sie Logs an gemeinsam genutzte Senken weiterleiten.

Geltungsgrenzen

Weisen Sie diese in der nutzerseitigen Ausgabe aus, damit ein positives Ergebnis nicht überinterpretiert wird.

• validateArchivalTimestampChain() weist Byte-Bereichs-Abdeckung nach, nicht xref-Erreichbarkeit. Sie weist nach, dass eine vertrauenswürdige Zeitstempelkette die Byte-Bereiche des Dokuments kryptografisch bis EOF abdeckt. Sie führt keine Analyse auf xref-Ebene oder startxref-Objekterreichbarkeit durch; das liegt per Design außerhalb des Geltungsbereichs. Append-after-Timestamp-Angriffe werden durch die EOF-Abdeckungsregel zusammen mit der Trust-Verankerung vereitelt, nicht durch Objektgraph-Analyse.
• Per Design außerhalb des Geltungsbereichs. Evidence Records (RFC 4998 / RFC 6283); die Verifikation von RSASSA-PSS-, EdDSA- oder SHA-3-Zeitstempel-Token; die Integration von Trusted Lists (TSL) und qualifizierten TSAs; sowie der Online-Abruf von TSA-Sperrinformationen werden von dieser Verifikationsseite nicht bereitgestellt. Der Sperrstatus wird aus Material ausgewertet, das dem Verifizierer bereits zur Verfügung steht.

Konformität

Verhalten	Referenz	Status
Signaturwert / Zeitstempel-Token DER-codiert in /Contents gespeichert	ISO 32000-2 §12.8.1	Geparst und verifiziert
Dokument-Zeitstempel-Dictionary	ISO 32000-2 §12.8.5	Für die Archivkette gelesen
Empfänger berechnet den Inhalts-Digest neu; er muss dem messageDigest-Attribut entsprechen	RFC 5652 §5.6 / §5.4	Erzwungen
TSA-Zertifikat trägt ein einzelnes kritisches id-kp-timeStamping-EKU	RFC 3161 §2.3	Zum genTime geprüft
genTime ist der UTC-Erstellungszeitpunkt	RFC 3161 §2.4.2	Als Validierungszeitpunkt verwendet
Richtlinienverarbeitungs-Zustandsvariablen (explicit_policy, inhibit_anyPolicy)	RFC 5280 §6.1.2	Verarbeitet
Abschlussschritt schneidet den Valid-Policy-Baum mit dem User-Initial-Policy-Set	RFC 5280 §6.1.4	Erzwungen
DSS-Einträge und Dokument-Zeitstempel für Langzeitsignaturen	ETSI EN 319 142-2 §5.5	Als Archivnachweis validiert

Alle Klauseln sind paraphrasiert. NextPDF gibt keinen normativen Text wieder; ziehen Sie für den maßgeblichen Wortlaut die veröffentlichten Standards heran. NextPDF erhebt keinen AdES- / PAdES-Zertifizierungsanspruch. Die Verifikationsseite implementiert die kryptografischen Prüfungen, die in den zitierten Spezifikationen beschrieben werden; sie ist kein zertifizierter Validierungsdienst und erstellt keine Attestierung durch Dritte.

FIPS-Modus-Verhalten

Wenn das Enterprise-FIPS-Profil aktiv ist, gilt die Beschränkung für die Digest- und Signaturalgorithmen, die der Verifizierer akzeptiert. Die Verifikationslogik — Digest-Neuberechnung, Signaturprüfungen, Zertifikatsbindung und Pfadvalidierung — bleibt unverändert.

Bedrohungsmodell

Asset	Angreifer	Risiko	Minderungsmaßnahme
Zeitstempel-Token	Gefälschtes oder verändertes Token	Falscher Existenznachweis	Vollständige kryptografische Verifikation; fail-closed bei allem Nicht-verifizierbaren
TSA-Zertifikat	Nicht vertrauenswürdiger Aussteller	Scheinbares Vertrauen, das der Verifizierer nicht behaupten sollte	Kette zu einem vom Aufrufer bereitgestellten Anker zum genTime validiert; eine nicht vertrauenswürdige Kette besteht nie
Dokument-Bytes	Append-after-Timestamp	Inhalt erlangt das Gewicht eines Zeitstempels ohne Abdeckung	Imprint an tatsächliche ByteRange-Bytes gebunden + EOF-Abdeckungsregel
Schwacher Algorithmus	Downgrade auf SHA-1 / nicht unterstütztes Verfahren	Eine schwache Signatur wird als gültig gelesen	SHA-1 herabgestuft; RSASSA-PSS / EdDSA / SHA-3 fail-closed

Editionsgate

Diese Verifikationsseite ist eine Enterprise-Fähigkeit und im Paket nextpdf/enterprise enthalten. NextPDF Core erkennt das Vorhandensein einer Signatur und erzeugt B-B- / B-T-Signaturen; es stellt diese kryptografische Verifikationsseite nicht bereit. Lizenz erwerben.

Lizenz-Feature-Flag

Die Verifikationsseite ist durch die Enterprise-Edition gegated (license_feature_flag: enterprise). Sie wird über die Core- und Pki-Verträge aufgelöst; die öffentliche API ändert sich bei einem Editions-Upgrade nicht.

Verhaltensvertrag

• Ein CMS- oder Zeitstempel-Token wird nur mit genau einem SignerInfo, strikt geparsten signierten Attributen, einem aufgelösten Signaturzertifikat, einem übereinstimmenden message-digest, der obligatorischen Signing-Certificate-Bindung und einer verifizierenden SignerInfo-Signatur akzeptiert.
• Das TSA-Zertifikat wird zum genTime des Tokens validiert: ein einzelnes kritisches id-kp-timeStamping-EKU, Gültigkeitsfenster, trust-anchored Kette und Sperrstatus.
• Ein Valid-Urteil erfordert zusätzlich einen schlüssig nicht gesperrten Status — mindestens ein maßgebliches Good (eine als gut verifizierte OCSP-Antwort oder eine frische CRL, in der die Seriennummer nicht auf einer nicht abgelaufenen Liste steht). Ein Status, der lediglich nicht-als-gesperrt-nachgewiesen ist, bei dem OCSP und CRL beide Unknown oder Unavailable sind, wird zu Indeterminate aufgelöst, niemals zu Valid (ETSI EN 319 102-1: Sperrstatus nicht verfügbar → INDETERMINATE). Da der CRL-Fallback-Pfad nur die Frische der Liste und nicht den Sperrstatus je Seriennummer attestiert, ist eine reine CRL-Kette ohne ein Good-OCSP üblicherweise Indeterminate.
• validateArchivalTimestampChain() erreicht ein vollständig bestandenes Ergebnis nur für eine vollständige, trust-anchored, EOF-abdeckende DocTimeStamp-Kette; sie weist Byte-Bereichs-Abdeckung nach, nicht xref-Erreichbarkeit.
• Die Zertifikatsrichtlinienverarbeitung folgt RFC 5280 §6.1.4; standardmäßige unbeschränkte Ketten bleiben unbeeinflusst.
• Unterstützte Algorithmen sind RSA (PKCS#1 v1.5 mit SHA-2) und ECDSA (P-256/384/521); RSASSA-PSS, EdDSA und SHA-3 schlagen fail-closed fehl; SHA-1 wird herabgestuft.

NDA-Scan-Status

Diese öffentliche Seite beschreibt ausschließlich von außen beobachtbares Verhalten der Verifikationsseite. Sie benennt die öffentliche Engine, die Pki- / Trust-Anchor-Verträge und die Methode validateArchivalTimestampChain() über die unterstützte Oberfläche. Die konkreten DER-, CMS-, Policy-Processor- und Path-Validator-Interna befinden sich in der gegateten Deep-Referenz unter NDA.

Core-Fallback

NextPDF Core erkennt das Vorhandensein einer Signatur und erzeugt B-B- / B-T-Signaturen, verifiziert aber weder CMS- noch Zeitstempel-Token kryptografisch, validiert keine Archivkette und führt auch nicht die Richtlinienverarbeitung nach RFC 5280 §6.1.4 aus. Eine reine Core-Bereitstellung hat keine äquivalente Verifikationsseite; siehe Security / Signing (Core).

Pro-Fallback

NextPDF Pro fügt Signierstrategien und E-Invoice-Handling hinzu, stellt diese kryptografische Verifikationsseite jedoch nicht bereit; Archivkettenvalidierung und Zertifikatsrichtlinienverarbeitung sind ausschließlich in nextpdf/enterprise enthalten.

Enterprise-Grenzhinweis

Die Verifikationsseite wird auf Verhaltensebene beschrieben. Der strikte DER-Stack, der CMS-Parser, der Policy-Processor und die Path-Validator-Interna liegen außerhalb des Geltungsbereichs der öffentlichen Oberfläche und werden hier nicht wiedergegeben.

Bereitstellungsgrenze

Die Verifikation hängt vom Trust-Anchor-Store und dem gesamten Sperrmaterial ab, das der Aufrufer bereitstellt oder das im Dokument eingebettet ist. NextPDF Enterprise wertet dieses Material aus; es betreibt weder eine Trust List, eine TSA noch einen Sperrdienst. Der Betreiber ist für die Ankerauswahl und die Frische des eingebetteten Sperrmaterials verantwortlich.

Rechts- und Compliance-Grenze

Diese Seite ist mit export_control_class: legal-review-required markiert; sie betrifft kryptografische Verifikation. Eine rechtliche Freigabe ist erforderlich, bevor das publish-Flag gesetzt wird. Ein positives Verifikationsergebnis ist eine kryptografische Aussage über die Signaturen und Zeitstempel des Dokuments — es ist keine rechtliche Stellungnahme, keine eIDAS-Qualifikationsfeststellung und keine Zertifizierung. NextPDF erhebt keinen AdES- / PAdES-Zertifizierungsanspruch. Ziehen Sie für Ihre regulatorischen Verpflichtungen Ihre eigenen Compliance- und Rechtsberater heran.

Siehe auch

• Signatur: PAdES B-LT- / B-LTA-Erzeuger — die Erzeugerseite.
• Validation — prozessinterne, strukturelle Richtlinienprüfungen (keine Kryptografie).
• Archive: DSS, VRI, LTV-Health — Langzeitarchivierung und LTV-Health.
• Security / Signing (Core) — CMS, RFC 3161, RFC 5280-Pfadvalidierung, OCSP/CRL.
• PAdES-Baseline-Mapping — B-B, B-T, B-LT, B-LTA über die Editionen hinweg.
• PAdES · DSS · LTV — Glossarbegriffe.