Summary

  • Revision 04 eines individuellen Internet-Drafts ergänzt einen proprietären CygnetSSL-CA-Treiber in einer von einem Administrator geführten Umgebung; ein unabhängiger Interoperabilitätstest fehlt.
  • Die 22 ECDSA-Zertifikate, eine DER-kodierte CRL und ein OCSP-Wechsel von good zu revoked sind CA-Betriebsdaten. Sie belegen weder TLS- und DNSSEC-Exporte noch Zertifikatsverteilung, QUIC-Signale oder eine CBOM-kompatible Aggregation.
  • Daniel Kade schlägt eine Evidenzmatrix vor, in der jede Lücke separat geschlossen wird. Das ist eine redaktionelle Empfehlung, keine IETF-Vorgabe und kein Urteil gegen die genannte Implementierung.

Die neue Angabe hat einen klaren Prozessrahmen

Die am 13. September veröffentlichte Revision 04 fügt einen Abschnitt zum Implementierungsstand ein. In Revision 03 fehlt er; der offizielle Vergleich grenzt die Ergänzung ab. Solche Angaben sind im Sinne von RFC 7942 nützlich: Leser erfahren, ob eine Spezifikation Berührung mit laufendem Code hat. Daraus folgt weder technische Reife in jeder Umgebung noch Zustimmung im Standardisierungsprozess.

Der Datatracker-Eintrag bezeichnet das Dokument als aktiven individuellen Internet-Draft. Laut Metadaten-API handelt es sich um Revision 04 mit dem IESG-Status I-D Exists, ohne IETF stream; der Kopf nennt Informational als angestrebten Status. Der Text ist also weder Arbeitsgruppenkonsens noch IESG-Freigabe oder RFC.

Was der Versuch zeigt – und was nicht

Dokumentiert wird ein proprietärer CA-Treiber von CygnetSSL in einer einzigen, von einem Administrator verwalteten Umgebung. Eine unabhängige Interoperabilitätsprüfung gab es nicht. In zwei Profilen wurden 22 End-Entity-Zertifikate beobachtet, sämtlich ECDSA P-384 / ECDSA-SHA384. Hinzu kommen eine CRL im DER-Format und ein OCSP-Status, der von good auf revoked wechselte.

Das sind brauchbare Spuren aus Ausstellung und Widerruf. Es sind keine Post-Quanten-Zertifikate und kein Nachweis einer PQC-Einführung. Zwar standardisieren FIPS 204 und FIPS 205 ML-DSA beziehungsweise SLH-DSA. Die Existenz dieser Standards sagt jedoch nicht, ob ein Betreiber den tatsächlichen Algorithmusbestand seiner Protokolle vollständig messen kann.

Die fünf Lücken liegen auf verschiedenen Messflächen

REQ-RG-1 bis REQ-RG-5 verlangen jeweils andere Exporte: den ausgehandelten Algorithmus pro TLS-Sitzung, den Algorithmus pro DNSSEC-Zone, die Verteilung von Zertifikatsalgorithmen einschließlich OCSP- und CRL-Nachweisen, ein entsprechendes QUIC-Signal sowie eine protokollübergreifende Aggregation, die mit einer Cryptography Bill of Materials interoperabel ist. Die zugehörigen technischen Gegenstände beschreiben RFC 8446, RFC 4034, RFC 5280, RFC 6960 und RFC 9000.

Eine Stichprobe von Zertifikaten beantwortet keine Frage nach TLS-Sitzungen, signierten Zonen oder QUIC-Verbindungen. Entscheidend ist der Nenner: 22 von wie vielen Zertifikaten, aus welcher Population und mit welchen Ausschlüssen? Ohne diese Angaben kann eine korrekte lokale Beobachtung unbemerkt zur Behauptung über die Gesamtumgebung werden.

Abhilfe schafft eine zeilenweise Lückenschluss-Matrix. Jede Zeile enthält genau eine Anforderung sowie Messmechanismus und Version, Artefakt, stabilen Fundort, Umgebung und Betreiber, Testmethode, Population und Nenner, Ergebnis, Einschränkung, Datum, Verantwortlichen, nächsten Prüftermin und unabhängigen Reproduzenten. Zulässige Zustände wären etwa „Versuch vorhanden“, „teilweise abgedeckt“ oder „unabhängige Prüfung ausstehend“. Die Implementierung behält so ihren Informationswert, ohne eine pauschale Bereitschaftsampel auszulösen.

Der Entwurf verweist als Implementierungsbeleg auf eine CygnetLib-URL bei GitHub. Zum Recherchezeitpunkt antwortete genau diese Adresse vom Produktionshost aus mit HTTP 404. Das ist eine zeitlich und auf den Pfad begrenzte Erreichbarkeitsfeststellung. Sie beweist weder, dass das Repository nie existierte, noch erlaubt sie Rückschlüsse auf Absichten oder die Funktionsfähigkeit der Software. Für die Matrix bedeutet sie lediglich: Solange der referenzierte Gegenstand nicht abrufbar ist, bleibt unabhängige Reproduktion offen.

Dieses Vorgehen folgt der überprüfbaren institutionellen Abbildung aus The Policy Mirror, dem schrittweisen Ausbau einer minimalen Ausgangsspezifikation in Minimum Initial Specification und der Trennung von beobachtbarer Wirklichkeit und Fürsprache in Why BTW Media Exists. Die faire Bilanz lautet deshalb: ein wertvoller Implementierungshinweis, fünf weiterhin offene Beweislinien.

Sources

  1. PQC-Bereitschaftslücken, Revision 04
  2. PQC-Bereitschaftslücken, Revision 03
  3. Offizieller Vergleich 03–04
  4. Datatracker-Eintrag
  5. Datatracker-Metadaten-API
  6. RFC 7942
  7. RFC 8446
  8. RFC 4034
  9. RFC 5280
  10. RFC 6960
  11. RFC 9000
  12. NIST FIPS 204
  13. NIST FIPS 205
  14. Im Entwurf zitierter CygnetLib-Link
  15. The Policy Mirror
  16. Minimum Initial Specification
  17. Why BTW Media Exists