Zusammenfassung

  • RFC 6920 definierte im April 2013 Named-Information-Namen (ni) für digitale Objekte. Hashverfahren, angegebene Länge und Hashwert bestimmen, ob zwei Namen dieselben Daten bezeichnen; ein optionaler Hostname entscheidet dabei nicht mit.
  • Ein ni-Name lässt sich auf eine HTTP(S)-Adresse unter /.well-known/ni/ abbilden. Der Server liefert mögliche Bytes, der Client kann sie prüfen. Das IANA-Register verwaltet Algorithmusnamen und Längen, keine Kopien der benannten Dateien.
  • Für eine konkrete Nutzung braucht es einen vertrauenswürdig erhaltenen Namen, einen erreichbaren Lieferweg und einen Client, der den passenden Hash tatsächlich berechnet. Ein datierter Ablauf dieser Schritte wäre der Beleg für eine bestimmte Installation.

Die Adresse war beständig, der Inhalt beweglich

Bei einer üblichen URL kontrolliert der Server, was er an einem Pfad heute ausliefert. Das ist für laufend aktualisierte Seiten nützlich. Alte Links bleiben brauchbar, während Texte korrigiert oder Dateien ersetzt werden. Wer dagegen eine genaue Version einer Software oder eines Dokuments benötigt, kann sich auf die Adresse allein nicht verlassen. Der erfolgreiche Kontakt zum erwarteten Host sagt noch nichts darüber, ob die erwarteten Bytes zurückkamen.

Hashwerte wurden schon vorher in Bezeichner geschrieben, aber nicht nach einer gemeinsamen Grammatik. RFC 6920 brachte den ni-URI: erst das Hashverfahren, nach einem Semikolon den ohne Füllzeichen als base64url codierten Wert. Üblicherweise wird über die Bytes des Objekts gerechnet, das bei der Abfrage zurückkommen soll. Legt ein anwendendes Protokoll eine andere Eingabe fest, muss es diese Regel beschreiben.

Der neue Name beantwortet eine andere Frage als die URL. Die URL nennt eine Anlaufstelle. Der Hashname bestimmt, welche Bytes ein prüfender Client akzeptieren soll. Eine Datei kann auf einen anderen Server umziehen und ihre Identität behalten, solange ihr Inhalt gleich ist. Ein Server kann am alten Pfad neue Bytes anbieten; für sie ergibt sich ein anderer Hashname. Der Betreiber behält den Weg in der Hand, verliert aber die einseitige Entscheidung über die Identität eines geprüften Objekts.

RFC 6920 zieht die Grenze ausdrücklich. Zum Vergleich zweier ni-Namen zählen das Verfahren und der Hashwert samt Länge. Optionale Authority-Felder und Suchparameter bleiben außen vor. Zwei verschiedene Hosts können dasselbe Objekt anbieten. Ihre Namen sind identisch, wenn die entscheidenden Hashteile übereinstimmen. Der Host ist ein Suchhinweis, kein Eigentumstitel für die Bytes.

Beim Ausliefern kehrt der Host zurück

Ein Hash verrät nicht, welche Maschine eine Kopie gespeichert hat. Die RFC definiert deshalb eine Übersetzung in HTTP- oder HTTPS-URLs unter /.well-known/ni/. Steht ein Host im ni-Namen, liefert er den Host der abgeleiteten URL. Ohne ihn kann die Anwendung aus ihrem Kontext einen wählen. Von dort kann eine Weiterleitung folgen. Am Ende muss der Client, wenn er die Bindung nutzen will, die erhaltenen Daten mit dem Namen vergleichen.

Die abgeleitete URL garantiert keine vorhandene Datei. Ein korrekt beschrifteter Schrank kann leer sein. Bleibt eine Antwort aus, liegt ein Problem der Verfügbarkeit vor. Kommen Bytes an, deren Hash nicht passt, liegt ein Problem der Identität oder der Berechnungsregel vor. Beide Ereignisse als kaputten Link zu behandeln verschleiert, ob der Betreiber eine Kopie bereitstellen oder der Client einen Austausch zurückweisen muss.

Drei Akteure teilen sich die Aufgabe. Der Herausgeber des Namens legt die erwarteten Bytes fest. Der Serverbetreiber hält Kandidaten bereit. Die Clientsoftware entscheidet, ob sie nachrechnet. RFC 6920 erlaubt Anwendungen, ni-Namen zu verarbeiten, ohne jedes Mal den Zusammenhang zwischen Name und Daten zu prüfen. Ein sichtbarer Hash in einer Oberfläche beweist daher noch keine Prüfung im Programm.

Für andere Umgebungen beschrieb das Dokument außerdem eine kompakte Binärform und das besser vorlesbare nih-Format mit Hexadezimalzeichen und Prüfziffer. Diese Formen erleichtern die Übertragung des Namens. Sie bauen keine neue Speicherinfrastruktur.

Das Register sortiert Verfahren, keine Dateien

Unabhängige Implementierungen brauchen gemeinsame Namen für die Hashverfahren und ihre Ausgabelängen. Das IANA-Register für Named Information führt solche Bezeichnungen, Referenzen und den Inhaltstyp-Parameter ct. RFC 6920 verlangt Unterstützung für vollständiges SHA-256 und erlaubt ausdrücklich benannte Kürzungen. Je kürzer der Wert, desto eher können unterschiedliche Inhalte kollidieren; die Länge gehört deshalb erkennbar zum Namen.

Ein Registereintrag für einen Algorithmus belegt eine gemeinsame Schreibweise. Er belegt keine online liegende Datei und nennt keinen Anbieter, der sie ausliefert. Die schmale Rolle ist ein Vorteil: Eine zentrale Stelle kann Interoperabilität der Bezeichnungen sichern, ohne zur Betreiberin jedes damit benannten Objekts zu werden. Die laufende Verteilung bleibt bei denjenigen, die Speicher und Netzverbindung bereitstellen.

Die Sicherheitsgrenze verläuft noch früher. RFC 6920 erklärt, dass die Bindung des Namens an die Bytes nur so vertrauenswürdig ist wie der Name, den der Client ursprünglich erhielt. Ein Angreifer kann eine schädliche Datei zusammen mit ihrem richtigen Hash versenden. Die Rechnung stimmt dann; die Herkunft des Sollwerts bleibt zweifelhaft. Ein veröffentlichter Hash macht leicht erratbare Inhalte auch nicht geheim. Jemand kann mögliche Dateien berechnen und die Werte vergleichen.

Die offiziellen Texte belegen Format, Vergleich und HTTP-Zuordnung. Für die Behauptung, ein bestimmtes Produkt habe das Verfahren im Betrieb genutzt, fehlen ein datierter Abruf und die Hashprüfung des Clients. Die Leistung von 2013 war die Trennung zweier bisher oft vermischter Antworten: welche Bytes gemeint sind und wo sie gerade abgeholt werden können.