Naming Things with Hashes
Extracted elements (29)
A new IANA registry for hash algorithms is created specifically for this specification rather than reusing existing registries, in order to avoid mixing strong full-length and weaker truncated hash algorithms in other protocol registries. Inclusion of weak hash functions (e.g., MD5) can trigger costly false positives in code audits for obsolete ciphers.
Public key hashes are computed over the SubjectPublicKeyInfo structure (RFC 5280 Section 4.1) for compatibility with DANE TSLA (RFC 6698) and to ensure relevant public key parameters are included in the hash input, which is sometimes necessary for security. This does not require full X.509 compliance since formatting as SubjectPublicKeyInfo is well-supported by libraries.
The nih URI scheme uses lowercase hex encoding rather than base64url because base64url uses both uppercase and lowercase characters, which can cause confusion when spoken aloud. The nih format is specifically designed for the 'confirmation' use case where a resource name must be spoken over a voice channel.
In the nih URI format, for algorithms with a reserved Suite ID, the alg field MAY contain the Suite ID as an ASCII-encoded decimal number instead of the hash name string (e.g., '3' instead of 'sha-256-120'). Implementations MUST be able to match decimal ID values for all supported algorithms even if they do not support the binary format.
The authority field in an ni URI has different semantics from HTTP URL authorities: ni URIs with different authorities (or no authority) that have matching digest algorithm, length, and value all refer to the same object. The authority assists applications in accessing the object but does not affect identity.
A client requesting a .well-known/ni URL MUST be able to handle 3xx HTTP redirection responses, as servers will often respond with a redirect rather than the resource directly.
If a user agent is sensitive to Content Type and the ni URI has a 'ct=' attribute and the retrieved object has a server-specified Content Type, and the two Content Types do not match, the client SHOULD treat that as a potential security error.
Implementations MUST support parsing the 'ct=' query string attribute in ni URIs, which specifies the MIME Content Type of the associated data. Implementations SHOULD support name-data integrity validation for at least the application/octet-stream Content Type (equivalent to binary, no Content-Transfer-Encoding).
SHA-256 is mandatory to implement: implementations MUST be able to generate/send and accept/process names based on a sha-256 hash. Implementations MAY support additional hash algorithms and MAY use those for specific names.
The digest value in an ni URI MUST be encoded using base64url encoding (RFC 4648) with no '=' padding characters.
When a hash value is truncated to N bits, the leftmost N bits (most significant bits in network byte order) from the binary representation of the hash MUST be used. The name MUST indicate the truncation via the algorithm string (e.g., 'sha-256-32' for 32-bit truncation of sha-256).
When comparing two ni/nih names, an implementation MUST only consider the digest algorithm and the digest value; it MUST NOT consider other fields such as the authority or query parameters. Two hashes are identical if and only if the decoded hashes have the same algorithm, same length, and same binary value.
When the hash input is a public key, the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure (RFC 5280 Section 4.1), chosen for compatibility with the DANE TSLA protocol (RFC 6698) and to include relevant public key parameters.
An ni URI maps to an HTTP(S) .well-known URL of the form 'http://h-authority/.well-known/ni/alg/val?query-string'. If the ni name specifies a non-empty authority, the h-authority MUST have the same value; if the authority is empty, h-authority MAY be derived from application context such as the web page origin.
The ni URI scheme uses the format 'ni://<authority>/<alg>;<val>[?<query>]' where the authority is optional, alg is the digest algorithm name from the IANA registry, and val is the base64url-encoded (no padding) hash output. All ni names with matching digest algorithm, length, and value refer to the same object regardless of authority.
The nih (Named Information for Humans) URI scheme provides a human-speakable form using lowercase ASCII hex encoding, with format 'nih:<alg>;<hexval>[;<checkdigit>]'. Separators ('-') MAY be interspersed in the hash value, and a Luhn mod N (N=16) checkdigit (per ISO/IEC 7812) MAY be appended to catch transcription errors.
The URL Segment format allows the 'alg-val' production (e.g., 'sha-256;UyaQV-...') to be embedded in the pathname, query string, or fragment of existing HTTP URLs without the ni scheme. Clients MUST NOT assume any URL with a pathname component matching 'alg-val' was produced per this specification.
IANA assigned the .well-known URI suffix 'ni' per RFC 5785, enabling the HTTP(S) mapping of ni URIs described in Section 4.
IANA created the 'Named Information Hash Algorithm Registry' with fields: Suite ID (0–63, optional), hash algorithm name string, value length, underlying algorithm reference, and status ('current' or 'deprecated'). Initial entries: sha-256 (ID 1, 256 bits), sha-256-128 (ID 2), sha-256-120 (ID 3), sha-256-96 (ID 4), sha-256-64 (ID 5), sha-256-32 (ID 6); IDs 0 and 32 reserved. Future assignments via Expert Review.
IANA created the 'Named Information URI Parameter Definitions' registry for query string parameters used in ni URIs, with Expert Review policy. Initial entry: 'ct' (Content Type, RFC 6920).
IANA registered the 'ni' URI scheme as a permanent URI scheme per RFC 4395, with syntax and semantics defined in Section 3 of this document.
IANA registered the 'nih' URI scheme as a permanent URI scheme per RFC 4395, with syntax and semantics defined in Section 7 of this document, for human-speakable Named Information URIs.
Disclosure of an ni name does not necessarily disclose the referenced object, but may enable an attacker to determine its contents via search engines or by guessing, especially for highly formatted objects with little variation. Hash-based names do not protect confidentiality of the hashed content.
Malformed ni URIs containing non-base64 characters, whitespace, or other non-conforming strings MUST NOT be treated as matching any other ni URI. Implementers must check the behavior of libraries for such parsing problems.
ni names provide name-data integrity but not confidentiality: no secret information is required to generate or verify a name, so the hash only proves integrity of the referenced object. The proof of integrity of the name is only as strong as the integrity of the source from which the name was obtained.
The presence of a domain name in the authority field of an ni URI implies nothing about the relationship between the domain name owner and the referenced content. Application developers MUST NOT assume any relationship between the domain registrant and matching content.
Truncated hashes reduce security: a birthday-attack collision requires O(2^(N/2)) work against an N-bit hash. 32-bit truncated hashes are essentially useless for security; applications using less than 100-bit hashes have limited security properties.
Two names are the same ONLY if algorithm, length, AND value all match. A 32-bit truncated sha-256 name is NOT the same as a full 256-bit sha-256 name even if one is a prefix of the other; treating them as equivalent opens collision and confusion attacks.
The binary name format has a 1-byte header with a 2-bit reserved field (Res, MUST be zero) and a 6-bit Suite ID, followed by the (possibly truncated) hash value. The Suite ID encodes both the hash algorithm and truncation length as registered in the IANA Named Information Hash Algorithm Registry.