Resumen

  • RFC 6487 prohíbe authorityCertIssuer y authorityCertSerialNumber en el Authority Key Identifier de un certificado de recursos RPKI, aunque la sintaxis general de RFC 5280 contempla ambos campos como opcionales.
  • El commit 994a598 de Barry conectó authorityCertIssuer con un analizador de GeneralNames que exige un arreglo. Al día siguiente, Rapport b1a59a sustituyó una cadena escalar por un arreglo con un rfc822Name y corrigió el diagnóstico esperado de FORT.
  • El guion ejecuta primero Barry, después el relying party, luego revisa el registro y finalmente compara los VRP con un archivo vacío. El código expresa esa secuencia, pero la captura pública no contiene una ejecución reproducible ni un artefacto de certificado decodificado.
  • Rapport enumera cuatro validadores seleccionables, pero en esta prueba solo fort2 tiene una comprobación exacta del motivo. En las otras columnas, un resultado vacío muestra una consecuencia sin identificar necesariamente la causa.

Antes del rechazo está la construcción

El defecto buscado es preciso. En los certificados de recursos, la extensión Authority Key Identifier debe identificar la clave pública del emisor. RFC 6487 exige esa extensión salvo en el caso autosignado, la declara no crítica y prohíbe que contenga authorityCertIssuer o authorityCertSerialNumber. RFC 5280, el perfil X.509 general, sí define esos miembros opcionales y dispone que aparezcan juntos. RPKI toma la sintaxis de base y le quita esa flexibilidad.

Una prueba negativa parece, entonces, una operación de tres pasos: producir un certificado con el miembro prohibido, entregarlo al validador y comprobar que el ROA subordinado no genera una carga útil aceptada. El peligro está en dar el primer paso por supuesto. Si el generador no entiende la descripción, descarta el campo o termina antes de escribir el certificado, la ausencia de VRP no demuestra una decisión del validador. Demuestra, a lo sumo, que no hubo salida.

Barry existe para fabricar esas entradas deliberadamente anómalas. LACNIC lo presentó en 2025 como un generador de repositorios RPKI válidos e inválidos a partir de archivos clave-valor. Rapport usa esos repositorios para poner a prueba relying parties. Esa arquitectura es potente porque permite repetir casos difíciles; también obliga a tratar al generador como parte de la cadena probatoria.

Una cadena no era un GeneralNames

El commit 994a598321336baf1767f0fbfb460ed96c29fe4f, fechado el 1 de septiembre de 2026, incorporó a Barry el campo authorityCertIssuer. En el código de extensiones, el miembro queda asociado al tipo ft_gnames. Su analizador, parse_gnames, acepta un conjunto o arreglo, reserva un objeto ASN.1 por elemento y procesa cada uno como un GeneralName. Una entrada de otro tipo toma una ruta de error que exige explícitamente corchetes.

El nuevo fixture funcional de Barry enseña la gramática con tres miembros: rfc822Name, iPAddress y registeredID. No intenta describir un certificado de recursos válido. Prueba que el generador puede construir varias formas de nombre general.

La versión anterior del caso de Rapport usaba otra forma: authorityCertIssuer = "CN=Fake Issuer". Era una cadena escalar, no un arreglo. El cruce de ambos archivos permite afirmar que esa descripción no cumple el contrato actual de parse_gnames. No permite afirmar que una versión antigua de Barry la haya rechazado en una ejecución concreta, porque no hay un registro público de esa ejecución ni un binario fijado que la reproduzca.

Rapport corrigió el archivo al día siguiente, en b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c. El valor pasó a ser un arreglo de un solo elemento, con tipo rfc822Name y una dirección de ejemplo como valor. La identidad es artificial y no necesita parecer un emisor legítimo: la norma prohíbe la presencia del miembro, cualquiera que sea su contenido. Lo relevante es que el generador dispone ahora de una estructura compatible para codificar la infracción.

El diagnóstico también apuntaba a otro campo

La corrección no se limita al fixture. El runner anterior buscaba en el registro de FORT un mensaje sobre authorityCertSerialNumber, pese a que el campo introducido era authorityCertIssuer. La nueva versión busca el mensaje correspondiente al issuer. Así se repara una segunda unión de la cadena: no basta con fabricar el defecto correcto si la prueba atribuye el rechazo a otro defecto.

El orden del guion merece conservarse como modelo. Primero run_barry; después run_rp; a continuación check_logfile; al final check_vrps. Una ejecución auditable debería producir una prueba en cada frontera: código de salida y versión de Barry; hash y decodificación del certificado; versión y configuración del validador; diagnóstico observado; y comparación entre el conjunto de VRP esperado y el real.

El repositorio capturado no publica esa colección de artefactos. GitHub informa cero check runs para b1a59a; además, Rapport no presenta tags ni releases en las superficies consultadas. Eso no significa que nadie haya corrido el caso fuera de GitHub. Significa que el lector no tiene base para llamar al commit “resultado certificado” ni para ligarlo a una versión distribuida.

Vacío es un resultado, no una explicación

La función check_vrps empieza creando un archivo esperado con los argumentos recibidos. En este caso no recibe ninguno, por lo que el archivo esperado queda vacío. Después normaliza y ordena los VRP del archivo de salida del relying party y ejecuta un diff. Si el diff no encuentra diferencias, el caso confirma que ningún VRP fue emitido.

Ese control es necesario: el repositorio de prueba coloca un ROA debajo del certificado de CA malformado. Pero varios caminos pueden acabar en el mismo vacío. Puede haber un rechazo correcto del AKI; puede fallar la adquisición del repositorio; puede existir otra anomalía en la cadena; puede cargarse otro TAL; o Barry puede no haber servido el objeto. La consecuencia solo adquiere causa cuando se une al objeto decodificado y a la telemetría de la ejecución.

Para FORT hay una pista adicional. La llamada es check_logfile fort2, y el helper solo ejecuta la búsqueda cuando la variable RP coincide con ese selector. Si se está probando otro relying party, retorna sin revisar el texto. Por eso la frase exacta que nombra authorityCertIssuer no es una expectativa común a todos los adaptadores.

El README fijado en el mismo commit reconoce fort2, routinator, rpki-client y rpki-prover, uno por ejecución. Que existan cuatro adaptadores no equivale a que esta prueba tenga cuatro diagnósticos comparables. Para los otros tres, el control común visible es el conjunto vacío. Puede ser suficiente para una afirmación limitada —el payload no apareció—, pero no para adjudicar con igual precisión el motivo.

Cómo publicar una matriz que sí se pueda usar

Una matriz útil para un operador tendría que separar al menos tres preguntas. ¿Se construyó la condición prohibida? ¿Qué decisión tomó el validador? ¿Qué efecto tuvo en sus salidas? En la primera columna deberían figurar el commit y la huella del binario Barry, el hash del fixture, el estado de terminación, el certificado generado y una decodificación del AKI. En la segunda, el producto, la versión, la configuración, el TAL y un código o diagnóstico de rechazo. En la tercera, los hashes del conjunto esperado y del conjunto observado.

No todos los proyectos consideran estable el texto de sus logs. Una suite portable no debe obligarlos a imprimir la misma frase. Puede usar categorías estructuradas, códigos propios o resultados cuidadosamente acotados. La comparabilidad no nace de fingir interfaces idénticas, sino de declarar qué evidencia sostiene cada celda.

También conviene distinguir tres estados de madurez: prueba presente en el código, prueba ejecutada contra un build identificado y prueba publicada dentro de una versión de la suite. El primer estado facilita la revisión. El segundo permite reproducir. El tercero conecta el resultado con decisiones de despliegue. Una casilla verde sin esas fechas convierte la rama principal en una garantía móvil.

La publicación de LACNIC de diciembre de 2025 describía Barry y Rapport como proyectos en etapa temprana y hablaba entonces de FORT. El README posterior enumera cuatro selectores. La lectura correcta es temporal: la cobertura creció. No se debe usar el artículo antiguo para negar la capacidad actual, ni la lista actual para inventar resultados históricos o simetría entre pruebas.

El hallazgo, por tanto, es pequeño pero importante. Barry añadió la capacidad de expresar authorityCertIssuer. Rapport adaptó su fixture al tipo correcto y alineó la expectativa de FORT. El caso fuente cuenta hoy una historia técnica más sólida. Lo que falta es el recibo de que esa historia se ejecutó de principio a fin en cada validador que se quiera comparar.

Fuentes

  1. LACNIC Blog, “Open-Source Projects at LACNIC”: https://blog.lacnic.net/en/open-source-projects-lacnic/
  2. Commit 994a598 de Barry: https://github.com/LACNIC/barry/commit/994a598321336baf1767f0fbfb460ed96c29fe4f
  3. Analizador y conexión del campo en Barry: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/field.c y https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/ext.c
  4. Fixture de GeneralNames: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/test/functional/tests/gnames.rd
  5. Corrección b1a59a de Rapport: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c
  6. Fixture y runner corregidos: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd y https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  7. Helpers y README de Rapport: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tools/checks.sh y https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/README.md
  8. RFC 6487: https://www.rfc-editor.org/rfc/rfc6487.html
  9. RFC 5280: https://www.rfc-editor.org/rfc/rfc5280.html
  10. Fixture y runner anteriores a la corrección, en el commit 69da5fe: https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd y https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  11. Archivos cambiados por el commit correctivo b1a59a: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/checks
  12. Historial de la ruta del fixture en main: https://github.com/LACNIC/rapport/commits/main/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd
  13. Tags y releases de Rapport: https://github.com/LACNIC/rapport/tags y https://github.com/LACNIC/rapport/releases