Resumen

  • RFC 9763 permite demostrar ante una autoridad de certificación el control de la clave privada de un certificado previo y grabar en el nuevo certificado el hash del certificado previo completo.
  • La extensión expresa una relación de emisión. No obliga a usar las dos credenciales, no prueba que ambas claves actuaron en la sesión y no dicta si basta una autenticación o deben superar las dos.
  • Para gobernar una migración hay que conservar por separado la prueba de registro, la política de la autoridad, los bytes exactos de cada certificado, las pruebas actuales, la negociación y la decisión del extremo.

El programa de migración llegó al cien por cien. Todas las cargas de trabajo tenían un certificado tradicional, un certificado postcuántico y una relación registrada entre ambos. El comité cerró el hito. Meses después, la telemetría reveló que la mayoría de las sesiones seguía usando solo el algoritmo tradicional.

No había contradicción técnica. El inventario medía emisión y asociación. El tráfico medía uso. Entre ambos quedaban la negociación, las anclas de confianza, la verificación de firmas, la política del receptor y la decisión de continuar la conexión.

La RFC 9763, Related Certificates for Use in Multiple Authentications within a Protocol, es valiosa precisamente porque no borra esa distancia. Define un atributo de solicitud, relatedCertRequest, y una extensión X.509, RelatedCertificate. El conjunto aporta seguridad adicional de que dos certificados de entidad final pertenecen a la misma entidad. No ejecuta por sí mismo ninguna función de seguridad.

Lo que ocurre en el registro

El punto de partida es un Certificado A ya emitido. Su titular solicita un Certificado B, quizá para combinar una clave tradicional con otra postcuántica sin abandonar inmediatamente los usos existentes. La petición del nuevo certificado lleva su propia clave pública. En PKCS#10, según la RFC 2986, la firma de la información de solicitud demuestra la posesión de la clave privada correspondiente a esa nueva clave pública.

El atributo de RFC 9763 añade una prueba referente a A. Incluye el emisor y número de serie de A, la hora de la solicitud, una ubicación y una firma. El solicitante firma con la clave privada de A la concatenación codificada en DER del identificador de A y el valor temporal.

La hora usa BinaryTime, definido en la RFC 6019 como segundos desde el comienzo del 1 de enero de 1970 UTC, sin segundos intercalares. Ese formato es compartido y verificable. La antigüedad máxima aceptable queda fuera del estándar y pertenece a la política local de la autoridad.

Por eso un registro de auditoría necesita algo más que fresh=true. Debe conservar la hora recibida, la hora de decisión, el límite aplicado y la versión de política. Dos autoridades pueden aceptar ventanas diferentes sin que ninguna interprete mal el formato.

La autoridad no verifica una sola cosa

Si admite el atributo, la autoridad debe obtener A desde la ubicación indicada y validar su ruta con las reglas de la RFC 5280. Después compara emisor y número de serie, comprueba la frescura conforme a su política y verifica la firma del atributo con la clave pública de A.

Son cuatro superficies de fallo. Puede llegar el objeto equivocado. La ruta puede terminar en una ancla no aceptada. El identificador puede no coincidir. La prueba puede ser demasiado antigua o la firma incorrecta. Un único mensaje de “relación inválida” impide distinguir un ataque de sustitución, un problema de repositorio, una discrepancia de confianza o un reloj fuera de tolerancia.

La RFC 5280 deja claro que la validación de ruta recibe anclas y políticas como entradas. Su algoritmo fija condiciones mínimas, pero una aplicación puede ser más restrictiva. También exige procesar de manera independiente los usos de clave y los usos extendidos cuando aparecen juntos.

Al emitir B, la autoridad puede insertar la extensión de relación. Solo debe referenciar el certificado que figuraba en la petición. A debe contener los bits de uso y los OID de uso extendido que se afirman en B. La autoridad debería determinar que A es válido en ese instante.

No obstante, el suscriptor conserva la responsabilidad por el solapamiento útil de las dos vigencias. Si A caduca mañana y B dura un año, la relación no regala once meses de autenticación dual. Si A se renueva con otros bytes, el nuevo certificado no sustituye automáticamente al que B nombró.

El hash cierra una identidad exacta

RelatedCertificate contiene un identificador de algoritmo de resumen y el hash del Certificado A entero. No es un hash del nombre de sujeto ni solo de la clave pública. Es la huella de una emisión concreta, con su serie, vigencia, extensiones y firma.

El receptor puede calcular localmente la huella de A y compararla con B. Esa operación es determinista: o son los bytes relacionados o no lo son. No hace falta consultar una autoridad en línea. Este es el valor de una capa común estrecha.

Pero la misma exactitud castiga los atajos de inventario. Dos certificados con el mismo nombre y la misma clave pueden ser distintos si uno fue reemitido. Agruparlos por “identidad del cliente” no demuestra que el hash de B apunte a la versión desplegada. La observabilidad debe trabajar con huellas de artefactos, no solo con etiquetas humanas.

La extensión no debería marcarse como crítica porque rompería la interoperabilidad con software que no la entiende. Solo puede estar en certificados de entidad final. Un cliente antiguo puede ignorarla y seguir procesando el certificado; eso permite transición, pero también obliga a distinguir compatibilidad de verificación. La ausencia de error no demuestra que se comprobó la relación.

El receptor conserva la política

Cuando un protocolo admite autenticaciones múltiples y llegan A y B, el extremo busca la extensión, calcula el hash de A y lo compara. A partir de ahí, RFC 9763 no decide el resultado. Cada par puede exigir que triunfen las dos autenticaciones o aceptar al menos una.

En CMS y S/MIME, el firmante elige qué claves usar según los verificadores previstos. En protocolos negociados, el receptor puede expresar preferencias. La RFC 5652 define Cryptographic Message Syntax y la RFC 8551 describe el transporte de certificados S/MIME utilizado por el mecanismo. Ninguna sintaxis convierte la relación en permiso de aplicación.

El estándar dice que no existe requisito ni mandato de usar un certificado con el otro. Solo aporta seguridad de que pueden emplearse juntos porque la misma entidad controla las claves. También advierte que los mecanismos se limitan a expresar una relación y no producen por sí mismos una función de seguridad.

Eso coloca la decisión donde se materializa el riesgo. La autoridad responde por la comprobación de registro y la afirmación que firmó. El extremo responde por las credenciales recibidas, las rutas que confía, las firmas de la sesión y la política que aplica. Una extensión no puede asumir esa responsabilidad en su nombre.

Control histórico y control actual

Una arquitectura híbrida necesita evidencia de control de todas las claves en dos momentos: durante el registro ante la autoridad y durante el uso ante el verificador. El primer momento no sustituye al segundo.

La firma de A sobre relatedCertRequest prueba una acción en el proceso de registro. La solicitud ordinaria prueba el control de la clave nueva dentro de su modelo. La extensión conserva la asociación emitida. Años después, una sesión tiene que mostrar las firmas o pruebas que exija el protocolo actual.

La mera presencia de B no demuestra que su clave privada participó. Dos firmas recibidas tampoco bastan si el software valida una sola. Dos validaciones matemáticas no bastan si una ruta termina en una ancla ajena a la política local. Y una relación correcta no evita que la negociación haya degradado el intercambio antes de presentar el método fuerte.

La diferencia con la RFC 9883 es importante. RFC 9883 permite que una clave de firma ya certificada emita una declaración sobre la posesión de otra clave de establecimiento sin prueba técnica de esa otra posesión. RFC 9763 exige una firma real de A y, en el flujo ordinario, una solicitud firmada para B; después relaciona certificados exactos. Aquí no se analiza una declaración que reemplaza una prueba, sino una prueba de registro que no debe convertirse en prueba de sesión.

La RFC 9955 se ocupa de propiedades y reglas de verificación de firmas híbridas. RFC 9763 no prescribe un combinador. Entrega un dato de relación para que un protocolo aplique una regla independiente.

Cambiar de autoridad cambia el problema

Una sola organización de certificación puede conocer su repositorio y sus anclas. Si B se solicita a otra organización, esta quizá no pueda validar A. RFC 9763 admite que hagan falta contratos previos, anclas preconfiguradas y acuerdos sobre solicitud, emisión y aceptación.

La nueva autoridad debe considerar políticas de certificación comparables. Haber demostrado que una entidad controla dos claves no demuestra que ambas se generaron, protegieron o revocaron bajo garantías equivalentes. La relación de sujeto y la equivalencia de política son preguntas distintas.

La gobernanza debe registrar quién aprobó la ancla externa, qué política de A se observó, con cuál política de B se comparó y cuándo caduca el acuerdo. De otro modo, una migración criptográfica puede crear una dependencia contractual opaca que nadie sabe retirar.

Una ubicación firmada aún puede ser hostil

El atributo indica dónde obtener A. Para una misma organización puede usarse HTTP(S) con un mensaje CMS de solo certificados. Entre organizaciones, el RFC recomienda una URL data: con los certificados y datos de revocación necesarios. La RFC 2397 define ese esquema.

Firmar una URL no vuelve seguro su contenido. El recurso puede ser malicioso y debe analizarse, comprobarse y validarse por completo. Además, una consulta de red puede ser observada y revelar que una autoridad está relacionando una petición con un certificado concreto. La carga embebida reduce esa exposición, no elimina el deber de validar.

Conviene retener el tipo de ubicación, el hash de lo recuperado, el resultado de análisis, las CRL o estados usados y la ruta construida. El certificado B emitido no permite reconstruir todos esos insumos.

El riesgo de degradación queda fuera

Todo despliegue híbrido puede sufrir degradación si un adversario oculta la compatibilidad con el algoritmo más fuerte. La extensión solo se procesa cuando el certificado ya llegó. No prueba qué capacidades se anunciaron ni qué partes de la negociación fueron protegidas.

El control debe estar en la política mínima del extremo, la transcripción autenticada cuando el protocolo la ofrece, la telemetría del modo seleccionado y las alertas ante retrocesos. Contar pares relacionados no equivale a contar sesiones híbridas.

La primacía del código en ejecución de Heng Lu ayuda a leer el estándar sin inflarlo. La especificación inicial mínima, la decisión futura localizada y la adopción voluntaria justifican una huella común y verificable, pero mantienen la aceptación en quien ejecuta el protocolo. Publicar una extensión no obliga a desplegarla.

Las capas de realidad completan el modelo: registro, emisión, coincidencia de hash, firma actual, ruta de confianza, autorización y efecto de servicio son registros relacionados, no sinónimos.

Un expediente que pueda reproducirse

En el alta deben guardarse la CSR exacta, el identificador de A, hora, ubicación, bytes firmados, verificación de firma y datos de ruta. En la emisión, los bytes de A, su hash, los bytes de B, la comparación de usos, la política aplicada y el cálculo de vigencias.

En la operación, deben quedar los certificados realmente recibidos, ambas rutas, el hash recalculado, las pruebas criptográficas que sí ocurrieron, el modo negociado, la versión de política, la decisión y el estado final. La separación permite saber si falló el registro, el transporte, la confianza, la sesión o la aplicación.

Fuentes