L. Martin S/MIME Working Group M. Schertler Internet Draft Voltage Security Expires: August 2006 February 26, 2006 Using the Boneh-Franklin identity-based encryption algorithm with the Cryptographic Message Syntax (CMS) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 21, 2006. Abstract This document describes the conventions for using the Boneh-Franklin identity-based encryption (BF-IBE) algorithm in the Cryptographic Message Syntax (CMS). The BF-IBE algorithm supports the transport of symmetric keys to encrypt message content. Object identifiers (OIDs) and the convention for encoding a recipient’s identity are also defined. Martin Expires August 26, 2006 [Page 1] Internet-Draft Using BF-IBE with CMS February 2006 Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................2 2. Definition of identity.........................................3 3. Algorithm object identifier....................................3 4. Processing by the sender.......................................3 5. Processing by the receiver.....................................4 6. Security Considerations........................................4 7. IANA Considerations............................................4 8. References.....................................................5 8.1. Normative References......................................5 8.2. Informative References....................................5 Author's Addresses................................................5 Intellectual Property Statement...................................6 Disclaimer of Validity............................................6 Copyright Statement...............................................6 Acknowledgment....................................................6 1. Introduction This document defines a profile for the use of Boneh-Franklin identity-based encryption (BF-IBE) public-key algorithm [BF] in the CMS [CMS]. BF-IBE is incorporated into the EnvelopedData CMS content type to encrypt content-encryption keys that are used for content encryption. This document does not describe the implementation of the BF-IBE algorithm, which is described in detail in [IBCS1]. (TO DO: convert the IBCS#1 document into an Internet Draft.) The BF-IBE algorithm is a public-key algorithm in which the public key is calculated directly from a user’s identity. This document also describes the format of the object that is used to define the identity of a message recipient. This includes the URI of where the private key that corresponds to a public is obtained. CMS values and identity objects are defined using ANS.1 [ASN1]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [KEYWORDS]. Martin, Schertler Expires August 26, 2006 [Page 2] Internet-Draft Using BF-IBE with CMS February 2006 2. Definition of identity An object defining the identity of a user that will be used in BF-IBE is represented in the type IBEIdentity. IBEIdentity ::= SEQUENCE { version INTEGER { 2 } district IBEDistrict, useridentity IBEIdentityData } IBEDistrict ::= UTF8String IBEIdentityData ::= SEQUENCE { oid IBEIdentityOID identity Identity } IBEIdentityOID OBJECT IDENTIFIER ::= { 2 16 840 1 114334 2 1 1 } Identity ::= SEQUENCE { notBefore GeneralizedTime ; time message is sent/encrypted IdentityString UTF8String } ; usually an e-mail address 3. Algorithm object identifier The BF-IBE algorithm as defined in [IBCS1] has the following object identifier: bf-ibe OBJECT IDENTIFIER ::= { 2 16 840 1 114334 1 1 2 1 } 4. Processing by the sender The sender of a message that uses BF-IBE to encrypt content encryption keys sets the fields of an IBEIdentity object to their appropriate values and then uses that IBEIdentity object to calculate a BF-IBE public key as defined in [IBCS1]. This BF-IBE public key then used to encrypt a content encryption key as defined in [IBCS1]. Martin, Schertler Expires August 26, 2006 [Page 3] Internet-Draft Using BF-IBE with CMS February 2006 Within the CMS, keyEncryptionAlgorithm MUST then be set to bf-ibe (see section 3). The identity of the recipient is then included in the OtherRecipientInfo field. An IBEIdentity object has the following object identifier: IBEIdentity OBJECT IDENTIFIER ::= { 2 16 840 1 114334 1 1 3 1 } 5. Processing by the receiver Upon receiving a message that has a content encryption key encrypted with BF-IBE, the recipient extracts the IBEIdentity from the OtherRecipientInfo field and uses this identity to request the private key that corresponds to the public key for that identity object. The URI of the Private Key Generator (PKG) is constructed using the district field from the IBEIdentity object. To do this, the string “https://ibe-ps-0000.” is prepended to the district, so that the full URI corresponding to the district “example.com#1234” is “https://ibe-ps-0000.example.com#1234,” for example. At this point, the requestor of the private key must authenticate to the PKG. If this authentication is successful, the recipient then uses the BF-IBE private key that he obtains to decrypt the content encryption key. 6. Security Considerations This document is based on [CMS] and [IBCS1], and the relevant security considerations of those documents apply. 7. IANA Considerations All of the OIDs used in this document were assigned by the National Institute of Standards and Technology (NIST), so no further action by the IANA is necessary for this document. Martin, Schertler Expires August 26, 2006 [Page 4] Internet-Draft Using BF-IBE with CMS February 2006 8. References 8.1. Normative References [ASN1] CCITT, Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1998. [CMS] R. Housley, “Cryptographic Message Syntax,” RFC 3369, August 2002. [KEYWORDS] S. Brander, “Key Words for Use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997. 8.2. Informative References [BF] D. Boneh, M. Franklin, "Identity-based encryption from the Weil pairing," Advances in Cryptology – Crypto 2001, Lecture Notes on Computer Science 2139, Springer-Verlag, pp. 213- 229, 2001. [IBCS1] X. Boyen, “The Identity-based Cryptography Standard #1 v.2: Supersingular Curve Implementations of the BF and BB1 Cryptosystems,” December 2005. Author's Addresses Luther Martin Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: martin@voltage.com Mark Schertler Voltage Security 1070 Arastradero Rd Suite 100 Palo Alto CA 94304 Phone: +1 650 543 1280 Email: mark@voltage.com Martin, Schertler Expires August 26, 2006 [Page 5] Internet-Draft Using BF-IBE with CMS February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Martin, Schertler Expires August 26, 2006 [Page 6] Internet-Draft Using BF-IBE with CMS February 2006 Martin, Schertler Expires August 26, 2006 [Page 7]