Zusammenfassung

  • Der LAMPS-Entwurf bindet ein Zertifikat mit signedDocumentBinding an eine konkrete Signatureingabe. Zugleich kann die gewöhnliche kryptografische Prüfung erfolgreich sein, ohne diese Bindung zu kontrollieren. „Signatur gültig“ und „dataTbsHash stimmt überein“ sind zwei getrennte Belege.
  • Das Zertifikat behauptet ferner, der private Schlüssel sei ausschließlich für dieses Dokument erzeugt, einmal benutzt und sofort vernichtet worden. Das ist eine Verfahrensaussage der Zertifizierungsstelle, keine Beobachtung der Erweiterung. Ohne Ablauf und Widerruf sinkt ein laufender Aufwand, während sich Langzeitvertrauen auf CA-Richtlinien, erhaltene Nachweise und spätere Vertrauensbereitstellung verlagert.

notAfter zeigt auf die letzte Sekunde des Jahres 9999. noRevAvail meldet, dass keine Widerrufsinformation verfügbar ist. signedDocumentBinding trägt einen Hash für ein Dokument. Die normale Signaturprüfung fällt positiv aus.

Welche dieser Tatsachen beweist, dass die Anwendung die Dokumentbindung geprüft hat? Keine.

Revision 02 von One Signature Certificates macht die Trennung ausdrücklich. Sie definiert ein Zertifikat, das beim Signieren für einen frisch erzeugten Schlüssel erstellt wird. Dieser Schlüssel dient einer einzigen digitalen Signatur und wird danach sofort vernichtet. Das Zertifikat ist an den signierten Inhalt gebunden, soll praktisch nicht ablaufen und besitzt keinen Widerrufsdienst. So sollen persistente Endschlüssel und langfristiger Widerrufszustand reduziert werden.

Das Dokument ist ein aktiver LAMPS-Working-Group-Entwurf im IETF Stream mit dem Ziel Proposed Standard. Revision 02 stammt vom 1. Juli 2026 und läuft am 2. Januar 2027 ab. Datatracker führt sie als WG-Dokument mit IESG-Status I-D Exists. Sie ist kein RFC und kein Nachweis, dass eine CA solche Zertifikate ausstellt, Schlüssel tatsächlich löscht, Software die Bindung prüft oder archivierte Signaturen dauerhaft gültig bleiben.

Ein Zertifikat enthält verschiedene Arten von Aussagen

Die Erweiterung heißt signedDocumentBinding. Ihr ASN.1-Wert enthält dataTbsHash, hashAlg und optional bindingType. Der Hash bezeichnet die zu signierenden Daten; der Bindungstyp erklärt, wie die Bytefolge aus dem umgebenden Dokumentformat gewonnen wird.

Ein Prüfer kann diese Eingabe rekonstruieren, hashen und vergleichen. Er kann aus dataTbsHash aber nicht ablesen, ob der entfernte Dienst den Schlüssel wirklich neu erzeugte, eine zweite Nutzung verhinderte, sämtliche Kopien löschte oder seine Richtlinie einhielt. Durch die Erweiterung authentifiziert die CA eine Behauptung über diesen Prozess. Revision 02 verweist Details des Ablaufs und der Vernichtungszusicherung in die Certificate Policy.

Ein langlebiger Prüfbeleg sollte Erweiterungswert, exakte Bindungseingabe, Digest-Ergebnis, CP/CPS-Version, Ausstellungsvorgang, Schlüsselerzeugung, einmalige Signaturfreigabe und Vernichtungsnachweis getrennt erhalten. Die Kurzform „gültiges Einmalzertifikat“ beseitigt genau die Unterscheidung, die eine spätere Untersuchung braucht.

Eine gültige Signatur kann eine ungeprüfte Bindung verdecken

Die Security Considerations sagen, dass signedDocumentBinding für die erfolgreiche kryptografische Signaturvalidierung nicht geprüft werden muss. Eine Bibliothek kann Format und öffentlichen Schlüssel korrekt verarbeiten; die Anwendung kann daraus eine Freigabe machen, ohne den Zusatzvergleich aufzurufen. Der relying party sollte den signierten Inhalt mit dataTbsHash vergleichen. Erst diese Prüfung erzwingt den beabsichtigten Zertifikatsumfang und begrenzt Austausch oder unbeabsichtigte Wiederverwendung.

Die Entscheidungsschnittstelle braucht deshalb mindestens zwei Zustände. signature_valid beschreibt Primitive und Signaturformat. document_binding_match beschreibt Bindungstyp, rekonstruierte Bytes, Hashverfahren, Sollwert und Vergleich. Wurde der zweite Test nicht ausgeführt, lautet sein Zustand not_checked, nicht passed und nicht stillschweigend erfolgreich aufgrund des ersten Ergebnisses.

Ob ein lokales Profil aus dem SHOULD eine Pflicht macht, ist eine Betriebsentscheidung. Wer sich auf die Beschränkung auf ein Dokument verlässt, muss ihre Durchsetzung in Archiv-Revalidierung, Stapelprüfung, mobilen Clients und externen Validierungsdiensten nachweisen.

Der Bindungstyp bestimmt, welche Bytes das Dokument bilden

Ohne bindingType greift die Standardbindung auf die genaue Signaturalgorithmus-Eingabe zu, etwa XML SignedInfo oder DER-kodierte CMS SignedAttributes. Enthält diese Eingabe das Zertifikat selbst oder einen Zertifikatshash, entsteht ein Kreis: dataTbsHash liegt im Zertifikat, während das Zertifikat in den Hash eingeht. Revision 02 verbietet hier die Standardbindung und definiert formatspezifische Ausnahmen.

Bei CAdES wird DER SignerInfo nach Entfernen von SigningCertificate und SigningCertificateV2 verwendet. Bei XAdES wird canonicalized SignedInfo nach Entfernen von Verweisen des Typs SignedProperties verwendet, wobei alle übrigen Zeichen, Leerzeichen und Zeilenumbrüche erhalten bleiben. JWS und COSE binden nur den Payload; protected und unprotected headers sind ausgeschlossen.

Derselbe sichtbare Inhalt kann somit je nach Bindungstyp andere dataTbsHash-Werte erzeugen. Ein passender JWS-Payload beweist zudem nicht, dass protected header, Key-ID, Algorithmus oder Zertifikatsreferenz identisch waren. Diese Felder bleiben Gegenstand der regulären JWS-Prüfung und Anwendungspolitik. Der Beleg sollte Format, Kennung, Kanonisierungs- oder Ausschlussregel, Implementierungsversion und Hash der rekonstruierten Bytes enthalten.

Kein Widerruf verfügbar heißt nicht: Schlüsselvernichtung bewiesen

Der Entwurf empfiehlt 99991231235959Z als notAfter und die Erweiterung id-ce-noRevAvail aus RFC 9608. Der erste Wert signalisiert, dass kein sinnvoller Zertifikatsablauf definiert ist. Der zweite sagt, dass für dieses Zertifikat keine Widerrufsinformation verfügbar ist. Keiner erklärt, warum Widerruf unnötig sein soll.

Die Begründung hängt am Betriebsmodell. Existierte der Schlüssel nur kurz, signierte genau einmal und wurde tatsächlich vernichtet, sollten spätere Widerrufsereignisse die bereits erzeugte Signatur nicht verändern. Das Risiko verschwindet jedoch nicht; es wandert in die Richtigkeit des Erstellungsnachweises. War der Schlüssel frisch? Gab es nur eine autorisierte Anfrage? Blieb eine Kopie in Backup, Log, Crash Dump, HSM-Replikation oder Retry-Pfad? War die Vernichtung vor einer Kompromittierung abgeschlossen?

noRevAvail beantwortet nichts davon. Es sagt dem Prüfer nur, keine CRL oder OCSP-Antwort zu erwarten. „Kein Widerruf per Design“, „Widerrufsdienst nicht erreichbar“ und „Profil unbekannt“ müssen unterschiedliche Zustände bleiben.

Der Ausstellungszeitpunkt erweitert die Zeitautorität der CA

Langzeitvalidierung braucht häufig eine best-signature-time, also den frühesten vertrauenswürdigen Beleg für die Existenz der Signatur. RFC 3161 beschreibt dafür eine unabhängige Time-Stamp Authority. Revision 02 argumentiert, das One-Signature-Zertifikat entstehe beim Signieren; seine Ausstellung begründe deshalb den Signaturzeitpunkt, und die CA übernehme eine zeitstempelähnliche Rolle.

Die Kopplung ist effizient, vergrößert aber die Beweisfläche der CA. Sie bestätigt nicht mehr nur Identität und öffentlichen Schlüssel, sondern auch den Zeitpunkt des einmaligen Vorgangs, dessen Inhaltsumfang, die frische Schlüsselerzeugung und die sofortige Vernichtung. Ein Betreiber sollte festhalten, ob die best-signature-time aus Ausstellung, RFC-3161-Zeitstempel, Validation Token, Archivbeleg oder mehreren Quellen stammt. Ein syntaktisch korrektes notBefore ist nicht automatisch eine unabhängige Zeitquelle.

Das Jahr 9999 macht die CA nicht unsterblich

Der Entwurf begrenzt das Versprechen des nicht ablaufenden Endzertifikats. Validierung bleibt an das Vertrauen in die ausstellende CA gebunden. Die erste Prüfung wird innerhalb der Gültigkeit des CA-Zertifikats angenommen. Spätere Prüfungen können erfordern, den CA-Schlüssel als lokalen trust anchor zu behalten, cross-certification zu verwenden, erneuerte CA-Zertifikate abzurufen oder anderes Trust Provisioning einzusetzen. Diese Langzeitbereitstellung liegt außerhalb des Entwurfs.

Der entfernte Ablauf des Endzertifikats bewahrt also nicht den gesamten Pfad bis 9999. Algorithmen altern, Trust Stores ändern sich, Richtlinien werden ersetzt, CAs schließen oder rotieren, Archive migrieren und Software verschwindet. Originalbytes, Zertifikatspfad, Richtlinien, Zeitbelege, Validierungsevidenz und Trust-Anchor-Historie müssen abrufbar bleiben.

Auch eine vollständige Bindungsprüfung beweist nur eine enge Beziehung: Dieses Zertifikat wurde für diese rekonstruierte Eingabe unter diesem Hash und dieser Regel ausgestellt. Sie beweist weder Verständnis noch Vertretungsmacht, korrekte Anzeige oder den versprochenen externen Effekt. Zertifikatssyntax, Pfadvertrauen, Signaturmathematik, Dokumentbindung, CA-Verfahren, Schlüssellebenszyklus, Zeit, Identität, Befugnis, Anwendungsentscheidung und reales Ergebnis bleiben getrennte Beweisarten.