Cryptographic Addressing by Keys: IP, DNS, DID, and IPvX

Cryptographic addressing by keys is a convenient phrase, but it can hide different architectural models: a public key as a host identifier, a hash of a public key, a DID document with verification methods, or a hash of a digital object’s content.¹³⁴ In this article, we do not ascribe to IPvX properties that are not present in the cited sources: the sources below describe HIP, DID, did:drn, and hash-based names, not an IPvX specification.¹²³⁴ We therefore use them as a vocabulary for precise discussion: where an identifier is proven by possession of a key, where it is a network locator, and where it remains a reference to an external record.¹³⁴

Why it matters to separate identity, locator, and name

RFC 9063 describes two important global Internet namespaces: IP addresses and DNS names.⁴ The same document states explicitly that these spaces have been semantically overloaded because they have had to perform too many functions.⁴ In response, the HIP architecture introduces the Host Identity namespace, intended to fill the gap between the IP and DNS namespaces.⁴

In HIP, Host Identity refers to a computing platform, while a Host Identifier is the specific bit-level representation of that identity.⁴ The document also emphasizes the distinction between identity as an abstract entity and identifier as a concrete bit pattern used in identification.⁴ For network engineers, this is a useful distinction: one term answers the question “who is participating in the interaction,” another answers “what bit material is used for verification,” while the IP space remains a separate namespace in the HIP architecture.⁴

When discussing IPvX, we therefore try to state properties conditionally: if an address is a public key or a value derived from one, that is one verification model; if an address is resolved through a document or directory, that is another trust model; if the value is a hash of data, that is already a content addressing model.¹³⁴

The HIP model: the identifier as a public key

In HIP’s cryptographic focus, a Host Identifier is the public key of an asymmetric key pair.⁴ In the terminology of RFC 9063, the private key is assumed to be known only to the party identified by the corresponding public key and is used by that party to authenticate its identity to other parties.⁴ Therefore, in this specific architecture, verification is not only about the existence of a string or binary value, but also about whether the participant can complete a cryptographic exchange using the corresponding private key.⁴

HIP also defines a Host Identity Tag as a 128-bit value created from a cryptographic hash of the Host Identifier plus bits indicating the hash used.⁴ This matters for addressing by a derived value: a compact tag is not the public key itself, but its meaning is defined by the fact that it is computed from the Host Identifier according to HIP rules.⁴ The document also notes that, when a key is replaced, there may be transition periods during which more than one identifier is active for a single Host Identity.⁴

This model cannot be used to automatically infer the properties of any system in which the word “key” appears.⁴ The precise statement is narrower: in HIP, the Host Identifier is a public key, and authentication relies on the corresponding public/private key pair.⁴

How this differs from IP addresses

HIP treats IP addresses as a separate global Internet namespace, distinct from the Host Identity namespace.⁴ The HIP protocol layer sits between the internetworking and transport layers, and the architecture itself states support for end-host mobility, multihoming, and NAT traversal.⁴ In this architecture, host identity and current IP information are not the same object in the model.⁴

For discussing IPvX, this provides a careful framing, but not a ready-made conclusion about IPvX implementation.⁴ If, in a project, an address is derived from a key, the verifiable property relates to key material and possession of the private key, by analogy with cryptographic HI in HIP.⁴ If the value is used for network delivery, it is necessary to describe separately how it relates to routing and the current point of reachability, because RFC 9063 itself separates the IP space and the Host Identity namespace.⁴

How this differs from DNS names

RFC 9063 names DNS names as the second important global Internet namespace alongside IP addresses.⁴ In HIP, a Host Identifier can be published, for example, in DNS, or it can remain unpublished.⁴ This only means that DNS may appear as a place where a Host Identifier is published in the described architecture, not that the DNS name itself becomes the Host Identifier.⁴

The 2020 DID Core Working Draft cites domain name registries as an example of centralized authorities in traditional identity management systems.⁵ The same draft says that such authorities act as their own roots of trust for the purposes of cryptographic trust verification.⁵ So comparisons with DNS-like names are best phrased carefully: the source discusses domain registries as centralized authorities, not that every DNS string in every protocol has a specific cryptographic semantics.⁵

The practical distinction is this: in HIP, a host’s cryptographic identity is defined by the Host Identifier, while DNS belongs to another namespace.⁴ If, in a specific specification, an IPvX address is derived from a public key, its verification should be described by the rules of that specification, not by an assumption about DNS resolution.⁴

How this differs from DID

DID Core 2022 defines a DID as a URI that associates a DID subject with a DID document.¹ A DID document can express cryptographic material, verification methods, or services that provide mechanisms for proving control over the DID.¹ The specification also says the design allows a DID controller to prove control without permission from any other party, although other parties may help discover information related to the DID.¹

But DID Core does not mandate a single technology or a single cryptographic approach for generating, persisting, resolving, or interpreting DIDs.¹ The specification explicitly allows implementers to create DIDs based on identifiers registered in federated or centralized identity management systems.¹ Therefore, the form did:method:id is not, by itself, enough to conclude that the identifier is equal to a public key.¹

The history of DID Core highlights the method-dependent nature of this model.⁵ The 2020 Working Draft described DID methods as a mechanism for creating, reading, updating, and deactivating DIDs and associated DID documents in a specific DID registry.⁵ The same draft warned that DIDs from different methods may not be interoperable and that different DID methods may use different cryptographic schemes.⁵

For IPvX, this means DID can be used in a discussion of identity only if the DID method and resolution rules are specified.¹⁵ If the property we want to discuss is specifically “the address is proved by a key,” then DID Core alone is insufficient: we need to look at the DID document, verification methods, and the method that defines operations with that DID.¹⁵

Content addressing: a data hash is not the same as a subject’s identity

RFC 6920 defines ways to identify a digital object by the result of a hash function.³ The document introduces Named Information identifiers, including the ni URI, as well as binary and human-speakable forms of such names.³ These formats are intended to support, but not require, a strong binding to the object so that the object can be authenticated to the same degree as the reference to it.³

The key check in this model is name-data integrity: the retrieved representation of the resource is compared with the name under which the resource was requested.³ RFC 6920 also indicates that a Named Identifier names a resource, and that the mechanism for dereferencing and locating the resource must be known to the party dereferencing it.³ This separates a “hash-based name” from a “route to the storage location.”³

RFC 6920 separately considers the case where the input to the hash function is a public key and recommends computing the hash over the public key in the X.509 SubjectPublicKeyInfo structure.³ However, the same document says that, apart from this special case, the input to the hash function is not specified by RFC 6920 and must be defined by other specifications.³ Therefore, a file hash, a message hash, and a public key hash have different meanings, even if technically they are all results of a hash function.³

There is also an important limitation: RFC 6920 permits truncated hashes, but explicitly says that a 32-bit truncated hash is practically useless for security in almost all cases, although it may be useful for naming.³ This is a good example of a negative result for addressing projects: compactness of a name does not automatically provide cryptographic strength.³

did:drn as an example of an external name without an embedded controller

The did:drn draft is useful as a boundary case, but its status must be taken into account: Internet-Drafts are IETF working documents, may be updated, replaced, or obsoleted, and should not be cited other than as work in progress.² In this draft, did:drn defines a deterministic mapping of a URN into a DID-compatible Decentralized Resource Name format.²

Baseline did:drn resolution must be able to construct a minimal DID Document from the DID string itself without a mandatory call to a centralized registry, distributed ledger, or network service.² At the same time, the draft explicitly says that a did:drn identifier does not assert or imply a controller by default.² Verification methods and service endpoints in did:drn are described as optional properties of a DID Document.²

This example shows an important boundary: a deterministic name and the absence of a mandatory network dependency in baseline resolution are not the same as proof of possession of a private key.² Proving control requires rules and verification methods, not just a reversible transformation of a URN into a DID string.²

How to talk precisely about an IPvX address

In IPvX materials, we suggest explicitly separating three questions, without presenting this as an already proven property of a global implementation: what material serves as the identifier, how control over it is verified, and what mechanism is used to find the delivery path.¹³⁴ If the identifier is a public key or a value derived from one, the closest model among the cited sources is HIP, where the Host Identifier is a public key and the private key is used to authenticate the corresponding identity.⁴ If the identifier is a DID, the DID method must be specified, because DID Core does not fix a single technology or cryptographic scheme for all DIDs.¹ If the value is a hash of a digital object, it is more accurate to talk about verifying the binding between name and data under the RFC 6920 model.³

This language helps avoid conflating routing, identity, and discovery.¹³⁴ HIP shows the separation of the Host Identity namespace from the IP/DNS namespaces.⁴ DID Core shows a model of URI, DID document, verification methods, and method-dependent infrastructure.¹⁵ RFC 6920 shows a hash-based naming model in which locating the resource remains separate from the name itself.³

Short comparison

Model	What the identifier defines	Where the binding is verified
IP in the HIP context	A separate global IP address space	HIP separates the IP space from the Host Identity namespace.4
DNS in the HIP context	A separate global DNS name space	A Host Identifier may be published in DNS, but HIP still introduces a separate Host Identity space.4
HIP Host Identifier	The public key of an asymmetric key pair	The private key is used by the party to authenticate its identity to other parties.4
DID	A URI linking a subject to a DID document	A DID document can contain verification methods, and the specific technology depends on the DID method.15
RFC 6920 / ni	A hash of a digital object or, in a special case, a hash of a public key	The data’s correspondence to the name is verified; the method for locating the resource must be known to the dereferencing party.3
did:drn draft	A deterministic mapping of a URN into a DID-compatible form	Baseline did:drn does not imply a controller, and verification methods are optional.2

Conclusion

Cryptographic addressing by keys in the strict sense requires a specification in which the identifier is tied to a public key or a value derived from it, and control is verified by possession of the corresponding private key; this is exactly the model HIP describes for a Host Identifier.⁴ IP addresses and DNS names in RFC 9063 are treated as separate namespaces that should not be automatically equated with a cryptographic Host Identity.⁴ DID provides a general URI format and DID Document with verification methods, but does not impose a single cryptographic scheme or a single resolution infrastructure.¹ Content addressing under RFC 6920 verifies the binding between a name and a digital object, but the meaning of the hash depends on what was provided as input to the hash function.³

For IPvX, this is not proof of a specific protocol property, but a discipline for describing the architecture.¹³⁴ If we say “key-based address,” we need to specify separately exactly what the key material is, how possession of the private key is verified, how delivery works, and what external records are involved in discovery.¹³⁴

Sources

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