Resumen

  • El reloj de aceptación de treinta días del RFC 9691 comienza con la primera verificación satisfactoria de cada validador, no con una fecha mundial de publicación.
  • La prueba de una transición exige unir TAK recíprocos, observaciones continuas, equivalencia de repositorios, raíz realmente usada, rezagados con TAL antiguo y retiro de la clave previa.

Un Trust Anchor Locator contiene la clave pública de una Autoridad de Confianza RPKI y los URI de su certificado. Según el RFC 8630, ese dato inicia la validación. Su utilidad histórica también era una restricción: se podía reexpedir el certificado mientras la clave siguiera igual, pero sustituir la clave requería cambiar la confianza local.

El RFC 9691 crea un objeto TAK firmado. La clave A publica a B como sucesora; B publica a A como predecesora. El validador recorre B, valida su TAK, exige que el current de B sea el successor anunciado por A y que el predecessor de B sea A. No basta una etiqueta ni un solo objeto.

La relación recíproca demuestra una ruta de transición coherente. No demuestra que la población la haya visto. Tampoco revela qué validadores actualizan automáticamente su configuración, cuáles sólo avisan a una persona y cuáles desconocen el formato.

La primera observación es parte de la autoridad

Cuando un validador verifica por primera vez la misma oferta B después de una ejecución satisfactoria que no la contenía, inicia su propio temporizador de treinta días. A continúa como raíz de producción. B se prueba, pero todavía no gobierna la validación normal.

Si el sucesor deja de validarse o desaparece, el temporizador se cancela. Si cambia la clave o el conjunto de URI, comienza otro episodio. Al expirar el reloj local tras observaciones coherentes, ese validador puede actualizar su clave corriente y reiniciar la validación desde B.

Por eso no existe “el día 30” de toda la red. Una instancia siempre encendida, otra detenida por mantenimiento y una instalación fría empiezan en momentos distintos. Un cliente sin TAK no empieza nunca. El registro correcto conserva identificador y versión del validador, TAL local, huellas A y B, URI, validación recíproca, primera observación, ejecución previa, cancelaciones, vencimiento y clave de producción elegida.

El RFC desaconseja retirar B y volver a publicarla sin cambios. Un validador que no vio el intervalo ausente podría conservar el reloj viejo y migrar antes. Cambiar los URI del sucesor obliga a reiniciar el contador incluso si se mantiene el mismo SubjectPublicKeyInfo. La historia no es metadato ornamental: decide cuándo cambia la confianza.

La equivalencia se opera, no se firma una vez

Durante la transición, la TA mantiene dos pares de claves porque los clientes antiguos pueden seguir anclados en A. Cada par debe publicar bajo un directorio distinto. Salvo los propios TAK, los certificados de CA, recursos y delegaciones deben producir el mismo resultado de validación.

Con un único servidor de publicación, las operaciones RFC 8181 de ambos lados van en una sola consulta. Con varios servidores puede existir una brecha breve. Una reducción o revocación no rige plenamente hasta llegar a todos los puntos; una ampliación no debe comunicarse al hijo hasta que todas las ramas estén listas.

Por tanto, dos TAK válidos no prueban que los repositorios sean equivalentes. Hace falta comparar los conjuntos validados bajo A y B, sus generaciones, manifestes, CRL y delegaciones. La igualdad relevante es semántica: las rutas de publicación pueden diferir, pero una misma asignación no debe aparecer válida desde una raíz e inválida desde la otra.

Retirar A convierte silencio en decisión

El procedimiento tiene cuatro fases. Primero se demuestra que A puede mantener un TAK. Después se crea B y el enlace recíproco. Luego se distribuye un TAL B mientras A sigue sirviendo a los clientes sin transición automática. Por último se vacía el repositorio A y se destruye su clave privada.

En la tercera fase, URI distintos en TAL y TAK pueden ayudar a estimar qué camino usó un cliente. No entregan un censo. Una ausencia puede ser migración, caché, parada, paquete actualizado o fallo. El artículo de APNIC de julio de 2025 explicaba que los RIR investigaban el trabajo de implantación bajo el programa RPKI de la NRO; eso es contexto de planificación, no prueba de soporte universal.

En la cuarta fase, un validador que sólo conserva A ya no puede recorrer la infraestructura para aprender B. Necesita una reparación local. Si perdió varias generaciones, cada salto puede implicar otro periodo de treinta días. Mantener A evita ese corte, pero conserva poder criptográfico antiguo. El retiro requiere un umbral explícito de rezagados y no puede derivarse de un calendario.

El TAK tampoco cura una clave raíz comprometida. Quien controla A ya controla la firma del camino. Una conversión externa de TAK a TAL mueve la confianza al distribuidor si el objeto no está anclado en una TA que el validador ya acepta.

Los RFC 6487, 6488, 9286 y 6481 fijan certificados, objetos, manifestes y repositorios. El RFC 9319 queda aguas abajo: migrar la raíz no demuestra la política del router ni el viaje de un paquete.

La especificación mínima de Lu Heng permite un mecanismo común y decisiones locales visibles. Su modelo de capas separa anuncio firmado, estado ejecutado, salida validada y efecto operativo. La primacía del código exige mirar el estado de cada validador, no atribuir voluntad colectiva a la página del calendario.

Fuentes