Proposed media types

[Luther Martin]

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 at voltage.com.

Intended usage: COMMON.

Author/Change controller: Luther Martin, martin at 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 at voltage.com.

Intended usage: COMMON.

Author/Change controller: Luther Martin, martin at 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 at voltage.com.

Intended usage: COMMON.

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