Resumen

  • La RFC 6916 coordina el cambio entre autoridades certificadoras, puntos de publicación y sistemas que validan el RPKI; no lo trata como una simple actualización de software.
  • Su migración descendente conserva productos firmados bajo los algoritmos antiguo y nuevo durante una ventana de transición y fija hitos para los validadores antes de retirar el primero.
  • El documento prevé varios años de trabajo y no especifica una transición de emergencia. Sirve para un cambio planificado, no para resolver por sí solo una ruptura criptográfica repentina.

Cambiar la criptografía cambia una cadena

En el RPKI, cada declaración firmada forma parte de una jerarquía. Una autoridad certificadora (CA) certifica a otra situada debajo; esta puede emitir certificados y objetos firmados para recursos en niveles posteriores. Un validador o relying party (RP) recupera el material publicado y comprueba la cadena. Después, los operadores pueden incorporar esos resultados a sus políticas de encaminamiento.

Son pasos diferentes. La emisión de un certificado no demuestra que todos los repositorios hayan publicado sus objetos correspondientes. La publicación no demuestra que cada RP pueda validarlos. Y el resultado de una validación tampoco determina por sí solo lo que aceptará un router: esa decisión depende de la política del operador. La pregunta de la RFC 6916 era cómo cambiar el conjunto criptográfico sin perder un camino utilizable entre todas esas funciones.

La RFC 6916, «Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)», se publicó en abril de 2013 como buena práctica BCP 182. Sus autores son Roque Gagliano, Stephen Kent y Sean Turner. Es un documento de consenso del IETF, no una orden personal de ninguno de ellos. RFC 6916

Primero el calendario, después el algoritmo

La RFC 6916 no elige el algoritmo siguiente. En 2013 exigió actualizar el perfil del RPKI definido entonces por la RFC 6485 y publicar, además, un calendario de transición. La RFC 7935 reemplazó posteriormente a la RFC 6485 y contiene el perfil consultado en las fuentes actuales. Por eso una transición futura tendría que actualizar el perfil aplicable, no limitarse a añadir una etiqueta nueva a un certificado. RFC 7935

El calendario debe fijar cinco fechas: cuándo las CA tienen que estar listas para emitir con el nuevo conjunto, cuándo deben haber vuelto a emitir sus productos, cuándo deben estar listos los RP, cuándo el algoritmo antiguo pasa a ser opcional y cuándo llega su fin de vida. La RFC sitúa cada hito un minuto después de la medianoche UTC y pide métricas de preparación para CA y RP. El tiempo pasa a ser una propiedad operativa del sistema de confianza: repositorios, validadores y certificados deben poder usar la versión correcta en el momento previsto.

También hay que separar el cambio de algoritmo del reemplazo de una clave. La RFC 6489 describe la renovación de una clave CA cuando no cambia el conjunto de algoritmos. La RFC 6916 aborda un cambio más profundo, que afecta a certificados, listas de revocación, manifiestos y objetos firmados. No se debe asumir que el procedimiento de renovación de una clave resuelve esa migración. RFC 6489

Por qué la migración empieza arriba

La secuencia es descendente. Una CA hija no puede pedir un certificado del nuevo conjunto hasta que su CA madre pueda emitirlo. La RFC también evita certificados de CA cuyo algoritmo de firma y cuya clave de sujeto pertenecen a conjuntos distintos. Una migración sin ese orden exigiría manejar certificados mixtos y una estructura de repositorios más compleja; el documento advierte que podría hacer crecer los repositorios de forma exponencial.

La jerarquía funciona aquí como superficie de control. La preparación de una CA madre condiciona a las entidades que dependen de ella; no pueden saltarse esa relación. La norma hace visible el orden —preparar, emitir, comprobar los validadores y retirar el conjunto antiguo— sin afirmar que exista un actor central capaz de obligar a todos a cambiar simultáneamente.

Publicar en paralelo compra tiempo

El proceso mantiene el algoritmo antiguo mientras introduce y prueba el nuevo. En la fase 0 solo se admite el conjunto vigente. La fase 1 empieza en la fecha de preparación de las CA: las autoridades no terminales deben poder procesar solicitudes con el conjunto nuevo, pero los RP siguen usando el antiguo en producción. Los productos nuevos pueden publicarse para pruebas, idealmente en puntos distintos.

La fase 2 comienza en la fecha de inicio de las CA. Cada conjunto de productos firmados debe estar disponible con ambos algoritmos. Los RP pueden probar la nueva versión y conservar la anterior. Los resultados correspondientes —por ejemplo, los datos de autorización de origen que contienen los ROA— deberían coincidir, salvo diferencias de sincronización. Si faltan muchas CA, hay que volver a publicar el calendario. La preparación de los RP aún no es obligatoria, pero un problema de validación puede justificar el retraso del siguiente hito.

En la fase 3, todos los RP deben poder validar el algoritmo nuevo y se recomienda que lo prefieran mientras se mantienen ambas versiones. La fase 4 arranca en la fecha Twilight: las CA y los RP deben usar el nuevo conjunto; los productos antiguos pueden seguir disponibles, pero ya no se garantiza que estén completos. En el fin de vida, el conjunto antiguo se retira y sus localizadores de ancla de confianza deben desaparecer de los puntos de publicación. RFC 6916, secciones 4 y 10

La alternativa de respaldo tiene plazo. Un RP que todavía no valida los productos nuevos puede seguir usando los antiguos mientras el estándar los exige y existen. No se promete que ambas versiones convivan para siempre: es una ventana limitada para probar, comparar y detectar retrasos antes de retirar el camino anterior. RFC 6481

El riesgo se reparte

La RFC describe un posible fallo en cada extremo. Si una CA no termina la migración antes del fin de vida del algoritmo antiguo, sus productos firmados dejan de ser válidos. Si un RP no migra, pierde la capacidad de validar los productos del nuevo conjunto. Eso puede producir una visión incompleta de la información RPKI relevante para el encaminamiento.

No significa que desaparezcan todas las rutas. Los RP generan resultados de validación; los operadores y routers deciden cómo utilizarlos. Un objeto ausente o inválido puede influir en la validación del origen, pero el efecto final depende de la política local, el software y los recursos implicados. El estándar identifica el riesgo de una validación incompleta, no cuantifica una caída ni impone un resultado universal de rechazo.

El calendario conservador también muestra un límite. El resumen de la RFC prevé varios años de transición y dice expresamente que no especifica una respuesta de emergencia. Esa elección encaja con un cambio planeado que necesita implementaciones y publicación compatibles. Pero deja sin resolver otra pregunta: ¿qué ocurre si el algoritmo o una clave deja de ser seguro antes de que termine el ciclo? La RFC 6916 no define ese procedimiento de crisis.

El lugar de Gagliano en el registro

El perfil público de Cisco presenta a Gagliano como Principal Solutions Engineer y señala que antes ocupó funciones de ingeniería y arquitectura en LACNIC, ANTEL y Sprint. Ese recorrido lo sitúa entre operadores, un registro regional y un proveedor, pero no demuestra por qué apoyó una cláusula concreta. La RFC permite una afirmación más precisa: Gagliano coescribió una práctica consensuada que convierte la preparación de toda la cadena RPKI en una condición de la migración. Perfil de Cisco

El perfil consultado en la RFC 7935 especifica RSA con clave de 2.048 bits y SHA-256. En 2026, un Internet-Draft informativo estudia candidatos poscuánticos y estructuras de migración, incluida la publicación paralela y un árbol mixto. Sus autores aclaran que el texto no actualiza las RFC 7935 ni 6916, no elige un perfil de producción y no autoriza las opciones evaluadas para el RPKI operativo. Son preguntas de investigación, no prueba de que se haya aprobado o programado una migración de producción. RFC 7935; draft-yoshikawa-sidrops-pqc-rpki-02

La contribución duradera de la RFC 6916 es procedimental. Convierte «adoptar un algoritmo más robusto» en dependencias observables: las CA deben emitir, los repositorios publicar productos correspondientes, los RP validarlos y la ruta antigua seguir disponible hasta comprobar la preparación. También hace visibles las preguntas que no responde: cómo medir la preparación, qué hacer con participantes rezagados y cómo distinguir una emergencia de una migración planificada. Ahí comienzan las siguientes decisiones de operadores y responsables de estándares.