Resumen

  • RFC 9691 permite anunciar una clave sucesora mediante un TAK, pero el RP sigue validando con la clave actual durante un plazo de aceptación de 30 días.
  • La adopción exige verificar la relación entre predecesora y sucesora y observar que las claves y URL permanezcan estables.
  • El cambio de un RP no demuestra que toda la población haya migrado.

El TAL de RFC 8630 indica dónde obtener el certificado de la autoridad de confianza y contiene la clave pública con la que el relying party verifica que ese certificado autofirmado es el correcto. Es un punto de confianza distribuido fuera de banda. Por eso cambiar la clave no equivale a sustituir un objeto corriente del repositorio.

RFC 9691 incorpora el objeto firmado TAK. Puede incluir la clave actual y las URL de su certificado, además de una clave sucesora y sus ubicaciones. El RP no adopta la sucesora por verla publicada. Primero valida bajo esa clave y comprueba dos referencias: el TAK inicial debe nombrar la sucesora, y el TAK de la sucesora debe nombrar la actual como predecesora.

Cuando esa comprobación tiene éxito por primera vez, comienza un plazo de 30 días. Durante él, el RP continúa la validación de producción con la clave actual y comprueba en ejecuciones posteriores que las claves y URL anunciadas no hayan cambiado. Si la sucesora desaparece o deja de verificarse, se cancela el plazo. El cambio solo llega al vencer el temporizador conforme al procedimiento.

El operador puede, por tanto, haber publicado correctamente una sucesora sin que un RP concreto la haya visto. Otro RP puede haber iniciado su plazo, y un tercero puede haber completado el cambio. Cada hecho tiene alcance propio. Ninguno permite afirmar que todos los validadores han convergido.

Además, los clientes que no procesan TAK siguen utilizando la clave de su TAL o configuración manual. RFC 9691 contempla que el operador mantenga durante un tiempo pares de claves anteriores y repositorios separados. Un cliente TAL antiguo y un RP moderno que todavía espera no son el mismo riesgo ni requieren la misma acción.

RFC 6489 ofrece una disciplina complementaria: crea una nueva instancia de CA, publica certificado, CRL y manifiesto, deja un periodo de preparación, reedita productos y después retira la instancia anterior. RFC 6916 separa hitos parecidos para una migración de algoritmos: preparación de CA, reedición, preparación de RP, ocaso y fin de vida.

El registro de aceptación debe enlazar huellas de las claves, URL, hashes de ambos TAK, primera verificación, inicio y continuidad del plazo, momento del cambio, identidad y versión del validador. En otra línea debe documentar qué cohortes siguen con TAL, por qué se conserva la clave anterior y qué decisión autoriza retirarla.

Este registro es una inferencia editorial de gobernanza. No se atribuye a las RFC un formato de auditoría que no prescriben, ni se convierte una muestra de validadores en una afirmación universal.

Fuentes