idnits 2.17.1 draft-ietf-smime-ibepkg-00.txt: -(65): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(272): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(275): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(278): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(337): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(340): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(349): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(359): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(363): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(367): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 415. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** There are 109 instances of too long lines in the document, the longest one being 11 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2006) is 6526 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 section? 'IBEARCH' on line 356 looks like a reference -- Missing reference section? 'IBCS' on line 359 looks like a reference -- Missing reference section? 'IBEPPS' on line 367 looks like a reference -- Missing reference section? 'KEY' on line 340 looks like a reference -- Missing reference section? 'IBCMS' on line 104 looks like a reference -- Missing reference section? 'RFC2616' on line 374 looks like a reference -- Missing reference section? 'SSL3' on line 346 looks like a reference -- Missing reference section? 'TLS' on line 349 looks like a reference -- Missing reference section? 'RFC2618' on line 114 looks like a reference -- Missing reference section? 'IBECMS' on line 363 looks like a reference -- Missing reference section? 'RFC2617' on line 378 looks like a reference -- Missing reference section? 'CMS' on line 337 looks like a reference -- Missing reference section? 'P1363' on line 343 looks like a reference -- Missing reference section? 'X509' on line 352 looks like a reference -- Missing reference section? 'RFC2396' on line 370 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group G. Appenzeller 3 Internet Draft Voltage Security 4 Expires: December 2006 June 2006 6 Identity-based Encryption 7 Private Key Request Protocol 9 11 Status of this Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware have been 15 or will be disclosed, and any of which he or she becomes aware will be 16 disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes a protocol to request private keys from a 37 Private Key Generator (PKG) for an identity-based encryption system. 39 Table of Contents 41 1. Introduction...................................................2 42 1.1. Terminology...............................................2 43 2. Overview.......................................................2 44 3. Private Key Request............................................3 45 3.1. Request Structure.........................................3 46 3.2. Authentication............................................4 47 4. Server Response Format.........................................4 48 4.1. Response containing a Private Key.........................5 49 4.2. Responses containing a Redirect...........................6 50 4.3. Responses indicating an Error.............................6 51 5. ASN.1 Module...................................................8 52 6. Security Considerations........................................9 53 7. IANA Considerations............................................9 54 8. References.....................................................9 55 8.1. Normative References......................................9 56 Author's Address.................................................10 57 Intellectual Property Statement..................................10 58 Disclaimer of Validity...........................................11 59 Copyright Statement..............................................11 60 Acknowledgment...................................................11 62 1. Introduction 64 An identity-based encryption system [IBEARCH] allows the encryption 65 of messages using a user�s identity plus a set of public parameters. 66 For decryption users need a private key that is generated by a 67 private key generator. This document defines a protocol to retrieve 68 private keys from the private key generator (PKG) of an IBE system. 70 This document does not describe the actual algorithms used for 71 encryption or the mathematical structure of the public parameters, 72 they are described in [IBCS]. It also does not describe the 73 communication protocol to retrieve public parameters, it is described 74 in [IBEPPS]. 76 1.1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC-2119 [KEY]. 82 2. Overview 84 In an identity-based encryption (IBE) system messages are encrypted 85 using a public key that is locally calculated from public parameters 86 and a user�s identity and decrypted using a private key that 87 corresponds to the user�s public key. These private keys are 88 generated by a private key generator (PKG) based on a global secret 89 called a master secret. 91 When requesting a private key, a client has to transmit two 92 parameters: 93 1. The identity it is requesting a key for 94 2. Authentication credentials 95 These two are often not the same as a single user may have access to 96 multiple aliases. For example an email user may have access to the 97 keys that correspond to two different email addresses, e.g. 98 bob@example.com and bob.smith@example.com. 100 This document defines the protocol to request private keys, a minimum 101 user authentication method for interoperability, and how to pass 102 authentication credentials to the server. It assumes that a client 103 has already determined the URL of the PKG. This can be done from 104 hints included in the IBE message format [IBCMS] and the system 105 parameters of the IBE system [IBEPPS]. 107 3. Private Key Request 109 To request a private key, a client performs a HTTP POST method as 110 defined in [RFC2616]. The request MUST happen over a secure protocol. 111 The requesting client MUST support either SSL v 3.0 [SSL3] protocol 112 or TLS v 1.1 [TLS]. When requesting the URL the client MUST abort the 113 key request if the server certificate verification of the SSL or TLS 114 connection fails [RFC2618]. Doing so is critical to protect the 115 authentication credentials and the private key against man-in-the- 116 middle attacks when it is transmitted from the key server to the 117 client. 119 3.1. Request Structure 121 The POST method contains in its body the following XML structure: 123 124 125 126 127 128 129 130 algorithmOID 131 132 133 ibeIdentityInfo 134 135 136 137 138 A SHOULD include a element that 139 identifies the client type and client version. 141 A key request MUST contain a valid ibeIdentityInfo that the private 142 key is requested for. This identity is the BASE64 encoding of the DER 143 encoding of the ASN.1 structure IBEIdentityInfo as defined in 144 [IBECMS]. 146 A key request MUST contain a element that contains a 147 XER encoded ASN.1 OBJECT IDENTIFIER that identifies algorithm for 148 which a key is requested. OIDs for the BB1 and BF algorithms are 149 listed in [IBCS]. 151 A client MAY include optional additional XML elements in the 152 part of the key request. 154 3.2. Authentication 156 When a client requests a key from a PKG, the PKG SHOULD authenticate 157 the client before issuing the key. Authentication may either be done 158 through the key request structure or as part of the secure transport 159 protocol. 161 A client or server implementing the request protocol MUST support 162 HTTP Basic Auth as described in [RFC2617]. A client and server SHOULD 163 also support HTTP Digest Auth as defined in [RFC2617]. 165 For authentication methods that are not done by the transport 166 protocol, a client MAY include additional authentication information 167 in xml elements in the body part of the key request. If a client does 168 not know how to authenticate to a server, the client MAY send a key 169 request without authentication information. If the key server 170 requires the client to authenticate externally, it MAY reply with a 171 201 response code as defined below to redirect the client to the 172 correct authentication mechanism. 174 4. Server Response Format 176 The key server replies to the HTTP request with an HTTP response. If 177 the response has a redirect, client error or server error status 178 code, the client MUST abort the key request and fail. 180 If the PKG replies with a HTTP response that has a status code 181 indicating success, the body of the reply MUST contain the following 182 XML structure: 184 185 186 187 bodyTags 188 189 191 The responseCode describes the type of response from the key server. 192 The list of currently defined response codes is: 194 100 KEY_FOLLOWS 195 101 RESERVED 196 201 FOLLOW_ENROLL_URL 197 300 SYSTEM_ERROR 198 301 INVALID_REQUEST 199 303 CLIENT_OBSOLETE 200 304 AUTHORIZATION DENIED 202 4.1. Response containing a Private Key 204 If the key request was successful, the key server responds with KEY 205 FOLLOWS, and the must contain a tag with 206 a valid private key. An example of this is shown below. 208 209 210 211 212 privateKey 213 214 215 217 The privateKey is the Base64 encoding of the DER encoding of the 218 following ASN.1 structure: 220 IBEPrivateKeyReply ::= SEQUENCE { 221 pkgIdentity IBEIdentityInfo, 222 pgkAlgorithm OBJECT IDENTIFIER 223 pkgKeyData OCTET STRING 224 pkgOptions SEQUENCE OF Extensions 225 } 227 The pkgIdentity is an IBEIdentityInfo structure as defined in 228 [IBECMS]. It MUST be identical to the IBEIdentityInfo structure that 229 was sent in the key request. 231 The pkgAlgorithm is an OID that identifies the algorithm of the 232 returned private key. The OIDs for the BB and BF algorithms are 233 defined in [IBCS]. 235 The pkgKeyData is a ASN.1 structure that contains the actual private 236 key. Private key formats for the BB and BF algorithms are defined in 237 [IBCS]. 239 A server MAY pass back additional information to a client in the 240 pkgOptions structure. The contents of the structure are defined in 241 the ASN.1 module below. 243 4.2. Responses containing a Redirect 245 A Key Server MAY support authenticating user to external 246 authentication mechanism. If this is the case, the server replies to 247 the client with response code 201 and the body MUST contain a 248 element that specifies the URL of the authentication 249 mechanism. An example is shown below. 251 252 253 254 255 256 258 The client can now contact the authentication mechanism to obtain 259 authentication credentials. Once the client has obtained the 260 credential, it sends a new key request to the PKG with the correct 261 authentication token contained in the request. 263 4.3. Responses indicating an Error 265 If the server replies with a 3xx error code, the client MUST abort 266 the request and discard any data that is part of the response. 268 The meaning of the response codes for errors is as follows: 270 300 � This indicates an internal server error of the PKG. 272 301 � The request to the server is invalid or the server is not able 273 to fulfill this type of request. 275 303 � The server is not able to serve key requests for this type of 276 client. A client with a newer version of the protocol is required. 278 304 � The key request was processed correctly, but the authentication 279 credentials provided by the user were invalid, could not be verified, 280 or do not allow access to keys for this identity. 282 5. ASN.1 Module 284 This section defines the ASN.1 module for the encodings discussed in 285 section 4. 287 IBEPKG { joint-iso-itu(2) country(16) us(840) organization(1) 288 identicrypt(114334) ibcs(1) ibcs2(2) pks(1) module (5) version(1) 289 } 291 DEFINITIONS IMPLICIT TAGS ::= BEGIN 293 IMPORTS IBEIdentityInfo 294 FROM BFCMS 295 { joint-iso-itu(2) country(16) us(840) organization(1) 296 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 297 }; 299 ibcs OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 300 us(840) organization(1) identicrypt(114334) ibcs(1) 301 } 303 -- Private Key Format 305 IBEPrivateKeyReply ::= SEQUENCE { 306 pkgIdentity IBEIdentityInfo, 307 pgkKeyType OBJECT IDENTIFIER, 308 pkgKeyData OCTET STRING, 309 pkgOptions Extensions 310 } 312 Extensions ::= SEQUENCE OF Extension 314 Extension ::= SEQUENCE { 315 id OBJECT IDENTIFIER, 316 value OCTET STRING 317 } 319 ibeParamExt OBJECT IDENTIFIER ::= { 320 ibcs ibcs2(2) pks(1) extensions(2) 321 } 323 END 324 6. Security Considerations 326 This entire document relates to security considerations. 328 7. IANA Considerations 330 No further action by the IANA is necessary for the protocols 331 described in this document. 333 8. References 335 8.1. Normative References 337 [CMS] R. Housley, �Cryptographic Message Syntax,� RFC 3369, August 338 2002. 340 [KEY] S. Brander, �Key Words for Use in RFCs to Indicate Requirement 341 Levels,� BCP 14, RFC 2119, March 1997. 343 [P1363] IEEE P1363.3, �Standards Specifications for Public-Key 344 Cryptography,� 2001. 346 [SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", 347 Netscape Communications Corp., Nov 18, 1996. 349 [TLS] T. Dierks, E. Rescorla, �The Transport Layer Security Protocol 350 Version 1.1,� RFC 4346, April 2006. 352 [X509] ITU-T Recommendation X.509 (1997 E): Information Technology - 353 Open Systems Interconnection - The Directory: Authentication 354 Framework, June 1997. 356 [IBEARCH] L. Martin, M. Schertler, �Identity-based encryption 357 architecture,� draft-ietf-smime-ibearch-00.txt. 359 [IBCS] X. Boyen, L. Martin, �Identity-based cryptography standard 360 (IBCS) #1: supersingular curve implementations of the BF and 361 BB1 cryptosystems,� draft-ietf-smime-ibcs-00.txt. 363 [IBECMS] M. Schertler, L. Martin, �Using the Boneh-Franklin identity- 364 based encryption algorithm with the Cryptographic Message 365 Syntax (CMS),� draft-ietf-smime-bfibecms-01.txt. 367 [IBEPPS] G. Appenzeller, �Parameter and policy lookup for identity- 368 based encryption,� draft-ietf-smime-ibepkg-00.txt. 370 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 371 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 372 1998.Author's Address 374 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, 375 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol 376 -- HTTP/1.1", RFC 2616, June 1999. 378 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 379 Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP 380 Authentication: Basic and Digest Access Authentication", RFC 381 2617, June 1999. [jg646] 383 Author's Address 385 Guido Appenzeller 386 Voltage Security 387 1070 Arastradero Rd Suite 100 388 Palo Alto CA 94304 390 Phone: +1 650 543 1280 391 Email: guido@voltage.com 393 Intellectual Property Statement 395 The IETF takes no position regarding the validity or scope of any 396 Intellectual Property Rights or other rights that might be claimed to 397 pertain to the implementation or use of the technology described in 398 this document or the extent to which any license under such rights 399 might or might not be available; nor does it represent that it has 400 made any independent effort to identify any such rights. Information 401 on the procedures with respect to rights in RFC documents can be 402 found in BCP 78 and BCP 79. 404 Copies of IPR disclosures made to the IETF Secretariat and any 405 assurances of licenses to be made available, or the result of an 406 attempt made to obtain a general license or permission for the use of 407 such proprietary rights by implementers or users of this 408 specification can be obtained from the IETF on-line IPR repository at 409 http://www.ietf.org/ipr. 411 The IETF invites any interested party to bring to its attention any 412 copyrights, patents or patent applications, or other proprietary 413 rights that may cover technology that may be required to implement 414 this standard. Please address the information to the IETF at 415 ietf-ipr@ietf.org. 417 Disclaimer of Validity 419 This document and the information contained herein are provided on an 420 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 421 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 422 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 423 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 424 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 425 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 427 Copyright Statement 429 Copyright (C) The Internet Society (2006). 431 This document is subject to the rights, licenses and restrictions 432 contained in BCP 78, and except as set forth therein, the authors 433 retain all their rights. 435 Acknowledgment 437 Funding for the RFC Editor function is currently provided by the 438 Internet Society.