Resumen

  • La documentación vigente de la API de gestión RPKI del RIPE NCC sitúa la gestión de la autoridad de certificación y de las ROA de un LIR detrás de una clave de acceso.
  • El plan del tercer trimestre de 2026 describe como previsto el reemplazo de las claves actuales por claves basadas en OpenID Connect e integradas con RIPE NCC Access; no afirma que ya esté funcionando.
  • Para una baliza RPKI propuesta, RIPE NCC dice que no aceptó una API que habría permitido editar ROA para todo el espacio RIPE NCC. Esa limitación pertenece al camino propuesto, no prueba una capacidad de la API ordinaria.
  • Un registro de cuenta, una credencial y la autorización limitada de una modificación de ROA responden a preguntas distintas y no deben comprimirse en una sola prueba.

Autenticar una llamada no define por sí mismo su autoridad

La documentación de la RPKI Management API explica la superficie actual con suficiente precisión. Un LIR puede administrar su autoridad de certificación y sus ROA mediante una clave de API. La guía incluye operaciones sobre recursos, creación de ROA y alertas. El valor de la clave se muestra una sola vez cuando se crea, se conserva de forma hash y las claves que ya no se usan pueden revocarse.

Nada de ello equivale a un expediente de una modificación concreta. Una clave puede pertenecer a una cuenta y seguir sin responder qué certificado o recurso estaba autorizado, qué operación se solicitó, qué estado de ROA existía antes y cuál fue el resultado. La frase “la llamada estaba autenticada” no debería transformarse automáticamente en “la autoridad, el alcance y la transición de estado están demostrados”.

La política RIPE-843 aporta otra separación. Indica que las claves API se vinculan a una cuenta específica de RIPE NCC Access y que se desactivan si la cuenta se inhabilita o si la persona deja de ser mantenedora de cuenta en la aplicación correspondiente. Es una regla de ciclo de vida de identidad. No es un libro público de acciones ni una declaración sobre el perímetro de recursos de cada solicitud.

Un futuro de identidad y un límite de alcance ya visible

En la planificación trimestral de RPKI, RIPE NCC afirma que planea sustituir las claves RPKI actuales por claves OpenID Connect integradas con RIPE NCC Access y añadir su gestión al panel de RPKI. El estado publicado es “Planned”. La página no fija una fecha de entrega, el diseño definitivo del token ni el formato público de los eventos de cambio.

Ese mismo registro contiene una advertencia de diseño muy concreta. La organización no pudo añadir todavía una baliza RPKI propuesta porque la API utilizada permitiría editar ROA para todo el espacio RIPE NCC, algo que no consideró aceptable. La lectura correcta es estrecha: se rechazó un camino propuesto por su perímetro potencial. No hay en ello prueba de una API actual con ese poder, una incidencia de seguridad, una clave defectuosa ni una ROA no autorizada.

Precisamente por eso el plan de OpenID Connect exige una pregunta adicional. Mejorar la administración de identidades puede ser valioso, pero no determina qué recurso y qué acción puede tocar cada petición con cambio de estado.

El objeto útil es un comprobante de alcance

No hace falta publicar secretos, prefijos, ASNs, solicitudes sin procesar o configuración. Hacerlo podría revelar información operativa sin explicar de manera fiable una decisión. Un comprobante proporcional puede ofrecer la trazabilidad necesaria.

Para un cambio material de ROA, podría conservar la versión de política y de implementación; una clase de actor o cliente sin secreto; el contexto de cuenta; un conjunto acotado de recursos autorizados o una huella protegida; la acción solicitada; los estados previo y posterior protegidos; los momentos de decisión y ejecución; el resultado; una observación posterior de publicación cuando corresponda; y la cadena de correcciones o sustituciones. Así se registra la forma de la autorización sin revelar la cartera de recursos de un titular.

Es una propuesta editorial, no una obligación de RIPE NCC. Las fuentes no permiten concluir que faltan controles internos. Sí muestran que mecanismo de identidad, ciclo de vida de una cuenta y alcance de una modificación individual son tres objetos que merecen evidencias diferentes.

Fuentes