Криптографическая адресация по ключам: IP, DNS, DID и IPvX

Криптографическая адресация по ключам — удобная фраза, но за ней могут скрываться разные архитектурные модели: открытый ключ как идентификатор хоста, хеш открытого ключа, DID-документ с verification methods или хеш содержимого цифрового объекта.¹³⁴ В этой статье мы не приписываем IPvX свойств, которых нет в приведённых источниках: источники ниже описывают HIP, DID, did:drn и имена на основе хешей, а не спецификацию IPvX.¹²³⁴ Поэтому мы используем их как словарь для точного обсуждения: где идентификатор доказывается владением ключом, где он является сетевым локатором, а где остаётся ссылкой на внешнюю запись.¹³⁴

Почему важно разделять идентичность, локатор и имя

RFC 9063 описывает две важные глобальные области имён Интернета: IP-адреса и DNS-имена.⁴ Тот же документ прямо говорит, что эти пространства были семантически перегружены, потому что им пришлось выполнять слишком много функций.⁴ В ответ архитектура HIP вводит пространство Host Identity, которое должно заполнить промежуток между IP- и DNS-пространствами.⁴

В HIP Host Identity относится к вычислительной платформе, а Host Identifier является конкретным битовым представлением этой идентичности.⁴ Документ также подчёркивает различие между identity как абстрактной сущностью и identifier как конкретным битовым шаблоном, используемым при идентификации.⁴ Для сетевых инженеров это полезное различие: один термин отвечает на вопрос «кто участвует во взаимодействии», другой — «какой битовый материал используется для проверки», а IP-пространство остаётся отдельным пространством имён в архитектуре HIP.⁴

Когда мы обсуждаем IPvX, мы поэтому стараемся формулировать свойства условно: если адрес является открытым ключом или производным от него значением, это одна модель проверки; если адрес разрешается через документ или каталог, это другая модель доверия; если значение является хешем данных, это уже модель content addressing.¹³⁴

Модель HIP: идентификатор как открытый ключ

В криптографическом фокусе HIP Host Identifier является открытым ключом асимметричной пары ключей.⁴ В терминологии RFC 9063 закрытый ключ предполагается известным только стороне, идентифицируемой соответствующим открытым ключом, и используется этой стороной для аутентификации своей идентичности перед другими сторонами.⁴ Поэтому в этой конкретной архитектуре проверка связана не только с тем, что строка или бинарное значение существует, но и с тем, что участник способен пройти криптографический обмен с соответствующим закрытым ключом.⁴

HIP также определяет Host Identity Tag как 128-битное значение, создаваемое криптографическим хешем Host Identifier и битами, указывающими использованный хеш.⁴ Это важно для адресации по производному значению: компактный тег не равен самому открытому ключу, но его смысл определяется тем, что он вычислен из Host Identifier по правилам HIP.⁴ В документе также отмечено, что при замене ключа могут быть переходные периоды, когда более одного идентификатора активно для одной Host Identity.⁴

Из этой модели нельзя автоматически выводить свойства любой системы, где встречается слово «ключ».⁴ Корректное утверждение уже: в HIP Host Identifier — это открытый ключ, а аутентификация опирается на соответствующую пару открытого и закрытого ключей.⁴

Чем это отличается от IP-адресов

HIP рассматривает IP-адреса как отдельное глобальное пространство имён Интернета, отличное от Host Identity namespace.⁴ Протокольный слой HIP расположен между internetworking- и transport-уровнями, а сама архитектура заявляет поддержку мобильности конечных хостов, multihoming и прохождения NAT.⁴ В этой архитектуре идентичность хоста и текущие IP-сведения не являются одним и тем же объектом модели.⁴

Для обсуждения IPvX это даёт аккуратную рамку, но не готовый вывод о реализации IPvX.⁴ Если в проекте адрес выводится из ключа, проверяемое свойство относится к ключевому материалу и владению закрытым ключом по аналогии с криптографическим HI в HIP.⁴ Если же значение используется для доставки по сети, нужно отдельно описывать, как оно соотносится с маршрутизацией и текущей точкой достижимости, потому что RFC 9063 сам разделяет IP-пространство и Host Identity namespace.⁴

Чем это отличается от DNS-имён

RFC 9063 называет DNS-имена вторым важным глобальным пространством имён Интернета наряду с IP-адресами.⁴ В HIP Host Identifier может быть опубликован, например, в DNS, или может оставаться неопубликованным.⁴ Это означает только то, что DNS может фигурировать как место публикации Host Identifier в описанной архитектуре, а не то, что DNS-имя само становится Host Identifier.⁴

Рабочий черновик DID Core 2020 года приводит domain name registries как пример централизованных авторитетов в традиционных системах управления идентичностью.⁵ Тот же черновик говорит, что такие авторитеты выступают собственными корнями доверия с точки зрения криптографической проверки доверия.⁵ Поэтому сравнение с DNS-подобными именами лучше формулировать осторожно: источник говорит о доменных регистраторах как о централизованных авторитетах, а не о том, что всякая DNS-строка в любом протоколе имеет конкретную криптографическую семантику.⁵

Практическое различие такое: в HIP криптографическая идентичность хоста задаётся Host Identifier, а DNS относится к другому пространству имён.⁴ Если IPvX-адрес в конкретной спецификации будет производным от открытого ключа, его проверка должна описываться правилами этой спецификации, а не предположением о DNS-разрешении.⁴

Чем это отличается от DID

DID Core 2022 определяет DID как URI, который связывает DID subject с DID document.¹ DID document может выражать криптографический материал, verification methods или сервисы, которые дают механизмы для доказательства контроля над DID.¹ Спецификация также говорит, что дизайн позволяет контроллеру DID доказывать контроль без разрешения другой стороны, хотя другие стороны могут помогать в обнаружении информации, связанной с DID.¹

Но DID Core не предписывает одну технологию или одну криптографию для генерации, устойчивости, разрешения или интерпретации DID.¹ Спецификация прямо допускает, что implementers могут создавать DIDs на основе идентификаторов, зарегистрированных в федеративных или централизованных системах управления идентичностью.¹ Поэтому из формы did:method:id нельзя само по себе заключить, что идентификатор равен открытому ключу.¹

История DID Core подчёркивает методно-зависимый характер этой модели.⁵ Рабочий черновик 2020 года описывал DID methods как механизм создания, чтения, обновления и деактивации DID и связанных DID documents в конкретном DID registry.⁵ Тот же черновик предупреждал, что DID из разных методов могут быть неинтероперабельны и что разные DID methods могут использовать разные криптографические схемы.⁵

Для IPvX это означает, что DID можно использовать в обсуждении идентичности только с указанием DID method и правил разрешения.¹⁵ Если свойство, которое мы хотим обсудить, — именно «адрес доказывается ключом», то DID Core сам по себе недостаточен: нужно смотреть на DID document, verification methods и метод, который определяет операции с этим DID.¹⁵

Content addressing: хеш данных не равен идентичности субъекта

RFC 6920 определяет способы идентифицировать цифровой объект через результат хеш-функции.³ Документ вводит Named Information identifiers, включая ni URI, а также бинарные и человекопроизносимые формы таких имён.³ Эти форматы предназначены поддерживать, но не требовать, сильную связь с объектом, чтобы объект можно было аутентифицировать до той же степени, что и ссылку на него.³

Ключевая проверка в этой модели — name-data integrity: полученное представление ресурса сравнивается с именем, по которому ресурс запрашивали.³ RFC 6920 также указывает, что Named Identifier называет ресурс, а механизм разыменования и нахождения ресурса должен быть известен стороне, которая его разыменовывает.³ Это отделяет «имя по хешу» от «маршрута до места хранения».³

RFC 6920 отдельно рассматривает случай, когда входом хеш-функции является открытый ключ, и рекомендует вычислять хеш по открытому ключу в структуре X.509 SubjectPublicKeyInfo.³ Однако тот же документ говорит, что кроме такого специального случая вход хеш-функции не задаётся RFC 6920 и должен определяться другими спецификациями.³ Поэтому хеш файла, хеш сообщения и хеш публичного ключа имеют разные смыслы, даже если технически все они являются результатами хеш-функции.³

Есть и важное ограничение: RFC 6920 допускает усечённые хеши, но прямо говорит, что 32-битный усечённый хеш практически бесполезен для безопасности почти во всех случаях, хотя может быть полезен для именования.³ Это хороший пример отрицательного результата для проектов адресации: компактность имени не автоматически даёт криптографическую стойкость.³

did:drn как пример внешнего имени без встроенного контроллера

Проект did:drn полезен как пограничный пример, но его статус нужно учитывать: Internet-Drafts являются рабочими документами IETF, могут обновляться, заменяться или устаревать, и не должны цитироваться иначе как work in progress.² В этом проекте did:drn задаёт детерминированное отображение URN в DID-совместимый формат Decentralized Resource Name.²

Базовое разрешение did:drn должно уметь строить минимальный DID Document из самой DID-строки без обязательного обращения к централизованному реестру, распределённому журналу или сетевому сервису.² При этом проект прямо говорит, что did:drn identifier по умолчанию не утверждает и не подразумевает контроллера.² Verification methods и service endpoints в did:drn описаны как опциональные свойства DID Document.²

Этот пример показывает важную грань: детерминированное имя и отсутствие обязательной сетевой зависимости в baseline resolution не равны доказательству владения закрытым ключом.² Для доказательства контроля нужны правила и verification methods, а не только обратимое преобразование URN в DID-строку.²

Как аккуратно говорить об адресе IPvX

Мы предлагаем в текстах IPvX явно разделять три вопроса, не выдавая это за уже доказанное свойство глобальной реализации: какой материал является идентификатором, как проверяется контроль над ним и каким механизмом находится путь доставки.¹³⁴ Если идентификатор является открытым ключом или производным от него значением, ближайшая модель из приведённых источников — HIP, где Host Identifier является открытым ключом, а закрытый ключ используется для аутентификации соответствующей идентичности.⁴ Если идентификатор является DID, нужно указывать DID method, потому что DID Core не фиксирует единую технологию или криптографию для всех DIDs.¹ Если значение является хешем цифрового объекта, корректнее говорить о проверке связи имени и данных по модели RFC 6920.³

Такой язык помогает не смешивать маршрутизацию, идентичность и обнаружение.¹³⁴ HIP показывает разделение Host Identity namespace и IP/DNS namespaces.⁴ DID Core показывает модель URI, DID document, verification methods и method-dependent инфраструктуры.¹⁵ RFC 6920 показывает модель имени по хешу, где нахождение ресурса остаётся отдельным от самого имени.³

Короткое сравнение

Модель	Что задаёт идентификатор	Где проверяется связь
IP в контексте HIP	Отдельное глобальное пространство IP-адресов	HIP отделяет IP-пространство от Host Identity namespace.4
DNS в контексте HIP	Отдельное глобальное пространство DNS-имён	Host Identifier может быть опубликован в DNS, но HIP всё равно вводит отдельное пространство Host Identity.4
HIP Host Identifier	Открытый ключ асимметричной пары	Закрытый ключ используется стороной для аутентификации идентичности перед другими сторонами.4
DID	URI, связывающий subject с DID document	DID document может содержать verification methods, а конкретная технология зависит от DID method.15
RFC 6920 / ni	Хеш цифрового объекта или, в специальном случае, хеш публичного ключа	Проверяется соответствие данных имени; способ нахождения ресурса должен быть известен разыменовывающей стороне.3
did:drn draft	Детерминированное отображение URN в DID-совместимую форму	Базовый did:drn не подразумевает контроллера, а verification methods являются опциональными.2

Вывод

Криптографическая адресация по ключам в строгом смысле требует спецификации, где идентификатор связан с открытым ключом или его производным значением, а контроль проверяется владением соответствующим закрытым ключом; именно такую модель для Host Identifier описывает HIP.⁴ IP-адреса и DNS-имена в RFC 9063 рассматриваются как отдельные пространства имён, которые не следует автоматически отождествлять с криптографической Host Identity.⁴ DID даёт общий формат URI и DID Document с verification methods, но не навязывает единую криптографию или единую инфраструктуру разрешения.¹ Content addressing по RFC 6920 проверяет связь имени с цифровым объектом, но смысл хеша зависит от того, что было подано на вход хеш-функции.³

Для IPvX это не доказательство конкретного свойства протокола, а дисциплина описания архитектуры.¹³⁴ Если мы говорим «адрес по ключу», нужно отдельно указать, что именно является ключевым материалом, как проверяется владение закрытым ключом, как происходит доставка и какие внешние записи участвуют в обнаружении.¹³⁴

Источники

1. Decentralized Identifiers (DIDs) v1.0, w3.org, 19 июл. 2022 г.
2. Decentralized Resource Name (DRN) DID Method, ietf.org, 24 мар. 2026 г.
3. RFC 6920: Naming Things with Hashes, datatracker.ietf.org
4. RFC 9063: Host Identity Protocol Architecture, datatracker.ietf.org
5. Decentralized Identifiers (DIDs) v1.0, w3.org, 3 апр. 2020 г.
6. Decentralized Identifiers (DIDs) v1.0, w3.org, 15 июн. 2021 г.
7. Decentralized Identifiers (DIDs) v1.0, w3.org, 8 апр. 2020 г.
8. RFC 6920: Naming Things with Hashes, datatracker.ietf.org