基于密钥的加密寻址：IP、DNS、DID 与 IPvX

基于密钥的加密寻址是一个方便的说法，但其背后可能隐藏着不同的架构模型：作为主机标识符的公钥、公钥哈希、带有 verification methods 的 DID Document，或数字对象内容的哈希。¹³⁴ 在本文中，我们不会把下列资料中没有的属性强加给 IPvX：下面的资料描述的是 HIP、DID、did:drn 和基于哈希的名称，而不是 IPvX 规范。¹²³⁴ 因此，我们把它们作为精确讨论的词汇表：哪些地方的标识符由密钥持有来证明，哪些地方它是网络定位符，哪些地方它仍然只是指向外部记录的引用。¹³⁴

为什么必须区分身份、定位符和名称

RFC 9063 描述了互联网中两个重要的全局命名空间：IP 地址和 DNS 名称。⁴ 同一份文档明确指出，这些空间在语义上被过度承载，因为它们不得不承担过多功能。⁴ 作为回应，HIP 架构引入了 Host Identity 空间，用以填补 IP 空间与 DNS 空间之间的空白。⁴

在 HIP 中，Host Identity 指计算平台，而 Host Identifier 是这种身份的具体比特表示。⁴ 该文档还强调了 identity 作为抽象实体与 identifier 作为识别时使用的具体比特模式之间的区别。⁴ 对网络工程师来说，这一区分很有用：一个术语回答“谁在参与交互”，另一个回答“用哪种比特材料进行验证”，而在 HIP 架构中，IP 空间仍然是一个独立的命名空间。⁴

因此，当我们讨论 IPvX 时，会尽量以条件方式表述其属性：如果地址是公钥或由公钥派生出的值，这是一种验证模型；如果地址通过文档或目录解析，这是另一种信任模型；如果该值是数据哈希，那已经是 content addressing 模型。¹³⁴

HIP 模型：作为公钥的标识符

从密码学视角看，HIP 的 Host Identifier 是一对非对称密钥中的公钥。⁴ 按 RFC 9063 的术语，私钥被假定只为由相应公钥所标识的一方知晓，并由该方用来向其他方认证自己的身份。⁴ 因此，在这一具体架构中，验证不仅关系到某个字符串或二进制值是否存在，还关系到参与者是否能够用相应私钥完成密码学交换。⁴

HIP 还定义了 Host Identity Tag：这是一个 128 位值，由 Host Identifier 的密码学哈希以及指示所用哈希的比特生成。⁴ 这对基于派生值的寻址很重要：紧凑的标签并不等于公钥本身，但其含义由它按 HIP 规则从 Host Identifier 计算得出这一事实决定。⁴ 文档还指出，在更换密钥时，可能会出现过渡期，即同一个 Host Identity 同时有不止一个标识符处于活动状态。⁴

不能从这一模型自动推导出任何出现“密钥”一词的系统都具备相同属性。⁴ 更准确的表述是：在 HIP 中，Host Identifier 是公钥，而认证依赖相应的公钥和私钥对。⁴

这与 IP 地址有何不同

HIP 将 IP 地址视为互联网中一个独立的全局命名空间，不同于 Host Identity namespace。⁴ HIP 协议层位于 internetworking 层与 transport 层之间，而该架构本身声明支持终端主机移动性、multihoming 和 NAT 穿越。⁴ 在这一架构中，主机身份与当前 IP 信息并不是模型中的同一对象。⁴

对于讨论 IPvX，这提供了一个严谨的框架，但并不能直接得出关于 IPvX 实现的结论。⁴ 如果在某个项目中地址由密钥派生，那么可验证的属性涉及密钥材料以及对私钥的持有，这可类比 HIP 中的密码学 HI。⁴ 但如果该值用于网络投递，就必须单独说明它如何与路由以及当前可达点相关联，因为 RFC 9063 本身将 IP 空间与 Host Identity namespace 区分开来。⁴

这与 DNS 名称有何不同

RFC 9063 将 DNS 名称称为与 IP 地址并列的互联网第二个重要全局命名空间。⁴ 在 HIP 中，Host Identifier 可以发布在 DNS 中，也可以不发布。⁴ 这只意味着，在所描述的架构中，DNS 可以作为 Host Identifier 的发布位置之一，而不意味着 DNS 名称本身变成了 Host Identifier。⁴

2020 年的 DID Core 工作草案将 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 registry 中创建、读取、更新和停用 DID 及相关 DID documents。⁵ 同一草案还警告，不同方法产生的 DID 可能不可互操作，不同 DID methods 也可能使用不同的密码学方案。⁵

对于 IPvX，这意味着只有在说明 DID method 和解析规则的前提下，才能在身份讨论中使用 DID。¹⁵ 如果我们想讨论的属性正是“地址由密钥证明”，那么 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 字符串本身构建最小 DID Document，而不强制访问中心化注册表、分布式日志或网络服务。² 同时，该草案明确指出，默认情况下，did:drn identifier 不声明也不暗示存在控制者。² 在 did:drn 中，verification methods 和 service endpoints 被描述为 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 的基础设施模型。¹⁵ RFC 6920 展示了基于哈希的名称模型，其中资源查找仍然独立于名称本身。³

简短比较

模型	标识符定义的内容	关联在哪里验证
HIP 语境下的 IP	独立的全局 IP 地址空间	HIP 将 IP 空间与 Host Identity namespace 区分开来。4
HIP 语境下的 DNS	独立的全局 DNS 名称空间	Host Identifier 可以发布在 DNS 中，但 HIP 仍然引入了独立的 Host Identity 空间。4
HIP Host Identifier	非对称密钥对中的公钥	私钥由一方用于向其他方认证身份。4
DID	将 subject 与 DID document 关联起来的 URI	DID document 可以包含 verification methods，而具体技术取决于 DID method。15
RFC 6920 / ni	数字对象的哈希，或在特殊情况下为公钥哈希	验证数据与名称是否匹配；资源查找方式必须为执行解引用的一方所知。3
did:drn draft	从 URN 到 DID 兼容形式的确定性映射	基础 did:drn 不暗示存在控制者，verification methods 是可选的。2

结论

严格意义上的基于密钥的加密寻址需要一份规范：其中标识符与公钥或其派生值相关联，并通过持有相应私钥来验证控制权；HIP 描述的 Host Identifier 正是这种模型。⁴ 在 RFC 9063 中，IP 地址和 DNS 名称被视为独立的命名空间，不应自动等同于密码学 Host Identity。⁴ DID 提供了通用 URI 格式以及带有 verification methods 的 DID Document，但并不强制采用统一的密码学或统一的解析基础设施。¹ RFC 6920 下的 content addressing 验证的是名称与数字对象之间的关联，但哈希的含义取决于哈希函数的输入是什么。³

对于 IPvX 来说，这并不是对某个协议具体属性的证明，而是一种描述架构的纪律。¹³⁴ 如果我们说“基于密钥的地址”，就必须分别说明：究竟什么是密钥材料，如何验证私钥持有，如何进行投递，以及有哪些外部记录参与发现。¹³⁴

来源

1. Decentralized Identifiers (DIDs) v1.0, w3.org, 2022年7月19日
2. Decentralized Resource Name (DRN) DID Method, ietf.org, 2026年3月24日
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, 2020年4月3日
6. Decentralized Identifiers (DIDs) v1.0, w3.org, 2021年6月15日
7. Decentralized Identifiers (DIDs) v1.0, w3.org, 2020年4月8日
8. RFC 6920: Naming Things with Hashes, datatracker.ietf.org