idnits 2.17.1 draft-farrell-decade-ni-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 3, 2012) is 4283 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-THIS' is mentioned on line 799, but not defined == Unused Reference: 'ISOIEC7812' is defined on line 913, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-20 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISOIEC7812' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA-256' == Outdated reference: A later version (-14) exists of draft-ietf-websec-strict-transport-sec-11 -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Standards Track D. Kutscher 5 Expires: February 4, 2013 NEC 6 C. Dannewitz 7 University of Paderborn 8 B. Ohlman 9 A. Keranen 10 Ericsson 11 P. Hallam-Baker 12 Comodo Group Inc. 13 August 3, 2012 15 Naming Things with Hashes 16 draft-farrell-decade-ni-10 18 Abstract 20 This document defines a set of ways to identify a thing (a digital 21 object in this case) using the output from a hash function, 22 specifying a new URI scheme for this, a way to map those to http 23 URLs, and binary and human "speakable" formats for these names. The 24 various formats are designed to support, but not require, a strong 25 link to the referenced object such that the referenced object may be 26 authenticated to the same degree as the reference to it. This work 27 is motivated as a way to standardise current uses of hash outputs in 28 URLs and to support new information-centric applications and other 29 uses of hash outputs in protocols. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on February 4, 2013. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Hashes are what Count . . . . . . . . . . . . . . . . . . . . 4 63 3. Named Information (ni) URI Format . . . . . . . . . . . . . . 6 64 3.1. Content Type Query String Attribute . . . . . . . . . . . 8 65 4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Human-speakable (nih) URI Format . . . . . . . . . . . . . . . 11 69 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13 71 8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13 72 8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15 75 9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15 76 9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16 77 9.4. Creation of Named Information Hash Algorithm Registry . . 16 78 9.5. Creation of Named Information Parameter Registry . . . . . 17 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 Identifiers -- names or locators -- are used in various protocols to 89 identify resources. In many scenarios, those identifiers contain 90 values that are obtained from hash functions. Different deployments 91 have chosen different ways to include the hash function outputs in 92 their identifiers, resulting in interoperability problems. 94 This document defines a "Named Information" identifier, which 95 provides a set of standard ways to use hash function outputs in 96 names. We begin with a few example uses for various ways to include 97 hash function output in a name, with the specifics defined later in 98 this document. Figure 1 shows an example of the Named Information 99 (ni) URI scheme that this document defines. 101 ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q 103 Figure 1: Example ni URI 105 Hash function outputs can be used to ensure uniqueness in terms of 106 mapping URIs [RFC3986] to a specific resource, or to make URIs hard 107 to guess for security reasons. Since there is no standard way to 108 interpret those strings today, in general only the creator of the URI 109 knows how to use the hash function output. Other protocols, such as 110 application layer protocols for accessing "smart objects" in 111 constrained environments also require more compact (e.g., binary) 112 forms of such identifiers. In yet other situations people may have 113 to speak such values, e.g., in a voice call, (see Section 8.3), in 114 order to confirm the presence or absence of a resource. 116 As another example, protocols for accessing in-network storage 117 servers need a way to identify stored resources uniquely and in a 118 location-independent way so that replicas on different servers can be 119 accessed by the same name. Also, such applications may require 120 verification that a resource representation that has been obtained 121 actually corresponds to the name that was used to request the 122 resource, i.e., verifying the binding between the data and the name, 123 which is here termed name-data integrity. 125 Similarly, in the context of information-centric networking 126 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 127 able to compare a presented resource against the URI that was used to 128 access that resource. If a cryptographically-strong comparison 129 function can be used then this allows for many forms of in-network 130 storage, without requiring as much trust in the infrastructure used 131 to present the resource. The outputs of hash functions can be used 132 in this manner, if thry are presented in a standard way. 134 Additional applications might include creating references from web 135 pages delivered over HTTP/TLS; DNS resource records signed using 136 DNSSEC or data values embedded in certificates, Certificate 137 Revocation Lists (CRLs), or other signed data objects. 139 The Named Identifier can be represented in a number of ways: using 140 the "ni" URI scheme that we specifically define for the name (which 141 is very similar to the "magnet link" that is informally defined in 142 other protocols [magnet]), or using other mechanisms also defined 143 herein. However it is represented, the Named Identifier *names* a 144 resource, and the mechanism used to dereference the name and to 145 *locate* the named resource needs to be known by the entity that 146 dereferences it. 148 Media content-type, alternative locations for retrieval and other 149 additional information about a resource named using this scheme can 150 be provided using a query string. A companion specification 151 [I-D.hallambaker-decade-ni-params] describes specific values that can 152 be used in such query strings for these various purposes and other 153 extensions to this basic format specification. 155 In addition, we also define a ".well-known" URL equivalent, and a way 156 to include a hash as a segment of an HTTP URL, as well as a binary 157 format for use in protocols that require more compact names and a 158 human-speakable text form that could be used, e.g., for reading out 159 (parts of) the name over a voice connection. 161 Not all uses of these names require use of the full hash output - 162 truncated hashes can be safely used in some environments. For this 163 reason, we define a new IANA registry for hash functions to be used 164 with this specification so as not to mix strong and weak (truncated) 165 hash algorithms in other protocol registries. 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 Syntax definitions in this memo are specified according to ABNF 172 [RFC5234]. 174 2. Hashes are what Count 176 This section contains basic considerations related to how we use hash 177 function outputs that are common to all formats. 179 When comparing two names of the form defined here, an implementation 180 MUST only consider the digest algorithm and the digest value, i.e., 181 it MUST NOT consider other fields defined below (such as an authority 182 field from a URI or any parameters). Implementations MUST consider 183 two hashes identical, regardless of encoding, if the decoded hashes 184 are based on the same algorithm and have the same length and the same 185 binary value. In that case, the two names can be treated as 186 referring to the same thing. 188 The sha-256 algorithm as specified in [SHA-256] is mandatory to 189 implement, that is, implementations MUST be able to generate/send and 190 to accept/process names based on a sha-256 hash. However 191 implementations MAY support additional hash algorithms and MAY use 192 those for specific names, for example in a constrained environment 193 where sha-256 is non-optimal or where truncated names are needed to 194 fit into corresponding protocols (when a higher collision probability 195 can be tolerated). 197 Truncated hashes MAY be supported. When a hash value is truncated 198 the name MUST indicate this. Therefore we use different hash 199 algorithm strings for these, such as sha-256-32 for a 32-bit 200 truncation of a sha-256 output. A 32-bit truncated hash is 201 essentially useless for security in almost all cases, but might be 202 useful for naming. With current best practices [RFC3766] very few, 203 if any, applications making use of names with less than 100 bit long 204 hashes will have useful security properties. 206 When a hash value is truncated to N bits the left-most N bits, that 207 is, the most significant N bits in network byte order, from the 208 binary representation of the hash value MUST be used as the truncated 209 value. An example of a 128-bit hash output truncated to 32 bits is 210 shown in Figure 2. 212 128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 213 32-bit truncated hash: 0x26535790 215 Figure 2: Example of Truncated Hash 217 When the input to the hash algorithm is a public key value, as may be 218 used by various security protocols, the hash SHOULD be calculated 219 over the public key in an X.509 SubjectPublicKeyInfo structure 220 (Section 4.1 of [RFC5280]). This input has been chosen primarily for 221 compatibility with DANE [I-D.ietf-dane-protocol], but also includes 222 any relevant public key parameters in the hash input, which is 223 sometimes necessary for security reasons. This does not force use of 224 X.509 or full compliance with [RFC5280] since formatting any public 225 key as a SubjectPublicKeyInfo is relatively straightforward and well 226 supported by libraries. 228 Any of the formats defined below can be used to represent the 229 resulting name for a public key. 231 Other than in the above special case where public keys are used, we 232 do not specify the hash function input here. Other specifications 233 are expected to define this. 235 3. Named Information (ni) URI Format 237 A Named Information (ni) URI consists of the following nine 238 components: 240 Scheme Name The scheme name is 'ni'. 242 Colon and Slashes The literal "://" 244 Authority The optional authority component may assist applications 245 in accessing the object named by an ni URI. There is no default 246 value for the authority field. (See [RFC3986] Section 3.2.2 for 247 details.) While ni names with and without an authority differ 248 syntactically from ni names with different authorities, all three 249 refer to the same object if and only if the digest algorithm, 250 length, and value are the same. 252 One slash The literal "/" 254 Digest Algorithm The name of the digest algorithm, as specified in 255 the IANA registry defined in Section 9.4 below. 257 Separator The literal ";" 259 Digest Value The digest value MUST be encoded using the base64url 260 [RFC4648] encoding, with no "=" padding characters. 262 Query Parameter separator '?' The query parameter separator acts as 263 a separator between the digest value and the query parameters (if 264 specified). For compatibility with IRIs, non-ASCII characters in 265 the query part MUST be encoded as UTF-8, and the resulting octets 266 MUST be %-encoded (see [RFC3986] Section 2.1). 268 Query Parameters A tag=value list of optional query parameters as 269 are used with HTTP URLs [RFC2616] with a separator character '&' 270 between each. For example, "foo=bar&baz=bat" 272 It is OPTIONAL for implementations to check the integrity of the URI/ 273 resource mapping when sending, receiving or processing "ni" URIs. 275 Escaping of characters follows the rules in RFC 3986. This means 276 that %-encoding is used to distinguish between reserved and 277 unreserved functions of the same character in the same URI component. 278 As an example, an ampersand ('&') is used in the query part to 279 separate attribute-value pairs; an ampersand in a value therefore has 280 to be escaped as '%26'. Note that the set of reserved characters 281 differs for each component, as an example, a slash ('/') does not 282 have any reserved function in a query part and therefore does not 283 have to be escaped. However, it can still appear escaped as '%2f' or 284 '%2F', and implementations have to be able to understand such escaped 285 forms. Also note that any characters outside those allowed in the 286 respective URI component have to be escaped. 288 The Named Information URI adapts the URI definition from the URI 289 Generic Syntax [RFC3986]. We start with the base URI production: 291 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 292 ; from RFC 3986 294 Figure 3: URI syntax 296 Adapting that for the Named Information URI: 298 NI-URI = ni-scheme ":" ni-hier-part [ "?" query ] 299 ; adapted from "URI" in RFC 3986 300 ; query is from RFC 3986, Section 3.4 301 ni-scheme = "ni" 302 ni-hier-part = "//" [ authority ] "/" alg-val 303 ; authority is from RFC 3986, Section 3.2 304 alg-val = alg ";" val 305 ; adapted from "hier-part" in RFC 3986 306 alg = 1*unreserved 307 val = 1*unreserved 308 ; unreserved is from RFC 3986, Section 2.3 310 Figure 4: ni Name syntax 312 The "val" field MUST contain the output of base64url encoding (with 313 no "=" padding characters) the result of applying the hash function 314 ("alg") to its defined input, which defaults to the object bytes that 315 are expected to be returned when the URI is dereferenced. 317 Relative ni URIs can occur. In such cases, the algorithm in 318 [RFC3986] Section 5 applies. As an example, in Figure 5, the 319 absolute URI for "this third document" is 320 "ni://example.com/sha-256-128;...". 322 323 324 ni: relative URI test 325 326 328 329

Please check this document. 330 and this other document. 331 and this third document. 332

333 334 336 Figure 5: Example HTML with relative ni URI 338 The authority field in an ni URI is not quite the same as that from 339 an HTTP URL, even though the same values (e.g., DNS names) may be 340 usefully used in both. For an ni URI, the authority does not control 341 nearly as much of the structure of the "right hand side" of the URI. 342 With ni URIs we also define standard query string attributes and of 343 cousrse have a strictly defined way to include the hash value. 345 Internationalisation of strings within ni names is handled exactly as 346 for http URIs - see [I-D.ietf-httpbis-p1-messaging] Section 2.7. 348 3.1. Content Type Query String Attribute 350 The semantics of a digest being used to establish a secure reference 351 from an authenticated source to an external source may be a function 352 of associated meta data such as the content type. The Content Type 353 "ct" parameter specifies the MIME Content Type of the associated data 354 as defined in [I-D.ietf-appsawg-media-type-regs]. See Section 9.5 355 for the associated IANA registry for ni parameter names. as shown in 356 Figure 6. Implementations of this specification MUST support parsing 357 the ct= query string attribute name. 359 ni:///sha-256-32;f4OxZQ?ct=text/plain 361 Figure 6: Example ni URI with Content Type 363 Protocols making use of ni URIs will need to specify how to verify 364 name-data integrity for the MIME Content Types that they need to 365 process and will need to take into account possible Content-Transfer- 366 Encodings and other aspects of MIME encoding. 368 Implementations of this specification SHOULD support name-data 369 integrity validation for at least the application/octet-stream 370 Content Type with no explicit Content-Transfer-Encoding (which is 371 equivalent to binary). Additional Content Types and Content- 372 Transfer- Encodings can of course also be supported, but are 373 OPTIONAL. Note that the hash is calculated after the Content 374 Transfer Encoding is removed, so it is applied to the raw data. 376 If a) the user agent is sensitive to the Content Type and b) the ni 377 name used has a ct= query string attribute and c) the object is 378 retrieved (from a server) using a protocol that specifies a Content 379 Type, then, if the two Content Types match, all is well. If, in this 380 situation, the Content Types do not match, then the client SHOULD 381 handle that situation as a potential security error. Content Type 382 matching rules are defined in [RFC2045] Section 5.1. 384 4. .well-known URI 386 We define a mapping between URIs following the ni URI scheme and HTTP 387 [RFC2616] or HTTPS [RFC2818] URLs that makes use of the .well-known 388 URI [RFC5785] by defining an "ni" suffix (see Section 9). 390 The HTTP(S) mapping MAY be used in any context where clients with 391 support for ni URIs are not available. 393 Since the .well-known name-space is not intended for general 394 information retrieval, if an application de-references a .well- 395 known/ni URL via HTTP(S), then it will often receive a 3xx HTTP re- 396 direction response. A server responding to a request for a .well- 397 known/ni URL will often therefore return a 3xx response and a client 398 sending such a request MUST be able to handle that, as should any 399 fully compliant HTTP [RFC2616] client. 401 For an ni name of the form "ni://n-authority/alg;val?query-string" 402 the corresponding HTTP(S) URL produced by this mapping is 403 "http://h-authority/.well-known/ni/alg/val?query-string", where 404 "h-authority" is derived as follows: If the ni name has a specified 405 authority (i.e., the n-authority is non-empty) then the h-authority 406 MUST have the same value. If the ni name has no authority specified 407 (i.e., the n-authority string is empty), a h-authority value MAY be 408 derived from the application context. For example, if the mapping is 409 being done in the context of a web page then the origin [RFC6454] for 410 that web site can be used. Of course, there are in general no 411 guarantees that the object named by the ni URI will be available via 412 the corresponding HTTP(S) URL. But in the case that any data is 413 returned, the retriever can determine whether or not it is content 414 that matches the ni URI. 416 If an application is presented with a HTTP(S) URL with "/.well- 417 known/ni/" as the start of its pathname component, then the reverse 418 mapping to an ni URI either including or excluding the authority 419 might produce an ni URI that is meaningful, but there is no guarantee 420 that this will be the case. 422 When mapping from an ni URI to a .well-known URL, an implementation 423 will have to decide between choosing an "http" or "https" URL. If 424 the object referenced does in fact match the hash in the URL, then 425 there is arguably no need for additional data integrity, if the ni 426 URI or .well-known URL was received "securely." However TLS also 427 provides confidentiality, so there can still be reasons to use the 428 "https" URL scheme even in this case. Additionally, web server 429 policy such as [I-D.ietf-websec-strict-transport-sec] may dictate 430 that data might only be available over "https". In general however, 431 whether to use "http" or "https" is something that needs to be 432 decided by the application. 434 5. URL Segment Format 436 Some applications may benefit from using hashes in existing HTTP URLs 437 or other URLs. To do this one simply uses the "alg-val" production 438 from the ni name scheme ABNF which may be included for example in the 439 pathname, query string or even fragment components of HTTP URLs 440 [RFC2616]. In such cases there is nothing present in the URL that 441 ensures that a client can depend on compliance with this 442 specification, so clients MUST NOT assume that any URL with a 443 pathname component that matches the "alg-val" production was in fact 444 produced as a result of this specification. That URL might or might 445 not be related to this specification, only the context will tell. 447 6. Binary Format 449 If a more space-efficient version of the name is needed, the 450 following binary format can be used. The binary format name consists 451 of two fields: a header and the hash value. The header field defines 452 how the identifier has been created and the hash value contains a 453 (possibly truncated) result of a one-way hash over whatever is being 454 identified by the hash value. The binary format of a name is shown 455 in Figure 7. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |Res| Suite ID | Hash Value / 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 / ... / 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 / ... | 465 +-+-+-+-+-+-+-+-+ 467 Figure 7: Binary Name Format 469 The Res field is a reserved 2-bit field for future use and MUST be 470 set to zero for this specification and ignored on receipt. 472 The hash algorithm and truncation length are specified by the Suite 473 ID. For maintaining efficient encoding for the binary format, only a 474 few hash algorithms and truncation lengths are supported. See 475 Section 9.4 for details. 477 A hash value that is truncated to 120 bits will result in the overall 478 name being a 128-bit value which may be useful for protocols that can 479 easily use 128-bit identifiers. 481 7. Human-speakable (nih) URI Format 483 Sometimes a resource may need to be referred to via a name in a 484 format that is easy for humans to read out, and less likely to be 485 ambiguous when heard. This is intended to be usable for example over 486 the phone in order to confirm the (current or future) presence or 487 absence of a resource. This "confirmation" use-case described 488 further in Section 8.3 is the main current use-case for nih URIs. 490 The ni URI format is not well-suited for this, as, for example, 491 base64url uses both upper and lower case which can easily cause 492 confusion. For this particular purpose, ("speaking" the value of a 493 hash output) the more verbose but less ambiguous (when spoken) nih 494 URI scheme is defined. "nih" stands for "Named Information for 495 Humans." (Or possibly "Not Invented Here," which is clearly false, 496 and therefore worth including [RFC5513]:-) 498 The justification for nih being a URI scheme is that that can help a 499 user agent for the speaker to better display the value, or help a 500 machine to better speak or recognise the value when spoken. We do 501 not include the query string since there is no way to ensure that its 502 value might be spoken unambiguously, and similarly for the authority, 503 where e.g., some internationalised forms of domain name might not be 504 easy to speak and comprehend easily. This leaves the hash value as 505 the only part of the ni URI that we feel can be usefully included. 506 But since speakers or listeners (or speech recognition) may err, we 507 also include a check-digit to catch common errors, and allow for the 508 inclusion of "-" separators to make nih URIs more easy to read out. 510 Fields in nih URIs are separated by a semi-colon (;) character. The 511 first field is a hash algorithm string, as in the ni URI format. The 512 hash value is represented using lower-case ASCII hex characters, for 513 example an octet with the decimal value 58 (0x3A) is encoded as '3a'. 514 This is the same as base16 encoding as defined in RFC 4648 [RFC4648] 515 except using lower-case letters. Separators ("-" characters) MAY be 516 interspersed in the hash value in any way to make those easier to 517 read, typically grouping four or six characters with a separator 518 between. 520 The hash value MAY be followed by a semi-colon ';' then a checkdigit. 521 The checkdigit MUST be calculated using Luhn's mod N algorithm (with 522 N=16) as defined in [ISOIEC7812], (see also 523 http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). The input to the 524 calculation is the ASCII-HEX encoded hash value (i.e., "sepval" in 525 the ABNF production below) but with all "-" separator characters 526 first stripped out. This maps the ASCII-HEX so that 527 '0'=0,...'9'=9,'a'=10,...'f'=15. None of the other fields, nor any 528 "-" separators, are input when calculating the checkdigit. 530 humanname = "nih:" alg-sepval [ ";" checkdigit ] 531 alg-sepval = alg ";" sepval 532 sepval = 1*(ahlc / "-") 533 ahlc = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 534 ; DIGIT is defined in RFC 5234 and is 0-9 535 checkdigit = ahlc 537 Figure 8: Human-speakable syntax 539 For algorithms that have a Suite ID reserved (see Figure 11), the alg 540 field MAY contain the ID value as a ASCII encoded decimal number 541 instead of the hash name string (for example, "3" instead of "sha- 542 256-120"). Implementations MUST be able to match the decimal ID 543 values for the algorithms and hash lengths that they support even if 544 they do not support the binary format. 546 There is no such thing as a relative nih URI. 548 8. Examples 549 8.1. Hello World! 551 The following ni URI is generated from the text "Hello World!" 552 (without the quotes, being 12 characters), using the sha-256 553 algorithm shown with and without an authority field: 555 ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 557 ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 559 The following HTTP URL represents a mapping from the previous ni name 560 based on the algorithm outlined above. 562 http://example.com/.well-known/ni/sha-256/ 563 f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 565 8.2. Public Key Examples 567 Given the DER-encoded SubjectPublicKeyInfo in Figure 9 we derive the 568 names shown in Figure 10 for this value. 570 0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 571 0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 572 0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94 573 0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 574 0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b 575 0000120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b 576 0000140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 577 0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 578 0000200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 579 0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 580 0000240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 581 0000260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf 582 0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7 583 0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 584 0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 585 0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12 586 0000400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d 587 0000420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 05 01 ee 588 0000440 dd 02 03 01 00 01 590 0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 591 0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4 593 Figure 9: A SubjectPublicKeyInfo used in examples and its sha-256 594 hash 596 +-------------------------------------------------------------------+ 597 | URI: | 598 | ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 599 +-------------------------------------------------------------------+ 600 | .well-known URL (split over 2 lines): | 601 | http://example.com/.well-known/ni/sha256/ | 602 | UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 603 +-------------------------------------------------------------------+ 604 | URL Segment: | 605 | sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 606 +-------------------------------------------------------------------+ 607 | Binary name (ASCII hex encoded) with 120-bit truncated hash value | 608 | which is Suite ID 0x03: | 609 | 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 | 610 +-------------------------------------------------------------------+ 611 | Human-speakable form of a name for this key (truncated to 120 bits| 612 | in length) with checkdigit: | 613 | nih:sha-256-120;5326-9057-e12f-e2b7-4ba0-7c89-2560-a2;f | 614 +-------------------------------------------------------------------+ 615 | Human-speakable form of a name for this key (truncated to 32 bits | 616 | in length) with checkdigit and no "-" separators: | 617 | nih:sha-256-32;53269057;b | 618 +-------------------------------------------------------------------+ 619 | Human-speakable form using decimal presentation of the | 620 | algorithm ID (sha-256-120) with checkdigit: | 621 | nih:3;532690-57e12f-e2b74b-a07c89-2560a2;f | 622 +-------------------------------------------------------------------+ 624 Figure 10: Example Names 626 8.3. nih Usage Example 628 Alice has set up a server node with an RSA key pair. She uses an ni 629 URI as the name for the public key that corresponds to the private 630 key on that box. Alice's node might identify itself using that ni 631 URI in some protocol. 633 Bob would like to believe that its really Alice's node when his node 634 interacts with the network and asks his friend Alice to tell him what 635 public key she uses. Alice hits the "tell someone the name of the 636 public key" button on her admin user interface, and that displays the 637 nih URI and says "tell this to your buddy." She phones Bob and reads 638 the nih URI to him. 640 Bob types that in to his "manage known nodes" admin application, (or 641 lets that application listen to part of the call), which can 642 regenerate the ni URI and store that or some equivalent. Then when 643 Bob's node interacts with Alice's node it can more safely accept a 644 signature or encrypt data to Alice's node. 646 9. IANA Considerations 648 9.1. Assignment of ni URI Scheme 650 The procedures for registration of a URI scheme are specified in RFC 651 4395 [RFC4395]. The following is the proposed assignment template. 653 URI scheme name: ni 655 Status: Permanent 657 URI scheme syntax. See Section 3 659 URI scheme semantics. See Section 3 661 Encoding considerations. See Section 3 663 Applications/protocols that use this URI scheme name: General 664 applicability. 666 Interoperability considerations: Defined here. 668 Security considerations: See Section 10 670 Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie 672 Author/Change controller: IETF 674 References: As specified in this document 676 9.2. Assignment of nih URI Scheme 678 The procedures for registration of a URI scheme are specified in RFC 679 4395 [RFC4395]. The following is the proposed assignment template. 681 URI scheme name: nih 683 Status: Permanent 685 URI scheme syntax. See Section 7 687 URI scheme semantics. See Section 7 689 Encoding considerations. See Section 7 690 Applications/protocols that use this URI scheme name: General 691 applicability. 693 Interoperability considerations: Defined here. 695 Security considerations: See Section 10 697 Contact: Stephen Farrell, stephen.farrell@cs.tcd.ie 699 Author/Change controller: IETF 701 References: As specified in this document 703 9.3. Assignment of .well-known 'ni' URI 705 The procedures for registration of a Well Known URI entry are 706 specified in RFC 5785 [RFC5785]. The following is the proposed 707 assignment template. 709 URI suffix: ni 711 Change controller: IETF 713 Specification document(s): This document 715 Related information: None 717 9.4. Creation of Named Information Hash Algorithm Registry 719 IANA is requested to create a new registry for hash algorithms as 720 used in the name formats specified here and called the "Named 721 Information Hash Algorithm Registry". Future assignments are to be 722 made through Expert Review [RFC5226]. This registry has five fields, 723 the suite ID, the hash algorithm name string, the truncation length, 724 the underlying algorithm reference and a status field that indicates 725 if algorithm is current or deprecated and should no longer be used. 726 The status field can have the value "current" or "deprecated". Other 727 values are reserved for possible future definition. 729 If the status is "current", then that does not necessarily mean that 730 the algorithm is "good" for any particular purpose, since the 731 cryptographic strength requirements will be set by other applications 732 or protocols. 734 A request to mark an entry as "deprecated" can be done by sending a 735 mail to the Designated Expert. Before approving the request, the 736 community MUST be consulted via a "call for comments" of at least two 737 weeks by sending a mail to the IETF discussion list. 739 Initial values are specified below. The Designated Expert SHOULD 740 generally approve additions that reference hash algorithms that are 741 widely used in other IETF protocols. In addition, the Designated 742 Expert SHOULD NOT accept additions where the underlying hash function 743 (with no truncation) is considered weak for collisions. Part of the 744 reasoning behind this last point is that inclusion of code for weak 745 hash functions, e.g. the MD5 algorithm, can trigger costly false- 746 positives if code is audited for inclusion of obsolete ciphers. See 747 for example [RFC6149],[RFC6150] and [RFC6151] for some hash functions 748 that are considered obsolete in this sense. 750 The suite ID field ("ID") can be empty, or can have values between 0 751 and 63, inclusive. Because there are only 64 possible values, this 752 field is OPTIONAL (leaving it empty if omitted). Where the binary 753 format is not expected to be used for a given hash algorithm, this 754 field SHOULD be omitted. If an entry is registered without a suite 755 ID, the Designated Expert MAY allow for later allocation of a suite 756 ID, if that appears warranted. The Designated Expert MAY consult the 757 community via a "call for comments" by sending a mail to the IETF 758 discussion list before allocating a suite ID. 760 ID Hash name string Value length Reference Status 761 0 Reserved 762 1 sha-256 256 bits [SHA-256] current 763 2 sha-256-128 128 bits [SHA-256] current 764 3 sha-256-120 120 bits [SHA-256] current 765 4 sha-256-96 96 bits [SHA-256] current 766 5 sha-256-64 64 bits [SHA-256] current 767 6 sha-256-32 32 bits [SHA-256] current 768 32 Reserved 770 Figure 11: Suite Identifiers 772 The Suite ID value 32 is reserved for compatibility with ORCHIDs 773 [RFC4843]. 775 The referenced hash algorithm matching to the Suite ID, truncated to 776 the length indicated, according to the description given in 777 Section 2, is used for generating the hash. The Designated Expert is 778 responsible for ensuring that the document referenced for the hash 779 algorithm meets the "specification required" rule." 781 9.5. Creation of Named Information Parameter Registry 783 IANA is requested to create a new registry entitled "Named 784 Information URI Parameter Definitions". 786 The policy for future assignments to the registry is Expert Review, 787 and as for the ni Hash Algorithm Registry above, the Designated 788 Expert is responsible for ensuring that the document referenced for 789 the paramater definition meets the "specification required" rule." 791 The fields in this registry are the parameter name, a description and 792 a reference. The parameter name MUST be such that it is suitable for 793 use as a query string parameter name in an ni URI. (See Section 3.) 795 The initial contents of the registry are: 797 Parameter Meaning Reference 798 ----------- -------------------------------------------- --------- 799 ct Content Type [RFC-THIS] 801 10. Security Considerations 803 No secret information is required to generate or verify a name of the 804 form described here. Therefore a name like this can only provide 805 evidence for the integrity for the referenced object and the proof of 806 integrity provided is only as good as the proof of integrity for the 807 name from which we started. In other words, the hash value can 808 provide a name-data integrity binding between the name and the bytes 809 returned when the name is de-referenced using some protocol. 811 Disclosure of a name value does not necessarily entail disclosure of 812 the referenced object but may enable an attacker to determine the 813 contents of the referenced object by reference to a search engine or 814 other data repository or, for a highly formatted object with little 815 variation, by simply guessing the value and checking if the digest 816 value matches. So the fact that these names contain hashes does not 817 protect the confidentiality of the object that was input to the hash. 819 The integrity of the referenced content would be compromised if a 820 weak hash function were used. SHA-256 is currently our preferred 821 hash algorithm which is why we've only added SHA-256 based suites to 822 the initial IANA registry. 824 If a truncated hash value is used, certain security properties will 825 be affected. In general a hash algorithm is designed to produce 826 sufficient bits to prevent a 'birthday attack' collision occurring. 827 To ensure that the difficulty of discovering two pieces of content 828 that result in the same digest with a work factor O(2^x) by brute 829 force requires a digest length of 2x. Many security applications 830 only require protection against a 2nd pre-image attack which only 831 requires a digest length of x to achieve the same work factor. 833 Basically, the shorter the hash value used, the less security benefit 834 you can possibly get. 836 An important thing to keep in mind is not to make the mistake of 837 thinking two names are the same when they aren't. For example, a 838 name with a 32 bit truncated sha-256 hash is not the same as a name 839 with the full 256 bits of hash output, even if the hash value for one 840 is a prefix of that for the other. 842 The reason for this is that if an application treats those as the 843 same name then that might open up a number of attacks. For example, 844 if I publish an object with the full hash, then I probably (in 845 general) don't want some other application to treat a name with just 846 the first 32 bits of that as referring to the same thing, since the 847 32 bit name will have lots of colliding objects. If ni or nih URIs 848 become widely used, there will be many cases where names will occur 849 more than once in application protocols, and it'll be unpredictable 850 which instance of the name would be used for name-data integrity 851 checking, leading to threats. For this reason, we require that the 852 algorithm, length and value all match before we consider two names to 853 be the same. 855 The fact that an ni URI includes a domain name in the authority field 856 by itself implies nothing about the relationship between the owner of 857 the domain name and any content referenced by that URI. While a 858 name-data integrity service can be provided using ni URIs, that does 859 not in any sense validate the authority part of the name. For 860 example, there is nothing to stop anyone creating an ni URI 861 containing a hash of someone else's content. Application developers 862 MUST NOT assume any relationship between the registrant of the domain 863 name that is part of an ni URI and some matching content just because 864 the ni URI matches that content. 866 If name-data integrity is successfully validated, and the hash is 867 strong and long enough, then the "web origin" [RFC6454] for the bytes 868 of the named object is really going to be the place from which you 869 got the ni name and not the place from which you got the bytes of the 870 object. This appears to offer a potential benefit if using ni names 871 for, for example, scripts included from a HTML page accessed via 872 server-authenticated https. If name-data integrity is not validated 873 (and it is optional), or fails, then the web origin is, as usual, the 874 place from which the object bytes were received. Applications making 875 use of ni names SHOULD take this into account in their trust models. 877 Some implementations might mis-handle ni URIs that include non-base64 878 characters, whitespace or other non-conforming strings and that could 879 lead to erroneously considering names to be the same when they are 880 not. An ni URI that is malformed in such ways MUST NOT be treated as 881 matching any other ni URI. Implementers need to check the behaviour 882 of libraries for such parsing problems. 884 11. Acknowledgments 886 This work has been supported by the EU FP7 project SAIL. The authors 887 would like to thank SAIL participants to our naming discussions, 888 especially Jean-Francois Peltier, for their input. 890 The authors would also like to thank Carsten Bormann, Martin Durst, 891 Tobias Heer, Bjoern Hoehrmann, Tero Kivinen, Barry Leiba, Larry 892 Masinter, David McGrew, Alexey Melnikov, Bob Moskowitz, Jonathan 893 Rees, Eric Rescorla, Zach Shelby, Martin Thomas, for their comments 894 and input to the document. Thanks, in particular, to James Manger 895 for correcting the examples. 897 12. References 899 12.1. Normative References 901 [I-D.ietf-appsawg-media-type-regs] 902 Freed, N., Klensin, J., and T. Hansen, "Media Type 903 Specifications and Registration Procedures", 904 draft-ietf-appsawg-media-type-regs-14 (work in progress), 905 June 2012. 907 [I-D.ietf-httpbis-p1-messaging] 908 Fielding, R., Lafon, Y., and J. Reschke, "HTTP/1.1, part 909 1: Message Routing and Syntax"", 910 draft-ietf-httpbis-p1-messaging-20 (work in progress), 911 July 2012. 913 [ISOIEC7812] 914 ISO, ""ISO/IEC 7812-1:2006 Identification cards -- 915 Identification of issuers -- Part 1: Numbering system",", 916 October 2006, . 919 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 920 Extensions (MIME) Part One: Format of Internet Message 921 Bodies", RFC 2045, November 1996. 923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 924 Requirement Levels", BCP 14, RFC 2119, March 1997. 926 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 927 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 928 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 930 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 932 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 933 Resource Identifier (URI): Generic Syntax", STD 66, 934 RFC 3986, January 2005. 936 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 937 Registration Procedures for New URI Schemes", BCP 35, 938 RFC 4395, February 2006. 940 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 941 Encodings", RFC 4648, October 2006. 943 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 944 Specifications: ABNF", STD 68, RFC 5234, January 2008. 946 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 947 Housley, R., and W. Polk, "Internet X.509 Public Key 948 Infrastructure Certificate and Certificate Revocation List 949 (CRL) Profile", RFC 5280, May 2008. 951 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 952 Uniform Resource Identifiers (URIs)", RFC 5785, 953 April 2010. 955 [SHA-256] NIST, "United States National Institute of Standards and 956 Technology (NIST), FIPS 180-3: Secure Hash Standard", 957 October 2008, . 960 12.2. Informative References 962 [I-D.hallambaker-decade-ni-params] 963 Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, 964 D., and B. Ohlman, "The Named Information (ni) URI Scheme: 965 Optional Features", draft-hallambaker-decade-ni-params-03 966 (work in progress), June 2012. 968 [I-D.ietf-dane-protocol] 969 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 970 of Named Entities (DANE) Transport Layer Security (TLS) 971 Protocol: TLSA", draft-ietf-dane-protocol-23 (work in 972 progress), June 2012. 974 [I-D.ietf-websec-strict-transport-sec] 975 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 976 Transport Security (HSTS)", 977 draft-ietf-websec-strict-transport-sec-11 (work in 978 progress), July 2012. 980 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For 981 Public Keys Used For Exchanging Symmetric Keys", BCP 86, 982 RFC 3766, April 2004. 984 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 985 for Overlay Routable Cryptographic Hash Identifiers 986 (ORCHID)", RFC 4843, April 2007. 988 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 989 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 990 May 2008. 992 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 993 Acronyms", RFC 5513, April 1 2009. 995 [RFC6149] Turner, S. and L. Chen, "MD2 to Historic Status", 996 RFC 6149, March 2011. 998 [RFC6150] Turner, S. and L. Chen, "MD4 to Historic Status", 999 RFC 6150, March 2011. 1001 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 1002 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 1003 RFC 6151, March 2011. 1005 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1006 December 2011. 1008 [magnet] Wikipedia article, "Magnet URI Scheme", April 2012, 1009 . 1011 [ref.ccn] Jacobson at al., "Networking Named Content", CoNEXT 2009 , 1012 December 2009. 1014 [ref.netinf-design] 1015 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 1016 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 1017 Considerations for a Network of Information", Re-Arch 2008 1018 Workshop , December 2008. 1020 Authors' Addresses 1022 Stephen Farrell 1023 Trinity College Dublin 1024 Dublin, 2 1025 Ireland 1027 Phone: +353-1-896-2354 1028 Email: stephen.farrell@cs.tcd.ie 1030 Dirk Kutscher 1031 NEC 1032 Kurfuersten-Anlage 36 1033 Heidelberg, 1034 Germany 1036 Phone: 1037 Email: kutscher@neclab.eu 1039 Christian Dannewitz 1040 University of Paderborn 1041 Paderborn 1042 Germany 1044 Email: cdannewitz@upb.de 1046 Borje Ohlman 1047 Ericsson 1048 Stockholm S-16480 1049 Sweden 1051 Email: Borje.Ohlman@ericsson.com 1053 Ari Keranen 1054 Ericsson 1055 Jorvas 02420 1056 Finland 1058 Email: ari.keranen@ericsson.com 1059 Phillip Hallam-Baker 1060 Comodo Group Inc. 1062 Email: philliph@comodo.com