Resumen

  • RFC 9963 asigna tres valores *_legacy para que un servidor TLS 1.3 pida de forma explícita RSASSA-PKCS1-v1_5 a un certificado de cliente incapaz de producir una firma RSASSA-PSS compatible.
  • La excepción está acotada: solo sirve para CertificateVerify del cliente, nunca para CertificateVerify del servidor ni para certificados de servidor, y las implementaciones deberían dejarla desactivada por defecto.

RFC 9963, de David Benjamin y Andrei Popov, aborda una fricción de migración específica. TLS 1.3 retiró RSASSA-PKCS1-v1_5 de CertificateVerify a favor de RSASSA-PSS. La RFC indica que cierto hardware criptográfico del lado cliente, incluidos algunos TPM, puede no generar una firma PSS compatible. Así, la conexión puede haber elegido TLS 1.3 antes de fallar cuando el servidor solicita un certificado de cliente.

La respuesta no es normalizar de nuevo el esquema viejo. El documento define rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy y rsa_pkcs1_sha512_legacy. Esos valores existen únicamente para una firma en CertificateVerify del cliente, no para otros contextos. El alcance de un número es parte de su significado: describe lo que un extremo puede expresar en un mensaje concreto, no un permiso que cualquier participante TLS pueda deducir del nombre del algoritmo.

Las reglas de negociación vuelven la excepción comprobable. El cliente no debe anunciar esos valores en signature_algorithms del ClientHello ni aceptarlos en un CertificateVerify de servidor. Un servidor que quiera admitir una clave cliente solo heredada puede enviarlos en CertificateRequest y aceptar uno en la respuesta del cliente, pero no puede aceptar un valor que no ofreció. El cliente afectado puede negociar la ruta si se le ofrece. Si su clave admite PSS, no debería usar la alternativa heredada, aunque en algunas aplicaciones no sea práctico averiguarlo. Las implementaciones deberían desactivar los valores de inicio.

El límite para el servidor también es expreso. El problema de migración descrito no se aplica a claves de servidor. Los nuevos valores están prohibidos para certificados de servidor y PSS sigue siendo obligatorio en servidores TLS 1.3 que usan RSA. Tampoco hay rebaja en la comprobación: debe aplicarse RFC 8017, con el parámetro NULL obligatorio y DER válido, y el servidor debe rechazar firmas que no cumplan esas condiciones.

La evidencia sostiene una conclusión acotada: un cliente y un servidor pueden negociar deliberadamente una excepción etiquetada bajo condiciones conocidas. No demuestra qué TPM, navegador, biblioteca, empresa o servidor la ha desplegado; no certifica una sesión ni convierte el mecanismo en un resultado general de seguridad. El perfil IETF vincula a David Benjamin con el RFC y su sitio público aporta contexto profesional, no evidencia sobre sistemas de terceros.

Esa modestia es una cualidad del diseño. La presión de compatibilidad es real, pero la vía es explícita, direccional y revocable por defecto. Un operador puede conservar el motivo del cliente, la oferta del servidor, el resultado negociado y una condición de retirada. El código sigue siendo una herramienta de protocolo, no una historia completa de despliegue.

Sources