idnits 2.17.1 draft-hallambaker-digesturi-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 3, 2011) is 4561 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: 'TBS' is mentioned on line 382, but not defined == Missing Reference: 'NIST-ALGS' is mentioned on line 435, but not defined == Missing Reference: 'RFC3642' is mentioned on line 439, but not defined == Unused Reference: 'RFC5280' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Hallam-Baker 3 Internet-Draft Comodo Group Inc. 4 Intended status: Standards Track R. Stradling 5 Expires: April 5, 2012 Comodo CA Ltd. 6 October 3, 2011 8 The di (DIGEST) URI Scheme 9 draft-hallambaker-digesturi-02 11 Abstract 13 A URI scheme for referencing static data abjects by means of a 14 cryptographic digest mechanism is specified. The format is designed 15 to resist content type substitution attacks and supports a choice of 16 digest algorithms. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 5, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Examples of Use . . . . . . . . . . . . . . . . . . . . . 3 57 2.1.1. Simple Digest . . . . . . . . . . . . . . . . . . . . 3 58 2.1.2. Truncated Digest . . . . . . . . . . . . . . . . . . . 3 59 2.1.3. Digest with Meta-Data . . . . . . . . . . . . . . . . 4 60 2.1.4. Digest with Locator . . . . . . . . . . . . . . . . . 4 61 2.1.5. Digest with Decryption Key . . . . . . . . . . . . . . 4 62 3. The di (DIGEST) URI TYPE . . . . . . . . . . . . . . . . . . . 5 63 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1.1. Encoding Considerations . . . . . . . . . . . . . . . 5 65 3.1.1.1. Use of base64url Encoding . . . . . . . . . . . . 5 66 3.1.1.2. Query Parameter Encoding . . . . . . . . . . . . . 5 67 3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2.1. Digest Algorithms . . . . . . . . . . . . . . . . . . 5 69 3.2.2. Parameters . . . . . . . . . . . . . . . . . . . . . . 6 70 3.2.2.1. Content Type (ct) . . . . . . . . . . . . . . . . 6 71 3.2.2.2. HTTP Locator (http & https) . . . . . . . . . . . 6 72 3.2.2.3. Encryption and MIME Encryption Specifiers (enc 73 & menc) . . . . . . . . . . . . . . . . . . . . . 6 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 4.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 77 4.3. Weak Digest Algorithm . . . . . . . . . . . . . . . . . . 7 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 5.1. Assignment of URI Scheme di . . . . . . . . . . . . . . . 8 80 5.2. Assignment of Well Known URI prefix di . . . . . . . . . . 8 81 5.3. Specification of Additional Cryptographic Algorithms . . . 8 82 5.4. Creation of di parameter registry . . . . . . . . . . . . 9 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 85 6.2. Non Normative References . . . . . . . . . . . . . . . . . 10 86 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 87 A.1. Example: Hello World ! . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Definitions 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 1.2. Defined Terms 100 The following terms are used in this document: 102 URI 104 2. Requirements 106 Provides a strong reference to a static data object. 108 Does not provide a means of resolution. 110 Allows an authenticated data source to provide an authenticated 111 reference to a static data object. 113 Intended applications include creating references from 115 Web pages delivered over HTTP/TLS 117 DNS resource records signed using DNSSEC 119 Data values embedded in certificates, CRLs, OCSP tokens and other 120 signed data objects. 122 2.1. Examples of Use 124 2.1.1. Simple Digest 126 For example, the following digest URI specifies a reference to the 127 text "Hello World !" using the SHA-2 algorithm with 256 bit output: 129 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 131 2.1.2. Truncated Digest 133 Message Digest algorithms are designed to provide protection against 134 a collision attack. Due to the birthday paradox, this requires that 135 the digest length be twice the length of a encryption or 136 authentication key to achieve the same work factor. 138 The digest portion MAY be truncated at any 32 bit boundary. If a 139 truncated digest is used the query separator '?' MUST be specified. 141 di:sha-256;B_K97zTtFuOhug27fke4_Q? 143 2.1.3. Digest with Meta-Data 145 The semantics of a digest being used to establish a secure reference 146 from an authenticated source to an external source may be a function 147 of associated meta data such as the content type. This data MAY be 148 specified by means of a parameter: 150 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain 152 2.1.4. Digest with Locator 154 A digest identifier MAY provide a location from which the referenced 155 content MAY be available. Note however that since it is 156 statistically unlikely that a given identifier will correspond to 157 more than one content sequence, the actual location from which the 158 data is retrieved is immaterial. 160 di:sha- 161 256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com 163 The corresponding content MAY be retrieved from the URL: 165 http://di.example.com/.well-known/di/sha-256/ 166 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 168 A digest identifier MAY specify multiple locations from which the 169 content MAY be obtained: 171 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? 172 http=one.example.com&http=two.example.com 174 Asserts that the content may be retrieved from either of the 175 following URIs: 177 http://one.example.com/.well-known/di/sha-256/ 178 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc http://two.example.com/ 179 .well-known/di/sha-256/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 181 2.1.5. Digest with Decryption Key 183 A digest identifier MAY provide a key for decrypting the referenced 184 data. 186 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? enc=aes- 187 cbc:Fw3x20nEKfq6FDGzq7ttIQ 189 3. The di (DIGEST) URI TYPE 191 3.1. Syntax 193 The DIGEST URI Type has the following format: 195 "di:" algorithm ";" digest [ "?" tag "=" value [ "&" tag "=" value ] 196 * ] 198 3.1.1. Encoding Considerations 200 3.1.1.1. Use of base64url Encoding 202 Section 2.2 of [RFC4395] states [URI schemes that are not intended 203 for use with relative URIs SHOULD avoid use of the forward slash "/" 204 character, which is used for hierarchical delimiters, and the 205 complete path segments "." and ".." (dot-segments).] 207 Consequently the encoding of the digest value is effected using the 208 base64url encoding specified in Section 5 of [RFC4648] which avoids 209 the use of the forward slash '/' character. 211 3.1.1.2. Query Parameter Encoding 213 The query segment of a URI is NOT hierarchical. Thus escape encoding 214 of slash '/' characters is NOT required. 216 Section 3.4 of [RFC3986] states [The characters slash ("/") and 217 question mark ("?") may represent data within the query component.] 219 Consequently no special escaping mechanism is required for the query 220 parameter portion of the URI. URI escaping is however frequently 221 imposed automatically by scripting environments. Thus to ensure 222 interoperability, implementations SHOULD NOT generate URIs that 223 employ URI character escaping and implementations MUST accept and 224 URIs that employ URI character escaping. 226 3.2. Semantics 228 3.2.1. Digest Algorithms 230 Implementations MUST support the sha-256 algorithm as specified in 231 [RFC4055]. 233 Implementations MAY support other algorithms specified in the Data 234 Structure for the Security Suitability of Cryptographic Algorithms 235 registry 'Cryptographic Algorithms' [RFC5698]. 237 3.2.2. Parameters 239 3.2.2.1. Content Type (ct) 241 The Content Type "ct" parameter specifies the MIME Content Type of 242 the associated data as defined in [RFC4288] 244 3.2.2.2. HTTP Locator (http & https) 246 The http and https parameters are used to specify a possible means of 247 resolving the referenced content. Mulltiple locator parameters MAY 248 be used to specify alternative sources for accessing the content. 250 The http and https parameters take a single argument, the domain name 251 to be used for resolution. To permit the use of digest URIs in 252 ASCII-only environments, the ASCII encoding (aka punycode) of the 253 domain name MUST be used. 255 To resolve such a location reference, a client first transforms the 256 digest URI to obtain a http or https url as follows: 258 URL = prefix + domain + "/.well-known/di/" + algorithm + digest 260 Where: 262 prefix Is the string "http://" for the http parameter type and is 263 the string "https://" for the https parameter type. 265 domain Is the value associated with the parameter. 267 algorithm Is the algorithm portion of the digest URI. 269 digest Is the digest portion of the digest URI. 271 Implementations MUST NOT disclose any other data. In particular 272 implementations MUST NOT disclose the query parameter portion of the 273 URI. 275 3.2.2.3. Encryption and MIME Encryption Specifiers (enc & menc) 277 The encryption and MIME encryption specifiers are used to provide a 278 means of obtaining the plaintext of a reference to encrypted content. 280 The enc specifier is used when the encrypted object consists of the 281 encrypted content alone. The menc spcifier is used when the 282 encrypted object consists of a MIME header containing metadata 283 followed by the binary object encoding. 285 The encryption specifiers both take an agrument of the form: 287 algorithm ":" base64url (key) [":" base64url (iv)] 289 Where 291 algorithm Is the algorithm used to encrypt the associated content 293 key Is the value of the cryptographic key 295 iv (optional) Is the value of the cryptographic Initialization 296 Vector. 298 If the IV is not spcified for a block cipher mode that requires 299 one, the IV MUST be prepended to the encrypted content. 301 [Actually the IV does not provide any additional security for this 302 application but explaining the reason would be more effort than it 303 is worth and what I really care about is saving bytes in the 304 identifier, not the resulting data package.] 306 4. Security Considerations 308 4.1. Integrity 310 No secret information is required to generate a DIGEST URI. 311 Therefore a DIGEST URI only provides a proof of integrity for the 312 referenced object and the proof of integrity provided is only as good 313 as the proof of integrity for the DIGEST URI value. 315 4.2. Confidentiality 317 Disclosure of a DIGEST URI value does not necessarily entail 318 disclosure of the referenced object but may enable an attacker to 319 determine the contents of the referenced object by reference to a 320 search engine or other data repository. 322 4.3. Weak Digest Algorithm 324 [The digest algorithm MUST be strong] 326 [For most use cases collision resistance is a requirement] 328 5. IANA Considerations 330 5.1. Assignment of URI Scheme di 332 The procedures for registration of a URI scheme are specified in RFC 333 4395 [RFC4395]. The following is the proposed assignment template. 335 URI scheme name: di 337 Status: Permanent 339 URI scheme syntax. See Section 3.1 341 URI scheme semantics. See Section 3.2 343 Encoding considerations. See Section 3.1.1 345 Applications/protocols that use this URI scheme name: General 346 applicability with initial use cases provided by WEBSEC and DECADE 348 Interoperability considerations: TBS 350 Security considerations: See Section 4 352 Contact: IETF / Phillip Hallam-Baker 354 Author/Change controller: IETF / Phillip Hallam-Baker 356 References: As specified in this document 358 5.2. Assignment of Well Known URI prefix di 360 The procedures for registration of a Well Known URI entry are 361 specified in RFC 5785 [RFC5785]. The following is the proposed 362 assignment template. 364 URI suffix: di 366 Change controller: IETF 368 Specification document(s): This document 370 Related information: None 372 5.3. Specification of Additional Cryptographic Algorithms 374 [Added in case it is decided to specify truncated forms of the 375 cryptographic digests] 376 The procedures for registration of a Cryptographic Algorithm 377 identifier are specified in RFC 5698 [RFC5698]. The following is the 378 proposed assignment template. 380 Textual name of the algorithm: SHA-128 382 OID of the algorithm: [TBS] 384 Reference: This document. 386 5.4. Creation of di parameter registry 388 This specification creates a new IANA registry entitled "DI URI 389 Parameter Definitions". 391 The policy for future assignments to the registry is "RFC Required". 393 6. References 395 6.1. Normative References 397 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 398 Requirement Levels", BCP 14, RFC 2119, March 1997. 400 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 401 Resource Identifier (URI): Generic Syntax", STD 66, 402 RFC 3986, January 2005. 404 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 405 Algorithms and Identifiers for RSA Cryptography for use in 406 the Internet X.509 Public Key Infrastructure Certificate 407 and Certificate Revocation List (CRL) Profile", RFC 4055, 408 June 2005. 410 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 411 Registration Procedures", BCP 13, RFC 4288, December 2005. 413 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 414 Registration Procedures for New URI Schemes", BCP 35, 415 RFC 4395, February 2006. 417 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 418 Encodings", RFC 4648, October 2006. 420 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 421 Housley, R., and W. Polk, "Internet X.509 Public Key 422 Infrastructure Certificate and Certificate Revocation List 423 (CRL) Profile", RFC 5280, May 2008. 425 [RFC5698] Kunz, T., Okunick, S., and U. Pordesch, "Data Structure 426 for the Security Suitability of Cryptographic Algorithms 427 (DSSC)", RFC 5698, November 2009. 429 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 430 Uniform Resource Identifiers (URIs)", RFC 5785, 431 April 2010. 433 6.2. Non Normative References 435 [NIST-ALGS] 436 National Institute of Standards and Technology, 437 "Cryptographic Algorithm Registration", March 2009. 439 [RFC3642] Legg, S., "Common Elements of Generic String Encoding 440 Rules (GSER) Encodings", RFC 3642, October 2003. 442 Appendix A. Test Vectors 444 A.1. Example: Hello World ! 446 The Digest URI of the text file "Hello World !" is computed as 447 follows: 449 Scheme "di" 451 Algorithm Identifier: "sha-256" 453 sha-256 ("Hello World !") " 07 f2 bd ef 34 ed 16 e3 a1 ba 0d bb 7e 454 47 b8 fd 98 1c e0 cc b3 e1 bf e5 64 d8 2c 42 3c ba 7e 47 " 456 BASE64URI (sha-256 ("Hello World !")): " 457 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc " 459 Content Type Parameter 'text/plain' "ct=text/plain" 461 Depending on the context, the digest URI MAY be specified using the 462 digest value alone or the digest value plus content type parameter: 464 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 466 di:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain 468 Authors' Addresses 470 Phillip Hallam-Baker 471 Comodo Group Inc. 473 Email: philliph@comodo.com 475 Rob Stradling 476 Comodo CA Ltd. 478 Email: rob.stradling@comodo.com