Résumé

  • RFC 9963 crée trois valeurs *_legacy pour une seule scène: la signature CertificateVerify d’un client, après une proposition dans CertificateRequest.
  • Le client ne peut ni les annoncer dans ClientHello ni les accepter pour le serveur. Le serveur ne peut les accepter que s’il les a proposées; l’implémentation devrait les désactiver par défaut.
  • Valeur enregistrée, exception proposée, capacité réelle d’une clé client et session authentifiée sont quatre preuves séparées. Aucune ne devient une autorisation applicative.

L’exception commence là où le serveur pose une question

TLS 1.3 a remplacé RSASSA-PKCS1-v1_5 par RSASSA-PSS pour CertificateVerify. Certains anciens matériels protégeant des clés de certificats clients ne peuvent pourtant pas produire la signature PSS exigée. Le problème n’apparaît qu’assez tard: la version TLS est déjà choisie, puis le serveur demande une authentification client. Sans issue précise, une équipe pourrait désactiver TLS 1.3 pour tout le monde ou fabriquer un repli extérieur.

RFC 9963 ne choisit ni l’un ni l’autre. Il nomme trois valeurs, mais les enferme dans le message où le serveur précise les signatures client qu’il accepte. Un serveur peut les placer dans CertificateRequest; un client détenteur d’une clé seulement compatible PKCS#1 v1.5 peut alors en choisir une dans son CertificateVerify. Le serveur doit refuser une valeur qu’il n’avait pas proposée.

La réciproque est interdite. Le client ne les annonce pas dans ClientHello et ne les accepte pas dans le CertificateVerify du serveur. Pour les certificats de serveur RSA sous TLS 1.3, PSS demeure requis. Une valeur ne voyage donc pas librement avec le mot RSA: elle porte un sens lié au sens de la preuve et au message qui l’a appelée.

Une étiquette unique effacerait les preuves utiles

Écrire « RSA historique activé » sur un tableau de bord efface quatre questions différentes. Le registre IANA montre qu’une valeur existe et qu’elle n’est pas recommandée. La configuration du serveur et le CertificateRequest conservé montrent si l’exception a été offerte. L’inventaire de clé établit si la clé client concernée ne sait réellement pas faire PSS. La trace de poignée de main montre enfin si cette valeur a été choisie et validée.

Ces dossiers n’ont pas le même propriétaire. La norme fournit le vocabulaire commun. L’opérateur décide d’ouvrir une exception sur un écouteur précis. Le détenteur de la clé répond de son inventaire et de son remplacement. Le propriétaire du service décide des droits du compte après authentification. Une signature client valide ne tranche pas à leur place.

Même la compatibilité doit respecter la forme exacte. RFC 9963 renvoie à la section 8.2 de RFC 8017: paramètre NULL obligatoire, DER valide, rejet par le serveur lorsque ces conditions ne sont pas réunies. « Héritage » ne signifie pas « tolérance indéfinie ».

Préparer la sortie en même temps que l’entrée

Le bon dossier d’exception lie la révision de politique du serveur, l’identifiant de la clé client, le CertificateRequest exact, le schéma choisi, le résultat de validation, le compte associé et la date d’extinction. Il teste aussi les refus: valeur non proposée, tentative côté serveur, DER mal formé et clé qui sait déjà signer en PSS.

Ainsi, l’interopérabilité reste réversible. Le texte commun décrit une passerelle technique; il ne décide ni de la durée de confiance accordée à un client ni de la permission d’exécuter une opération après la poignée de main.