Resumo

  • No RFC 9691, cada Relying Party inicia seu próprio prazo de 30 dias após verificar pela primeira vez a mesma relação sucessora; não existe um cronômetro global.
  • A transição só é demonstrável quando TAKs recíprocos, histórico local, equivalência dos repositórios, raiz usada em produção e aposentadoria de A permanecem separados e ligados.

O RFC 8630 usa o TAL para entregar a uma Relying Party a chave pública do Trust Anchor e os endereços do certificado. Reemitir o certificado sem mudar a chave é simples. Trocar a chave exige alterar o ponto de partida da confiança.

O RFC 9691 cria o objeto TAK assinado. O TAK de A anuncia B como sucessora. O de B declara A como predecessora. O validador precisa percorrer B, validar seu TAK e conferir os dois sentidos da ligação. Uma única declaração não basta.

Essa reciprocidade autentica um caminho planejado. Ela não mede quantos validadores o observaram, quais mantiveram a observação sem interrupção, quais aceitam atualização automática nem qual chave está em uso real.

Cada primeira observação abre um prazo diferente

O validador inicia 30 dias quando B passa na verificação e não aparecia na execução bem-sucedida anterior. Durante o prazo, A continua sendo a raiz de produção; B serve para teste. Depois do vencimento local, com a relação ainda válida, aquela instância pode adotar B e reiniciar a validação.

Se B falha ou some, o relógio é cancelado. Se a chave ou o conjunto de URI muda, começa uma nova oferta. Um serviço contínuo pode iniciar no primeiro dia; uma máquina parada começa depois; uma instalação fria começa meses depois. Software sem TAK continua com o TAL, e software configurado para decisão manual apenas alerta o operador.

O recibo precisa conter identidade e versão do validador, TAL local, impressões A e B, URI, execução anterior, primeiro sucesso, cancelamentos, reinícios, vencimento e raiz efetivamente selecionada. “Publicado há 30 dias” não informa quem aceitou.

O RFC desaconselha retirar B e recolocá-la idêntica. Quem perdeu o intervalo pode conservar o prazo antigo e migrar antes. Alterar os URI da sucessora força novo relógio mesmo mantendo a mesma SubjectPublicKeyInfo. O histórico de coleta participa da decisão.

Dois repositórios não ficam equivalentes por assinatura

Durante a sobreposição, a TA mantém A e B em diretórios diferentes. Certificados, recursos IP e AS e delegações precisam produzir resultados equivalentes, exceto pelos próprios TAKs.

Com um servidor, as operações RFC 8181 dos dois lados devem seguir numa só consulta. Com vários, pode haver defasagem curta. Revogação e redução só se completam quando todos os pontos mudam; extensão de recursos não deve ser informada ao filho antes de todos estarem prontos.

Por isso, valide e compare as projeções sob A e B: recursos, delegações, certificados, manifests, CRLs e gerações. A equivalência é semântica, não igualdade de bytes. Um TAK correto não prova essa sincronização operacional.

A retirada de A transforma atraso em recuperação manual

As quatro fases são distintas: manter um TAK só com A; criar B e a ligação recíproca; distribuir um TAL B mantendo A para clientes antigos; remover o repositório A e destruir a chave privada.

URI diferentes entre TAL e TAK podem ajudar a estimar o canal utilizado, mas silêncio não é censo. Pode significar migração, parada, cache, pacote atualizado ou falta de suporte. A explicação da APNIC em 2025 dizia que os RIRs investigavam implementação no programa RPKI da NRO; isso não demonstra adoção universal.

Depois da retirada, uma instância que só conhece A não consegue validar o caminho para aprender B e exige reparo local. Se perdeu várias gerações, pode cumprir um prazo por salto. Manter A indefinidamente preserva continuidade e também preserva uma autoridade antiga.

O TAK não corrige comprometimento da raiz atual. Quem controla A já controla seus objetos. Converter um TAK fora de banda em TAL também transfere confiança para o distribuidor quando o objeto não está enraizado numa TA já aceita.

Os RFC 6487, 6488, 9286 e 6481 separam certificados, objetos, manifests e repositórios. O RFC 9319 fica adiante: trocar a raiz não prova instalação no roteador nem entrega de pacotes.

A especificação mínima de Lu Heng mantém comum apenas o necessário e deixa decisões futuras localmente responsáveis. Suas camadas de realidade impedem que publicação, estado do validador e resultado de rede se substituam. A primazia do código em execução coloca a observação real acima do calendário.

Fontes