idnits 2.17.1 draft-farrell-decade-ni-03.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 (April 11, 2012) is 4391 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 227, but not defined == Missing Reference: 'Optional' is mentioned on line 234, but not defined ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-23) exists of draft-ietf-dane-protocol-18 -- 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: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: October 13, 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 April 11, 2012 15 Naming Things with Hashes 16 draft-farrell-decade-ni-03 18 Abstract 20 This document defines a set of ways to identify a thing using the 21 output from a hash function, specifying URI, URL, binary and human 22 "speakable" formats for these names. The various formats are 23 designed to support, but not require, a strong link to the referenced 24 object such that the referenced object may be authenticated to the 25 same degree as the reference to it. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Named Information (ni) URI Format . . . . . . . . . . . . . . 5 61 4. .well-known URL Format . . . . . . . . . . . . . . . . . . . . 7 62 5. URL Segment Format . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Binary Format . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. Human-readable Format . . . . . . . . . . . . . . . . . . . . 9 65 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9.1. Assignment of Named Information (ni) URI Scheme . . . . . 12 68 9.2. Assignment of Named Information for Humans (nih) URI 69 Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.3. Assignment of Well Known URI prefix ni . . . . . . . . . . 13 71 9.4. Hash Name Algorithm Registry . . . . . . . . . . . . . . . 14 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 Names or identifiers are used in various protocols for identifying 82 resources. In many scenarios those names or identifiers contain 83 values that are hash function outputs. However, different 84 deployments have chosen various different ways to include hash 85 function outputs in such names or identifiers. This document 86 specifies standard ways to do that to aid interoperability. 88 Hash function outputs can be used to ensure uniqueness in terms of 89 mapping URIs [RFC3986] to a specific resource, or to make URIs hard 90 to guess for security reasons. Since, there is no standard way to 91 interpret those strings, today in general only the creator of the URI 92 knows how to use the hash function output. Other protocols, such as 93 application layer protocols for accessing "smart objects" in 94 constrained environments also require more compact (e.g., binary) 95 forms of such identifiers, while in other situations people may have 96 to input such values or talk about them, e.g., in a voice call. 98 As another example, protocols for accessing in-network storage 99 servers need a way to identify stored resources uniquely and in a 100 location-independent way so that replicas on different servers can be 101 accessed by the same name. Also, such applications may require 102 verifying that a resource representation that has been obtained 103 actually corresponds to the name that was used to request the 104 resource, i.e., verifying the name-content binding. 106 Similarly, in the context of information-centric networking 107 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 108 able to compare a presented resource against the URI that was 109 dereferenced in order to access that resource. If a 110 cryptographically-strong comparison function can be used then this 111 allows for many forms of in-network storage, without requiring as 112 much trust in the infrastructure used to present the resource. The 113 outputs of hash functions can be used in this manner, if presented in 114 a standard way. 116 Additional applications might include creating references from web 117 pages delivered over HTTP/TLS; DNS resource records signed using 118 DNSSEC or Data values embedded in certificates, Certificate 119 Revocation Lists (CRLs), or other signed data objects. 121 The new URI scheme defined here allows for the use of a query-string, 122 similar to how query-strings are used in HTTP URLs. A companion 123 specification [niexts] describes specific values that can be used in 124 such query strings for various purposes and other extensions to this 125 basic format specification. 127 The "ni" URI scheme defined here is very similar to the "magnet link" 128 informally defined in various other protocols. [magnet] 130 In addition to the URI form we also define a ".well-known" URL 131 equivalent, and a way to include a hash as a segment of an HTTP URL, 132 as well as a binary format for use in protocols that require more 133 compact names and a human-speakable text form that could be used, 134 e.g. for reading out (parts of) the name over a voice connection. 136 Not all uses of these names require use of the full hash output - 137 truncated hashes can be safely used in some environments. For this 138 reason, we define a new IANA registry for hash functions to be used 139 with this specification so as not to mix strong and weak hash 140 algorithms in other protocol registries. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 Syntax definitions in this memo are specified according to ABNF 147 [RFC5234]. 149 [[Comments are included in double-square brackets, like this.]] 151 2. Basics 153 This section contains basic considerations common to all formats. 155 When verifying whether two names refer to same object, an 156 implementation MUST only consider the digest algorithm identifier and 157 the digest value, i.e., it MUST NOT consider the authority field from 158 a URI or any parameters and MUST consider two hashes identical 159 regardless of encoding, if they encode the same binary value, and are 160 the same length. 162 The sha-256 algorithm as specified in [RFC4055] is mandatory to 163 implement, that is, implementations MUST be able to generate/send and 164 to accept/process names based on a sha-256 hash. However 165 implementations MAY support additional hash algorithms and MAY use 166 those for specific names, for example in a constrained environment 167 where sha-256 is non-optimal or where truncated names are needed to 168 fit into corresponding protocols (when a higher collision probability 169 can be tolerated). 171 Truncated hashes MAY be supported if needed. When a hash value is 172 truncated the name MUST indicate this. Therefore we use different 173 hash algorithm strings for these, such as sha-256-32 for a 32-bit 174 truncation of a sha-256 output. (Note that a 32-bit truncated hash 175 is essentially useless for security but might be useful for naming.) 177 When a hash value is truncated to N bits the left-most or most 178 significant in network byte order N bits from the binary 179 representation of the hash value MUST be used as the truncated value. 180 An example of a 128-bit hash output truncated to 32 bits is shown in 181 Figure 1. 183 128-bit hash: 0x265357902fe1b7e2a04b897c6025d7a2 184 32-bit truncated hash: 0x26535790 186 Figure 1: Example of Truncated Hash 188 When the input to the hash algorithm is a public key value, as may be 189 used by various security protocols, the hash SHOULD be calculated 190 over the public key in an X.509 SubjectPublicKeyInfo structure 191 (Section 4.1 of [RFC5280]). This input has been chosen primarily for 192 compatibility with DANE [I-D.ietf-dane-protocol], but also includes 193 any relevant public key parameters in the hash input, which is 194 sometimes necessary for security reasons. Note also that this does 195 not force use of X.509 or full compliance with [RFC5280] since 196 formatting any public key as a SubjectPublicKeyInfo is relatively 197 straightforward and well supported by libraries. 199 Any of the formats defined below can be used to represent the 200 resulting name for a public key. 202 Other than in the above special case where public keys are used, we 203 do not specify the hash function input here. Other specifications 204 are expected to define this. 206 3. Named Information (ni) URI Format 208 A Named Information (ni) URI consists of the following components: 210 Scheme Name [Required] The scheme name is 'ni'. 212 Colon and Slashes [Required] The literal "://" 214 Authority [Optional] The optional authority component may assist 215 applications in accessing the object named by an ni URI. Note 216 that while the ni names with and without an authority differ 217 syntactically, both names will almost always refer to the same 218 object. 220 One slash [Required] The literal "/" 222 Digest Algorithm [Required] The name of the digest algorithm, as 223 specified in the IANA registry defined in Section 9.4 below. 225 Separator [Required] The literal ";" 227 Digest Value [Required] The digest value encoded in the specified 228 encoding. 230 Query Parameter separator [Optional] '?' The query parameter 231 separator acts a separator between the digest value and the query 232 parameters (if specified). 234 Query Parameters [Optional] A tag=value list of optional query 235 parameters as are used with HTTP URLs. 237 It is OPTIONAL for implementations to check the integrity of the URI/ 238 resource mapping when sending, receiving or processing "ni" URIs. 240 The digest value MUST be encoded using base64url [RFC4648] encoding. 242 The query segment of an URI is NOT hierarchical. Thus escape 243 encoding of slash '/' characters is NOT required. Since application 244 code often attempts to enforce such encoding, decoders MUST recognize 245 the use of URI escape encoding (e.g., '%2f' or '%2F' for the slash 246 character). Section 3.4 of [RFC3986] states that "The characters 247 slash ("/") and question mark ("?") may represent data within the 248 query component." 250 [[The above is maybe ambiguous, 'cause we're not sure of what's 251 right. Is it better to say "decoders MUST treat %2f as /" or that 252 they MUST NOT do that, or that the world's a nasty place so you just 253 need to know when to do which?]] 255 Consequently no special escaping mechanism is required for the query 256 parameter portion of ni URIs. URI escaping is however frequently 257 imposed automatically by scripting environments. Thus to ensure 258 interoperability, implementations SHOULD NOT generate URIs that 259 employ URI character escaping, and implementations MUST NOT reject 260 any URIs that employ URI character escaping. 262 The Named Information URI has the following syntax: 264 niname ="ni://" [ authority ] "/" algval [ "?" query ] 265 algval = alg ";" val 266 alg = 1*unreserved 267 val = 1*unreserved 268 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 270 Figure 2: ni Name syntax 272 Note that "unreserved" is defined in the URI specification [RFC3986] 273 Section 2.3, in the way shown above. The "authority" and "query" 274 types are also from the URI specification. [RFC3986] 276 The "val" field MUST contain the output of applying the hash function 277 ("alg") to its defined input, which defaults to the object bytes that 278 are expected to be returned when the URI is dereferenced. 280 4. .well-known URL Format 282 We define a mapping between URIs following the ni URI scheme and HTTP 283 or HTTPS URLs that makes use of the .well-known URI [RFC5785] by 284 defining an "ni" suffix (see Section 9). 286 The HTTP(S) mapping MAY be used in any context where clients without 287 support for ni URIs are needed without loss of interoperability or 288 functionality. 290 For an ni name of the form "ni://n-authority/alg;val?query-string" 291 the corresponding HTTP(S) URL produced by this mapping is 292 "http://h-authority/.well-known/ni/alg/val?query-string", where 293 "h-authority" is derived as follows: If the ni name has a specified 294 authority (i.e., the n-authority is non-empty) then the h-authority 295 MUST have the same value. If the ni name has no authority specified 296 (i.e. the n-authority string is empty), a h-authority value MAY be 297 derived from the application context. For example, if the mapping is 298 being done in the context of a web page then the origin [RFC6454] for 299 that web site can be used. Of course, there are in general no 300 guarantees that the object named by the ni URI will be available at 301 the corresponding HTTP(S) URL. But in the case that any data is 302 returned, the retriever can determine whether or not it is content 303 that matches the ni URI. 305 If an application is presented with a HTTP(S) URL with "/.well- 306 known/ni/" as the start of its pathname component, then the reverse 307 mapping to an ni URI either including or excluding the authority 308 might produce an ni URI that is meaningful, but there is no guarantee 309 that this will be the case. 311 When mapping from a ni URI to a .well-known URL, an implementation 312 will have to decide between choosing an "http" or "https" URL. If 313 the object referenced does in fact match the hash in the URL, then 314 there is arguably no need for additional data integrity, if the ni 315 URI or .well-known URL was received "securely." However TLS also 316 provides confidentiality, so there may still be reasons to use the 317 "https" URL scheme even in this case. In general however, whether to 318 use "http" or "https" is something that needs to be decided by the 319 application. 321 5. URL Segment Format 323 Some applications may benefit from using hashes in existing HTTP URLs 324 or other URLs. To do this one simply uses the "algval" production 325 from the ni name scheme ABNF which may be included in the pathname 326 component of HTTP URLs. In such cases there is nothing present in 327 the URL that ensures that a client can depend on compliance with this 328 specification, so clients MUST NOT assume that any URL with a 329 pathname component that matches the "algval" production was in fact 330 produced as a result of this specification. That URL might or might 331 not be related to this specification, only the context will tell. 333 6. Binary Format 335 When a more space-efficient version of the name is needed, we can use 336 a binary format. The binary format name consists of two fields: a 337 header and the hash value. The header field defines how the 338 identifier has been created and the hash value contains a (possibly 339 truncated) result of a one-way hash over the whatever is being 340 identified by the hash value. The format of the binary 341 representation of a name is shown in Figure 3. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |Res| Suite ID | Hash Value / 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 / ... / 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 / ... | 351 +-+-+-+-+-+-+-+-+ 353 Figure 3: Binary Name Format 355 The Res field is a reserved 2-bit field for future use and MUST be 356 set to zero for this specification. 358 The hash algorithm and truncation length are specified by the Suite 359 ID. For maintaining efficient encoding for the binary presentation, 360 only a few hash algorithms and truncation lengths are supported. See 361 Section Section 9.4 for details. 363 Note that a hash value that is truncated to 120 bits will result in 364 the overall name being a 128-bit value which may be useful with 365 certain use-cases. 367 7. Human-readable Format 369 [[Comment on apps-discuss asked about using "ni:" for this, but might 370 be that then the abnf is too complex and easily confused, so I think 371 a different scheme is warranted here, so how about "nih"? Hard-to- 372 resist acronym anyway:-) ]] 374 Sometimes the name may need to be used in a format that is easy for 375 humans to read and possibly communicate, for example, over the phone. 376 For this purpose, the following more verbose but less ambiguous (when 377 spoken) URI format is defined with scheme name "nih," standing for 378 "Named Information for Humans," (or possibly jokingly for for "Not 379 Invented Here," which is clearly false, and therefore worth 380 including:-) 382 As with the ni URI format, nih URI fields are separated by a semi- 383 colon (;) character. The first field is a hash algorithm string, as 384 in the ni URI format. Then the hash value is encoded using base32 385 encoding [RFC4648] and lower-case alphabets. Since the length of the 386 hash value is known from the hash algorithm string, padding 387 characters are not needed and SHOULD NOT be used when the result of 388 the base32 encoding is used in the hash value field. When decoding 389 the base32-encoded string, only first N bits of the result, depending 390 on the truncation as indicated by the hash algorithm string, MUST be 391 used. 393 The hash value is OPTIONALLY followed by a checksum. The checksum 394 MUST be calculated as a crc16 over the following parts: the URI 395 scheme and separator ("nih:"), the algorithm string, the first 396 delimiter, (";") the base32 encoding of the hash value, and the 397 second delimiter (also ";"). The result of crc16 is encoded like the 398 hash value with base32 encoding and lower-case alphabets (only the 399 first 4 characters of the base32 encoded result are used to exclude 400 padding). 402 The crc16 MUST use the CRC-CCITT polynomial: x^16 + x^12 + x^5 + 1. 404 [[CCITT crc16 needs a proper reference]] 406 humanname = "nih: " algval [ ";" checksum ] 407 algval = alg ";" val 408 alg = 1*unreserved 409 val = 1*unreserved 410 checksum = 1*unreserved 412 Figure 4: Human-readable syntax 414 8. Examples 416 The following ni URI references the text "Hello World!" (without the 417 quotes, being 12 characters), using the SHA-2 algorithm with 256-bit 418 output and no authority field: 420 ni:///sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A 422 And the same example shown with an authority would be: 424 ni://example.com/sha-256;A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A 426 The following HTTP URL represents a mapping from the previous ni name 427 based on the algorithm outlined above. 429 http://example.com/.well-known/ni/sha-256/ 430 A7ogTlDRJuRnTABeBNguhMITZngK8fQ71Uo3gWtqs0A 432 Given the SubjectPublicKeyInfo in Figure 5 we derive the names shown 433 in Figure 6 for this value. 435 0000000 82 01 0a 02 82 01 01 00 a2 5f 83 da 9b d9 f1 7a 436 0000020 3a 36 67 ba fd 5a 94 0e cf 16 d5 5a 55 3a 5e d4 437 0000040 03 b1 65 8e 6d cf a3 b7 db a4 e7 cc 0f 52 c6 7d 438 0000060 35 1d c4 68 c2 bd 7b 9d db e4 0a d7 10 cd f9 53 439 0000100 20 ee 0d d7 56 6e 5b 7a ae 2c 5f 83 0a 19 3c 72 440 0000120 58 96 d6 86 e8 0e e6 94 eb 5c f2 90 3e f3 a8 8a 441 0000140 88 56 b6 cd 36 38 76 22 97 b1 6b 3c 9c 07 f3 4f 442 0000160 97 08 a1 bc 29 38 9b 81 06 2b 74 60 38 7a 93 2f 443 0000200 39 be 12 34 09 6e 0b 57 10 b7 a3 7b f2 c6 ee d6 444 0000220 c1 e5 ec ae c5 9c 83 14 f4 6b 58 e2 de f2 ff c9 445 0000240 77 07 e3 f3 4c 97 cf 1a 28 9e 38 a1 b3 93 41 75 446 0000260 a1 a4 76 3f 4d 78 d7 44 d6 1a e3 ce e2 5d c5 78 447 0000300 4c b5 31 22 2e c7 4b 8c 6f 56 78 5c a1 c4 c0 1d 448 0000320 ca e5 b9 44 d7 e9 90 9c bc ee b0 a2 b1 dc da 6d 449 0000340 a0 0f f6 ad 1e 2c 12 a2 a7 66 60 3e 36 d4 91 41 450 0000360 c2 f2 e7 69 39 2c 9d d2 df b5 a3 44 95 48 7c 87 451 0000400 64 89 dd bf 05 01 ee dd 02 03 01 00 01 452 0000415 454 0000000 c4 f6 dd 00 8f 7e b5 a0 95 cf 09 c5 8d d7 95 ba 455 0000020 1d 06 6c 11 50 cf 2a e3 d3 07 9b fa af e6 2b 1a 457 Figure 5: A SubjectPublicKeyInfo used in examples and its sha-256 458 hash 460 +-------------------------------------------------------------------+ 461 | URI: | 462 | ni:///sha-256;xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo | 463 +-------------------------------------------------------------------+ 464 | .well-known URL (split over 2 lines): | 465 | http://example.com/.well-known/ni/sha256/ | 466 | xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo | 467 +-------------------------------------------------------------------+ 468 | URL Segment: | 469 | sha-256;xPbdAI9-taCVzwnFjdeVuh0GbBFQzyrj0web-q_mKxo | 470 +-------------------------------------------------------------------+ 471 | Binary name (ASCII hex encoded) with 120-bit truncated hash value | 472 | which is Suite ID 0x03: | 473 | 03c4 f6dd 008f 7eb5 a095 cf09 c58d d795 | 474 +-------------------------------------------------------------------+ 475 | Human-readable form of a name for this key (truncated to 120 bits | 476 | in length) with checksum: | 477 | nih:sha-256-120;yt3n2aepp222bfopbhcy3v4v;ezcg | 478 +-------------------------------------------------------------------+ 479 | Human readable form of a name for this key (truncated to 32 bits | 480 | in length) with checksum: | 481 | nih:sha-256-32;yt3n2aa;moer | 482 +-------------------------------------------------------------------+ 484 Figure 6: Example Names 486 9. IANA Considerations 488 9.1. Assignment of Named Information (ni) URI Scheme 490 The procedures for registration of a URI scheme are specified in RFC 491 4395 [RFC4395]. The following is the proposed assignment template. 493 URI scheme name: ni 495 Status: Permanent 497 URI scheme syntax. See Section 3 499 URI scheme semantics. See Section 3 501 Encoding considerations. See Section 3 503 Applications/protocols that use this URI scheme name: General 504 applicability with initial use cases provided by CoAP and DECADE 506 Interoperability considerations: Defined here. 508 Security considerations: See Section 10 510 Contact: stephen.farrell@cs.tcd.ie 512 Author/Change controller: IETF 514 References: As specified in this document 516 9.2. Assignment of Named Information for Humans (nih) URI Scheme 518 The procedures for registration of a URI scheme are specified in RFC 519 4395 [RFC4395]. The following is the proposed assignment template. 521 URI scheme name: nih 523 Status: Permanent 525 URI scheme syntax. See Section 7 527 URI scheme semantics. See Section 7 529 Encoding considerations. See Section 7 531 Applications/protocols that use this URI scheme name: General 532 applicability with initial use cases provided by CoAP and DECADE 534 Interoperability considerations: Defined here. 536 Security considerations: See Section 10 538 Contact: stephen.farrell@cs.tcd.ie 540 Author/Change controller: IETF 542 References: As specified in this document 544 9.3. Assignment of Well Known URI prefix ni 546 The procedures for registration of a Well Known URI entry are 547 specified in RFC 5785 [RFC5785]. The following is the proposed 548 assignment template. 550 URI suffix: ni 552 Change controller: IETF 554 Specification document(s): This document 555 Related information: None 557 9.4. Hash Name Algorithm Registry 559 IANA is requested to create a new registry for hash algorithms as 560 used in the name formats specified here. This registry has four 561 fields, the binary suite ID, the hash algorithm name string, the 562 truncation length and the underlying algorithm reference. Future 563 assignments are to be made through expert review [RFC5226]. Initial 564 values are specified below. 566 Since there are only 63 possible binary suite ID field values allowed 567 by the binary format specified here, the suite ID field value is 568 OPTIONAL. Where the binary format is not expected to be used for a 569 given hash algorithm, this field SHOULD be omitted. 571 ID Hash name String Value length Reference 572 0 Reserved 573 1 sha-256 256 bits [RFC4055] 574 2 sha-256-128 128 bits [RFC4055] 575 3 sha-256-120 120 bits [RFC4055] 576 4 sha-256-96 96 bits [RFC4055] 577 5 sha-256-64 64 bits [RFC4055] 578 6 sha-256-32 32 bits [RFC4055] 579 32 Reserved 581 Figure 7: Suite Identifiers 583 The Suite ID value 32 is reserved for compatibility with ORCHIDs 584 [RFC4843]. The referenced hash algorithm matching to the Suite ID, 585 truncated to the length indicated, according to the description given 586 in Section 2, MUST be used for generating the hash. 588 [[Do we need sha-1 here? Its been asked for, but in a new standards 589 track spec is dodgy...]] 591 10. Security Considerations 593 No secret information is required to generate or verify a name of the 594 form described here. Therefore a name like this can only provide 595 evidence for the integrity for the referenced object and the proof of 596 integrity provided is only as good as the proof of integrity for the 597 name from which we started. In other words, the hash value can 598 provide a name-data integrity binding between the name and the bytes 599 returned when the name is de-referenced using some protocol. 601 Disclosure of a name value does not necessarily entail disclosure of 602 the referenced object but may enable an attacker to determine the 603 contents of the referenced object by reference to a search engine or 604 other data repository or, for a highly formatted object with little 605 variation, by simply guessing the value and checking if the digest 606 value matches. So the fact that these names contain hashes does not 607 necessarily protect the confidentiality of the object that was input 608 to the hash. 610 The integrity of the referenced content would be compromised if a 611 weak hash function were used. So don't use those. SHA-256 is 612 currently our preferred hash algorithm which is why we've only added 613 SHA-256 based suites to the initial IANA registry. 615 If a truncated hash value is used, certain security properties might 616 be affected. In general a hash algorithm is designed to produce 617 sufficient bits to prevent a 'birthday attack' collision occurring. 618 To ensure that the difficulty of discovering two pieces of content 619 that result in the same digest with a work factor O(2^x) by brute 620 force requires a digest length of 2x. Many security applications 621 only require protection against a 2nd pre-image attack which only 622 requires a digest length of x to achieve the same work factor. 623 Basically, the shorter the hash value used, the less security benefit 624 you can possibly get. 626 11. Acknowledgements 628 This work has been supported by the EU FP7 project SAIL. The authors 629 would like to thank SAIL participants to our naming discussions, 630 especially Jean-Francois Peltier, for their input. 632 The authors would also like to thank Bob Moskowitz, Tero Kivinen, 633 Zach Shelby, Carsten Bormann, David McGrew, Eric Rescorla, Tobias 634 Heer, Martin Thomas and James Manger for their comments and input to 635 the document. 637 12. References 639 12.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 645 Resource Identifier (URI): Generic Syntax", STD 66, 646 RFC 3986, January 2005. 648 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 649 Algorithms and Identifiers for RSA Cryptography for use in 650 the Internet X.509 Public Key Infrastructure Certificate 651 and Certificate Revocation List (CRL) Profile", RFC 4055, 652 June 2005. 654 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 655 Registration Procedures for New URI Schemes", BCP 35, 656 RFC 4395, February 2006. 658 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 659 Encodings", RFC 4648, October 2006. 661 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 662 Specifications: ABNF", STD 68, RFC 5234, January 2008. 664 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 665 Housley, R., and W. Polk, "Internet X.509 Public Key 666 Infrastructure Certificate and Certificate Revocation List 667 (CRL) Profile", RFC 5280, May 2008. 669 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 670 Uniform Resource Identifiers (URIs)", RFC 5785, 671 April 2010. 673 12.2. Informative References 675 [I-D.ietf-dane-protocol] 676 Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 677 of Named Entities (DANE) Protocol for Transport Layer 678 Security (TLS)", draft-ietf-dane-protocol-18 (work in 679 progress), March 2012. 681 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 682 for Overlay Routable Cryptographic Hash Identifiers 683 (ORCHID)", RFC 4843, April 2007. 685 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 686 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 687 May 2008. 689 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 690 December 2011. 692 [magnet] Wikipedia article, "Magnet URI Scheme", April 2012, 693 . 695 [niexts] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, 696 C., and B. Ohlman, "The Network Information (ni) URI 697 Scheme: Parameters", draft-hallambaker-decade-ni-params-01 698 (work in progress), April 2012. 700 [ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content", 701 CoNEXT 2009 , December 2009. 703 [ref.netinf-design] 704 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 705 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 706 Considerations for a Network of Information", Re-Arch 2008 707 Workshop , December 2008. 709 Authors' Addresses 711 Stephen Farrell 712 Trinity College Dublin 713 Dublin, 2 714 Ireland 716 Phone: +353-1-896-2354 717 Email: stephen.farrell@cs.tcd.ie 719 Dirk Kutscher 720 NEC 721 Kurfuersten-Anlage 36 722 Heidelberg, 723 Germany 725 Phone: 726 Email: kutscher@neclab.eu 728 Christian Dannewitz 729 University of Paderborn 730 Paderborn 731 Germany 733 Email: cdannewitz@upb.de 734 Borje Ohlman 735 Ericsson 736 Stockholm S-16480 737 Sweden 739 Email: Borje.Ohlman@ericsson.com 741 Ari Keranen 742 Ericsson 743 Jorvas 02420 744 Finland 746 Email: ari.keranen@ericsson.com 748 Phillip Hallam-Baker 749 Comodo Group Inc. 751 Email: philliph@comodo.com