Resumo

  • RFC 9674 exige que URIs de Snapshot e Delta e todos os destinos de redirecionamento mantenham a mesma origem — esquema, host e porta — da notificação RRDP.
  • Uma migração para outro CDN ou nome pode preservar os bytes e ainda retirar a autoridade de recuperação; hash correto não conserta um salto entre origens.
  • Aprovar a origem só inicia a cadeia: estrutura e estado RRDP, hashes, certificados, CRL, manifesto, objetos assinados, cache validado, sessão do roteador e política local continuam independentes.

O plano de migração dizia que nada mudaria para o consumidor: mesmo arquivo, mesma equipe, certificado válido e um CDN mais próximo. O endereço antigo responderia com redirect para o novo. O Snapshot realmente chegou e seu hash bateu. Ainda assim, RFC 9674 manda o Relying Party rejeitar a sessão quando o destino pertence a outra origem.

Essa recusa não discute a qualidade do CDN. Ela preserva a fronteira que a notificação recebeu ao ser descoberta pelo certificado. O fato de a infraestrutura ser administrada pela mesma empresa não altera esquema, host e porta.

Distribuição não pode ampliar autoridade em silêncio

RFC 8182 define o rpkiNotify no SIA do certificado de recursos. A URI leva ao Update Notification File, que declara session, serial, um Snapshot e uma cadeia opcional de Deltas. Os arquivos podem ser distribuídos e armazenados em cache porque cada versão imutável é ligada por hash.

A especificação original não proibia de forma explícita uma referência a outro origin e não tratava do redirect HTTP para outro principal. RFC 9674 corrige a lacuna. O servidor deve publicar Snapshot e Delta na mesma origem da notificação e não pode redirecionar para fora. O cliente deve comparar e rejeitar, registrando o evento.

RFC 6454 fornece a unidade de comparação. Origem não é o registrante do domínio, o grupo empresarial nem a conta do provedor. É o conjunto scheme/host/port. Trocar HTTPS por HTTP, repo.example por cdn.example ou 443 por 8443 altera o principal do protocolo.

Essa precisão evita uma cadeia de exceções baseadas em narrativas internas. Se “mesmo operador” bastasse, cada terceirização exigiria que o validador entendesse contratos e topologias que não aparecem na URI.

Redirect bem-sucedido ainda é uma ação sem autorização

RFC 9110 explica que um redirect pede ao agente outra ação em outra URI. O status 200 no fim da cadeia não reescreve o caminho. Por isso um monitor RRDP deve guardar a URI SIA, a origem normalizada, cada referência, cada resposta e Location, e a decisão tomada antes de seguir.

O hash também não é procuração. Ele compara o arquivo obtido ao compromisso da notificação. Não autoriza o uso dos recursos do servidor que entregou esse arquivo. RFC 9674 reduz justamente a possibilidade de um repositório fazer muitos clientes e outro repositório gastarem recursos por meio de referências cruzadas.

Same-origin responde apenas ao lado da autoridade. Um servidor dentro da origem pode devolver XML inválido, cadeia de Delta incompleta, serial impróprio ou bytes que não correspondem ao hash. O controle de origem não substitui esses testes.

A sincronização ainda não validou os objetos

RFC 8182 requer que a notificação seja bem formada e siga o schema. O session_id precisa ser associado à localização da notificação. Deltas usados devem formar sequência contínua. Snapshot e Delta devem casar com os hashes declarados e com session/serial esperados.

Se um Delta falhar, o RP pode recorrer ao Snapshot. Se o Snapshot falhar, RRDP não pode ser usado. Outro access method indicado no SIA pode ser tentado, mas abre uma nova cadeia de aquisição; não apaga a decisão anterior.

RFC 6480 separa a PKI de recursos, os objetos assinados e o repositório que os distribui. RFC 6487 especifica certificados, CRLs e validação de caminho. RFC 9286 dá ao manifesto número, tempos e inventário de arquivo/hash.

Um Snapshot recebido da origem permitida pode, portanto, conter material que falha mais tarde. Recuperação autorizada não é assinatura, atualidade, completude nem decisão de confiança.

O roteador não está dentro da origem HTTP

RFC 7115 chama de cache validado o conjunto efetivamente verificado pelo RP. RFC 8210 cria outra relação entre cache e roteador, com versão, session e serial próprios. RFC 6811 define estados de validação de origem que entram numa política local.

Assim, o indicador completo não pode ser uma única luz. É preciso distinguir: origem autorizada; integridade RRDP; validação de objetos; payload emitido; ingestão do roteador; política; rota selecionada; resultado observado. A falha de uma camada não descreve automaticamente as anteriores ou posteriores.

Da mesma forma, detectar cross-origin não prova intenção hostil. Prova que a regra foi violada. Aprovar same-origin não prova que o operador seja confiável ou que o tráfego tenha seguido determinada rota.

A evidência de implantação tinha janela

RFC 9674 registra que não encontrou referências cross-origin nas notificações dos arquivos examinados entre outubro de 2021 e outubro de 2024. Em outra janela de 2024, encontrou um servidor usando redirect same-origin. A conclusão era de deployability: a regra não tornaria não conforme uma operação comum então observada.

Não é uma medição global atual. Preservar data, população e pergunta impede que o número seja reciclado como garantia.

A mesma disciplina vale para mudanças internas. Antes de migrar distribuição, a organização deve comparar todas as URIs e redirects como o cliente fará. Depois, deve observar rejeições, fallback e estado do RP sem confundir essa telemetria com validação e roteamento.

A leitura de especificação inicial mínima mantém a regra comum pequena: uma notificação não delega além da sua origem. As camadas de realidade separam organização, endereço, arquivo, objeto validado e rota. A primazia do código em execução exige recibos do RP, cache e roteador antes de qualquer afirmação operacional.

RFC 9674 não escolhe a rota. Ele impede que o caminho de obtenção finja não ter autoridade própria.

Fontes