Zusammenfassung

  • Mit RFC 9763 kann ein Antragsteller die Kontrolle über den privaten Schlüssel eines bestehenden Zertifikats belegen; die CA kann anschließend den Hash des vollständigen Altzertifikats in das neue Zertifikat aufnehmen.
  • Diese Beziehung ist eine Ausstellungsaussage, kein Ergebnis einer laufenden Authentisierung. Sie schreibt weder die gemeinsame Nutzung vor noch entscheidet sie, ob eine oder beide Authentisierungen erfolgreich sein müssen.
  • Revisionssichere Migration trennt Registrierungsbeleg, CA-Richtlinie, exakte Zertifikatsbytes, aktuelle Schlüsselhandlungen, beide Pfade, Aushandlung und lokale Endpunktentscheidung.

Der einfachste Fehler steht oft im Statusbericht: „Zertifikate verknüpft, Migration abgeschlossen.“ Die erste Hälfte kann technisch korrekt sein. Die zweite folgt daraus nicht.

Eine Verknüpfung zeigt nicht, dass beide privaten Schlüssel in einer beobachteten Sitzung gehandelt haben. Sie sagt nichts über die Vertrauensanker des Gegenübers. Sie schützt die Aushandlung nicht vor einer Herabstufung und erteilt der Anwendung keine Freigabe.

RFC 9763 definiert dafür das CSR-Attribut relatedCertRequest und die X.509-Erweiterung RelatedCertificate. Gemeinsam liefern sie zusätzliche Gewissheit, dass zwei Endteilnehmerzertifikate derselben Entität gehören. Die Mechanismen drücken eine Beziehung aus; allein bewirken sie keine Sicherheitsfunktion.

Zwei Schlüssel, zwei nachweisbare Handlungen

Das vorhandene Zertifikat sei Cert A, das neu beantragte Cert B. Eine klassische und eine postquantenfähige Identität parallel zu führen, ist das Leitbeispiel.

Der normale Antrag für B enthält den neuen öffentlichen Schlüssel. Im PKCS#10-Modell aus RFC 2986 signiert das Subjekt die Antragsinformationen. Dadurch werden Name, Schlüssel und Attribute gebunden und der Besitz des zugehörigen privaten Schlüssels gezeigt.

RFC 9763 ergänzt eine Handlung des A-Schlüssels. relatedCertRequest enthält Aussteller und Seriennummer von A, Antragszeit, Fundort und Signatur. Der private Schlüssel von A signiert die DER-kodierte Kennung zusammen mit BinaryTime.

RFC 6019 zählt dafür Sekunden seit dem 1. Januar 1970, 00:00 UTC, ohne Schaltsekunden. Das Format ist gemeinsam; das zulässige Alter bestimmt die lokale CA-Richtlinie. Ein Audit braucht daher Wert, Entscheidungszeitpunkt, Grenzwert und Richtlinienversion statt nur eines Frische-Boolschen Werts.

Die CA prüft eine Kette von Aussagen

Eine unterstützende CA muss A vom angegebenen Ort beziehen und den Zertifizierungspfad nach RFC 5280 prüfen. Sie vergleicht Aussteller und Seriennummer, bewertet die Frische und prüft die Attributsignatur mit dem öffentlichen Schlüssel von A.

Abruf, Pfad, Kennung, Zeit und Signatur sind eigenständige Ergebnisse. Der Abruf bestimmt die empfangenen Bytes. Die Pfadprüfung hängt von Ankern und Richtlinien ab. Die Kennung verhindert den Tausch des gemeinten Zertifikats. Die Signatur belegt die damalige Handlung des A-Schlüssels.

RFC 5280 behandelt Vertrauensanker und Richtlinien als Eingaben. Ein formal gültiger Pfad ist nicht automatisch für jede Anwendung geeignet. Key Usage und Extended Key Usage müssen, sofern beide vorhanden sind, unabhängig verarbeitet werden.

Nach erfolgreicher Prüfung kann die CA B mit der Erweiterung ausstellen. Sie darf nur A referenzieren, muss die beanspruchten Schlüsselverwendungen abgleichen und sollte A zum Ausstellungszeitpunkt als gültig bestimmen. Für die praktisch nutzbare Überschneidung der Laufzeiten bleibt der Teilnehmer verantwortlich.

Ein morgen ablaufendes A macht ein zwölf Monate gültiges B nicht zwölf Monate lang hybrid nutzbar. Widerruf oder Neuausstellung können die operative Paarung beenden, obwohl die ursprüngliche Ausstellung korrekt war.

Der Hash meint genau dieses Zertifikat

Die Erweiterung enthält den Digest-Algorithmus und den Hash über das gesamte Cert A. Nicht nur der öffentliche Schlüssel, nicht nur der Subjektname und nicht eine abstrakte Kundenidentität werden gebunden.

Der Prüfer kann den Hash des empfangenen A lokal neu berechnen. Das ist eine deterministische gemeinsame Regel ohne Online-Auslegung. Wird A jedoch mit gleicher Identität und gleichem Schlüssel neu ausgestellt, ändern Seriennummer, Laufzeit oder Erweiterungen die Bytes und damit den Hash. Das neue A ersetzt die referenzierte Ausgabe nicht automatisch.

Bestandslisten, die nur nach Namen gruppieren, können deshalb eine Beziehung vortäuschen. Für die Kontrolle braucht es Artefakt-Fingerabdrücke. Die Erweiterung sollte außerdem nicht kritisch markiert werden und gehört nur in Endteilnehmerzertifikate. Ein altes Programm darf sie ignorieren; Fehlerfreiheit ist dann kein Nachweis der Beziehungskontrolle.

Nach dem Vergleich beginnt die lokale Entscheidung

Unterstützt ein Endpunkt nicht-komposite hybride Authentisierung, kann er A und B empfangen, die Erweiterung lesen und den Hash vergleichen. Wie es danach weitergeht, lässt RFC 9763 ausdrücklich offen. Eine Richtlinie verlangt beide Authentisierungen, eine andere mindestens eine.

Bei CMS oder S/MIME entscheidet der Signierende, was er anbietet; bei ausgehandelten Protokollen kann der Prüfer Präferenzen äußern. RFC 5652 definiert CMS, RFC 8551 die referenzierte Zertifikatsverpackung. Das Datenformat trifft keine Anwendungsentscheidung.

Der Standard bezeichnet die Beziehung weder als Pflicht noch als Mandat zur gemeinsamen Verwendung. Er sagt, dass die Zertifikate zusammen eingesetzt werden können, weil dieselbe Entität die Schlüssel kontrolliert. Die CA verantwortet ihre Aussage; der Endpunkt verantwortet das angenommene Risiko.

Registrierung ist nicht Gegenwart

Für hybride Sicherheit ist Kontrolle zu zwei Zeiten nötig: bei der Registrierung gegenüber der CA und bei der Nutzung gegenüber dem Prüfer. Die A-Signatur im Antrag belegt den ersten Zeitpunkt. Der normale B-Antrag behandelt den neuen Schlüssel. Die Erweiterung bewahrt die Beziehung. Die spätere Sitzung verlangt neue kryptografische Handlungen.

Wird nur mit A signiert, macht ein beigelegtes B die Sitzung nicht postquantenfest. Treffen zwei Signaturen ein, aber nur eine wird geprüft, trägt die andere keine Gewissheit. Bestehen beide mathematisch, kann ein lokal nicht vertrauter Pfad dennoch zur Ablehnung führen.

Hier liegt die Abgrenzung zu RFC 9883. Dort darf ein zertifizierter Signaturschlüssel eine richtliniengestützte Aussage über den Besitz eines anderen Schlüssels machen, ohne dessen technischen Besitznachweis. RFC 9763 verwendet eine echte A-Signatur und im normalen Ablauf eine B-Antragssignatur und schreibt danach die Beziehung. Diese Untersuchung betrifft die Grenze zwischen Registrierungsbeweis und Sitzungsbeweis.

RFC 9955 behandelt Eigenschaften hybrider Signaturen und Kombinationsregeln. RFC 9763 wählt keine universelle Regel, sondern liefert eine Beziehungsinformation für andere Protokolle.

Zwei CAs bedeuten zwei Vertrauensordnungen

Innerhalb einer Organisation sind Repository und Anker häufig bekannt. Soll eine andere Organisation B ausstellen, kann sie A möglicherweise nicht validieren. RFC 9763 nennt Vorabvereinbarungen, Verträge, konfigurierte Vertrauensanker und Absprachen über Ausstellung und Akzeptanz.

Gemeinsame Schlüsselkontrolle bedeutet nicht gleiche Gewährleistung. Identitätsprüfung, Schlüsselschutz, Widerrufsleistung und Teilnehmerpflichten können abweichen. Die B-CA soll eine vergleichbare Richtlinie wählen. Vergleichbarkeit ist jedoch eine zurechenbare Entscheidung, kein Hash-Ergebnis.

„Gleiche Entität“ darf im Bericht nicht zu „gleiches Sicherheitsniveau“ werden. „Gültiger Pfad“ ist nicht „für diese Anwendung akzeptiert“. „Beziehung passt“ ist nicht „beide Authentisierungen waren erfolgreich“.

Der Fundort ist eine eigene Angriffsfläche

Das Attribut nennt den Ort von A. Innerhalb derselben Organisation kann HTTP(S) auf eine CMS-Nachricht mit Zertifikaten verweisen. Organisationsübergreifend wird eine data:-URL mit Zertifikaten und Widerrufsmaterial empfohlen; RFC 2397 definiert das Schema.

Eine signierte URL macht ihren Inhalt nicht sicher. Sie kann auf bösartige Daten zeigen, die vollständig geparst und validiert werden müssen. Der Netzwerkabruf kann außerdem beobachtet werden. Eingebettete Daten mindern diese Sichtbarkeit, beseitigen die Validierungspflicht aber nicht.

Zu speichern sind Abrufart, Hash des empfangenen Objekts, Parsergebnis, Pfad- und Widerrufsdaten sowie Anker. B allein rekonstruiert diese Entscheidungsgrundlage nicht.

Downgrade bleibt außerhalb des Zertifikats

Ein böswilliger Peer kann Unterstützung für den stärkeren Algorithmus verschweigen. Die Erweiterung wird erst nach dem Empfang eines Zertifikats ausgewertet und belegt weder angebotene Fähigkeiten noch eine geschützte Aushandlung.

Schutz entsteht durch Mindestkonfigurationen, authentisierte Transkripte, Telemetrie des gewählten Modus und Warnungen bei Rückschritten. Die Zahl verknüpfter Zertifikate misst Bereitschaft; nur Verkehrsdaten messen Nutzung.

Das entspricht Heng Lus Running-Code-Primat. Minimale Anfangsspezifikation, lokalisierte Zukunftsentscheidung und freiwillige Übernahme erlauben gemeinsame Felder, Signaturen und Hashregeln, ohne der CA die künftige Entscheidung jedes Endpunkts zu übertragen.

Die Realitätsebenen trennen Registrierungsbeleg, Ausstellungsaussage, Zertifikatsbytes, Hashvergleich, aktuelle Signatur, Pfad, Autorisierung und Wirkung. Sie sind verbunden, aber nicht identisch.

Eine reproduzierbare Beweiskette

Bei der Registrierung gehören CSR, A-Kennung, Zeit, Ort, signierte Bytes, Signaturergebnis und Pfaddaten in den Nachweis. Bei der Ausstellung: A-Bytes und Hash, B-Bytes, Nutzungsvergleich, Richtlinie und Laufzeitüberschneidung.

Bei der Nutzung: tatsächlich empfangene Zertifikate, beide Pfadergebnisse, Beziehungsberechnung, ausgeführte Schlüsselnachweise, ausgehandelter Modus, Richtlinienversion und Verbindungsergebnis. So lässt sich ein Vorfall dem richtigen Entscheidungsträger zuordnen.

Quellen