Resumo

  • A RFC 6487 proíbe authorityCertIssuer e authorityCertSerialNumber no Authority Key Identifier de certificados de recursos RPKI, embora a RFC 5280 defina os dois como componentes opcionais da sintaxe X.509 geral.
  • O commit 994a598 do Barry ligou authorityCertIssuer a um parser de GeneralNames que exige array. No dia seguinte, o Rapport b1a59a trocou a antiga string escalar por um array com um rfc822Name e corrigiu a mensagem esperada do FORT.
  • O roteiro chama Barry, depois o relying party, verifica o log e só então compara os VRPs com um conjunto vazio. A fonte demonstra esse desenho, mas não traz um transcript público da execução nem o certificado gerado e decodificado.
  • O Rapport documenta quatro seletores de validadores, porém a asserção que nomeia o campo é executada apenas quando RP=fort2. Nos demais, saída vazia mostra consequência, não necessariamente causa.

Um teste negativo precisa provar sua entrada

A norma estabelece uma fronteira específica. O Authority Key Identifier relaciona o certificado à chave pública do emissor. A RFC 6487 exige a extensão nos certificados de recursos, salvo o caso autosassinado, determina que ela seja não crítica e veda os membros authorityCertIssuer e authorityCertSerialNumber. A RFC 5280, perfil geral da PKIX, permite os dois como opcionais desde que apareçam juntos. O RPKI usa a estrutura X.509, mas restringe essa opção.

O caso de teste parece direto: inserir o membro proibido em um certificado de CA, publicar um ROA abaixo dele e verificar que o validador não exporta a carga de origem de rota. Só que o primeiro verbo — inserir — não é detalhe operacional. Se o gerador não compreender o fixture, omitir o campo ou parar antes de gravar o certificado, o validador jamais recebe a condição que deveria julgar. Zero VRPs pode ser o resultado esperado pela razão errada.

O Barry foi criado para fabricar esse tipo de repositório. A LACNIC o descreveu em 2025 como ferramenta capaz de gerar cenários válidos e propositalmente inválidos a partir de descrições chave-valor. O Rapport coordena esses cenários contra relying parties e examina saídas. A vantagem é tornar repetível uma borda difícil do protocolo. A obrigação é manter evidência de que a borda foi de fato construída.

A diferença entre uma string e GeneralNames

Em 1º de setembro de 2026, o commit 994a598321336baf1767f0fbfb460ed96c29fe4f implementou no Barry o campo authorityCertIssuer. O arquivo ext.c o associa ao tipo ft_gnames. No field.c, parse_gnames verifica se a entrada é conjunto ou array, conta os elementos, aloca um GeneralName ASN.1 para cada um e interpreta cada membro como objeto. Se a entrada não for array, o caminho de erro informa que colchetes são esperados.

O novo teste funcional do Barry torna o contrato visível. Seu array contém um rfc822Name, um iPAddress e um registeredID. Não é um modelo de certificado RPKI conforme; é uma prova de que o gerador consegue codificar alternativas diferentes de GeneralName.

Na revisão anterior do caso no Rapport, a descrição usava authorityCertIssuer = "CN=Fake Issuer". Era uma string escalar. Compará-la com o parser atual sustenta uma conclusão limitada: aquela forma não atende ao contrato atual de parse_gnames. Não revela como um binário antigo se comportou nem prova que determinada execução falhou antes do validador. Faltam versão executável, comando e log da época.

O commit b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c, no dia 2, corrigiu o fixture do Rapport. O valor passou a ser um array com um elemento: type = rfc822Name, com um endereço de exemplo como value. O endereço não precisa representar emissor plausível, porque a regra veta o membro como um todo. O ganho é estrutural: agora a condição proibida está expressa na forma que o gerador sabe processar.

O log também acusava o campo errado

Antes da correção, o run.sh procurava no log do FORT uma mensagem sobre authorityCertSerialNumber. O fixture tentava adicionar authorityCertIssuer. Depois de b1a59a, a asserção cita o issuer. Isso corrige uma segunda ligação: construir o defeito certo e atribuir a rejeição a outro campo também produziria evidência enganosa.

A ordem do script é instrutiva: run_barry, run_rp, check_logfile, check_vrps. Uma execução auditável deveria guardar um artefato por transição. Do gerador: commit, hash do binário, hash do fixture, código de saída e certificado. Do objeto: decodificação do AKI. Do validador: produto, versão, configuração, TAL e estado do ciclo. Do resultado: diagnóstico estável, quando houver, e hashes dos conjuntos de VRPs esperado e observado.

Na captura pública, esses recibos não aparecem. O GitHub informa zero check runs para o commit do Rapport; o repositório não apresenta tags nem releases. Isso não autoriza dizer que ninguém testou localmente. Autoriza apenas separar uma correção legível em código de um resultado executado, reproduzível e vinculado a uma versão.

Vazio não explica por que ficou vazio

O helper check_vrps cria o arquivo esperado a partir de seus argumentos. Como esta chamada não fornece nenhum, o esperado fica vazio. A saída CSV do relying party é convertida para um formato comum, ordenada e comparada. Um diff limpo demonstra que nenhum VRP foi exportado naquele caminho.

É uma consequência importante: há um ROA abaixo do certificado de CA malformado e ele não deve virar autorização de origem aceita. Ainda assim, várias causas terminam no mesmo arquivo vazio. O validador pode rejeitar corretamente o AKI, falhar ao buscar o repositório, encontrar outro defeito, usar um TAL diferente ou nem receber o objeto porque o Barry parou. Sem prova de construção e telemetria da execução, o resultado não escolhe uma dessas explicações.

Para o FORT, o caso contém uma verificação adicional. A chamada é check_logfile fort2, e a própria função só examina o arquivo quando o seletor ativo RP coincide com o nome recebido; caso contrário, retorna. Logo, a frase exata sobre authorityCertIssuer é uma asserção específica do FORT 2.

O README fixado no mesmo commit lista fort2, routinator, rpki-client e rpki-prover e diz que cada execução escolhe um. Quatro adaptadores não criam automaticamente quatro diagnósticos equivalentes. Nas outras três opções, a verificação comum visível é o conjunto vazio. Ela pode sustentar “nenhum payload foi aceito”, mas não “o campo foi identificado” com a mesma precisão.

Uma matriz com três colunas de verdade

Uma matriz de conformidade útil deveria separar construção, decisão e saída. A primeira coluna guardaria commit e impressão do Barry, fixture, término, certificado e AKI decodificado. A segunda registraria o validador, versão, configuração e sinal de rejeição. A terceira mostraria os conjuntos esperado e real. Só depois caberia um resumo em cor.

Nem todo validador oferece texto de log estável, e uma suíte portable não deveria impor a mesma frase. Código estruturado, classe de erro própria ou afirmação estrita de que o payload não apareceu podem ser alternativas honestas. Comparabilidade não significa interface idêntica; significa que a legenda de cada célula corresponde ao que foi realmente observado.

Também é preciso distinguir “teste presente na fonte”, “teste executado contra um build identificado” e “resultado publicado numa suíte versionada”. O primeiro permite revisão por pares. O segundo adiciona ambiente e artefatos. O terceiro conecta a evidência ao software que um operador pode instalar. Misturar os três faz a branch principal parecer garantia retroativa.

Entre o fixture e o validador há um artefato especialmente útil: o certificado gerado e uma decodificação independente do seu AKI. O arquivo de descrição registra intenção; o parser registra a forma aceita; só o DER registra o que poderia chegar ao software testado. Guardar o hash do certificado, a versão da ferramenta de decodificação e os campos observados fecha essa passagem com pouco custo.

O transporte também deve aparecer no recibo. Um repositório não adquirido e um certificado adquirido e rejeitado podem produzir o mesmo conjunto vazio, mas são resultados operacionais diferentes. Protocolo usado, sucesso das requisições e término do ciclo de validação permitem separar indisponibilidade, erro de preparação e decisão criptográfica.

Um manifesto pequeno basta: hashes de entrada e binários, objetos produzidos, versões, horários, códigos de saída, classe de diagnóstico e conjuntos de VRP. Vinculado ao job e ao release, ele continua verificável mesmo depois que a interface do CI ou a redação do log mudar.

O texto da LACNIC de dezembro de 2025 chamava Barry e Rapport de projetos ainda iniciais e descrevia então o FORT como alvo. O README posterior apresenta quatro seletores. As duas fontes registram momentos diferentes de evolução. Não se deve usar o post antigo para negar a capacidade atual, nem a lista atual para inventar quatro resultados históricos.

A conclusão mais forte disponível é deliberadamente modesta. O Barry ganhou a mecânica de authorityCertIssuer; o Rapport ajustou o tipo do fixture e alinhou o diagnóstico do FORT. A definição da prova ficou melhor. A evidência pública capturada não certifica sucesso no FORT nem nos outros três relying parties.

Fontes

  1. LACNIC Blog, “Open-Source Projects at LACNIC”: https://blog.lacnic.net/en/open-source-projects-lacnic/
  2. Commit 994a598 do Barry: https://github.com/LACNIC/barry/commit/994a598321336baf1767f0fbfb460ed96c29fe4f
  3. Parser e ligação do campo no Barry: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/field.c e https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/src/ext.c
  4. Fixture funcional de GeneralNames: https://github.com/LACNIC/barry/blob/994a598321336baf1767f0fbfb460ed96c29fe4f/test/functional/tests/gnames.rd
  5. Commit corretivo b1a59a do Rapport: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c
  6. Fixture e runner corrigidos: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd e https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  7. Helpers e README do Rapport: https://github.com/LACNIC/rapport/blob/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/tools/checks.sh e 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 e runner anteriores à correção, no commit 69da5fe: https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd e https://github.com/LACNIC/rapport/blob/69da5fe98cf09594fc009f4151a84368c08489ba/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/run.sh
  11. Arquivos alterados pelo commit corretivo b1a59a: https://github.com/LACNIC/rapport/commit/b1a59a39ea3b3f8ddc66571a7177c8afb1d0967c/checks
  12. Histórico do caminho do fixture em main: https://github.com/LACNIC/rapport/commits/main/tests/rfc6487/4.8.3-c-aki-with-authoritycertIssuer-rejected/rd
  13. Tags e releases do Rapport: https://github.com/LACNIC/rapport/tags e https://github.com/LACNIC/rapport/releases