Resumo

  • A RFC 6493 permite localizar, em um objeto assinado, dados mínimos de contato de quem mantém uma CA RPKI, mas afirma que o registro não é certificado de identidade nem substituto do WHOIS.
  • Um objeto completamente validado demonstra que foram aprovadas a assinatura, as verificações de objeto da RFC 6488 e as verificações de versão e perfil da RFC 6493; não demonstra que o canal é acompanhado, que alguém confirmou o problema ou que o contato pode autorizar uma correção.
  • Um registro operacional útil separa validade do objeto, escopo do contato, disponibilidade do canal, confirmação humana, autoridade para agir e conclusão do escalonamento ou do repasse.

O problema prático do Ghostbusters Record é estreito e importante. Um operador pode descobrir que um certificado no caminho entre uma Route Origin Authorization e a âncora de confiança expirou, está perto de expirar ou depende de uma lista de revogação desatualizada. Como nomes de certificados RPKI não servem para localizar pessoas, a RFC 6493 responde a uma pergunta simples: quem deve ser contatado sobre a CA que requer atenção?

A resposta é um objeto assinado cujo conteúdo é um vCard fortemente limitado. Ele pode indicar uma pessoa ou função responsável pelo certificado e conter endereço postal, telefone ou e-mail. O perfil exige o invólucro do vCard, versão e nome formatado, além de pelo menos um canal. O objetivo é dado mínimo, não uma lista completa de pessoal.

Essa economia também estabelece um limite. A RFC 6493 diz que o registro não é certificado de identidade. Trata-se de uma declaração de contato feita pelo responsável pela CA e não de dados WHOIS de um registro de recursos. O registro descreve quem mantém o certificado, não necessariamente quem detém os recursos numéricos.

A validação responde a outra pergunta delimitada. O registro usa o modelo de objeto assinado da RFC 6488 e um certificado EE. O validador confere o objeto e a versão, extrai o vCard e verifica sua conformidade com o perfil. Só então o conteúdo fica disponível ao aplicativo. Isso prova que uma carga assinada passou pelos controles criptográficos e sintáticos previstos.

Não prova que a caixa postal seja lida hoje. A especificação alerta que os dados são autodeclarados e não foram verificados pela CA que emitiu o certificado superior. O registro é opcional, e uma CA pode publicar zero ou vários. Um objeto válido pode apontar para pessoa, função administrativa ou NOC, sem revelar plantão, prazo de confirmação, autoridade delegada, substituto ou rota de escalonamento.

Em um problema urgente de certificado ou CRL, essa distinção importa. Enviar uma mensagem não é alcançar um responsável; alcançá-lo não significa obter autorização para alterar um certificado, publicar um objeto corrigido ou acionar continuidade. Um único contato assinado não pode ser tratado como prova de todo um sistema de comando de incidentes.

Um registro de resposta preservaria as diferenças sem mudar o protocolo. Primeiro, guardaria o hash do objeto, o horário, a cadeia e o resultado da validação. Depois, o escopo declarado e os tipos de canal. Em seguida, um teste controlado de disponibilidade, a confirmação do problema, a autoridade para agir ou escalar e, por fim, o repasse, a ação ou a falha explícita em chegar a alguém autorizado.

Essa é uma proposta editorial de governança, não uma exigência das RFCs. Ela não deve expor escalas privadas, formar arquivo de vigilância nem transformar contato em identidade. Apenas impede que seis alegações distintas sejam reduzidas a “contatado”. Um teste isolado tampouco prova adoção universal ou prontidão de outra CA.

Contato público tem custo. A RFC 6493 menciona chamadas abusivas e spam. Os testes precisam de limites previsíveis, divulgação controlada, proteção contra assédio e rotação de canais que preserve a prova histórica de que o registro anterior existiu.

Para a Number Resource Society, a posição defensável é modesta: pedir evidências delimitadas de que caminhos assinados de contato continuam utilizáveis e de que a responsabilidade de escalonamento está clara. Ela não pode certificar CAs, verificar identidades, operar o repositório nem encerrar incidentes. A autoridade permanece com quem controla o certificado e sua publicação.

Fontes