idnits 2.17.1 draft-ietf-smime-bfibecms-00.txt: -(41): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(69): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(76): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(205): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(388): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(392): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(398): 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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 441. ** 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 16 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: ' 1. Introduction' ) ** 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: ' 8. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 97 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 6525 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: 'BF' is mentioned on line 66, but not defined == Missing Reference: 'IBE3' is mentioned on line 278, but not defined == Missing Reference: 'IBCS1' is mentioned on line 369, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- No information found for draft-ieft-smime-ibcs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBCS' -- No information found for draft-ietf-ibepps - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBEPPS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 12 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 Using the Boneh-Franklin identity-based encryption algorithm with 8 the Cryptographic Message Syntax (CMS) 10 12 Status of this Document 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware have been 16 or will be disclosed, and any of which he or she becomes aware will be 17 disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes the conventions for using the Boneh-Franklin 38 identity-based encryption (BF-IBE) algorithm in the Cryptographic 39 Message Syntax (CMS). The BF-IBE algorithm supports the transport of 40 symmetric keys to encrypt content encryption keys. Object 41 identifiers and the convention for encoding a recipient�s identity 42 are also defined. 44 Table of Contents 46 1. Introduction...................................................2 47 1.1. Terminology...............................................2 48 2. Using identity-based encryption................................3 49 3. Algorithm object identifier....................................5 50 4. Processing by the sender.......................................6 51 5. Processing by the receiver.....................................6 52 6. ASN.1 Module...................................................7 53 7. Security Considerations........................................9 54 8. IANA Considerations............................................9 55 9. References....................................................10 56 9.1. Normative References.....................................10 57 Author's Addresses...............................................10 58 Intellectual Property Statement..................................10 59 Disclaimer of Validity...........................................11 60 Copyright Statement..............................................11 61 Acknowledgment...................................................11 63 1. Introduction 65 This document defines the steps needed to use the Boneh-Franklin 66 identity-based encryption (BF-IBE) public-key algorithm [BF] in the 67 Cryptographic Message Syntax (CMS) [CMS]. BF-IBE is a public key 68 technology for encrypting content-encryption keys (CEKs). The 69 recipient�s identity is incorporated into the EnvelopedData CMS 70 content type using the OtherRecipientInfo CHOICE in the RecipientInfo 71 field as defined in section 6.2.5 of [CMS]. This document does not 72 describe the implementation of the BF-IBE algorithm, which is 73 described in detail in [IBCS]. 75 The BF-IBE algorithm is a public-key algorithm in which the public 76 key is calculated directly from a user�s identity instead of being 77 generated randomly. This document defines the object identifiers and 78 syntax of the object that is used to define the identity of a message 79 recipient. 81 CMS values and identity objects are defined using ANS.1 [ASN1]. 83 1.1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 89 2. Using identity-based encryption 91 To use IBE, the OtherRecipientInfo field MUST be set to an 92 IBEOtherRecipient type. 94 IBEOtherRecipientInfo ::= SEQUENCE { 96 ibeORIType OBJECT IDENTIFIER, 98 ibeORIValue IBERecipientInfo 100 } 102 The fields of IBEOtherRecipientInfo have the following meanings: 104 ibeORIType defines the object identifier (OID) that indicates that 105 the subsequent ibeORIValue is the information necessary to decrypt 106 the message using IBE. This field MUST be set to 108 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 110 us(840) organization(1) identicrypt(114334) ibcs(1) 112 cms(4) ori-oid(1) } 114 ibeORIValue defines the identity that was used in the BF-IBE 115 algorithm to encrypt the CEK. This is an IBERecipientInfo type. 117 IBERecipientInfo ::= SEQUENCE { 119 cmsVersion INTEGER { v0(0) }, 121 keyFetchMethod OBJECT IDENTIFIER, 123 recipientIdentity IBEIdentityInfo, 125 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 127 encryptedKey EncryptedKey 129 } 131 The fields of IBERecipientInfo have the following meanings: 133 cmsVersion MUST be set to 0. 135 keyFetchMethod is the OID that defines the method of retrieving the 136 private key that the recipient MUST use. How to retrieve an IBE 137 private key using the steps defined in [IBEPPS] is defined by the 138 keyFetchMethod OID. The method for retrieving private keys that is 139 specified in [IBEPPS] is defined by cmsPPSOID. 141 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 143 us(840) organization(1) identicrypt(114334) pps-schemas(3) 145 ic-schemas(1) pps-uri(1) 147 } 149 recipientIdentity is the data that was used to calculate the public 150 key that was used to encrypt the CEK. This MUST be an IBEIdentityInfo 151 type. This recipientIdentity is used to calculate IBE public and 152 private keys as described in [IBCS]. 154 IBEIdentityInfo ::= SEQUENCE { 156 district UTF8STRING, 158 serial INTEGER, 160 identitySchema OBJECT IDENTIFIER, 162 identityData OCTET STRING 164 } 166 The fields of IBEIdentityInfo have the following meanings. 168 district and serial are unique identifiers that are used to construct 169 the URI for the location of where the IBE public parameters are 170 located. The construction and use of this URI is defined in [IBEPPS]. 172 identitySchema defines the format that is used to encode the 173 information that defines the identity of the recipient. This MUST be 174 set to cmsIdentityOID. 176 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 178 us(840) organization(1) identicrypt(114334) keyschemas(2) 180 icschemas(1) rfc822email(1) 182 } 184 identityData is the data that defines the identity of the recipient. 185 This MUST be an EmailIdentitySchema type which is DER encoded. 187 EmailIdentitySchema ::= SEQUENCE { 189 rfc822Email UTF8STRING, 191 time UTCTime 193 } 195 rfc822Email is the DER-encoded e-mail address of the recipient in the 196 format defined by [RFC822]. 198 time is the DER-encoded UTC time at which the sender wants to let the 199 recipient decrypt the message, so it may be called the �not-before� 200 time. This is usually set to the time when the message is encrypted, 201 but MAY be set to a future time. UTC time values are expressed to the 202 nearest second, but the sender of an IBE-encrypted message may want 203 to express this time rounded to a larger time interval to reduce the 204 number of IBE private keys that a recipient needs to retrieve. To do 205 this, follow the following steps. Let �time-interval� be the number 206 of seconds in this larger time interval. 208 1. Find the UTC time for the not-before value. 210 2. Convert this UTC time into the number of seconds since 212 January 1, 1970. Call this �total-time.� 214 3. Calculate reduced-time = ( floor( total-time / 216 time-interval ) ) * time-interval. 218 4. Convert reduced-time to a UTC time to get the not-before value. 220 3. Algorithm object identifier 222 The BF-IBE algorithm as defined in [IBCS] has the following object 223 identifier: 225 bf-ibe OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 227 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 228 ibe-algorithms(2) bf(1) } 230 This is the object identifier that MUST be inserted in the 231 keyEncryptionAlgorithm field in the CMS when the BF-IBE algorithm is 232 used to encrypt the CEK. 234 4. Processing by the sender 236 The sender of a message that uses BF-IBE to encrypt content 237 encryption keys performs the following steps: 239 1. Selects a set of IBE public parameters to use in the subsequent 240 steps in accordance with his local security policy. He then 241 determines the URI where the public parameters can be obtained using 242 the process described in [IBEPPS]. This information MUST be encoded 243 in the IBEIdentityInfo as described in [IBEPPS]. 245 2. Sets the fields of an OtherRecipientInfo object to their 246 appropriate values as described in Section 2. 248 3. Calculates a BF-IBE public key as defined in [IBCS] using this 249 IBEIdentityInfo as the identity information. 251 4. This BF-IBE public key is then used to encrypt the content 252 encryption key (CEK), using the algorithms that are defined in 253 [IBCS]. 255 5. Sets encryptedKey to the BF-IBE-encrypted CEK. 257 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to bf- 258 ibe (see Section 3). 260 5. Processing by the receiver 262 Upon receiving a message that has a CEK encrypted with BF-IBE, the 263 recipient performs the following steps to decrypt the CEK: 265 1. Determines that the CEK is IBE-encrypted by noting that the 266 oriType of the OtherRecipientInfo type is set to ibeORIType. 268 2. Determines that the recipientIdentity was used as the identity 269 in BF encryption of the CEK. 271 3. Determines the location of the IBE public parameters and the 272 IBE Private Key Generator as described in [IBEPPS]. 274 4. Obtains the IBE public parameters from the location determined 275 in Step 3 using the process defined in [IBEPPS]. 277 5. Obtains the IBE private key needed to decrypt the encrypted CEK 278 using the process defined in [IBE3]. 280 6. Decrypts the CEK using the IBE private key obtained in Step 4 281 using the algorithms described in [IBCS]. 283 6. ASN.1 Module 285 BFCMS-module { joint-iso-itu(2) country(16) us(840) organization(1) 287 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 289 } 291 DEFINITIONS IMPLICIT TAGS ::= BEGIN 293 IBEOtherRecipientInfo ::= SEQUENCE { 295 oriType OBJECT IDENTIFIER, 297 oriValue IBERecipientInfo 299 } 301 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 303 us(840) organization(1) identicrypt(114334) ibcs(1) 305 cms(4) ori-oid(1) 307 } 309 IBERecipientInfo ::= SEQUENCE { 311 cmsVersion INTEGER { v0(0) }, 312 keyFetchMethod OBJECT IDENTIFIER, 314 recipientIdentity IBEIdentityInfo, 316 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 318 encryptedKey EncryptedKey 320 } 322 IBEIdentityInfo ::= SEQUENCE { 324 district UTF8STRING, 326 serial INTEGER, 328 identitySchema OBJECT IDENTIFIER, 330 identityData OCTET STRING 332 } 334 OIDValuePairs ::= SEQUENCE { 336 fieldID OBJECT IDENTIFIER, 338 fieldData OCTET STRING 340 } 342 EmailIdentitySchema ::= SEQUENCE { 344 rfc822Email UTF8STRING, 346 time UTCTime 348 } 350 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 351 us(840) organization(1) identicrypt(114334) keyschemas(2) 353 icschemas(1) rfc822email(1) 355 } 357 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 359 us(840) organization(1) identicrypt(114334) pps-schemas(3) 361 ic-schemas(1) pps-uri(1) 363 } 365 END 367 7. Security Considerations 369 This document is based on [CMS] and [IBCS1], and the relevant 370 security considerations of those documents apply. 372 8. IANA Considerations 374 All of the object identifiers used in this document were assigned by 375 the National Institute of Standards and Technology (NIST), so no 376 further action by the IANA is necessary for this document. 378 9. References 380 9.1. Normative References 382 [ASN1] CCITT, Recommendation X.209: Specification of Basic Encoding 383 Rules for Abstract Syntax Notation One (ASN.1). 1998. 385 [CMS] R. Housley, �Cryptographic Message Syntax,� RFC 3369, August 386 2002. 388 [IBCS] X. Boyen, L. Martin, �Identity-based cryptography standard 389 (IBCS) #1: supersingular curve implementations of the BF 390 and BB1 cryptosystems,� draft-ieft-smime-ibcs-00.txt. 392 [IBEPPS] G. Appenzeller, �Parameter and Policy Lookup for Identity- 393 based Encryption,� draft-ietf-ibepps-00.txt. 395 [KEYWORDS] S. Brander, �Key Words for Use in RFCs to Indicate 396 Requirement Levels,� BCP 14, RFC 2119, March 1997. 398 [RFC822] D. Crocker, �Standard for the format of ARPA internet text 399 messages,� RFC 822, August 1982. 401 Authors� Addresses 403 Luther Martin 404 Voltage Security 405 1070 Arastradero Rd Suite 100 406 Palo Alto CA 94304 408 Phone: +1 650 543 1280 409 Email: martin@voltage.com 411 Mark Schertler 412 Voltage Security 413 1070 Arastradero Rd Suite 100 414 Palo Alto CA 94304 416 Phone: +1 650 543 1280 417 Email: mark@voltage.com 419 Intellectual Property Statement 421 The IETF takes no position regarding the validity or scope of any 422 Intellectual Property Rights or other rights that might be claimed to 423 pertain to the implementation or use of the technology described in 424 this document or the extent to which any license under such rights 425 might or might not be available; nor does it represent that it has 426 made any independent effort to identify any such rights. Information 427 on the procedures with respect to rights in RFC documents can be 428 found in BCP 78 and BCP 79. 430 Copies of IPR disclosures made to the IETF Secretariat and any 431 assurances of licenses to be made available, or the result of an 432 attempt made to obtain a general license or permission for the use of 433 such proprietary rights by implementers or users of this 434 specification can be obtained from the IETF on-line IPR repository at 435 http://www.ietf.org/ipr. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights that may cover technology that may be required to implement 440 this standard. Please address the information to the IETF at 441 ietf-ipr@ietf.org. 443 Disclaimer of Validity 445 This document and the information contained herein are provided on an 446 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 447 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 448 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 449 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 450 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Copyright Statement 455 Copyright (C) The Internet Society (2006). 457 This document is subject to the rights, licenses and restrictions 458 contained in BCP 78, and except as set forth therein, the authors 459 retain all their rights. 461 Acknowledgment 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.