Resumen

  • El plan trimestral RPKI actualizado el 17 de septiembre de 2026 pone en marcha primero OpenID Connect y las claves de API; también mantiene tareas de cumplimiento y auditoría. El soporte por API para Resource Signed Checklists, o RSC, figura como previsto si hay capacidad, según avance de los dos puntos anteriores. Una pantalla para usuarios dependería de la demanda posterior.
  • En una comunicación de mayo de 2024 al grupo de trabajo de enrutamiento, RIPE NCC proponía trabajar en firma de RSC por API y por pantalla después de ASPA, o antes si el estándar ASPA se demoraba. El archivo de planes registró RPKI-2024#01 como petición que debía estudiarse. No era un compromiso de fecha.
  • El RFC 9323 define un objeto firmado que vincula huellas de archivos con un conjunto limitado de direcciones IP o ASN. Prohíbe distribuir ese objeto por el repositorio RPKI global. Una API que algún día lo firme no sustituye su entrega fuera de ese repositorio, su validación independiente ni la decisión comercial del receptor.
  • No hay en las fuentes examinadas una fecha de lanzamiento, un endpoint RSC público operativo, una incidencia del servicio ni un afectado concreto. Que una biblioteca reconozca extensiones RSC tampoco acredita un producto desplegado.

La pregunta del proveedor llega antes que la API

Pensemos en una empresa que quiere llevar sus direcciones a una nube. El proveedor le pide una declaración y un inventario; la empresa puede mostrar un documento, pero la otra parte necesita saber si esos bytes son los mismos que firmó quien controlaba los recursos declarados. Esa es una aplicación plausible de RSC, citada por el estándar como clase de uso. No afirma que ninguna empresa concreta ya haya pasado por el sistema de RIPE NCC.

El RFC existe desde 2022. Permite firmar un conjunto de huellas de archivos bajo un certificado limitado por recursos numéricos. Al validar, el receptor comprueba la cadena de certificados, el bloque de recursos y las huellas de los archivos que recibió. La mejora frente a una carta reenviada es real. Lo que no existe por decreto es la API de RIPE NCC que un cliente podría invocar para obtener esa firma. Una norma describe el objeto; no contrata ingenieros, no fija prioridades y no publica una operación de producción.

El plan de septiembre coloca por delante el cambio del panel RPKI a OpenID Connect y la sustitución de las claves de API actuales por claves integradas con RIPE NCC Access. También sitúa en curso un trabajo ISO 27001 para la organización y un nuevo SOC 2 Type II iniciado en mayo. Las listas firmadas son el tercer punto: RIPE NCC implementaría soporte en la API si el progreso de los dos anteriores deja capacidad. La posible interfaz gráfica quedaría para una etapa en la que se observe demanda. No hay calendario vinculante para esa tercera pieza.

Es difícil objetar el orden por principio. Antes de emitir otro tipo de objeto firmado, tiene sentido aclarar quién accede al sistema y bajo qué control se mantiene una autoridad certificadora. Sin embargo, la sensatez de una prioridad no debe confundirse con la disponibilidad de un producto. Un operador que se compromete a incorporar recursos de clientes mediante una API todavía condicional está trasladando al contrato una incertidumbre que el propio plan declara.

La antigua secuencia no obliga a la nueva

La historia pública ayuda a explicar por qué alguien esperaría esta función. En mayo de 2024, RIPE NCC explicó al grupo Routing que una RSC podía firmar, por ejemplo, un desafío enviado por un proveedor a un titular de direcciones. Su propuesta era hacer firma por API y en el panel después de ASPA; cabía adelantarla si la última llamada del IETF sobre ASPA no llegaba. Más tarde, el archivo de planificación recogió la petición comunitaria como RPKI-2024#01 y dijo que se investigarían los posibles usos.

Dos años después, el proyecto aparece de forma más estrecha y más dependiente de otras tareas. Eso no prueba un incumplimiento. La comunicación anterior era una propuesta, no un contrato de servicio; el archivo tampoco certificaba la entrega. Lo que sí cambia es la hipótesis de quien diseña una integración: ya no puede tratar «API y panel tras ASPA» como una hoja de ruta firme cuando el texto actual dice «API si queda capacidad» y «panel si hay demanda».

La documentación pública de la API de gestión RPKI explica cómo un LIR gestiona su autoridad certificadora y sus ROA mediante una clave. No documenta una operación pública para crear RSC. La ausencia en esa página no demuestra que no haya experimentos internos; delimita lo que un tercero puede integrar con respaldo documental. El registro de cambios de rpki-commons menciona, en una versión de 2024, un primer paso para reconocer extensiones relacionadas con RSC. Leer un formato no es ofrecer un servicio de emisión.

No es un ROA que todos deban descargar

Aquí aparece una diferencia decisiva para el diseño. La comunicación de 2024 usa al principio una descripción amplia de la lista como si se publicara en RPKI. Unos renglones después precisa que las RSC no se publican en el repositorio global y que deben intercambiarse entre el firmante y quien las valida. El RFC 9323 establece esa exclusión de manera normativa: el certificado de un solo uso omite la extensión que daría la ubicación de un objeto publicado en el repositorio.

Por tanto, el producto eventual no se cerraría al devolver «200 OK». El firmante debe obtener el archivo .sig; alguien debe entregarlo con los archivos exactos a la contraparte; esta debe validarlo y decidir si los recursos descritos corresponden a la operación que pretende aprobar. Un ROA difundido para validación de origen de rutas cumple otra función. La RSC no aparece automáticamente en todos los validadores de rutas ni autoriza a un AS a anunciar un prefijo.

Una API sin pantalla puede ser suficiente para integradores avanzados. Pero antes de confiar en ella habría que conocer el esquema de petición, el alcance de credenciales, la forma de recuperar el objeto, los errores, el ciclo de vida y un ejemplo verificable por herramientas independientes. Son pruebas de aceptación para un futuro lanzamiento, no fallos constatados hoy. El plan publicado no proporciona todavía ese contrato RSC.

Verificar una firma no resuelve el negocio

El RFC añade una cautela que impide inflar el resultado. La información de una RSC la declara el propio firmante. La validación no identifica por sí sola a la sociedad mercantil, no determina su mandato legal ni certifica la veracidad de los documentos: indica control suficiente sobre la autoridad certificadora emisora para producir el objeto. Un ejemplo antiguo del archivo de RIPE NCC habla de «prueba de propiedad de un ASN»; esa expresión no debe leerse como conclusión jurídica del estándar.

La cobertura previa de BTW ya ha tratado el límite entre huella correcta y autoridad empresarial. Este artículo no reabre ese caso general. Pregunta quién puede ofrecer el servicio concreto, cuándo un plan pasaría a ser una capacidad operativa y qué parte de la decisión seguirá en manos del proveedor. A día de hoy solo se pueden afirmar los estados publicados: dos trabajos en curso, soporte RSC por API condicional y una posible pantalla más adelante. No hay base para anunciar un incidente ni para prometer al cliente una función aún sin fecha.

Fuentes