idnits 2.17.1 draft-farrell-decade-ni-08.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 (June 22, 2012) is 4324 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 243, but not defined == Missing Reference: 'Optional' is mentioned on line 253, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 747, but not defined == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-19 -- 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 4288 (Obsoleted by RFC 6838) ** 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-09 -- 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: 5 errors (**), 0 flaws (~~), 6 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: December 24, 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 June 22, 2012 15 Naming Things with Hashes 16 draft-farrell-decade-ni-08 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. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 24, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Hashes are what Count . . . . . . . . . . . . . . . . . . . . 4 61 3. Named Information (ni) URI Format . . . . . . . . . . . . . . 5 62 3.1. Content Type Query String Attribute . . . . . . . . . . . 8 63 4. .well-known URL Format . . . . . . . . . . . . . . . . . . . . 9 64 5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Human-speakable Format . . . . . . . . . . . . . . . . . . . . 11 67 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. Assignment of Named Information (ni) URI Scheme . . . . . 14 70 9.2. Assignment of Named Information for Humans (nih) URI 71 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 9.3. Well Known 'ni' URI . . . . . . . . . . . . . . . . . . . 15 73 9.4. ni Hash Algorithm Registry . . . . . . . . . . . . . . . . 16 74 9.5. Creation of ni parameter registry . . . . . . . . . . . . 17 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 79 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 82 1. Introduction 84 Names or identifiers are used in various protocols for identifying 85 resources. In many scenarios those names or identifiers contain 86 values that are hash function outputs. However, different 87 deployments have chosen various different ways to include hash 88 function outputs in such names or identifiers. This document 89 specifies standard ways to do that to aid interoperability. We begin 90 with a few example uses for the various ways to include a hash in a 91 name as they are defined later in this document, for example Figure 1 92 shows an example of the "Named Information" (ni) URI scheme defined 93 here. 95 ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q 97 Figure 1: Example ni URI 99 Hash function outputs can be used to ensure uniqueness in terms of 100 mapping URIs [RFC3986] to a specific resource, or to make URIs hard 101 to guess for security reasons. Since there is no standard way to 102 interpret those strings, today in general only the creator of the URI 103 knows how to use the hash function output. Other protocols, such as 104 application layer protocols for accessing "smart objects" in 105 constrained environments also require more compact (e.g., binary) 106 forms of such identifiers, while in other situations people may have 107 to input such values or talk about them, e.g., in a voice call. 109 As another example, protocols for accessing in-network storage 110 servers need a way to identify stored resources uniquely and in a 111 location-independent way so that replicas on different servers can be 112 accessed by the same name. Also, such applications may require 113 verifying that a resource representation that has been obtained 114 actually corresponds to the name that was used to request the 115 resource, i.e., verifying the integrity of the name-data binding. 117 Similarly, in the context of information-centric networking 118 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 119 able to compare a presented resource against the URI that was 120 dereferenced in order to access that resource. If a 121 cryptographically-strong comparison function can be used then this 122 allows for many forms of in-network storage, without requiring as 123 much trust in the infrastructure used to present the resource. The 124 outputs of hash functions can be used in this manner, if presented in 125 a standard way. 127 Additional applications might include creating references from web 128 pages delivered over HTTP/TLS; DNS resource records signed using 129 DNSSEC or data values embedded in certificates, Certificate 130 Revocation Lists (CRLs), or other signed data objects. 132 The "ni" URI scheme defined here is very similar to the "magnet link" 133 informally defined in various other protocols. [magnet] 135 Media content-type, alternative locations for retrieval and other 136 additional information about a resource named using this scheme can 137 be provided using a query string. A companion specification 138 [I-D.hallambaker-decade-ni-params] describes specific values that can 139 be used in such query strings for these various purposes and other 140 extensions to this basic format specification. 142 In addition, we also define a ".well-known" URL equivalent, and a way 143 to include a hash as a segment of an HTTP URL, as well as a binary 144 format for use in protocols that require more compact names and a 145 human-speakable text form that could be used, e.g. for reading out 146 (parts of) the name over a voice connection. 148 Not all uses of these names require use of the full hash output - 149 truncated hashes can be safely used in some environments. For this 150 reason, we define a new IANA registry for hash functions to be used 151 with this specification so as not to mix strong and weak (truncated) 152 hash algorithms in other protocol registries. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 Syntax definitions in this memo are specified according to ABNF 159 [RFC5234]. 161 2. Hashes are what Count 163 This section contains basic considerations related to how we use hash 164 function outputs that are common to all formats. 166 When verifying whether two names refer to same object, an 167 implementation MUST only consider the digest algorithm and the digest 168 value, i.e., it MUST NOT consider other fields defined below (such as 169 an authority field from a URI or any parameters). Implementations 170 MUST consider two hashes identical, regardless of encoding, if the 171 decoded hashes are based on the same algorithm and have the same 172 length and the same binary value. In that case, the two names can be 173 treated as referring to the same thing. 175 The sha-256 algorithm as specified in [SHA-256] is mandatory to 176 implement, that is, implementations MUST be able to generate/send and 177 to accept/process names based on a sha-256 hash. However 178 implementations MAY support additional hash algorithms and MAY use 179 those for specific names, for example in a constrained environment 180 where sha-256 is non-optimal or where truncated names are needed to 181 fit into corresponding protocols (when a higher collision probability 182 can be tolerated). 184 Truncated hashes MAY be supported if needed. When a hash value is 185 truncated the name MUST indicate this. Therefore we use different 186 hash algorithm strings for these, such as sha-256-32 for a 32-bit 187 truncation of a sha-256 output. (A 32-bit truncated hash is 188 essentially useless for security but might be useful for naming.) 190 When a hash value is truncated to N bits the left-most N bits, that 191 is, the most significant N bits in network byte order, from the 192 binary representation of the hash value MUST be used as the truncated 193 value. An example of a 128-bit hash output truncated to 32 bits is 194 shown in Figure 2. 196 128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 197 32-bit truncated hash: 0x26535790 199 Figure 2: Example of Truncated Hash 201 When the input to the hash algorithm is a public key value, as may be 202 used by various security protocols, the hash SHOULD be calculated 203 over the public key in an X.509 SubjectPublicKeyInfo structure 204 (Section 4.1 of [RFC5280]). This input has been chosen primarily for 205 compatibility with DANE [I-D.ietf-dane-protocol], but also includes 206 any relevant public key parameters in the hash input, which is 207 sometimes necessary for security reasons. This does not force use of 208 X.509 or full compliance with [RFC5280] since formatting any public 209 key as a SubjectPublicKeyInfo is relatively straightforward and well 210 supported by libraries. 212 Any of the formats defined below can be used to represent the 213 resulting name for a public key. 215 Other than in the above special case where public keys are used, we 216 do not specify the hash function input here. Other specifications 217 are expected to define this. 219 3. Named Information (ni) URI Format 221 A Named Information (ni) URI consists of the following nine 222 components: 224 Scheme Name [Required] The scheme name is 'ni'. 226 Colon and Slashes [Required] The literal "://" 228 Authority [Optional] The optional authority component may assist 229 applications in accessing the object named by an ni URI. There is 230 no default value for the authority field. (See [RFC3986] Section 231 3.2.2 for details.) While ni names with and without an authority 232 differ syntactically from ni names with different authorities, all 233 three refer to the same object if and only if the digest 234 algorithm, length, and value are the same. 236 One slash [Required] The literal "/" 238 Digest Algorithm [Required] The name of the digest algorithm, as 239 specified in the IANA registry defined in Section 9.4 below. 241 Separator [Required] The literal ";" 243 Digest Value [Required] The digest value MUST be encoded using the 244 base64url [RFC4648] encoding. 246 Query Parameter separator [Optional] '?' The query parameter 247 separator acts as a separator between the digest value and the 248 query parameters (if specified). For compatibility with IRIs, 249 non-ASCII characters in the query part MUST be encoded as UTF-8, 250 and the resulting octets MUST be %-encoded (see [RFC3986] Section 251 2.1). 253 Query Parameters [Optional] A tag=value list of optional query 254 parameters as are used with HTTP URLs [RFC2616] with a separator 255 character '&' between each. For example, "foo=bar&baz=bat" 257 It is OPTIONAL for implementations to check the integrity of the URI/ 258 resource mapping when sending, receiving or processing "ni" URIs. 260 Escaping of characters follows the rules in RFC 3986. This means 261 that %-encoding is used to distinguish between reserved and 262 unreserved functions of the same character in the same URI component. 263 As an example, an ampersand ('&') is used in the query part to 264 separate attribute-value pairs; an ampersand in a value therefore has 265 to be escaped as '%26'. Note that the set of reserved characters 266 differs for each component, as an example, a slash ('/') does not 267 have any reserved function in a query part and therefore does not 268 have to be escaped. However, it can still appear escaped as '%2f' or 269 '%2F', and implementations have to be able to understand such escaped 270 forms. Also note that any characters outside those allowed in the 271 respective URI component have to be escaped. 273 The Named Information URI adapts the URI definition from the URI 274 Generic Syntax [RFC3986]. We start with the base URI production: 276 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 277 ; from RFC 3986 279 Figure 3: URI syntax 281 Adapting that for the Named Information URI: 283 NI-URI = ni-scheme ":" ni-hier-part [ "?" query ] 284 ; adapted from "URI" in RFC 3986 285 ; query is from RFC 3986, Section 3.4 286 ni-scheme = "ni" 287 ni-hier-part = "//" [ authority ] "/" alg-val 288 ; authority is from RFC 3986, Section 3.2 289 alg-val = alg ";" val 290 ; adapted from "hier-part" in RFC 3986 291 alg = 1*unreserved 292 val = 1*unreserved 293 ; unreserved is from RFC3986, Section 2.3 295 Figure 4: ni Name syntax 297 The "val" field MUST contain the output of base64url encoding the 298 result of applying the hash function ("alg") to its defined input, 299 which defaults to the object bytes that are expected to be returned 300 when the URI is dereferenced. 302 Relative ni URIs can occur. In such cases, the algorithm in 303 [RFC3986] Section 5 applies. As an example, in Figure 5, the 304 absolute URI for "this third document" is 305 "ni://example.com/sha-256-128;...". 307 308 309 ni: relative URI test 310 311 313 314

Please check this document. 315 and this other document. 316 and this third document. 317

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