idnits 2.17.1 draft-farrell-decade-ni-09.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 (July 5, 2012) is 4307 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 247, but not defined == Missing Reference: 'Optional' is mentioned on line 257, but not defined == Missing Reference: 'RFC-THIS' is mentioned on line 785, 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 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-10 -- 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 (==), 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: January 6, 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 July 5, 2012 15 Naming Things with Hashes 16 draft-farrell-decade-ni-09 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 January 6, 2013. 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 . . . . . . . . . . . . . . 6 62 3.1. Content Type Query String Attribute . . . . . . . . . . . 8 63 4. .well-known URI . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 10 66 7. Human-speakable (nih) URI Format . . . . . . . . . . . . . . . 11 67 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Hello World! . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.2. Public Key Examples . . . . . . . . . . . . . . . . . . . 13 70 8.3. nih Usage Example . . . . . . . . . . . . . . . . . . . . 14 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 72 9.1. Assignment of ni URI Scheme . . . . . . . . . . . . . . . 15 73 9.2. Assignment of nih URI Scheme . . . . . . . . . . . . . . . 15 74 9.3. Assignment of .well-known 'ni' URI . . . . . . . . . . . . 16 75 9.4. Creation of ni Hash Algorithm Registry . . . . . . . . . . 16 76 9.5. Creation of ni Parameter Registry . . . . . . . . . . . . 17 77 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 79 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 81 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 84 1. Introduction 86 Names or identifiers are used in various protocols for identifying 87 resources. In many scenarios those names or identifiers contain 88 values that are hash function outputs. However, different 89 deployments have chosen various different ways to include hash 90 function outputs in such names or identifiers. This document 91 specifies standard ways to do that to aid interoperability. We begin 92 with a few example uses for the various ways to include a hash in a 93 name as they are defined later in this document, for example Figure 1 94 shows an example of the "Named Information" (ni) URI scheme defined 95 here. 97 ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q 99 Figure 1: Example ni URI 101 Hash function outputs can be used to ensure uniqueness in terms of 102 mapping URIs [RFC3986] to a specific resource, or to make URIs hard 103 to guess for security reasons. Since there is no standard way to 104 interpret those strings, today in general only the creator of the URI 105 knows how to use the hash function output. Other protocols, such as 106 application layer protocols for accessing "smart objects" in 107 constrained environments also require more compact (e.g., binary) 108 forms of such identifiers. In yet other situations people may have 109 to speak such values, e.g., in a voice call, (see Section 8.3), in 110 order to confirm the presence or absence of a resource. 112 As another example, protocols for accessing in-network storage 113 servers need a way to identify stored resources uniquely and in a 114 location-independent way so that replicas on different servers can be 115 accessed by the same name. Also, such applications may require 116 verification that a resource representation that has been obtained 117 actually corresponds to the name that was used to request the 118 resource, i.e., verifying the binding between the data and the name, 119 which is here termed name-data integrity. 121 Similarly, in the context of information-centric networking 122 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 123 able to compare a presented resource against the URI that was 124 dereferenced in order to access that resource. If a 125 cryptographically-strong comparison function can be used then this 126 allows for many forms of in-network storage, without requiring as 127 much trust in the infrastructure used to present the resource. The 128 outputs of hash functions can be used in this manner, if presented in 129 a standard way. 131 Additional applications might include creating references from web 132 pages delivered over HTTP/TLS; DNS resource records signed using 133 DNSSEC or data values embedded in certificates, Certificate 134 Revocation Lists (CRLs), or other signed data objects. 136 The "ni" URI scheme defined here is very similar to the "magnet link" 137 informally defined in various other protocols. [magnet] 139 Media content-type, alternative locations for retrieval and other 140 additional information about a resource named using this scheme can 141 be provided using a query string. A companion specification 142 [I-D.hallambaker-decade-ni-params] describes specific values that can 143 be used in such query strings for these various purposes and other 144 extensions to this basic format specification. 146 In addition, we also define a ".well-known" URL equivalent, and a way 147 to include a hash as a segment of an HTTP URL, as well as a binary 148 format for use in protocols that require more compact names and a 149 human-speakable text form that could be used, e.g. for reading out 150 (parts of) the name over a voice connection. 152 Not all uses of these names require use of the full hash output - 153 truncated hashes can be safely used in some environments. For this 154 reason, we define a new IANA registry for hash functions to be used 155 with this specification so as not to mix strong and weak (truncated) 156 hash algorithms in other protocol registries. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 Syntax definitions in this memo are specified according to ABNF 163 [RFC5234]. 165 2. Hashes are what Count 167 This section contains basic considerations related to how we use hash 168 function outputs that are common to all formats. 170 When comparing two names of the form defined here, an implementation 171 MUST only consider the digest algorithm and the digest value, i.e., 172 it MUST NOT consider other fields defined below (such as an authority 173 field from a URI or any parameters). Implementations MUST consider 174 two hashes identical, regardless of encoding, if the decoded hashes 175 are based on the same algorithm and have the same length and the same 176 binary value. In that case, the two names can be treated as 177 referring to the same thing. 179 The sha-256 algorithm as specified in [SHA-256] is mandatory to 180 implement, that is, implementations MUST be able to generate/send and 181 to accept/process names based on a sha-256 hash. However 182 implementations MAY support additional hash algorithms and MAY use 183 those for specific names, for example in a constrained environment 184 where sha-256 is non-optimal or where truncated names are needed to 185 fit into corresponding protocols (when a higher collision probability 186 can be tolerated). 188 Truncated hashes MAY be supported if needed. When a hash value is 189 truncated the name MUST indicate this. Therefore we use different 190 hash algorithm strings for these, such as sha-256-32 for a 32-bit 191 truncation of a sha-256 output. (A 32-bit truncated hash is 192 essentially useless for security but might be useful for naming.) 194 When a hash value is truncated to N bits the left-most N bits, that 195 is, the most significant N bits in network byte order, from the 196 binary representation of the hash value MUST be used as the truncated 197 value. An example of a 128-bit hash output truncated to 32 bits is 198 shown in Figure 2. 200 128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 201 32-bit truncated hash: 0x26535790 203 Figure 2: Example of Truncated Hash 205 When the input to the hash algorithm is a public key value, as may be 206 used by various security protocols, the hash SHOULD be calculated 207 over the public key in an X.509 SubjectPublicKeyInfo structure 208 (Section 4.1 of [RFC5280]). This input has been chosen primarily for 209 compatibility with DANE [I-D.ietf-dane-protocol], but also includes 210 any relevant public key parameters in the hash input, which is 211 sometimes necessary for security reasons. This does not force use of 212 X.509 or full compliance with [RFC5280] since formatting any public 213 key as a SubjectPublicKeyInfo is relatively straightforward and well 214 supported by libraries. 216 Any of the formats defined below can be used to represent the 217 resulting name for a public key. 219 Other than in the above special case where public keys are used, we 220 do not specify the hash function input here. Other specifications 221 are expected to define this. 223 3. Named Information (ni) URI Format 225 A Named Information (ni) URI consists of the following nine 226 components: 228 Scheme Name [Required] The scheme name is 'ni'. 230 Colon and Slashes [Required] The literal "://" 232 Authority [Optional] The optional authority component may assist 233 applications in accessing the object named by an ni URI. There is 234 no default value for the authority field. (See [RFC3986] Section 235 3.2.2 for details.) While ni names with and without an authority 236 differ syntactically from ni names with different authorities, all 237 three refer to the same object if and only if the digest 238 algorithm, length, and value are the same. 240 One slash [Required] The literal "/" 242 Digest Algorithm [Required] The name of the digest algorithm, as 243 specified in the IANA registry defined in Section 9.4 below. 245 Separator [Required] The literal ";" 247 Digest Value [Required] The digest value MUST be encoded using the 248 base64url [RFC4648] encoding. 250 Query Parameter separator [Optional] '?' The query parameter 251 separator acts as a separator between the digest value and the 252 query parameters (if specified). For compatibility with IRIs, 253 non-ASCII characters in the query part MUST be encoded as UTF-8, 254 and the resulting octets MUST be %-encoded (see [RFC3986] Section 255 2.1). 257 Query Parameters [Optional] A tag=value list of optional query 258 parameters as are used with HTTP URLs [RFC2616] with a separator 259 character '&' between each. For example, "foo=bar&baz=bat" 261 It is OPTIONAL for implementations to check the integrity of the URI/ 262 resource mapping when sending, receiving or processing "ni" URIs. 264 Escaping of characters follows the rules in RFC 3986. This means 265 that %-encoding is used to distinguish between reserved and 266 unreserved functions of the same character in the same URI component. 267 As an example, an ampersand ('&') is used in the query part to 268 separate attribute-value pairs; an ampersand in a value therefore has 269 to be escaped as '%26'. Note that the set of reserved characters 270 differs for each component, as an example, a slash ('/') does not 271 have any reserved function in a query part and therefore does not 272 have to be escaped. However, it can still appear escaped as '%2f' or 273 '%2F', and implementations have to be able to understand such escaped 274 forms. Also note that any characters outside those allowed in the 275 respective URI component have to be escaped. 277 The Named Information URI adapts the URI definition from the URI 278 Generic Syntax [RFC3986]. We start with the base URI production: 280 URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 281 ; from RFC 3986 283 Figure 3: URI syntax 285 Adapting that for the Named Information URI: 287 NI-URI = ni-scheme ":" ni-hier-part [ "?" query ] 288 ; adapted from "URI" in RFC 3986 289 ; query is from RFC 3986, Section 3.4 290 ni-scheme = "ni" 291 ni-hier-part = "//" [ authority ] "/" alg-val 292 ; authority is from RFC 3986, Section 3.2 293 alg-val = alg ";" val 294 ; adapted from "hier-part" in RFC 3986 295 alg = 1*unreserved 296 val = 1*unreserved 297 ; unreserved is from RFC 3986, Section 2.3 299 Figure 4: ni Name syntax 301 The "val" field MUST contain the output of base64url encoding the 302 result of applying the hash function ("alg") to its defined input, 303 which defaults to the object bytes that are expected to be returned 304 when the URI is dereferenced. 306 Relative ni URIs can occur. In such cases, the algorithm in 307 [RFC3986] Section 5 applies. As an example, in Figure 5, the 308 absolute URI for "this third document" is 309 "ni://example.com/sha-256-128;...". 311 312 313 ni: relative URI test 314 315 317 318

Please check this document. 319 and this other document. 320 and this third document. 321

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