Zusammenfassung

  • RFC 9963 definiert drei *_legacy-Werte allein für das Client-CertificateVerify, nachdem sie im CertificateRequest angeboten wurden.
  • Ein Client darf sie nicht im ClientHello ankündigen und nicht vom Server akzeptieren; ein Server darf sie ohne eigenes Angebot nicht akzeptieren. Standardmäßig sollen sie aus sein.
  • Register, Angebot, Schlüsselfähigkeit und authentisierte Sitzung sind getrennte Nachweise. Keiner davon verleiht Anwendungs- oder Änderungsbefugnis.

Die Ausnahme folgt der Nachrichtenrichtung

TLS 1.3 hat RSASSA-PKCS1-v1_5 bei CertificateVerify durch RSASSA-PSS ersetzt. Manche alte, hardwaregeschützte Client-Zertifikatsschlüssel können jedoch keine passende PSS-Signatur erzeugen. Der Fehler wird oft erst sichtbar, wenn TLS 1.3 schon ausgehandelt ist und der Server anschließend Client-Authentisierung anfordert.

RFC 9963 schafft dafür keinen allgemeinen Rückweg. Ein Server darf einen der drei Werte in signature_algorithms seines CertificateRequest anbieten. Erst dann darf der betreffende Client ihn in seiner eigenen Signatur verwenden; erst dann darf der Server ihn annehmen. Ohne Angebot ist die Annahme verboten.

Der umgekehrte Weg bleibt geschlossen. Der Client kündigt die Werte nicht im ClientHello an und muss sie im CertificateVerify des Servers zurückweisen. Für RSA-Serverauthentisierung in TLS 1.3 bleibt PSS erforderlich. Die gleiche Abkürzung „RSA“ macht aus einer clientseitigen Ausnahme keine serverseitige Berechtigung.

Ein grünes Feld verdeckt vier unterschiedliche Fragen

Der IANA-Eintrag belegt, dass ein Wert definiert und nicht empfohlen ist. Die Serverkonfiguration samt aufgezeichnetem CertificateRequest belegt ein lokales Angebot. Die Schlüsselinventur belegt, ob dieser Client-Schlüssel tatsächlich kein PSS kann. Das Handshake-Protokoll belegt Auswahl und Verifikation. Diese Nachweise sollten nicht zu „Legacy RSA aktiv“ verschmolzen werden.

Auch die Kodierung bleibt kontrollpflichtig. RFC 9963 verlangt RFC 8017 Abschnitt 8.2, einen obligatorischen NULL-Parameter und gültiges DER; fehlerhafte Signaturen muss der Server verwerfen. Kompatibilität ersetzt keine korrekte Prüfung.

Nach der Kryptographie folgen weitere lokale Entscheidungen: Kontozuordnung, Rechte, angeforderte Operation, Freigabe und Rücknahme. Eine bestätigte Client-Signatur beantwortet nur ihre eigene Frage.

Ausnahme und Ausstieg zusammen verwalten

Eine brauchbare Akte verknüpft Policy-Revision, Schlüsselkennung, genaues CertificateRequest, gewählten Wert, Prüfergebnis, Konto und Abschaltdatum. Tests ohne Angebot, mit Serververwendung, mit fehlerhaftem DER und mit PSS-fähigem Ersatzschlüssel halten die Ausnahme begrenzt. Der gemeinsame Standard beschreibt dann eine überprüfbare Brücke, nicht eine dauerhafte Vertrauensentscheidung.