idnits 2.17.1 draft-farrell-decade-ni-06.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 (May 6, 2012) is 4366 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: 'Required' is mentioned on line 228, but not defined == Missing Reference: 'Optional' is mentioned on line 235, but not defined -- 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 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-03) exists of draft-hallambaker-decade-ni-params-02 == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-20 == Outdated reference: A later version (-14) exists of draft-ietf-websec-strict-transport-sec-07 -- 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 (~~), 6 warnings (==), 4 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: November 7, 2012 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 May 6, 2012 15 Naming Things with Hashes 16 draft-farrell-decade-ni-06 18 Abstract 20 This document defines a set of ways to identify a thing using the 21 output from a hash function, specifying URI, URL, binary and human 22 "speakable" formats for these names. The various formats are 23 designed to support, but not require, a strong link to the referenced 24 object such that the referenced object may be authenticated to the 25 same degree as the reference to it. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 7, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Hashes are what Count . . . . . . . . . . . . . . . . . . . . 4 60 3. Named Information (ni) URI Format . . . . . . . . . . . . . . 5 61 4. .well-known URL Format . . . . . . . . . . . . . . . . . . . . 7 62 5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Human-readable Format . . . . . . . . . . . . . . . . . . . . 9 65 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Assignment of Named Information (ni) URI Scheme . . . . . 12 68 9.2. Assignment of Named Information for Humans (nih) URI 69 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.3. Assignment of Well Known URI prefix ni . . . . . . . . . . 13 71 9.4. Hash Name Algorithm Registry . . . . . . . . . . . . . . . 14 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 Names or identifiers are used in various protocols for identifying 82 resources. In many scenarios those names or identifiers contain 83 values that are hash function outputs. However, different 84 deployments have chosen various different ways to include hash 85 function outputs in such names or identifiers. This document 86 specifies standard ways to do that to aid interoperability. 88 Hash function outputs can be used to ensure uniqueness in terms of 89 mapping URIs [RFC3986] to a specific resource, or to make URIs hard 90 to guess for security reasons. Since, there is no standard way to 91 interpret those strings, today in general only the creator of the URI 92 knows how to use the hash function output. Other protocols, such as 93 application layer protocols for accessing "smart objects" in 94 constrained environments also require more compact (e.g., binary) 95 forms of such identifiers, while in other situations people may have 96 to input such values or talk about them, e.g., in a voice call. 98 As another example, protocols for accessing in-network storage 99 servers need a way to identify stored resources uniquely and in a 100 location-independent way so that replicas on different servers can be 101 accessed by the same name. Also, such applications may require 102 verifying that a resource representation that has been obtained 103 actually corresponds to the name that was used to request the 104 resource, i.e., verifying the integrity of the name-data binding. 106 Similarly, in the context of information-centric networking 107 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 108 able to compare a presented resource against the URI that was 109 dereferenced in order to access that resource. If a 110 cryptographically-strong comparison function can be used then this 111 allows for many forms of in-network storage, without requiring as 112 much trust in the infrastructure used to present the resource. The 113 outputs of hash functions can be used in this manner, if presented in 114 a standard way. 116 Additional applications might include creating references from web 117 pages delivered over HTTP/TLS; DNS resource records signed using 118 DNSSEC or data values embedded in certificates, Certificate 119 Revocation Lists (CRLs), or other signed data objects. 121 The "ni" URI scheme defined here is very similar to the "magnet link" 122 informally defined in various other protocols. [magnet] 124 The ni URI scheme also allows for the use of a query-string, similar 125 to how query-strings are used in HTTP URLs. A companion 126 specification [I-D.hallambaker-decade-ni-params] describes specific 127 values that can be used in such query strings for various purposes 128 and other extensions to this basic format specification. 130 In addition, we also define a ".well-known" URL equivalent, and a way 131 to include a hash as a segment of an HTTP URL, as well as a binary 132 format for use in protocols that require more compact names and a 133 human-speakable text form that could be used, e.g. for reading out 134 (parts of) the name over a voice connection. 136 Not all uses of these names require use of the full hash output - 137 truncated hashes can be safely used in some environments. For this 138 reason, we define a new IANA registry for hash functions to be used 139 with this specification so as not to mix strong and weak (truncated) 140 hash algorithms in other protocol registries. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 Syntax definitions in this memo are specified according to ABNF 147 [RFC5234]. 149 2. Hashes are what Count 151 This section contains basic considerations related to how we use hash 152 function outputs that are common to all formats. 154 When verifying whether two names refer to same object, an 155 implementation MUST only consider the digest algorithm and the digest 156 value, i.e., it MUST NOT other fields defined below (such as an 157 authority field from a URI or any parameters). Implementations MUST 158 consider two hashes identical, regardless of encoding, if the decoded 159 hashes are based on the same algorithm and have are the same length 160 and the same binary value. In that case, the two names can be 161 treated as referring to the same thing. 163 The sha-256 algorithm as specified in [RFC4055] is mandatory to 164 implement, that is, implementations MUST be able to generate/send and 165 to accept/process names based on a sha-256 hash. However 166 implementations MAY support additional hash algorithms and MAY use 167 those for specific names, for example in a constrained environment 168 where sha-256 is non-optimal or where truncated names are needed to 169 fit into corresponding protocols (when a higher collision probability 170 can be tolerated). 172 Truncated hashes MAY be supported if needed. When a hash value is 173 truncated the name MUST indicate this. Therefore we use different 174 hash algorithm strings for these, such as sha-256-32 for a 32-bit 175 truncation of a sha-256 output. (Note that a 32-bit truncated hash 176 is essentially useless for security but might be useful for naming.) 178 When a hash value is truncated to N bits the left-most or most 179 significant in network byte order N bits from the binary 180 representation of the hash value MUST be used as the truncated value. 181 An example of a 128-bit hash output truncated to 32 bits is shown in 182 Figure 1. 184 128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 185 32-bit truncated hash: 0x26535790 187 Figure 1: Example of Truncated Hash 189 When the input to the hash algorithm is a public key value, as may be 190 used by various security protocols, the hash SHOULD be calculated 191 over the public key in an X.509 SubjectPublicKeyInfo structure 192 (Section 4.1 of [RFC5280]). This input has been chosen primarily for 193 compatibility with DANE [I-D.ietf-dane-protocol], but also includes 194 any relevant public key parameters in the hash input, which is 195 sometimes necessary for security reasons. Note also that this does 196 not force use of X.509 or full compliance with [RFC5280] since 197 formatting any public key as a SubjectPublicKeyInfo is relatively 198 straightforward and well supported by libraries. 200 Any of the formats defined below can be used to represent the 201 resulting name for a public key. 203 Other than in the above special case where public keys are used, we 204 do not specify the hash function input here. Other specifications 205 are expected to define this. 207 3. Named Information (ni) URI Format 209 A Named Information (ni) URI consists of the following components: 211 Scheme Name [Required] The scheme name is 'ni'. 213 Colon and Slashes [Required] The literal "://" 215 Authority [Optional] The optional authority component may assist 216 applications in accessing the object named by an ni URI. Note 217 that while the ni names with and without an authority differ 218 syntactically, both names refer to the same object if the digest 219 algorithm and value are the same. 221 One slash [Required] The literal "/" 223 Digest Algorithm [Required] The name of the digest algorithm, as 224 specified in the IANA registry defined in Section 9.4 below. 226 Separator [Required] The literal ";" 228 Digest Value [Required] The digest value encoded in the specified 229 encoding. 231 Query Parameter separator [Optional] '?' The query parameter 232 separator acts a separator between the digest value and the query 233 parameters (if specified). 235 Query Parameters [Optional] A tag=value list of optional query 236 parameters as are used with HTTP URLs [RFC2616] with a separator 237 character '&' between each. For example, "foo=bar&baz=bat" 239 It is OPTIONAL for implementations to check the integrity of the URI/ 240 resource mapping when sending, receiving or processing "ni" URIs. 242 The digest value MUST be encoded using base64url [RFC4648] encoding. 244 The query segment of a URI is NOT hierarchical. Thus escape encoding 245 of slash '/' characters is NOT required. Since application code 246 often attempts to enforce such encoding, decoders MUST recognize the 247 use of URI escape encoding (e.g., '%2f' or '%2F' for the slash 248 character). Section 3.4 of [RFC3986] states that "The characters 249 slash ("/") and question mark ("?") may represent data within the 250 query component." All of this is as per RFC 3986, and should 251 anything here conflict with that, RFC 3986 rules apply. 253 Consequently no special escaping mechanism is required for the query 254 parameter portion of ni URIs. URI escaping is however frequently 255 imposed automatically by scripting environments. Thus to ensure 256 interoperability, implementations SHOULD NOT generate URIs that 257 employ URI character escaping, and implementations MUST NOT reject 258 any URIs that employ URI character escaping. 260 The Named Information URI adapts the URI definition from the URI 261 Generic Syntax [RFC3986]. We start with the base URI production: 263 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 264 ; from RFC 3986 266 Figure 2: URI syntax 268 Adapting that for the Named Information URI: 270 NI-URI = ni-scheme ":" ni-hier-part [ "?" ni-query ] 271 ; adapted from "URI" in RFC 3986 272 ni-scheme = "ni" 274 ni-hier-part = "//" authority path-algval 275 / path-algval 276 ; adapted from "hier-part" in RFC 3986 278 path-algval = "/" alg ";" val 279 alg = 1*unreserved 280 val = 1*unreserved 282 ni-query = attr "=" value [*( "&" attr "=" value )] 283 attr = query-token 284 value = query-token 286 query-token = 1*( unreserved / pct-encoded ) 288 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 289 ; directly from RFC 3986, section 2.3 290 ; "authority" and "pct-encoded" are also from RFC 3986 292 Figure 3: ni Name syntax 294 The "val" field MUST contain the output of applying the hash function 295 ("alg") to its defined input, which defaults to the object bytes that 296 are expected to be returned when the URI is dereferenced. 298 4. .well-known URL Format 300 We define a mapping between URIs following the ni URI scheme and HTTP 301 [RFC2616] or HTTPS [RFC2617] URLs that makes use of the .well-known 302 URI [RFC5785] by defining an "ni" suffix (see Section 9). 304 The HTTP(S) mapping MAY be used in any context where clients without 305 support for ni URIs are needed without loss of interoperability or 306 functionality. 308 Note that since the .well-known name-space is not intended for 309 general information retrieval, if an application de-references a 310 .well-known/ni URL via HTTP(S), then it SHOULD expect to receive a 311 30x HTTP re-direction response and it MUST be able to handle this. 312 Put another way, a server SHOULD return a 30x response when a .well- 313 known/ni URL is de-referenced. 315 For an ni name of the form "ni://n-authority/alg;val?query-string" 316 the corresponding HTTP(S) URL produced by this mapping is 317 "http://h-authority/.well-known/ni/alg/val?query-string", where 318 "h-authority" is derived as follows: If the ni name has a specified 319 authority (i.e., the n-authority is non-empty) then the h-authority 320 MUST have the same value. If the ni name has no authority specified 321 (i.e. the n-authority string is empty), a h-authority value MAY be 322 derived from the application context. For example, if the mapping is 323 being done in the context of a web page then the origin [RFC6454] for 324 that web site can be used. Of course, there are in general no 325 guarantees that the object named by the ni URI will be available at 326 the corresponding HTTP(S) URL. But in the case that any data is 327 returned, the retriever can determine whether or not it is content 328 that matches the ni URI. 330 If an application is presented with a HTTP(S) URL with "/.well- 331 known/ni/" as the start of its pathname component, then the reverse 332 mapping to an ni URI either including or excluding the authority 333 might produce an ni URI that is meaningful, but there is no guarantee 334 that this will be the case. 336 When mapping from a ni URI to a .well-known URL, an implementation 337 will have to decide between choosing an "http" or "https" URL. If 338 the object referenced does in fact match the hash in the URL, then 339 there is arguably no need for additional data integrity, if the ni 340 URI or .well-known URL was received "securely." However TLS also 341 provides confidentiality, so there may still be reasons to use the 342 "https" URL scheme even in this case. Additionally, web server 343 policy such as [I-D.ietf-websec-strict-transport-sec] may dictate 344 that data might only be available over "https". In general however, 345 whether to use "http" or "https" is something that needs to be 346 decided by the application. 348 5. URL Segment Format 350 Some applications may benefit from using hashes in existing HTTP URLs 351 or other URLs. To do this one simply uses the "alg;val" production 352 from the ni name scheme ABNF which may be included in the pathname 353 component of HTTP URLs. [RFC2616] In such cases there is nothing 354 present in the URL that ensures that a client can depend on 355 compliance with this specification, so clients MUST NOT assume that 356 any URL with a pathname component that matches the "alg;val" 357 production was in fact produced as a result of this specification. 358 That URL might or might not be related to this specification, only 359 the context will tell. 361 6. Binary Format 363 When a more space-efficient version of the name is needed, we can use 364 a binary format. The binary format name consists of two fields: a 365 header and the hash value. The header field defines how the 366 identifier has been created and the hash value contains a (possibly 367 truncated) result of a one-way hash over whatever is being identified 368 by the hash value. The format of the binary representation of a name 369 is shown in Figure 4. 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |Res| Suite ID | Hash Value / 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 / ... / 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 / ... | 379 +-+-+-+-+-+-+-+-+ 381 Figure 4: Binary Name Format 383 The Res field is a reserved 2-bit field for future use and MUST be 384 set to zero for this specification. 386 The hash algorithm and truncation length are specified by the Suite 387 ID. For maintaining efficient encoding for the binary presentation, 388 only a few hash algorithms and truncation lengths are supported. See 389 Section 9.4 for details. 391 Note that a hash value that is truncated to 120 bits will result in 392 the overall name being a 128-bit value which may be useful with 393 certain use-cases. 395 7. Human-readable Format 397 Sometimes the name may need to be used in a format that is easy for 398 humans to read and possibly communicate, for example, over the phone. 399 For this purpose, the following more verbose but less ambiguous (when 400 spoken) URI format is defined with scheme name "nih", standing for 401 "Named Information for Humans." (Or possibly "Not Invented Here," 402 which is clearly false, and therefore worth including :-) 404 Fields in nih URIs are separated by a semi-colon (;) character. The 405 first field is a hash algorithm string, as in the ni URI format. The 406 hash value is represented using lower-case ASCII hex characters, for 407 example an octet with the decimal value 58 (0x3A) is encoded as '3a'. 408 This is the same as base16 encoding as defined in RFC 4648 [RFC4648] 409 except using lower-case letters. 411 The hash value is OPTIONALLY followed by a semi-colon ';' then a 412 checkdigit. The checkdigit MUST be calculated using Luhn's mod N 413 algorithm (with N=16) as defined in [ISOIEC7812], (see also 414 http://en.wikipedia.org/wiki/Luhn_mod_N_algorithm). The input to the 415 calculation is the ASCII-HEX encoded hash value (i.e. "val" in the 416 ABNF production below). This maps the ASCII-HEX so that 417 '0'=0,...'9'=9,'a'=10,...'f'=15. None of the other fields are input 418 when calculating the checkdigit. 420 humanname = "nih:" algval [ ";" checkdigit ] 421 algval = alg ";" val 422 alg = 1*unreserved 423 val = 1*unreserved 424 checkdigit = unreserved 426 Figure 5: Human-readable syntax 428 For algorithms that have a Suite ID reserved (see Figure 8), the alg 429 field MAY contain the ID value as a UTF-8 encoded decimal number 430 instead of the hash name string (for example, "3" instead of "sha- 431 256-120"). Implementations MUST be able to match the decimal ID 432 values for the algorithms and hash lengths that they support even if 433 they do not support the binary presentation. 435 8. Examples 437 The following ni URI references the text "Hello World!" (without the 438 quotes, being 12 characters), using the sha-256 algorithm shown with 439 and without an authority field: 441 ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 443 ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 445 The following HTTP URL represents a mapping from the previous ni name 446 based on the algorithm outlined above. 448 http://example.com/.well-known/ni/sha-256/ 449 f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk 451 Given the SubjectPublicKeyInfo in Figure 6 we derive the names shown 452 in Figure 7 for this value. 454 0000000 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 455 0000020 01 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 01 456 0000040 00 a2 5f 83 da 9b d9 f1 7a 3a 36 67 ba fd 5a 94 457 0000060 0e cf 16 d5 5a 55 3a 5e d4 03 b1 65 8e 6d cf a3 458 0000100 b7 db a4 e7 cc 0f 52 c6 7d 35 1d c4 68 c2 bd 7b 459 0000120 9d db e4 0a d7 10 cd f9 53 20 ee 0d d7 56 6e 5b 460 0000140 7a ae 2c 5f 83 0a 19 3c 72 58 96 d6 86 e8 0e e6 461 0000160 94 eb 5c f2 90 3e f3 a8 8a 88 56 b6 cd 36 38 76 462 0000200 22 97 b1 6b 3c 9c 07 f3 4f 97 08 a1 bc 29 38 9b 463 0000220 81 06 2b 74 60 38 7a 93 2f 39 be 12 34 09 6e 0b 464 0000240 57 10 b7 a3 7b f2 c6 ee d6 c1 e5 ec ae c5 9c 83 465 0000260 14 f4 6b 58 e2 de f2 ff c9 77 07 e3 f3 4c 97 cf 466 0000300 1a 28 9e 38 a1 b3 93 41 75 a1 a4 76 3f 4d 78 d7 467 0000320 44 d6 1a e3 ce e2 5d c5 78 4c b5 31 22 2e c7 4b 468 0000340 8c 6f 56 78 5c a1 c4 c0 1d ca e5 b9 44 d7 e9 90 469 0000360 9c bc ee b0 a2 b1 dc da 6d a0 0f f6 ad 1e 2c 12 470 0000400 a2 a7 66 60 3e 36 d4 91 41 c2 f2 e7 69 39 2c 9d 471 0000420 d2 df b5 a3 44 95 48 7c 87 64 89 dd bf 05 01 ee 472 0000440 dd 02 03 01 00 01 474 0000000 53 26 90 57 e1 2f e2 b7 4b a0 7c 89 25 60 a2 d7 475 0000020 53 87 7e b6 2f f4 4d 5a 19 00 25 30 ed 97 ff e4 477 Figure 6: A SubjectPublicKeyInfo used in examples and its sha-256 478 hash 480 +-------------------------------------------------------------------+ 481 | URI: | 482 | ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 483 +-------------------------------------------------------------------+ 484 | .well-known URL (split over 2 lines): | 485 | http://example.com/.well-known/ni/sha256/ | 486 | UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 487 +-------------------------------------------------------------------+ 488 | URL Segment: | 489 | sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q | 490 +-------------------------------------------------------------------+ 491 | Binary name (ASCII hex encoded) with 120-bit truncated hash value | 492 | which is Suite ID 0x03: | 493 | 0353 2690 57e1 2fe2 b74b a07c 8925 60a2 | 494 +-------------------------------------------------------------------+ 495 | Human-readable form of a name for this key (truncated to 120 bits | 496 | in length) with checksum: | 497 | nih:sha-256-120;53269057e12fe2b74ba07c892560a2;f | 498 +-------------------------------------------------------------------+ 499 | Human-readable form of a name for this key (truncated to 32 bits | 500 | in length) with checksum: | 501 | nih:sha-256-32;53269057;b | 502 +-------------------------------------------------------------------+ 503 | Human-readable form using decimal presentation of the | 504 | algorithm ID (sha-256-120) with checksum: | 505 | nih:3;53269057e12fe2b74ba07c892560a2;f | 506 +-------------------------------------------------------------------+ 508 Figure 7: Example Names 510 9. IANA Considerations 512 9.1. Assignment of Named Information (ni) URI Scheme 514 The procedures for registration of a URI scheme are specified in RFC 515 4395 [RFC4395]. The following is the proposed assignment template. 517 URI scheme name: ni 519 Status: Permanent 521 URI scheme syntax. See Section 3 523 URI scheme semantics. See Section 3 525 Encoding considerations. See Section 3 526 Applications/protocols that use this URI scheme name: General 527 applicability with initial use cases provided by CoAP and DECADE 529 Interoperability considerations: Defined here. 531 Security considerations: See Section 10 533 Contact: stephen.farrell@cs.tcd.ie 535 Author/Change controller: IETF 537 References: As specified in this document 539 9.2. Assignment of Named Information for Humans (nih) URI Scheme 541 The procedures for registration of a URI scheme are specified in RFC 542 4395 [RFC4395]. The following is the proposed assignment template. 544 URI scheme name: nih 546 Status: Permanent 548 URI scheme syntax. See Section 7 550 URI scheme semantics. See Section 7 552 Encoding considerations. See Section 7 554 Applications/protocols that use this URI scheme name: General 555 applicability with initial use cases provided by CoAP and DECADE 557 Interoperability considerations: Defined here. 559 Security considerations: See Section 10 561 Contact: stephen.farrell@cs.tcd.ie 563 Author/Change controller: IETF 565 References: As specified in this document 567 9.3. Assignment of Well Known URI prefix ni 569 The procedures for registration of a Well Known URI entry are 570 specified in RFC 5785 [RFC5785]. The following is the proposed 571 assignment template. 573 URI suffix: ni 574 Change controller: IETF 576 Specification document(s): This document 578 Related information: None 580 9.4. Hash Name Algorithm Registry 582 IANA is requested to create a new registry for hash algorithms as 583 used in the name formats specified here. Future assignments are to 584 be made through expert review [RFC5226]. This registry has five 585 fields, the binary suite ID, the hash algorithm name string, the 586 truncation length, the underlying algorithm reference and a status 587 field that indicates if algorithm is deprecated and should no longer 588 be used. The status field can be empty or have the value 589 "deprecated". Other values are reserved for possible future 590 definition. 592 Note that if the status is not "deprecated" (it is empty), then that 593 does not necessarily mean that the algorithm is "good" for any 594 particular purpose, since the cryptographic strength requirements 595 will be set by other applications or protocols. The expert SHOULD 596 seek IETF review before approving a request to mark an entry as 597 "deprecated." Such requests may simply take the form of a mail to 598 the designated expert (an RFC is not required). IETF review can be 599 achieved if the designated expert sends a mail to the IETF discussion 600 list. At least two weeks for comments MUST be allowed thereafter 601 before the request is approved and actioned. 603 Initial values are specified below. The expert SHOULD generally 604 approve additions that reference hash algorithms that are widely used 605 in other IETF protocols. In addition, the expert SHOULD NOT accept 606 additions where the underlying hash function (with no truncation) is 607 considered weak for collisions. 609 The binary suite ID field ("ID") can be empty, or can have values 610 between 0 and 63, inclusive. Because there are only 64 possible 611 values, this field is OPTIONAL (leaving it empty if omitted). Where 612 the binary format is not expected to be used for a given hash 613 algorithm, this field SHOULD be omitted. If an entry is registered 614 without a suite ID, the expert may allow for later allocation of a 615 suite ID, if that appears warranted. The expert MAY request IETF 616 review before allocating a suite ID. 618 ID Hash name string Value length Reference Status 619 0 Reserved 620 1 sha-256 256 bits [RFC4055] - 621 2 sha-256-128 128 bits [RFC4055] - 622 3 sha-256-120 120 bits [RFC4055] - 623 4 sha-256-96 96 bits [RFC4055] - 624 5 sha-256-64 64 bits [RFC4055] - 625 6 sha-256-32 32 bits [RFC4055] - 626 32 Reserved 628 Figure 8: Suite Identifiers 630 The Suite ID value 32 is reserved for compatibility with ORCHIDs 631 [RFC4843]. 633 The referenced hash algorithm matching to the Suite ID, truncated to 634 the length indicated, according to the description given in 635 Section 2, is used for generating the hash. The designated expert is 636 responsible for ensuring that the document referenced for the hash 637 algorithm is such that it would be acceptable were the "specification 638 required" rule applied. 640 10. Security Considerations 642 No secret information is required to generate or verify a name of the 643 form described here. Therefore a name like this can only provide 644 evidence for the integrity for the referenced object and the proof of 645 integrity provided is only as good as the proof of integrity for the 646 name from which we started. In other words, the hash value can 647 provide a name-data integrity binding between the name and the bytes 648 returned when the name is de-referenced using some protocol. 650 Disclosure of a name value does not necessarily entail disclosure of 651 the referenced object but may enable an attacker to determine the 652 contents of the referenced object by reference to a search engine or 653 other data repository or, for a highly formatted object with little 654 variation, by simply guessing the value and checking if the digest 655 value matches. So the fact that these names contain hashes does not 656 protect the confidentiality of the object that was input to the hash. 658 The integrity of the referenced content would be compromised if a 659 weak hash function were used. SHA-256 is currently our preferred 660 hash algorithm which is why we've only added SHA-256 based suites to 661 the initial IANA registry. 663 If a truncated hash value is used, certain security properties will 664 be affected. In general a hash algorithm is designed to produce 665 sufficient bits to prevent a 'birthday attack' collision occurring. 666 To ensure that the difficulty of discovering two pieces of content 667 that result in the same digest with a work factor O(2^x) by brute 668 force requires a digest length of 2x. Many security applications 669 only require protection against a 2nd pre-image attack which only 670 requires a digest length of x to achieve the same work factor. 671 Basically, the shorter the hash value used, the less security benefit 672 you can possibly get. 674 Note that fact that an ni URI includes an domain name in the 675 authority field by itself implies nothing about the relationship 676 between the owner of the domain name and any content referenced by 677 that URI. While a name-data integrity service can be provided using 678 ni URIs, that does not in any sense validate the authority part of 679 the name, for example, there is nothing to stop anyone creating an ni 680 URI containing a hash of someone else's content so application 681 developers MUST NOT assume any relationship between the owner of a 682 domain name that is part of an ni URI and some matching content just 683 because the ni URI matches that content. 685 11. Acknowledgements 687 This work has been supported by the EU FP7 project SAIL. The authors 688 would like to thank SAIL participants to our naming discussions, 689 especially Jean-Francois Peltier, for their input. 691 The authors would also like to thank Bob Moskowitz, Tero Kivinen, 692 Zach Shelby, Carsten Bormann, David McGrew, Eric Rescorla, Tobias 693 Heer, Martin Thomas, Alexey Melnikov, Barry Leiba and, in particular, 694 James Manger for their comments and input to the document. 696 12. References 698 12.1. Normative References 700 [ISOIEC7812] 701 ISO, ""ISO/IEC 7812-1:2006 Identification cards -- 702 Identification of issuers -- Part 1: Numbering system",", 703 October 2006, . 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 711 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 713 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 714 Leach, P., Luotonen, A., and L. Stewart, "HTTP 715 Authentication: Basic and Digest Access Authentication", 716 RFC 2617, June 1999. 718 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 719 Resource Identifier (URI): Generic Syntax", STD 66, 720 RFC 3986, January 2005. 722 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 723 Algorithms and Identifiers for RSA Cryptography for use in 724 the Internet X.509 Public Key Infrastructure Certificate 725 and Certificate Revocation List (CRL) Profile", RFC 4055, 726 June 2005. 728 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 729 Registration Procedures for New URI Schemes", BCP 35, 730 RFC 4395, February 2006. 732 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 733 Encodings", RFC 4648, October 2006. 735 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 736 Specifications: ABNF", STD 68, RFC 5234, January 2008. 738 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 739 Housley, R., and W. Polk, "Internet X.509 Public Key 740 Infrastructure Certificate and Certificate Revocation List 741 (CRL) Profile", RFC 5280, May 2008. 743 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 744 Uniform Resource Identifiers (URIs)", RFC 5785, 745 April 2010. 747 12.2. Informative References 749 [I-D.hallambaker-decade-ni-params] 750 Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, 751 D., and B. Ohlman, "The Named Information (ni) URI Scheme: 752 Optional Features", draft-hallambaker-decade-ni-params-02 753 (work in progress), April 2012. 755 [I-D.ietf-dane-protocol] 756 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 757 of Named Entities (DANE) Transport Layer Security (TLS) 758 Protocol: TLSA", draft-ietf-dane-protocol-20 (work in 759 progress), April 2012. 761 [I-D.ietf-websec-strict-transport-sec] 762 Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 763 Transport Security (HSTS)", 764 draft-ietf-websec-strict-transport-sec-07 (work in 765 progress), May 2012. 767 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 768 for Overlay Routable Cryptographic Hash Identifiers 769 (ORCHID)", RFC 4843, April 2007. 771 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 772 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 773 May 2008. 775 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 776 December 2011. 778 [magnet] Wikipedia article, "Magnet URI Scheme", April 2012, 779 . 781 [ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content", 782 CoNEXT 2009 , December 2009. 784 [ref.netinf-design] 785 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 786 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 787 Considerations for a Network of Information", Re-Arch 2008 788 Workshop , December 2008. 790 Authors' Addresses 792 Stephen Farrell 793 Trinity College Dublin 794 Dublin, 2 795 Ireland 797 Phone: +353-1-896-2354 798 Email: stephen.farrell@cs.tcd.ie 799 Dirk Kutscher 800 NEC 801 Kurfuersten-Anlage 36 802 Heidelberg, 803 Germany 805 Phone: 806 Email: kutscher@neclab.eu 808 Christian Dannewitz 809 University of Paderborn 810 Paderborn 811 Germany 813 Email: cdannewitz@upb.de 815 Borje Ohlman 816 Ericsson 817 Stockholm S-16480 818 Sweden 820 Email: Borje.Ohlman@ericsson.com 822 Ari Keranen 823 Ericsson 824 Jorvas 02420 825 Finland 827 Email: ari.keranen@ericsson.com 829 Phillip Hallam-Baker 830 Comodo Group Inc. 832 Email: philliph@comodo.com