idnits 2.17.1 draft-hallambaker-decade-ni-params-01.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: 'RFC-THIS' is mentioned on line 305, but not defined ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 2 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: October 13, 2012 Comodo CA Ltd. 6 S. Farrell 7 Trinity College Dublin 8 D. Kutscher 9 NEC 10 B. Ohlman 11 Ericsson 12 April 11, 2012 14 The Named Information (ni) URI Scheme: Parameters 15 draft-hallambaker-decade-ni-params-01 17 Abstract 19 This document specifies an additional hash algorithm and parameters 20 that may be used in the query string of ni URIs. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 13, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Additional Algorithm . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Hashed Dynamic Content . . . . . . . . . . . . . . . . . . 3 59 3. Query String Paramaeters . . . . . . . . . . . . . . . . . . . 4 60 3.1. Digest with Content Type . . . . . . . . . . . . . . . . . 4 61 3.2. Additional Locators . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Digest with Decryption Key . . . . . . . . . . . . . . . . 6 63 3.4. Wrapped URL . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Additional algorithm in RFCXXXX registry . . . . . . . . . 7 67 5.2. Creation of ni parameter registry . . . . . . . . . . . . . 7 68 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The ni URI scheme [nischeme] supports extensibility in terms of the 74 algorithm used to derive a value (normally, but not always a strong 75 digest algorithm) and via support for a query-string thay can contain 76 a list of key=value pairs. This document defines some uses for both 77 of these extensibility points and creates IANA registries that can be 78 used to register additional algorithms and key strings for use in the 79 query part of an ni name. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 [[Comments are included in double-square brackets, like this.]] 87 [[Note that the features here are less mature than the specification 88 in the [nischeme] document. The intent is to develop these as 89 required for the various use-cases as we go. If something from here 90 appears to be as widely useful as the core ni scheme, then the 91 authors are willing to move features from this document to the core 92 document. We are also happy to incoroporate features to handle 93 additional use-cases here if those arise.]] 95 2. Additional Algorithm 97 This section specifies an additional algorithm that MAY be used to 98 handle hashes calculated over dynamically changing objects. 100 2.1. Hashed Dynamic Content 102 The ni scheme involves calculating digest values over content 103 objects. That works fine with static objects but is problematic for 104 objects whose value is dynamically generated. In this section we 105 define an algorithm that supports the same core "name-data integrity" 106 service for dynamic objects. The basic idea is simply to include a 107 hash of a public key in the ni name, and then for the dynamic object 108 to be digitally signed with the corresponding private key. With a 109 little work to handle the various useful formats, this allows a 110 client that is presented with the ni name and the signed object to 111 verify the binding between the name and the object data. 113 Note that the signature scheme used might or might not provide 114 additional information, e.g. a name for the signer. Applications 115 might benefit from that, but it is not required in order to provide 116 the core "name-data integrity" service for dynamically generated 117 objects. 119 Since there are a number of digital signing schemes that might be 120 used, our approach is to define a new algorithm for the ni scheme 121 that takes as input a specific public key encoded in a specific way, 122 and runs that through a digest function. That is, the ni algorithm 123 fields will specify both a public key algorithm and a digest 124 algorithm, just as is done with digital signature algorithm 125 identifiers. 127 Since it is possible that an ni algorithm might also be defined where 128 the value contains an actual digital signature we need to be careful 129 to ensure there is no ambiguity. However, since the lengths of 130 signatures and hash outputs are (with current algorithms) always 131 different, we could use that fact to disambigute between rsa-with- 132 sha256 meaning the value is a sha256 hash of an rsa public key and 133 the alternative meaning the the value is an rsa-with-sha256 134 signature. However, we prefer to use a new algorithm (see Section 5 135 to disambiguate these. 137 We define one such algorithm, "pk-rsa-with-sha256" that takes an RSA 138 public key as input, with the input bits formatted as a 139 SubjectPublicKeyInfo as defined by [nischeme] Note that this does not 140 mean that one cannot use e.g. PGP to sign the actual object. It 141 means that if you do use PGP then in order to verify the name-data 142 integrity, the client needs to extract the signer's PGP public key, 143 then reformat that as a SubjectPublicKeyInfo and then run that 144 through the sha-256 algorithm and make the relevant comparison. 146 3. Query String Paramaeters 148 This section defines query string parameters that MAY be used to 149 indicate the type of content hashed or to specify additional 150 locations from which the named content can be retrieved. We also 151 define a way to specify how an encryption key MAY be included in an 152 ni URI that allows for decryption of object content. 154 3.1. Digest with Content Type 156 The semantics of a digest being used to establish a secure reference 157 from an authenticated source to an external source may be a function 158 of associated meta data such as the content type. This data MAY be 159 specified by means of a parameter: 161 ni:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain 163 The Content Type "ct" parameter specifies the MIME Content Type of 164 the associated data as defined in [RFC4288] 166 3.2. Additional Locators 168 In addition to the algorithm for mapping an ni URI to an HTTP(S) URL 169 specified in the ni scheme definition [nischeme], an ni name MAY 170 provide information about additional locations from which the 171 referenced content might be available. This is done via the 172 inclusion of an "alt" or "alts" key in the query string that can 173 supply more values for the authority field when constructing the HTTP 174 or HTTPS URL. For example: 176 ni://example.com/ 177 sha- 178 256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?alt=ni.example.net 180 The corresponding content might then also be retrieved from the URL: 182 http://ni.example.net/.well-known/ni/sha-256/ 183 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 185 A ni name MAY specify multiple locations from which the content MAY 186 be obtained: 188 ni:/// 189 sha- 190 256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?alt=one.example.com& 191 alt=two.example.com 193 The above example asserts that the content might be retrieved from 194 either of the following URIs: 196 http://one.example.com/.well-known/ni/sha-256/ 197 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 199 http://two.example.com/.well-known/ni/sha-256/ 200 B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc 202 The "alt" parameter means "use HTTP" and the "alts" parameter means 203 use "HTTPS". 205 The alt and alts parameters are used to specify a possible means of 206 resolving the referenced content. Multiple locator parameters MAY be 207 used to specify alternative sources for accessing the content. 209 The alt and alts parameters take a single argument, the authority to 210 be used for resolution. To permit the use of ni URIs in ASCII-only 211 environments, the ASCII encoding (aka punycode) of the domain name 212 MUST be used. [[Note sure if this is needed/correct.]] 214 3.3. Digest with Decryption Key 216 An ni name MAY provide a key for decrypting the referenced data. The 217 use-case here is where the referenced data has be distributed 218 (somehow) in ciphertext form, probably with little or no access 219 control required (since the data is strongly encrypted) and where a 220 client wishing to decrypt that data subsequently acquires an ni name 221 for that data that provides the required decryption key. 223 Clearly, to be of any benefit, access to the ni name that includes 224 the decryption key MUST be controlled so that only the appropriate 225 clients get access to the ni name and of course this ni name MUST be 226 strongly protected via some (probably mutual) authentication and 227 confidentiality service such as can be provided by TLS. [RFC5246] 229 ni///:sha-256;B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?enc=aes- 230 cbc:Fw3x20nEKfq6FDGzq7ttIQ 232 The "enc" specifier is used when the encrypted object consists of the 233 ciphertext alone. The "menc" spcifier is used when the encrypted 234 object consists of a MIME header containing metadata followed by the 235 binary object encoding. [[Note: there may be more needed here.]] 237 The encryption specifiers both take an agrument of the form: 239 algorithm ":" base64url (key) [":" base64url (iv)] 241 Where 243 algorithm Is the algorithm used to encrypt the associated content 245 key Is the value of the cryptographic key 247 iv (optional) Is the value of the cryptographic Initialization 248 Vector. 250 If the IV is not spcified for a block cipher mode that requires 251 one, the IV MUST be prepended to the encrypted content. 253 [[Note: Actually the IV does not provide any additional security 254 for this application but explaining the reason might be more 255 effort than it is worth and what we really care about is saving 256 bytes in the identifier, not the resulting data package.] 258 3.4. Wrapped URL 260 The "ni" URI form can usefully "wrap" an HTTP URL in order to provide 261 a way for an HTTP client that has securely received an "ni" URI (e.g. 262 embedded within some HTML received via a TLS session) to validate the 263 referred-to content, at the same level of security as the embedding 264 page. A good use for this might be to provide data integrity for 265 javascript or other files referred to by an HTML page. 267 To achieve the above, we define the "url" parameter which allows for 268 the inclusion of any URL within the query string. The intent is that 269 the content accessed via that URL match the hash in the ni name. 271 [[TBD: say how to encode the URL]] 273 4. Security Considerations 275 [[TBD for sure.]] 277 5. IANA Considerations 279 5.1. Additional algorithm in RFCXXXX registry 281 We request IANA to add a new entry to the hash algorithm registry 282 created in [nischeme], Section 9.3, as follows: 284 ID: 7 285 Hash string name: pk-rsa-with-sha256 286 Value length: 256 287 Reference: [RFC-THIS] 289 5.2. Creation of ni parameter registry 291 This specification creates a new IANA registry entitled "Named 292 Information URI Parameter Definitions". 294 The policy for future assignments to the registry is "RFC Required". 296 The initial contents of the registry are: 298 Parameter Meaning Reference 299 ----------- -------------------------------------------- --------- 300 ct Content Type [RFC-THIS] 301 alt Additional HTTP Locator [RFC-THIS] 302 alts Additional HTTPS Locator [RFC-THIS] 303 enc Encryption Key [RFC-THIS] 304 menc Encryption Key [RFC-THIS] 305 url Wrapped URL [RFC-THIS] 307 6. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 313 Registration Procedures", BCP 13, RFC 4288, December 2005. 315 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 316 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 318 [nischeme] 319 Farrell, S., Kutscher, D., Ohlman, B., Keranen, A., and P. 320 Hallam-Baker, "Naming things with hashes", 321 draft-farrell-decade-ni-03 (work in progress), April 2012. 323 Authors' Addresses 325 Phillip Hallam-Baker 326 Comodo Group Inc. 328 Email: philliph@comodo.com 330 Rob Stradling 331 Comodo CA Ltd. 333 Email: rob.stradling@comodo.com 334 Stephen Farrell 335 Trinity College Dublin 336 Dublin, 2 337 Ireland 339 Phone: +353-1-896-2354 340 Email: stephen.farrell@cs.tcd.ie 342 Dirk Kutscher 343 NEC 344 Kurfuersten-Anlage 36 345 Heidelberg, 346 Germany 348 Phone: 349 Email: kutscher@neclab.eu 351 Boerje Ohlman 352 Ericsson 353 Stockholm S-16480 354 Sweden 356 Email: Borje.Ohlman@ericsson.com