Summary: three media types are proposed: application/ibe-pp-request, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. Background Identity-based encryption (IBE) is a public key technology in which public keys are calculated from an arbitrary string instead of being generated randomly or calculated from random components. This string typically represents the identity of a user. The user then receives the private key corresponding to a public key from a secure server called a private key generator (PKG). The technology is fairly widely deployed, being used by multiple vendors and roughly 6 million users worldwide. A set of global public parameters are required that define the mathematical operations that IBE calculations require. These parameters are downloaded from a server as specified in draft-smime-ibearch-07 and its successors. Once a client has these parameters, it can then calculate IBE public keys and can use both IBE public and private keys in cryptographic operations. The calculation of such public and private keys and their use to encrypt and decrypt is described in RFC 5091. To request an IBE private key, a user passes the parameters that are defined in draft-smime-ibearch-07 and its successors to a PKG. If the user can successfully authenticate to the PKG according to the PKG's security policy then the corresponding private key is calculated and provided to the user as defined in draft-smime-ibearch-07 and its successors. To support the use of IBE, we propose the definition of three new media types: application/ibe-pp-request, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml. These are further described below. ----- MIME media type name: application MIME subtype name: ibe-pp-request Mandatory parameters: The single required parameter is a base64-encoded DER-encoded IBESysParams structure as defined in draft-ieft-smime-ibearch-07 and its successors. Optional parameters: There are no optional parameters. Encoding considerations: This media type MUST be encoded as 7bit (us-ascii text). Security considerations: The data conveyed as this media type are the public parameters needed for the operation of a cryptographic system. To ensure that the parameters can be trusted, the request for these parameters 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 parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This media type is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors 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 proposed 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. ----- 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 as defined in draft-ietf-smime-ibearch-07 and its successors. The object identifier is the base64-encoding of a DER-encoded object identifier, like those defined in RFC 5091. Optional parameters: Any optional parameters may be defined by an administrator of a particular PKG. The most common optional parameter is an authentication credential. As described in draft-ietf-smime-ibearch-07 and its successors, 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. 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 parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors 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 proposed 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. ----- MIME media type name: application MIME subtype name: ibe-pkg-reply+xml Mandatory parameters: The only required parameter is a response code which indicates the status of a key request. Other parameters may be also required, depending on the nature of the response from the PKG. For example, for the responseCode IBE100 ("key follows"), an IBE private key is also a required parameter. The list of defined responses is given in draft-ietf-smime-ibearch-07 and its successors. Optional parameters: None. Encoding considerations: This media type MUST be encoded as us-ascii. Security considerations: The 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 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 certificate and must abort the parameter request if the server certificate of the TLS connection fails. This proposed media type contains no active content and does not use compression. Interoperability considerations: There are no known interoperability considerations for this proposed media type. Published specification: This media type is defined in draft-ietf-smime-ibearch-07 and its successors. Applications that use this media type: Applications that implement IBE in compliance with draft-ietf-smime-ibearch-07 and its successors 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 PKG after receiving a request for an IBE private key. This proposed 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.