RFC 6920
Naming Things with Hashes
🎀 RFC 6920: Naming Things with Hashes 🦋
Bestie, this one's so good. It's a Standards Track doc from the IETF, dated April 2013, with ISSN 2070-1721 📚
- Authors: S. Farrell (Trinity College Dublin), D. Kutscher (NEC), C. Dannewitz (University of Paderborn), B. Ohlman and A. Keranen (both Ericsson), and P. Hallam-Baker (Comodo Group Inc.) 👑
- Category: Standards Track
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈
Internet Engineering Task Force (IETF) S. Farrell
Request for Comments: 6920 Trinity College Dublin
Category: Standards Track D. Kutscher
ISSN: 2070-1721 NEC
C. Dannewitz
University of Paderborn
B. Ohlman
A. Keranen
Ericsson
P. Hallam-Baker
Comodo Group Inc.
April 2013Abstract 🌸
Okay so the big idea here is naming a thing (a digital object, in this case) by using the output of a hash function 🔥 It defines a brand-new URI scheme for that, a way to map those names onto HTTP URLs, and binary and human-speakable formats for the names too. The formats are built to support a strong link to the referenced object, so the object can be authenticated to the same degree as the reference to it, but they don't require that link 💅 The whole point is to standardise what people are already doing with hash outputs in URLs, and to support information-centric apps and other protocol uses of hash outputs ✨
Status of This Memo 📝
This is an Internet Standards Track document. 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. ⭐
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6920. 🧚
Copyright Notice 💜
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Hashes Are What Count . . . . . . . . . . . . . . . . . . . . 4
3. Named Information (ni) URI Format . . . . . . . . . . . . . . 6
3.1. Content Type Query String Attribute . . . . . . . . . . . 8
4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9
5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10
6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Human-Speakable (nih) URI Format . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13
8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15
9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15
9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16
9.4. Creation of Named Information Hash Algorithm Registry . . 16
9.5. Creation of Named Information Parameter Registry . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . . 211. Introduction ✨
Okay, identifiers (names or locators) are used all over protocols to point at resources, and in a lot of situations those identifiers hold values pulled from hash functions 🦋 The problem is that different deployments have each picked their own way of putting hash outputs into identifiers, and that's causing interoperability problems 💀
This document defines the "Named Information" identifier, which gives us a set of standard ways to use hash function outputs in names 🎀 We'll start with a few example uses of the different ways to put hash output into a name, and the specifics come later on. Figure 1 shows an example of the Named Information (ni) URI scheme that this document defines 🍓
ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q
Figure 1: Example ni URIHash function outputs can be used to make sure URIs [RFC3986] map uniquely to a specific resource, or to make URIs hard to guess for security reasons 🔐 There's no standard way to interpret those strings today, so in general only the creator of the URI knows how to use the hash function output 🙈 Other protocols also need more compact (e.g., binary) forms of these identifiers. Think application-layer protocols for accessing "smart objects" in constrained environments 🧚 And in other situations, people may have to speak these values out loud, e.g., on a voice call (see Section 8.3), just to confirm whether a resource is present or absent 📞
Another example: protocols for accessing in-network storage servers need a way to identify stored resources uniquely and in a location-independent way, so replicas on different servers can be reached by the same name 🌈 These apps may also need to verify that a resource representation you obtained actually corresponds to the name you used to request it. That means checking the binding between the data and the name, which this document calls "name-data integrity" 💅
Similarly, in information-centric networking [NETINF-ARCHITECTURE] [CCN] and elsewhere, being able to compare a presented resource against the URI used to access it is super valuable 👑 If a cryptographically strong comparison function can be used, that allows many forms of in-network storage without needing as much trust in the infrastructure that presents the resource 🔥 Hash outputs can be used this way, as long as they're presented in a standard way ✨
More applications might include creating references from web pages delivered over HTTP/TLS, DNS resource records signed using DNSSEC, or data values embedded in certificates, Certificate Revocation Lists (CRLs), or other signed data objects 🫶
The Named Identifier can be represented in a bunch of ways: using the ni URI scheme that we specifically define for the name (which is very similar to the "magnet link" informally defined in other protocols [Magnet]), or using other mechanisms also defined herein 🦋 However it's represented, the Named Identifier names a resource, and the mechanism used to dereference the name and to locate the named resource needs to be known by whatever entity does the dereferencing 🧠
Media content-type, alternative locations for retrieval, and other extra info about a resource named with this scheme can be provided in a query string 🎀 "The Named Information (ni) URI Scheme: Optional Features" [DECPARAMS] describes the specific values you can use in those query strings for these purposes, plus other extensions to this basic format spec 📚
We also define a ".well-known" URL equivalent, a way to include a hash as a segment of an HTTP URL, a binary format for protocols that need more compact names, and a human-speakable text form. That last one could be used for reading out (parts of) the name over a voice connection 🌸
Not every use of these names needs the full hash output, because truncated hashes can be safely used in some environments ✂️ So we define a new IANA registry for hash functions to be used with this specification. That way we don't mix strong and weak (truncated) hash algorithms into other protocol registries 🔐
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🍓
Syntax definitions in this memo are specified according to ABNF [RFC5234]. 💖
2. Hashes Are What Count ✨
okay so this section is all about the basic hash stuff that's the same no matter which format you're using 🔍
When you compare two names of this form, an implementation MUST only look at the digest algorithm and the digest value. It MUST NOT consider the other fields defined below, like an authority field from a URI or any parameters 🙅♀️. Implementations MUST consider two hashes identical, regardless of encoding, if the decoded hashes use the same algorithm and have the same length and the same binary value. When that's true, the two names can be treated as referring to the same thing 💖
The sha-256 algorithm from [SHA-256] is mandatory to implement, which means implementations MUST be able to generate/send and to accept/process names based on a sha-256 hash. The core rule, bestie 👑 However, implementations MAY support additional hash algorithms and MAY use those for specific names. For example, that could be in a constrained environment where sha-256 isn't a great fit, or where truncated names are needed to fit into certain protocols (when a higher collision probability is okay).
Truncated hashes MAY be supported 🎀 When a hash value is truncated, the name MUST indicate this. That's why we use different algorithm strings in these cases, like sha-256-32 for a 32-bit truncation of a sha-256 output. ngl, a 32-bit truncated hash is basically useless for security in almost every case, but it can still be useful for naming 🧚 With current best practices [RFC3766], very few (if any) applications using names with less than 100-bit hashes will have useful security properties 💀
When a hash value is truncated to N bits, the leftmost N bits (the most significant N bits in network byte order) from the binary representation of the hash value MUST be used as the truncated value. Here's an example of a 128-bit hash output truncated to 32 bits, see Figure 2 🦋
128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2
32-bit truncated hash: 0x26535790
Figure 2: Example of Truncated HashWhen the input to the hash algorithm is a public key value (as various security protocols may use), the hash SHOULD be calculated over the public key in an X.509 SubjectPublicKeyInfo structure (Section 4.1 of [RFC5280]). This input was picked mainly for compatibility with the DANE TSLA protocol [RFC6698], but it also includes any relevant public key parameters in the hash input, which is sometimes necessary for security reasons 🔐 This doesn't force you to use X.509 or fully comply with [RFC5280], since formatting any public key as a SubjectPublicKeyInfo is pretty straightforward and well supported by libraries 🙌
Any of the formats defined below can be used to represent the resulting name for a public key ✨
Outside of that special public key case, we don't specify the hash function input here. Other specifications are expected to define it 📝
3. Named Information (ni) URI Format 🌸
A Named Information (ni) URI is made up of the following nine components 💅
- Scheme Name: The scheme name is
ni. - Colon and Slashes: The literal
:// - Authority: The optional authority component can help applications access the object named by an ni URI. There is no default value for the authority field (see Section 3.2.2 of [RFC3986] for details). ni names with and without an authority are syntactically different from ni names with different authorities, but all three refer to the same object if and only if the digest algorithm, length, and value are the same 🫶
- One slash: The literal
/ - Digest Algorithm: The name of the digest algorithm, as specified in the IANA registry defined in Section 9.4 below.
- Separator: The literal
; - Digest Value: The digest value MUST be encoded using the base64url [RFC4648] encoding, with no
=padding characters. - Query Parameter separator
?: This acts as a separator between the digest value and the query parameters (if any are specified). For compatibility with Internationalized Resource Identifiers (IRIs), non-ASCII characters in the query part MUST be encoded as UTF-8, and the resulting octets MUST be percent-encoded (see [RFC3986], Section 2.1) 🍓 - Query Parameters: A
tag=valuelist of optional query parameters, like the ones used with HTTP URLs [RFC2616], with a&separator between each one. For example,foo=bar&baz=bat.
It is OPTIONAL for implementations to check the integrity of the URI/resource mapping when sending, receiving, or processing ni URIs 🔍
Escaping of characters follows the rules in RFC 3986. That means percent-encoding is used to tell apart reserved and unreserved functions of the same character in the same URI component 🎀
For example, an ampersand ('&') separates attribute-value pairs in the query part, so an ampersand in a value has to be escaped as '%26'. Note that the set of reserved characters is different for each component. A slash ('/') has no reserved function in a query part, so it doesn't have to be escaped. It can still show up escaped as '%2f' or '%2F', though, and implementations have to be able to understand those escaped forms 🙈 Also, any characters outside the ones allowed in the respective URI component have to be escaped.
The Named Information URI adapts the URI definition from the URI Generic Syntax [RFC3986]. We start with the base URI production 👑
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
; from RFC 3986
Figure 3: URI SyntaxThen we adapt that for the Named Information URI 🧚
NI-URI = ni-scheme ":" ni-hier-part [ "?" query ]
; adapted from "URI" in RFC 3986
; query is from RFC 3986, Section 3.4
ni-scheme = "ni"
ni-hier-part = "//" [ authority ] "/" alg-val
; authority is from RFC 3986, Section 3.2
alg-val = alg ";" val
; adapted from "hier-part" in RFC 3986
alg = 1*unreserved
val = 1*unreserved
; unreserved is from RFC 3986, Section 2.3
Figure 4: ni Name SyntaxThe "val" field MUST contain the output of base64url encoding (with no "=" padding characters). That's the result of applying the hash function ("alg") to its defined input, which defaults to the object bytes that are expected to be returned when the URI is dereferenced 💖
Relative ni URIs can happen 🦋 In those cases, the algorithm in Section 5 of [RFC3986] applies. As an example, in Figure 5, the absolute URI for "this third document" is "ni://example.com/sha-256-128;...".
<html>
<head>
<title>ni: relative URI test</title>
<base href="ni://example.com">
</head>
<body>
<p>Please check <a href="sha-256;f4OxZX...">this document</a>.
and <a href="sha-256;UyaQV...">this other document</a>.
and <a href="sha-256-128;...">this third document</a>.
</p>
</body>
</html>
Figure 5: Example HTML with Relative ni URIThe authority field in an ni URI isn't quite the same as the one in an HTTP URL, even though the same values (like DNS names) can be useful in both 🌈 For an ni URI, the authority doesn't control nearly as much of the structure of the "right-hand side" of the URI. ni URIs also define standard query string attributes and, of course, have a strictly defined way to include the hash value ✨
Internationalisation of strings within ni names is handled exactly like it is for http URIs. See [RFC2616], Section 3.2.3 🌍
3.1. Content Type Query String Attribute 💜
A digest can be used to set up a secure reference from an authenticated source to an external source, and that can depend on metadata like the Content Type 👀 The Content Type "ct" parameter specifies the MIME Content Type of the associated data, as defined in [RFC6838]. See Section 9.5 for the associated IANA registry for ni parameter names, as shown in Figure 6. Implementations of this specification MUST support parsing the "ct=" query string attribute name 🫶
ni:///sha-256-32;f4OxZQ?ct=text/plain
Figure 6: Example ni URI with Content TypeProtocols that use ni URIs will need to specify how to verify name-data integrity for the MIME Content Types they need to process. They'll also need to take into account possible Content-Transfer-Encodings and other aspects of MIME encoding 🧚
Implementations of this specification SHOULD support name-data integrity validation for at least the application/octet-stream Content Type, with no explicit Content-Transfer-Encoding (which is equivalent to binary). Additional Content Types and Content-Transfer-Encodings can also be supported, but they are OPTIONAL. Note that the hash is calculated after the Content-Transfer-Encoding is removed, so it's applied to the raw data 🍓
If a) the user agent is sensitive to the Content Type, b) the ni name used has a "ct=" query string attribute, and c) the object is retrieved (from a server) using a protocol that specifies a Content Type, then, if the two Content Types match, all is well ✨ If the Content Types don't match in this situation, the client SHOULD handle it as a potential security error 🚨 Content Type matching rules are defined in [RFC2045], Section 5.1.
4. .well-known URI ✨
okay so bestie, this section is about making a mapping between ni URIs and HTTP [RFC2616] or HTTPS [RFC2818] URLs. It uses the .well-known URI [RFC5785] thing, with an "ni" suffix (see Section 9). it's giving organised 💅
The HTTP(S) mapping MAY be used anywhere clients that support ni URIs aren't around 🌸
the .well-known namespace isn't meant for general info retrieval, so if an app asks for a .well-known/ni URL over HTTP(S), it will often get a 3xx HTTP redirection response 🙈 a server answering a request for a .well-known/ni URL will often send back a 3xx response too, so a client sending that kind of request MUST be able to handle it, as should any fully compliant HTTP [RFC2616] client. no cap, that's the main thing to remember here 💖
for an ni name of the form ni://n-authority/alg;val?query-string, the matching HTTP(S) URL from this mapping is http://h-authority/.well-known/ni/alg/val?query-string. the h-authority part is worked out like this:
- if the ni name has a specified authority (so the n-authority isn't empty), then the h-authority MUST have the same value 🎀
- if the ni name has no authority (so the n-authority string is empty), a h-authority value MAY be derived from the application context ✨ for example, if the mapping is happening inside a web page, the origin [RFC6454] for that website can be used 🧚
ngl there are no guarantees the object named by the ni URI will actually be available at the matching HTTP(S) URL. but if any data does come back, the retriever can check whether it's content that matches the ni URI 🔥
if an application gets an HTTP(S) URL where the pathname starts with /.well-known/ni/, then mapping it back to an ni URI (with or without the authority) might give you an ni URI that's meaningful. however, there's no guarantee that'll happen 🦋
when you're mapping from an ni URI to a .well-known URL, the implementation will have to pick between an "http" URL and an "https" URL 👑 if the object really does match the hash in the URL, then there's arguably no need for extra data integrity, if the ni URI or .well-known URL was received "securely." but TLS also gives you confidentiality, so there can still be reasons to use the "https" URL scheme even then 🫶 also, web server policy like [RFC6797] may decide that data should only be available over "https". overall though, whether to use "http" or "https" is something the application needs to decide 💅
5. URL Segment Format 🌈
some applications might benefit from putting hashes into existing HTTP URLs or other URLs. to do that, you just use the alg-val production from the ni name scheme ABNF. it can go in the pathname, the query string, or even the fragment components of HTTP URLs [RFC2616] 🍓 but here's the catch: nothing in the URL makes sure a client can count on this specification being followed. so clients MUST NOT assume that any URL with a pathname component that matches the alg-val production was actually produced by this specification 😭 that URL might or might not be related to this specification, and only the context will tell 🤷♀️
6. Binary Format 🦋
if you need a more space-efficient version of the name, you can use this binary format 🧚 the binary format name has two fields: a header and the hash value. the header field says how the identifier was created, and the hash value holds a (possibly truncated) result of a one-way hash over whatever is being identified by the hash value 💜 the binary format of a name is shown in Figure 7 below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| Suite ID | Hash Value /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... |
+-+-+-+-+-+-+-+-+ Figure 7: Binary Name Formatthe Res field is a reserved 2-bit field for future use. it MUST be set to zero for this specification and ignored on receipt 🙅♀️
the hash algorithm and truncation length are specified by the Suite ID. to keep the binary encoding efficient, only a few hash algorithms and truncation lengths are supported. see Section 9.4 for details 🧮
a hash value truncated to 120 bits gives you an overall name that's a 128-bit value, which is super handy for protocols that can easily use 128-bit identifiers 🎀
7. Human-Speakable (nih) URI Format 🗣️
sometimes a resource needs to be referred to by a name that's easy for humans to read out loud and less likely to be misheard 👂 this is meant to be usable over the phone, for example, to confirm the (current or future) presence or absence of a resource 📞 the "confirmation" use-case described further in Section 8.3 is the main current use-case for Named Information for Humans (nih) URIs. ("nih" also means "Not Invented Here", which is clearly false, and therefore worth including [RFC5513]. :-) 😂
the ni URI format isn't great for this, because base64url uses both uppercase and lowercase, and that can easily cause confusion 🙈 for speaking the value of a hash output, the more verbose but less ambiguous (when spoken) nih URI scheme is defined 💅
the reason nih is a URI scheme is that it can help the speaker's user agent display the value better, or help a machine speak or recognise the value better when it's spoken 🤖 we don't include the query string, since there's no way to make sure its value could be spoken unambiguously. same goes for the authority, where some internationalised forms of domain name might not be easy to say or understand 🌍 that leaves the hash value as the only part of the ni URI we feel can be usefully included. but since speakers or listeners (or speech recognition) can mess up, we also include a checkdigit to catch common errors, and we allow "-" separators to make nih URIs easier to read out loud 🧠
fields in nih URIs are separated by a semicolon (;) character. the first field is a hash algorithm string, same as in the ni URI format. the hash value is written with lowercase ASCII hex characters. for example, an octet with the decimal value 58 (0x3A) is encoded as '3a'. this is the same as base16 encoding as defined in RFC 4648 [RFC4648], except it uses lowercase letters 🌸 separators ("-" characters) MAY be put anywhere in the hash value to make it easier to read, typically grouping four or six characters with a separator between them 🍓
the hash value MAY be followed by a semicolon ';' and then a checkdigit. the checkdigit MUST be calculated using Luhn's mod N algorithm (with N=16) as defined in [ISOIEC7812] (see also [Luhn]) 🧮 the input to the calculation is the ASCII hex-encoded hash value (that's the "sepval" in the ABNF production below), but with all "-" separator characters stripped out first. this maps the ASCII hex so that '0'=0, ...'9'=9, 'a'=10, ...'f'=15 🔢 none of the other fields, nor any "-" separators, are input when calculating the checkdigit ✨
humanname = "nih:" alg-sepval [ ";" checkdigit ]
alg-sepval = alg ";" sepval
sepval = 1*(ahlc / "-")
ahlc = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; DIGIT is defined in RFC 5234 and is 0-9
checkdigit = ahlc Figure 8: Human-Speakable Syntaxfor algorithms that have a Suite ID reserved (see Figure 11), the alg field MAY contain the ID value as an ASCII-encoded decimal number instead of the hash name string. for example, "3" instead of "sha-256-120" 🔥 implementations MUST be able to match the decimal ID values for the algorithms and hash lengths they support, even if they don't support the binary format 💪
there is no such thing as a relative nih URI 🙅♀️
8. Examples 🍰
8.1. Hello World! 👋
the following ni URI is generated from the text "Hello World!" (12 characters without the quotes), using the sha-256 algorithm. it's shown with and without an authority field 💖
ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGkni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGkthe following HTTP URL is the mapping from the previous ni name, using the algorithm outlined above ✨
http://example.com/.well-known/ni/sha-256/
f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk8.2. Public Key Examples 🔑✨
Okay bestie, so we start with this DER-encoded SubjectPublicKeyInfo from Figure 9 🎀. From it we get all the names in Figure 10, and yes, they're all for this one key 🦋
0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01
0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01
0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94
0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3
0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b
0000120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b
0000140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6
0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76
0000200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b
0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b
0000240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83
0000260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf
0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7
0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b
0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90
0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12
0000400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d
0000420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 05 01 ee
0000440 dd 02 03 01 00 01
0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7
0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4Figure 9: A SubjectPublicKeyInfo Used in Examples and Its sha-256 Hash
Now for the names 🌸 Figure 10 has every form we've met so far, all derived from that same key 💅
+-------------------------------------------------------------------+
| URI: |
| ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| .well-known URL (split over 2 lines): |
| http://example.com/.well-known/ni/sha256/ |
| UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| URL Segment: |
| sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q |
+-------------------------------------------------------------------+
| Binary name (ASCII hex encoded) with 120-bit truncated hash value |
| which is Suite ID 0x03: |
| 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 120 bits|
| in length) with checkdigit: |
| nih:sha-256-120;5326-9057-e12f-e2b7-4ba0-7c89-2560-a2;f |
+-------------------------------------------------------------------+
| Human-speakable form of a name for this key (truncated to 32 bits |
| in length) with checkdigit and no "-" separators: |
| nih:sha-256-32;53269057;b |
+-------------------------------------------------------------------+
| Human-speakable form using decimal presentation of the |
| algorithm ID (sha-256-120) with checkdigit: |
| nih:3;532690-57e12f-e2b74b-a07c89-2560a2;f |
+-------------------------------------------------------------------+Figure 10: Example Names
8.3. nih Usage Example 🧚
Okay, storytime 📞 Alice has set up a server node with an RSA key pair. She uses an ni URI as the name for the public key that matches the private key on that box. Alice's node might identify itself with that ni URI in some protocol, and honestly that's so iconic 👑
Now Bob wants to be sure it's really Alice's node when his node talks to the network and asks his friend Alice what public key she uses. Alice hits the "tell someone the name of the public key" button on her admin user interface, which shows the nih URI and says "tell this to your buddy" 🫶 She calls Bob and reads the nih URI out loud to him.
Bob types that into his "manage known nodes" admin application (or lets that app listen in on part of the call). The app can regenerate the ni URI and store it, or something equivalent. Then whenever Bob's node talks to Alice's node, it can more safely accept a signature or encrypt data to Alice's node 🔐✨
9. IANA Considerations 🌈
9.1. Assignment of ni URI Scheme 💜
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
- URI scheme name: ni
- Status: Permanent
- URI scheme syntax: See Section 3.
- URI scheme semantics: See Section 3.
- Encoding considerations: See Section 3.
- Applications/protocols that use this URI scheme name:
- General applicability.
- Interoperability considerations: Defined here.
- Security considerations: See Section 10.
- Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
- Author/Change controller: IETF
- References: As specified in this document
9.2. Assignment of nih URI Scheme 🍓
The procedures for registration of a URI scheme are specified in RFC 4395 [RFC4395]. The following assignment has been made.
- URI scheme name: nih
- Status: Permanent
- URI scheme syntax: See Section 7.
- URI scheme semantics: See Section 7.
- Encoding considerations: See Section 7.
- Applications/protocols that use this URI scheme name:
- General applicability.
- Interoperability considerations: Defined here.
- Security considerations: See Section 10.
- Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie
- Author/Change controller: IETF
- References: As specified in this document
9.3. Assignment of .well-known 'ni' URI 🦋
The procedures for registration of a Well-Known URI entry are specified in RFC 5785 [RFC5785]. The following assignment has been made.
- URI suffix: ni
- Change controller: IETF
- Specification document(s): This document
- Related information: None
9.4. Creation of Named Information Hash Algorithm Registry 🔥
IANA has created a new registry for hash algorithms as used in the name formats specified here 🎀 It's called the "Named Information Hash Algorithm Registry", and future assignments go through Expert Review [RFC5226]. The registry has five fields: the suite ID, the hash algorithm name string, the truncation length, the underlying algorithm reference, and a status field that shows whether the algorithm is current or deprecated and should no longer be used. The status field can have the value "current" or "deprecated". Other values are reserved for possible future definition.
If the status is "current", that does not automatically mean the algorithm is "good" for any particular purpose 🙈 The cryptographic strength requirements get set by other applications or protocols.
Marking an entry as "deprecated" is a big deal, so it's not a quick vibe check. A request to do it can be made by sending a mail to the Designated Expert. Before approving that request, the community MUST be consulted via a "call for comments" of at least two weeks, sent by mail to the IETF discussion list.
Initial values are listed below. The Designated Expert SHOULD generally approve additions that reference hash algorithms widely used in other IETF protocols 💖 The Designated Expert SHOULD NOT accept additions where the underlying hash function (with no truncation) is considered weak for collisions. Part of the reasoning behind that last point is that including code for weak hash functions, e.g., the MD5 algorithm, can trigger costly false positives when code is audited for obsolete ciphers 😭 See [RFC6149], [RFC6150], and [RFC6151] for examples of hash functions considered obsolete in this sense.
The suite ID field ("ID") can be empty or can have values between 0 and 63, inclusive. Because there are only 64 possible values, this field is OPTIONAL (it's left empty if omitted) ✨ Where the binary format is not expected to be used for a given hash algorithm, this field SHOULD be omitted. If an entry is registered without a suite ID, the Designated Expert MAY allow for later allocation of a suite ID, if that appears warranted. The Designated Expert MAY consult the community via a "call for comments" sent by mail to the IETF discussion list before allocating a suite ID.
ID Hash Name String Value Length Reference Status
0 Reserved
1 sha-256 256 bits [SHA-256] current
2 sha-256-128 128 bits [SHA-256] current
3 sha-256-120 120 bits [SHA-256] current
4 sha-256-96 96 bits [SHA-256] current
5 sha-256-64 64 bits [SHA-256] current
6 sha-256-32 32 bits [SHA-256] current
32 ReservedFigure 11: Suite Identifiers
The Suite ID value 32 is reserved for compatibility with IPv6 addresses from the Special Purpose Address Registry [RFC4773], such as Overlay Routable Cryptographic Hash Identifiers (ORCHIDs) [RFC4843] 🧚
The referenced hash algorithm that matches the Suite ID, truncated to the indicated length and following the description given in Section 2, is used for generating the hash. The Designated Expert is responsible for ensuring that the document referenced for the hash algorithm meets the "specification required" rule. 👑
9.5. Creation of Named Information Parameter Registry 💅
IANA has created a new registry called "Named Information URI Parameter Definitions" 🌸
The policy for future assignments to this registry is Expert Review. Just like the ni Hash Algorithm Registry above, the Designated Expert is responsible for ensuring that the document referenced for the parameter definition meets the "specification required" rule.
The fields in this registry are the parameter name, a description, and a reference. The parameter name MUST be suitable for use as a query string parameter name in an ni URI. (See Section 3.) 🫶
The initial contents of the registry are:
Parameter Meaning Reference
----------- -------------------------------------------- ---------
ct Content Type [RFC6920]10. Security Considerations 🔐✨
okay bestie, security time, and this part is SERIOUS 😭🫶 read it slowly
No secret info is needed to generate or verify a name like this 🙈 So a name like this can only give you evidence for the integrity of the referenced object, and the proof is only as good as the proof for the name you started with. The hash value gives you a name-data integrity binding between the name and the bytes you get back when you dereference it using some protocol. Main character energy for the hash 💅
Knowing a name doesn't automatically mean knowing the object it points to, BUT an attacker might still figure out the contents by searching engines or other data repositories 👀 Or, for a highly formatted object with little variation, they can just guess a value and check if the digest matches. So the fact that these names contain hashes does NOT protect the confidentiality of whatever was fed into the hash 💀
If a weak hash function is used, the integrity of the referenced content gets compromised 😤 SHA-256 is currently our preferred hash algorithm, and that's why we've only added SHA-256-based suites to the initial IANA registry 💖
Now the truncation tea 🍵 If you use a truncated hash value, certain security properties get affected. A hash is designed to produce enough bits to prevent a 'birthday attack' collision. To make finding two pieces of content with the same digest by brute force take a work factor of O(2^x), you need a digest length of 2x. Lots of security apps only need protection against a second pre-image attack, and that only needs a digest length of x to reach the same work factor. Basically? The shorter the hash, the less security benefit you can possibly get 📉
Here's the important bit ✨ Don't make the mistake of thinking two names are the same when they aren't! For example, a name with a 32-bit truncated sha-256 hash is NOT the same as a name with the full 256 bits of hash output, even if one hash value is a prefix of the other 🙅♀️
Why does this matter? If an application treats them as the same name, a bunch of attacks can open up 😭 Say I publish an object with the full hash. I probably don't want some other app treating a name with just the first 32 bits as referring to the same thing, because that 32-bit name will have LOTS of colliding objects. If ni or nih URIs get widely used, names will show up more than once in application protocols, and it'll be unpredictable which instance gets used for name-data integrity checking, which leads to threats 🚨 That's why we require that the algorithm, length, and value ALL match before we consider two names to be the same 🫶
The domain name in the authority field of an ni URI tells you NOTHING by itself about the relationship between the domain owner and any content referenced by that URI 🙃 A name-data integrity service can be provided using ni URIs, but that doesn't validate the authority part in any sense. Nothing stops anyone from making an ni URI that contains a hash of someone else's content 👀 Application developers MUST NOT assume any relationship between the registrant of the domain name that is part of an ni URI and some matching content just because the ni URI matches that content.
If name-data integrity is successfully validated, and the hash is strong and long enough, then the "web origin" [RFC6454] for the bytes of the named object is really going to be the place you got the ni name from, NOT the place you got the bytes from 🤯 That seems like a potential benefit if you're using ni names for scripts included from an HTML page accessed via server-authenticated https, for example ✨ If name-data integrity is not validated (and it is optional) or it fails, then the web origin is, as usual, the place the object bytes were received from. Applications making use of ni names SHOULD take this into account in their trust models. 🧚
Last one, and it's a big one 🌈 Some implementations might mishandle ni URIs that include non-base64 characters, whitespace, or other non-conforming strings. That could lead to erroneously considering names to be the same when they aren't 😱 An ni URI that is malformed in such ways MUST NOT be treated as matching any other ni URI. Implementers need to check the behaviour of their libraries for these parsing problems, bestie 🫶💅
11. Acknowledgments 🎀
This work was supported by the EU FP7 project SAIL 💜 The authors would like to thank the SAIL participants for their naming discussions, especially Jean-Francois Peltier, for their input 🌸
The authors would also like to thank Carsten Bormann, Martin Duerst, Tobias Heer, Bjoern Hoehrmann, Tero Kivinen, Barry Leiba, Larry Masinter, David McGrew, Alexey Melnikov, Bob Moskowitz, Jonathan Rees, Eric Rescorla, Zach Shelby, and Martin Thomas for their comments and input to the document 🙌 Special thanks to James Manger for correcting the examples ✨
12. References 📚
12.1. Normative References
[ISOIEC7812] ISO, "Identification cards -- Identification of issuers -- Part 1: Numbering system", ISO/IEC 7812-1:2006, October 2006, <http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39698>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[SHA-256] NIST, "Secure Hash Standard", FIPS 180-3, October 2008, <http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf>.
12.2. Informative References
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), December 2009.
[DECPARAMS] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, D., and B. Ohlman, "The Named Information (ni) URI Scheme: Optional Features", Work in Progress, June 2012.
[Luhn] Wikipedia, "Luhn mod N algorithm", September 2011, <http://en.wikipedia.org/w/index.php?title=Luhn_mod_N_algorithm&oldid=449928878>.
[Magnet] Wikipedia, "Magnet URI scheme", March 2013, <http://en.wikipedia.org/w/index.php?title=Magnet_URI_scheme&oldid=546892719>.
[NETINF-ARCHITECTURE] Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B., and M. Karl, "Network of Information (NetInf) - An information-centric networking architecture", Computer Communications, Volume 36, Issue 7, pages 721-735, ISSN 0140-3664, 1 April 2013, <http://www.sciencedirect.com/science/article/pii/S0140366413000364>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC4773] Huston, G., "Administration of the IANA Special Purpose IPv6 Address Block", RFC 4773, December 2006.
[RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", RFC 4843, April 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter Acronyms", RFC 5513, April 1 2009.
[RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status", RFC 6149, March 2011.
[RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", RFC 6150, March 2011.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012.
Authors' Addresses 💌
Here are the amazing humans who wrote this, with their contact details 🦋
Stephen Farrell
Trinity College Dublin
Dublin, 2
Ireland
Phone: +353-1-896-2354
EMail: stephen.farrell@cs.tcd.ie
Dirk Kutscher
NEC
Kurfuersten-Anlage 36
Heidelberg
Germany
EMail: kutscher@neclab.eu
Christian Dannewitz
University of Paderborn
Paderborn
Germany
EMail: cdannewitz@googlemail.com
Borje Ohlman
Ericsson
Stockholm S-16480
Sweden
EMail: Borje.Ohlman@ericsson.com
Ari Keranen
Ericsson
Jorvas 02420
Finland
EMail: ari.keranen@ericsson.com
Phillip Hallam-Baker
Comodo Group Inc.
EMail: philliph@comodo.comAnd that's a wrap on the whole spec, bestie!! 🌈👑💅
📦 where this page comes from
- ietf: rfc6920 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms