Resumo

  • A RFC 9323, de Job Snijders, Tom Harrison e Ben Maddison, permite verificar que uma chave autorizada para um subconjunto de endereços IP ou números de sistema autônomo assinou uma lista com os hashes exatos de arquivos determinados.
  • Uma RSC válida não identifica uma pessoa, não confirma poderes societários, não declara o conteúdo verdadeiro e não obriga o destinatário a aceitar BYOIP ou interconexão. Identidade, contrato, finalidade e risco operacional continuam sendo decisões separadas.

O comprovante que não aprova a operação

Quando um cliente leva seus próprios endereços a uma nuvem, a plataforma precisa associar a solicitação aos recursos corretos. Pode haver carta de autorização, formulário, configuração e outros anexos. O provedor quer saber se o pacote foi alterado e se a assinatura está ligada ao prefixo ou ASN em questão.

Essas respostas não bastam para ativar o serviço. A pessoa que enviou o material pertence à conta? Pode representar a empresa? O contrato permite o anúncio? Há outra rede usando o prefixo? A mudança pode provocar vazamento ou indisponibilidade? Cada pergunta pertence a uma camada diferente.

A RFC 9323, publicada em novembro de 2022 como Proposed Standard do IETF, resolve uma parte estreita. Job Snijders, Tom Harrison e Ben Maddison definiram a RPKI Signed Checklist, ou RSC, um objeto CMS com recursos de numeração, algoritmo de resumo e uma lista de hashes de arquivos externos.

Os arquivos ficam fora do objeto. O destinatário calcula os hashes de suas cópias e procura correspondência. Se a validação passar, ele sabe que uma chave autorizada, segundo a cadeia escolhida, para aquele subconjunto de recursos assinou uma lista que aponta para aqueles bytes.

Não sabe se o texto é verdadeiro, atual ou juridicamente suficiente. Também não sabe se o operador da chave possui mandato corporativo. A precisão da RSC nasce dessa recusa em responder por evidências que ela não contém.

O IETF Datatracker registra a atuação de Snijders em segurança de roteamento. O OpenBSD o cita entre os principais desenvolvedores do rpki-client e como mantenedor da versão portátil. O traço comum é transformar alegações operacionais em testes delimitados, em vez de prometer confiança universal.

O conteúdo da checklist

Uma RSC traz ao menos um bloco de endereços IP ou identificador de sistema autônomo. Declara um algoritmo de hash e inclui um ou mais elementos. Cada elemento contém um resumo e pode conter um nome de arquivo.

Os recursos listados precisam formar um subconjunto dos recursos do certificado de entidade final embutido. A chave não consegue ampliar sua autoridade escrevendo outro prefixo na lista. Se o escopo ultrapassar o certificado, a validação deve rejeitar o objeto.

O hash compromete o signatário com uma sequência exata de bytes. Mudar data, vírgula, anexo ou codificação tende a produzir outro valor. Isso detecta substituição. Não interpreta a linguagem nem testa se as afirmações do documento correspondem à realidade.

O nome do arquivo é opcional. Na validação sensível ao nome, nome e hash devem coincidir. Na validação que não usa nome, o elemento correspondente deve omiti-lo. O fluxo decide se precisa atestar um pacote nomeado ou apenas o conteúdo exato.

Essa diferença evita que o rótulo faça o trabalho da prova. Um arquivo chamado autorizacao.pdf pode ser inválido; o mesmo conteúdo pode ser renomeado sem mudar um byte. A política do recebedor deve dizer qual objeto está comparando.

Certificado descartável não é identidade permanente

Cada RSC usa um novo par de chaves e um certificado de entidade final de uso único. A chave privada deve ser destruída depois da assinatura. O certificado omite SIA porque a checklist não será buscada no repositório RPKI público.

O arranjo desencoraja o uso do certificado como login duradouro, crachá pessoal ou selo empresarial. Sua função é validar um objeto específico e um conjunto limitado de recursos. Expiração ou revogação ainda podem mudar o resultado segundo as regras de objetos assinados da RPKI.

A RFC 6480 define a fronteira original: certificados de recursos vinculam uma chave pública a endereços IP ou ASNs, mas não atestam a identidade descritiva do sujeito. A RSC herda essa limitação.

A RFC 9255 afirma que credenciais RPKI não devem autenticar documentos ou transações do mundo real. Uma conta de gerenciamento pode ser operada por um administrador com responsabilidade técnica restrita. Controle de recursos não equivale a poder de contratar.

Uma organização pode delegar a manutenção de ROAs a uma equipe de rede ou prestador sem conceder poderes para assinar contratos. Um sistema que trata essas duas delegações como iguais transforma uma boa evidência técnica em autorização inventada.

A validação precisa continuar explicável

O recebedor primeiro valida o objeto RPKI: invólucro CMS, caminho do certificado, escopo dos recursos e regras próprias da RFC 9323. Em seguida, calcula o hash de cada arquivo escolhido e procura o elemento adequado.

No modo com nome, exige nome e hash exatos. No modo sem nome, o elemento encontrado precisa omitir o nome. É permitido verificar menos arquivos do que a lista contém. Elementos não usados não geram erro fatal, mas a RFC recomenda um alerta para que anexos ausentes ou diferenças de processo sejam investigados.

A RFC 6488 esclarece que verificações genéricas são necessárias, porém insuficientes; cada tipo de objeto necessita de semântica própria. A RFC 6487 descreve os certificados de recursos, e a RFC 9286 atualiza o algoritmo de validação.

Um CMS íntegro não julga o documento externo. Nem um atributo opcional de hora da assinatura serve automaticamente como horário oficial da transação. Se o momento de entrega tiver valor jurídico ou de auditoria, o processo precisa de recibo ou registro preparado para isso.

O melhor resultado é uma coleção de estados: assinatura válida, recursos contidos, bytes correspondentes, identidade confirmada, mandato aprovado, conformidade aceita e operação liberada. É possível que alguns estejam verdes e outros permaneçam pendentes. Essa granularidade preserva o significado da prova.

Fora do repositório global por escolha

A RFC 9323 proíbe distribuir RSCs pelo sistema global de repositórios RPKI. O transporte é externo: HTTPS, email, mídia removível ou outro canal escolhido pelas partes.

O registro RPKI da IANA atribui à Signed Checklist o OID 1.2.840.113549.1.9.16.1.48 e a extensão .sig. Isso coordena implementações, mas não cria uma caixa postal mundial nem obriga qualquer provedor a aceitar o objeto.

Manter a lista fora do repositório protege relações comerciais. Materiais de BYOIP ou interconexão pertencem a participantes específicos. Publicar globalmente a associação entre recursos e pacotes poderia revelar clientes e planos sem melhorar a validação de origem de rotas.

O canal escolhido ainda precisa de autenticação, sigilo, retenção e proteção contra software malicioso. A RSC mostra se os bytes recebidos correspondem aos hashes. Não prova quem controlou a conta de envio e não garante que todos os anexos chegaram.

Cada provedor pode criar seu próprio upload autenticado, limites, formatos e revisão. O padrão oferece uma evidência interoperável sem assumir a gestão da relação com o cliente.

O recebedor conserva o poder de dizer não

Considere uma RSC válida para um prefixo e documentos de BYOIP correspondentes. O provedor recebeu uma prova relevante sobre recursos e integridade. Ainda precisa verificar conta, identidade, delegação, contrato, regras aplicáveis, uso atual do prefixo e segurança do anúncio.

Esses controles não são burocracia residual. Eles respondem a fatos diferentes. Identidade vem do processo do cliente; mandato vem de delegação e documentos jurídicos; finalidade vem do contrato; segurança vem de filtros, testes, monitoramento e plano de reversão.

Uma checklist pode ser criptograficamente válida e a solicitação ser negada de modo correto. Arquivos idênticos podem estar desatualizados. O administrador real do recurso pode não ser a pessoa habilitada para o negócio. O receptor não contradiz a RPKI ao exigir essas provas.

Automação robusta trata como determinísticos sintaxe, certificado, recursos, assinatura, hash e nome. Depois encaminha os resultados a regras explícitas de identidade, negócio e operação. A intervenção humana pode ser reduzida, mas a separação de autoridade não pode desaparecer.

Ao conservar os motivos de falha, a organização também resolve disputas com mais rapidez. Hash divergente aponta para empacotamento ou transporte; recurso fora do escopo aponta para a cadeia; identidade falha no cadastro; risco de rota pertence à operação. Um único selo verde esconderia tudo.

Implementação não se presume

RFC, OID e extensão não provam adoção universal. O plano trimestral de RPKI do RIPE NCC registra suporte de API a RSC como previsto para o terceiro trimestre de 2026, após pedidos da comunidade. Uma interface posterior depende de demanda e capacidade.

O registro mostra interesse e caminho de execução, não disponibilidade ampla. Quem pretende usar RSC deve verificar portais, API, versões de validadores, algoritmos aceitos, mensagens de erro e a política do destinatário.

Os testes devem incluir expiração, revogação, transferência de recursos, arquivos ausentes, renomeação, hashes duplicados, verificação parcial e algoritmo desconhecido. Também precisam reproduzir a hipótese central da RFC 9255: o administrador do RPKI é legítimo, mas não possui mandato comercial.

O perfil do MENOG situa Snijders na comunidade de roteamento e peering. A checklist reflete esse ambiente: partes autônomas compartilham uma prova pequena e verificável, sem entregar a outra parte sua decisão final.

Segurança que sabe parar

Um hash conhece bytes. Um certificado de recursos conhece a relação entre uma chave e números sob determinado modelo de confiança. Juntos, respondem a uma pergunta importante e limitada.

O remetente ganha uma forma portátil de ligar documentos a recursos. O receptor ganha uma verificação reproduzível. Ambos continuam livres para discutir identidade, intenção, atualidade, completude e risco com as evidências adequadas.

Job Snijders e seus coautores não eliminaram a confiança institucional. Eles marcaram o ponto em que a máquina pode concluir sem usurpar autoridade. A RSC assina bytes, não a verdade; é esse limite que a torna segura para automatizar.

Fontes