Zusammenfassung

  • Pull Request 679 würde ML-DSA-44, ML-DSA-65 und ML-DSA-87 in die TLS Baseline Requirements aufnehmen und Schlüssel sowie Signaturen in Subscriber- und CA-Zertifikaten, CRLs und OCSP-Antworten profilieren.
  • Die Begründung nennt SDK-basierte Clients, eingebettete und IoT-Systeme, Unternehmens-Middleware sowie Anwendungen mit System-Trust-Stores. Sie stellt zugleich klar, dass weder Root-Store-Vertrauen erzwungen noch die SCT-Signatur eines CT-Logs geändert würde.
  • Die SCWG-Charta umfasst TLS-Zertifikate für über das Internet erreichbare Server. Ein stimmberechtigter Certificate Consumer muss aber Software für die sichere Web-Navigation der Öffentlichkeit herstellen; auch die Issuer-Qualifikation wird über Browserakzeptanz geprüft.
  • Ausdrücklich ausgeschlossen ist eine engere Klasse rein interner Unternehmens-PKI. Daraus folgt weder, dass jeder Non-Web-Fall ausgeschlossen, noch dass jede Software mit öffentlicher Root automatisch vertreten ist.
  • Zum Stichtag 2. September 2026 war SC-106 ein offener Draft-PR und fehlte auf der offiziellen Ballot-Seite. Kommentare und Sitzungsprotokolle belegen Streit, nicht Beschluss oder Konsens.
  • Ein Mandatsbeleg sollte Zielgruppen, Charta-Klausel, Beteiligung, gemeinsames Invariant, Root-/CT-/Pfadgrenzen, Implementierungsnachweise, alternatives Forum und Überprüfungstermin ausweisen.

Bedarfskreis und Abstimmungskreis fallen nicht zusammen

Die institutionell wichtigste Passage von SC-106 ist keine ASN.1-Regel. Der PR behauptet, viele relying parties hätten innerhalb der bestehenden öffentlichen X.509-Infrastruktur keinen praktischen Weg zu postquantenfester Authentisierung. Danach benennt er die Betroffenen: Service-Clients auf SDK-Basis, Embedded- und IoT-Systeme, Middleware und Anwendungen, die von Betriebssystemherstellern verwaltete Trust Stores verwenden.

Diese Programme können TLS-Server authentisieren, ohne Browser zu sein. Die Charta des Server Certificate Working Group legt für die stimmberechtigte Consumer-Klasse jedoch einen anderen Anker fest. Das Mitglied muss für die Allgemeinheit ein Softwareprodukt zum sicheren Browsen im Web herstellen, regelmäßig aktualisieren und seine Root- sowie Compliance-Mechanik dokumentieren. Der Certificate Issuer qualifiziert sich über Zertifikate, die in einem Browser eines solchen Consumer-Mitglieds gültig sind.

Ein Browserhersteller kann zugleich ein Betriebssystem oder eine Kryptobibliothek betreiben. Ein CA-Mitglied kann die Gerätewelt sehr gut kennen. Diese Mehrfachrollen schaffen technisches Wissen, erweitern aber nicht automatisch den Wortlaut, auf dem die Stimmqualifikation beruht.

Lu Hengs Trennung von Stakeholder und Principal ist dafür präzise. Betroffenheit und Teilnahme liefern Informationen; sie ersetzen keine Bevollmächtigung durch die Partei, die Kompatibilitätskosten trägt. Die öffentliche Akte müsste daher festlegen, ob SC-106 ein Web-Mindestprofil mit zusätzlichem Nutzen, eine ancillary activity oder ein allgemeines Public-Trust-Profil für mehrere, teilweise nicht stimmberechtigte Nutzergruppen ist.

Der eingefrorene Text schafft konkrete Koppelungen

Commit eefc670… ergänzt die drei FIPS-204-Parametersätze, prüfbare Public-Key-Encodings, Key-Usage-Vorgaben und exakte AlgorithmIdentifier. Parameter müssen fehlen; HashML-DSA ist untersagt. Nur die „pure“ Variante darf verwendet werden.

Danach koppelt der Entwurf zertifizierten Schlüssel und Signatur in beide Richtungen. Ein ML-DSA Subject Public Key braucht eine ML-DSA-Zertifikatssignatur. Eine ML-DSA-Signatur in Certificate oder Precertificate darf nur einen ML-DSA-Schlüssel zertifizieren. Für CRL und OCSP gilt die zweite Regel nicht, weil diese Objekte keinen öffentlichen Schlüssel zertifizieren.

Der Vorspann grenzt die Wirkung selbst ein. Root Store Operators bleiben frei, die Hierarchie nicht zu akzeptieren. Das Verfahren ändert nicht den Algorithmus, mit dem ein CT-Log den Signed Certificate Timestamp signiert. Damit sind Erlaubnis zur Ausstellung, Root-Vertrauen, CT-Operation und akzeptierter Pfad getrennte Entscheidungen.

Gerade deshalb muss der angebliche Blocker bestimmt werden. Verhindert heute der BR-Text eine auditierbare Ausstellung? Verweigert ein Root-Programm den Schlüssel? Fehlt Library-Support, Trust-Store-Distribution, Path Building oder Credential Negotiation? Die Quellen enthalten keine Bestandsaufnahme der betroffenen Versionen und keinen Nachweis, dass ein einziges Pure-Chain-Profil all diese Hindernisse löst.

Eine Draft-PR ist noch kein formales Ballot

Der Repository-Titel verwendet SC-106, und der Vorspann spricht vom geplanten Ballot. Am Stichtag zeigte GitHub dennoch Open, Draft, einen Commit und keine formale Review. Die offizielle SCWG-Seite listete SC-106 weder unter Voting, IPR Review, Discussion, Draft / Under Consideration noch im Ballot-Verzeichnis.

Die zurechenbare Verfahrenslage lautet daher: Draft Pull Request. Ein offizielles Diskussionsfenster, formale Proposer und Endorser, Abstimmungsdaten, Stimmen, Ergebnis, IPR-Verfahren, Final Maintenance Guideline oder Inkrafttreten sind nicht belegt.

Die Zustände bauen aufeinander auf. Ein Autor erstellt Text. Das Working Group nimmt eine bestimmte Fassung in sein Verfahren. Issuer und Consumer stimmen getrennt ab. Die IPR-Regeln behandeln Ausschlüsse. Eine Endfassung erhält ein Datum. Danach treffen Root-Programme, CAs, CT und Clients eigene Umsetzungsentscheidungen. Der erste Text darf diese Befugnisse nicht vorwegnehmen.

Der unveränderliche Vergleich erfüllt eine andere Funktion: Er hält fest, was zu einem bestimmten Zeitpunkt vorgeschlagen war, selbst wenn es später ersetzt wird.

Die Charta ist funktional weit und repräsentativ eng

Wer nur „browsing the Web securely“ zitiert, lässt die Scope-Klausel aus. Sie ermächtigt das SCWG, Anforderungen für TLS-Serverzertifikate zu entwickeln, die Internet-erreichbare Server authentisieren, und auf neue Online-Bedrohungen zu reagieren. Sie erlaubt auch Tätigkeiten, die zu den Hauptaufgaben ancillary sind. Das ist weiter als ein einzelnes Browserprodukt.

Wer nur „servers accessible through the Internet“ zitiert, lässt die Entscheidungsquelle aus. Consumer-Stimmen sind an Browser-Software gebunden; Issuer-Stimmen an Zertifikate, die ein solcher Browser akzeptiert. Die technische Nutzerfläche von X.509 ist größer als diese Mitgliedschaftsdefinition.

Die Out-of-Scope-Regel schließt Unternehmens-PKI aus, die ausschließlich intern genutzt wird und deren Root von keinem Certificate Consumer verteilt wird. Außerdem werden primäre Zwecke wie Code Signing und S/MIME ausgeschlossen. Diese Regel sagt nicht, dass jeder System-Client außerhalb liegt. Sie zeigt aber, dass Grenzziehung ein ausdrücklicher Akt sein kann.

Der belastbare Befund ist daher ein Interpretationskonflikt, kein Verstoß. Falls der Internet-Server-Satz oder „ancillary“ trägt, sollte die Gruppe die Klausel, den Interpretationsinhaber und die Reichweite öffentlich festhalten. Sonst entscheidet die technische Datei indirekt über die institutionelle Zuständigkeit.

Tokio dokumentierte die ungeklärte Nahtstelle

Die Minutes des F2F 64 vom März 2025 enthalten einen eigenen Punkt zur Klärung des TLS-BR-Umfangs. Diskutiert wurden Browser und Non-Browser, Betriebssystem-Trust-Stores, Server-to-Server-Anwendungen, private PKI, Agilität und ein möglicher neuer Arbeitskreis.

Eine Seite sah Browser-Root-Programme als operative Realität der BR und wollte die Web-Sicherheit nicht von weniger agilen Anwendungen blockieren lassen. Die andere erinnerte daran, dass Betriebssysteme und Anwendungen dieselben Roots nutzen, keine gleichwertige Alternative besitzen und durch browser-spezifische Regeln fragmentiert werden können.

Das Protokoll bewahrte beide Perspektiven, beschloss aber keine Charta-Änderung. Es beweist nicht, wer recht hat. Es beweist, dass die Institution den Konflikt vor SC-106 kannte.

Die Kommentare 2026 führen ihn fort. Ein Teilnehmer beschrieb die Fokusfälle als non WebPKI. Ben Wilson verwies auf den vom relying party konstruierten und akzeptierten Pfad. Ein späterer Chrome-Kommentar trennte die zwei Richtungen gemischter Ketten, stellte die Charta-Frage und schlug eine zusätzliche Forum Working Group vor.

Diese Äußerungen sind wichtige, namentlich zurechenbare Belege. Sie sind keine Abstimmung. Herstellerautorität und GitHub-Reaktionen ersetzen das kollektive Verfahren nicht.

„Pure“ beschreibt einen Pfad, nicht automatisch alle Pfade

Die Draft-Begründung sagt, dass ein klassischer Signaturlink im präsentierten Pfad dessen Assurance auf klassische Stärke begrenzt. Daraus folgt nicht zwingend, dass ein Profil jede gemischte Konstruktion verbieten muss. Ein Client kann einen vollständig postquantenfesten Pfad akzeptieren und eine klassische Alternative ignorieren; deren Existenz verändert die Signaturen im akzeptierten Pfad nicht.

RFC 5280 nennt den prospective certification path und die Trust-Anchor-Information als Eingaben. Die Anchor-Auswahl ist Policy. Unterschiedliche Pfade dürfen unterschiedliche Anchors nutzen. Das CA-Profil steuert die Ausstellung, nicht die lokale Pfadauswahl.

Eine gemeinsame Beschränkung kann dennoch gerechtfertigt sein. Eine klassische CA, die einen PQ-Subscriber-Key signiert, betrifft bestehende CT-Logs und endet in klassischer Authority. Eine PQ-CA, die vorübergehend einen klassischen Key signiert, kann einer Übergangs- und Downgrade-Sicherung dienen. Die Richtungen haben verschiedene Effekte.

Das gemeinsame Invariant muss benannt werden: Web-CT-Kapazität, Wahrhaftigkeit eines PQ-Pfadlabels, Root-Signalisierung, Legacy-Kompatibilität oder Non-Web-Migration. Eine einzige Pure-Chain-Regel darf nicht fünf Entscheidungsflächen als dieselbe behandeln.

Laufende Systeme zeigen mehrere Profile

Chromiums Roadmap beschreibt einen stufenweisen Web-Übergang mit Certificate Negotiation, parallelen klassischen und PQ-Credentials, Downgrade-Schutz und einer sehr fernen Entfernung klassischer Optionen. Für öffentliche Web-Vertrauensketten verfolgt Chrome Merkle Tree Certificates statt traditioneller ML-DSA-X.509-Zertifikate.

Die Testanleitung trennt weitere Zustände. Chrome 150 unterstützt traditionelle ML-DSA-Zertifikate in privaten Hierarchien. Für MTC existiert ein separater Test-Root-Store, der bewusst aktiviert werden muss; seine Cosigner sind ausdrücklich nicht für Produktionsvertrauen zugelassen. Log-, Mirroring- und Algorithmusbedingungen gehören zu diesem Testprofil.

Das ist kein Mandat für jedes Gerät. Es ist Running-Code-Evidenz dafür, dass private, experimentelle und spätere öffentliche Compatibility Sets getrennt entwickelt werden können.

FIPS 204 definiert ML-DSA. Ein Zertifikatsprofil definiert Encoding und Ausstellung. Root Policy entscheidet Vertrauen. CT entscheidet Admission und Transparenz. Der Client entscheidet Pfad und Anchor. Deployment beweist Wirkung. Lu Hengs Minimum-Initial-Specification-Disziplin verlangt, diese Verben nicht gegenseitig zu vertreten.

Inhalt eines Mandatsbelegs

Der erste Block enthält Base, Head, Status, formale Proposer und Endorser, Discussion, Voting, Stimmen je Klasse, IPR, Endfassung und Datum. Der zweite trennt Browser, OS-Validatoren, SDK, Embedded, IoT, Middleware, private und öffentliche PKI.

Für jede Klasse nennt der Beleg Charta-Klausel, Interpretationsinhaber, Stimmweg, Beratungsweg oder dessen Fehlen. Keine Stimme zu haben schafft kein Veto; es begrenzt den Repräsentationsanspruch.

Der Technikblock führt Encoding, Path Assurance, Downgrade, CT-Kapazität und Root Admission getrennt. Jede Zeile nennt Invariant, Decision Owner, Evidenz, Unsicherheit und lokale Wahl. Die Implementierungsspalten halten Testvektoren, Bibliothek, Version, Größe, Pfad, Pilot und Fehler fest.

Zum Schluss werden Foren verglichen: SCWG mit veröffentlichter Auslegung, Charta-Klärung, neue Non-Browser Working Group oder root-spezifische Pilotprofile. Review-Datum, Schwelle und Exit verhindern dauerhafte Übergangsregeln.

Was nicht belegt ist

SC-106 ist nicht angenommen, wirksam, abgelehnt oder technisch final. Es gibt keine kollektive Charta-Auslegung, keine Nutzerzählung, keine Produktionszusage eines Root Stores und keinen CT-Kapazitätsbefund. Die Quellen entscheiden auch nicht, welche Mixed-Chain-Richtung eingesetzt wird.

Ebenso wenig belegen sie Unnötigkeit oder Illegitimität. Der faire Zustand lautet: ein präziser technischer Draft trifft auf eine bekannte, ungeklärte Mandatsgrenze.

Jetzt ist der Nachweis billig. Später können Audits, Beschaffung und Tooling das Dokument als „Industriestandard“ behandeln; die so erzeugte Abhängigkeit würde dann rückwirkend als Legitimation seines Ursprungs erscheinen.

Ein enges Mandat kann ein starkes Profil tragen

Das SCWG kann seine Internet-Server-Kompetenz öffentlich auslegen und den Repräsentationsanspruch begrenzen. Das Forum kann für System- und Geräte-Clients eine andere Gruppe schaffen. Root-Programme können weiter testen, bis ein gemeinsames Invariant messbar wird.

Keine Option lehnt ML-DSA ab. Sie verhindert nur, dass der Ablageort eines Dokuments die Zuständigkeit bestimmt.

SC-106 trennt bereits Profile Permission, Root Trust und SCT-Signatur. Als Nächstes muss es Begünstigten und Wähler trennen. Dann bleibt die Technik genau so verbindlich wie ihr nachweisbares Mandat.

Quellen

  1. Lu Heng, „The Multi-Stakeholder Mirage“
  2. Lu Heng, „Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption“
  3. CA/Browser Forum, Pull Request 679 — SC-106
  4. Unveränderlicher SC-106-Vergleich
  5. Vorgeschlagene TLS Baseline Requirements
  6. Server Certificate Working Group Charter
  7. Minutes des SCWG F2F 64
  8. CA/Browser Forum Bylaws
  9. SCWG Ballot-Status
  10. NIST FIPS 204
  11. RFC 5280, Abschnitt 6
  12. Chromium Post-Quantum HTTPS Authentication Roadmap
  13. Testanleitung des Chrome Quantum-resistant Root Program