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