Resumo

  • A assinatura PKCS#10 prova a posse da chave solicitante; o BPKI autentica o representante e liga o pedido ao cadastro do membro na AFRINIC.
  • A AFRINIC só emite o certificado quando os recursos solicitados são um subconjunto dos registrados, mas o objeto público não atesta a identidade da organização nem da pessoa.
  • Uma ROA válida autoriza um ASN a originar prefixos; ela não prova anúncio atual, alcançabilidade, segurança do caminho ou aceitação por uma rede.
  • Um recibo de proveniência pode guardar versões, hashes, decisões e horários sem divulgar documentos pessoais, contatos privados ou credenciais.

O nome opaco é um limite deliberado

O Certification Practice Statement da AFRINIC diz que o nome do sujeito pode ser gerado pelo emissor e não precisa ser legível. O certificado serve à autorização para segurança de roteamento, não à identificação. Com exceção dos registros, ele não atesta a identidade organizacional do detentor; tampouco atesta identidade individual.

A página de Resource Certification repete que certificados de recursos não são certificados de identidade. Eles permitem a aplicações especializadas verificar o direito de uso de endereços IP e números AS. O validador precisa do vínculo entre chave e recursos, não dos documentos usados no atendimento ao membro.

Sete decisões escondidas numa palavra

Primeiro, a solicitação PKCS#10 é assinada pela chave privada correspondente à chave pública. Isso prova posse, não mandato ou recursos.

Segundo, somente uma pessoa com certificado BPKI da AFRINIC pode pedir o certificado RPKI. Terceiro, o BPKI liga o pedido ao banco de membros que contém registros de alocação.

Quarto, a AFRINIC compara conjuntos e só emite se o pedido estiver contido no conjunto registrado. Quinto, RFC 6487 exige extensões de recursos IP ou AS e uma cadeia em que os recursos do emissor englobem os do filho.

Sexto, a ROA é outro objeto. RFC 9582 a define como autorização para um ASN originar rotas para prefixos e comprimentos máximos determinados. Sétimo, RFC 6811 deriva a origem de uma rota BGP recebida e a compara com dados ROA validados.

Uma etapa válida não substitui a próxima. A chave não nomeia o representante; o BPKI não amplia recursos; o certificado não escolhe um ASN; a ROA não anuncia uma rota; o estado Valid não autentica o AS_PATH completo nem ordena que um operador aceite a rota.

BPKI é a junção privada do objeto público

Não ver o nome da empresa não significa ausência de controles. O CPS coloca identificação do representante e autenticação de pedidos no BPKI, recursos no cadastro do membro e alcance na verificação de subconjunto. O certificado RPKI publica somente o resultado necessário ao terceiro confiável.

RFC 6480 segue a mesma lógica: a RPKI oferece autorização, não autenticação, e o DN não deve alegar uma identidade descritiva. O emissor pode usá-lo como referência a registros existentes.

O cadastro, porém, continua sendo um registro operacional da AFRINIC. Ele sustenta uma decisão de emissão, não se transforma em sentença, procuração societária ou título jurídico de propriedade.

A ROA dá permissão; o BGP registra um evento

RFC 9582 esclarece que a PKI da ROA fornece autorização, não autenticação nem não repúdio. Uma ROA válida permite a relação ASN-prefixo. Saber se o anúncio ocorre exige uma observação BGP com fonte, horário e ponto de vista.

Valid, Invalid e NotFound resultam da comparação com VRPs e alimentam política local. Não validam o caminho inteiro. O TAL da AFRINIC aponta para a âncora de confiança, mas a reprodução também depende do repositório, manifesto, CRL, ROA e amostra BGP utilizados naquele momento.

Um recibo de autorização que preserve privacidade

A proposta editorial é um recibo tipado. No lado do registro: horário e impressão digital da chave, referência BPKI ou função não secreta, resultado da autenticação, versão ou hash do cadastro, instantâneo dos recursos, pedido, resultado do subconjunto, serial, SKI, extensões e validade do certificado.

No lado da validação: ponto de publicação, manifesto, CRL, TAL e horário. Para a ROA: certificado EE, ASN, prefixos, maxLength, hash e resultado. Para a origem: fonte BGP, horário, ponto de observação, prefixo, origem vista e comparação.

O membro guardaria a versão completa; o público poderia receber só referências e hashes. O auditor não precisaria de documento de identidade, contato privado ou segredo. Correção e revogação apontariam para a versão substituída. Cada bloco declararia seu limite: não é propriedade legal, anúncio atual, segurança de caminho ou visibilidade global.

Fontes