Resumen

  • RIPE NCC dijo en RIPE 93, el 28 de octubre, que OpenID Connect ya funcionaba en el panel RPKI desde esa mañana. La cookie compartida se mantendría hasta el final del día para las sesiones abiertas.
  • El acceso a la API de gestión RPKI continuaba con un secreto compartido sin vencimiento. Las claves vinculadas al inicio de sesión único y limitadas a un año seguían siendo un proyecto.

RIPE cambió la cerradura que ve una persona. La que usan los programas todavía lleva la vieja llave. En la sesión de enrutamiento, Tim Bruijnzeels separó dos hitos que el calendario público había juntado: el panel RPKI ya aceptaba OIDC; la migración de claves API vendría después.

La cookie antigua tuvo una prórroga de horas, no un cierre instantáneo. Bruijnzeels explicó que RIPE NCC había mitigado antes el problema de acceso comunicado en el panel, y que OIDC era necesario para completar otra parte de la solución. La cookie compartida seguía allí durante la charla y estaba programada para desaparecer al final del 28 de octubre, evitando que los usuarios conectados perdieran su sesión a mitad de trabajo.

El plan RPKI del cuarto trimestre enumeraba OIDC y la sustitución de claves API en la misma tarea. El informe de octubre puso un separador entre ambos. La clave actual de la API, configurada en el portal LIR, es un secreto compartido que no vence. Solo está disponible para LIR; quienes tienen recursos PI o heredados mediante un LIR patrocinador carecen de esa vía. La propuesta nueva une las claves a cuentas SSO, limita su vida a un año, prevé renovación y avisos, y abriría la API a esos titulares.

La guía técnica de RIPE NCC documenta X-API-Key para publicar ROA. Ahí reside la apuesta: una sesión nueva en el navegador deja intacta la credencial que invoca ese punto de entrada desde un script. Faltan en el registro público el cierre posterior de la cookie y una fecha de puesta en marcha de las nuevas claves; dos anuncios fechados resolverían la cuenta.