idnits 2.17.1 draft-ietf-smime-ibearch-00.txt: -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(267): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(270): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(271): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(273): 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 -(277): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(279): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(284): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(293): 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 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 323. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 336. ** 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 18 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.1. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. 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: ' 4. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 112 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 6518 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? 'KEY' on line 284 looks like a reference -- Missing reference section? 'P1363' on line 287 looks like a reference -- Missing reference section? 'CMS' on line 267 looks like a reference -- Missing reference section? 'IBEPPS' on line 270 looks like a reference -- Missing reference section? 'SSL3' on line 290 looks like a reference -- Missing reference section? 'IBCS' on line 273 looks like a reference -- Missing reference section? 'IBECMS' on line 277 looks like a reference -- Missing reference section? 'IBEPKG' on line 281 looks like a reference -- Missing reference section? 'TLS' on line 293 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L. Martin 3 S/MIME Working Group M. Schertler 4 Internet Draft Voltage Security 5 Expires: December 2006 June 2006 7 Identity-based Encryption Architecture 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 the security architecture required to implement 37 identity-based encryption, a public-key encryption technology that uses 38 a user�s identity as a public key. 40 Table of Contents 42 1. Introduction...................................................2 43 1.1. Terminology...............................................2 44 2. Identity-based Encryption......................................2 45 2.1. Overview..................................................2 46 2.2. Sending a message that is encrypted using IBE.............3 47 2.2.1. Sender obtains IBE public parameters.................3 48 2.2.2. Sender IBE-encrypts message..........................4 49 2.3. Receiving and viewing an IBE-encrypted message............4 50 2.3.1. Recipient obtains IBE private key from PKG...........5 51 2.3.2. Recipient decrypts IBE-encrypted message.............6 52 3. Security Considerations........................................6 53 4. IANA Considerations............................................6 54 5. References.....................................................6 55 5.1. Normative References......................................6 56 Author's Address..................................................7 57 Intellectual Property Statement...................................7 58 Disclaimer of Validity............................................8 59 Copyright Statement...............................................8 60 Acknowledgment....................................................8 62 1. Introduction 64 This document describes the security architecture required to 65 implement identity-based encryption, a public-key encryption 66 technology that uses a user�s identity as a public key. 68 1.1. Terminology 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [KEY]. 74 2. Identity-based Encryption 76 2.1. Overview 78 Identity-based encryption (IBE) is a public-key technology that 79 allows keys to be calculated from an identity. This contrasts with 80 other public-key systems [P1363], in which keys are generated 81 randomly. Much like other public-key systems, IBE systems have public 82 parameters that define their operation, and a user of an IBE system 83 needs to obtain these public parameters before he can do any IBE 84 operations. A user of an IBE system is capable of calculating the 85 public key of a recipient after he obtains the public parameters for 86 the IBE system and the recipient of an IBE-encrypted message can 87 decrypt an IBE-encrypted message if he has both the IBE public 88 parameters and the necessary private key. 90 With an IBE public key, a user can encrypt messages to a recipient 91 using the conventions of the Cryptographic Message Syntax [CMS]. 92 Within the framework of the CMS, a recipient also needs one 93 additional element of information to decrypt a message: the URI of 94 where he can obtain the private key that he needs to decrypt the IBE- 95 encrypted message. 97 To decrypt an IBE-encrypted message, the recipient needs to obtain 98 IBE public parameters as well as the private key that corresponds to 99 the public key that the sender used. A recipient of an IBE-encrypted 100 message obtains the IBE public parameters the same way that the 101 sender did. The IBE private key is obtained after authenticating to a 102 private key generator (PKG), a trusted third party that calculates 103 private keys for users. 105 This document describes the overall architecture that can be used to 106 implement IBE, and how the components of this architecture work 107 together to provide a functioning IBE system. The components required 108 for a complete IBE system include the following: 110 o A Public Parameter Server (PPS). A PPS provides IBE public 111 parameters and policy information for an IBE Private-key 112 Generator and is uniquely identified by the form of an 113 identity that it supports. 115 o A URI for a Private-key Generator (PKG) where users can get 116 IBE private keys after authenticating their identity in some 117 way. 119 Diagrams of these components and their interactions are shown in the 120 following sections. Note that IBE algorithms are used only for 121 encryption, so that any digital signatures that are required will 122 need to be provided by an additional mechanism. 124 2.2. Sending a message that is encrypted using IBE 126 2.2.1. Sender obtains IBE public parameters 128 The first step is for the sender of a message to obtain the IBE 129 public parameters that he needs for calculating the IBE public key of 130 the recipient. He obtains this information from a PPS that is hosted 131 at a well-known URI. The IBE public parameters contain all of the 132 information that the sender needs to create an IBE-encrypted message 133 except for the identity of the recipient. [IBEPPS] describes the URI 134 where a PPS is located, the format of IBE public parameters, and how 135 to obtain them. The URI from which users obtain IBE public parameters 136 MUST be authenticated in some way as defined in [IBEPPS], for 137 example, by using the SSL 3.0 protocol [SSL3]. [IBEPPS] also 138 describes the way in which identity formats are defined and a minimum 139 interoperable format that all PPSs and PKGs MUST support. This step 140 is shown below in Figure 1. 142 The sender of an IBE-encrypted message selects the PPS and 143 corresponding PKG based on his local security policy. Different PPSs 144 may provide public parameters that specify different IBE algorithms 145 or different key strengths, for example, or different PKGs may 146 require different levels of authentication before granting IBE 147 private keys. 149 IBE Public Parameter Request 150 -----------------------------> 151 Sender Public Parameter Server 152 <----------------------------- 153 IBE Public Parameters 155 Figure 1 Requesting IBE Public Parameters 157 2.2.2. Sender IBE-encrypts message 159 To IBE-encrypt a message, the sender chooses a content encryption key 160 (CEK) and uses it to encrypt his message and then encrypts the CEK 161 with the recipient�s IBE public key as described in [CMS]. This 162 operation is shown below in Figure 2. [IBCS] describes the algorithms 163 needed to implement two forms of IBE and [IBECMS] describes how to 164 use the Cryptographic Message Syntax (CMS) to encapsulate the 165 encrypted message along with the IBE information that the recipient 166 needs to decrypt the message, including the URI of the PPS and PKG. 168 CEK ----> Sender ----> IBE-encrypted CEK 170 ^ 171 | 172 | 174 Recipient�s Identity 175 and IBE Public Parameters 177 Figure 2 Using an IBE Public-key Algorithm to Encrypt 179 2.3. Receiving and viewing an IBE-encrypted message 181 The recipient of an IBE-encrypted message parses the message as 182 described in [IBECMS]. This gives him the URI where he can obtain the 183 IBE public parameters required to perform IBE calculations as well as 184 the identity that was used to encrypt the messsage. The PPS also 185 gives the URI of the PKG where the recipient of an IBE-encrypted 186 message can obtain the IBE private keys. After successfully 187 authenticating to this PKG the recipient, will receive the IBE 188 private key. 190 The PKG may allow users other than the intended recipient to receive 191 some IBE private keys. Giving a mail filtering appliance permission 192 to obtain IBE private keys on behalf of users, for example, can allow 193 the appliance to decrypt and scan encrypted messages for viruses or 194 other malicious features. 196 2.3.1. Recipient obtains IBE public parameters from PPS 198 Before he can perform any IBE calculations related to the message 199 that he has received, the recipient of an IBE-encrypted message needs 200 to obtain the IBE public parameters that were used in the encryption 201 operation. This operation is shown below in Figure 3. The comments in 202 Section 2.2.1 also apply to this operation. 204 IBE Public Parameter Request 205 -----------------------------> 206 Recipient Public Parameter Server 207 <----------------------------- 208 IBE Public Parameters 210 Figure 3 Requesting IBE Public Parameters 212 2.3.2. Recipient obtains IBE private key from PKG 214 To obtain an IBE private key, the recipient of an IBE-encrypted 215 message provides an identity that was used to calculate an IBE public 216 key to a PKG and requests the private key that corresponds to the IBE 217 public key. After providing the identity for which a private key is 218 being requested, a user MUST authenticate to the PKG. [IBEPKG] 219 defines the protocol for communicating with a PKG as well as a 220 minimum interoperable way to authenticate to a PKG that all IBE 221 implementations MUST support. Because the security of IBE private 222 keys is vital to the overall security of an IBE system, IBE private 223 keys MUST be transported to recipients over a secure protocol. PKGs 224 MUST support the SSL v 3.0 [SSL3] protocol and SHOULD support the TLS 225 v 1.1 [TLS] protocol for transport of IBE private keys. This 226 operation is shown below in Figure 4. 228 IBE Private Key Request 229 ----------------------------> 230 Recipient PKG 231 <---------------------------- 232 IBE Private Key 234 Figure 4 Obtaining an IBE Private Key 236 2.3.3. Recipient decrypts IBE-encrypted message 238 After obtaining the necessary IBE private key, the recipient uses 239 that IBE private key and the corresponding IBE public parameters to 240 decrypt the CEK. This operation is shown below in Figure 5. He then 241 uses the CEK to decrypt the encrypted message content. 243 IBE-encrypted CEK ----> Recipient ----> CEK 245 ^ 246 | 247 | 249 IBE Private Key 250 and IBE Public Parameters 252 Figure 5 Using an IBE Public-key Algorithm to Decrypt 254 3. Security Considerations 256 This entire document relates to security considerations. 258 4. IANA Considerations 260 No further action by the IANA is necessary for the protocols 261 described in this document. 263 5. References 265 5.1. Normative References 267 [CMS] R. Housley, �Cryptographic Message Syntax,� RFC 3369, August 268 2002. 270 [IBEPPS] G. Appenzeller, �Identity-based Encryption Parameter and 271 Policy Lookup,� draft-ietf-smime-ibepps-00.txt, June 2006. 273 [IBCS] X. Boyen, L. Martin, �Identity-Based Cryptography Standard 274 (IBCS) #1: Supersingular Curve Implementations of the BF and 275 BB1 Cryptosystems,� draft-ietf-smime-ibcs-00.txt, June 2006. 277 [IBECMS] M. Schertler, L. Martin, �Using the Boneh-Franklin identity- 278 based encryption algorithm with the Cryptographic Message 279 Syntax (CMS),� draft-ietf-smime-bfibecms-01.txt, June 2006. 281 [IBEPKG] G. Appenzeller, Identity-based Encryption Private Key 282 Request Protocol, draft-ietf-smime-ibepkg-00.txt, June 2006. 284 [KEY] S. Brander, �Key Words for Use in RFCs to Indicate Requirement 285 Levels,� BCP 14, RFC 2119, March 1997. 287 [P1363] IEEE P1363.3, �Standards Specifications for Public-Key 288 Cryptography,� 2001. 290 [SSL3] A. Frier, P. Karlton, P. Kocher, "The SSL 3.0 Protocol," 291 Netscape Communications Corp., Nov 18, 1996. 293 [TLS] T. Dierks, E. Rescorla, �The Transport Layer Security Protocol 294 Version 1.1,� RFC 4346, April 2006. 296 Authors� Addresses 298 Luther Martin 299 Voltage Security 300 1070 Arastradero Rd Suite 100 301 Palo Alto CA 94304 303 Phone: +1 650 543 1280 304 Email: martin@voltage.com 306 Mark Schertler 307 Voltage Security 308 1070 Arastradero Rd Suite 100 309 Palo Alto CA 94304 311 Phone: +1 650 543 1280 312 Email: mark@voltage.com 314 Intellectual Property Statement 316 The IETF takes no position regarding the validity or scope of any 317 Intellectual Property Rights or other rights that might be claimed to 318 pertain to the implementation or use of the technology described in 319 this document or the extent to which any license under such rights 320 might or might not be available; nor does it represent that it has 321 made any independent effort to identify any such rights. Information 322 on the procedures with respect to rights in RFC documents can be 323 found in BCP 78 and BCP 79. 325 Copies of IPR disclosures made to the IETF Secretariat and any 326 assurances of licenses to be made available, or the result of an 327 attempt made to obtain a general license or permission for the use of 328 such proprietary rights by implementers or users of this 329 specification can be obtained from the IETF on-line IPR repository at 330 http://www.ietf.org/ipr. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights that may cover technology that may be required to implement 335 this standard. Please address the information to the IETF at 336 ietf-ipr@ietf.org. 338 Disclaimer of Validity 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 343 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 344 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 345 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Copyright Statement 350 Copyright (C) The Internet Society (2006). 352 This document is subject to the rights, licenses and restrictions 353 contained in BCP 78, and except as set forth therein, the authors 354 retain all their rights. 356 Acknowledgment 358 Funding for the RFC Editor function is currently provided by the 359 Internet Society.