Résumé

  • RFC 9963 attribue trois valeurs *_legacy afin qu’un serveur TLS 1.3 puisse demander explicitement une signature RSASSA-PKCS1-v1_5 à un certificat client qui ne sait pas produire une signature RSASSA-PSS compatible.
  • Cette possibilité est bornée : elle concerne uniquement CertificateVerify côté client, jamais une vérification côté serveur ni un certificat serveur, et elle doit être désactivée par défaut.

RFC 9963 de David Benjamin et Andrei Popov traite d’une rupture de migration très localisée. TLS 1.3 a remplacé RSASSA-PKCS1-v1_5 dans CertificateVerify par RSASSA-PSS. Certaines clés côté client — la RFC cite notamment des TPM — ne produisent pas forcément une signature PSS compatible. Le choix de TLS 1.3 peut alors précéder l’échec, lorsque le serveur demande ensuite l’authentification du client.

Le texte ne remet pas l’ancien mécanisme dans le régime ordinaire. Il crée trois valeurs explicitement nommées rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy et rsa_pkcs1_sha512_legacy. Elles ne signifient quelque chose que dans la signature CertificateVerify du client. Elles ne sont définies dans aucun autre contexte. Ce détail est essentiel : un numéro de registre décrit une possibilité dans un message donné ; il ne donne pas à tous les acteurs TLS une licence déduite du seul nom de l’algorithme.

La négociation garde l’exception visible. Le client ne doit ni annoncer ces valeurs dans signature_algorithms de ClientHello ni les accepter dans un CertificateVerify de serveur. Un serveur qui choisit d’aider une clé client strictement ancienne peut les proposer dans CertificateRequest, puis accepter la réponse du client, mais seulement s’il les a proposées. Le client concerné peut les négocier quand elles sont offertes. S’il sait employer PSS, il ne devrait pas choisir cette voie, même si cette capacité n’est pas toujours simple à déterminer. Les implémentations devraient laisser ces valeurs désactivées par défaut.

La limite côté serveur ne souffre pas d’ambiguïté. Le problème de migration visé ne concerne pas les clés de serveur. Les nouvelles valeurs sont interdites pour les certificats serveur et PSS demeure exigé pour un serveur TLS 1.3 utilisant RSA. L’exception n’allège pas non plus l’exigence de mise en œuvre : RFC 8017 doit être respectée, avec le paramètre NULL obligatoire et un encodage DER valide ; le serveur doit refuser une signature non conforme.

Les sources permettent donc une conclusion sobre. Un serveur et un client peuvent négocier intentionnellement une exception marquée, dans les conditions annoncées. Elles ne prouvent pas l’adoption par un TPM, un navigateur, une bibliothèque ou un parc donné ; elles ne certifient pas une session et ne démontrent pas un résultat de sécurité général. Le profil IETF relie David Benjamin à la RFC et son site public fournit un contexte professionnel, non une preuve sur les systèmes d’autrui.

La valeur de la solution est précisément cette retenue. La pression de compatibilité existe, mais l’exception est directionnelle, explicite et désactivée par défaut. Un opérateur peut consigner le besoin client, l’offre du serveur, l’usage négocié et une condition de sortie. Le code point reste alors un outil de protocole exact, non le récit complet d’un déploiement.

Sources