Resumen

  • RFC 9963 asigna tres valores *_legacy a un único uso: el CertificateVerify de un cliente TLS 1.3 tras una oferta explícita en CertificateRequest.
  • El cliente no puede anunciarlos en ClientHello ni aceptarlos en una firma del servidor; el servidor no puede aceptarlos si no los ofreció. La configuración predeterminada debería deshabilitarlos.
  • Registro, oferta, capacidad de una clave y sesión autenticada son evidencias distintas. Ninguna concede por sí sola permiso sobre una aplicación o cambio.

La negociación no concede el mismo privilegio a ambos lados

TLS 1.3 sustituyó RSASSA-PKCS1-v1_5 por RSASSA-PSS para CertificateVerify. RFC 9963 atiende una dificultad concreta: ciertas claves de certificados de cliente guardadas en hardware heredado no producen una PSS compatible. El fallo puede descubrirse sólo después de negociar TLS 1.3, cuando el servidor pide de pronto autenticación de cliente.

La salida no consiste en bajar toda la política a TLS 1.2 ni en añadir un mecanismo de retroceso ajeno. El servidor que necesita admitir una clave cliente heredada puede incluir uno de los tres valores en el signature_algorithms de CertificateRequest. El cliente puede usarlo después en su propia firma. Si no existió esa oferta, el servidor debe rechazarlo.

El camino opuesto queda cerrado. El cliente no los anuncia en ClientHello y debe rechazarlos si el servidor intenta usarlos en su CertificateVerify. Para certificados RSA del servidor bajo TLS 1.3 sigue siendo obligatorio PSS. La dirección del mensaje define el alcance de la excepción; no basta con leer el nombre del algoritmo.

Guardar las piezas que el tablero suele mezclar

Un indicador llamado “RSA heredado” pierde precisamente la información de control. El registro IANA acredita que hay tres valores y que no son recomendados. La configuración y el CertificateRequest capturado acreditan que un servidor ofreció una excepción. El inventario de la clave acredita —o no— que esa clave cliente no puede firmar con PSS. La traza de la sesión acredita qué esquema se seleccionó y si la verificación terminó.

La forma de PKCS#1 también importa. RFC 9963 exige seguir la sección 8.2 de RFC 8017, con parámetro NULL obligatorio y DER válido; el servidor debe rechazar una firma que no cumpla. La excepción no permite convertir una implementación defectuosa en una firma aceptable.

Además, ninguna de esas pruebas equivale a autorización de negocio. Un certificado de cliente probado puede asociarse a una cuenta; la cuenta puede carecer de permiso para modificar una ruta, liberar un secreto o cambiar un servicio. La capa común define el intercambio criptográfico. El operador local conserva identidad, alcance y consecuencia.

Una excepción de migración necesita fecha de caducidad

Conservar la revisión de política, identificador de la clave, CertificateRequest, esquema elegido, resultado de validación, cuenta asociada y fecha prevista de retirada permite responder qué excepción sigue viva y por qué. Probar rechazo sin oferta, rechazo de uso servidor, DER erróneo y uso de PSS por una clave de sustitución impide que una compatibilidad temporal se vuelva una costumbre invisible.

El estándar hace transportable una forma limitada de entenderse. No decide cuánto tiempo debe mantenerse ni qué debe hacer el servicio después de aceptar la autenticación.