Resumo

  • O roteiro do programa RPKI do NRO, atualizado em dezembro de 2025, listou certificados de Trust Anchor de curta duração como recurso essencial, então oferecido por APNIC, ARIN e LACNIC, com meta de adoção pelos cinco RIRs até o fim de 2025.
  • Em 29 de agosto de 2026, o TAL publicado pela AFRINIC ainda levava a um certificado raiz autoassinado válido de 30 de março de 2020 a 28 de março de 2030.
  • A comparação expõe uma lacuna de comprovação, não uma interrupção nem uma falha de validação demonstrada. As fontes verificadas não definem o limite de “curta duração” nem publicam uma exceção da AFRINIC.
  • Um comprovante de entrega deve ligar definição, emissão, impressão digital, continuidade da chave do TAL, disponibilidade do repositório, observação de atualização, exceções, reversão e correções.

O prazo passou; o estado seguinte não foi registrado

Uma única linha do roteiro do NRO contém o compromisso. O recurso é “Short-lived TA certificates”. APNIC, ARIN e LACNIC aparecem como os registros que já o ofereciam. Para todos os RIRs, a data indicada é “End of 2025”.

A página foi modificada pela última vez em 2 de dezembro de 2025. Era, portanto, uma projeção pouco antes do prazo, não um termo de aceite produzido depois dele. Não há problema em um roteiro olhar para a frente. O problema surge quando a data passa sem que a página ganhe um segundo registro capaz de distinguir entrega, adiamento, exceção, redefinição ou pendência.

O material público da AFRINIC permite observar o outro lado. Em 29 de agosto de 2026, seu Trust Anchor Locator estava acessível e apontava primeiro para AfriNIC.cer no repositório RPKI. O certificado autoassinado se identificava como AfriNIC-Root-Certificate, tinha série E5CF72BA6C7E9E28 e validade entre 30 de março de 2020 e 28 de março de 2030.

O arquivo estava disponível, o endereço respondia e sua impressão digital podia ser conferida. Nada disso indica incidente. O fato delimitado é que, oito meses depois da meta comum, o objeto servido pela AFRINIC continuava exibindo um intervalo de aproximadamente dez anos, e a documentação do programa não explicava como esse estado se relacionava com a expressão “curta duração”.

Há explicações benignas plausíveis. O roteiro pode estar desatualizado. A AFRINIC pode usar uma definição não ligada naquela página. A mudança pode estar em teste, ter sido adiada ou receber uma exceção. O certificado atual pode permanecer até uma reemissão controlada. O conjunto de fontes não autoriza escolher uma dessas versões.

A lacuna é, antes de tudo, de prova pública. Depois de anunciar um prazo, a instituição não deveria obrigar o operador a imaginar o estado posterior.

“Curta duração” precisa de critério antes de virar conclusão

Dez anos parecem longos diante do rótulo. Ainda assim, declarar a meta descumprida exigiria inventar a condição de aceite que o material consultado não fornece.

O roteiro não fixa duração máxima, periodicidade de renovação, janela de sobreposição nem autoridade para exceções. A linha de base que compara serviços dos RIRs também não traz um aceite datado para a AFRINIC. Dois anos, um ano ou noventa dias não podem ser tratados como regra sem fonte.

O intervalo observado continua relevante porque pertence a um artefato operacional obtido no URI publicado pelo TAL. Ele mostra o que estava disponível em um instante verificável. Não define a política ausente nem substitui a decisão institucional sobre cumprimento.

Há três coisas distintas. O compromisso diz o que se pretendia entregar. O artefato mostra o que um observador recuperou. O comprovante operacional declara se o artefato satisfaz a definição acordada, se há exceção ou se a tarefa permanece aberta. Misturar os três transforma anúncio em implementação.

Um registro competente pode usar estados simples: entregue segundo a definição publicada; entregue com exceção identificada; adiado para nova data; substituído por outro controle; não concluído. Silêncio não é um sexto estado técnico.

O TAL fixa a chave, não o mesmo certificado para sempre

O RFC 7730 mostra por que reduzir a validade do certificado não exige necessariamente redistribuir uma nova decisão de confiança a cada operador.

O TAL contém locais de recuperação e material de chave pública usado para verificar o certificado do Trust Anchor. O objeto referenciado deve ser um certificado CA de RPKI atual e autoassinado, e a chave pública precisa corresponder àquela registrada no TAL. A chave da âncora deve permanecer estável quando o certificado é reemitido por renovação comum ou mudança de recursos. O certificado novo continua acessível no URI estável.

Continuidade de chave e vida do certificado são, portanto, estados separados. A AFRINIC pode manter a relação de confiança fixada no TAL e reemitir o certificado que expressa datas e recursos atuais. Renovação de certificado não significa, por si, troca da chave da âncora.

A arquitetura também divide a entrega em etapas. É preciso emitir o objeto correto, publicá-lo no endereço esperado, permitir que o software de relying party o recupere, confira vigência e autoassinatura, compare a chave com o TAL e execute seus testes locais. O RFC recomenda recuperar e verificar o certificado durante a ressincronização do repositório e antes que a cópia em cache expire.

Assim, até uma nova emissão seria insuficiente para provar toda a transição. A evidência útil liga política de duração, emissão, correspondência de chave, publicação, recuperação observada, exceções e correção.

Essa cadeia não é evidência de estado de rotas. O pacote não mostra rota tornando-se RPKI Invalid, roteador rejeitando prefixo, falha de atualização ou operador mantendo objeto incorreto. Cada efeito exigiria observação própria.

Um relógio menor redistribui o risco

O melhor argumento a favor de certificados mais curtos não é que “curto” seja automaticamente seguro. Uma validade reduzida pode limitar o período em que um estado antigo continua aceitável e transformar a renovação em disciplina rotineira.

O benefício depende do restante da automação. Emissões mais frequentes exercitam publicação e recuperação, revelando defeitos mais cedo. Ao mesmo tempo, deixam menos tempo para corrigir atraso de emissão ou indisponibilidade perto do vencimento.

Certificados longos reduzem a frequência desses pontos críticos, mas mantêm por mais tempo uma expressão antiga de datas e recursos. O desenho troca uma distribuição de falhas por outra; não elimina risco.

Por isso, “implementado” não deveria significar apenas que existe código capaz de emitir o certificado. O registro deve dizer qual objeto de produção materializa a política, quando começou a mudança, como estados antigo e novo se sobrepuseram, como o repositório foi testado, qual amostra de validadores foi observada e qual é o gatilho de reversão.

Chaves privadas, arranjo de HSM e procedimentos aproveitáveis em ataque não precisam aparecer. Datas, hashes, classes de resultado e observações agregadas oferecem transparência sem expor o sistema.

O comprovante operacional mínimo

O primeiro bloco deve definir a característica: validade normal, antecedência de renovação, regra de sobreposição e responsável pela exceção. Se “curta” for uma comparação relativa, a referência deve estar explícita.

Depois vêm os fatos públicos do certificado: RIR emissor, número de série, impressão digital SHA-256, notBefore, notAfter, URI do repositório e confirmação da correspondência com a chave do TAL.

O registro precisa separar o ponto de publicação autoritativo, a amostra declarada de relying parties monitoradas e a população que não foi medida. Sucesso numa amostra não prova atualização de todos os validadores da Internet.

Uma exceção pode ser transparente sem revelar deliberação sensível: identificador, classe de motivo, responsável, data de revisão e condição de encerramento bastam. Correções devem ser aditivas. Se uma impressão digital, data ou classificação mudar, o estado anterior deve permanecer visível.

Um teste da AFRINIC dentro de uma promessa conjunta

O programa RPKI do NRO coordena cinco organizações. Pode aproximar definições, tornar serviços comparáveis e reduzir diferenças desnecessárias para quem mantém recursos em mais de uma região.

Coordenação não transforma o NRO no operador da autoridade certificadora da AFRINIC. A AFRINIC emite e publica seu material. Desenvolvedores de relying parties controlam recuperação e aceitação no software. Operadores controlam implantação, monitoramento e a política de roteamento que consome os dados validados.

A conclusão é estreita. O certificado da AFRINIC oferece uma observação reproduzível dentro de um compromisso compartilhado. Não prova serviço quebrado nem descrição deliberadamente falsa pelo NRO. Mostra que a cadeia pública ainda não liga a meta do fim de 2025 a um estado de produção da AFRINIC aceito sob uma definição visível.

É possível fechar a lacuna sem drama. O NRO pode conservar a linha histórica e acrescentar definição, estado por RIR, data da evidência e exceção. A AFRINIC pode publicar sua política de validade e os fatos limitados de aceite da próxima emissão. A âncora de confiança deve ser entediante na operação; o caminho entre compromisso e produção deve ser reconstruível.

Sources