Resumen

  • La página vigente de certificación de recursos de AFRINIC enlaza directamente un CPS de RPKI de 48 páginas, versión 3.0, publicado en mayo de 2020.
  • La sección V.8 afirma que AFRINIC recibió de IANA autoridad exclusiva sobre direcciones IP y números de AS de «la región Asia-Pacífico». AFRINIC e IANA sitúan su región real en África y parte del océano Índico.
  • El CPS actual de APNIC contiene una cláusula de tres frases casi idéntica, pero empareja correctamente APNIC con Asia-Pacífico. Esa similitud no demuestra quién copió a quién ni quién introdujo el error.
  • El hallazgo afecta a un documento público de control. No prueba una asignación, un certificado, una ROA, un ancla de confianza, un estado de validación, una ruta o una interrupción erróneos.

La vigencia depende del enlace, no de la fecha

Un documento de 2020 podría ser una pieza histórica sin efecto presente. Este no aparece así. La página de certificación de recursos de AFRINIC ofrece un único enlace titulado Certificate Practice Statement (CPS) dentro de sus documentos de política. El destino es CPS; no lleva una etiqueta de archivo, borrador o versión sustituida.

El PDF descargado para esta investigación tiene 48 páginas y 195.830 bytes. Su huella SHA-256 es 2770e175edbd611c798d0036229a05f3e830843dc4ee202e35e5e944db91d5f0. La portada dice AFRINIC Certification Practice Statement for the Resource PKI, versión 3.0, mayo de 2020. El historial impreso registra las versiones 1.0 de enero de 2011, 2.0 de marzo de 2015 y 3.0 de mayo de 2020.

La anomalía está en la página 36, sección V.8, CA or RA termination. Allí se afirma que IANA concedió a AFRINIC la autoridad exclusiva para gestionar la asignación de espacio de direcciones IP y números de AS en «the Asia-Pacific region». La frase siguiente dice que AFRINIC estableció RPKI para su región de acuerdo con esa autoridad. El párrafo concluye señalando que no existen disposiciones para terminar y transferir la función de CA a otra entidad.

La página se examinó tanto mediante extracción de texto como mediante una imagen renderizada. La región no procede de un fallo de OCR, de una columna contigua ni de un resumen de buscador. Forma parte del texto que aparece en la composición normal del PDF.

Tampoco ocupa un rincón ornamental. La cláusula V.8 explica la base institucional de la autoridad certificadora y qué declara el documento sobre su terminación. Al colocar la geografía dentro de ese razonamiento, el CPS convierte la región en una premisa de autoridad.

Las páginas del propio registro resuelven la contradicción

La corrección geográfica no requiere una opinión externa. La página About AFRINIC define a la organización como el registro regional que sirve a África y a la región del océano Índico. Su página de región de servicio divide el territorio en África septentrional, occidental, central, oriental y meridional, además del océano Índico.

IANA ofrece la misma distribución. Su explicación pública de los cinco RIR asigna África y partes del océano Índico a AFRINIC, y Asia/Pacífico a APNIC. El informe de reconocimiento de AFRINIC de 2005 detalla los países y territorios de la nueva región y documenta la transición que creó el quinto RIR.

No estamos ante dos límites plausibles que deban conciliarse. La afirmación segura es concreta: el CPS al que AFRINIC dirige hoy a sus lectores combina el nombre de AFRINIC con la región de otro registro.

Los metadatos HTTP merecen una lectura igualmente contenida. La captura de la página HTML devolvió un Last-Modified del 20 de agosto de 2026; el PDF devolvió el 28 de mayo de 2020. Esas fechas describen lo que cada servidor comunicó acerca del archivo entregado. No prueban que una persona revisara el contenido y los enlaces en agosto. Una compilación del sitio, una migración o un despliegue general pueden cambiar el encabezado sin reaprobar cada cláusula.

La cláusula de APNIC muestra el encaje correcto

El contraste más revelador está en el CPS vigente de APNIC. Su sección 5.8 presenta la misma arquitectura de tres frases.

Primero dice que APNIC tiene autoridad de IANA sobre las direcciones y los números de AS de Asia-Pacífico. Después relaciona esa autoridad con el RPKI establecido por APNIC para su región. Por último declara que no hay disposiciones para transferir la función de CA a otra entidad. En esa versión, institución y geografía coinciden.

La semejanza abarca el orden, el propósito y buena parte de la redacción. Es razonable investigar si hubo un texto heredado o una plantilla compartida. No es razonable publicar esa hipótesis como autoría probada. El conjunto de fuentes no contiene historial de edición, notas marginales ni registros de aprobación capaces de establecer el sentido de una copia o el nombre de quien dejó la región incorrecta.

El cotejo permite, sin embargo, dos conclusiones útiles. El lector puede comprobar en fuentes oficiales que APNIC corresponde a Asia-Pacífico y AFRINIC a África y el océano Índico. Además, el paralelismo enseña que no conviene ejecutar una sustitución mecánica sobre todo el párrafo. La región equivocada y la frase sobre una futura transferencia de la CA exigen decisiones distintas.

Un error documental no es un evento de validación

RPKI une políticas institucionales con infraestructura de confianza, pero no todos sus objetos cumplen la misma función. El RFC 6484 explica la relación entre la política de certificados de RPKI y la declaración de prácticas que mantiene cada CA. El CPS comunica cómo dice operar la autoridad. Es evidencia importante de gobernanza y práctica; no es una ROA, un certificado de recursos, un manifiesto, una CRL, una TAL ni la salida de un validador.

Las fuentes no muestran un certificado de AFRINIC rotulado como Asia-Pacífico. No muestran que un prefijo o ASN se asignara a esa región por la frase V.8, ni que APNIC perdiera o compartiera autoridad. Tampoco documentan un cambio en el ancla de confianza, una avería del repositorio o una alteración del conjunto de cargas útiles validadas.

No hay mediciones de rutas que conecten este párrafo con un estado Invalid, NotFound o inaccesible. No hay un anuncio rechazado, una clave comprometida, una cuenta vulnerada ni un apagón de servicio. Convertir una frase equivocada en uno de esos incidentes añadiría una historia que el expediente no contiene.

La oración sobre el cese de la CA tampoco autoriza una conclusión absoluta. Dice que el CPS público no contiene disposiciones para la terminación y transición de esa función a otra entidad. No demuestra que AFRINIC carezca de continuidad interna, recuperación ante desastres o facultades legales para una emergencia. Esas superficies necesitarían documentos propios.

Delimitar el hallazgo no reduce la importancia de corregirlo. Una CA invita a suscriptores y terceros a usar el CPS como relato de sus prácticas. Cuando la institución, la autoridad y el territorio no concuerdan, nadie fuera de AFRINIC puede saber si falló una sola sustitución o si el control de versiones dejó más texto heredado sin examinar.

El cierre debe conservar el antes y el después

Una edición silenciosa resolvería la apariencia: cambiar Asia-Pacific por Africa and the Indian Ocean, volver a subir el archivo y mantener el mismo URL. Pero impediría responder qué bytes estuvieron vigentes, quién autorizó el cambio, qué versión lo contiene, cuándo adquirió efecto y si se revisó el resto de la cláusula.

Un recibo de corrección puede ser breve y público. Debe identificar el documento, la versión nueva y la sección V.8; mostrar el texto anterior y el sustitutivo; y registrar los SHA-256 del PDF retirado y del PDF nuevo. Cada cambio debe clasificarse como corrección editorial, aclaración o cambio de práctica.

También hacen falta el cargo que aprobó la modificación, la autoridad con la que actuó y tres tiempos separados: aprobación, publicación y entrada en vigor. La frase sobre la transición de la CA necesita una decisión expresa: conservada, revisada, sustituida o regulada en otro instrumento enlazado.

El PDF antiguo debe permanecer en un URL histórico inmutable. El URL estable de la versión actual debe entregar exactamente la nueva huella anunciada. Un aviso público o registro de cambios debería enlazar ambos archivos. Después se puede hacer una lectura de vuelta: estado HTTP, cadena de redirecciones, ETag, tamaño, hash, portada y contenido de V.8.

Si no cambiaron certificados, claves, objetos del repositorio o servicios, el recibo debería decir document correction only. Esa delimitación negativa informa más que una garantía imprecisa de que «RPKI no se vio afectado», porque permite conocer las superficies realmente comprobadas.

Las preguntas que el PDF no responde

La fecha de 2020 no demuestra que el error naciera entonces. Habría que obtener y autenticar las versiones 1.0 y 2.0 para saber si ya contenían la misma región. Tampoco sabemos si una revisión interna detectó el problema o si existe una instrucción más reciente que nunca sustituyó el enlace público. Lo que sí está congelado es el recorrido actual desde la página de servicio hasta la versión 3.0.

El expediente tampoco atribuye el texto a una persona. La seguridad, los asuntos jurídicos, la ingeniería del servicio y el equipo web pueden compartir distintas partes del ciclo documental. Un organigrama no es una prueba de autoría. La próxima versión debería identificar al responsable institucional de la corrección, no inventar retrospectivamente a un culpable.

Por último, la cláusula de APNIC no decide si la política de continuidad de AFRINIC es adecuada. Su utilidad es textual: revela cómo encajan las frases y la región. Una eventual revisión de sucesión o terminación sería un cambio de gobernanza, con su propio fundamento y su propia fecha efectiva.

Una reparación que cualquiera pueda reconstruir

La prueba de cierre cabe en un recorrido repetible. Un lector debería poder abrir el URL actual, identificar el número de versión, verificar la huella, leer la región correcta, conocer el destino de la oración sobre transición y recuperar el archivo sustituido.

Ese recorrido separa dos cuestiones que suelen mezclarse. AFRINIC puede reconocer un defecto de su documento sin afirmar un fallo operativo no probado. Los usuarios pueden verificar el cambio sin acceder a secretos de claves o instalaciones. Y el registro histórico permite saber qué texto se presentaba como vigente antes de la corrección.

Un URL estable es útil para la automatización, pero no garantiza que los bytes detrás de él sigan bajo revisión. La decisión duradera consiste en corregir la región, decidir el alcance de V.8, conservar la versión 3.0 y publicar un recibo autorizado y verificable.

Fuentes