[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5409

                                                                   L. Martin
     S/MIME Working Group                                       M. Schertler
     Internet Draft                                         Voltage Security
     Expires: December 2006                                        June 2006
     
     
     
          Using the Boneh-Franklin identity-based encryption algorithm with
                       the Cryptographic Message Syntax (CMS)
     
     
                         <draft-ietf-smime-bfibecms-00.txt>
     
     
     Status of this Document
     
        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
     
     
     
     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 content encryption keys. Object
        identifiers and the convention for encoding a recipient’s identity
        are also defined.
     
     
     
     
     
     

     Martin, Schertler       Expires December 2006                  [Page 1]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
     Table of Contents
     
     
        1. Introduction...................................................2
           1.1. Terminology...............................................2
        2. Using identity-based encryption................................3
        3. Algorithm object identifier....................................5
        4. Processing by the sender.......................................6
        5. Processing by the receiver.....................................6
        6. ASN.1 Module...................................................7
        7. Security Considerations........................................9
        8. IANA Considerations............................................9
        9. References....................................................10
           9.1. Normative References.....................................10
        Author's Addresses...............................................10
        Intellectual Property Statement..................................10
        Disclaimer of Validity...........................................11
        Copyright Statement..............................................11
        Acknowledgment...................................................11
     
        1. Introduction
     
        This document defines the steps needed to use the Boneh-Franklin
        identity-based encryption (BF-IBE) public-key algorithm [BF] in the
        Cryptographic Message Syntax (CMS) [CMS]. BF-IBE is a public key
        technology for encrypting content-encryption keys (CEKs). The
        recipient’s identity is incorporated into the EnvelopedData CMS
        content type using the OtherRecipientInfo CHOICE in the RecipientInfo
        field as defined in section 6.2.5 of [CMS]. This document does not
        describe the implementation of the BF-IBE algorithm, which is
        described in detail in [IBCS].
     
        The BF-IBE algorithm is a public-key algorithm in which the public
        key is calculated directly from a user’s identity instead of being
        generated randomly. This document defines the object identifiers and
        syntax of the object that is used to define the identity of a message
        recipient.
     
        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 December 2006                  [Page 2]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
        2. Using identity-based encryption
     
        To use IBE, the OtherRecipientInfo field MUST be set to an
        IBEOtherRecipient type.
     
        IBEOtherRecipientInfo ::= SEQUENCE {
     
           ibeORIType     OBJECT IDENTIFIER,
     
           ibeORIValue    IBERecipientInfo
     
        }
     
        The fields of IBEOtherRecipientInfo have the following meanings:
     
        ibeORIType defines the object identifier (OID)  that indicates that
        the subsequent ibeORIValue is the information necessary to decrypt
        the message using IBE. This field MUST be set to
     
        ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
           us(840) organization(1) identicrypt(114334) ibcs(1)
     
           cms(4) ori-oid(1) }
     
        ibeORIValue defines the identity that was used in the BF-IBE
        algorithm to encrypt the CEK. This is an IBERecipientInfo type.
     
        IBERecipientInfo ::= SEQUENCE {
     
           cmsVersion        INTEGER { v0(0) },
     
           keyFetchMethod    OBJECT IDENTIFIER,
     
           recipientIdentity IBEIdentityInfo,
     
           serverInfo        SEQUENCE OF OIDValuePairs OPTIONAL,
     
           encryptedKey      EncryptedKey
     
        }
     
        The fields of IBERecipientInfo have the following meanings:
     
        cmsVersion MUST be set to 0.
     
     
     
     
     Martin, Schertler       Expires December 2006                  [Page 3]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
        keyFetchMethod is the OID that defines the method of retrieving the
        private key that the recipient MUST use. How to retrieve an IBE
        private key using the steps defined in [IBEPPS] is defined by the
        keyFetchMethod OID. The method for retrieving private keys that is
        specified in [IBEPPS] is defined by cmsPPSOID.
     
        cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
           us(840) organization(1) identicrypt(114334) pps-schemas(3)
     
           ic-schemas(1) pps-uri(1)
     
        }
     
        recipientIdentity is the data that was used to calculate the public
        key that was used to encrypt the CEK. This MUST be an IBEIdentityInfo
        type. This recipientIdentity is used to calculate IBE public and
        private keys as described in [IBCS].
     
        IBEIdentityInfo ::= SEQUENCE {
     
           district    UTF8STRING,
     
           serial      INTEGER,
     
           identitySchema OBJECT IDENTIFIER,
     
           identityData   OCTET STRING
     
        }
     
        The fields of IBEIdentityInfo have the following meanings.
     
        district and serial are unique identifiers that are used to construct
        the URI for the location of where the IBE public parameters are
        located. The construction and use of this URI is defined in [IBEPPS].
     
        identitySchema defines the format that is used to encode the
        information that defines the identity of the recipient. This MUST be
        set to cmsIdentityOID.
     
        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
           us(840) organization(1) identicrypt(114334) keyschemas(2)
     
           icschemas(1) rfc822email(1)
     
     
     
     Martin, Schertler       Expires December 2006                  [Page 4]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
        }
     
        identityData is the data that defines the identity of the recipient.
        This MUST be an EmailIdentitySchema type which is DER encoded.
     
        EmailIdentitySchema ::= SEQUENCE {
     
           rfc822Email UTF8STRING,
     
           time     UTCTime
     
        }
     
        rfc822Email is the DER-encoded e-mail address of the recipient in the
        format defined by [RFC822].
     
        time is the DER-encoded UTC time at which the sender wants to let the
        recipient decrypt the message, so it may be called the “not-before”
        time. This is usually set to the time when the message is encrypted,
        but MAY be set to a future time. UTC time values are expressed to the
        nearest second, but the sender of an IBE-encrypted message may want
        to express this time rounded to a larger time interval to reduce the
        number of IBE private keys that a recipient needs to retrieve. To do
        this, follow the following steps. Let “time-interval” be the number
        of seconds in this larger time interval.
     
           1. Find the UTC time for the not-before value.
     
           2. Convert this UTC time into the number of seconds since
     
              January 1, 1970. Call this “total-time.”
     
           3. Calculate reduced-time = ( floor( total-time /
     
              time-interval ) ) * time-interval.
     
           4. Convert reduced-time to a UTC time to get the not-before value.
     
        3. Algorithm object identifier
     
        The BF-IBE algorithm as defined in [IBCS] has the following object
        identifier:
     
        bf-ibe OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) us(840)
     
           organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
     
     
     
     Martin, Schertler       Expires December 2006                  [Page 5]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
           ibe-algorithms(2) bf(1) }
     
        This is the object identifier that MUST be inserted in the
        keyEncryptionAlgorithm field in the CMS when the BF-IBE algorithm is
        used to encrypt the CEK.
     
        4. Processing by the sender
     
        The sender of a message that uses BF-IBE to encrypt content
        encryption keys performs the following steps:
     
           1. Selects a set of IBE public parameters to use in the subsequent
        steps in accordance with his local security policy. He then
        determines the URI where the public parameters can be obtained using
        the process described in [IBEPPS]. This information MUST be encoded
        in the IBEIdentityInfo as described in [IBEPPS].
     
           2. Sets the fields of an OtherRecipientInfo object to their
        appropriate values as described in Section 2.
     
           3. Calculates a BF-IBE public key as defined in [IBCS] using this
        IBEIdentityInfo as the identity information.
     
           4. This BF-IBE public key is then used to encrypt the content
        encryption key (CEK), using the algorithms that are defined in
        [IBCS].
     
           5. Sets encryptedKey to the BF-IBE-encrypted CEK.
     
           6. Within the CMS, keyEncryptionAlgorithm MUST then be set to bf-
        ibe (see Section 3).
     
        5. Processing by the receiver
     
        Upon receiving a message that has a CEK encrypted with BF-IBE, the
        recipient performs the following steps to decrypt the CEK:
     
           1. Determines that the CEK is IBE-encrypted by noting that the
             oriType of the OtherRecipientInfo type is set to ibeORIType.
     
           2. Determines that the recipientIdentity was used as the identity
             in BF encryption of the CEK.
     
           3. Determines the location of the IBE public parameters and the
             IBE Private Key Generator as described in [IBEPPS].
     
     
     
     
     Martin, Schertler       Expires December 2006                  [Page 6]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
           4. Obtains the IBE public parameters from the location determined
             in Step 3 using the process defined in [IBEPPS].
     
           5. Obtains the IBE private key needed to decrypt the encrypted CEK
             using the process defined in [IBE3].
     
           6. Decrypts the CEK using the IBE private key obtained in Step 4
             using the algorithms described in [IBCS].
     
        6. ASN.1 Module
     
        BFCMS-module { joint-iso-itu(2) country(16) us(840) organization(1)
     
           identicrypt(114334) ibcs(1) cms(4) module(5) version(1)
     
        }
     
     
     
        DEFINITIONS IMPLICIT TAGS ::= BEGIN
     
     
     
        IBEOtherRecipientInfo ::= SEQUENCE {
     
           oriType  OBJECT IDENTIFIER,
     
           oriValue IBERecipientInfo
     
        }
     
     
     
        ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
              us(840) organization(1) identicrypt(114334) ibcs(1)
     
              cms(4) ori-oid(1)
     
        }
     
     
     
        IBERecipientInfo ::= SEQUENCE {
     
           cmsVersion     INTEGER { v0(0) },
     
     
     
     Martin, Schertler       Expires December 2006                  [Page 7]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
           keyFetchMethod OBJECT IDENTIFIER,
     
           recipientIdentity IBEIdentityInfo,
     
           serverInfo     SEQUENCE OF OIDValuePairs OPTIONAL,
     
           encryptedKey   EncryptedKey
     
        }
     
     
     
        IBEIdentityInfo ::= SEQUENCE {
     
           district    UTF8STRING,
     
           serial      INTEGER,
     
           identitySchema OBJECT IDENTIFIER,
     
           identityData   OCTET STRING
     
        }
     
     
     
        OIDValuePairs ::= SEQUENCE {
     
          fieldID     OBJECT IDENTIFIER,
     
          fieldData   OCTET STRING
     
        }
     
     
     
        EmailIdentitySchema ::= SEQUENCE {
     
           rfc822Email UTF8STRING,
     
           time     UTCTime
     
        }
     
     
     
        cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
     
     Martin, Schertler       Expires December 2006                  [Page 8]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
           us(840) organization(1) identicrypt(114334) keyschemas(2)
     
           icschemas(1) rfc822email(1)
     
        }
     
     
     
        cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
     
           us(840) organization(1) identicrypt(114334) pps-schemas(3)
     
           ic-schemas(1) pps-uri(1)
     
        }
     
     
     
        END
     
        7. Security Considerations
     
        This document is based on [CMS] and [IBCS1], and the relevant
        security considerations of those documents apply.
     
        8. IANA Considerations
     
        All of the object identifiers 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 December 2006                  [Page 9]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
        9. References
     
        9.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.
     
        [IBCS]   X. Boyen, L. Martin, “Identity-based cryptography standard
                  (IBCS) #1: supersingular curve implementations of the BF
                  and BB1 cryptosystems,” draft-ieft-smime-ibcs-00.txt.
     
        [IBEPPS] G. Appenzeller, “Parameter and Policy Lookup for Identity-
                  based Encryption,” draft-ietf-ibepps-00.txt.
     
        [KEYWORDS]  S. Brander, “Key Words for Use in RFCs to Indicate
                  Requirement Levels,” BCP 14, RFC 2119, March 1997.
     
        [RFC822] D. Crocker, “Standard for the format of ARPA internet text
                  messages,” RFC 822, August 1982.
     
     Authors’ 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
     
     
     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
     
     
     Martin, Schertler       Expires December 2006                 [Page 10]
     

     Internet-Draft          Using BF-IBE with CMS                 June 2006
     
     
        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 December 2006                 [Page 11]
     

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/