Resumo

  • Uma RSC válida mostra que alguém com controle suficiente da CA emissora assinou uma lista que relaciona um subconjunto de ASNs ou endereços IP a hashes exatos. Ela não prova identidade real, propriedade, representação societária ou completude.
  • A organização receptora precisa registrar separadamente a validação do objeto, a correspondência de cada arquivo e a autoridade externa que identifica o ator e seu mandato para a decisão específica.

Considere uma diligência de compra de ativos de rede. É um exercício ilustrativo, não um caso real. O vendedor entrega uma planilha de endereços, um arquivo compactado de equipamentos e um .sig. A ferramenta confirma hashes, certificado, cadeia, CRL e o subconjunto de recursos.

Existe uma terceira entrada na checklist, mas seu arquivo não foi entregue. O RFC 9323 permite verificar os dois objetos apresentados; a implementação deve alertar quando a lista é maior que o conjunto fornecido. Mesmo assim, o comitê registra que o signatário é o proprietário, pode vender e entregou tudo.

A matemática respondeu à pergunta sobre bytes. As três conclusões pertenciam a outras autoridades.

O objeto e seu alcance

A RSC é um objeto assinado RPKI protegido por CMS. O eContentType id-ct-signedChecklist usa o OID 1.2.840.113549.1.9.16.1.48. O registro RPKI da IANA lista Signed Checklist e a extensão .sig; o tipo de mídia é application/rpki-checklist.

O bloco precisa conter ASNs, blocos IP ou ambos. Os recursos declarados devem ser subconjunto das extensões RFC 3779 do certificado EE e não podem usar inherit. Depois vêm o algoritmo de digest e uma ou mais entradas, cada uma com hash obrigatório e nome portátil opcional. Nomes presentes são únicos; hashes de entradas sem nome também.

Essa estrutura delimita recursos e bytes. Não contém identidade empresarial, função do operador, finalidade contratual ou título de propriedade.

Uma sequência de decisões

O RFC 6488 exige CMS SignedData em DER, signedAttrs permitidos, exatamente um certificado EE correspondente, assinatura verificável e caminho válido até uma âncora RPKI. Esses testes são necessários, mas o próprio RFC diz que não bastam sem as regras do tipo de objeto.

O RFC 9323 acrescenta sintaxe RSC, subconjunto de recursos, regras da checklist e ausência de SIA no certificado EE. O certificado precisa estar válido e fora da CRL. Quando expira ou é revogado, um objeto antes válido deixa de ser válido.

Na verificação do arquivo, o digest é calculado sobre os bytes recebidos. No modo filename-aware, deve existir exatamente uma entrada de hash correspondente com o mesmo nome. No filename-unaware, deve existir exatamente uma entrada correspondente sem nome. A escolha do modo integra o registro da prova.

Só então se chega à decisão externa: quem apresentou o objeto, se pode representar a entidade e se o conjunto satisfaz o propósito. Um painel que reduz tudo a verde apaga essa última fronteira.

Hash não lê verdade nem completude

Um documento falso, se não foi alterado, corresponde perfeitamente ao hash. Uma planilha assinada pode descrever propriedade inexistente. A criptografia conserva a declaração; não a investiga.

Também pode ocorrer falha por mudança inofensiva de bytes, como quebra de linha ou codificação. Por isso RFC 9323 recomenda compressão sem perda para texto. Essa proteção evita canonicalização acidental, mas não verifica o significado.

Nem todas as entradas precisam ser usadas numa operação. A flexibilidade serve a destinatários que validam subconjuntos diferentes. Para uma aquisição, porém, completude vem de uma matriz externa: registros, clientes, gravames, litígios, equipamentos, incidentes, acessos e poderes. A RSC prova o que foi listado e entregue; a diligência define o que deveria existir.

O relatório deve separar entradas casadas, arquivos sem casamento, entradas sem arquivo e requisitos ausentes da própria RSC.

Controle da CA não é identidade

RFC 9323 chama os dados de autoafirmados. O relying party não pode presumir mais que controle suficiente da CA emissora para criar o objeto. A CA superior não verificou o conteúdo.

RFC 9255 explica que o I de RPKI significa Infrastructure, não Identity. A RPKI autoriza declarações sobre recursos; não autentica o titular real ou uma transação.

Em RPKI hospedada, o usuário pode pedir a assinatura por credenciais sem possuir a chave. Pode ser proprietário, administrador com função limitada, fornecedor ou invasor. Mesmo o administrador legítimo talvez não possa vender ativos.

Os nomes Subject e Issuer não solucionam isso, pois RFC 6487 não os destina a identidade descritiva. Registro empresarial, resolução do conselho, procuração, contrato ou outra autoridade exógena precisam confirmar ator, entidade, ato, finalidade e vigência.

Fora do repositório e sem relógio confiável

RSCs não são distribuídas pelo repositório público RPKI. Terceiros sem a cópia podem desconhecer sua existência. Lacunas de serial ou uma entrada CRL sem objeto visível não provam que uma RSC existe.

O canal de entrega vira evidência própria. Portal autenticado, e-mail conhecido e link anônimo podem trazer bytes idênticos com contextos distintos. Canal não substitui validação; validação não substitui canal.

Um certificado EE de uso único permite revogar o objeto pela revogação do certificado. Reusar a chave em várias RSCs impede revogação individual. A economia operacional acopla decisões que deveriam ser independentes.

RFC 9589 torna signing-time obrigatório, mas não exige que o valor esteja correto. Ele não é prova confiável da hora da assinatura. Tempo de validação, validade, CRL e cronologia contratual continuam separados.

Registrar a prova negativa

O dossiê final guarda bytes e hash da RSC, canal, OID, certificado, cadeia, CRL, momento, recursos, algoritmo, arquivos, nomes, modo, casamentos, entradas não usadas, alertas, identidade, mandato e decisão. Também declara o que não foi provado: propriedade, verdade, completude, representação, data confiável ou autorização de origem BGP.

Essa limitação é a força da RSC. A prova é precisa porque não tenta governar identidade e comércio. O receptor preserva seu valor quando exige prova separada para toda autoridade que fica de fora.

Fontes