Кратко

  • RFC 6920, опубликованный в апреле 2013 года, определил имена Named Information (ni) на основе алгоритма хеширования и значения хеша. Для сравнения имён важны алгоритм, длина и значение; необязательный адрес сервера в решении не участвует.
  • Имя ni можно перевести в HTTP(S)-адрес с путём /.well-known/ni/ и запросить данные у сервера. Реестр IANA фиксирует названия алгоритмов и длины значений, а не сами файлы и места их хранения.
  • Клиенту нужны достоверно полученное имя, доступная копия и вычисление хеша над правильными данными. Датированная запись этих шагов показала бы работу механизма в конкретной системе.

Адрес указывал место, которое могло измениться

Обычный URL ведёт к хосту и пути на нём. Сервер может заменить содержимое пути, оставив все старые ссылки действительными. Для страницы с новостями это удобно. Для точной версии программы, документа или набора данных возникает другая задача: удостовериться, что полученный сегодня файл совпадает с тем, который имел в виду отправитель ссылки. Успешное соединение с ожидаемым хостом этого не доказывает.

Результаты хеш-функций уже включали в разные идентификаторы, но каждая система выбирала свой формат. RFC 6920 предложил общую грамматику. Имя ni содержит алгоритм, точку с запятой и значение в кодировке base64url без завершающих знаков заполнения. По умолчанию хеш вычисляется по байтам объекта, который должен прийти при получении. Если протокол использует другую последовательность на входе, он должен определить это отдельно.

Так имя стало отвечать на вопрос, отличающийся от вопроса адреса. Адрес сообщает, где спросить. Хеш говорит, какие именно байты следует принять. Одинаковую копию могут хранить две независимые машины, и её имя останется одним. Если сервер меняет файл на старом пути, новый набор байтов получает другое хеш-имя. При работающей проверке хост уже не определяет тождество файла одним только контролем над путём.

Правило сравнения в RFC 6920 специально отстраняет адрес доставки. Для двух имён учитываются алгоритм, длина и значение хеша. Поле authority и параметры запроса игнорируются. Имя с указанным хостом и имя без него могут обозначать один объект. Два разных хоста также могут предоставлять одни и те же байты. Адрес помогает найти экземпляр, но не голосует за его идентичность.

При доставке понадобился прежний интернет

Хеш сам не ищет склад. Поэтому RFC 6920 установил отображение ni в HTTP- или HTTPS-URL с путём /.well-known/ni/. Если в исходном имени есть authority, оно задаёт хост для этого URL. Если нет, приложение может выбрать хост из контекста. Сервер вправе перенаправить запрос. В конце цепочки клиент получает байты-кандидаты и может сравнить вычисленное значение с именем.

Стандарт прямо говорит: получившийся HTTP-адрес не гарантирует наличия объекта. Можно принести правильный отпечаток к пустому шкафу. Отсутствие ответа указывает на проблему доступности. Ответ с другим хешем указывает на несовпадение содержимого или ошибку в правиле вычисления. Сваливать обе ситуации в одну категорию «сломанная ссылка» значит терять подсказку о том, какую часть системы чинить.

Работу делят три участника. Источник имени определяет ожидаемые байты. Распространитель решает, будет ли копия доступна для запроса. Разработчик клиента решает, будет ли программа сравнивать полученное с именем. RFC 6920 допускает обработку ni без обязательной проверки связи имени и данных при каждом применении. Видимый идентификатор в интерфейсе ещё не показывает, что вычисление выполняется.

Документ описал также компактную двоичную форму и более удобный для произнесения вариант nih с шестнадцатеричными символами и контрольной цифрой. Форматы помогают передавать одно и то же имя в разных условиях. Они не создают копий файла и не управляют серверами.

Таблица алгоритмов не является хранилищем

Независимые программы должны одинаково понимать название хеш-функции и длину результата. Реестр Named Information в IANA перечисляет такие названия, длины, документы и параметр ct для типа содержимого. RFC 6920 требует поддержки полного SHA-256 и допускает усечённые результаты с отдельным обозначением длины. Чем короче значение, тем выше вероятность коллизии; короткий вариант нельзя выдавать за полный.

Строка IANA согласует словарь двух реализаций. Она не содержит файл и не указывает сервер, на котором его можно скачать. Такой ограниченный мандат полезен: общая организация обеспечивает совместимость написания имён, не получая управление каждым объектом, которому дали имя. Доставку по-прежнему обеспечивают работающие системы хранения и сети.

Наконец, верный хеш не заменяет доверия к самому ожидаемому имени. Раздел о безопасности RFC 6920 объясняет: проверка байтов сильна лишь настолько, насколько достоверно имя, от которого начал клиент. Злоумышленник может прислать вредоносный файл вместе с точным хешем этого файла. Сравнение пройдёт, хотя источник ожидания был подменён. Опубликованный хеш также не скрывает легко угадываемое содержимое: возможный файл можно вычислить и сравнить.

Официальный текст и реестр подтверждают формат, сравнение и перевод в HTTP. Чтобы показать применение в названном продукте, нужны датированная запись передачи имени, путь получения и результат расчёта клиента. Достижение 2013 года состоит в ясном разделении: файл может сохранить своё тождество при переезде, а его доставку приходится организовывать отдельно.