Resumo

  • A RFC 9691 permite anunciar uma chave sucessora em um objeto TAK, mas a parte confiante continua usando a chave atual durante o prazo de aceitação de 30 dias.
  • A validação exige referências recíprocas entre as chaves e estabilidade das chaves e URLs ao longo do prazo.
  • A migração de um validador não comprova a adoção por todos os demais.

O TAL da RFC 8630 informa onde buscar o certificado da autoridade de confiança e contém a chave pública usada para confirmar que o certificado autoassinado recuperado é o correto. Como esse ponto inicial de confiança é distribuído fora da própria hierarquia, sua troca não é uma atualização comum do repositório.

A RFC 9691 cria o objeto assinado TAK. Ele pode indicar a chave atual e os endereços de seu certificado, além da chave sucessora e dos endereços correspondentes. Ver a sucessora não basta. A parte confiante valida a hierarquia com a nova chave e confere a continuidade em duas direções: o TAK atual aponta para a sucessora, e o TAK sucessor reconhece a atual como predecessora.

Na primeira verificação bem-sucedida, começa um prazo de aceitação de 30 dias. A validação de produção permanece na chave atual. Nas execuções seguintes, as chaves e URLs anunciadas devem continuar iguais. Se a sucessora desaparecer ou falhar na verificação, o prazo é cancelado. A mudança só ocorre depois de sua conclusão nas condições definidas.

Assim, a publicação pelo operador, a verificação por uma parte confiante, a observação contínua e a efetiva migração são fatos diferentes. Nenhum deles, isoladamente, demonstra a convergência da população inteira.

Há também clientes sem suporte a TAK. Eles continuam usando a chave do TAL ou de uma configuração manual. A RFC 9691 reconhece que o operador pode precisar manter pares antigos e novos e publicar seus materiais em diretórios separados. Um cliente preso a um TAL antigo e outro ainda dentro do prazo de 30 dias exigem respostas diferentes.

A RFC 6489 oferece disciplina semelhante para a troca de chaves de uma CA: prepara uma nova instância, publica certificado, CRL e manifesto, aguarda o período de preparação, reedita os produtos subordinados e só então retira a antiga. A RFC 6916 separa ainda os marcos de prontidão das CAs, reemissão, prontidão das partes confiantes, transição e fim de vida em uma migração de algoritmos.

O registro de aceitação deve ligar as impressões digitais das chaves, o conjunto de URLs, os hashes dos TAKs, a primeira verificação, o início e a continuidade do prazo, a hora da migração e a identidade e versão do validador. Para grupos que dependem de TAL, deve guardar separadamente o período de suporte e a decisão que autoriza seu encerramento.

Esse registro é uma inferência editorial de governança, não uma nova exigência atribuída às RFCs. Ele conserva o alcance de cada prova e impede que uma observação local vire alegação universal.

Fontes