Zusammenfassung

  • RFC 9963 ordnet drei *_legacy-Werte zu, damit ein TLS-1.3-Server von einem Client-Zertifikat, das keine kompatible RSASSA-PSS-Signatur erzeugen kann, ausdrücklich RSASSA-PKCS1-v1_5 anfordern kann.
  • Die Ausnahme gilt nur für CertificateVerify des Clients: nie für CertificateVerify des Servers, nie für Serverzertifikate, und sie sollte standardmäßig deaktiviert sein.

RFC 9963 von David Benjamin und Andrei Popov behandelt eine eng begrenzte Migrationsreibung. TLS 1.3 hat RSASSA-PKCS1-v1_5 in CertificateVerify zugunsten von RSASSA-PSS entfernt. Die RFC verweist auf Client-seitige Kryptohardware, darunter manche TPMs, die möglicherweise keine TLS-1.3-kompatible PSS-Signatur erzeugt. Die Endpunkte können TLS 1.3 also bereits gewählt haben, bevor die Verbindung beim Anfordern eines Client-Zertifikats scheitert.

Die Antwort ist nicht, das alte Verfahren wieder zum Normalfall zu machen. Das Dokument definiert rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy und rsa_pkcs1_sha512_legacy. Diese Werte sind nur für Signaturen im Client-CertificateVerify definiert, nicht für andere Kontexte. Diese kleine Formulierung ist die Betriebsgrenze: Ein Codepoint beschreibt, was ein Endpunkt in einer bestimmten Nachricht ausdrücken darf; der Algorithmusname allein gibt keinem TLS-Teilnehmer eine allgemeine Erlaubnis.

Die Aushandlungsregeln halten die Ausnahme sichtbar. Ein Client darf die Werte weder in der signature_algorithms-Erweiterung des ClientHello ankündigen noch sie in einem Server-CertificateVerify akzeptieren. Ein Server, der einen Client mit ausschließlich altem Schlüssel unterstützen will, darf sie in CertificateRequest senden und eine solche Client-Antwort annehmen; er darf jedoch keinen Wert akzeptieren, den er nicht angeboten hat. Der betroffene Client darf den Weg nutzen, wenn er angeboten wird. Unterstützt sein Schlüssel PSS, sollte er nicht den alten Weg wählen, auch wenn sich das nicht immer praktisch feststellen lässt. Implementierungen sollten die Werte standardmäßig deaktivieren.

Auch die Servergrenze ist eindeutig. Das geschilderte Migrationsproblem gilt nicht für Serverschlüssel. Die neuen Werte sind für Serverzertifikate verboten, und PSS bleibt für TLS-1.3-Server mit RSA erforderlich. Die Ausnahme lockert zudem keine Implementierungsanforderung: RFC 8017 ist einzuhalten, der obligatorische NULL-Parameter und eine gültige DER-Codierung sind erforderlich, und der Server muss nichtkonforme Signaturen zurückweisen.

Die Belege erlauben damit nur einen präzisen Schluss. Ein Server und ein Client können unter genannten Bedingungen bewusst eine gekennzeichnete Kompatibilitätsausnahme aushandeln. Sie belegen nicht, dass ein bestimmtes TPM, ein Browser, eine Bibliothek, ein Unternehmen oder ein Server sie eingeführt hat; sie zertifizieren keine Sitzung und beweisen kein allgemeines Sicherheitsergebnis. Das IETF-Profil verbindet David Benjamin mit der RFC, und seine öffentliche Website liefert beruflichen Kontext, aber keinen Beleg über laufende Systeme Dritter.

Gerade diese Zurückhaltung ist der Nutzen des Entwurfs. Kompatibilitätsdruck ist real, doch der Pfad ist ausdrücklich, gerichtet und standardmäßig geschlossen. Ein Betreiber kann Client-Bedarf, Serverangebot, ausgehandeltes Ergebnis und Ausstiegskriterium festhalten. Der Codepoint bleibt dann ein genaues Protokollwerkzeug und kein Ersatz für eine vollständige Deployment-Erzählung.

Sources