Kryptografische Adressierung über Schlüssel: IP, DNS, DID und IPvX

Kryptografische Adressierung über Schlüssel ist eine griffige Formulierung, doch dahinter können sehr unterschiedliche Architekturmodelle stehen: ein öffentlicher Schlüssel als Host-Identifier, ein Hash des öffentlichen Schlüssels, ein DID-Dokument mit verification methods oder der Hash des Inhalts eines digitalen Objekts.¹³⁴ In diesem Artikel schreiben wir IPvX keine Eigenschaften zu, die in den angeführten Quellen nicht belegt sind: Die Quellen unten beschreiben HIP, DID, did:drn und hash-basierte Namen, nicht aber eine Spezifikation von IPvX.¹²³⁴ Deshalb verwenden wir sie als Vokabular für eine präzise Diskussion: wo ein Identifier durch den Besitz eines Schlüssels nachgewiesen wird, wo er ein Netzwerk-Locator ist und wo er ein Verweis auf einen externen Eintrag bleibt.¹³⁴

Warum Identität, Locator und Name getrennt werden müssen

RFC 9063 beschreibt zwei wichtige globale Namensräume des Internets: IP-Adressen und DNS-Namen.⁴ Dasselbe Dokument sagt ausdrücklich, dass diese Räume semantisch überladen wurden, weil sie zu viele Funktionen erfüllen mussten.⁴ Als Antwort darauf führt die HIP-Architektur den Host-Identity-Namensraum ein, der die Lücke zwischen dem IP- und dem DNS-Namensraum schließen soll.⁴

In HIP bezieht sich Host Identity auf eine Rechenplattform, während der Host Identifier die konkrete Bit-Repräsentation dieser Identität ist.⁴ Das Dokument betont außerdem den Unterschied zwischen identity als abstrakter Entität und identifier als konkretem Bitmuster, das bei der Identifikation verwendet wird.⁴ Für Netzwerkingenieure ist das eine hilfreiche Unterscheidung: Der eine Begriff beantwortet die Frage „wer nimmt an der Interaktion teil“, der andere „welches Bitmaterial wird für die Prüfung verwendet“, während der IP-Namensraum in der HIP-Architektur ein separater Namensraum bleibt.⁴

Wenn wir über IPvX sprechen, formulieren wir Eigenschaften daher bewusst konditional: Wenn eine Adresse ein öffentlicher Schlüssel oder ein daraus abgeleiteter Wert ist, ist das ein bestimmtes Prüfmodell; wenn eine Adresse über ein Dokument oder ein Verzeichnis aufgelöst wird, ist das ein anderes Vertrauensmodell; wenn der Wert ein Hash von Daten ist, handelt es sich bereits um ein Modell des Content Addressing.¹³⁴

Das HIP-Modell: der Identifier als öffentlicher Schlüssel

Im kryptografischen Kern von HIP ist der Host Identifier der öffentliche Schlüssel eines asymmetrischen Schlüsselpaars.⁴ In der Terminologie von RFC 9063 wird angenommen, dass der private Schlüssel nur der Partei bekannt ist, die durch den entsprechenden öffentlichen Schlüssel identifiziert wird, und von dieser Partei genutzt wird, um ihre Identität gegenüber anderen Parteien zu authentisieren.⁴ In dieser konkreten Architektur hängt die Prüfung daher nicht nur daran, dass eine Zeichenkette oder ein binärer Wert existiert, sondern daran, dass der Teilnehmer einen kryptografischen Austausch mit dem entsprechenden privaten Schlüssel erfolgreich durchführen kann.⁴

HIP definiert außerdem das Host Identity Tag als 128-Bit-Wert, der durch einen kryptografischen Hash des Host Identifier und durch Bits erzeugt wird, die den verwendeten Hash angeben.⁴ Das ist für die Adressierung über einen abgeleiteten Wert wichtig: Ein kompakter Tag ist nicht dasselbe wie der öffentliche Schlüssel selbst, aber seine Bedeutung ergibt sich daraus, dass er nach den HIP-Regeln aus dem Host Identifier berechnet wurde.⁴ Das Dokument hält zudem fest, dass es beim Austausch eines Schlüssels Übergangszeiträume geben kann, in denen mehr als ein Identifier für eine Host Identity aktiv ist.⁴

Aus diesem Modell lassen sich nicht automatisch Eigenschaften jeder beliebigen Systemarchitektur ableiten, in der das Wort „Schlüssel“ vorkommt.⁴ Die korrekte Aussage ist enger: In HIP ist der Host Identifier ein öffentlicher Schlüssel, und die Authentisierung stützt sich auf das entsprechende Paar aus öffentlichem und privatem Schlüssel.⁴

Worin sich das von IP-Adressen unterscheidet

HIP betrachtet IP-Adressen als separaten globalen Namensraum des Internets, der sich vom Host Identity namespace unterscheidet.⁴ Die HIP-Protokollschicht liegt zwischen der Internetworking- und der Transportschicht, und die Architektur selbst beansprucht Unterstützung für Mobilität von End-Hosts, Multihoming und NAT-Traversal.⁴ In dieser Architektur sind die Identität eines Hosts und die aktuellen IP-Informationen nicht dasselbe Objekt im Modell.⁴

Für die Diskussion von IPvX liefert das einen sauberen Rahmen, aber keinen fertigen Schluss über die Implementierung von IPvX.⁴ Wenn in einem Projekt eine Adresse aus einem Schlüssel abgeleitet wird, bezieht sich die prüfbare Eigenschaft auf das Schlüsselmaterial und den Besitz des privaten Schlüssels, analog zur kryptografischen HI in HIP.⁴ Wenn der Wert dagegen für die Zustellung im Netz verwendet wird, muss gesondert beschrieben werden, wie er sich zu Routing und aktuellem Erreichbarkeitspunkt verhält, weil RFC 9063 selbst den IP-Namensraum und den Host Identity namespace trennt.⁴

Worin sich das von DNS-Namen unterscheidet

RFC 9063 nennt DNS-Namen neben IP-Adressen als zweiten wichtigen globalen Namensraum des Internets.⁴ In HIP kann der Host Identifier zum Beispiel im DNS veröffentlicht werden oder auch unveröffentlicht bleiben.⁴ Das bedeutet lediglich, dass DNS in der beschriebenen Architektur als Ort der Veröffentlichung eines Host Identifier auftreten kann, nicht aber, dass der DNS-Name selbst zum Host Identifier wird.⁴

Der Working Draft von DID Core aus dem Jahr 2020 nennt domain name registries als Beispiel für zentralisierte Autoritäten in traditionellen Identitätsmanagementsystemen.⁵ Derselbe Entwurf sagt, dass solche Autoritäten aus Sicht der kryptografischen Vertrauensprüfung als eigene Trust Roots auftreten.⁵ Ein Vergleich mit DNS-ähnlichen Namen sollte daher vorsichtig formuliert werden: Die Quelle spricht über Domain-Registries als zentralisierte Autoritäten, nicht darüber, dass jede DNS-Zeichenkette in jedem Protokoll eine bestimmte kryptografische Semantik hätte.⁵

Der praktische Unterschied ist: In HIP wird die kryptografische Identität eines Hosts durch den Host Identifier festgelegt, während DNS zu einem anderen Namensraum gehört.⁴ Wenn eine IPvX-Adresse in einer konkreten Spezifikation von einem öffentlichen Schlüssel abgeleitet wird, muss ihre Prüfung nach den Regeln dieser Spezifikation beschrieben werden und nicht durch eine Annahme über DNS-Auflösung.⁴

Worin sich das von DID unterscheidet

DID Core 2022 definiert einen DID als URI, der ein DID subject mit einem DID document verknüpft.¹ Ein DID document kann kryptografisches Material, verification methods oder Dienste ausdrücken, die Mechanismen zum Nachweis der Kontrolle über den DID bereitstellen.¹ Die Spezifikation sagt außerdem, dass das Design es dem DID-Controller ermöglicht, Kontrolle ohne Erlaubnis einer anderen Partei nachzuweisen, auch wenn andere Parteien bei der Auffindung von Informationen helfen können, die mit dem DID verbunden sind.¹

DID Core schreibt jedoch weder eine einzelne Technologie noch eine einzelne Kryptografie für Erzeugung, Beständigkeit, Auflösung oder Interpretation von DIDs vor.¹ Die Spezifikation lässt ausdrücklich zu, dass implementers DIDs auf Grundlage von Identifiern erstellen können, die in föderierten oder zentralisierten Identitätsmanagementsystemen registriert sind.¹ Aus der Form did:method:id allein lässt sich daher nicht schließen, dass der Identifier einem öffentlichen Schlüssel entspricht.¹

Die Geschichte von DID Core unterstreicht den methodenabhängigen Charakter dieses Modells.⁵ Der Working Draft von 2020 beschrieb DID methods als Mechanismus zum Erzeugen, Lesen, Aktualisieren und Deaktivieren von DIDs und zugehörigen DID documents in einer konkreten DID registry.⁵ Derselbe Entwurf warnte, dass DIDs aus unterschiedlichen Methoden möglicherweise nicht interoperabel sind und dass verschiedene DID methods unterschiedliche kryptografische Schemata verwenden können.⁵

Für IPvX bedeutet das: DID kann in der Identitätsdiskussion nur unter Angabe der DID method und der Regeln für die Auflösung verwendet werden.¹⁵ Wenn die Eigenschaft, über die wir sprechen wollen, gerade lautet „die Adresse wird durch einen Schlüssel nachgewiesen“, reicht DID Core für sich genommen nicht aus: Man muss auf das DID document, die verification methods und die Methode schauen, die die Operationen mit diesem DID definiert.¹⁵

Content Addressing: Ein Daten-Hash ist nicht die Identität eines Subjekts

RFC 6920 definiert Verfahren, um ein digitales Objekt über das Ergebnis einer Hash-Funktion zu identifizieren.³ Das Dokument führt Named Information identifiers ein, darunter ni URIs sowie binäre und menschlich aussprechbare Formen solcher Namen.³ Diese Formate sind dafür gedacht, eine starke Bindung an das Objekt zu unterstützen, aber nicht zu erzwingen, damit das Objekt bis zu demselben Grad authentifiziert werden kann wie der Verweis darauf.³

Die zentrale Prüfung in diesem Modell ist name-data integrity: Die erhaltene Repräsentation der Ressource wird mit dem Namen verglichen, unter dem die Ressource angefordert wurde.³ RFC 6920 weist außerdem darauf hin, dass ein Named Identifier eine Ressource benennt, während der Mechanismus zum Dereferenzieren und Auffinden der Ressource der Partei bekannt sein muss, die sie dereferenziert.³ Das trennt den „Namen per Hash“ von der „Route zum Speicherort“.³

RFC 6920 behandelt gesondert den Fall, dass die Eingabe der Hash-Funktion ein öffentlicher Schlüssel ist, und empfiehlt, den Hash über den öffentlichen Schlüssel in der Struktur X.509 SubjectPublicKeyInfo zu berechnen.³ Dasselbe Dokument sagt jedoch, dass die Eingabe der Hash-Funktion abgesehen von diesem Sonderfall nicht durch RFC 6920 festgelegt wird und von anderen Spezifikationen definiert werden muss.³ Deshalb haben der Hash einer Datei, der Hash einer Nachricht und der Hash eines öffentlichen Schlüssels unterschiedliche Bedeutungen, auch wenn sie technisch alle Ergebnisse einer Hash-Funktion sind.³

Es gibt auch eine wichtige Einschränkung: RFC 6920 lässt gekürzte Hashes zu, sagt aber ausdrücklich, dass ein auf 32 Bit gekürzter Hash für Sicherheit in fast allen Fällen praktisch nutzlos ist, auch wenn er für die Benennung nützlich sein kann.³ Das ist ein gutes Beispiel für ein negatives Ergebnis bei Adressierungsprojekten: Die Kompaktheit eines Namens führt nicht automatisch zu kryptografischer Stärke.³

did:drn als Beispiel für einen externen Namen ohne eingebauten Controller

Der Entwurf did:drn ist als Grenzfall nützlich, doch sein Status muss berücksichtigt werden: Internet-Drafts sind Arbeitsdokumente der IETF, können aktualisiert, ersetzt oder obsolet werden und sollten nur als work in progress zitiert werden.² In diesem Entwurf definiert did:drn eine deterministische Abbildung von URNs in ein DID-kompatibles Format, den Decentralized Resource Name.²

Die grundlegende Auflösung von did:drn muss in der Lage sein, ein minimales DID Document aus der DID-Zeichenkette selbst zu konstruieren, ohne zwingend auf ein zentrales Register, ein verteiltes Journal oder einen Netzwerkdienst zuzugreifen.² Zugleich sagt der Entwurf ausdrücklich, dass ein did:drn identifier standardmäßig keinen Controller behauptet oder impliziert.² Verification methods und service endpoints werden in did:drn als optionale Eigenschaften des DID Document beschrieben.²

Dieses Beispiel zeigt eine wichtige Grenze: Ein deterministischer Name und das Fehlen einer zwingenden Netzwerkabhängigkeit in der baseline resolution sind nicht dasselbe wie der Nachweis des Besitzes eines privaten Schlüssels.² Für den Nachweis von Kontrolle braucht es Regeln und verification methods, nicht nur eine umkehrbare Umwandlung einer URN in eine DID-Zeichenkette.²

Wie man präzise über eine IPvX-Adresse spricht

Wir schlagen vor, in Texten zu IPvX drei Fragen ausdrücklich zu trennen, ohne dies als bereits bewiesene Eigenschaft einer globalen Implementierung auszugeben: welches Material der Identifier ist, wie die Kontrolle darüber geprüft wird und durch welchen Mechanismus der Zustellpfad gefunden wird.¹³⁴ Wenn der Identifier ein öffentlicher Schlüssel oder ein daraus abgeleiteter Wert ist, ist das naheliegendste Modell aus den angeführten Quellen HIP, wo der Host Identifier ein öffentlicher Schlüssel ist und der private Schlüssel zur Authentisierung der entsprechenden Identität verwendet wird.⁴ Wenn der Identifier ein DID ist, muss die DID method angegeben werden, weil DID Core keine einheitliche Technologie oder Kryptografie für alle DIDs festlegt.¹ Wenn der Wert ein Hash eines digitalen Objekts ist, ist es korrekter, von der Prüfung der Bindung zwischen Name und Daten nach dem Modell von RFC 6920 zu sprechen.³

Eine solche Sprache hilft, Routing, Identität und Auffindung nicht zu vermischen.¹³⁴ HIP zeigt die Trennung zwischen Host Identity namespace und IP/DNS namespaces.⁴ DID Core zeigt ein Modell aus URI, DID document, verification methods und methodenabhängiger Infrastruktur.¹⁵ RFC 6920 zeigt ein Modell eines hash-basierten Namens, bei dem das Auffinden der Ressource vom Namen selbst getrennt bleibt.³

Kurzer Vergleich

Modell	Was der Identifier festlegt	Wo die Bindung geprüft wird
IP im HIP-Kontext	Separater globaler Namensraum von IP-Adressen	HIP trennt den IP-Namensraum vom Host Identity namespace.4
DNS im HIP-Kontext	Separater globaler Namensraum von DNS-Namen	Der Host Identifier kann im DNS veröffentlicht werden, doch HIP führt dennoch einen separaten Host-Identity-Namensraum ein.4
HIP Host Identifier	Öffentlicher Schlüssel eines asymmetrischen Paars	Der private Schlüssel wird von der Partei zur Authentisierung der Identität gegenüber anderen Parteien verwendet.4
DID	URI, der ein subject mit einem DID document verknüpft	Das DID document kann verification methods enthalten, und die konkrete Technologie hängt von der DID method ab.15
RFC 6920 / ni	Hash eines digitalen Objekts oder, in einem Sonderfall, Hash eines öffentlichen Schlüssels	Geprüft wird die Übereinstimmung der Daten mit dem Namen; das Verfahren zum Auffinden der Ressource muss der dereferenzierenden Partei bekannt sein.3
did:drn draft	Deterministische Abbildung einer URN in eine DID-kompatible Form	Ein grundlegendes did:drn impliziert keinen Controller, und verification methods sind optional.2

Fazit

Kryptografische Adressierung über Schlüssel im strengen Sinn erfordert eine Spezifikation, in der der Identifier mit einem öffentlichen Schlüssel oder einem daraus abgeleiteten Wert verbunden ist und die Kontrolle durch den Besitz des entsprechenden privaten Schlüssels geprüft wird; genau dieses Modell beschreibt HIP für den Host Identifier.⁴ IP-Adressen und DNS-Namen werden in RFC 9063 als separate Namensräume betrachtet, die nicht automatisch mit einer kryptografischen Host Identity gleichgesetzt werden sollten.⁴ DID bietet ein allgemeines URI-Format und ein DID Document mit verification methods, erzwingt aber weder eine einheitliche Kryptografie noch eine einheitliche Auflösungsinfrastruktur.¹ Content Addressing nach RFC 6920 prüft die Bindung eines Namens an ein digitales Objekt, doch die Bedeutung des Hashes hängt davon ab, was der Hash-Funktion als Eingabe übergeben wurde.³

Für IPvX ist das kein Nachweis einer konkreten Protokolleigenschaft, sondern eine Disziplin der Architekturbeschreibung.¹³⁴ Wenn wir von einer „Adresse per Schlüssel“ sprechen, müssen wir gesondert angeben, was genau das Schlüsselmaterial ist, wie der Besitz des privaten Schlüssels geprüft wird, wie die Zustellung erfolgt und welche externen Einträge an der Auffindung beteiligt sind.¹³⁴

Quellen

1. Decentralized Identifiers (DIDs) v1.0, w3.org, 19.07.2022
2. Decentralized Resource Name (DRN) DID Method, ietf.org, 24.03.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, 03.04.2020
6. Decentralized Identifiers (DIDs) v1.0, w3.org, 15.06.2021
7. Decentralized Identifiers (DIDs) v1.0, w3.org, 08.04.2020
8. RFC 6920: Naming Things with Hashes, datatracker.ietf.org