Resumo

  • Uma alteração do Rapport em 4 de setembro de 2026 separou dois casos da RFC 9286. No caso da mesma instância de CA, o teste forma um cache válido, remove ca2.mft e ainda espera seis VRPs, inclusive os dois guardados para a CA afetada.
  • O próprio script diz que o validador deve avisar sobre o manifesto ausente, mas a única chamada de check_logfile logo abaixo começa com #. Na revisão fixada, o shell não a executa.
  • A RFC 9286 trata o alerta fundamentado e a continuidade do cache como obrigações distintas: a falha deve gerar um aviso com a razão, recomenda-se informar uma pessoa e os objetos em cache devem continuar em uso até ficarem obsoletos ou serem substituídos.
  • A aceitação completa exige duas provas: qual estado foi mantido e qual sinal semântico chegou ao plano operacional. VRPs preservados não comprovam aviso; um aviso não comprova o conjunto correto de VRPs.

O teste que continua parecendo normal

O cenário começa com uma condição deliberadamente saudável. Duas instâncias de CA publicam dois VRPs cada uma, e a primeira execução cria um resultado conhecido de quatro VRPs. Em seguida, o roteiro monta uma nova condição com uma terceira CA, retira do alcance o arquivo ca2.mft e roda outra vez o relying party escolhido, desta vez sem a possibilidade de buscar o manifesto por HTTP. O experimento isola uma pergunta: se a mesma instância de CA não consegue entregar seu manifesto na rodada seguinte, o estado anteriormente validado deve desaparecer imediatamente?

A resposta codificada no teste é não. A segunda execução deve entregar seis VRPs: dois da primeira CA, dois novos da terceira e os dois que pertenciam à segunda CA no ciclo bem-sucedido anterior. O conjunto esperado transforma a recomendação de continuidade em algo observável. Uma indisponibilidade de publicação não vira, por reflexo, uma mudança abrupta na interpretação de origens de rota.

Esse comportamento não é uma licença para confiar indefinidamente em material antigo. É um mecanismo de amortecimento. A interrupção pode acabar antes da próxima coleta, enquanto a remoção imediata poderia fazer o relying party tratar rotas válidas como inválidas, ou inverter a conclusão em outro estado. Manter a última observação bem-sucedida por um período delimitado protege o sistema contra a tradução automática de uma falha de transporte em uma mudança de autorização.

É exatamente aí que a segunda metade do teste importa. Antes de conferir os seis VRPs, o script traz um comentário segundo o qual o validador deve produzir um alerta a respeito do manifesto ausente. A linha seguinte contém uma checagem de log voltada ao FORT, mas começa com #. Em shell POSIX, isso faz dela texto inerte. Portanto, a revisão analisada verifica o conjunto de saída retido e não verifica, por essa instrução, se o alerta foi emitido.

O alcance dessa observação é pequeno por necessidade. A linha comentada não demonstra que o FORT ou qualquer outro relying party ficou silencioso. Não mostra que o teste falhou, que os seis VRPs estão errados ou que um repositório real de produção enfrentou esse problema. Também não explica a intenção dos mantenedores, a existência de uma cobertura não publicada ou a data de uma eventual ativação. O que ela demonstra é mais simples: o caminho executável do caso de fallback não contém ali uma asserção sobre o alerta que o comentário declara necessário.

Uma publicação pode abrigar várias instâncias

A RFC 9286 oferece a chave conceitual para não confundir diretório, publicação e identidade. Um manifesto é o inventário assinado dos certificados, da CRL e dos objetos assinados associados a um ponto de publicação de CA. Mais de uma instância de CA pode compartilhar um ponto de publicação. Cada manifesto, porém, descreve apenas a instância de CA à qual está associado.

Por isso, o processamento não deve juntar tudo o que vive no mesmo lugar. Ele ocorre separadamente para cada instância, guiado pelo URI do manifesto no campo SIA do certificado da CA. Se esse manifesto não puder ser obtido, a busca termina com falha e o relying party entra no procedimento de falha daquela instância específica. A identidade que liga o cache não é apenas o caminho do repositório; é a instância indicada pelo certificado e pelo SIA.

Nesse procedimento, a RFC usa verbos separados. A falha deve produzir um alerta que informe a razão pela qual o processamento daquela CA terminou, e o texto recomenda notificar um operador humano. Em outra instrução, o relying party deve continuar usando os objetos em cache associados à mesma CA até que eles se tornem obsoletos ou sejam substituídos depois de uma busca bem-sucedida.

As instruções se complementam, mas não são intercambiáveis. A continuidade responde quais objetos continuam sustentando o cálculo. O alerta explica que o cálculo está se apoiando em uma evidência anterior, por qual motivo e em que parte da árvore de validação. Uma coleção de seis VRPs pode ser idêntica tanto numa rodada inteiramente nova quanto numa rodada parcialmente carregada do cache. O número não contém, por si, a proveniência temporal.

Essa distinção faz da observabilidade uma fronteira de segurança, não um acabamento. A decisão de preservar o cache reduz a perturbação no plano de controle; a decisão de avisar impede que a redução de perturbação seja lida como uma coleta normal. Se apenas o estado final atravessa o teste, o operador perde a capacidade de separar “seis resultados renovados” de “seis resultados, dois deles mantidos porque a coleta falhou”.

O teste vizinho torna a diferença visível

O mesmo conjunto de mudanças contém um caso comparável. No outro roteiro, o certificado da CA e o URI de manifesto no SIA mudam, configurando um SIA quebrado em vez da ausência transitória do manifesto da mesma instância. Nesse caso, o conjunto esperado exclui os VRPs da CA afetada e preserva os resultados da CA irmã e da nova CA. A checagem de alerta com check_logfile é executada.

O contraste não autoriza uma nota de qualidade para produtos. Ele permite uma conclusão mais útil: o Rapport já consegue distinguir continuidade de instância e continuidade do ponto de publicação, e já consegue afirmar um diagnóstico visível ao operador em um cenário adjacente. A lacuna observável é a falta de conexão entre essas duas capacidades no caso em que o cache deve sobreviver.

Também seria insuficiente aceitar qualquer linha marcada como alerta. O cenário de SIA quebrado retira o material da CA afetada; o cenário da mesma instância o retém. Os dois podem emitir aviso, mas precisam comunicar decisões diferentes. Uma asserção útil deve ligar a razão, a instância e o resultado de fallback. Caso contrário, o teste pode passar com um alerta sobre outro evento ou com a decisão de cache errada.

A frase do FORT não é o contrato

Descomentar a expressão regular existente seria uma mudança direta, porém transformaria a frase exata de um produto numa interface comum. Logs mudam capitalização, ordem e vocabulário por razões legítimas. Se qualquer ajuste de redação quebrar a suíte, a manutenção da checagem competirá com a estabilidade do teste. O resultado costuma ser um padrão amplo demais para ter valor ou uma asserção novamente desativada.

Uma suíte para vários relying parties precisa fixar a semântica, não a sentença. O evento comum deveria identificar a classe “manifesto não recuperado”, a instância de CA afetada, a decisão de usar o cache, a idade ou o limite de frescor desse cache, a severidade, o horário de emissão e o destino da notificação ou escalada. Um adaptador por implementação pode extrair esses elementos de um evento estruturado, métrica, log do sistema ou diagnóstico documentado.

Esse desenho não exige que todos os produtos se pareçam. Ele permite diferenças de texto e de transporte, mas recusa perdas essenciais. A causa não pode virar um erro genérico sem contexto. A instância afetada deve ser rastreável. A decisão de cache não deve ser inferida apenas do total de VRPs. E o tempo precisa permitir que o operador saiba se o estado foi guardado há segundos ou se está perto de atravessar seu limite de validade.

Um recibo com duas colunas

Cada execução deveria produzir, além do resultado sintético, um recibo de aceitação. A primeira coluna documenta a decisão de cache: identificador da instância de CA, impressão do certificado e do SIA atual, última busca bem-sucedida, conjunto ou resumo dos objetos guardados, limite de frescor, razão da falha atual, diferença entre VRPs mantidos e removidos, isolamento das CAs irmãs e próxima tentativa.

A segunda coluna documenta o sinal operacional: classe semântica encontrada, referência à CA, descrição explícita do fallback, idade do cache, severidade, instante de emissão e situação do encaminhamento para log, métrica, plantão ou escalada. Cada coluna deve apontar para a evidência original que sustenta a conclusão.

O formato impede dois atalhos. “Os VRPs sobreviveram” não significa “uma pessoa foi avisada”. “Houve um alerta” não significa “os objetos corretos sobreviveram”. As duas colunas precisam passar de forma independente para que a suíte demonstre a postura completa: o serviço continua com o último estado validado, e a perda de frescor não fica invisível.

A ligação à instância de CA merece atenção especial. Como várias instâncias podem compartilhar um ponto de publicação, a localização comum não prova a propriedade do cache. A impressão do certificado e do SIA, a última observação válida e o isolamento das CAs irmãs reduzem o risco de atribuir objetos antigos à instância errada. A mesma referência no evento de alerta torna a mensagem acionável, em vez de produzir apenas um aviso genérico sobre o repositório.

O que a evidência pública permite concluir

O LACNIC apresentou o Rapport como um testador de relying parties e o repositório o descreve como trabalho em estágio inicial. Essa condição não diminui o valor da suíte aberta. Ao contrário: scripts legíveis mostram como a linguagem normativa está sendo transformada em experimentos e onde ainda existe uma fronteira sem prova executada.

A revisão fixada sustenta quatro afirmações limitadas. A mudança de 4 de setembro de 2026 separou o caso de identidade alterada do caso de fallback da mesma instância. O segundo caso espera seis VRPs, inclusive dois do cache afetado. Seu comentário requer alerta, mas a linha de checagem está comentada. A RFC enuncia alerta e continuidade separadamente, enquanto o teste vizinho comprova que a infraestrutura pode checar logs.

Ela não sustenta uma acusação contra um validador, não revela uso de produção e não informa a intenção por trás do comentário. O próximo passo verificável não é adivinhar essas respostas. É dar nome aos dois eixos e fazer a suíte entregar uma prova independente para cada um.

Fontes