Resumo

  • O número de um manifesto RPKI ordena localmente os inventários assinados de uma única CA. Não é relógio global nem prova do que a rede está encaminhando. Como a codificação tem limite, uma emissão defeituosa pode impedir que qualquer sucessor seja maior que o valor já aceito.
  • Pela RFC 9981, um nome de manifesto diferente estabelece uma nova época de comparação. O relying party precisa alertar o operador, e a CA não deve usar a troca de nome como rotina.
  • Só a referência numérica guardada recomeça. A cadeia criptográfica, um thisUpdate posterior, a lista de arquivos e hashes e a correspondência exata do URI assinado com RRDP ou rsync continuam obrigatórios.

Um sucessor mais novo que jamais poderia ser maior

Considere uma CA prestes a emitir o manifesto 7.914. Um erro no software grava 2^159 - 1, o maior valor possível no campo. A chave correta assina o objeto, as datas são válidas e o inventário descreve com precisão o ponto de publicação. Alguns relying parties aceitam e memorizam o número.

O operador corrige o contador e emite outro manifesto. Ele é posterior no mundo real, tem assinatura válida e conteúdo coerente. Ainda assim, a comparação antiga o torna impossível: nenhum valor permitido supera o máximo já armazenado.

Duas provas se chocam. A assinatura atribui a nova declaração ao emissor. A sequência diz que ela não pode seguir a declaração anterior. Ignorar a sequência enfraquece a defesa contra repetição; obedecê-la para sempre congela o ponto de publicação.

A RFC 9981 escolhe a menor ruptura que CA e validador conseguem observar: outro nome de arquivo. Não concede poder geral de apagar histórico. O nome abre uma época nova para o contador, enquanto as demais evidências atravessam a fronteira.

O que o manifesto realmente registra

Um manifesto RPKI é o inventário assinado dos arquivos que uma CA pretende disponibilizar em um ponto de publicação. Cada nome vem associado a um hash, permitindo detectar ausência, substituição ou visão incompleta do repositório.

O manifesto também é um objeto assinado RPKI, sustentado por certificado EE de uso único. Ele contém manifestNumber, thisUpdate, nextUpdate, algoritmo de hash e pares de nome e impressão. O certificado da CA aponta para ele por meio da SIA id-ad-rpkiManifest.

Esse testemunho tem limite claro. A presença de um ROA não prova que uma rota esteja visível no BGP. A presença de uma CRL não mostra que todos a buscaram. Um VRP produzido não prova que chegou ao roteador. O manifesto fala da camada de publicação; validação e encaminhamento pertencem a camadas seguintes.

Essa precisão mantém a recuperação proporcional. A confiança RPKI inteira não quebrou. Tornou-se impraticável continuar a história numérica de uma CA sob um nome específico. A correção pode permanecer local.

Um campo astronômico também é finito

A RFC 9286 manda incrementar o número em uma unidade para cada novo manifesto. O relying party espera valor maior que o último aceito. Um salto pode indicar estado intermediário ausente; uma regressão pode denunciar objeto antigo ou repetido.

O número não é comparável entre CAs e não substitui tempo. Mesmo dentro da mesma autoridade, thisUpdate, nextUpdate, validade, revogação e as verificações do objeto assinado continuam separadas.

A RFC 9981 explicita o limite: INTEGER positivo em até 20 octetos, com máximo de 2^159 - 1. Emitindo um por segundo, o esgotamento normal levaria cerca de 23.171.956.451.847.141.650.870 quintilhões de anos. Não se trata de capacidade.

O risco é software: incremento exagerado, laço de emissão sem espera, restauração de estado corrompido ou atribuição acidental do máximo. Uma falha consegue atravessar a distância astronômica de uma vez.

Depois da aceitação, implementações podem divergir. Uma esquece o estado após expiração; outra rejeita números menores indefinidamente. O mesmo repositório parece atual para um grupo e congelado para outro. A memória dos relying parties passa a integrar o incidente.

O nome como fronteira explícita

Quando o nome do manifesto difere daquele antes associado à CA, a RFC 9981 impede rejeição apenas porque o número não é maior. Se as outras verificações passarem, o relying party registra o valor sob o nome novo e inicia outra época.

O nome não é rótulo livre de painel. Ele é o último segmento do URI id-ad-rpkiManifest no certificado da CA. A autoridade precisa nomear a localização nova, publicar nela e manter coerência com o URI signed-object do certificado EE.

A transição deixa três fatos auditáveis: o certificado designa outro caminho, o repositório entrega o objeto nesse caminho e o validador muda a chave de comparação. Não é necessário um coordenador decretando reinício global, nem uma heurística supondo que número pequeno deve ser recente.

O relying party deve alertar o operador. A mudança pode ser recuperação legítima, transição planejada, erro ou indício de comprometimento. A assinatura mostra quem declarou; não explica por que abandonou o histórico anterior.

A CA não deve rotacionar nomes rotineiramente. Se toda reinicialização ou atualização abrir uma época, a sequência deixa de revelar retrocessos e histórias antigas ganham novas oportunidades de parecer atuais.

O que não é reiniciado

“Nome novo, aceitar” é uma leitura perigosa. A regra só escolhe qual manifestNumber armazenado serve de referência.

O manifesto ainda exige assinatura válida, certificado EE válido e cadeia até a CA. Permanecem validade, revogação, perfil RPKI, estrutura, algoritmo, inventário e tratamento de arquivos ausentes ou hashes divergentes.

O tempo permanece. O thisUpdate do novo manifesto precisa ser posterior ao último aceito. Um inventário velho não ganha frescor ao ser copiado para outro caminho. nextUpdate continua delimitando o intervalo declarado.

A localização permanece. O URI signed-object no certificado EE deve corresponder exatamente ao publish URI RRDP ou ao caminho rsync usado na obtenção. Copiar bytes sob outro nome sem alinhar referências assinadas não cria a época da RFC.

O manifesto tampouco altera os arquivos listados. Pode tornar um inventário elegível para validação, mas não muda recursos de certificado, prefixos de ROA, revogação ou a entrada consumida pelo roteador.

A armadilha de múltiplas SIA

Um certificado de CA pode trazer várias descrições SIA de manifesto. Relying parties podem escolher localizações diferentes. Se o certificado substituto remover um nome antigo e conservar outro, alguns verão nova época; outros acreditarão que a antiga continua.

Ambos podem seguir corretamente o URI escolhido e chegar a resultados opostos. Quem usa o nome novo aceita o número baixo. Quem usa o nome antigo compara com o máximo e rejeita. A diferença pode parecer cache, atraso RRDP ou falha de produto.

Por isso, ao depender da mudança de nome, a RFC 9981 exige que nenhum nome antigo permaneça no novo certificado. É preciso inventariar todas as SIA, caminhos e preferências. Trocar somente a localização considerada principal não basta.

RRDP e rsync são transportes, não verdades alternativas. Snapshot, delta e visão rsync devem convergir em objetos cujos bytes e URIs assinados coincidam. Uma resposta HTTP bem-sucedida comprova entrega, não autorização criptográfica do local.

Por que a âncora de confiança é mais difícil

Uma CA subordinada normalmente pode fazer troca de chave sob o pai, criar outra identidade e recomeçar a história de manifestos. Ainda precisa de sobreposição e continuidade, mas existe autoridade superior para vincular a passagem.

Uma âncora de confiança não tem pai. Sua chave e as localizações do certificado chegam aos relying parties em geral por TAL. Trocar chave ou distribuir novo TAL enfrenta ritmos diferentes de atualização, instalações antigas e risco de perder a árvore inteira para validadores presos ao material anterior.

A RFC 9691 melhora transições planejadas com objetos TAK. A âncora atual anuncia chave sucessora e localizações; os validadores conferem referências recíprocas e aguardam um período de aceitação antes da mudança.

TAK não é uma porta mágica ao redor de um ponto de publicação quebrado. O relying party parte da chave já confiada, busca o certificado, valida manifesto e CRL e só então processa TAK. A continuidade deve ser preparada antes da emergência, separadamente da recuperação por nome.

Recuperação é convergência observável

Assinar outro arquivo não conclui a recuperação. Ela termina quando implementações independentes obtêm o objeto exato, reconhecem a época RFC 9981, validam o inventário e convergem nas saídas esperadas.

O ensaio seguro usa material capturado ou sintético, nunca aproxima o contador de produção do máximo. Deve incluir sequência normal, salto, máximo, número baixo no mesmo nome, número baixo no nome novo, thisUpdate antigo, URI assinado divergente e certificado que conserva uma SIA velha.

Por produto e versão, registram-se URI, nomes, número guardado, comparação temporal, alerta, resultado, objetos aceitos e delta de VRP. Diferenças mostram suporte e estado antes de uma CA real depender da saída.

Em produção, preservam-se certificado e manifesto antigos, todos os URIs, números, tempos e impressões de saída. Registram-se motivo, aprovadores, novas SIA e efeito esperado. RRDP snapshot, delta, rsync, validadores e alimentação dos roteadores são comparados antes da retirada do material antigo.

Se o novo objeto falhar em assinatura, tempo, URI ou inventário, outro nome não é rollback. A emissão para, a evidência fica preservada e o último estado comprovado é restaurado quando as regras permitem. Reinícios repetidos transformam exceção controlada em história incompreensível.

Fontes