Eine Signatur korrekt validieren

Spec Spec: RFC 5280, §6 RFC 5280 §6 Spec Spec: RFC 6960 RFC 6960 Spec Spec: RFC 5652 RFC 5652 Evidence ✓ Test-backed Evidence: Test-backed

Auf einen Blick

„Die Signatur ist gültig“ bedeutet meist nur, dass eine einzige Sache geprüft wurde: Die kryptografische Rechnung ist aufgegangen. Eine korrekte Validierung prüft mindestens fünf voneinander unabhängige Aspekte, und schon einer davon kann so fehlschlagen, dass ein grünes Häkchen bedeutungslos wird. Diese Seite stellt die vollständige Prüfreihe vor und erklärt, warum eine Teilantwort gefährlich ist.

Warum das wichtig ist

Ein einzelner boolescher Wert ist die gefährlichste Ausgabe in diesem gesamten Themenfeld. Er verleitet einen Leser dazu, „gültig“ als „vertrauenswürdig“ zu deuten, obwohl „gültig“ unter Umständen nur bedeutet, dass die Bytes unverändert geblieben sind — signiert mit einem Schlüssel aus einem Zertifikat, das vor drei Jahren abgelaufen ist, letzten Monat gesperrt wurde und sich auf keine Ihnen bekannte Instanz zurückführen lässt. Jede dieser Tatsachen ist eine eigene Prüfung. Software, die nur einen booleschen Wert meldet, hat stillschweigend entschieden, welche Prüfungen maßgeblich sind — und sie hat diese Entscheidung für Sie getroffen. In einem regulierten oder vertraglichen Umfeld ist „das Werkzeug sagte gültig“ keine Verteidigung, wenn das Werkzeug nur die am einfachsten zu prüfende Eigenschaft verifiziert hat.

Die Kurzfassung

Eine vollständige Validierung beantwortet fünf separate Fragen. Sie sind voneinander unabhängig — das Bestehen einer Prüfung sagt nichts über die übrigen aus:

1. Integrität — ergibt der neu berechnete Hash der signierten Bytes noch den Wert, den die Signatur abdeckt? (Den Digest über den Byte-Bereich neu berechnen; vergleichen.)
2. Authentizität — lässt sich die kryptografische Signatur mit dem öffentlichen Schlüssel im Signaturzertifikat verifizieren, und zwar über die signierten Attribute?
3. Zertifikatspfad — führt dieses Zertifikat über eine Kette zu einem Vertrauensanker, den Sie gewählt haben, wobei jedes einzelne Glied gültig ist?
4. Zeit — lag das Zertifikat zum maßgeblichen Zeitpunkt innerhalb seines Gültigkeitszeitraums, und ist dieser Zeitpunkt vertrauenswürdig statt nur selbst behauptet?
5. Sperrung — war das Zertifikat zu diesem Zeitpunkt nicht gesperrt, belegt durch Nachweise (OCSP/CRL), die Sie tatsächlich beschaffen können oder die eingebettet sind?

Ein „gültig“, bei dem nicht alle fünf Prüfungen durchgeführt wurden, ist eine unvollständige Antwort, die wie eine vollständige Antwort aussieht.

Wie NextPDF daran herangeht

Der Ansatz von NextPDF ist, jede Frage eigenständig zu behandeln und ausdrücklich zu beantworten. Keine Frage wird in ein einziges optimistisches Flag verdichtet und keine stillschweigend übersprungen, nur weil eine Prüfung unbequem war. Das erzwingt die Test-Suite. Deshalb ist diese Seite als testgestützt statt als standardgestützt gekennzeichnet: Das Verhalten wird durch die Test-Suite abgesichert, nicht nur aus einer Klausel hergeleitet.

Integrität und Authentizität werden durchgängig getestet. Ein bekanntes Zertifikat signiert eine echte Struktur signierter Attribute, und die Test-Suite verifiziert die Signatur mit dem passenden öffentlichen Schlüssel über mehrere Zeitvektoren hinweg. Eine Änderung, die die kanonische Struktur zerstört, lässt den Test daher scheitern. Die Validierung des Zertifikatspfads wird durch Tests abgesichert, die absichtlich ein Byte der Signatur manipulieren und feststellen, dass das Ergebnis mit einer strukturierten Begründung nicht gültig ist — keine weggeworfene Ausnahme, sondern ein ausdrücklich erfasster Fehlschlag. Die Verifikation des Zeitstempel-Tokens ist in einzelne Schritte zerlegt — Decodierung, Signer-Info, signierte Attribute, Message-Digest, Zertifikatsbindung, Schlüsselverwendung, Signatur, Produced-At — und jeder Schritt wird für sich getestet, sodass „der Zeitstempel wurde verifiziert“ bedeutet, dass jeder Schritt verifiziert wurde. Ein Soft-Fehlschlag bei der Sperrprüfung (ein nicht erreichbarer Responder) wird in Code und Tests von einem definitiven „gesperrt“ unterschieden. Beides wird nie zu derselben Antwort vermengt.

1. Integrity Recompute the byte-range digest and compare it to the value the signature covers.
2. Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
3. Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
4. Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
5. Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

Die fünf unabhängigen Fragen, die eine korrekte PDF-Signaturvalidierung beantwortet, in dieser Reihenfolge. Jede steht für sich: Das Bestehen einer Prüfung sagt nichts über die anderen aus, und das Auslassen auch nur einer macht das Gesamtergebnis unvollständig.

Was die Belege sagen

Evidence ✓ Test-backed Evidence: Test-backed Das Verhalten ist durch Tests abgesichert, und diese Tests setzen um, was die Standards verlangen.

Für die Integrität gilt Spec Spec: ISO 32000-2, §12.8.1 ISO 32000-2 §12.8.1 : Der Digest wird über den Byte-Bereich neu berechnet und mit dem gespeicherten Wert verglichen, und jeder Unterschied bedeutet, dass die Signatur ungültig ist. Authentizität über die signierten Attribute wird durch einen Integrationstest abgedeckt, der einen echten Satz signierter Attribute signiert und ihn mit dem passenden öffentlichen Schlüssel über mehrere Zeitvektoren hinweg verifiziert. Die Frage des Zertifikatspfads ist Spec Spec: RFC 5280, §6.1 RFC 5280 §6.1 : Gültige Pfade beginnen bei einem Vertrauensanker, und Spec Spec: RFC 5280, §6.2 RFC 5280 §6.2 legt fest, dass dieser Algorithmus die Mindestbedingungen dafür definiert, dass ein Pfad gültig ist — ein Unit-Test für den Pfadvalidierer stellt fest, dass eine manipulierte Signatur valid = false mit einer ausdrücklichen Begründung ergibt, niemals ein stillschweigendes Akzeptieren.

Die Reihenfolge der Sperrprüfung ergibt sich aus Spec Spec: RFC 6960, §3.2 RFC 6960 §3.2 : Bevor ein Client eine signierte Sperrantwort als gültig akzeptiert, MUSS er bestätigen, dass die Signatur der Antwort selbst gültig ist und dass der Unterzeichner aktuell autorisiert ist — und Spec Spec: RFC 6960, §4.2.2.2 RFC 6960 §4.2.2.2 definiert diese Autorisierung als eine id-kp-OCSPSigning-Delegation, die direkt von der betreffenden CA ausgestellt wurde. Eine Sperrantwort, die nicht selbst gegen einen autorisierten, verifizierbaren Unterzeichner validiert wurde, ist also ohne Aussagewert. Die Prüfung der Zertifikatsbindung ist Spec Spec: RFC 5035, §5.4.2 RFC 5035 §5.4.2 : Wenn der Zertifikats-Hash im signierten Attribut signing-certificate-v2 nicht mit dem Zertifikat übereinstimmt, das zur Verifikation der Signatur verwendet wurde, muss die Signatur als ungültig gelten. Das schließt die Substitutionslücke, bei der eine Signatur gegen ein vom Angreifer gewähltes Zertifikat verifiziert wird. Das Zeitstempel-Token selbst wird Spec Spec: RFC 5652 RFC 5652 -konform als CMS-Objekt verifiziert, Schritt für Schritt, wobei jeder Schritt für sich getestet wird.

Human-factors note: Human-factors note

Die Kernbotschaft — „gültig“ allein ist unvollständig; eine korrekte Antwort besteht aus fünf separaten Antworten — steht vor der Prüfliste, weil der häufigste und teuerste Fehler darin besteht, aufgrund eines einzigen booleschen Werts zu handeln. Ein Leser, der nur diesen einen Satz mitnimmt, ist bereits vor der Falle gewarnt; deshalb steht die Botschaft vor dem Mechanismus und nicht danach.

Praktisches Beispiel

Der entscheidende Teil ist kein API-Aufruf. Es sind die Fragen, die Sie beantworten können müssen, bevor Sie anhand eines Ergebnisses handeln. Behandeln Sie dies als die Checkliste, an der ein Review Sie messen wird.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Wenn auch nur eine Zeile „Ich weiß es nicht“ lautet, ist der ehrliche Status nicht „gültig“. Er lautet „noch nicht ermittelt“ — und beides gleichzusetzen ist genau der Fehler, den diese Seite verhindern soll.

Häufiges Missverständnis

Die Falle besteht darin, „kryptografisch gültig“ mit „vertrauenswürdig“ gleichzusetzen. Integrität und Authentizität zusammen beweisen nur, dass diese Bytes vom Inhaber dieses Schlüssels signiert wurden. Sie sagen nichts darüber aus, ob das Zertifikat zu diesem Schlüssel vertrauenswürdig, zeitlich gültig oder nicht gesperrt war. Ein mit einem selbst erzeugten Zertifikat signiertes Dokument kann „kryptografisch gültig“ sein und trotzdem keinen Vertrauenswert haben. Die umgekehrte Falle besteht darin, eine unbestimmte Sperrprüfung (Responder offline) als bestanden — oder als durchgefallen — zu behandeln. Sie ist weder das eine noch das andere. Das Ergebnis ist unbekannt, und ein korrekter Validierer meldet es als unbekannt, statt in die eine oder andere Richtung zu raten. Ein grünes Häkchen, das verbirgt, welche der fünf Prüfungen tatsächlich ausgeführt wurden, ist kein Validierungsergebnis. Es ist eine Entscheidung, die jemand anderes in Ihrem Namen getroffen hat.

Grenzen und Abgrenzungen

NextPDF führt die strukturellen und kryptografischen Prüfungen durch und testet sie. Es wählt Ihre Vertrauensanker nicht aus und garantiert nicht die darauf aufbauende Richtlinie. Welchen Zertifikaten Sie vertrauen, ist eine Deployment-Entscheidung, die die Engine nicht treffen kann. Eine Kette, die erfolgreich bis zu einem Anker validiert wird, dem Sie nicht hätten vertrauen sollen, ist immer noch eine Validierung, auf die Sie sich nicht verlassen können. Sperrbelege können nur geprüft werden, wenn sie beschaffbar oder eingebettet sind. Ein Offline-Responder ergibt „unbestimmt“, und dies in ein Urteil zu überführen ist eine Richtlinienentscheidung, keine Entscheidung der Engine. Diese Seite beschreibt die Prüfreihe, nicht die rechtliche Ausreichendheit. Ob eine validierte Signatur eine bestimmte Rechtswirkung hat, hängt vom Zertifikat, vom Unterzeichner, von der Rechtsordnung und von der Verpflichtung ab. Wie eingebettete Belege diese Prüfungen über die Zeit hinweg beantwortbar halten, behandelt Langzeitvalidierung; der Byte-Bereich-Mechanismus hinter der Integritätsprüfung steht in Wie Signaturen in einem PDF liegen.

Tier-Verfügbarkeit des Validierungsumfangs:

Signature validation checks — edition availability

Edition	Availability
Core	○ Integrität und Authentizität über signierte Attribute, plus RFC 5280 §6 Zertifikatspfad-Validierung gegen einen bereitgestellten Vertrauensanker.
Pro	○ Ergänzt RFC 3161-Zeitstempel-Token-Verifikation — die Frage der vertrauenswürdigen Zeit, zerlegt in unabhängig geprüfte Schritte.
Enterprise	○ Ergänzt die Sperrbewertung (OCSP/CRL) und die Validierung gegen eingebettetes Langzeitmaterial, wobei unbestimmte Ergebnisse von definitiven unterschieden werden.

Verwandte Dokumente

• Langzeitvalidierung — wie eingebettete Belege die Zeit- und Sperrprüfungen auch Jahre später beantwortbar halten.
• Wie Signaturen in einem PDF liegen — der Byte-Bereich-Mechanismus, den die Integritätsprüfung neu berechnet.
• Zeitstempel und vertrauenswürdige Zeit — wodurch sich die Frage der „Zeit“ ohne die Uhr des Unterzeichners beantworten lässt.

Glossar

• Integritätsprüfung — die Neuberechnung des Digests über den Byte-Bereich sowie der Vergleich mit dem Wert, den die Signatur abdeckt.
• Authentizitätsprüfung — die Verifikation der kryptografischen Signatur mit dem öffentlichen Schlüssel des Signaturzertifikats, über die signierten Attribute.
• Signierte Attribute — die authentisierten CMS-Attribute (content-type, message-digest, signing-time, signing-certificate-v2), über die die Signatur tatsächlich berechnet wird.
• Zertifikatspfad-Validierung — das Aufbauen und Prüfen der Kette vom Signaturzertifikat bis zu einem gewählten Vertrauensanker (RFC 5280 §6).
• Vertrauensanker — eine Zertifizierungsstelle, der Sie bewusst vertrauen; die Wurzel eines akzeptablen Pfads.
• Sperrprüfung — die Feststellung, ob ein Zertifikat zum maßgeblichen Zeitpunkt gesperrt war, per OCSP oder einer CRL.
• Unbestimmt — ein Sperrergebnis, das weder „gut“ noch „gesperrt“ ist, weil die Belege nicht beschafft werden konnten; also weder bestanden noch durchgefallen.