Zusammenfassung

  • Die Fassung 01 eines individuellen ACME-Internet-Drafts streicht das strenge Profil der Fassung 00. Dort mussten TLS-Server- und JWS-Anfrageauthentifizierung postquantenfest oder hybrid sein; ein Rückfall auf ausschließlich klassische Signaturen war ausgeschlossen.
  • Der neue Text würde ACME-Servern erlauben, ES256 nicht mehr zu implementieren. Nach RFC 8555 §6.2 ist es derzeit Pflicht. Bleibt ES256 erhalten, kann der Betreiber klassische JWS-Signaturen während einer selbst gewählten Übergangsfrist weiter annehmen.

Ein neuer Tunnel mit einer alten Zutrittskarte

Ein Zertifikatsdienst stellt die Verbindung zwischen Client und ACME-Server auf postquantenfesten oder hybriden Schlüsselaustausch um. Das schützt aufgezeichnete Nachrichten vor späterer Entschlüsselung. Ob der Client im Namen eines Kontos ein Zertifikat bestellen darf, prüft jedoch seine JWS-Signatur. Nimmt der Server dafür weiterhin eine rein klassische Signatur an, bleibt genau diese Zutrittskarte gültig. Die neue Leitung entscheidet nicht über die Autorisierung am Schalter.

Der Juni-Entwurf trennte einen strengen Betriebsmodus ab. In ihm mussten sowohl die Authentifizierung des TLS-Servers als auch die signierte Anfrage postquantenfeste oder hybride Verfahren verwenden. Ein klassischer Alleingang war verboten. Die Oktoberfassung löscht den Abschnitt. Sie beschreibt nur noch einen Quantum-Ready-Mechanismus mit TLS 1.3 oder neuer und postquantenfestem oder hybridem Schlüsselaustausch. Neue Authentifizierung wird unterstützt; eine ausschließlich klassische Variante darf während einer ausdrücklich begrenzten Übergangszeit bleiben. Den Endpunkt dieser Frist nennt der Entwurf nicht.

Der Hebel steckt in Abschnitt 4.2. Zuvor waren bestimmte ML-DSA-Varianten und eine zusammengesetzte Signatur für teilnehmende Server vorgeschrieben, ES256 ebenfalls. Nun darf der Server JWS-Algorithmen aus dem JOSE-Register wählen; ein bestimmter Algorithmus oder Parametersatz ist nicht mehr vorgeschrieben. Er dürfte ES256 ganz weglassen. Behält er es für alte Clients, darf er deren klassische Signaturen während seiner gewählten Übergangszeit akzeptieren. Zwei Dienste können denselben Mechanismus beanspruchen und dieselbe Anfrage unterschiedlich behandeln.

Eine Unstimmigkeit bleibt im Text selbst: Die Einleitung bezeichnet postquantenfeste und hybride Signaturen als verpflichtend zu implementieren. Abschnitt 4.2 verwendet dagegen „MAY“ und schließt eine Pflicht für einen bestimmten JWS-Algorithmus aus. Für einen gemeinsamen Konformitätstest muss diese Differenz geklärt werden. Das ist keine Frage der Markenbotschaft, sondern der erwarteten Serverantwort.

Der IETF-Datatracker führt die Veröffentlichung vom 28. Oktober als individuellen Entwurf, nicht als beschlossene Norm. Er enthält keinen Beleg für produktiven Einsatz und keinen branchenweiten Stichtag. Eine veröffentlichte Serverrichtlinie mit Tests für angenommene neue und abgewiesene alte Signaturen würde zeigen, welche Grenze tatsächlich gilt.

Quellen: Oktoberfassung; Junifassung; RFC 8555; IETF-Status.