idnits 2.17.1 draft-farrell-decade-ni-00.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 (October 24, 2011) is 4539 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 156, but not defined == Missing Reference: 'Optional' is mentioned on line 163, but not defined ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: April 26, 2012 NEC 6 C. Dannewitz 7 University of Paderborn 8 B. Ohlman 9 Ericsson 10 P. Hallam-Baker 11 Comodo Group Inc. 12 October 24, 2011 14 The Named Information (ni) URI Scheme: Core Syntax 15 draft-farrell-decade-ni-00 17 Abstract 19 This document defines a URI-based name form that identifies a named 20 object via hash-based binding. The URI name form defined is intended 21 for use in applications that need to uniquely identify resources in a 22 location-independent way such as accessing in-network storage 23 (DECADE), information-centric networking and more generally. The 24 format is designed to support a strong link to the referenced object 25 such that the referenced object may be authenticated to the same 26 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 April 26, 2012. 45 Copyright Notice 47 Copyright (c) 2011 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. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Processing NI URIs . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Verifying URI/Resource Mappings . . . . . . . . . . . . . 4 63 3.2. Testing for Equality . . . . . . . . . . . . . . . . . . . 5 64 3.3. Mapping to HTTP(S) URLs . . . . . . . . . . . . . . . . . 5 65 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. The Named Information URI TYPE . . . . . . . . . . . . . . . . 6 67 5.1. Encoding Considerations . . . . . . . . . . . . . . . . . 6 68 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Assignment of Network Information (ni) URI Scheme . . . . 8 73 8.2. Assignment of Well Known URI prefix ni . . . . . . . . . . 9 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 URIs [RFC3986] are used in various protocols for identifying 82 resources. In many deployments those URIs contain strings that are 83 hash function outputs in order to ensure uniqueness in terms of 84 mapping the URI to a specific resource, or to make URIs hard to guess 85 for security reasons. However, there is no standard way to interpret 86 those strings, and so today in general only the creator of the URI 87 knows how to use the hash function output. 89 For example, protocols for accessing in-network storage servers (as 90 defined in the IETF DECADE WG) need a way to identify the stored 91 resources uniquely and in a location-independent way so that replicas 92 on different servers can be accessed by the same name. Also, such 93 applications may require verifying that a resource that has been 94 obtained actually corresponds to the name that was used to request 95 the resource, i.e., verifying the name-content binding. 97 Similarly, in the context of information-centric networking 98 [ref.netinf-design] [ref.ccn] and elsewhere there is value in being 99 able to compare a presented resource against the URI that was de- 100 referenced in order to access that resource. If a cryptographically- 101 strong comparison function can be used then this allows for many 102 forms of in-network storage, without requiring as much trust in the 103 infrastructure used to present the resource. The outputs of hash 104 functions can be used in this manner, if presented in a standard way. 106 Additional applications might include creating references from web 107 pages delivered over HTTP/TLS; DNS resource records signed using 108 DNSSEC or Data values embedded in certificates, CRLs, OCSP tokens and 109 other signed data objects. 111 Accordingly, the "ni" URI scheme allows for checking of the integrity 112 of the URI/resource mapping, but it is OPTIONAL for implementations 113 to do so when sending, receiving or processing "ni" URIs. 115 The URI scheme defined here allows for the use of a query-string, 116 simiilar to how query-strings are used in HTTP URLs. A companion 117 specification [niexts] describes specific values that can be used in 118 such query strings in for various purposese. That document also 119 specifies additional optional algorithms for truncated hashes and for 120 hashing of dynamic objects. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 Syntax definitions in this memo are specified according to ABNF 128 [RFC4648]. 130 [[Comments are included in double-square brackets, like this.]] 132 2. Format 134 In this section we provide an informal description of the ni name 135 syntax. An ni URI consists of the following components: 137 Scheme Name [Required] The scheme name is 'ni'. 139 Colon and Slashes [Required] The literal "://" 141 Authority [Optional] The optional authority component may assist 142 applications in accessing the object named by an ni URI. Note 143 that while the ni names with and without an authority differ 144 syntactically, both names will almost always refer to the same 145 object. 147 One slash [Required] The literal "/" 149 Digest Algorithm [Required] The name of the digest algorithm, as 150 specified in the IANA registry titled "Data Structure for the 151 Security Suitability of Cryptographic Algorithms registry 152 'Cryptographic Algorithms'" [RFC5698]. 154 Separator [Required] The literal ";" 156 Digest Value [Required] The digest value encoded in the specified 157 encoding. The digest value MAY be trucated at a 64 byte boundary. 159 Query Parameter separator [Optional] '?' The query parameter 160 separator acts a separator between the digest value and the query 161 parameters (if specified). 163 Query Parameters [Optional] A tag=value list of optional query 164 parameters as are used with HTTP URLs. 166 3. Processing NI URIs 168 3.1. Verifying URI/Resource Mappings 170 It is OPTIONAL for implementations to check the integrity of the URI/ 171 resource mapping when sending, receiving or processing "ni" URIs. 173 3.2. Testing for Equality 175 When verifying whether two NI URIs refer to same object, an 176 implementation MUST only consider the Digest Algorithm identifier and 177 the Digest Value, i.e., it MUST NOT consider the authority field or 178 any parameters. 180 3.3. Mapping to HTTP(S) URLs 182 We define a bidirectional mapping between the ni URI scheme and a 183 subset of the the HTTP scheme that makes use of the .well-known URI 184 [RFC5785] by defining an "ni" suffix (see Section 8). 186 The HTTP(s) mapping MAY be used in any context where legacy clients 187 without support for ni indentifiers is required without loss of 188 interoperability or functionality. A legacy client interprets the ni 189 identifier as an ordinary HTTP(s) URL while a ni aware client can 190 determine the corresponding ni form of the URI and apply ni 191 processing. 193 Implementations SHOULD support this mapping, in both directions. 194 [[Not sure if we really want 2119 language for the mapping, nor if we 195 need to specify both directions, so this is kind of a placeholder.]] 197 For an ni name of the form "ni://n-authority/alg;val?query-string" 198 the corresponding HTTP URL produced by this algorithm is 199 "http://h-authority/.well-known/ni/alg/val?query-string". If the ni 200 name has a specified authority then the h-authority MUST have the 201 same value. If the ni name has no authority specified (i.e. the 202 n-authority string is empty), a h-authority value MAY be derived from 203 the applicaiton context. For example, if the mapping is being done 204 in the context of a web page then the origin [websec-origin] for that 205 web site can be used. Of course, there are in general no guarantees 206 that the object named by the ni name will be available at the 207 corresponding HTTP URL. But in the case that any data is returned, 208 the retreiver can determine if it is the correct content. 210 If an application is presented with a HTTP URL with "/.well- 211 known/ni/" as the start of its pathname component, then the reverse 212 mapping to an ni name either including or excluding the authority 213 might produce an ni name that is meaningful depending on the 214 application. 216 In all of the above the application MAY use the "https" URI scheme if 217 security considerations warrant use of TLS. 219 4. Examples 221 [[Note: check examples and make sure they're correct sometime.]] 223 The following digest URI specifies a reference to the text "Hello 224 World !" using the SHA-2 algorithm with 256 bit output and no 225 authority field: 227 ni:///sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 229 And the same example shown with an authority would be: 231 ni://example.com/sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 233 The following HTTP URL represents a mapping from the previous ni name 234 based on the algorithm outlined above. 236 http://example.com/.well-known/ni/sha-256/ 237 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 239 5. The Named Information URI TYPE 241 5.1. Encoding Considerations 243 [[Note that this section may change. However, the intent is that 244 there be one and only one well defined encoding scheme for ni names. 245 However, getting the right scheme for that, and for the URL mapping 246 may be tricky.]] 248 The digest value MUST be encoded using base64url [RFC4648] encoding. 250 The query segment of an URI is NOT hierarchical. Thus escape 251 encoding of slash '/' characters is NOT required. Since application 252 code often attempts to enforce such encoding, decoders MUST recognize 253 the use of URI escape encoding. Section 3.4 of [RFC3986] states that 254 "The characters slash ("/") and question mark ("?") may represent 255 data within the query component." 257 Consequently no special escaping mechanism is required for the query 258 parameter portion of ni URIs. URI escaping is however frequently 259 imposed automatically by scripting environments. Thus to ensure 260 interoperability, implementations SHOULD NOT generate URIs that 261 employ URI character escaping, and implementations MUST accept any 262 URIs that employ URI character escaping. [[That might need to be 263 more specific.]] 265 5.2. Syntax 267 The Named Information URI has the following syntax: 269 niname ="ni://" [ authority ] "/" alg ";" val [ "?" query ] 270 alg = 1*CHAR 271 val = 1*CHAR 273 Figure 1: ni Name syntax 275 The "authority" and "query" types are as in the URI specification. 276 [RFC3986] 278 Implementations MUST support the sha-256 algorithm as specified in 279 [RFC4055]. 281 Implementations MAY support other algorithms specified in the Data 282 Structure for the Security Suitability of Cryptographic Algorithms 283 registry 'Cryptographic Algorithms' [RFC5698]. 285 Note that additional algorithms are specified in the companion 286 document to this one [niexts] that implementations can choose to 287 support if they wish. Those algorithms use a different IANA registry 288 defined in that document. 290 The "val" field MUST contain the output of applying the hash function 291 ("alg") to its defined input, which defaults to the object bytes that 292 are expected to be returned when the URI is de-referenced. 294 6. Security Considerations 296 No secret information is required to generate or verify an ni URI. 297 Therefore an ni URI only provides a proof of integrity for the 298 referenced object and the proof of integrity provided is only as good 299 as the proof of integrity for the ni URI. In other words, the digest 300 value can provide name-data integrity binding the ni name value to 301 the object bytes returned when the ni name is de-referenced using 302 some protocol. 304 Disclosure of an ni URI value does not necessarily entail disclosure 305 of the referenced object but may enable an attacker to determine the 306 contents of the referenced object by reference to a search engine or 307 other data repository or, for highly formatted object with little 308 variation, by simply guessing the value and checking if the digest 309 value matches. 311 The integrity of the referenced content would be compromised if a 312 weak digest were used. 314 If a truncated digest is used, certain security properties MAY be 315 affected. In general a digest algorithm is designed to produce 316 sufficient bits to prevent a 'birthday attac' collision occuring. To 317 ensure that the difficulty of discovering two pieces of content that 318 result in the same digest with a work factor O(2^x) by brute force 319 requires a digest length of 2x. Many security applications only 320 require protection against a 2nd pre-image attack which only requires 321 a digest length of x to achieve the same work factor. 323 [[Don't reduce too much, and don't rely on a digest that has been 324 truncated as being the strength of the original digest alg.]] 326 7. Acknowledgements 328 This work has been supported by the EU FP7 project SAIL. The authors 329 would like to thank SAIL participants to our naming discussions, 330 especially Jean-Francois Peltier, for their input. 332 [[Mention folk on the WebSec list who contributed to the 333 discussions]] 335 8. IANA Considerations 337 8.1. Assignment of Network Information (ni) URI Scheme 339 The procedures for registration of a URI scheme are specified in RFC 340 4395 [RFC4395]. The following is the proposed assignment template. 342 URI scheme name: ni 344 Status: Permanent 346 URI scheme syntax. See Section 5.2 348 URI scheme semantics. See Section 5.2 350 Encoding considerations. See Section 5.1 352 Applications/protocols that use this URI scheme name: General 353 applicability with initial use cases provided by WEBSEC and DECADE 355 Interoperability considerations: TBS 357 Security considerations: See Section 6 358 Contact: TBD 360 Author/Change controller: IETF 362 References: As specified in this document 364 8.2. Assignment of Well Known URI prefix ni 366 The procedures for registration of a Well Known URI entry are 367 specified in RFC 5785 [RFC5785]. The following is the proposed 368 assignment template. 370 URI suffix: ni 372 Change controller: IETF 374 Specification document(s): This document 376 Related information: None 378 9. References 380 9.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 386 Resource Identifier (URI): Generic Syntax", STD 66, 387 RFC 3986, January 2005. 389 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 390 Algorithms and Identifiers for RSA Cryptography for use in 391 the Internet X.509 Public Key Infrastructure Certificate 392 and Certificate Revocation List (CRL) Profile", RFC 4055, 393 June 2005. 395 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 396 Registration Procedures for New URI Schemes", BCP 35, 397 RFC 4395, February 2006. 399 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 400 Encodings", RFC 4648, October 2006. 402 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure 403 for the Security Suitability of Cryptographic Algorithms 404 (DSSC)", RFC 5698, November 2009. 406 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 407 Uniform Resource Identifiers (URIs)", RFC 5785, 408 April 2010. 410 9.2. Informative References 412 [niexts] Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, 413 C., and B. Ohlman, "The Network Information (ni) URI 414 Scheme: Parameters", draft-hallambaker-decade-ni-params-00 415 (work in progress), October 2011. 417 [ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content", 418 CoNEXT 2009 , December 2009. 420 [ref.netinf-design] 421 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 422 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 423 Considerations for a Network of Information", Re-Arch 2008 424 Workshop , December 2008. 426 [websec-origin] 427 Barth, A., "The Web Origin Concept", 428 draft-ietf-websec-origin-06 (work in progress), 429 October 2011. 431 Authors' Addresses 433 Stephen Farrell 434 Trinity College Dublin 435 Dublin, 2 436 Ireland 438 Phone: +353-1-896-2354 439 Email: stephen.farrell@cs.tcd.ie 441 Dirk Kutscher 442 NEC 443 Kurfuersten-Anlage 36 444 Heidelberg, 445 Germany 447 Phone: 448 Email: kutscher@neclab.eu 449 Christian Dannewitz 450 University of Paderborn 451 Paderborn 452 Germany 454 Email: cdannewitz@upb.de 456 Borje Ohlman 457 Ericsson 458 Stockholm S-16480 459 Sweden 461 Email: Borje.Ohlman@ericsson.com 463 Phillip Hallam-Baker 464 Comodo Group Inc. 466 Email: philliph@comodo.com