Zusammenfassung

  • RFC 9955 wurde im Juli 2026 als Informational RFC im IETF Stream veröffentlicht. Das Dokument ordnet hybride digitale Signaturen nach mehreren Eigenschaften. Rückwärtskompatibilität, hybride Unfälschbarkeit, starke Nichttrennbarkeit, gleichzeitige Verifikation, Beweiskomposition, Leistung und geringer Zulassungsaufwand können einander widersprechen.
  • Ein modernes System kann bei derselben Signatur alle Komponenten prüfen, während ein Altsystem nur die traditionelle Komponente akzeptiert. Beide melden womöglich „gültig“, aber nur eines hat die beabsichtigte hybride Zusicherung ausgeübt.
  • Ein geheimnisfreier Hybridprüfungsnachweis sollte Objekt, Konstruktion, Ergebnisse je Komponente, Ort der Hybridartefakte, Schlüsselherkunft und -zweck, Prüfer-Build, Richtlinie, Zulassungsgrenze, Empfängerkohorte und Ablauf jeder Alt-Ausnahme verbinden. Das ist eine hier vorgeschlagene Betriebspraxis, keine Vorgabe von RFC 9955, IETF oder NIST.

Die fehlende Zeile im Architekturentscheid

Architekturvorlagen sind gut darin, Dinge aufzulisten: Algorithmen, Schlüssellängen, Zertifikate, Bibliotheken und Zulassungen. Bei hybriden Signaturen genügt diese Inventur nicht. Zwei Systeme können dieselben Einträge besitzen und trotzdem beim entscheidenden Schritt verschiedene Sicherheitseigenschaften anwenden.

Der Unterschied entsteht beim Prüfen. Ein Sender versieht ein Dokument, Softwarepaket oder Zertifikat mit zwei Signaturkomponenten. Der neue Empfänger verlangt den Erfolg beider. Ein älterer Empfänger darf die unbekannte Komponente ignorieren und verlässt sich auf die traditionelle. Das Objekt ist bitgleich; die Aussage hinter der Annahme ist es nicht.

RFC 9955 liefert dafür eine außergewöhnlich klare Systematik. Es ist ein Konsensdokument des IETF, aber Informational, kein Standards-Track-Profil. Es schreibt keinen konkreten Kombinierer vor, fordert keinen Sektor zur Einführung auf und nimmt keine IANA-Zuweisung vor. Stattdessen trennt es Ziele, die in Projektfolien oft im Wort „hybrid“ zusammenfallen.

Diese Trennung sollte in den Architekturentscheid übernommen werden. „Erzeugung unterstützt“ ist ein Befund. „Jeder relevante Empfänger prüft alle Komponenten“ ist ein anderer. „Die Konstruktion verhindert gültige Abtrennung“ ist ein dritter. „Ein Modul ist zugelassen“ ist ein vierter. Wer nur zwei Häkchen setzt, überspringt die Beziehungen zwischen ihnen.

Nichttrennbarkeit ist kein einzelner Schalter

RFC 9955 beschreibt ein Spektrum. Bei schwacher Nichttrennbarkeit bleibt nach dem Entfernen einer Komponente ein Artefakt der Hybridabsicht zurück. Die abgetrennte Komponente kann trotzdem erfolgreich geprüft werden. Ein sorgfältiger Prüfer oder eine spätere Untersuchung kann den verbliebenen Hinweis erkennen.

Bei starker Nichttrennbarkeit erzeugt die Trennung keine selbständig gültige Komponentensignatur. Starke Nichttrennbarkeit mit gleichzeitiger Verifikation geht weiter: Ein normal arbeitender Prüfer kann nicht nach dem Erfolg einer Komponente beenden, ohne auch das Ergebnis der anderen zu kennen.

Das Artefakt kann an verschiedenen Stellen liegen. In der Signatur gehört es zur Algorithmusschicht. In einem Zertifikat oder in der Algorithmusaushandlung liegt es in der Protokollschicht. Als Kennzeichnung im signierten Inhalt gehört es zur Richtlinie.

Gerade die letzte Variante verschiebt viel Verantwortung. Die Echtheit des Inhalts soll durch die Signatur belegt werden; zugleich erfährt der Prüfer aus dem Inhalt, dass eine hybride Prüfung verlangt war. Ignoriert er diese Kennzeichnung, kann die Einzelkomponente gültig bleiben, obwohl eine spätere Untersuchung noch Spuren der Trennung findet. Das ist ein zirkulärer Bezug zwischen Inhalt und Signaturauslegung.

Auch Bezeichnungen wie Verkettung, Verschachtelung oder Fusion lösen die Frage nicht. Derselbe allgemeine Ansatz kann Artefakte im Inhalt, im Zertifikat, in der Signatur oder nirgends platzieren. Der Architekturentscheid muss daher den Ort, die Leseberechtigung und die Reaktion des Prüfers festhalten.

Kompatibilität wird am Empfänger bezahlt

Rückwärtskompatibilität ist bei langlebiger Infrastruktur oft unvermeidlich. Beschaffung, Gerätewechsel, Root-Zertifikate und Archive bewegen sich langsam. Ein hybrider Sender kann den Übergang beginnen, bevor der letzte Empfänger erneuert ist.

Doch RFC 9955 benennt den Preis. Rückwärtskompatibilität und starke Nichttrennbarkeit schließen sich aus. Muss jede Entfernung zum Fehler führen, kann ein Empfänger, der nur eine Komponente versteht, das Objekt nicht weiter annehmen. Wird die Kompatibilität tatsächlich genutzt und eine Komponente übersprungen, gilt auch die hybride Unfälschbarkeit nicht für diese konkrete Prüfung.

Das bedeutet nicht, dass jede Ausnahme unzulässig wäre. Es bedeutet, dass sie als Ausnahme behandelt werden muss. Eine Empfängerkohorte braucht einen Namen. Die verlorene Eigenschaft braucht eine präzise Beschreibung. Ein Verantwortlicher muss das Restrisiko akzeptieren. Und eine Frist muss festlegen, wann die Ein-Komponenten-Annahme endet.

Ohne diese Angaben wird die Migrationsquote zum falschen Spiegel. Sie zeigt, was Sender liefern, und verdeckt, was die wichtigsten Empfänger tatsächlich verlangen. Eine einzige alte Freigabestelle kann institutionell bedeutsamer sein als tausend modernisierte Lesegeräte.

Schlüsselrichtlinien reichen bis zum letzten Vertrauenspunkt

Eine abgetrennte Komponentensignatur kann einem anderen Prüfer vorgelegt werden als dem vorgesehenen hybriden Empfänger. Vertraut eine weitere Anwendung oder ein weiteres Protokoll demselben Komponentenschlüssel, endet die Schutzwirkung der Richtlinie des Hauptsystems an dessen Grenze.

Der RFC nennt die Beschränkung der Schlüsselwiederverwendung als Gegenmaßnahme. Zertifikate können erlaubte Nutzungen angeben; eigene Schlüssel können für die hybride Konstruktion reserviert werden. Zugleich wird die Grenze nicht beschönigt: Das ist eine Richtlinienanforderung, keine kryptografische Zusicherung. Sie wirkt nur, wenn alle relevanten Signierer und Prüfer sie konsistent durchsetzen.

Für die Prüfung reicht daher kein Bibliotheksinventar. Öffentliche Schlüssel, Zertifikatsprofile, Protokolle, Anwendungen, Softwarestände, Richtlinien und Eigentümer müssen verknüpft werden. Wer nicht weiß, wo ein Schlüssel noch akzeptiert wird, kann die Exklusivität seiner Nutzung nicht belegen.

Eine geschriebene Regel ist in Heng Lus Policy-Mirror-Sinn nur so belastbar wie ihr Abbild im laufenden System. Der Beleg für „nur hybrid“ ist die Ablehnung in jedem anderen relevanten Kontext.

Zulassung und Zusicherung bilden zwei Achsen

Der zweite wichtige Teil des RFC ist sein Zulassungsspektrum. Ein eng fusionierter neuer Algorithmus kann eine neue Begutachtung erfordern. Ein Wrapper, der zugelassene Komponenten unverändert als Blackboxes aufruft, kann vorhandene Zulassungen leichter weiterverwenden. Das ist ein echter Beschaffungsvorteil.

Es ist aber keine Abkürzung zur gleichzeitigen Verifikation. Getrennte Aufrufe erzwingen nicht, dass ein Prüfer beide Ergebnisse als unteilbare Entscheidung behandelt. Umgekehrt kann eine Fusion stärkere Nichttrennbarkeit bieten und gerade deshalb neue Analyse benötigen.

Die PQC-FAQ des NIST beschreibt eine Dual-Signatur-Prüfung als erfolgreichen Nachweis aller Komponenten und erklärt, dass bestehende Standards solche Signaturen aufnehmen können, wenn mindestens ein Komponentenalgorithmus zugelassen ist. FIPS 204 standardisiert ML-DSA. Das sind genaue, begrenzte Aussagen. Aus der Zulassung einer Komponente folgt nicht die Zulassung jeder Eigenschaft des Kombinierers, der Schlüsselherkunft, der Ausnahmeverwaltung oder der ausgeführten Prüfung.

Ein Beschaffungsentscheid darf den Zulassungsweg gewichten. Er muss dafür offenlegen, welche Sicherheitsaussagen weiterhin von Richtlinie, Zertifikatskette und Prüferverhalten abhängen.

Der Nachweis für die ausgeführte Prüfung

Die Signatur selbst ist bereits im Objekt. Zusätzlich benötigt jede folgenreiche Annahme einen Nachweis des Entscheidungskontexts. Er sollte binden:

  1. Objekt-Hash, Nutzungskontext, erwartete Hybridkonstruktion und Version;
  2. Komponentenalgorithmen, nicht geheime öffentliche Schlüsselkennungen und tatsächlich validierte Herkunftsketten;
  3. Ort jedes Artefakts der Hybridabsicht und die Tatsache, dass der Prüfer es ausgewertet hat;
  4. den geforderten Ergebnisvektor, die beobachteten Ergebnisse aller Komponenten und die Endentscheidung;
  5. die beanspruchte Form von Nichttrennbarkeit oder gleichzeitiger Verifikation, abgeleitet aus Konstruktion und Ausführung;
  6. Prüfer-Build, Konfigurations-Hash und Richtlinienrevision;
  7. Regeln zur Schlüsselwiederverwendung und die Population, die sie durchsetzt;
  8. Zulassungs- oder Validierungsstatus bezogen auf die genaue Komponente beziehungsweise das Modul;
  9. Empfängerkohorte, Alt-Ausnahme, Eigentümer und Ablauf;
  10. Fehlerbehandlung und Einfluss partieller Resultate;
  11. Entscheidungszeit, Aufbewahrungsdauer und Auslöser einer erneuten Prüfung;
  12. die Befugnis zu Ablehnung, Quarantäne oder Rücknahme, wenn sich die Zusicherung nicht reproduzieren lässt.

Der Nachweis bleibt geheimnisfrei. Er enthält Hashes, Versionen, begrenzte Kennungen und geschützte Protokollverweise, keine privaten Schlüssel oder vertraulichen Inhalte. Er macht schwache Kryptografie nicht stark. Er verhindert, dass ein lokales gültig als globale Hybridgarantie ausgegeben wird.

Ein Testplan für die Empfangsseite

Eine belastbare Abnahme schickt denselben geprüften Objektkorpus durch jede wesentliche Kombination von Prüfer-Build und Richtlinie. Jeweils eine Komponente fehlt oder ist falsch; Artefakte werden verändert; Zertifikatsketten wechseln; ein Komponentenschlüssel wird in einem anderen Vertrauenskontext angeboten.

Das Ergebnis muss nicht nur Erfolg oder Fehler zeigen. Es hält fest, welche Operationen in welcher Reihenfolge liefen, welche Richtlinie galt und ob ein Teilergebnis die Entscheidung beeinflussen konnte. Erst danach lässt sich die institutionelle Aussage prüfen.

„Alle Sender erzeugen zwei Signaturen“ kann wahr sein, während „alle kritischen Empfänger prüfen beide“ falsch ist. „Stark nichttrennbar“ kann zutreffen, ohne dass ein bestimmtes Modul zugelassen ist. „Zugelassene Komponente“ kann zutreffen, ohne starke Nichttrennbarkeit zu liefern. Die Minimum Initial Specification beginnt mit jeder dieser kleinen Aussagen und verbindet sie erst, wenn Belege die Kanten tragen.

Ein negativer Test ist kein nutzloses Ergebnis. Er identifiziert eine Kohorte, der man Funktionen entziehen, eigene Schlüssel geben, Budget zuweisen und ein Ausstiegsdatum setzen kann. Unsichtbare Kompatibilität lässt sich nicht beenden; eine benannte Ausnahme schon.

Grenzen

Dieser Beitrag berichtet keinen Angriff, keine Fälschung, keinen Produktfehler, keinen Vorfall und keinen Zulassungsverstoß. Die Quellen behandeln Standards und Eigenschaften, nicht die Verbreitung konkreter Implementierungen. Starke Nichttrennbarkeit und gleichzeitige Verifikation sind nicht für jeden Anwendungsfall die beste Wahl. Der Nachweis schützt nicht vor zukünftigen kryptanalytischen Erkenntnissen.

Er erhält eine kleinere, aber entscheidende Wahrheit: Welche Prüfung hat welche Instanz unter welcher Richtlinie tatsächlich akzeptiert?

Quellen