G. Appenzeller
                                                        L. Martin
                                                Stanford University
     S/MIME Working Group                        Voltage Security                                 L. Martin
     Internet Draft                                Voltage Security
     Intended status: Standards Track                  M. Schertler
     Expires: May 2008 February 2009               Tumbleweed Communications
                                                    November 2007
                                                        August 2008

        Identity-based Encryption Architecture

                    <draft-ietf-smime-ibearch-06.txt> and Supporting Data
                                Structures

                     <draft-ietf-smime-ibearch-07.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 security architecture required to
     implement identity-based encryption, a public-key encryption
     technology that uses a user's identity as a public key. It
     also defines data structures that can be used to implement the
     technology.

     Table of Contents

        1. Introduction.........................................3 Introduction.........................................4
           1.1. Terminology.....................................3 Terminology.....................................4
        2. Identity-based Encryption............................3 Encryption............................4
           2.1. Overview........................................3 Overview........................................4
           2.2. Sending a Message that is IBE-encrypted.........4 IBE-encrypted.........6
              2.2.1. Sender Obtains Public Parameters...........5 Parameters...........6
              2.2.2. Construct and Send IBE-encrypted Message...6 Message...7
           2.3. Receiving and Viewing an IBE-encrypted Message..6 Message..8
              2.3.1. Recipient Obtains Public Parameters........7 Parameters........9
              2.3.2. Recipient Obtains IBE Private Key..........8 Key..........9
              2.3.3. Recipient Decrypts IBE-encrypted Message...8 Message..10
        3. Identity Format.....................................10
        4. Public Parameter Lookup..............................9
           3.1. Lookup.............................11
           4.1. Request Method.................................10
           3.2. Method.................................12
           4.2. Parameter and Policy Format....................10
        4. Format....................12
           4.3. The application/ibe-pp-data MIME type..........16
        5. Private Key Request Protocol........................13
           4.1. Overview.......................................13
           4.2. Protocol........................17
           5.1. Overview.......................................17
           5.2. Private Key Request............................14
           4.3. Request............................18
           5.3. Request Structure..............................14
           4.4. Authentication.................................15
           4.5. Structure..............................18
           5.4. The application/ibe-key-request+xml MIME type..20
           5.5. Authentication.................................21
           5.6. Server Response Format.........................16
           4.6. Response Containing a Private Key..............16
           4.7. Responses Containing a Redirect................18
           4.8. Responses Indicating an Error..................18
        5. ASN.1 Module........................................19 Format.........................22
              5.6.1. The IBE100 responseCode...................22
              5.6.2. The IBE101 responseCode...................24
              5.6.3. The IBE201 responseCode...................24
              5.6.4. The IBE300 responseCode...................25
              5.6.5. The IBE301 responseCode...................25
              5.6.6. The IBE303 responseCode...................25
              5.6.7. The IBE304 responseCode...................26
           5.7. The application/ibe-pkg-reply+xml MIME type....26
        6. ASN.1 Module........................................27
        7. Security Considerations.............................21
           6.1. Considerations.............................29
           7.1. Attacks that are outside the scope of this
           document............................................21
           6.2. document.....29
           7.2. Attacks that are within the scope of this
           document............................................22
              6.2.1. document......30
              7.2.1. Attacks to which on the protocols defined in this document are susceptible....................22
        7. IANA Considerations.................................23
              document.........................................30
        8. References..........................................24 IANA Considerations.................................31
           8.1. Normative References...........................24 Media types....................................31
           8.2. XML namespace..................................31
        9. References..........................................33
           9.1. Normative References...........................33
           9.2. Informative References.........................25 References.........................34
        Authors' Addresses.....................................26 Addresses.....................................35
        Intellectual Property Statement........................26 Statement........................35
        Disclaimer of Validity.................................27 Validity.................................36
        Copyright Statement....................................27
        Acknowledgment.........................................27 Statement....................................36
        Acknowledgment.........................................36
     1. Introduction

        This document describes the security architecture required
        to implement identity-based encryption, a public-key
        encryption technology that uses a user's identity as a
        public key. It also defines data structures that are
        required to implement the technology. Objects used in this
        implementation are defined using ASN.1 [ASN1]. [ASN1] and XML
        [XML].

     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 [KEY].

     2. Identity-based Encryption

     2.1. Overview

        Identity-based encryption (IBE) is a public-key encryption
        technology that allows a public key to be calculated from
        an identity and a set of public mathematical parameters and
        for the corresponding private key to be calculated from the an
        identity, a set of public key. A mathematical parameters and a
        domain-wide secret value. An IBE public key can be
        calculated by anyone who has the necessary
        mathematical parameters that are needed for the
        calculation; public
        parameters; a cryptographic secret is needed to calculate a
        an IBE private key, and the calculation can only be
        performed by a trusted server which has this secret.

        Calculation of both the public and private keys in an
        IBE-based IBE
        system can occur as needed, resulting in just-
        in-time key material. just-in-time
        creation of both public and private keys. This contrasts
        with other public-
        key public-key systems [P1363], in which keys are
        generated randomly and distributed prior to secure
        communication commencing. commencing, and in which private encryption
        keys need to be securely archived to allow for their
        recovery if they are lost or destroyed. The ability to
        calculate a recipient's public key, in particular,
        eliminates the need for the sender and receiver in an IBE-based messaging system to interact
        with each other, either directly or through a proxy such as
        a directory server, before sending secure messages.

        A characteristic of IBE systems that differentiates them
        from other server-based cryptographic systems is that once
        a set of public parameters is fetched, encryption is
        possible with no further communication with a server during
        the validity period of the public parameters. Other server-
        based systems may require a connection to a server for each
        encryption operation.

        This document describes an IBE-based messaging system and system, how
        the components of the such a system work together. together, and defines
        data structures that support the operation of such a
        system. The server components required for such a complete IBE messaging system
        are the following:

              o  A Private-key Generator (PKG). The PKG contains
                 the Public Parameter Server (PPS). IBE Public
                 parameters include publicly-sharable cryptographic
                 material, known as a master
                 secret, which is used IBE public parameters, and
                 policy information for generating an
                 individual's IBE private key. A PKG accepts an
                 IBE user's private key request, and after
                 successfully authenticating them in some way
                 returns, their IBE private key.

              o  A Public Parameter Server (PPS). IBE System
                 Parameters include publicly-sharable
                 cryptographic material, known as IBE public
                 parameters, and policy information for an
                 associated PKG. associated PKG. A PPS
                 provides a well-known location for secure
                 distribution of IBE public parameters and policy
                 information for that describe the operation of a PKG.
                 Section 4 of this document describes the protocol
                 that a client uses to communicate with a PPS.

              o  A Private-key Generator (PKG). The PKG stores and
                 uses cryptographic material, known as a master
                 secret, which is used for generating a user's IBE
                 private key. A PKG accepts an IBE user's private
                 key request, and after successfully authenticating
                 them in some way, returns their IBE private key.
                 Section 5 of this document describes the protocol
                 that a client uses to communicate with a PKG.

        A logical architecture of such an IBE system would be to
        have a PKG/PPS PKG and PPS per a name space, such as a DNS zone. The
        organization that controls the DNS zone would also control
        the PKG/PPS PKG and PPS and thus the determination of which PKG/PSS PKG or
        PSS to use when creating public and private keys for the
        organization's members. In this case the PPS URI URI/IRI can be
        uniquely created
        by from a user-friendly name for the form of the
        identity that it supports. This architecture would make it
        clear which set of public parameters to use and where to
        retrieve them for a given identity (for example, an RFC 2822
        2821 address [TEXTMSG]).

        IBE encrypted [SMTP]).

        IBE-encrypted messages can use standard message formats,
        such as the Cryptographic Message Syntax [CMS]. How to use
        IBE with the CMS to encrypt e-mail messages is defined in
        [IBECMS].

        Note that IBE algorithms are used only for encryption, so
        if digital signatures are required they will need to be
        provided by an additional mechanism.

        Section 3 of this document describes the identity format
        that all PPS and PKG servers MUST support.

     2.2. Sending a Message that is IBE-encrypted

        In order to send an encrypted message, an IBE user must
        perform the following steps:

           1. Obtain the recipient's public parameters

              A user of an IBE system is capable of calculating
              the

              The public key parameters of the recipient's system are
              needed to perform IBE operations. Once a recipient after he user obtains the
              these public parameters for their parameters, he can perform IBE system. Once the
              encryption operations. These public parameters are obtained, IBE-encrypted
              messages can may be sent.
              available at a PPS that is operated by the user's
              organization, one that is operated by the sender's
              organization, or by a different organization
              entirely.

           2. Construct and Send IBE-encrypted Message

              In addition to the IBE public parameters, all that is
              needed to construct an IBE-encrypted message is the
              recipient's identity, the form of which can be used to
              generate their is defined by
              the public key. parameters. When this identity is the same
              as the identity that a message would be addressed to,
              then no more information is needed from a user to
              send them a secure an encrypted message then is needed to send
              them an unsecured unencrypted message. This is one of the major
              benefits of an IBE-based secure messaging system.
              Examples of identities can be an individual, group,
              or role identifiers.

     2.2.1. Sender Obtains Public Parameters

        The sender of a message obtains the IBE public parameters
        that he needs for calculating the IBE public key of the
        recipient from a PPS that is hosted at a well-known URI. URI
        or IRI. The IBE public parameters contain all of the
        information that the sender needs to create an IBE-encrypted IBE-
        encrypted message except for the identity of the recipient.
        Section 3 4 of this document describes the URI [URI] where or IRI
        [IRI] of a PPS is
        located, PPS, the format of IBE public parameters, and
        how to obtain them. them from a PPS. The URI or IRI from which
        users obtain IBE public parameters MUST be authenticated in
        some way; way. PPS servers MUST support TLS 1.1 [TLS] to satisfy
        this requirement.
        Section 3 also describes the way in which identity
        formats are defined and a minimum interoperable format
        that all PPSs and PKGs MUST support. This step is shown below in Figure 1.

                     IBE Public Parameter Request
                    ----------------------------->
             Sender                                PPS
                    <-----------------------------
                         IBE Public Parameters

                 Figure 1 Requesting IBE Public Parameters

        The sender of an IBE-encrypted message selects the PPS and
        corresponding PKG based on his local security policy.
        Different PPSs PPS servers may provide public parameters that
        specify different IBE algorithms or different key
        strengths, for example, or require the use of PKGs PKG servers
        that require different levels of authentication before
        granting IBE private keys.

     2.2.2. Construct and Send IBE-encrypted Message

        To IBE-encrypt a message, the sender chooses a content-
        encryption key (CEK) and uses it to encrypt his message and
        then encrypts the CEK with the recipient's IBE public key
        as described in [CMS]. This operation is shown below in
        Figure 2. The document [IBCS] describes the algorithms
        needed to implement two forms of IBE and [IBECMS] describes
        how to use the Cryptographic Message Syntax (CMS) to
        encapsulate the encrypted message along with the IBE
        information that the recipient needs to decrypt the an e-mail
        message.

                      CEK ----> Sender ----> IBE-encrypted CEK

                                  ^
                                  |
                                  |

                         Recipient's Identity
                       and IBE Public Parameters

           Figure 2 Using an IBE Public-key Algorithm to Encrypt
     2.3. Receiving and Viewing an IBE-encrypted Message

        In order to read an encrypted IBE-encrypted message, a recipient of an
        IBE-encrypted
        such a message parses the message as described in
        [IBECMS]. This gives him to find the URI or IRI he
        needs to obtain the IBE public parameters that are required
        to perform IBE calculations as well as a component of the
        identity that was used to encrypt the message. Next the
        recipient must
        carry carries out the following steps:

           1. Obtain the recipient's IBE public parameters

              An IBE system's public parameters allow it to
              uniquely create public and private keys. The
              recipient of an IBE-encrypted message can decrypt an
              IBE-encrypted message if he has both the IBE public
              parameters and the necessary IBE private key. The PPS can
              public parameters also provide the URI or IRI of the
              PKG where the recipient of an IBE-encrypted message
              can obtain the IBE private keys.

           2. Obtain the IBE private key from the PKG

              To decrypt an IBE-encrypted message, in addition to
              the IBE public parameters parameters, the recipient needs to
              obtain the private key that corresponds to the public
              key that the sender used. The IBE private key is
              obtained after successfully authenticating to a
              private key generator (PKG), a trusted third party
              that calculates private keys for users. The recipient
              then receives the IBE private key over a secure
              connection.

           3. Decrypt IBE-encrypted message

              The IBE private key decrypts the CEK (see section Section
              2.2.2). The CEK is then used to decrypt encrypted
              message.

        The PKG

        It may be useful for a PKG to allow users other than the
        intended recipient to receive some IBE private keys. Giving
        a mail filtering appliance permission to obtain IBE private
        keys on behalf of users, for example, can allow the
        appliance to decrypt and scan encrypted messages for
        viruses or other malicious features.

     2.3.1. Recipient Obtains Public Parameters

        Before he can perform any IBE calculations related to the
        message that he has received, the recipient of an IBE-
        encrypted message needs to obtain the IBE public parameters
        that were used in the encryption operation. This operation
        is shown below in Figure 3. Because the use of the correct
        public parameters is vital to the overall security of an
        IBE system, IBE public parameters MUST be transported to
        recipients over a secure protocol.
        PPSs PPS servers MUST support
        TLS 1.1 [TLS] or its successors, using the latest version
        supported by both parties, for transport of IBE public
        parameters. In addition, users MUST verify that the subject
        name in the server certificate matches the URI URI/IRI of the
        PPS. The comments in Section 2.2.1 also apply to this
        operation.

                        IBE Public Parameter Request
                       ----------------------------->
             Recipient                                PPS
                       <-----------------------------
                            IBE Public Parameters

                 Figure 3 Requesting IBE Public Parameters

     2.3.2. Recipient Obtains IBE Private Key

        To obtain an IBE private key, the recipient of an IBE-
        encrypted message provides the IBE public key used to
        encrypt the message and their authentication credentials to
        a PKG and requests the private key that corresponds to the
        IBE public key. Section 4 5 of this document defines the
        protocol for communicating with a PKG as well as a minimum
        interoperable way to authenticate to a PKG that all IBE
        implementations MUST support. Because the security of IBE
        private keys is vital to the overall security of an IBE
        system, IBE private keys MUST be transported to recipients
        over a secure protocol. PKGs PKG servers MUST support TLS 1.1
        [TLS] or its successors, using the latest version supported
        by both parties, for transport of IBE private keys. This
        operation is shown below in Figure 4.

                          IBE Private Key Request
                       ---------------------------->
             Recipient                                PKG
                       <----------------------------
                              IBE Private Key

                   Figure 4 Obtaining an IBE Private Key

     2.3.3. Recipient Decrypts IBE-encrypted Message

        After obtaining the necessary IBE private key, the
        recipient uses that IBE private key and the corresponding
        IBE public parameters to decrypt the CEK. This operation is
        shown below in Figure 5. He then uses the CEK to decrypt
        the encrypted message content as specified content. An example of how to do this
        with e-mail messages is given in [IBECMS].

        IBE-encrypted CEK ----> Recipient ----> CEK

                                    ^
                                    |
                                    |

                            IBE Private Key
                        and IBE Public Parameters

           Figure 5 Using an IBE Public-key Algorithm to Decrypt

     3. Public Parameter Lookup

        For an identity-based encryption (IBE) system Identity Format

        An IBEIdentityInfo type MUST be used to operate, represent the sender, receiver and
        identity of a recipient. This is defined to be the
        following:

        IBEIdentityInfo ::= SEQUENCE {
          district        IA5String,
          serial          INTEGER,
          identityType    OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }

        An IBEIdentityInfo type is used to calculate public and
        private key generator (PKG)
        must agree on a number IBE keys. Because of parameters, specifically:

          1. this, such a structure is
        typically DER-encoded [DER].

        The Public Parameters fields of an IBEIdentityInfo structure have the PKG.
        following meanings.

        The public
             parameters are part of the encryption (and in some
             cases decryption) operation of the IBE system.
             Generation of public parameters and district is an IA5String that represents the master
             secret, as well as URI [URI]
        or IRI [IRI] where the mathematical structure recipient of an IBE-encrypted
        message can retrieve the IBE public parameters needed to
        encrypt or decrypt a message encrypted for this identity.
        Applications MUST support the BF and BB1 algorithms are method described in [IBCS].

          2. The URI of the PKG. Knowledge of Section 4
        for doing this URI allows
             recipients and MAY support other methods. IRIs MUST be
        handled according to request a private key as described the procedures specified in Section 4
        7.4 of this document.

          3. [PKIX].

        The schema to format the identity strings. When
             issuing a private key, the PKG often wants to limit
             who can obtain private keys. For example for serial is an
             identity string INTEGER that contains "bob@example.com,"
             only the owner defines a unique set of IBE
        public parameters in the identity string should be able
             to request the private key. To ensure event that the PKG
             can interpret the identity string for which more than one set of
        parameters is used by a
             private key single district.

        identityType is requested, an OBJECT IDENTIFIER that defines the encryption engine and
        format that the PKG have identityData field is encoded with.

        An example of a useful IBEIdentityInfo type is given in
        [IBECMS]. This example is tailored to the use of IBE in
        encrypting e-mail. Because the same schema for information that comprises
        an identity
             strings. Identity schemas are described in [IBECMS] is very dependent on the application, this
        document does not define an identityType that all
        applications MUST support.

     4. Public Parameter Lookup

        This section specifies how a component of an IBE system can
        retrieve these parameters. A sending or receiving client
        MUST allow configuration of these parameters manually, e.g. for
        example, through editing a configuration file. However for
        simplified configuration a client MAY SHOULD also implement the PP URI
        public parameter URI/IRI request method described in this
        document to fetch the system public parameters based on a
        configured URI. URI/IRI. This is especially useful for
        federating between IBE systems. By specifying a single URI
        URI/IRI, a client can be configured to fetch all the
        relevant parameters for a remote PKG. These public
        parameters can then be used to encrypt messages to
        recipients who authenticate to and retrieve private keys
        from that PKG.

        The following section outlines the URI URI/IRI request method
        to retrieve a parameter block and describes the structure
        of the parameter block itself.

     3.1. The technique for fetching
        IBE public parameters using the process defined in this
        section is indicated by the OBJECT IDENTIFIER uriPPSOID,
        which is defined to be the following:

        uriPPSOID OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840)
          organization(1) identicrypt(114334)
          pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
        }

     4.1. Request Method

        The configuration URI URI/IRI SHOULD be an HTTPS URI [HTTP] of
        the format:

          http_URI = "https:" "//" host [ ":" port ] [ abs_path ]

        An example URI and
        MAY additionally support IRIs [IRI] for ibe system parameters is

          https://ibe-0000.example.com/example.com.pp this purpose. To
        retrieve the IBE system public parameters, the client SHOULD use
        the HTTP GET method as defined in [HTTP]. The request MUST
        happen over a secure protocol. The requesting client MUST
        support TLS 1.1 [TLS] or its successors and SHOULD use the
        latest version supported by both parties. When requesting
        the URI URI/IRI the client MUST only accept the system
        parameter block if the server identity was verified
        successfully by TLS 1.1 [TLS] or its successors.

        A successful GET request returns in its body the Base64 base64
        [B64] encoding of the DER-encoded [DER] IBESysParams
        structure that is described in the next section. This
        structure MUST be served encoded as an application/octet-stream application/ibe-pp-data
        MIME type
        [MIME].

     3.2. type.

     4.2. Parameter and Policy Format

        The IBE System Public parameters are a structure of the form

        IBESysParams ::= SEQUENCE {
           version              INTEGER { v2(2) },
           districtName         IA5String,
           districtSerial       INTEGER,
           validity             ValidityPeriod,
           ibePublicParameters  IBEPublicParameters,
           ibeIdentitySchema
           ibeIdentityType      OBJECT IDENTIFIER,
           ibeParamExtensions   IBEParamExtensions OPTIONAL
        }

        The fields of an IBESysParams structure have the following
        meanings.

        The version field specifies the version of the IBESysParams
        format. For the format described in this document it document, this
        MUST be set to 2.

        The district name districtName field is an IA5String that MUST be a valid domain name as defined by [DOM]. The
        districtSerial is a serial number that represents a
        unique set of an
        encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled
        according to the procedures specified in Section 7.4 of
        [PKIX].

        The districtSerial field is an integer that represents a
        unique set of IBE public parameters. parameters that are available at
        the URI or IRI defined by the districtName. If new
        parameters are published for a district, it districtName, the
        districtSerial MUST be increased to a number greater than
        the previously-used serial number. districtSerial.

        The validity period or field defines lifetime of a specific instance
        of the IBESysParams and is defined as follows: to be the following:

        ValidityPeriod ::= SEQUENCE {
          notBefore     GeneralizedTime,
          notAfter      GeneralizedTime
        }

        A client MUST verify that the date on which it utilizes uses the IBE system
        public parameters falls between the notBefore time and the
        notAfter time of the IBE system public parameters and SHOULD not MUST NOT use
        the parameters for IBE encryption operations if they do
        not.

        IBE system public parameters MUST be regenerated and republished
        whenever the values of ibePublicParameters, ibeIdentitySchema,
        ibeIdentityType, or ibeParamExtensions change for a
        district. A client SHOULD refetch the IBE system public parameters
        at an application-
        configurable application-configurable interval to ensure that it
        has the most current version on the IBE system public parameters.

        It is possible to create identities for use in IBE that
        have a time component, as described in [IBECMS]. [IBECMS], for
        example. If such an identity is used, the time component of
        the identity MUST fall between the notBefore time and the
        notAfter times of the IBE system public parameters.

        IBEPublicParameters is a structure containing public
        parameters that correspond to IBE algorithms that the PKG
        associated with this district understands.
        supports. This structure is defined to be following:

        IBEPublicParameters ::= SEQUENCE (1..MAX) OF
          IBEPublicParameter

        IBEPublicParameter  ::= SEQUENCE {
          ibeAlgorithm          OBJECT IDENTIFIER,
          publicParameterData   OCTET STRING
        }

        The ibeAlgorithm OID OBJECT IDENTIFIER specifies an IBE
        algorithm. The OIDs for two IBE algorithms, the Boneh-
        Franklin and Boneh-Boyen algorithms and their
        publicParameterData structures are defined in [IBCS].

        The publicParameterData is a DER-encoded [DER] structure
        that contains the actual cryptographic parameters. Its
        specific structure depends on the algorithm.

        The OIDs for
        two IBE algorithms, the Boneh-Franklin and Boneh-Boyen
        algorithms and their publicParameterData structures are
        defined in [IBCS].

        The IBESysParams of a district MUST contain an OID that
        identifies at least one algorithm and MAY contain several algorithms. OIDs that
        identify more than one algorithm. It MUST NOT contain two
        or more IBEPublicParameter entries with the same algorithm.
        A client that wants to use IBESysParams can chose any of
        the algorithms specified in the publicParameterData
        structure. A client MUST implement at least the Boneh-Franklin Boneh-
        Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen
        [IBCS] and other algorithms. If a client does not support
        any of the supported algorithms it MUST generate an error
        message and fail.

        ibeIdentitySchema

        ibeIdentityType is an OID that defines the type of
        identities that are used with this district. The OIDs and
        the required and optional fields for each OID are
        described
        application dependent. An example of this is given in [IBECMS].
        [IBECMS], which defines an identity format suitable for use
        in encrypting e-mail.

        IBEParamExtensions is a set of extensions that can be used
        to define additional parameters that particular
        implementations may require. This structure is defined as
        follows:

        IBEParamExtensions ::= SEQUENCE OF IBEParamExtension

        IBEParamExtension ::= SEQUENCE {
          ibeParamExtensionOID     OBJECT IDENTIFIER,
          ibeParamExtensionValue   OCTET STRING
        }

        The contents of the octet string ibeParamExtensionValue are
        defined by the specific extension type. ibeParamExtensionOID. The System Parameters
        IBEParamExtensions of a district MAY have any number of
        extensions, including zero.

        The IBEParamExtension pkgURI defines the URI of the
        Private Key Generator One example of the district. If the PKG extensions that
        have been used in practice is
        publicly accessible, this extension SHOULD be present to
        allow the automatic retrieval provide a URI where an
        encrypted message can be decrypted and viewed by users of private keys
        webmail systems. Another example is to provide commercial
        branding information, so that a bank can provide a
        different user interface for
        recipients customers of encrypted messages. For this different lines
        of business.

        If a client receives Public parameters that contain an
        extension the
        OCTET STRING that it is an IA5String unable to process, it MUST NOT use the
        values in the IBESysParams structure for any cryptographic
        operations. Clients MUST be able to process an IBESysParams
        structure that contains no IBEParamExtensions.

        The pkgURI OBJECT IDENTIFIER that is defined below defines
        an IBEParamExtensions structure that contains the URI or
        IRI of a Private Key Generator. The presence of this OBJECT
        IDENTIFIER in an IBEParamExtension indicates that clients
        MUST use the protocol defined in Section 5 of this document
        to obtain IBE private keys from the PKG and do so using the
        URI/IRI that is defined by the value defined by the
        ibeParamExtensionValue in the IBEParamExtension.

        If the PKG is publicly-accessible, this extension SHOULD be
        present to allow the automatic retrieval of private keys
        for recipients of encrypted messages. For this extension
        the ibeParamExtensionValue OCTET STRING is an IA5String
        containing the URI [URI] or IRI [IRI] of the
        key server. PKG where IBE
        private keys can be obtained. IRIs MUST be handled
        according to the procedures specified in Section 7.4 of
        [PKIX].

        ibeParamExt OBJECT IDENTIFIER ::= {
          ibcs ibcs3(3) parameter-extensions(2)
        }

        pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }

     4. Private Key Request Protocol

     4.1.  Overview

        In an identity-based encryption (IBE) system messages are
        encrypted using a public key that

     4.3. The application/ibe-pp-data MIME type

        The following summarizes the properties of the
        application/ibe-pp-data MIME type.

        MIME media type name: application

        MIME subtype name: ibe-pp-data

        Mandatory parameters: The single required parameter is locally calculated
        from a
        base64-encoded DER-encoded IBESysParams structure.

        Optional parameters: There are no optional parameters.

        Encoding considerations: This media type MUST be encoded as
        7bit (us-ascii text [ASCII]).

        Security considerations: The data conveyed as this media
        type are the public parameters and a user`s identity and
        decrypted using needed for the operation of
        a private key cryptographic system. To ensure that corresponds to the
        user`s public key. These private keys are generated by a
        private key generator (PKG) based on a global secret
        called parameters can
        be trusted, the request for these parameters must take
        place over a master secret. secure protocol, TLS 1.1 or its successors. To
        ensure the validity of the server, the client MUST verify
        the server certificate and MUST abort the parameter request
        if the verification of the server certificate of the TLS
        connection fails. This media type contains no active
        content and does not use compression.

        Interoperability considerations: There are no known
        interoperability considerations for this media type.

        Applications that use this media type: Applications that
        implement IBE in compliance with this specification will
        use this media type. The most commonly-used of these
        applications are encrypted email and file encryption.

        Additional information: This media type is used for the
        response from a public parameter server after receiving a
        request for IBE public parameters. This media type contains
        no active content and does not use compression.

        Person and email address for further information: Luther
        Martin, martin@voltage.com.

        Intended usage: COMMON.

        Author/Change controller: Luther Martin,
        martin@voltage.com.

     5. Private Key Request Protocol

     5.1.  Overview

        When requesting a private key, a client has to transmit
        two
        three parameters:

           1. The IBE algorithm for which the key is being
              requested

           2. The identity for which it is requesting a key

           2.

           3. Authentication credentials for the individual
              requesting the key

        These two are often not the same as a single user may have
        access to multiple aliases. For example an email user may
        have access to the keys that correspond to two different
        email addresses, e.g. bob@example.com and
        bob.smith@example.com.

        This section defines the protocol to request private keys,
        a minimum user authentication method for interoperability,
        and how to pass authentication
        credentials pass authentication credentials to the server.
        It assumes that a client has already determined the URI/IRI
        of the PKG. This can be done from information included in
        the IBE message format and the public parameters of the IBE
        system.

        The technique for fetching an IBE private key using the
        process defined in this section is indicated by the OBJECT
        IDENTIFIER pkgURI, which is defined to be the following:

        ibcs OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840)
          organization(1) identicrypt(114334) ibcs(1)
        }

        ibeParamExt OBJECT IDENTIFIER ::= {
          ibcs ibcs3(3) parameter-extensions(2)
        }

        pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }

     5.2. Private Key Request

        To request a private key, a client MUST perform a HTTP POST
        method as defined in [HTTP]. The request MUST take place
        over a secure protocol. The requesting client MUST support
        TLS 1.1 [TLS] or its successors, using the latest version
        supported by both the client and the PKG. When requesting
        the URI/IRI the client MUST verify the server certificate
        [HTTPTLS], and MUST abort the key request if the server
        certificate verification of the TLS connection fails. Doing
        so is critical to protect the authentication credentials
        and the private key against man-in-the-middle attacks when
        it is transmitted from the key server to the client.

     5.3. Request Structure

        The POST method contains in its body the following XML
        structure that MUST be encoded as an application/ibe-key-
        request+xml MIME type:

        <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:header>
              <ibe:client version="clientID"/>
           </ibe:header>
           <ibe:body>
           <ibe:keyRequest>
              <ibe:algorithm>
                 algorithmOID
              </ibe:algorithm>
              <ibe:id>
                 ibeIdentityInfo
              </ibe:id>
           </ibe:keyRequest>
           <ibe:authData>
              ibeAuthData
           </ibe:authData>
           </ibe:body>
        </ibe:request>

        A <ibe:request> SHOULD include an <ibe:client> element in
        the <ibe:header> part of a key request that contains an
        ASCII string that identifies the client type and client
        version.

        A key request MUST contain an <ibe:oid> element that
        contains the base64 [B64] encoding of a DER-encoded [DER]
        object identifier that identifies the algorithm for which a
        key is requested. OIDs for the BB1 and BF algorithms are
        listed in [IBCS].

        A key request MUST contain an <ibe:id> element that
        contains the identity that the private key is being
        requested for. This identity is the base64 [B64] encoding
        of a DER-encoded [DER] ASN.1 structure. This structure
        defines a user's identity in a way appropriate for the
        application.  An example of such a structure that is
        appropriate for use in encrypting e-mail is defined in
        [IBECMS].

        A key request MAY contain an <ibe:authData> element. This
        element contains authentication information that the PKG
        can use to determine whether or not a request for a
        particular IBE private key should be granted.

        A client MAY include optional additional XML elements in
        the <ibe:body> part of the key request. A PKG MUST be able
        to process key requests that contain no such optional
        elements.

     5.4. The application/ibe-key-request+xml MIME type

        The following summarizes the properties of the application/
        ibe-key-request+xml MIME type.

        MIME media type name: application

        MIME subtype name: ibe-key-request+xml

        Mandatory parameters: The required parameters are the
        identity for which an IBE private key is being requested
        and an object identifier that identifies which
        cryptographic algorithm the key is being requested for. The
        identity is the base64-encoding of a DER-encoded
        ibeIdentityInfo structure. The object identifier is the
        base64-encoding of a DER-encoded object identifier, like
        those defined in [IBCS].

        Optional parameters: Any optional parameters may be defined
        by an administrator of a particular PKG. The most common
        optional parameter is an authentication credential. A PKG
        may redirect a request for an IBE private key to an
        external authentication mechanism, the reply from which is
        then included as this optional parameter in a subsequent
        key request. Other optional parameters may include other
        information as required by particular implementations. An
        example of this from an existing implementation is a bank
        that has clients pass branding information along with a key
        request so that mortgage customers see a different user
        interface than non-mortgage customers do, for example.

        Encoding considerations: This media type MUST be encoded as
        us-ascii [ASCII].

        Security considerations: The data conveyed in this media
        type may contain authentication credentials. Because of
        this, its confidentiality and integrity is extremely
        important. To ensure this, the request for an IBE private
        key must take place over a secure protocol, TLS 1.1 or its
        successors. To ensure the validity of the server, the
        client MUST verify the server certificate and MUST abort
        the key request if the verification of the server
        certificate of the TLS connection fails. This media type
        contains no active content and does not use compression.

        Interoperability considerations: There are no known
        interoperability considerations for this media type.

        Applications that use this media type: Applications that
        implement IBE in compliance with this specification will
        use this media type. The most commonly-used of these
        applications are encrypted email and file encryption.

        Additional information: This media type is used for the
        data that is passed to an IBE PKG by a client requesting an
        IBE private key. This media type contains no active content
        and does not use compression.

        Person and email address for further information: Luther
        Martin, martin@voltage.com.

        Intended usage: COMMON.

        Author/Change controller: Luther Martin,
        martin@voltage.com.

     5.5. Authentication

        When a client requests a key from a PKG, the PKG MUST
        authenticate the client before issuing the key.
        Authentication may either be done through the key request
        structure or as part of the secure transport protocol.

        A client or server implementing the request protocol MUST
        support HTTP Basic Auth [AUTH] and SHOULD also support HTTP
        Digest Auth [AUTH]. Applications MAY also use other means
        of authentication that are appropriate for the application.
        An e-mail application, for example, might rely on deployed
        e-mail infrastructure for this, for example.

        For authentication methods that are not done by the
        transport protocol, a client MAY include additional
        authentication information in XML elements in the
        <ibe:authData> element of a key request. If a client does
        not know how to authenticate to the server. It assumes that a client has
        already determined server, the URI of client MAY
        send a key request without authentication information. If
        the PKG. This can be done
        from hints included in key server requires the IBE message format [IBECMS]
        and client to authenticate
        externally, it MAY reply with an IBE201 responseCode as
        defined below to redirect the system parameters of client to the IBE system.

     4.2. Private Key Request

        To request a private key, correct
        authentication mechanism. After receiving an authentication
        credential from this external mechanism, a client performs can then
        use the credential to form a HTTP POST
        method as defined in [HTTP]. The key request MUST happen over
        a secure protocol. that contains the
        additional authentication data.

     5.6. Server Response Format

        The requesting client MUST support TLS
        1.1 [TLS] or its successors, using key server replies to the latest version
        supported by both HTTP request with an HTTP
        response. If the response contains a client and the PKG. When requesting
        the URI error or server
        error status code, the client MUST verify the server certificate
        [HTTPTLS], and MUST abort the key request if the server
        certificate verification of the TLS connection fails.
        Doing so is critical to protect the authentication
        credentials
        and fail.

        If the private key against man-in-the-middle
        attacks when it is transmitted from the key server to PKG replies with an HTTP response that has a status
        code indicating success, the
        client.

     4.3. Request Structure

        The POST method contains in its body of the reply MUST contain
        the following XML structure that MUST be encoded as an
        application/xhtml+xml
        application/ibe-pkg-reply+xml MIME type [XHTML]:

        <ibe:request type:

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:header>
              <ibe:client version="clientID"/>
           </ibe:header>
           <ibe:body>
           <ibe:keyRequest>
              <ibe:algorithm>
                <oid> algorithmOID </oid>
              </ibe:algorithm>
              <ibe:id>
              ibeIdentityInfo
              </ibe:id>
           </ibe:keyRequest>
           </ibe:body>
        </ibe:request>

        A <ibe:request> SHOULD include a <ibe:clientID> element,
           <ibe:responseType value="responseCode"/>
           <ibe:body>
              bodyTags
           </ibe:body>
        </ibe:response>

        The responseCode attribute contains an ASCII string that identifies
        describes the client type of response from the key server. The
        list of currently-defined responseCodes and
        client version.

        A their
        associated meanings is:

         IBE100 KEY_FOLLOWS
         IBE101 RESERVED
         IBE201 FOLLOW_ENROLL_URI
         IBE300 SYSTEM_ERROR
         IBE301 INVALID_REQUEST
         IBE303 CLIENT_OBSOLETE
         IBE304 AUTHORIZATION DENIED

     5.6.1. The IBE100 responseCode

        If the key request was successful, the key server responds
        with a responseCode of IBE100, and the <ibe:body> MUST
        contain a valid ibeIdentityInfo <ibe:privateKey> element that
        the contains a valid
        private key key. An example of this is requested for. This identity shown below.

          <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
             <ibe:responseType value="IBE100"/>
             <ibe:body>
                <ibe:privateKey>
                  privateKey
                </ibe:privateKey>
             </ibe:body>
          </ibe:response>

        The privateKey is the base64 [B64] encoding of the DER
        encoding [DER] of the
        structure following structure:

        IBEPrivateKeyReply ::= SEQUENCE {
           pkgIdentity    IBEIdentityInfo, an example of which is defined
        in [IBECMS].

        A key request MUST contain a <ibe:algorithmOID> element
        that contains a DER-encoded [DER]
           pgkAlgorithm   OBJECT IDENTIFIER that
        identifies the algorithm for which a key IDENTIFIER,
           pkgKeyData     OCTET STRING,
           pkgOptions     SEQUENCE SIZE (1..MAX) OF PKGOption
        }

        PKGOption ::=  SEQUENCE  {
             optionID    OBJECT IDENTIFIER,
             optionValue OCTET STRING
        }

        The pkgIdentity is requested.
        OIDs for an IBEIdentityInfo structure that MUST
        be identical to the BB1 and BF algorithms are listed in [IBCS].

        A client MAY include optional additional XML elements IBEIdentityInfo structure that was sent
        in the <ibe:body> part of the key request.

     4.4. Authentication

        When a client requests a key from a PKG, the PKG SHOULD
        authenticate the client before issuing the key.
        Authentication may either be done through

        The pkgAlgorithm is an OID that identifies the key request
        structure or as part algorithm of
        the secure transport protocol.

        A client or server implementing the request protocol MUST
        support HTTP Basic Auth as described in [AUTH]. A client
        and server SHOULD also support HTTP Digest Auth as returned private key. The OIDs for the BB and BF
        algorithms are defined in [AUTH].

        For authentication methods [IBCS].

        The pkgKeyData is a structure that are not done by contains the
        transport protocol, a client actual
        private key. Private-key formats for the BB and BF
        algorithms are defined in [IBCS].

        A server MAY include pass back additional
        authentication information in xml elements in the body
        part of the key request. If a client does not know how to
        authenticate to a server, client
        in the pkgOptions structure. A client MAY send that receives a key
        request without authentication information. If
        IBEPrivateKeyReply from a PKG that contains information in
        a pkgOptions structure that it is unable process MUST NOT
        use the IBE private key
        server requires the client to authenticate externally, it
        MAY reply with a 201 response code as defined below to
        redirect in the IBEPrivateKeyReply structure
        for any cryptographic operations. A client MUST be able to the correct authentication
        mechanism.

     4.5. Server Response Format
        process an IBEPrivateKeyReply that contains no PKGOptions
        structure.

     5.6.2. The key server replies IBE101 responseCode

        The responseCode IBE101 is reserved to ensure
        interoperability with earlier versions of the HTTP request protocol that
        is described in this document. An example of such a
        response is shown below. A response with an HTTP
        response. the IBE101
        responseCode SHOULD contain no body. If information is
        contained in the response contains body of such a client error or
        server error status code, response, the client
        receiving the response MUST abort discard any data that is
        contained in the key
        request and fail.

        If body.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="IBE101"/>
           <ibe:body>
              This message must be discarded by the recipient
           </ibe:body
        </ibe:response>

     5.6.3. The IBE201 responseCode

        A PKG MAY support authenticating users to external
        authentication mechanisms. If this is the case, the server
        replies with a HTTP response that has a status
        code indicating success, to the client with responseCode IBE201 and the body
        of the reply response MUST contain the following XML structure a <ibe:location> element that MUST be encoded
        as an application/xhtml+xml MIME type [XHTML]:
        specifies the URI of the authentication mechanism. An
        example of such a response is shown below.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="responseCode"/> value="IBE201"/>
           <ibe:body>
              bodyTags
              <ibe:location
                 URI="http://www.example.com/enroll.asp"/>
           </ibe:body>
        </ibe:response>

        The responseCode describes client can now contact the type of URI returned in such a
        response from using the
        key server. The list of currently same mechanisms as defined response codes
        is:

         100  KEY_FOLLOWS
         101  RESERVED
         201  FOLLOW_ENROLL_URI
         300  SYSTEM_ERROR
         301  INVALID_REQUEST
         303  CLIENT_OBSOLETE
         304  AUTHORIZATION DENIED

     4.6. Response Containing a Private Key

        If in Section
        4.2 to obtain an authentication credential. Once the client
        has obtained the credential from the authentication
        mechanism at this URI, it sends a new key request was successful, to the key server
        responds
        PKG with KEY FOLLOWS, and the <ibe:body> must
        contain correct authentication credentials contained
        in the request, placing the authentication credential in
        the <ibe:authData> element of a <ibe:privateKey> tag with key request as described in
        Section 4.4.

     5.6.4. The IBE300 responseCode

        The IBE300 responseCode indicates that an internal server
        error has occurred. Information that may help diagnose the
        error MAY be included in the body of such a valid private key. response. An
        example of this such a response is shown below. Upon receiving a
        IBE300 responseCode, the client MUST abort the key request
        and discard any data that was included in the body of the
        response.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="100"/> value="IBE300"/>
           <ibe:body>
                <ibe:privateKey>
                  privateKey
                </ibe:privateKey>
              Widget phlebotomy failure
           </ibe:body>
        </ibe:response>

     5.6.5. The privateKey is the Base64 [B64] encoding of the DER
        encoding [DER] of the following structure:

        IBEPrivateKeyReply ::= SEQUENCE {
           pkgIdentity    IBEIdentityInfo,
           pgkAlgorithm   OBJECT IDENTIFIER,
           pkgKeyData     OCTET STRING,
           pkgOptions     SEQUENCE SIZE (1..MAX) OF PKGOption
        }

        PKGOption  ::=  SEQUENCE  {
             optionID    OBJECT IDENTIFIER,
             critical    BOOLEAN DEFAULT FALSE,
             optionValue OCTET STRING
        } IBE301 responseCode

        The pkgIdentity is an IBEIdentityInfo structure as
        defined in [IBECMS]. It MUST be identical to IBE303 responseCode indicates that an invalid key
        request has been received by the
        IBEIdentityInfo structure server. Information that was sent
        may help diagnose the error MAY be included in the key
        request.

        The pkgAlgorithm body of
        such a response. An example of such a response is shown
        below. Upon receiving an OID IBE301 responseCode, the client
        MUST abort the key request and discard any data that identifies was
        included in the algorithm body of the returned private key. response.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="IBE301"/>
           <ibe:body>
              Some additional stuff
           </ibe:body>
        </ibe:response>

     5.6.6. The OIDs for the BB and BF
        algorithms are defined in [IBCS]. IBE303 responseCode

        The pkgKeyData is a structure IBE303 responseCode indicates that contains the actual
        private key. Private-key formats for the BB and BF
        algorithms are defined in [IBCS].

        A server MAY pass back additional information to a client
        in the pkgOptions structure.

     4.7. Responses Containing a Redirect

        A Key Server MAY support authenticating user to external
        authentication mechanism. If this is unable
        to correctly process the case, request because the server
        replies to version of the client with response code 201 and
        request is no longer supported by the body
        MUST contain a <ibe:location> element server. Information
        that specifies may help diagnose the
        URI of error MAY be included in the authentication mechanism. Such
        body of such a response MUST
        be encoded as an application/xhtml+xml MIME type [XHTML]. response. An example of such a response is
        shown below. Upon receiving an IBE303 responseCode, the
        client MUST abort the key request and discard any data that
        was included in the body of the response.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="201"/> value="IBE303"/>
           <ibe:body>
              <ibe:location
                 URI="http://www.example.com/enroll.asp"/>
              Version 3.3 or later needed
           </ibe:body>
        </ibe:response>

     5.6.7. The client can now contact the authentication mechanism
        to obtain authentication credentials. Once the client has
        obtained the credential, it sends IBE304 responseCode

        The IBE304 responseCode indicates that a new valid key request to
        has been received by the PKG with server but the correct authentication
        credentials
        contained in provided were invalid. Information that may
        help diagnose the request.

     4.8. Responses Indicating an Error

        If error MAY be included in the server replies with body of such
        a response. An example of such a response is shown below.
        Upon receiving an error code from 300 through
        399, IBE304 responseCode, the client MUST
        abort the key request and discard any data that is part was
        included in the body of the response.

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="IBE304"/>
           <ibe:body>
              Helpful error message
           </ibe:body>
        </ibe:response>

     5.7. The application/ibe-pkg-reply+xml MIME type

        The meaning following summarizes the properties of the response codes for errors
        application/ibe-pkg-reply+xml MIME type.

        MIME media type name: application

        MIME subtype name: ibe-pkg-reply+xml

        Mandatory parameters: The only required parameter is as
        follows:

        300 - This a
        response code which indicates an internal server error the status of a key request.
        Other parameters may be also required, depending on the
        nature of the response from the PKG.

        301 - For example, for the
        responseCode IBE100 ("key follows"), an IBE private key is
        also a required parameter.

        Optional parameters: None.

        Encoding considerations: This media type MUST be encoded as
        us-ascii [ASCII].

        Security considerations: The request to data conveyed as this media
        type is an IBE private key, so its confidentiality and
        integrity is extremely important. To ensure this, the
        response from the server is invalid that contains an IBE private key
        must take place over a secure protocol, TLS 1.1 or its
        successors. To ensure the validity of the server, the
        client MUST verify the server
        is not able to fulfill this type certificate and MUST abort
        the key request if the verification of request.

        303 - The the server is
        certificate of the TLS connection fails. This media type
        contains no active content and does not able to serve key requests use compression.

        Interoperability considerations: There are no known
        interoperability considerations for this type of client. A client media type.

        Applications that use this media type: Applications that
        implement IBE in compliance with a newer version this specification will
        use this media type. The most commonly-used of the
        protocol these
        applications are encrypted email and file encryption.

        Additional information: This media type is required.

        304 - The key request was processed correctly, but the
        authentication credentials provided by used for the user were
        invalid, could not be verified, or do
        response from a PKG after receiving a request for an IBE
        private key. This media type contains no active content and
        does not allow access to
        keys use compression.

        Person and email address for this identity.

     5. further information: Luther
        Martin, martin@voltage.com.

        Intended usage: COMMON.

        Author/Change controller: Luther Martin,
        martin@voltage.com.

     6. ASN.1 Module

        The following ASN.1 module summarizes the ASN.1 definitions
        discussed in this document.

        IBEARCH-module { joint-iso-itu-t(2) country(16) us(840)
          organization(1) identicrypt(114334) ibcs(1) ibearch(5)
          module(5) version(1)
        }

        DEFINITIONS IMPLICIT TAGS ::= BEGIN

        IBESysParams ::= SEQUENCE {
          version               INTEGER { v2(2) },
          districtName          IA5String,
          districtSerial        INTEGER,
          validity              ValidityPeriod,
          ibePublicParameters   IBEPublicParameters,
          ibeIdentitySchema
          ibeIdentityType       OBJECT IDENTIFIER,
          ibeParamExtensions    IBEParamExtensions OPTIONAL
        }

        ValidityPeriod ::= SEQUENCE {
          notBefore     GeneralizedTime,
          notAfter      GeneralizedTime
        }

        IBEPublicParameters ::= SEQUENCE (1..MAX) OF
        IBEPublicParameter

        IBEPublicParameter  ::= SEQUENCE {
          ibeAlgorithm          OBJECT IDENTIFIER,
          publicParameterData   OCTET STRING
        }

        IBEParamExtensions ::= SEQUENCE OF IBEParamExtension

        IBEParamExtension ::= SEQUENCE {
          ibeParamExtensionOID     OBJECT IDENTIFIER,
          ibeParamExtensionValue   OCTET STRING
        }

        ibcs OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840)
          organization(1) identicrypt(114334) ibcs(1)
        }

        ibeParamExt OBJECT IDENTIFIER ::= {
          ibcs ibcs3(3) parameter-extensions(2)
        }

        pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
        IBEPrivateKeyReply ::= SEQUENCE {
          pkgIdentity  IBEIdentityInfo,
          pgkAlgorithm OBJECT IDENTIFIER,
          pkgKeyData   OCTET STRING,
          pkgOptionsSEQUENCE
          pkgOptions   SEQUENCE SIZE (1..MAX) OF PKGOption
        }

        PKGOption  ::=  SEQUENCE  {
          optionID    OBJECT IDENTIFIER,
          critical    BOOLEAN DEFAULT FALSE,
          optionValue OCTET STRING
        }

        uriPPSOID OBJECT IDENTIFIER ::= {
          joint-iso-itu-t(2) country(16) us(840)
          organization(1) identicrypt(114334)
          pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
        }

        IBEIdentityInfo ::= SEQUENCE {
          district        IA5String,
          serial          INTEGER,
          identityType    OBJECT IDENTIFIER,
          identityData    OCTET STRING
        }

        END

     6.

     7. Security Considerations

     6.1.

     7.1. Attacks that are outside the scope of this document

        Attacks on the cryptographic algorithms that are used to
        implement IBE are outside the scope of this document. Such
        attacks are detailed in [IBCS], which defines parameters
        that give 80-bit, 112-bit and 128-bit encryption strength.
        We assume that capable administrators of an IBE system will
        select parameters that provide a sufficient resistance to
        cryptanalytic attacks by adversaries.

        Attacks that give an adversary the ability to access or
        change the information on a PPS or PKG, especially the
        cryptographic material (referred to in this document as the
        master secret), will defeat the security of an IBE system.
        In particular, if the cryptographic material is compromised
        the adversary will have the ability to recreate any user's
        private key and therefore decrypt all messages protected
        with the corresponding public key. To address this concern,
        it is highly RECOMMENDED that best practices for physical
        and operational security for PPS and PKG servers be
        followed and that these servers be configured (sometimes
        known as hardened) in accordance with best current
        practices [NIST]. An IBE system SHOULD be operated in an
        environment where illicit access is infeasible for
        attackers to obtain.

        Attacks that require administrative or IBE user equivalent
        access to machines used by either the client or the server
        components defined in this document are also outside the
        scope of this document.

        We also assume that all administrators of a system
        implementing the protocols that are defined in this
        document are trustworthy and will not abuse their authority
        to bypass the security provided by an IBE system.
        Similarly, we assume that users of an IBE system will
        behave responsibly, not sharing their authentication
        credentials with others. Thus attacks that require such
        assumptions are outside the scope of this document.

     6.2.

     7.2. Attacks that are within the scope of this document

        Attacks within the scope of this document are those that
        allow an adversary to:

              o  passively monitor information transmitted between
                 users of an IBE system and the PPS and PKG

              o  masquerade as a PPS or PKG

              o  perform a DOS attack on a PPS or PKG

              o  easily guess an IBE users authentication
                 credential

     6.2.1.

     7.2.1. Attacks to which on the protocols defined in this document are susceptible

        All communications between users of an IBE system and the
        PPS or PKG are protected using TLS 1.1 [TLS]. The IBE
        system defined in this document provides no additional
        security protections for the communications between IBE
        users and the PPS or PKG. Therefore the described IBE
        system is completely dependent on the TLS security
        mechanisms for authentication of the PKG or PPS server and
        for confidentiality and integrity of the communications.
        Should there be a compromise of the TLS security
        mechanisms, the integrity of all communications between an
        IBE user and the PPS or PKG will be suspect.

        The protocols defined in this document do not explicitly
        defend against an attacker masquerading as a legitimate IBE
        PPS or PKG. The protocols rely on the server authentication
        mechanism of TLS [TLS]. In addition to the TLS server
        authentication mechanism IBE client software can provide
        protection against this possibility by providing user
        interface capabilities that allows users to visually
        determine that a connection to PPS and PKG servers is
        legitimate. This additional capability can help ensure that
        users cannot easily be tricked into providing valid
        authorization credentials to an attacker.

        The protocols defined in this document are also vulnerable
        to attacks against an IBE PPS or PKG. Denial of service
        attacks against either component can result in users unable
        to encrypt or decrypt using IBE, and users of an IBE system
        SHOULD take the appropriate countermeasures [DOS, BGPDOS]
        that their use of IBE requires.

        The IBE user authentication method selected by an IBE PKG
        SHOULD be of sufficient strength to prevent attackers from
        easily guessing the IBE user's authentication credentials
        through trial and error.

     7.

     8. IANA Considerations

     8.1. Media types

        This specification proposes the registration of three media
        types in the standard registration tree. These are
        application/ibe-pp-data, application/ibe-key-request+xml,
        and application/ibe-pkg-reply+xml. The XML media type
        application/ibe-pp-data is defined in Section 3.3 of this document will be registered with
        the IANA per the instructions
        document. The media type application/ibe-key-request+xml is
        defined in RFC 3688, Section 4.4 of this document. The IETF media type
        application/ibe-pkg-reply+xml is defined in Section 4.7 of
        this document.

     8.2. XML
        Registry.

        URI: namespace

        The IANA is requested to register the following namespace
        identifier:

        urn:ietf:params:xml:ns:ibe

        Registrant Contact:

           Luther Martin
           Voltage Security
           1070 Arastradero Rd Suite 100
           Palo Alto CA 94304

           Phone: +1 650 543 1280
           Email: martin@voltage.com

        XML:

        BEGIN
        <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:header>
              <ibe:client version="clientID"/>
           </ibe:header>
           <ibe:body>
           <ibe:keyRequest>
              <ibe:algorithm>
                <oid>
                 algorithmOID </oid>
              </ibe:algorithm>
              <ibe:id>
                 ibeIdentityInfo
              </ibe:id>
           </ibe:keyRequest>
           <ibe:authData>
              ibeAuthData
           </ibe:authData>
           </ibe:body>
        </ibe:request>

        <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
           <ibe:responseType value="responseCode"/>
           <ibe:body>
              bodyTags
           </ibe:body>
        </ibe:response>
        END

     8.

     9. References

     8.1.

     9.1. Normative References

        [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7-
                  bit Coded Character Set for Information Exchange

        [ASN1] ITU-T Recommendation X.680: Information Technology -
                  Abstract Syntax Notation One, 1997.

        [AUTH] J. Franks, et al., "HTTP Authentication: Basic and
              Digest Access Authentication", RFC 2617, June 1999.

        [B64] N. Freed and N. Borenstein, Multipurpose "Multipurpose Internet
              Mail Extensions(MIME) Part One: Format of Internet
              Message Bodies," RFC 2045, November 1996.

        [CMS] R. Housley, "Cryptographic Message Syntax," Syntax (CMS)," RFC
              3852, July 2004.

        [DER] CCITT, "Recommendation X.209: Specification of
             Basic Encoding Rules for ITU-T Recommendation X.690: OSI Networking and System
             Aspects: Abstract Syntax Notation One (ASN.1)," 1998.

        [DOM] P. Mockapetris, "Domain Names - Implementation and
              Specification," RFC 1035, November 1987. (ASN.1), July
             2002.

        [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP
              Source Address Spoofing," RFC 2827, BCP 38, May 2000.

        [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol --
              HTTP/1.1", RFC 2616, June 1999.

        [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000.

        [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography
              Standard (IBCS) #1: Supersingular Curve
              Implementations of the BF and BB1 Cryptosystems," RFC
              5091, December 2007.

        [IRI] M. Deurst and M. Suignard, "Internationalized
              Resource Identifiers (IRIs)," RFC 3987, January 2005.

        [KEY] S. Brander, "Key Words for Use in RFCs to Indicate
              Requirement Levels," BCP 14, RFC 2119, March 1997.

        [MIME] N. Freed

        [PKIX] D. Cooper, et al., "Internet X.509 Public Key
              Infrastructure Certificate and N. Borenstein, "Multipurpose Internet Certificate Revocation
        [SMTP] J. Klensin (ed.), "Simple Mail Extensions (MIME) Part Two: Media Types," RFC
              2046, November 1996.

        [TEXTMSG] D. Crocker, "Standard for the format of ARPA
             internet text messages," Transfer Protocol,"
             RFC 2822, 2821, April 2001.

        [TLS] T. Dierks and E. Rescorla, "The Transport Layer
              Security (TLS) Protocol Version 1.1," RFC 4346, April
              2006.

        [URI] T. Berners-Lee, R. Fielding, and L. Masinter,
              "Uniform Resource Identifiers Identifier (URI): Generic Syntax",
              STD 66, RFC 3986, January 2005.

        [XHTML] M. Baker and P. Stark, "The
              'application/xhtml+xml' Media Type," RFC 3236,
              January 2002.

     8.2.

        [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth
              Edition), September 2006.

     9.2. Informative References

        [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
              Service Attacks," RFC 3882, September 2004.

        [IBCS] X. Boyen and L. Martin, "Identity-Based
              Cryptography Standard (IBCS) #1: Supersingular
              Curve Implementations of the BF and BB1
              Cryptosystems," draft-martin-ibcs-06.txt, September
              2007.

        [IBECMS] L. Martin and M. Schertler, "Using the Boneh-
              Franklin identity-based encryption algorithm with the
              Cryptographic Message Syntax (CMS)," draft-
              ietf-smime-bfibecms-06.txt, September 2007. draft-ietf-
              smime-bfibecms-10.txt, July 2008.

        [NIST] M. Souppaya, J. Wack and K. Kent, "Security
              Configuration Checklist Program for IT Products -
              Guidance for Checklist Users and Developers," NIST
              Special Publication SP 800-70, May 2005.

        [P1363] IEEE P1363, "Standards "Standard Specifications for Public-
              Key Public-Key
              Cryptography," 2001.

     Authors' Addresses

        Guido Appenzeller
        Voltage Security
        1070 Arastradero Rd Suite 100
        Palo Alto
        Stanford University
        Gates Building 3A
        Stanford, CA 94304 94305

        Phone: +1 650 543 1280 732 2273
        Email: guido@voltage.com appenz@cs.stanford.edu

        Luther Martin
        Voltage Security
        1070 Arastradero Rd Suite 100
        Palo Alto CA 94304
        USA

        Phone: +1 650 543 1280
        Email: martin@voltage.com

        Mark Schertler
        Tumbleweed Communications
        700 Saginaw Dr
        Redwood City CA 94063
        USA

        Phone: +1 650 216 2039
        Email: mark.schertler@tumbleweed.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 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, THE IETF TRUST 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 IETF Trust (2007). (2008).

        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.