Resumo

  • A RFC 6920, publicada em abril de 2013, definiu os identificadores Named Information (ni) para objetos digitais. O algoritmo, o comprimento e o valor do resumo determinam a identidade; a autoridade opcional do URI pode orientar a busca, mas não decide se dois nomes designam o mesmo objeto.
  • Um nome ni pode virar uma URL HTTP(S) em /.well-known/ni/ para solicitar os bytes a um servidor. O registro da IANA coordena nomes e comprimentos de algoritmos. Ele não conserva os arquivos nem informa qual servidor possui cada cópia.
  • A aplicação precisa receber um nome confiável, localizar uma cópia e calcular o resumo sobre a entrada correta para estabelecer a correspondência. Um registro datado dessas etapas provaria o uso em uma implantação específica.

O endereço servia, até o conteúdo mudar

O servidor no endereço de uma página pode substituir o arquivo a qualquer momento. Essa liberdade faz a web funcionar para conteúdo atualizado. Uma notícia pode ser corrigida, um manual pode ganhar versão nova, e os links antigos continuam chegando. O mesmo comportamento atrapalha quem quer uma versão exata de um programa ou documento. Receber uma resposta do endereço esperado não responde se os bytes ainda são aqueles que o remetente pretendia entregar.

Diversos sistemas já colocavam resultados de funções hash em identificadores, com sintaxes incompatíveis. A RFC 6920 estabeleceu uma forma comum: o esquema ni, o nome do algoritmo, um ponto e vírgula e o resumo em base64url sem preenchimento. Por padrão, o cálculo recai sobre os bytes do objeto a recuperar. Um protocolo pode definir outra entrada, mas precisa dizer qual é.

Isso muda a função do nome. Um endereço comum responde onde perguntar. O nome derivado do conteúdo responde que conjunto de bytes aceitar. Se uma cópia fiel sair de um servidor e passar para outro, o nome permanece. Se o arquivo for modificado na mesma rota, seu resumo muda. O operador do servidor ainda controla o caminho; a identidade verificável passa a seguir o objeto.

A regra de comparação da RFC 6920 evita que uma autoridade de rede recupere poder por outro campo. Ao comparar dois nomes, a implementação deve considerar o algoritmo e o valor do resumo com seu comprimento. Deve ignorar a autoridade opcional e os parâmetros de consulta. Assim, nomes com hosts diferentes podem designar os mesmos bytes. O host ajuda a procurar, não ganha um voto sobre a definição do objeto.

A entrega devolveu trabalho ao host

Uma impressão digital não informa em qual máquina o arquivo está. A RFC 6920 definiu, por isso, o mapeamento de ni para uma URL HTTP ou HTTPS sob /.well-known/ni/. Quando há uma autoridade no nome, ela fornece o host. Sem autoridade, a aplicação pode escolhê-lo conforme o contexto. O servidor pode responder com redirecionamento. Depois da entrega, o cliente pode calcular o resumo dos bytes recebidos e compará-lo ao nome.

O mapeamento não garante a presença do objeto no endereço escolhido. Um depósito vazio pode ter a placa correta na porta. Falta de resposta é falha de disponibilidade. Uma resposta com resumo diferente é falha de identidade. A distinção importa para o operador: adicionar uma cópia resolve a primeira; a segunda exige descobrir se houve troca de dados ou erro na regra de cálculo.

Há três decisões separadas. Quem entrega o nome escolhe o objeto esperado. Quem distribui os dados decide se haverá bytes para buscar. Quem desenvolve o cliente decide se a verificação ocorrerá. A RFC 6920 permite que aplicações processem nomes ni sem verificar sempre o vínculo entre nome e dados. Um identificador bem formado só se torna um controle quando o programa faz a conta.

O documento incluiu ainda uma forma binária para protocolos que precisam economizar espaço e uma forma nih pensada para leitura em voz alta, com caracteres hexadecimais e dígito de controle. São maneiras de transportar o nome. Nenhuma cria por si mesma um serviço de armazenamento.

O cartório de algoritmos não guarda os arquivos

Programas independentes precisam concordar sobre a escrita do algoritmo e o comprimento do resultado. O registro Named Information da IANA publica esses nomes, comprimentos e referências, além do parâmetro ct para tipo de conteúdo. A RFC 6920 exige suporte ao SHA-256 completo e permite resumos truncados com nomes próprios. Um valor mais curto aumenta a possibilidade de colisão; seu comprimento precisa acompanhar a identidade.

A IANA mantém um vocabulário interoperável. Não mantém uma coleção dos objetos nomeados, nem uma agenda dos servidores que os fornecem. Essa tarefa estreita é importante justamente por ser estreita. Ela permite que implementações compartilhem a mesma sintaxe sem entregar a uma tabela central a administração de cada arquivo.

O resumo também não autentica sozinho quem escolheu o nome. A seção de segurança da RFC 6920 observa que a força do vínculo depende da confiança na origem do identificador. Um atacante pode oferecer um arquivo nocivo junto com o hash correto desse mesmo arquivo: a comparação passa. O cálculo prova correspondência, e a procedência do valor esperado precisa ser estabelecida por outro meio. Um resumo divulgado tampouco esconde um objeto previsível; quem adivinha os bytes pode calcular candidatos.

Os documentos oficiais estabelecem formato, comparação, registro e conversão para HTTP. Para afirmar que uma aplicação específica os usou, faltam uma captura datada da entrega do nome, da recuperação e da comparação feita pelo cliente. A proposta histórica foi dar a uma cópia exata um nome capaz de sobreviver à mudança do servidor.