Direccionamiento criptográfico basado en claves: IP, DNS, DID e IPvX

El direccionamiento criptográfico basado en claves es una expresión cómoda, pero detrás de ella pueden esconderse distintos modelos arquitectónicos: una clave pública como identificador de host, un hash de la clave pública, un documento DID con verification methods o el hash del contenido de un objeto digital.¹³⁴ En este artículo no atribuimos a IPvX propiedades que no estén en las fuentes citadas: las fuentes siguientes describen HIP, DID, did:drn y nombres basados en hashes, no una especificación de IPvX.¹²³⁴ Por eso las usamos como vocabulario para una discusión precisa: dónde el identificador se demuestra mediante la posesión de una clave, dónde es un localizador de red y dónde sigue siendo una referencia a un registro externo.¹³⁴

Por qué es importante separar identidad, localizador y nombre

RFC 9063 describe dos espacios de nombres globales importantes de Internet: las direcciones IP y los nombres DNS.⁴ El mismo documento afirma explícitamente que estos espacios se han sobrecargado semánticamente porque han tenido que cumplir demasiadas funciones.⁴ Como respuesta, la arquitectura HIP introduce el espacio Host Identity, que debe cubrir el hueco entre los espacios IP y DNS.⁴

En HIP, Host Identity se refiere a una plataforma de computación, mientras que Host Identifier es la representación concreta en bits de esa identidad.⁴ El documento también subraya la diferencia entre identity como entidad abstracta e identifier como patrón concreto de bits usado en la identificación.⁴ Para los ingenieros de redes, esta distinción es útil: un término responde a la pregunta «quién participa en la interacción», otro a «qué material en bits se usa para la verificación», y el espacio IP sigue siendo un espacio de nombres separado dentro de la arquitectura HIP.⁴

Por eso, cuando hablamos de IPvX, intentamos formular sus propiedades de forma condicional: si la dirección es una clave pública o un valor derivado de ella, se trata de un modelo de verificación; si la dirección se resuelve mediante un documento o un catálogo, se trata de otro modelo de confianza; si el valor es un hash de datos, estamos ya ante un modelo de content addressing.¹³⁴

El modelo HIP: el identificador como clave pública

En el foco criptográfico de HIP, Host Identifier es una clave pública de un par de claves asimétricas.⁴ En la terminología de RFC 9063, se presupone que la clave privada solo la conoce la parte identificada por la clave pública correspondiente, y esa parte la usa para autenticar su identidad ante otras partes.⁴ Por tanto, en esta arquitectura concreta, la verificación no está vinculada solo a que exista una cadena o un valor binario, sino a que el participante sea capaz de completar un intercambio criptográfico con la clave privada correspondiente.⁴

HIP también define Host Identity Tag como un valor de 128 bits creado mediante un hash criptográfico del Host Identifier y bits que indican el hash utilizado.⁴ Esto es importante para el direccionamiento mediante un valor derivado: un tag compacto no equivale a la propia clave pública, pero su significado viene determinado por el hecho de que se calcula a partir del Host Identifier según las reglas de HIP.⁴ El documento también señala que, al sustituir una clave, puede haber periodos de transición en los que más de un identificador esté activo para una misma Host Identity.⁴

De este modelo no se pueden inferir automáticamente las propiedades de cualquier sistema en el que aparezca la palabra «clave».⁴ La afirmación correcta es más limitada: en HIP, Host Identifier es una clave pública, y la autenticación se apoya en el par correspondiente de clave pública y clave privada.⁴

En qué se diferencia de las direcciones IP

HIP considera las direcciones IP como un espacio de nombres global de Internet separado, distinto del Host Identity namespace.⁴ La capa de protocolo HIP se sitúa entre las capas de internetworking y transporte, y la propia arquitectura declara soporte para la movilidad de hosts finales, multihoming y travesía de NAT.⁴ En esta arquitectura, la identidad del host y la información IP actual no son el mismo objeto del modelo.⁴

Para hablar de IPvX, esto proporciona un marco cuidadoso, pero no una conclusión ya hecha sobre la implementación de IPvX.⁴ Si en un proyecto la dirección se deriva de una clave, la propiedad verificable se refiere al material de clave y a la posesión de la clave privada, por analogía con la HI criptográfica en HIP.⁴ En cambio, si el valor se usa para la entrega por la red, hay que describir por separado cómo se relaciona con el enrutamiento y con el punto actual de alcanzabilidad, porque RFC 9063 separa el espacio IP y el Host Identity namespace.⁴

En qué se diferencia de los nombres DNS

RFC 9063 denomina a los nombres DNS el segundo espacio de nombres global importante de Internet, junto con las direcciones IP.⁴ En HIP, un Host Identifier puede publicarse, por ejemplo, en DNS, o puede permanecer sin publicar.⁴ Esto solo significa que DNS puede figurar como lugar de publicación del Host Identifier en la arquitectura descrita, no que el nombre DNS se convierta por sí mismo en Host Identifier.⁴

El borrador de trabajo DID Core de 2020 cita los domain name registries como ejemplo de autoridades centralizadas en los sistemas tradicionales de gestión de identidad.⁵ El mismo borrador afirma que dichas autoridades actúan como sus propias raíces de confianza desde el punto de vista de la verificación criptográfica de la confianza.⁵ Por eso, la comparación con nombres de tipo DNS conviene formularla con cautela: la fuente habla de registradores de dominios como autoridades centralizadas, no de que toda cadena DNS en cualquier protocolo tenga una semántica criptográfica concreta.⁵

La diferencia práctica es la siguiente: en HIP, la identidad criptográfica del host viene dada por Host Identifier, mientras que DNS pertenece a otro espacio de nombres.⁴ Si una dirección IPvX en una especificación concreta va a derivarse de una clave pública, su verificación deberá describirse mediante las reglas de esa especificación, no mediante una suposición sobre la resolución DNS.⁴

En qué se diferencia de DID

DID Core 2022 define un DID como un URI que vincula un DID subject con un DID document.¹ Un DID document puede expresar material criptográfico, verification methods o servicios que proporcionan mecanismos para demostrar el control sobre el DID.¹ La especificación también dice que el diseño permite al controlador del DID demostrar control sin permiso de otra parte, aunque otras partes pueden ayudar a descubrir información asociada al DID.¹

Pero DID Core no prescribe una única tecnología ni una única criptografía para generar, mantener, resolver o interpretar DID.¹ La especificación admite explícitamente que los implementers pueden crear DIDs a partir de identificadores registrados en sistemas federados o centralizados de gestión de identidad.¹ Por tanto, de la forma did:method:id no se puede concluir por sí sola que el identificador sea igual a una clave pública.¹

La historia de DID Core subraya el carácter dependiente del método de este modelo.⁵ El borrador de trabajo de 2020 describía los DID methods como un mecanismo para crear, leer, actualizar y desactivar DID y DID documents asociados en un DID registry concreto.⁵ El mismo borrador advertía de que los DID de distintos métodos pueden no ser interoperables y de que distintos DID methods pueden usar esquemas criptográficos diferentes.⁵

Para IPvX, esto significa que DID puede usarse en una discusión sobre identidad solo indicando el DID method y las reglas de resolución.¹⁵ Si la propiedad que queremos debatir es precisamente que «la dirección se demuestra mediante una clave», DID Core por sí solo no basta: hay que examinar el DID document, las verification methods y el método que define las operaciones con ese DID.¹⁵

Content addressing: un hash de datos no equivale a la identidad de un sujeto

RFC 6920 define formas de identificar un objeto digital mediante el resultado de una función hash.³ El documento introduce Named Information identifiers, incluidos los URI ni, así como formas binarias y pronunciables por humanos de esos nombres.³ Estos formatos están destinados a admitir, pero no a exigir, una vinculación fuerte con el objeto, de modo que el objeto pueda autenticarse hasta el mismo grado que la referencia a él.³

La comprobación clave en este modelo es la name-data integrity: la representación recibida del recurso se compara con el nombre por el que se solicitó el recurso.³ RFC 6920 también indica que un Named Identifier nombra un recurso, y que el mecanismo para dereferenciar y encontrar el recurso debe ser conocido por la parte que lo dereferencia.³ Esto separa el «nombre por hash» de la «ruta hasta el lugar de almacenamiento».³

RFC 6920 examina por separado el caso en que la entrada de la función hash es una clave pública, y recomienda calcular el hash sobre la clave pública en la estructura X.509 SubjectPublicKeyInfo.³ Sin embargo, el mismo documento afirma que, aparte de ese caso especial, la entrada de la función hash no la define RFC 6920 y debe ser definida por otras especificaciones.³ Por eso, un hash de archivo, un hash de mensaje y un hash de clave pública tienen significados distintos, aunque técnicamente todos sean resultados de una función hash.³

También hay una limitación importante: RFC 6920 permite hashes truncados, pero afirma explícitamente que un hash truncado de 32 bits es prácticamente inútil para la seguridad en casi todos los casos, aunque puede ser útil para la nomenclatura.³ Es un buen ejemplo de resultado negativo para los proyectos de direccionamiento: la compacidad del nombre no proporciona automáticamente robustez criptográfica.³

did:drn como ejemplo de nombre externo sin controlador incorporado

El proyecto did:drn es útil como ejemplo limítrofe, pero hay que tener en cuenta su estatus: los Internet-Drafts son documentos de trabajo de la IETF, pueden actualizarse, sustituirse o quedar obsoletos, y no deben citarse de otra forma que como work in progress.² En este proyecto, did:drn establece un mapeo determinista de URN a un formato compatible con DID, Decentralized Resource Name.²

La resolución básica de did:drn debe ser capaz de construir un DID Document mínimo a partir de la propia cadena DID, sin recurrir obligatoriamente a un registro centralizado, un registro distribuido o un servicio de red.² Al mismo tiempo, el proyecto afirma explícitamente que un did:drn identifier no afirma ni implica por defecto la existencia de un controlador.² Verification methods y service endpoints en did:drn se describen como propiedades opcionales del DID Document.²

Este ejemplo muestra un matiz importante: un nombre determinista y la ausencia de una dependencia de red obligatoria en la baseline resolution no equivalen a una prueba de posesión de la clave privada.² Para demostrar control hacen falta reglas y verification methods, no solo una transformación reversible de URN en una cadena DID.²

Cómo hablar con precisión de una dirección IPvX

Proponemos que en los textos sobre IPvX se separen explícitamente tres cuestiones, sin presentarlas como una propiedad ya demostrada de una implementación global: qué material actúa como identificador, cómo se verifica el control sobre él y mediante qué mecanismo se encuentra la ruta de entrega.¹³⁴ Si el identificador es una clave pública o un valor derivado de ella, el modelo más cercano entre las fuentes citadas es HIP, donde Host Identifier es una clave pública y la clave privada se usa para autenticar la identidad correspondiente.⁴ Si el identificador es un DID, hay que indicar el DID method, porque DID Core no fija una tecnología ni una criptografía únicas para todos los DIDs.¹ Si el valor es el hash de un objeto digital, lo más correcto es hablar de la verificación de la relación entre nombre y datos según el modelo de RFC 6920.³

Este lenguaje ayuda a no mezclar enrutamiento, identidad y descubrimiento.¹³⁴ HIP muestra la separación entre Host Identity namespace y los namespaces IP/DNS.⁴ DID Core muestra el modelo de URI, DID document, verification methods e infraestructura dependiente del método.¹⁵ RFC 6920 muestra el modelo de nombre por hash, donde encontrar el recurso sigue estando separado del propio nombre.³

Comparación breve

Modelo	Qué define el identificador	Dónde se verifica la relación
IP en el contexto de HIP	Espacio global separado de direcciones IP	HIP separa el espacio IP del Host Identity namespace.4
DNS en el contexto de HIP	Espacio global separado de nombres DNS	Host Identifier puede publicarse en DNS, pero HIP sigue introduciendo un espacio Host Identity separado.4
HIP Host Identifier	Clave pública de un par asimétrico	La clave privada la usa la parte para autenticar la identidad ante otras partes.4
DID	URI que vincula el subject con el DID document	El DID document puede contener verification methods, y la tecnología concreta depende del DID method.15
RFC 6920 / ni	Hash de un objeto digital o, en un caso especial, hash de una clave pública	Se verifica la correspondencia entre los datos y el nombre; la forma de encontrar el recurso debe ser conocida por la parte que lo dereferencia.3
did:drn draft	Mapeo determinista de URN a una forma compatible con DID	El did:drn básico no implica un controlador, y las verification methods son opcionales.2

Conclusión

El direccionamiento criptográfico basado en claves, en sentido estricto, exige una especificación en la que el identificador esté vinculado a una clave pública o a un valor derivado de ella, y el control se verifique mediante la posesión de la clave privada correspondiente; ese es precisamente el modelo que HIP describe para Host Identifier.⁴ Las direcciones IP y los nombres DNS en RFC 9063 se consideran espacios de nombres separados, que no deben identificarse automáticamente con una Host Identity criptográfica.⁴ DID proporciona un formato URI general y un DID Document con verification methods, pero no impone una criptografía única ni una infraestructura única de resolución.¹ El content addressing según RFC 6920 verifica la relación del nombre con un objeto digital, pero el significado del hash depende de lo que se haya introducido como entrada en la función hash.³

Para IPvX, esto no es una prueba de una propiedad concreta del protocolo, sino una disciplina para describir la arquitectura.¹³⁴ Si decimos «dirección basada en una clave», hay que indicar por separado qué es exactamente el material de clave, cómo se verifica la posesión de la clave privada, cómo se realiza la entrega y qué registros externos intervienen en el descubrimiento.¹³⁴

Fuentes

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