Resumen

  • La hoja de ruta de la NRO, modificada en diciembre de 2025, consideraba esenciales los certificados TA de corta duración; APNIC, ARIN y LACNIC aparecían como proveedores y la meta para todos los RIR era el final de 2025.
  • El 29 de agosto de 2026, el TAL publicado por AFRINIC seguía recuperando un certificado raíz autofirmado válido desde el 30 de marzo de 2020 hasta el 28 de marzo de 2030.
  • El contraste señala una cadena pública incompleta, no una caída del servicio: las fuentes no definen el máximo de «corta duración» ni prueban fallo de validación, ruta inválida o incidente criptográfico.
  • Una constancia de entrega debe unir definición, emisión, continuidad de la clave del TAL, publicación, observaciones de actualización, excepciones, reversión y correcciones.

La hoja de ruta terminó donde debía empezar la verificación

La promesa aparece en una sola fila. La función se llama «Short-lived TA certificates». APNIC, ARIN y LACNIC figuran en la columna de los registros que ya la ofrecían. La fecha para que estuviera disponible en los cinco RIR es «End of 2025».

La página se modificó por última vez el 2 de diciembre de 2025. Era, por tanto, un compromiso prospectivo cuando se publicó, no una certificación de cierre. Una hoja de ruta puede y debe contener trabajo pendiente. Lo que no puede hacer es convertirse, por el mero paso del calendario, en prueba de que ese trabajo terminó.

Después de la fecha hacen falta estados nuevos: entregado conforme a una definición pública; entregado con una excepción; aplazado con una nueva fecha; sustituido por otro control; o pendiente. La página examinada no incorpora ese cierre para AFRINIC.

El material operativo permite plantear el asunto con precisión. El 29 de agosto de 2026, el Trust Anchor Locator de AFRINIC estaba disponible. Su primera URI conducía a AfriNIC.cer en el repositorio RPKI. El archivo DER recuperado tenía 1.216 bytes. Su sujeto y emisor eran AfriNIC-Root-Certificate, su número de serie era E5CF72BA6C7E9E28 y su intervalo de validez iba del 30 de marzo de 2020 al 28 de marzo de 2030.

El repositorio respondió. El certificado pudo descargarse e inspeccionarse. No hay aquí evidencia de interrupción. Hay una observación más modesta: ocho meses después del objetivo común, el artefacto que AFRINIC servía públicamente todavía mostraba un intervalo de casi diez años.

Puede haber explicaciones razonables. Tal vez la hoja de ruta quedó desactualizada. AFRINIC puede haber preparado una transición que aún no produjo una nueva emisión. Puede existir una excepción, una fase de pruebas o una decisión de mantener el certificado durante una ventana prudente. También puede haber una definición técnica de «corta duración» que no esté enlazada desde los documentos revisados.

Ninguna de esas posibilidades puede convertirse en hecho sin su propio registro. Precisamente por eso una fecha objetivo necesita una constancia posterior.

«Corto» no es todavía un criterio de aceptación

Diez años parecen una duración larga. Esa intuición no autoriza a inventar el umbral del programa.

La hoja de ruta no especifica cuántos días o años acepta, con qué antelación debe renovarse el certificado, cuánto solapamiento se permite ni quién puede aprobar una excepción. No dice si el objetivo era de dos años, uno, noventa días u otro plazo. Tampoco explica si la expresión describe una reducción relativa respecto de una práctica anterior.

El certificado observado sigue siendo evidencia. No es un anuncio institucional: es un objeto obtenido desde la ubicación que publica el propio TAL de AFRINIC. Permite conservar la hora de observación, la URI, la serie, la huella y las fechas. Lo que no puede hacer es aportar por sí mismo la definición que falta.

Conviene separar tres objetos. El compromiso declara qué pretende entregar una institución. El artefacto observable muestra qué bytes sirve en un momento acotado. La aceptación explica con qué criterio y autoridad se considera que esos bytes cumplen el compromiso. Una misma palabra —«implementado»— no debe borrar las diferencias.

Sin ese desglose, el incentivo es claro. Una organización puede contar la disponibilidad del código; otra, la primera emisión de prueba; otra, la publicación en producción; una cuarta, la recuperación satisfactoria por validadores. Todas pueden marcar la misma casilla y haber completado actos distintos.

El TAL estabiliza la clave, no congela el certificado

RFC 7730 muestra por qué renovar con mayor frecuencia no obliga necesariamente a redistribuir una nueva decisión de confianza a todos los operadores.

Un TAL contiene ubicaciones para recuperar el certificado y el material de clave pública con el que debe comprobarse. El objeto referido ha de ser un certificado CA RPKI autofirmado y vigente. La clave pública del certificado debe coincidir con la del TAL.

El documento también exige estabilidad de la clave del ancla cuando el certificado se vuelve a emitir por cambios en los recursos o por renovación previa a su vencimiento. El reemplazo debe seguir disponible en la URI estable. La renovación del certificado y la rotación de la clave son, por diseño, acciones distintas.

Así, un RIR puede mantener la clave que las partes dependientes ya han aceptado y emitir certificados con fechas más cortas. Pero esa capacidad abre una cadena de ejecución. El sistema emisor debe crear el objeto correcto. El repositorio debe servirlo en el lugar previsto. El validador debe recuperarlo, verificar que está vigente y autofirmado, comparar la clave con el TAL y aplicar sus controles locales.

RFC 7730 recomienda repetir esas comprobaciones durante la resincronización del repositorio y antes de que expire la copia almacenada. Una emisión exitosa no demuestra, por sí sola, que la población de validadores la haya recuperado. Mucho menos lo demuestra la llegada de una fecha en un cuadro.

La cadena completa comprende política de duración, emisión, coincidencia de clave, publicación, recuperación observada, excepciones y corrección. Tampoco equivale a un resultado de enrutamiento. Las fuentes congeladas no muestran prefijos convertidos en RPKI Invalid, routers rechazando anuncios, fallos de actualización ni validadores con objetos erróneos. Cada consecuencia requeriría mediciones separadas.

Reducir la duración cambia la distribución del riesgo

El argumento serio a favor de una vida más corta no es que todo certificado breve sea seguro. Es que un intervalo reducido limita el tiempo durante el cual un estado antiguo puede seguir presentándose como vigente y convierte la renovación en una disciplina periódica.

Esa ventaja depende de la automatización. Emitir con mayor frecuencia prueba con mayor frecuencia el proceso de creación, publicación y recuperación. Puede descubrir un defecto antes de que una renovación excepcional se vuelva crítica. A la vez, deja menos margen para reparar una emisión o publicación fallida cerca del vencimiento.

Los certificados largos reducen la frecuencia de cambio, pero pueden prolongar la aceptación del estado anterior. Los cortos reducen esa persistencia solo si el reemplazo y la actualización funcionan. La elección no enfrenta seguridad con comodidad; redistribuye el tiempo, la frecuencia y la presión de recuperación.

Por eso no basta con que una versión de software sea capaz de emitir certificados. La puesta en servicio debe identificar qué certificado de producción materializa la política, cuándo comenzó, si hubo solapamiento, cómo se comprobó el repositorio, qué población de validadores se observó y qué ocurre si el siguiente certificado no aparece a tiempo.

Puede publicarse esa información sin revelar claves privadas, arquitectura de HSM ni procedimientos que faciliten un ataque. Fechas, huellas, clases de resultado y datos agregados son suficientes para la rendición de cuentas.

La constancia que falta

El primer bloque debe definir la función: duración normal, antelación de renovación, ventana de solapamiento, autoridad de excepción y fecha de revisión. Si «corto» es relativo, hay que publicar la referencia.

El segundo bloque describe el artefacto: RIR emisor, serie, huella SHA-256, notBefore, notAfter, URI y confirmación de coincidencia entre la clave del certificado y la del TAL. Son atributos públicos, no secretos operativos.

El tercero separa poblaciones. ¿El punto de publicación sirvió los bytes previstos? ¿Una muestra declarada de validadores los recuperó y aceptó? ¿Qué queda fuera de la observación? Ninguna muestra permite afirmar sin límites que «Internet» se actualizó.

Las excepciones necesitan identificador, responsable, motivo acotado, fecha de revisión y condición de cierre. No hace falta publicar la deliberación de seguridad. Sí hace falta distinguir una excepción gestionada de un silencio.

Las correcciones deben añadirse, no sobrescribir. Si cambia una huella, se sustituye un certificado o se redefine la función, el estado anterior debe conservarse. Una página editada sin historial impide reconstruir qué se prometió y qué estaba en línea en una fecha determinada.

Coordinación común, control distribuido

El programa RPKI de la NRO coordina a los cinco registros. El NRO Executive Council patrocina y prioriza; la dirección del programa organiza el trabajo; el Steering Group reúne el criterio técnico; los especialistas de cada RIR ejecutan. Esa estructura puede reducir diferencias innecesarias para operadores con recursos en varias regiones.

No convierte a la NRO en la autoridad de certificación operativa de AFRINIC. AFRINIC controla su emisión y repositorio. Las partes dependientes mantienen sus TAL y validadores. Los operadores deciden cómo utilizar los resultados en sus políticas de enrutamiento. La coordinación puede fijar un objetivo, pero no ejecuta todos esos actos.

La conclusión debe permanecer dentro de esa frontera. El certificado de AFRINIC aporta una observación reproducible en una promesa común. No demuestra un RPKI averiado, un anuncio engañoso ni un efecto sobre rutas. Demuestra que el expediente público no permite unir todavía el objetivo de 2025 con un estado de producción de AFRINIC aceptado bajo una definición visible.

La solución es pequeña: definición, estado por RIR, fecha de evidencia, excepción cuando proceda e historial de correcciones. El ancla debería ser aburrida. Su prueba de puesta en servicio debería ser inequívoca.

Sources