Resumo

  • RFC 9589 torna CMS signing-time obrigatório em RPKI Signed Objects e exclui binary-signing-time.
  • O operador do repositório e o relying party podem gravar esse valor como mod-time nas cópias rsync e RRDP, evitando retransfers desnecessários após falha de RRDP.
  • O atributo não prova quando houve assinatura, publicação, validade de certificado, inventário atual ou encaminhamento de tráfego.

Uma convenção para duas formas de entrega

RRDP entrega snapshots e deltas; rsync compara árvores de arquivos. São caminhos de entrega, não tribunais de verdade. XML inválido, TLS expirado ou timeout podem levar o relying party de RRDP para rsync quando ele já guarda objetos DER obtidos antes.

No teste rápido de rsync, tamanho e tempo de modificação iguais podem dispensar a cópia. Se a materialização de RRDP recebe a hora do download e o servidor rsync conserva outra hora, o primeiro fallback pode mover de novo objetos que já estavam presentes. RFC 9589 estabelece a ponte: o emissor inclui signing-time; o repositório deveria colocá-lo no mod-time do arquivo rsync; o relying party deveria fazer o mesmo para a cópia materializada de RRDP. Assim ambas as vistas carregam o mesmo sinal de comparação.

Isso reduz banda, I/O e CPU em uma falha. Não decide aceitação. É uma ajuda para escolher se se transfere o arquivo, não uma declaração de que o objeto representa o estado atual.

Assinado não significa cronometado

A assinatura protege o valor que veio no objeto contra alteração em trânsito. Ela não garante relógio correto, não demonstra quando a chave foi usada nem quando os bytes foram publicados. A seção de segurança de RFC 9589 é explícita: não há requisito de correção do atributo e ele não fornece informação confiável sobre a hora de produção da assinatura.

Essa estreiteza é intencional. Para reutilizar um arquivo entre RRDP e rsync basta a consistência do valor para o mesmo objeto. Uma linha do tempo operacional exige logs controlados e observação de publicação. Uma decisão de validade exige a cadeia RPKI. Também tamanho mais mod-time igual não é prova criptográfica de bytes iguais; é apenas o atalho de transferência de rsync.

O que continua sob outra autoridade

O objeto precisa passar o perfil CMS de RFC 6488 e a validação própria do tipo. Seu certificado EE precisa encadear e não estar revogado. O manifesto atual de RFC 9286 é o inventário assinado. RFC 9829 define a CRL relevante como aquela apontada pelo certificado e listada, com hash correspondente, no manifesto atual da CA.

Uma ROA válida permanece uma autorização limitada de origem de prefixo. Não prova anúncio atual, seleção por vizinhos, instalação no roteador ou alcance de pacote. Uma resposta RRDP, um fallback rsync ou um arquivo omitido não estendem essa autoridade.

O registro operacional deve percorrer URI e hash, decisão de transferência, certificado, CRL, manifesto, validação do objeto, impressão do conjunto validado e a entrada posterior de política. Sucesso de transporte só demonstra transporte.

Ensaiar a troca implantada

Inclua no corpus: RRDP normal e rsync com bytes iguais, XML defeituoso, TLS expirado, timeout, arquivo ausente, tamanho ou mod-time diferente, certificado revogado e objeto ausente do manifesto. Por produto e versão, guarde caminho, hash, signing-time, tempos locais/remotos, tamanho, decisão de cópia, resultados de certificado/CRL/manifesta e fingerprint de saída.

Diferenças entre validadores são evidência. Menos bytes com conjunto aceito diferente não é vitória; mais bytes com a mesma saída pode ser apenas custo. Rodar o teste no caminho real é mais valioso que uma promessa de compatibilidade.

Fontes