idnits 2.17.1 draft-ietf-smime-bfibecms-01.txt: 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 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 500. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. 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: ' 8. IANA Considerations' ) ** There are 155 instances of too long lines in the document, the longest one being 5 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 (October 2006) is 6395 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 70, but not defined == Missing Reference: 'BB1' is mentioned on line 71, but not defined == Missing Reference: 'SSL' is mentioned on line 412, but not defined == Missing Reference: 'TLS' is mentioned on line 412, but not defined == Unused Reference: 'RFC2827' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC3882' is defined on line 457, but no explicit reference was found in the text -- 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-martin-ibcs - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBCS' -- No information found for draft-ietf-ibearch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IBE' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 3882 Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 13 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: April 2007 October 2006 7 Using the Boneh-Franklin and Boneh-Boyen identity-based encryption 8 algorithms with 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 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be 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 made obsolete by other documents at 26 any 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 (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in 39 the Cryptographic Message Syntax (CMS) to encrypt content encryption 40 keys. Object identifiers and the convention for encoding a 41 recipient's identity are also defined. 43 Table of Contents 45 1. Introduction...................................................2 46 1.1. Terminology...............................................3 47 2. Using identity-based encryption................................3 48 3. Algorithm object identifiers...................................6 49 4. Processing by the sender.......................................6 50 5. Processing by the receiver.....................................7 51 6. ASN.1 Module...................................................8 52 7. Security Considerations........................................9 53 7.1. Attacks that are outside the scope of this document.......9 54 7.2. Attacks that are within the scope of this document........9 55 7.3. Attacks that the protocols defined in this document are 56 susceptible to................................................10 57 7.4. Attacks that the protocols defined in this document protect 58 against.......................................................10 59 8. IANA Considerations...........................................10 60 9. References....................................................11 61 9.1. Normative References.....................................11 62 Authors' Addresses...............................................12 63 Intellectual Property Statement..................................12 64 Disclaimer of Validity...........................................12 65 Copyright Statement..............................................13 66 Acknowledgment...................................................13 68 1. Introduction 70 This document defines the steps needed to use the Boneh-Franklin [BF] 71 and Boneh-Boyen [BB1] identity-based encryption (IBE) public-key 72 algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a 73 public key technology for encrypting content-encryption keys (CEKs) 74 that can be implemented within the framework of the CMS: the 75 recipient's identity is incorporated into the EnvelopedData CMS 76 content type using the OtherRecipientInfo CHOICE in the RecipientInfo 77 field as defined in section 6.2.5 of [CMS]. This document does not 78 describe the implementation of the BF and BB1 algorithms, which are 79 described in detail in [IBCS]. 81 IBE algorithms are a type of public-key cryptographic algorithm in 82 which the public key is calculated directly from a user's identity 83 instead of being generated randomly. This requires a different set of 84 steps for encryption and decryption than would be used with other 85 public-key algorithms, and these steps are defined in Sections 4 and 86 5 of this document respectively. 88 This document also defines the object identifiers and syntax of the 89 object that is used to define the identity of a message recipient. 91 CMS values and identity objects are defined using ANS.1 [ASN1]. 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC-2119 [KEYWORDS]. 99 2. Using identity-based encryption 101 To use IBE, the OtherRecipientInfo field MUST be set to an 102 IBEOtherRecipient type. 104 IBEOtherRecipientInfo ::= SEQUENCE { 105 ibeORIType OBJECT IDENTIFIER, 106 ibeORIValue IBERecipientInfo 107 } 109 The fields of IBEOtherRecipientInfo have the following meanings: 111 ibeORIType defines the object identifier (OID) that indicates that 112 the subsequent ibeORIValue is the information necessary to decrypt 113 the message using IBE. This field MUST be set to 115 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 116 us(840) organization(1) identicrypt(114334) ibcs(1) 117 cms(4) ori-oid(1) } 119 ibeORIValue defines the identity that was used in the IBE algorithm 120 to encrypt the CEK. This is an IBERecipientInfo type. 122 IBERecipientInfo ::= SEQUENCE { 123 cmsVersion INTEGER { v3(3) }, 124 keyFetchMethod OBJECT IDENTIFIER, 125 recipientIdentity IBEIdentityInfo, 126 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 127 encryptedKey EncryptedKey 128 } 130 The fields of IBERecipientInfo have the following meanings: 132 The cmsVersion MUST be set to 3. 134 The keyFetchMethod is the OID that defines the method of retrieving 135 the private key that the recipient MUST use. How to retrieve an IBE 136 private key using the steps defined in [IBE] is defined by the 137 keyFetchMethod OID. The method for retrieving private keys that is 138 specified in [IBE] is defined by cmsPPSOID. 140 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 141 us(840) organization(1) identicrypt(114334) pps-schemas(3) 142 ic-schemas(1) pps-uri(1) 143 } 145 The recipientIdentity is the data that was used to calculate the 146 public key that was used to encrypt the CEK. This MUST be an 147 IBEIdentityInfo type. This recipientIdentity is used to calculate IBE 148 public and private keys as described in [IBCS]. 150 IBEIdentityInfo ::= SEQUENCE { 151 District UTF8STRING, 152 Serial INTEGER, 153 identitySchema OBJECT IDENTIFIER, 154 identityData OCTET STRING 155 } 157 The fields of IBEIdentityInfo have the following meanings. 159 The district and serial are unique identifiers that are used to 160 construct the URI for the location of where the IBE public parameters 161 are located. The construction and use of this URI is defined in 162 [IBE]. 164 The identitySchema defines the format that is used to encode the 165 information that defines the identity of the recipient. This MUST be 166 set to cmsIdentityOID. 168 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 169 us(840) organization(1) identicrypt(114334) keyschemas(2) 170 icschemas(1) rfc822email(1) 171 } 173 The identityData is the identity of the recipient. For use in S/MIME, 174 this MUST be an EmailIdentitySchema type which is DER encoded. Other 175 applications MAY use other formats for the identityData. 177 EmailIdentitySchema ::= SEQUENCE { 178 rfc822Email UTF8STRING, 179 time GeneralizedTime 180 } 182 The rfc822Email is the DER-encoded e-mail address of the recipient in 183 the format defined by [RFC822]. 185 The value of "time" is the DER-encoded UTC time after which the 186 sender wants to let the recipient decrypt the message, so it may be 187 called the "not-before" time. This is usually set to the time when 188 the message is encrypted, but MAY be set to a future time. UTC time 189 values are expressed to the nearest second. 191 The sender of an IBE-encrypted message may want to express this time 192 rounded to a larger time interval to create a key lifetime and reduce 193 the number of IBE private keys that a recipient needs to retrieve. 194 Based on the time interval chosen a recipient would only have to 195 retrieve a new IBE key once during the interval. To do this, follow 196 the following steps. Let "time-interval" be the number of seconds in 197 this larger time interval. 199 1. Find the GeneralizedTime for the not-before value. 201 2. Convert this GeneralizedTime into the number of seconds since 203 January 1, 1970. Call this "total-time." 205 3. Calculate reduced-time = ( floor(total-time / 207 time-interval) ) * time-interval. 209 4. Convert reduced-time to a GeneralizedTime to get the not-before 210 "time" value. 212 An example of this algorithm for computing a one week time interval 213 is: 215 1. Say the GeneralizedTime is 20020401000000Z 217 2. The total-time is 1017612000 219 3. A time-interval of 1 week is 604800 seconds. So the reduced- 220 time = (floor(1017612000/604800))* 604800 = 1017273600 222 4. Giving the reduced-time GeneralizedTime for a 1 week time 223 interval of 20020328000000Z 225 3. Algorithm object identifiers 227 The BF and BB1 algorithms as defined in [IBCS] have the following 228 object identifiers: 230 bf OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 231 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 232 ibe-algorithms(2) bf(1) } 234 This is the object identifier that MUST be inserted in the 235 keyEncryptionAlgorithm field in the CMS when the BF algorithm is used 236 to encrypt the CEK. 238 bb1 OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840) 239 organization(1) identicrypt(114334) ibcs(1) ibcs1(1) 240 ibe-algorithms(2) bb1(2) } 242 This is the object identifier that MUST be inserted in the 243 keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is 244 used to encrypt the CEK. 246 4. Processing by the sender 248 The sender of a message that uses IBE to encrypt content encryption 249 keys performs the following steps: 251 1. Selects a set of IBE public parameters to use in the subsequent 252 steps in accordance with his local security policy. He then 253 determines the URI where the public parameters can be obtained using 254 the process described in [IBE]. This information MUST be encoded in 255 the IBEIdentityInfo as described in Section 2. 257 2. Sets the fields of an OtherRecipientInfo object to their 258 appropriate values as described in Section 2. 260 3. Calculates an IBE public key as defined in [IBCS] using this 261 IBEIdentityInfo as the identity information. 263 4. This IBE public key is then used to encrypt the content 264 encryption key (CEK), using the algorithms that are defined in 265 [IBCS]. 267 5. Sets encryptedKey to the IBE-encrypted CEK. 269 6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the 270 appropriate OID for the IBE algorithm that was used (see Section 3). 272 5. Processing by the receiver 274 Upon receiving a message that has a CEK encrypted with IBE, the 275 recipient performs the following steps to decrypt the CEK: 277 1. Determines that the CEK is IBE-encrypted by noting that the 278 oriType of the OtherRecipientInfo type is set to ibeORIType. 280 2. Determines that the recipientIdentity was used as the identity 281 in IBE encryption of the CEK. 283 3. Determines the location of the IBE public parameters and the 284 IBE Private Key Generator as described in [IBE]. 286 4. Obtains the IBE public parameters from the location determined 287 in Step 3 using the process defined in [IBE]. 289 5. Obtains the IBE private key needed to decrypt the encrypted CEK 290 using the process defined in [IBE]. 292 6. Decrypts the CEK using the IBE private key obtained in Step 4 293 using the algorithms described in [IBCS]. 295 6. ASN.1 Module 297 IBECMS-module { joint-iso-itu(2) country(16) us(840) organization(1) 298 identicrypt(114334) ibcs(1) cms(4) module(5) version(1) 299 } 301 DEFINITIONS IMPLICIT TAGS ::= BEGIN 303 IBEOtherRecipientInfo ::= SEQUENCE { 304 oriType OBJECT IDENTIFIER, 305 oriValue IBERecipientInfo 306 } 308 ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 309 us(840) organization(1) identicrypt(114334) ibcs(1) 310 cms(4) ori-oid(1) 311 } 313 IBERecipientInfo ::= SEQUENCE { 314 cmsVersion INTEGER { v3(3) }, 315 keyFetchMethod OBJECT IDENTIFIER, 316 recipientIdentity IBEIdentityInfo, 317 serverInfo SEQUENCE OF OIDValuePairs OPTIONAL, 318 encryptedKey EncryptedKey 319 } 321 IBEIdentityInfo ::= SEQUENCE { 322 District UTF8STRING, 323 serial INTEGER, 324 identitySchema OBJECT IDENTIFIER, 325 identityData OCTET STRING 326 } 328 OIDValuePairs ::= SEQUENCE { 329 fieldID OBJECT IDENTIFIER, 330 fieldData OCTET STRING 331 } 333 EmailIdentitySchema ::= SEQUENCE { 334 rfc822Email UTF8STRING, 335 time GeneralizedTime 336 } 338 cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 339 us(840) organization(1) identicrypt(114334) keyschemas(2) 340 icschemas(1) rfc822email(1) 341 } 342 cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) 343 us(840) organization(1) identicrypt(114334) pps-schemas(3) 344 ic-schemas(1) pps-uri(1) 345 } 347 END 349 7. Security Considerations 351 This document is based on [CMS] and [IBCS], and the relevant security 352 considerations of those documents apply. In addition, the following 353 considerations that are particular to this document. 355 7.1. Attacks that are outside the scope of this document 357 Attacks on the cryptographic algorithms that are used to implement 358 IBE are outside the scope of this document. Such attacks are detailed 359 in [IBCS], which defines parameters that will give the equivalent of 360 80-bit security, 112-bit security and 128-bit security. We assume 361 that competent administrators of an IBE system will select parameters 362 that provide a sufficient resistance to cryptanalytic attacks by 363 adversaries. 365 Attacks that require access to machines used by either the client or 366 the server components defined in this document are also outside the 367 scope of this document. Attacks that give an attacker the ability to 368 access or change the information on a PPS or PKG, especially the 369 cryptographic material, will defeat the security of an IBE system. To 370 address this concern, the PPS and PKG servers SHOULD be configured in 371 accordance with best current practices [NIST]. An IBE system should 372 be operated in an environment where such illicit access is infeasible 373 for attackers to obtain. 375 We also assume that all administrators of a system implementing the 376 protocols that are defined in this document are trustworthy and will 377 not abuse their authority to bypass the security provided by an IBE 378 system. Similarly, we assume that users of an IBE system will behave 379 responsibly, not sharing their authentication credentials with 380 others. Thus attacks that require such assumptions are outside the 381 scope of this document. 383 7.2. Attacks that are within the scope of this document 385 Attacks that passively monitor information transmitted between users 386 of an IBE system and the PPS and PKG are within the scope of this 387 document, as are attacks that let an adversary masquerade as a PPS or 388 PKG are also within the scope of this document. 390 7.3. Attacks that the protocols defined in this document are 391 susceptible to 393 The protocols defined in this document do not explicitly defend 394 against an attacker masquerading as a legitimate IBE PPS or PKG. To 395 provide protection against this possibility, client software that 396 implements the protocols defined in this document SHOULD have a user 397 interface that allows users to view the details of connections to PPS 398 and PKG servers so that users cannot easily be tricked into providing 399 valid authorization credentials to an attacker. 401 The protocols defined in this document are also vulnerable to Denial 402 of Service attacks against an IBE PPS or PKG. DOS attacks against 403 either component can result in users unable to access the information 404 and services required to encrypt or decrypt using IBE, and users of 405 an IBE system SHOULD take the appropriate countermeasures [RFC2827, 406 RFC3882] that their use of IBE requires. 408 7.4. Attacks that the protocols defined in this document protect 409 against 411 All communications between users of an IBE system and the PPS or PKG 412 are encrypted using SSL 3.0 [SSL] or TLS 1.1 [TLS], which should 413 provide an adequate level of protection for such communications. 415 The authentication method used by an IBE PKG should also be 416 sufficiently strong to prevent attackers from easily guessing them 417 through trial and error. 419 8. IANA Considerations 421 All of the object identifiers used in this document were assigned by 422 the National Institute of Standards and Technology (NIST), so no 423 further action by the IANA is necessary for this document. 425 9. References 427 9.1. Normative References 429 [ASN1] CCITT, Recommendation X.209: Specification of Basic Encoding 430 Rules for Abstract Syntax Notation One (ASN.1). 1998. 432 [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August 433 2002. 435 [IBCS] X. Boyen, L. Martin, "Identity-based cryptography standard 436 (IBCS) #1: supersingular curve implementations of the BF 437 and BB1 cryptosystems," draft-ieft-martin-ibcs-00.txt. 439 [IBE] G. Appenzeller, L. Martin, M. Schertler, "Identity-based 440 Encryption Architecture," draft-ietf-ibearch-01.txt. 442 [KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate 443 Requirement Levels," BCP 14, RFC 2119, March 1997. 445 [NIST] M. Souppaya, J. Wack, K. Kent, "Security Configuration 446 Checklist Program for IT Products - Guidance for Checklist 447 Users and Developers," NIST Special Publication SP 800-70, May 448 2005. 450 [RFC822] D. Crocker, "Standard for the format of ARPA internet text 451 messages," RFC 822, August 1982. 453 [RFC2827] P. Ferguson, D. Senie, "Network Ingress Filtering: 454 Defeating Denial of Service Attacks which employ IP Source 455 Address Spoofing," RFC 2827, BCP 38, May 2000. 457 [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service 458 Attacks," RFC 3882, September 2004. 460 Authors' Addresses 462 Luther Martin 463 Voltage Security 464 1070 Arastradero Rd Suite 100 465 Palo Alto CA 94304 467 Phone: +1 650 543 1280 468 Email: martin@voltage.com 470 Mark Schertler 471 Voltage Security 472 1070 Arastradero Rd Suite 100 473 Palo Alto CA 94304 475 Phone: +1 650 543 1280 476 Email: mark@voltage.com 478 Intellectual Property Statement 480 The IETF takes no position regarding the validity or scope of any 481 Intellectual Property Rights or other rights that might be claimed to 482 pertain to the implementation or use of the technology described in 483 this document or the extent to which any license under such rights 484 might or might not be available; nor does it represent that it has 485 made any independent effort to identify any such rights. Information 486 on the procedures with respect to rights in RFC documents can be 487 found in BCP 78 and BCP 79. 489 Copies of IPR disclosures made to the IETF Secretariat and any 490 assurances of licenses to be made available, or the result of an 491 attempt made to obtain a general license or permission for the use of 492 such proprietary rights by implementers or users of this 493 specification can be obtained from the IETF on-line IPR repository at 494 http://www.ietf.org/ipr. 496 The IETF invites any interested party to bring to its attention any 497 copyrights, patents or patent applications, or other proprietary 498 rights that may cover technology that may be required to implement 499 this standard. Please address the information to the IETF at 500 ietf-ipr@ietf.org. 502 Disclaimer of Validity 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 512 Copyright Statement 514 Copyright (C) The Internet Society (2006). 516 This document is subject to the rights, licenses and restrictions 517 contained in BCP 78, and except as set forth therein, the authors 518 retain all their rights. 520 Acknowledgment 522 Funding for the RFC Editor function is currently provided by the 523 Internet Society.