draft-ietf-smime-ibearch-09.txt   rfc5408.txt 
G. Appenzeller Network Working Group G. Appenzeller
Stanford University Request for Comments: 5408 Stanford University
S/MIME Working Group L. Martin Category: Informational L. Martin
Internet Draft Voltage Security Voltage Security
Intended status: Standards Track M. Schertler M. Schertler
Expires: April 2009 Tumbleweed Communications Axway
October 2008 January 2009
Identity-based Encryption Architecture and Supporting Data
Structures
<draft-ietf-smime-ibearch-09.txt>
Status of this Document Identity-Based Encryption Architecture and Supporting Data Structures
By submitting this Internet-Draft, each author represents Status of This Memo
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 This memo provides information for the Internet community. It does
Engineering Task Force (IETF), its areas, and its working not specify an Internet standard of any kind. Distribution of this
groups. Note that other groups may also distribute working memo is unlimited.
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of Copyright Notice
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 Copyright (c) 2009 IETF Trust and the persons identified as the
http://www.ietf.org/ietf/1id-abstracts.txt document authors. All rights reserved.
The list of Internet-Draft Shadow Directories can be This document is subject to BCP 78 and the IETF Trust's Legal
accessed at Provisions Relating to IETF Documents (http://trustee.ietf.org/
http://www.ietf.org/shadow.html license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the security architecture required to This document describes the security architecture required to
implement identity-based encryption, a public-key encryption implement identity-based encryption, a public-key encryption
technology that uses a user's identity as a public key. It technology that uses a user's identity as a public key. It also
also defines data structures that can be used to implement the defines data structures that can be used to implement the technology.
technology.
Table of Contents Table of Contents
1. Introduction.........................................4 1. Introduction ....................................................3
1.1. Terminology.....................................4 1.1. Terminology ................................................3
2. Identity-based Encryption............................4 2. Identity-Based Encryption .......................................3
2.1. Overview........................................4 2.1. Overview ...................................................3
2.2. Sending a Message that is IBE-encrypted.........6 2.2. Sending a Message That Is IBE-Encrypted ....................5
2.2.1. Sender Obtains Public Parameters...........6 2.2.1. Sender Obtains Public Parameters ....................5
2.2.2. Construct and Send IBE-encrypted Message...7 2.2.2. Construct and Send an IBE-Encrypted Message .........6
2.3. Receiving and Viewing an IBE-encrypted Message..8 2.3. Receiving and Viewing an IBE-Encrypted Message .............6
2.3.1. Recipient Obtains Public Parameters........9 2.3.1. Recipient Obtains Public Parameters .................7
2.3.2. Recipient Obtains IBE Private Key..........9 2.3.2. Recipient Obtains IBE Private Key ...................8
2.3.3. Recipient Decrypts IBE-encrypted Message..10 2.3.3. Recipient Decrypts IBE-Encrypted Message ............8
3. Identity Format.....................................10 3. Identity Format .................................................9
4. Public Parameter Lookup.............................11 4. Public Parameter Lookup .........................................9
4.1. Request Method.................................12 4.1. Request Method ............................................10
4.2. Parameter and Policy Format....................12 4.2. Parameter and Policy Format ...............................11
4.3. The application/ibe-pp-data MIME type..........16 4.3. The application/ibe-pp-data MIME Type .....................14
5. Private Key Request Protocol........................17 5. Private Key Request Protocol ...................................15
5.1. Overview.......................................17 5.1. Overview ..................................................15
5.2. Private Key Request............................18 5.2. Private Key Request .......................................15
5.3. Request Structure..............................18 5.3. Request Structure .........................................16
5.4. The application/ibe-key-request+xml MIME type..20 5.4. The application/ibe-key-request+xml MIME type .............17
5.5. Authentication.................................21 5.5. Authentication ............................................18
5.6. Server Response Format.........................21 5.6. Server Response Format ....................................18
5.6.1. The IBE100 responseCode...................22 5.6.1. The IBE100 responseCode ............................19
5.6.2. The IBE101 responseCode...................23 5.6.2. The IBE101 responseCode ............................20
5.6.3. The IBE201 responseCode...................23 5.6.3. The IBE201 responseCode ............................20
5.6.4. The IBE300 responseCode...................24 5.6.4. The IBE300 responseCode ............................21
5.6.5. The IBE301 responseCode...................24 5.6.5. The IBE301 responseCode ............................21
5.6.6. The IBE303 responseCode...................25 5.6.6. The IBE303 responseCode ............................21
5.6.7. The IBE304 responseCode...................25 5.6.7. The IBE304 responseCode ............................22
5.7. The application/ibe-pkg-reply+xml MIME type....25 5.7. The application/ibe-pkg-reply+xml MIME type ...............22
6. ASN.1 Module........................................26 6. ASN.1 Module ...................................................23
7. Security Considerations.............................28 7. Security Considerations ........................................25
7.1. Attacks outside the scope of this document.....28 7.1. Attacks outside the Scope of This Document ................25
7.2. Attacks within the scope of this document......29 7.2. Attacks within the Scope of This Document .................26
7.2.1. Attacks on the protocols defined in this 7.2.1. Attacks on the Protocols Defined in This Document ..26
document.........................................29 8. IANA Considerations ............................................27
8. IANA Considerations.................................30 8.1. Media Types ...............................................27
8.1. Media types....................................30 8.2. XML Namespace .............................................27
8.2. XML namespace..................................30 9. References .....................................................28
9. References..........................................32 9.1. Normative References ......................................28
9.1. Normative References...........................32 9.2. Informative References ....................................29
9.2. Informative References.........................33
Authors' Addresses.....................................34
Intellectual Property Statement........................34
Disclaimer of Validity.................................35
Copyright Statement....................................35
Acknowledgment.........................................35
1. Introduction 1. Introduction
This document describes the security architecture required This document describes the security architecture required to
to implement identity-based encryption, a public-key implement identity-based encryption, a public-key encryption
encryption technology that uses a user's identity as a technology that uses a user's identity as a public key. It also
public key. It also defines data structures that are defines data structures that are required to implement the
required to implement the technology. Objects used in this technology. Objects used in this implementation are defined using
implementation are defined using ASN.1 [ASN1] and XML ASN.1 [ASN1] and XML [XML].
[XML].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
and "OPTIONAL" in this document are to be interpreted as document are to be interpreted as described in [KEY].
described in [KEY].
2. Identity-based Encryption 2. Identity-Based Encryption
2.1. Overview 2.1. Overview
Identity-based encryption (IBE) is a public-key encryption Identity-based encryption (IBE) is a public-key encryption technology
technology that allows a public key to be calculated from that allows a public key to be calculated from an identity and a set
an identity and a set of public mathematical parameters and of public mathematical parameters and that allows for the
for the corresponding private key to be calculated from an corresponding private key to be calculated from an identity, a set of
identity, a set of public mathematical parameters and a public mathematical parameters, and a domain-wide secret value. An
domain-wide secret value. An IBE public key can be IBE public key can be calculated by anyone who has the necessary
calculated by anyone who has the necessary public public parameters; a cryptographic secret is needed to calculate an
parameters; a cryptographic secret is needed to calculate IBE private key, and the calculation can only be performed by a
an IBE private key, and the calculation can only be trusted server that has this secret.
performed by a trusted server which has this secret.
Calculation of both the public and private keys in an IBE Calculation of both the public and private keys in an IBE system can
system can occur as needed, resulting in just-in-time occur as needed, resulting in just-in-time creation of both public
creation of both public and private keys. This contrasts and private keys. This contrasts with other public-key systems
with other public-key systems [P1363], in which keys are [P1363], in which keys are generated randomly and distributed prior
generated randomly and distributed prior to secure to secure communication commencing, and in which private encryption
communication commencing, and in which private encryption keys need to be securely archived to allow for their recovery if they
keys need to be securely archived to allow for their are lost or destroyed. The ability to calculate a recipient's public
recovery if they are lost or destroyed. The ability to key, in particular, eliminates the need for the sender and receiver
calculate a recipient's public key, in particular, to interact with each other, either directly or through a proxy such
eliminates the need for the sender and receiver to interact as a directory server, before sending secure messages.
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 A characteristic of IBE systems that differentiates them from other
from other server-based cryptographic systems is that once server-based cryptographic systems is that once a set of public
a set of public parameters is fetched, encryption is parameters is fetched, encryption is possible with no further
possible with no further communication with a server during communication with a server during the validity period of the public
the validity period of the public parameters. Other server- parameters. Other server-based systems may require a connection to a
based systems may require a connection to a server for each server for each encryption operation.
encryption operation.
This document describes an IBE-based messaging system, how This document describes an IBE-based messaging system, how the
the components of such a system work together, and defines components of such a system work together, and defines data
data structures that support the operation of such a structures that support the operation of such a system. The server
system. The server components required for such a system components required for such a system are the following:
are the following:
o A Public Parameter Server (PPS). IBE Public o A Public Parameter Server (PPS). IBE public parameters include
parameters include publicly-sharable cryptographic publicly-sharable cryptographic material, known as IBE public
material, known as IBE public parameters, and parameters, and policy information for an associated PKG. A
policy information for an associated PKG. A PPS PPS provides a well-known location for secure distribution of
provides a well-known location for secure IBE public parameters and policy information that describe the
distribution of IBE public parameters and policy operation of a PKG. Section 5 of this document describes the
information that describe the operation of a PKG. protocol that a client uses to communicate with a PPS.
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 o A Private-key Generator (PKG). The PKG stores and uses
uses cryptographic material, known as a master cryptographic material, known as a master secret, which is used
secret, which is used for generating a user's IBE for generating a user's IBE private key. A PKG accepts an IBE
private key. A PKG accepts an IBE user's private user's private key request, and after successfully
key request, and after successfully authenticating authenticating them in some way, returns their IBE private key.
them in some way, returns their IBE private key. Section 5 of this document describes the protocol that a client
Section 5 of this document describes the protocol uses to communicate with a PKG.
that a client uses to communicate with a PKG.
A logical architecture of such an IBE system would be to A logical architecture of such an IBE system would be to have a PKG
have a PKG and PPS per name space, such as a DNS zone. The and PPS per name space, such as a DNS zone. The organization that
organization that controls the DNS zone would also control controls the DNS zone would also control the PKG and PPS and thus the
the PKG and PPS and thus the determination of which PKG or determination of which PKG or PPS to use when creating public and
PSS to use when creating public and private keys for the private keys for the organization's members. In this case, the PPS
organization's members. In this case the PPS URI/IRI can be URI/IRI can be uniquely created from a user-friendly name for the
uniquely created from a user-friendly name for the form of form of identity that the PPS supports. This architecture would make
identity that it supports. This architecture would make it it clear which set of public parameters to use and where to retrieve
clear which set of public parameters to use and where to them for a given identity (for example, an RFC 2821 address [SMTP]).
retrieve them for a given identity (for example, an RFC
2821 address [SMTP]).
IBE-encrypted messages can use standard message formats, IBE-encrypted messages can use standard message formats, such as the
such as the Cryptographic Message Syntax [CMS]. How to use Cryptographic Message Syntax [CMS]. How to use IBE with the CMS to
IBE with the CMS to encrypt e-mail messages is defined in encrypt email messages is defined in [IBECMS].
[IBECMS].
Note that IBE algorithms are used only for encryption, so Note that IBE algorithms are used only for encryption, so if digital
if digital signatures are required they will need to be signatures are required, they will need to be provided by an
provided by an additional mechanism. additional mechanism.
Section 3 of this document describes the identity format Section 3 of this document describes the identity format that all PPS
that all PPS and PKG servers MUST support. and PKG servers MUST support.
2.2. Sending a Message that is IBE-encrypted 2.2. Sending a Message That Is IBE-Encrypted
In order to send an encrypted message, an IBE user must In order to send an encrypted message, an IBE user must perform the
perform the following steps: following steps:
1. Obtain the recipient's public parameters 1. Obtain the recipient's public parameters
The public parameters of the recipient's system are The public parameters of the recipient's system are needed to
needed to perform IBE operations. Once a user obtains perform IBE operations. Once a user obtains these public
these public parameters, he can perform IBE parameters, he can perform IBE encryption operations. These
encryption operations. These public parameters may be public parameters may be available at a PPS that is operated by
available at a PPS that is operated by the user's the user's organization, one that is operated by the sender's
organization, one that is operated by the sender's organization, or by a different organization entirely.
organization, or by a different organization
entirely.
2. Construct and Send IBE-encrypted Message 2. Construct and send an IBE-encrypted message
In addition to the IBE public parameters, all that is In addition to the IBE public parameters, all that is needed to
needed to construct an IBE-encrypted message is the construct an IBE-encrypted message is the recipient's identity,
recipient's identity, the form of which is defined by the form of which is defined by the public parameters. When
the public parameters. When this identity is the same this identity is the same as the identity that a message would
as the identity that a message would be addressed to, be addressed to, then no more information is needed from a user
then no more information is needed from a user to to send them an encrypted message than is needed to send them
send them an encrypted message then is needed to send an unencrypted message. This is one of the major benefits of
them an unencrypted message. This is one of the major an IBE-based secure messaging system. Examples of identities
benefits of an IBE-based secure messaging system. are individual, group, or role identifiers.
Examples of identities can be an individual, group,
or role identifiers.
2.2.1. Sender Obtains Public Parameters 2.2.1. Sender Obtains Public Parameters
The sender of a message obtains the IBE public parameters The sender of a message obtains the IBE public parameters that he
that he needs from a PPS that is hosted at a well-known URI needs from a PPS that is hosted at a well-known URI or IRI. The IBE
or IRI. The IBE public parameters contain all of the public parameters contain all of the information that the sender
information that the sender needs to create an IBE- needs to create an IBE-encrypted message except for the identity of
encrypted message except for the identity of the recipient. the recipient. Section 4 of this document describes the URI [URI] or
Section 4 of this document describes the URI [URI] or IRI IRI [IRI] of a PPS, the format of IBE public parameters, and how to
[IRI] of a PPS, the format of IBE public parameters, and obtain them from a PPS. The URI or IRI from which users obtain IBE
how to obtain them from a PPS. The URI or IRI from which public parameters MUST be authenticated in some way. PPS servers
users obtain IBE public parameters MUST be authenticated in MUST support TLS 1.2 [TLS] to satisfy this requirement and SHOULD
some way. PPS servers MUST support TLS 1.1 [TLS] to satisfy support its successors. This step is shown below in Figure 1.
this requirement and SHOULD support its successors. This
step is shown below in Figure 1.
IBE Public Parameter Request IBE Public Parameter Request
-----------------------------> ----------------------------->
Sender PPS Sender PPS
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 1 Requesting IBE Public Parameters Figure 1: Requesting IBE Public Parameters
The sender of an IBE-encrypted message selects the PPS and The sender of an IBE-encrypted message selects the PPS and
corresponding PKG based on his local security policy. corresponding PKG based on his local security policy. Different PPS
Different PPS servers may provide public parameters that servers may provide public parameters that specify different IBE
specify different IBE algorithms or different key algorithms or different key strengths, for example. Or, they may
strengths, for example, or require the use of PKG servers require the use of PKG servers that require different levels of
that require different levels of authentication before authentication before granting IBE private keys.
granting IBE private keys.
2.2.2. Construct and Send IBE-encrypted Message 2.2.2. Construct and Send an IBE-Encrypted Message
To IBE-encrypt a message, the sender chooses a content- To IBE-encrypt a message, the sender chooses a content-encryption key
encryption key (CEK) and uses it to encrypt his message and (CEK) and uses it to encrypt his message and then encrypts the CEK
then encrypts the CEK with the recipient's IBE public key with the recipient's IBE public key as described in [CMS]. This
as described in [CMS]. This operation is shown below in operation is shown below in Figure 2. The document [IBCS] describes
Figure 2. The document [IBCS] describes the algorithms the algorithms needed to implement two forms of IBE, and [IBECMS]
needed to implement two forms of IBE and [IBECMS] describes describes how to use the Cryptographic Message Syntax (CMS) to
how to use the Cryptographic Message Syntax (CMS) to encapsulate the encrypted message along with the IBE information that
encapsulate the encrypted message along with the IBE the recipient needs to decrypt an email message.
information that the recipient needs to decrypt an e-mail
message.
CEK ----> Sender ----> IBE-encrypted CEK CEK ----> Sender ----> IBE-encrypted CEK
^ ^
| |
| |
Recipient's Identity Recipient's Identity
and IBE Public Parameters and IBE Public Parameters
Figure 2 Using an IBE Public-key Algorithm to Encrypt Figure 2: Using an IBE Public-key Algorithm to Encrypt
2.3. Receiving and Viewing an IBE-encrypted Message
In order to read an IBE-encrypted message, a recipient of 2.3. Receiving and Viewing an IBE-Encrypted Message
such a message parses the message to find the URI or IRI he
needs to obtain the IBE public parameters that are required In order to read an IBE-encrypted message, a recipient of such a
to perform IBE calculations as well as a component of the message parses it to find the URI or IRI he needs in order to obtain
identity that was used to encrypt the message. Next the the IBE public parameters that are required to perform IBE
recipient carries out the following steps: calculations as well as to obtain a component of the identity that
was used to encrypt the message. Next, the recipient carries out the
following steps:
1. Obtain the IBE public parameters 1. Obtain the IBE public parameters
An IBE system's public parameters allow it to An IBE system's public parameters allow it to uniquely create
uniquely create public and private keys. The public and private keys. The recipient of an IBE-encrypted
recipient of an IBE-encrypted message can decrypt an message can decrypt an IBE-encrypted message if he has both the
IBE-encrypted message if he has both the IBE public IBE public parameters and the necessary IBE private key. The
parameters and the necessary IBE private key. The public parameters also provide the URI or IRI of the PKG where
public parameters also provide the URI or IRI of the the recipient of an IBE-encrypted message can obtain the IBE
PKG where the recipient of an IBE-encrypted message private keys.
can obtain the IBE private keys.
2. Obtain the IBE private key from the PKG 2. Obtain the IBE private key from the PKG
To decrypt an IBE-encrypted message, in addition to To decrypt an IBE-encrypted message, in addition to the IBE
the IBE public parameters, the recipient needs to public parameters, the recipient needs to obtain the private
obtain the private key that corresponds to the public key that corresponds to the public key that the sender used.
key that the sender used. The IBE private key is The IBE private key is obtained after successfully
obtained after successfully authenticating to a authenticating to a private key generator (PKG), a trusted
private key generator (PKG), a trusted third party third party that calculates private keys for users. The
that calculates private keys for users. The recipient recipient then receives the IBE private key over a secure
then receives the IBE private key over a secure
connection. connection.
3. Decrypt IBE-encrypted message 3. Decrypt the IBE-encrypted Message
The IBE private key decrypts the CEK (see Section The IBE private key decrypts the CEK (see Section 2.3.3). The
2.2.2). The CEK is then used to decrypt encrypted CEK is then used to decrypt the encrypted message.
message.
It may be useful for a PKG to allow users other than the It may be useful for a PKG to allow users other than the intended
intended recipient to receive some IBE private keys. Giving recipient to receive some IBE private keys. Giving a mail-filtering
a mail filtering appliance permission to obtain IBE private appliance permission to obtain IBE private keys on behalf of users,
keys on behalf of users, for example, can allow the for example, can allow the appliance to decrypt and scan encrypted
appliance to decrypt and scan encrypted messages for messages for viruses or other malicious features.
viruses or other malicious features.
2.3.1. Recipient Obtains Public Parameters 2.3.1. Recipient Obtains Public Parameters
Before he can perform any IBE calculations related to the Before he can perform any IBE calculations related to the message
message that he has received, the recipient of an IBE- that he has received, the recipient of an IBE-encrypted message needs
encrypted message needs to obtain the IBE public parameters to obtain the IBE public parameters that were used in the encryption
that were used in the encryption operation. This operation operation. This operation is shown below in Figure 3. Because the
is shown below in Figure 3. Because the use of the correct use of the correct public parameters is vital to the overall security
public parameters is vital to the overall security of an of an IBE system, IBE public parameters MUST be transported to
IBE system, IBE public parameters MUST be transported to recipients over a secure protocol. PPS servers MUST support TLS 1.2
recipients over a secure protocol. PPS servers MUST support [TLS] or its successors, using the latest version supported by both
TLS 1.1 [TLS] or its successors, using the latest version parties, for transport of IBE public parameters. In addition, users
supported by both parties, for transport of IBE public MUST verify that the subject name in the server certificate matches
parameters. In addition, users MUST verify that the subject the URI/IRI of the PPS. The comments in Section 2.2.1 also apply to
name in the server certificate matches the URI/IRI of the this operation.
PPS. The comments in Section 2.2.1 also apply to this
operation.
IBE Public Parameter Request IBE Public Parameter Request
-----------------------------> ----------------------------->
Recipient PPS Recipient PPS
<----------------------------- <-----------------------------
IBE Public Parameters IBE Public Parameters
Figure 3 Requesting IBE Public Parameters Figure 3: Requesting IBE Public Parameters
2.3.2. Recipient Obtains IBE Private Key 2.3.2. Recipient Obtains IBE Private Key
To obtain an IBE private key, the recipient of an IBE- To obtain an IBE private key, the recipient of an IBE-encrypted
encrypted message provides the IBE public key used to message provides the IBE public key used to encrypt the message and
encrypt the message and their authentication credentials to their authentication credentials to a PKG and requests the private
a PKG and requests the private key that corresponds to the key that corresponds to the IBE public key. Section 5 of this
IBE public key. Section 5 of this document defines the document defines the protocol for communicating with a PKG as well as
protocol for communicating with a PKG as well as a minimum a minimum interoperable way to authenticate to a PKG that all IBE
interoperable way to authenticate to a PKG that all IBE implementations MUST support. Because the security of IBE private
implementations MUST support. Because the security of IBE keys is vital to the overall security of an IBE system, IBE private
private keys is vital to the overall security of an IBE keys MUST be transported to recipients over a secure protocol. PKG
system, IBE private keys MUST be transported to recipients servers MUST support TLS 1.2 [TLS] or its successors, using the
over a secure protocol. PKG servers MUST support TLS 1.1 latest version supported by both parties, for transport of IBE
[TLS] or its successors, using the latest version supported private keys. This operation is shown below in Figure 4.
by both parties, for transport of IBE private keys. This
operation is shown below in Figure 4.
IBE Private Key Request IBE Private Key Request
----------------------------> ---------------------------->
Recipient PKG Recipient PKG
<---------------------------- <----------------------------
IBE Private Key IBE Private Key
Figure 4 Obtaining an IBE Private Key Figure 4: Obtaining an IBE Private Key
2.3.3. Recipient Decrypts IBE-encrypted Message 2.3.3. Recipient Decrypts IBE-Encrypted Message
After obtaining the necessary IBE private key, the After obtaining the necessary IBE private key, the recipient uses
recipient uses that IBE private key and the corresponding that IBE private key and the corresponding IBE public parameters to
IBE public parameters to decrypt the CEK. This operation is decrypt the CEK. This operation is shown below in Figure 5. He then
shown below in Figure 5. He then uses the CEK to decrypt uses the CEK to decrypt the encrypted message content. An example of
the encrypted message content. An example of how to do this how to do this with email messages is given in [IBECMS].
with e-mail messages is given in [IBECMS].
IBE-encrypted CEK ----> Recipient ----> CEK IBE-encrypted CEK ----> Recipient ----> CEK
^ ^
| |
| |
IBE Private Key IBE Private Key
and IBE Public Parameters and IBE Public Parameters
Figure 5 Using an IBE Public-key Algorithm to Decrypt Figure 5: Using an IBE Public-Key Algorithm to Decrypt
3. Identity Format 3. Identity Format
An IBEIdentityInfo type MUST be used to represent the An IBEIdentityInfo type MUST be used to represent the identity of a
identity of a recipient. This is defined to be the recipient. This is defined to be the following:
following:
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district IA5String, district IA5String,
serial INTEGER, serial INTEGER,
identityType OBJECT IDENTIFIER, identityType OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
An IBEIdentityInfo type is used to calculate public and An IBEIdentityInfo type is used to calculate public and private IBE
private IBE keys. Because of this, such a structure is keys. Because of this, such a structure is typically DER-encoded
typically DER-encoded [DER]. [DER].
The fields of an IBEIdentityInfo structure have the The fields of an IBEIdentityInfo structure have the following
following meanings. meanings.
The district is an IA5String that represents the URI [URI] The district is an IA5String that represents the URI [URI] or IRI
or IRI [IRI] where the recipient of an IBE-encrypted [IRI] where the recipient of an IBE-encrypted message can retrieve
message can retrieve the IBE public parameters needed to the IBE public parameters needed to encrypt or decrypt a message
encrypt or decrypt a message encrypted for this identity. encrypted for this identity. Applications MUST support the method
Applications MUST support the method described in Section 4 described in Section 4 for doing this and MAY support other methods.
for doing this and MAY support other methods. IRIs MUST be IRIs MUST be handled according to the procedures specified in Section
handled according to the procedures specified in Section
7.4 of [PKIX]. 7.4 of [PKIX].
The serial is an INTEGER that defines a unique set of IBE The serial is an INTEGER that defines a unique set of IBE public
public parameters in the event that more than one set of parameters in the event that more than one set of parameters is used
parameters is used by a single district. by a single district.
identityType is an OBJECT IDENTIFIER that defines the identityType is an OBJECT IDENTIFIER that defines the format that the
format that the identityData field is encoded with. identityData field is encoded with.
An example of a useful IBEIdentityInfo type is given in An example of a useful IBEIdentityInfo type is given in [IBECMS].
[IBECMS]. This example is tailored to the use of IBE in This example is tailored to the use of IBE in encrypting email.
encrypting e-mail. Because the information that comprises Because the information that comprises an identity is very dependent
an identity is very dependent on the application, this on the application, this document does not define an identityType
document does not define an identityType that all that all applications MUST support.
applications MUST support.
4. Public Parameter Lookup 4. Public Parameter Lookup
This section specifies how a component of an IBE system can This section specifies how a component of an IBE system can retrieve
retrieve these parameters. A sending or receiving client the public parameters. A sending or receiving client MUST allow
MUST allow configuration of these parameters manually, for configuration of these parameters manually, for example, through
example, through editing a configuration file. However for editing a configuration file. However, for simplified configuration,
simplified configuration a client SHOULD also implement the a client SHOULD also implement the public parameter URI/IRI request
public parameter URI/IRI request method described in this method described in this document to fetch the public parameters
document to fetch the public parameters based on a based on a configured URI/IRI. This is especially useful for
configured URI/IRI. This is especially useful for federating between IBE systems. By specifying a single URI/IRI, a
federating between IBE systems. By specifying a single client can be configured to fetch all the relevant parameters for a
URI/IRI, a client can be configured to fetch all the remote PKG. These public parameters can then be used to encrypt
relevant parameters for a remote PKG. These public messages to recipients who authenticate to and retrieve private keys
parameters can then be used to encrypt messages to
recipients who authenticate to and retrieve private keys
from that PKG. from that PKG.
The following section outlines the URI/IRI request method The following section outlines the URI/IRI request method to retrieve
to retrieve a parameter block and describes the structure a parameter block and describes the structure of the parameter block
of the parameter block itself. The technique for fetching itself. The technique for fetching IBE public parameters using the
IBE public parameters using the process defined in this process defined in this section is indicated by the OID uriPPSOID,
section is indicated by the OBJECT IDENTIFIER uriPPSOID,
which is defined to be the following: which is defined to be the following:
uriPPSOID OBJECT IDENTIFIER ::= { uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1) pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
} }
4.1. Request Method 4.1. Request Method
The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and MAY
MAY additionally support IRIs [IRI] for this purpose. To additionally support IRIs [IRI] for this purpose. To retrieve the
retrieve the IBE public parameters, the client SHOULD use IBE public parameters, the client SHOULD use the HTTP GET method as
the HTTP GET method as defined in [HTTP]. The request MUST defined in [HTTP]. The request MUST happen over a secure protocol.
happen over a secure protocol. The requesting client MUST The requesting client MUST support TLS 1.2 [TLS] or its successors
support TLS 1.1 [TLS] or its successors and SHOULD use the and SHOULD use the latest version supported by both parties. When
latest version supported by both parties. When requesting requesting the URI/IRI, the client MUST only accept the system
the URI/IRI the client MUST only accept the system parameter block if the server identity was verified successfully by
parameter block if the server identity was verified TLS 1.2 [TLS] or its successors.
successfully by TLS 1.1 [TLS] or its successors.
A successful GET request returns in its body the base64 A successful GET request returns in its body the base64 [B64]
[B64] encoding of the DER-encoded [DER] IBESysParams encoding of the DER-encoded [DER] IBESysParams structure that is
structure that is described in the next section. This described in the next section. This structure MUST be encoded as an
structure MUST be encoded as an application/ibe-pp-data application/ibe-pp-data MIME type.
MIME type.
4.2. Parameter and Policy Format 4.2. Parameter and Policy Format
The IBE Public parameters are a structure of the form The IBE public parameters are a structure of the form
IBESysParams ::= SEQUENCE { IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) }, version INTEGER { v2(2) },
districtName IA5String, districtName IA5String,
districtSerial INTEGER, districtSerial INTEGER,
validity ValidityPeriod, validity ValidityPeriod,
ibePublicParameters IBEPublicParameters, ibePublicParameters IBEPublicParameters,
ibeIdentityType OBJECT IDENTIFIER, ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL ibeParamExtensions IBEParamExtensions OPTIONAL
} }
The fields of an IBESysParams structure have the following The fields of an IBESysParams structure have the following meanings.
meanings.
The version field specifies the version of the IBESysParams The version field specifies the version of the IBESysParams format.
format. For the format described in this document, this For the format described in this document, this MUST be set to 2.
MUST be set to 2.
The districtName field is an IA5String that MUST be an The districtName field is an IA5String that MUST be an encoding of an
encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled URI [URI] or IRI [IRI]. IRIs MUST be handled according to the
according to the procedures specified in Section 7.4 of procedures specified in Section 7.4 of [PKIX].
[PKIX].
The districtSerial field is an integer that represents a The districtSerial field is an integer that represents a unique set
unique set of IBE public parameters that are available at of IBE public parameters that are available at the URI or IRI defined
the URI or IRI defined by the districtName. If new by the districtName. If new parameters are published for a
parameters are published for a districtName, the districtName, the districtSerial MUST be increased to a number
districtSerial MUST be increased to a number greater than greater than the previously-used districtSerial.
the previously-used districtSerial.
The validity field defines lifetime of a specific instance The validity field defines the lifetime of a specific instance of the
of the IBESysParams and is defined to be the following: IBESysParams and is defined to be the following:
ValidityPeriod ::= SEQUENCE { ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime notAfter GeneralizedTime
} }
The values of notBefore and netAfter MUST be expressed in The values of notBefore and notAfter MUST be expressed in Greenwich
Greenwich Mean Time(Zulu), MUST include seconds (i.e. times Mean Time (Zulu), MUST include seconds (i.e., times are always
are always YYYYMMDDHHMMSSZ), even where the number of YYYYMMDDHHMMSSZ), even where the number of seconds is equal to zero,
seconds is equal to zero and MUST be expressed to the and MUST be expressed to the nearest second.
nearest second.
A client MUST verify that the date on which it uses the IBE A client MUST verify that the date on which it uses the IBE public
public parameters falls between the notBefore time and the parameters falls between the notBefore time and the notAfter time of
notAfter time of the IBE public parameters and MUST NOT use the IBE public parameters, and it MUST NOT use the parameters for IBE
the parameters for IBE encryption operations if they do encryption operations if they do not.
not.
IBE public parameters MUST be regenerated and republished IBE public parameters MUST be regenerated and republished whenever
whenever the values of ibePublicParameters, the values of ibePublicParameters, ibeIdentityType, or
ibeIdentityType, or ibeParamExtensions change for a ibeParamExtensions change for a district. A client SHOULD refetch
district. A client SHOULD refetch the IBE public parameters the IBE public parameters at an application-configurable interval to
at an application-configurable interval to ensure that it ensure that it has the most current version of the IBE public
has the most current version on the IBE public parameters. parameters.
It is possible to create identities for use in IBE that It is possible to create identities for use in IBE that have a time
have a time component, as described in [IBECMS], for component, as described in [IBECMS], for example. If such an
example. If such an identity is used, the time component of identity is used, the time component of the identity MUST fall
the identity MUST fall between the notBefore time and the between the notBefore time and the notAfter times of the IBE public
notAfter times of the IBE public parameters. parameters.
IBEPublicParameters is a structure containing public IBEPublicParameters is a structure containing public parameters that
parameters that correspond to IBE algorithms that the PKG correspond to IBE algorithms that the PKG supports. This structure
supports. This structure is defined to be following: is defined to be following:
IBEPublicParameters ::= SEQUENCE (1..MAX) OF IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter IBEPublicParameter
IBEPublicParameter ::= SEQUENCE { IBEPublicParameter ::= SEQUENCE {
ibeAlgorithm OBJECT IDENTIFIER, ibeAlgorithm OBJECT IDENTIFIER,
publicParameterData OCTET STRING publicParameterData OCTET STRING
} }
The ibeAlgorithm OBJECT IDENTIFIER specifies an IBE The ibeAlgorithm OID specifies an IBE algorithm. The OIDs for two
algorithm. The OIDs for two IBE algorithms, the Boneh- IBE algorithms (the Boneh-Franklin and Boneh-Boyen algorithms) and
Franklin and Boneh-Boyen algorithms and their their publicParameterData structures are defined in [IBCS].
publicParameterData structures are defined in [IBCS].
The publicParameterData is a DER-encoded [DER] structure The publicParameterData is a DER-encoded [DER] structure that
that contains the actual cryptographic parameters. Its contains the actual cryptographic parameters. Its specific structure
specific structure depends on the algorithm. depends on the algorithm.
The IBESysParams of a district MUST contain an OID that The IBESysParams of a district MUST contain an OID that identifies at
identifies at least one algorithm and MAY contain OIDs that least one algorithm and MAY contain OIDs that identify more than one
identify more than one algorithm. It MUST NOT contain two algorithm. It MUST NOT contain two or more IBEPublicParameter
or more IBEPublicParameter entries with the same algorithm. entries with the same algorithm. A client that wants to use
A client that wants to use IBESysParams can chose any of IBESysParams can chose any of the algorithms specified in the
the algorithms specified in the publicParameterData publicParameterData structure. A client MUST implement at least the
structure. A client MUST implement at least the Boneh- Boneh-Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen
Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen [IBCS] and other algorithms. If a client does not support any of the
[IBCS] and other algorithms. If a client does not support supported algorithms, it MUST generate an error message and fail.
any of the supported algorithms it MUST generate an error
message and fail.
ibeIdentityType is an OID that defines the type of ibeIdentityType is an OID that defines the type of identities that
identities that are used with this district. The OIDs and are used with this district. The OIDs and the required and optional
the required and optional fields for each OID are fields for each OID are application dependent. An example of this is
application dependent. An example of this is given in given in [IBECMS], which defines an identity format suitable for use
[IBECMS], which defines an identity format suitable for use in encrypting email.
in encrypting e-mail.
IBEParamExtensions is a set of extensions that can be used IBEParamExtensions is a set of extensions that can be used to define
to define additional parameters that particular additional parameters that particular implementations may require.
implementations may require. This structure is defined as This structure is defined as follows:
follows:
IBEParamExtensions ::= SEQUENCE OF IBEParamExtension IBEParamExtensions ::= SEQUENCE OF IBEParamExtension
IBEParamExtension ::= SEQUENCE { IBEParamExtension ::= SEQUENCE {
ibeParamExtensionOID OBJECT IDENTIFIER, ibeParamExtensionOID OBJECT IDENTIFIER,
ibeParamExtensionValue OCTET STRING ibeParamExtensionValue OCTET STRING
} }
The contents of the octet string ibeParamExtensionValue are The contents of the octet string ibeParamExtensionValue are defined
defined by the specific ibeParamExtensionOID. The by the specific ibeParamExtensionOID. The IBEParamExtensions of a
IBEParamExtensions of a district MAY have any number of district MAY have any number of extensions, including zero. One
extensions, including zero. One example of extensions that example of extensions that have been used in practice is to provide a
have been used in practice is to provide a URI where an URI where an encrypted message can be decrypted and viewed by users
encrypted message can be decrypted and viewed by users of of webmail systems. Another example is to provide commercial
webmail systems. Another example is to provide commercial branding information, so that a bank can provide a different user
branding information, so that a bank can provide a interface for customers of different lines of business.
different user interface for customers of different lines
of business.
If a client receives Public parameters that contain an If a client receives public parameters that contain an extension that
extension that it is unable to process, it MUST NOT use the it is unable to process, it MUST NOT use the values in the
values in the IBESysParams structure for any cryptographic IBESysParams structure for any cryptographic operations. Clients
operations. Clients MUST be able to process an IBESysParams MUST be able to process an IBESysParams structure that contains no
structure that contains no IBEParamExtensions. IBEParamExtensions.
The pkgURI OBJECT IDENTIFIER that is defined below defines The pkgURI OID that is defined below defines an IBEParamExtensions
an IBEParamExtensions structure that contains the URI or structure that contains the URI or IRI of a Private Key Generator.
IRI of a Private Key Generator. The presence of this OBJECT The presence of this OID in an IBEParamExtension indicates that
IDENTIFIER in an IBEParamExtension indicates that clients clients MUST use the protocol defined in Section 5 of this document
MUST use the protocol defined in Section 5 of this document to obtain IBE private keys from the PKG and MUST do so using the
to obtain IBE private keys from the PKG and do so using the URI/IRI that is defined by the ibeParamExtensionValue in the
URI/IRI that is defined by the value defined by the IBEParamExtension.
ibeParamExtensionValue in the IBEParamExtension.
If the PKG is publicly-accessible, this extension SHOULD be If the PKG is publicly-accessible, this extension SHOULD be present
present to allow the automatic retrieval of private keys to allow the automatic retrieval of private keys for recipients of
for recipients of encrypted messages. For this extension encrypted messages. For this extension, the ibeParamExtensionValue
the ibeParamExtensionValue OCTET STRING is an IA5String OCTET STRING is an IA5String containing the URI [URI] or IRI [IRI] of
containing the URI [URI] or IRI [IRI] of the PKG where IBE the PKG where IBE private keys can be obtained. IRIs MUST be handled
private keys can be obtained. IRIs MUST be handled according to the procedures specified in Section 7.4 of [PKIX].
according to the procedures specified in Section 7.4 of
[PKIX].
ibeParamExt OBJECT IDENTIFIER ::= { ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2) ibcs ibcs3(3) parameter-extensions(2)
} }
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
4.3. The application/ibe-pp-data MIME type 4.3. The application/ibe-pp-data MIME Type
The following summarizes the properties of the The following summarizes the properties of the
application/ibe-pp-data MIME type. application/ibe-pp-data MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-pp-data MIME subtype name: ibe-pp-data
Mandatory parameters: none Mandatory parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: This media type MUST be encoded as Encoding considerations: This media type MUST be encoded as 7-bit
7bit (us-ascii text [ASCII]). (US-ASCII text [ASCII]).
Security considerations: The data conveyed as this media Security considerations: The data conveyed as this media type are the
type are the public parameters needed for the operation of public parameters needed for the operation of a cryptographic
a cryptographic system. To ensure that the parameters can system. To ensure that the parameters can be trusted, the request
be trusted, the request for these parameters must take for these parameters must take place over a secure protocol, such
place over a secure protocol, TLS 1.1 or its successors. To as TLS 1.2 or its successors. To ensure the validity of the
ensure the validity of the server, the client MUST verify server, the client MUST verify the server certificate and MUST
the server certificate and MUST abort the parameter request abort the parameter request if the verification of the server
if the verification of the server certificate of the TLS certificate of the TLS connection fails. This media type contains
connection fails. This media type contains no active no active content and does not use compression.
content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known interoperability
interoperability considerations for this media type. considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that implement
implement IBE in compliance with this specification will IBE in compliance with this specification will use this media
use this media type. The most commonly-used of these type. The most commonly used of these applications are encrypted
applications are encrypted email and file encryption. email and file encryption.
Additional information: none Additional information: none
Person and email address for further information: Luther Person and email address for further information: Luther Martin,
Martin, martin@voltage.com. martin@voltage.com.
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Luther Martin,
martin@voltage.com. Author/Change controller: Luther Martin, martin@voltage.com.
5. Private Key Request Protocol 5. Private Key Request Protocol
5.1. Overview 5.1. Overview
When requesting a private key, a client has to transmit When requesting a private key, a client has to transmit three
three parameters: parameters:
1. The IBE algorithm for which the key is being 1. The IBE algorithm for which the key is being requested
requested
2. The identity for which it is requesting a key 2. The identity for which it is requesting a key
3. Authentication credentials for the individual 3. Authentication credentials for the individual requesting the
requesting the key key
These two are often not the same as a single user may have The identity for which a client requests a key may not necessarily be
access to multiple aliases. For example an email user may the same as the identity that the authentication credentials
have access to the keys that correspond to two different validate. This may happen, for example, when a single user has
email addresses, e.g. bob@example.com and access to multiple aliases. For example, an email user may have
bob.smith@example.com. 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, This section defines the protocol to request private keys, a minimum
a minimum user authentication method for interoperability, user authentication method for interoperability, and how to pass
and how to pass authentication credentials to the server. authentication credentials to the server. It assumes that a client
It assumes that a client has already determined the URI/IRI has already determined the URI/IRI of the PKG. This can be done from
of the PKG. This can be done from information included in information included in the IBE message format and the public
the IBE message format and the public parameters of the IBE parameters of the IBE system.
system.
The technique for fetching an IBE private key using the The technique for fetching an IBE private key using the process
process defined in this section is indicated by the OBJECT defined in this section is indicated by the OBJECT IDENTIFIER pkgURI,
IDENTIFIER pkgURI, which is defined to be the following: which is defined to be the following:
ibcs OBJECT IDENTIFIER ::= { ibcs OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) organization(1) identicrypt(114334) ibcs(1)
} }
ibeParamExt OBJECT IDENTIFIER ::= { ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2) ibcs ibcs3(3) parameter-extensions(2)
} }
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
5.2. Private Key Request 5.2. Private Key Request
To request a private key, a client MUST perform a HTTP POST To request a private key, a client MUST perform a HTTP POST method as
method as defined in [HTTP]. The request MUST take place defined in [HTTP]. The request MUST take place over a secure
over a secure protocol. The requesting client MUST support protocol. The requesting client MUST support TLS 1.2 [TLS] or its
TLS 1.1 [TLS] or its successors, using the latest version successors, using the latest version supported by both the client and
supported by both the client and the PKG. When requesting the PKG. When requesting the URI/IRI, the client MUST verify the
the URI/IRI the client MUST verify the server certificate server certificate [HTTPTLS], and it MUST abort the key request if
[HTTPTLS], and MUST abort the key request if the server the server certificate verification of the TLS connection fails.
certificate verification of the TLS connection fails. Doing Doing so is critical to protect the authentication credentials and
so is critical to protect the authentication credentials the private key against man-in-the-middle attacks when it is
and the private key against man-in-the-middle attacks when transmitted from the key server to the client.
it is transmitted from the key server to the client.
5.3. Request Structure 5.3. Request Structure
The POST method contains in its body the following XML The POST method contains in its body the following XML structure that
structure that MUST be encoded as an application/ibe-key- MUST be encoded as an application/ibe-key-request+xml MIME type:
request+xml MIME type:
<ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:header> <ibe:header>
<ibe:client version="clientID"/> <ibe:client version="clientID"/>
</ibe:header> </ibe:header>
<ibe:body> <ibe:body>
<ibe:keyRequest> <ibe:keyRequest>
<ibe:algorithm> <ibe:algorithm>
algorithmOID algorithmOID
</ibe:algorithm> </ibe:algorithm>
<ibe:id> <ibe:id>
ibeIdentityInfo ibeIdentityInfo
</ibe:id> </ibe:id>
</ibe:keyRequest> </ibe:keyRequest>
<ibe:authData> <ibe:authData>
ibeAuthData ibeAuthData
</ibe:authData> </ibe:authData>
</ibe:body> </ibe:body>
</ibe:request> </ibe:request>
A <ibe:request> SHOULD include an <ibe:client> element in A <ibe:request> SHOULD include an <ibe:client> element in the
the <ibe:header> part of a key request that contains an <ibe:header> part of a key request that contains an ASCII string that
ASCII string that identifies the client type and client identifies the client type and client version.
version.
A key request MUST contain an <ibe:oid> element that A key request MUST contain an <ibe:oid> element that contains the
contains the base64 [B64] encoding of a DER-encoded [DER] base64 [B64] encoding of a DER-encoded [DER] object identifier that
object identifier that identifies the algorithm for which a identifies the algorithm for which a key is requested. OIDs for the
key is requested. OIDs for the BB1 and BF algorithms are Boneh-Boyen (BB1) and Boneh-Franklin (BF) algorithms are listed in
listed in [IBCS]. [IBCS].
A key request MUST contain an <ibe:id> element that A key request MUST contain an <ibe:id> element that contains the
contains the identity that the private key is being identity that the private key is being requested for. This identity
requested for. This identity is the base64 [B64] encoding is the base64 [B64] encoding of a DER-encoded [DER] ASN.1 structure.
of a DER-encoded [DER] ASN.1 structure. This structure This structure defines a user's identity in a way appropriate for the
defines a user's identity in a way appropriate for the application. An example of such a structure that is appropriate for
application. An example of such a structure that is use in encrypting email is defined in [IBECMS].
appropriate for use in encrypting e-mail is defined in
[IBECMS].
A key request MAY contain an <ibe:authData> element. This A key request MAY contain an <ibe:authData> element. This element
element contains authentication information that the PKG contains authentication information that the PKG can use to determine
can use to determine whether or not a request for a whether or not a request for a particular IBE private key should be
particular IBE private key should be granted. granted.
A client MAY include optional additional XML elements in A client MAY include optional additional XML elements in the
the <ibe:body> part of the key request. A PKG MUST be able <ibe:body> part of the key request. A PKG MUST be able to process
to process key requests that contain no such optional key requests that contain no such optional elements.
elements.
5.4. The application/ibe-key-request+xml MIME type 5.4. The application/ibe-key-request+xml MIME type
The following summarizes the properties of the application/ The following summarizes the properties of the
ibe-key-request+xml MIME type. application/ibe-key-request+xml MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-key-request+xml MIME subtype name: ibe-key-request+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: This media type MUST be encoded as Encoding considerations: This media type MUST be encoded as US-ASCII
us-ascii [ASCII]. [ASCII].
Security considerations: The data conveyed in this media Security considerations: The data conveyed in this media type may
type may contain authentication credentials. Because of contain authentication credentials. Because of this, its
this, its confidentiality and integrity is extremely confidentiality and integrity is extremely important. To ensure
important. To ensure this, the request for an IBE private this, the request for an IBE private key must take place over a
key must take place over a secure protocol, TLS 1.1 or its secure protocol, such as TLS 1.2 or its successors. To ensure the
successors. To ensure the validity of the server, the validity of the server, the client MUST verify the server
client MUST verify the server certificate and MUST abort certificate and MUST abort the key request if the verification of
the key request if the verification of the server the server certificate of the TLS connection fails. This media
certificate of the TLS connection fails. This media type type contains no active content and does not use compression.
contains no active content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known interoperability
interoperability considerations for this media type. considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that implement
implement IBE in compliance with this specification will IBE in compliance with this specification will use this media
use this media type. The most commonly-used of these type. The most commonly used of these applications are encrypted
applications are encrypted email and file encryption. email and file encryption.
Additional information: none Additional information: none
Person and email address for further information: Luther Person and email address for further information: Luther Martin,
Martin, martin@voltage.com. martin@voltage.com.
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Luther Martin, Author/Change controller: Luther Martin, martin@voltage.com.
martin@voltage.com.
5.5. Authentication 5.5. Authentication
When a client requests a key from a PKG, the PKG MUST When a client requests a key from a PKG, the PKG MUST authenticate
authenticate the client before issuing the key. the client before issuing the key. Authentication may either be done
Authentication may either be done through the key request through the key request structure or as part of the secure transport
structure or as part of the secure transport protocol. protocol.
A client or server implementing the request protocol MUST A client or server implementing the request protocol MUST support
support HTTP Basic Auth [AUTH] and SHOULD also support HTTP HTTP Basic Auth [AUTH] and SHOULD also support HTTP Digest Auth
Digest Auth [AUTH]. Applications MAY also use other means [AUTH]. Applications MAY also use other means of authentication that
of authentication that are appropriate for the application. are appropriate for the application. An email application, for
An e-mail application, for example, might rely on deployed example, might rely on deployed email infrastructure for this.
e-mail infrastructure for this, for example.
For authentication methods that are not done by the For authentication methods that are not done by the transport
transport protocol, a client MAY include additional protocol, a client MAY include additional authentication information
authentication information in XML elements in the in XML elements in the <ibe:authData> element of a key request. If a
<ibe:authData> element of a key request. If a client does client does not know how to authenticate to a server, the client MAY
not know how to authenticate to a server, the client MAY send a key request without authentication information. If the key
send a key request without authentication information. If server requires the client to authenticate externally, it MAY reply
the key server requires the client to authenticate with an IBE201 responseCode (as defined below) to redirect the client
externally, it MAY reply with an IBE201 responseCode as to the correct authentication mechanism. After receiving an
defined below to redirect the client to the correct authentication credential from this external mechanism, a client can
authentication mechanism. After receiving an authentication then use the credential to form a key request that contains the
credential from this external mechanism, a client can then
use the credential to form a key request that contains the
additional authentication data. additional authentication data.
5.6. Server Response Format 5.6. Server Response Format
The key server replies to the HTTP request with an HTTP The key server replies to the HTTP request with an HTTP response. If
response. If the response contains a client error or server the response contains a client error or server error status code, the
error status code, the client MUST abort the key request client MUST abort the key request and fail.
and fail.
If the PKG replies with an HTTP response that has a status If the PKG replies with an HTTP response that has a status code
code indicating success, the body of the reply MUST contain indicating success, the body of the reply MUST contain the following
the following XML structure that MUST be encoded as an XML structure that MUST be encoded as an
application/ibe-pkg-reply+xml MIME type: application/ibe-pkg-reply+xml MIME type:
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="responseCode"/> <ibe:responseType value="responseCode"/>
<ibe:body> <ibe:body>
bodyTags bodyTags
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The responseCode attribute contains an ASCII string that The responseCode attribute contains an ASCII string that describes
describes the type of response from the key server. The the type of response from the key server. The list of currently-
list of currently-defined responseCodes and their defined responseCodes and their associated meanings is:
associated meanings is:
IBE100 KEY_FOLLOWS IBE100 KEY_FOLLOWS
IBE101 RESERVED IBE101 RESERVED
IBE201 FOLLOW_ENROLL_URI IBE201 FOLLOW_ENROLL_URI
IBE300 SYSTEM_ERROR IBE300 SYSTEM_ERROR
IBE301 INVALID_REQUEST IBE301 INVALID_REQUEST
IBE303 CLIENT_OBSOLETE IBE303 CLIENT_OBSOLETE
IBE304 AUTHORIZATION DENIED IBE304 AUTHORIZATION DENIED
5.6.1. The IBE100 responseCode 5.6.1. The IBE100 responseCode
If the key request was successful, the key server responds If the key request was successful, the key server responds with a
with a responseCode of IBE100, and the <ibe:body> MUST responseCode of IBE100, and the <ibe:body> MUST contain a
contain a <ibe:privateKey> element that contains a valid <ibe:privateKey> element that contains a valid private key. An
private key. An example of this is shown below. example of this is shown below.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE100"/> <ibe:responseType value="IBE100"/>
<ibe:body> <ibe:body>
<ibe:privateKey> <ibe:privateKey>
privateKey privateKey
</ibe:privateKey> </ibe:privateKey>
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The privateKey is the base64 [B64] encoding of the DER The privateKey is the base64 [B64] encoding of the DER encoding [DER]
encoding [DER] of the following structure: of the following structure:
IBEPrivateKeyReply ::= SEQUENCE { IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo, pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER, pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING, pkgKeyData OCTET STRING,
pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption pkgOptions SEQUENCE SIZE (1..MAX) OF PKGOption
} }
PKGOption ::= SEQUENCE { PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER, optionID OBJECT IDENTIFIER,
optionValue OCTET STRING optionValue OCTET STRING
} }
The pkgIdentity is an IBEIdentityInfo structure that MUST The pkgIdentity is an IBEIdentityInfo structure that MUST be
be identical to the IBEIdentityInfo structure that was sent identical to the IBEIdentityInfo structure that was sent in the key
in the key request. request.
The pkgAlgorithm is an OID that identifies the algorithm of The pkgAlgorithm is an OID that identifies the algorithm of the
the returned private key. The OIDs for the BB and BF returned private key. The OIDs for the BB1 and BF algorithms are
algorithms are defined in [IBCS]. defined in [IBCS].
The pkgKeyData is a structure that contains the actual The pkgKeyData is a structure that contains the actual private key.
private key. Private-key formats for the BB and BF Private-key formats for the BB1 and BF algorithms are defined in
algorithms are defined in [IBCS]. [IBCS].
A server MAY pass back additional information to a client A server MAY pass back additional information to a client in the
in the pkgOptions structure. A client that receives a pkgOptions structure. A client that receives a IBEPrivateKeyReply
IBEPrivateKeyReply from a PKG that contains information in from a PKG that contains information in a pkgOptions structure that
a pkgOptions structure that it is unable process MUST NOT it is unable process MUST NOT use the IBE private key in the
use the IBE private key in the IBEPrivateKeyReply structure IBEPrivateKeyReply structure for any cryptographic operations. A
for any cryptographic operations. A client MUST be able to client MUST be able to process an IBEPrivateKeyReply that contains no
process an IBEPrivateKeyReply that contains no PKGOptions PKGOptions structure.
structure.
5.6.2. The IBE101 responseCode 5.6.2. The IBE101 responseCode
The responseCode IBE101 is reserved to ensure The responseCode IBE101 is reserved to ensure interoperability with
interoperability with earlier versions of the protocol that earlier versions of the protocol described in this document. An
is described in this document. An example of such a example of such a response is shown below. A response with the
response is shown below. A response with the IBE101 IBE101 responseCode SHOULD contain no body. If information is
responseCode SHOULD contain no body. If information is contained in the body of such a response, the client receiving the
contained in the body of such a response, the client response MUST discard any data that is contained in the body.
receiving the response MUST discard any data that is
contained in the body.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE101"/> <ibe:responseType value="IBE101"/>
<ibe:body> <ibe:body>
This message must be discarded by the recipient This message must be discarded by the recipient
</ibe:body </ibe:body
</ibe:response> </ibe:response>
5.6.3. The IBE201 responseCode 5.6.3. The IBE201 responseCode
A PKG MAY support authenticating users to external A PKG MAY support authenticating users to external authentication
authentication mechanisms. If this is the case, the server mechanisms. If this is the case, the server replies to the client
replies to the client with responseCode IBE201 and the body with responseCode IBE201 and the body of the response MUST contain a
of the response MUST contain a <ibe:location> element that <ibe:location> element that specifies the URI of the authentication
specifies the URI of the authentication mechanism. An mechanism. An example of such a response is shown below.
example of such a response is shown below.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE201"/> <ibe:responseType value="IBE201"/>
<ibe:body> <ibe:body>
<ibe:location <ibe:location
URI="http://www.example.com/enroll.asp"/> URI="http://www.example.com/enroll.asp"/>
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
The client can now contact the URI returned in such a response using
The client can now contact the URI returned in such a the same mechanisms as defined in Section 5.2 to obtain an
response using the same mechanisms as defined in Section authentication credential. Once the client has obtained the
4.2 to obtain an authentication credential. Once the client credential from the authentication mechanism at this URI, it sends a
has obtained the credential from the authentication new key request to the PKG with the correct authentication
mechanism at this URI, it sends a new key request to the credentials contained in the request, placing the authentication
PKG with the correct authentication credentials contained credential in the <ibe:authData> element of a key request as
in the request, placing the authentication credential in described in Section 5.5.
the <ibe:authData> element of a key request as described in
Section 4.4.
5.6.4. The IBE300 responseCode 5.6.4. The IBE300 responseCode
The IBE300 responseCode indicates that an internal server The IBE300 responseCode indicates that an internal server error has
error has occurred. Information that may help diagnose the occurred. Information that may help diagnose the error MAY be
error MAY be included in the body of such a response. An included in the body of such a response. An example of such a
example of such a response is shown below. Upon receiving a response is shown below. Upon receiving a IBE300 responseCode, the
IBE300 responseCode, the client MUST abort the key request client MUST abort the key request and discard any data that was
and discard any data that was included in the body of the included in the body of the response.
response.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE300"/> <ibe:responseType value="IBE300"/>
<ibe:body> <ibe:body>
Widget phlebotomy failure Widget phlebotomy failure
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
5.6.5. The IBE301 responseCode 5.6.5. The IBE301 responseCode
The IBE303 responseCode indicates that an invalid key The IBE303 responseCode indicates that an invalid key request has
request has been received by the server. Information that been received by the server. Information that may help diagnose the
may help diagnose the error MAY be included in the body of error MAY be included in the body of such a response. An example of
such a response. An example of such a response is shown such a response is shown below. Upon receiving an IBE301
below. Upon receiving an IBE301 responseCode, the client responseCode, the client MUST abort the key request and discard any
MUST abort the key request and discard any data that was data that was included in the body of the response.
included in the body of the response.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE301"/> <ibe:responseType value="IBE301"/>
<ibe:body> <ibe:body>
Some additional stuff Some additional stuff
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
5.6.6. The IBE303 responseCode 5.6.6. The IBE303 responseCode
The IBE303 responseCode indicates that the server is unable The IBE303 responseCode indicates that the server is unable to
to correctly process the request because the version of the correctly process the request because the version of the request is
request is no longer supported by the server. Information no longer supported by the server. Information that may help
that may help diagnose the error MAY be included in the diagnose the error MAY be included in the body of such a response.
body of such a response. An example of such a response is
shown below. Upon receiving an IBE303 responseCode, the An example of such a response is shown below. Upon receiving an
client MUST abort the key request and discard any data that IBE303 responseCode, the client MUST abort the key request and
was included in the body of the response. discard any data that was included in the body of the response.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE303"/> <ibe:responseType value="IBE303"/>
<ibe:body> <ibe:body>
Version 3.3 or later needed Version 3.3 or later needed
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
5.6.7. The IBE304 responseCode 5.6.7. The IBE304 responseCode
The IBE304 responseCode indicates that a valid key request The IBE304 responseCode indicates that a valid key request has been
has been received by the server but the authentication received by the server, but the authentication credentials provided
credentials provided were invalid. Information that may were invalid. Information that may help diagnose the error MAY be
help diagnose the error MAY be included in the body of such included in the body of such a response. An example of such a
a response. An example of such a response is shown below. response is shown below. Upon receiving an IBE304 responseCode, the
Upon receiving an IBE304 responseCode, the client MUST client MUST abort the key request and discard any data that was
abort the key request and discard any data that was
included in the body of the response. included in the body of the response.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE304"/> <ibe:responseType value="IBE304"/>
<ibe:body> <ibe:body>
Helpful error message Helpful error message
</ibe:body> </ibe:body>
</ibe:response> </ibe:response>
5.7. The application/ibe-pkg-reply+xml MIME type 5.7. The application/ibe-pkg-reply+xml MIME type
skipping to change at page 26, line 13 skipping to change at page 22, line 46
application/ibe-pkg-reply+xml MIME type. application/ibe-pkg-reply+xml MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-pkg-reply+xml MIME subtype name: ibe-pkg-reply+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: This media type MUST be encoded as Encoding considerations: This media type MUST be encoded as US-ASCII
us-ascii [ASCII]. [ASCII].
Security considerations: The data conveyed as this media Security considerations: The data conveyed as this media type is an
type is an IBE private key, so its confidentiality and IBE private key, so its confidentiality and integrity are
integrity is extremely important. To ensure this, the extremely important. To ensure this, the response from the server
response from the server that contains an IBE private key that contains an IBE private key must take place over a secure
must take place over a secure protocol, TLS 1.1 or its protocol, such as TLS 1.2 or its successors. To ensure the
successors. To ensure the validity of the server, the validity of the server, the client MUST verify the server
client MUST verify the server certificate and MUST abort certificate and MUST abort the key request if the verification of
the key request if the verification of the server the server certificate of the TLS connection fails. This media
certificate of the TLS connection fails. This media type type contains no active content and does not use compression.
contains no active content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known interoperability
interoperability considerations for this media type. considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that implement
implement IBE in compliance with this specification will IBE in compliance with this specification will use this media
use this media type. The most commonly-used of these type. The most commonly used of these applications are encrypted
applications are encrypted email and file encryption. email and file encryption.
Additional information: none Additional information: none
Person and email address for further information: Luther Person and email address for further information: Luther Martin,
Martin, martin@voltage.com. martin@voltage.com.
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Luther Martin, Author/Change controller: Luther Martin, martin@voltage.com.
martin@voltage.com.
6. ASN.1 Module 6. ASN.1 Module
The following ASN.1 module summarizes the ASN.1 definitions The following ASN.1 module summarizes the ASN.1 definitions discussed
discussed in this document. in this document.
IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) IBEARCH-module { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibearch(5) organization(1) identicrypt(114334) ibcs(1) ibearch(5)
module(5) version(1) module(5) version(1)
} }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBESysParams ::= SEQUENCE { IBESysParams ::= SEQUENCE {
version INTEGER { v2(2) }, version INTEGER { v2(2) },
skipping to change at page 28, line 33 skipping to change at page 25, line 15
district IA5String, district IA5String,
serial INTEGER, serial INTEGER,
identityType OBJECT IDENTIFIER, identityType OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
END END
7. Security Considerations 7. Security Considerations
7.1. Attacks outside the scope of this document 7.1. Attacks outside the Scope of This Document
Attacks on the cryptographic algorithms that are used to Attacks on the cryptographic algorithms that are used to implement
implement IBE are outside the scope of this document. Such IBE are outside the scope of this document. Such attacks are
attacks are detailed in [IBCS], which defines parameters detailed in [IBCS], which defines parameters that give 80-bit,
that give 80-bit, 112-bit and 128-bit encryption strength. 112-bit, and 128-bit encryption strength. We assume that capable
We assume that capable administrators of an IBE system will administrators of an IBE system will select parameters that provide a
select parameters that provide a sufficient resistance to sufficient resistance to cryptanalytic attacks by adversaries.
cryptanalytic attacks by adversaries.
Attacks that give an adversary the ability to access or Attacks that give an adversary the ability to access or change the
change the information on a PPS or PKG, especially the information on a PPS or PKG, especially the cryptographic material
cryptographic material (referred to in this document as the (referred to in this document as the master secret), will defeat the
master secret), will defeat the security of an IBE system. security of an IBE system. In particular, if the cryptographic
In particular, if the cryptographic material is compromised material is compromised, the adversary will have the ability to
the adversary will have the ability to recreate any user's recreate any user's private key and therefore decrypt all messages
private key and therefore decrypt all messages protected protected with the corresponding public key. To address this
with the corresponding public key. To address this concern, concern, it is highly RECOMMENDED that best practices for physical
it is highly RECOMMENDED that best practices for physical and operational security for PPS and PKG servers be followed and that
and operational security for PPS and PKG servers be these servers be configured (sometimes known as hardened) in
followed and that these servers be configured (sometimes accordance with best current practices [NIST]. An IBE system SHOULD
known as hardened) in accordance with best current be operated in an environment where illicit access is infeasible for
practices [NIST]. An IBE system SHOULD be operated in an
environment where illicit access is infeasible for
attackers to obtain. attackers to obtain.
Attacks that require administrative or IBE user equivalent Attacks that require administrative access or IBE-user-equivalent
access to machines used by either the client or the server access to machines used by either the client or the server components
components defined in this document are also outside the defined in this document are also outside the scope of this document.
scope of this document.
We also assume that all administrators of a system We also assume that all administrators of a system implementing the
implementing the protocols that are defined in this protocols that are defined in this document are trustworthy and will
document are trustworthy and will not abuse their authority not abuse their authority to bypass the security provided by an IBE
to bypass the security provided by an IBE system. system. Similarly, we assume that users of an IBE system will behave
Similarly, we assume that users of an IBE system will responsibly, not sharing their authentication credentials with
behave responsibly, not sharing their authentication others. Thus, attacks that require such assumptions are outside the
credentials with others. Thus attacks that require such scope of this document.
assumptions are outside the scope of this document.
7.2. Attacks within the scope of this document 7.2. Attacks within the Scope of This Document
Attacks within the scope of this document are those that Attacks within the scope of this document are those that allow an
allow an adversary to: adversary to:
o passively monitor information transmitted between o passively monitor information transmitted between users of an
users of an IBE system and the PPS and PKG IBE system and the PPS and PKG
o masquerade as a PPS or PKG o masquerade as a PPS or PKG
o perform a DOS attack on a PPS or PKG o perform a denial-of-service (DoS) attack on a PPS or PKG
o easily guess an IBE users authentication o easily guess an IBE users authentication credential
credential
7.2.1. Attacks on the protocols defined in this document 7.2.1. Attacks on the Protocols Defined in This Document
All communications between users of an IBE system and the All communications between users of an IBE system and the PPS or PKG
PPS or PKG are protected using TLS 1.1 [TLS]. The IBE are protected using TLS 1.2 [TLS]. The IBE system defined in this
system defined in this document provides no additional document provides no additional security protections for the
security protections for the communications between IBE communications between IBE users and the PPS or PKG. Therefore, the
users and the PPS or PKG. Therefore the described IBE described IBE system is completely dependent on the TLS security
system is completely dependent on the TLS security mechanisms for authentication of the PKG or PPS server and for
mechanisms for authentication of the PKG or PPS server and confidentiality and integrity of the communications. Should there be
for confidentiality and integrity of the communications. a compromise of the TLS security mechanisms, the integrity of all
Should there be a compromise of the TLS security communications between an IBE user and the PPS or PKG will be
mechanisms, the integrity of all communications between an suspect.
IBE user and the PPS or PKG will be suspect.
The protocols defined in this document do not explicitly The protocols defined in this document do not explicitly defend
defend against an attacker masquerading as a legitimate IBE against an attacker masquerading as a legitimate IBE PPS or PKG. The
PPS or PKG. The protocols rely on the server authentication protocols rely on the server authentication mechanism of TLS [TLS].
mechanism of TLS [TLS]. In addition to the TLS server In addition to the TLS server authentication mechanism, IBE client
authentication mechanism IBE client software can provide software can provide protection against this possibility by providing
protection against this possibility by providing user user interface capabilities that allow users to visually determine
interface capabilities that allows users to visually that a connection to PPS and PKG servers is legitimate. This
determine that a connection to PPS and PKG servers is additional capability can help ensure that users cannot easily be
legitimate. This additional capability can help ensure that tricked into providing valid authorization credentials to an
users cannot easily be tricked into providing valid attacker.
authorization credentials to an attacker.
The protocols defined in this document are also vulnerable The protocols defined in this document are also vulnerable to attacks
to attacks against an IBE PPS or PKG. Denial of service against an IBE PPS or PKG. Denial-of-service attacks against either
attacks against either component can result in users unable component can result in users' being unable to encrypt or decrypt
to encrypt or decrypt using IBE, and users of an IBE system using IBE, and users of an IBE system SHOULD take the appropriate
SHOULD take the appropriate countermeasures [DOS, BGPDOS] countermeasures [DOS, BGPDOS] that their use of IBE requires.
that their use of IBE requires.
The IBE user authentication method selected by an IBE PKG The IBE user authentication method selected by an IBE PKG SHOULD be
SHOULD be of sufficient strength to prevent attackers from of sufficient strength to prevent attackers from easily guessing the
easily guessing the IBE user's authentication credentials IBE user's authentication credentials through trial and error.
through trial and error.
8. IANA Considerations 8. IANA Considerations
8.1. Media types 8.1. Media Types
This specification proposes the registration of three media With this specification, IANA has registered three media types in the
types in the standard registration tree. These are standard registration tree. These are application/ibe-pp-data,
application/ibe-pp-data, application/ibe-key-request+xml, application/ibe-key-request+xml, and application/ibe-pkg-reply+xml.
and application/ibe-pkg-reply+xml. The media type The media type application/ibe-pp-data is defined in Section 4.3 of
application/ibe-pp-data is defined in Section 4.3 of this this document. The media type application/ibe-key-request+xml is
document. The media type application/ibe-key-request+xml is
defined in Section 5.4 of this document. The media type defined in Section 5.4 of this document. The media type
application/ibe-pkg-reply+xml is defined in Section 5.7 of application/ibe-pkg-reply+xml is defined in Section 5.7 of this
this document. document.
8.2. XML namespace 8.2. XML Namespace
The IANA is requested to register the following namespace The IANA is requested to register the following namespace identifier:
identifier:
urn:ietf:params:xml:ns:ibe urn:ietf:params:xml:ns:ibe
Registrant Contact: Registrant Contact:
Luther Martin Luther Martin
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd Suite 100
Palo Alto CA 94304 Palo Alto, CA 94304
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
XML: XML:
BEGIN <?xml version="1.0"?>
<ibe:request xmlns:ibe="urn:ietf:params:xml:ns:ibe"> <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML Basic 1.0//EN"
<ibe:header> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<ibe:client version="clientID"/> <html xmlns="http://www.w3.org/1999/xhtml">
</ibe:header> <head>
<ibe:body> <meta http-equiv="content-type"
<ibe:keyRequest> content="text/html;charset=iso-8859-1"/>
<ibe:algorithm> <title>Identity-Based Encryption</title>
algorithmOID </head>
</ibe:algorithm> <body>
<ibe:id> <h1>Namespace for Identity-Based Encryption</h1>
ibeIdentityInfo <h2>urn:ietf:params:xml:ns:ibe</h2>
</ibe:id> <p>
</ibe:keyRequest> <a href="http://www.rfc-editor.org/rfc/rfc5408.txt">RFC5408</a>.
<ibe:authData> </p>
ibeAuthData </body>
</ibe:authData> </html>
</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
9. References 9. References
9.1. Normative References 9.1. Normative References
[ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7- [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7-bit Coded
bit Coded Character Set for Information Exchange Character Set for Information Exchange.
[ASN1] ITU-T Recommendation X.680: Information Technology - [ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997. Abstract Syntax Notation One, 1997.
[AUTH] J. Franks, et al., "HTTP Authentication: Basic and [AUTH] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Digest Access Authentication", RFC 2617, June 1999. Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[B64] N. Freed and N. Borenstein, "Multipurpose Internet [B64] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Mail Extensions(MIME) Part One: Format of Internet Extensions (MIME) Part One: Format of Internet Message
Message Bodies," RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[CMS] R. Housley, "Cryptographic Message Syntax (CMS)," RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 3852, July 2004.
[DER] ITU-T Recommendation X.690: OSI Networking and System [DER] ITU-T Recommendation X.690: OSI Networking and System
Aspects: Abstract Syntax Notation One (ASN.1), July Aspects: Abstract Syntax Notation One (ASN.1), July 2002.
2002.
[DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: [DOS] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Defeating Denial of Service Attacks which employ IP Source
Source Address Spoofing," RFC 2827, BCP 38, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[HTTP] R. Fielding, et al., "Hypertext Transfer Protocol -- [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
HTTP/1.1", RFC 2616, June 1999. L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000. [HTTPTLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography [IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Standard (IBCS) #1: Supersingular Curve Implementations of
Implementations of the BF and BB1 Cryptosystems," RFC the BF and BB1 Cryptosystems", RFC 5091, December 2007.
5091, December 2007.
[IRI] M. Deurst and M. Suignard, "Internationalized [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Resource Identifiers (IRIs)," RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[KEY] S. Brander, "Key Words for Use in RFCs to Indicate [KEY] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKIX] D. Cooper, et al., "Internet X.509 Public Key [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Infrastructure Certificate and Certificate Revocation Housley, R., and W. Polk, "Internet X.509 Public Key
[SMTP] J. Klensin, "Simple Mail Transfer Protocol," RFC Infrastructure Certificate and Certificate Revocation List
5321, October 2008. (CRL) Profile", RFC 5280, May 2008.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
Security (TLS) Protocol Version 1.1," RFC 4346, April October 2008.
2006.
[URI] T. Berners-Lee, R. Fielding, and L. Masinter, [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
"Uniform Resource Identifier (URI): Generic Syntax", (TLS) Protocol Version 1.2", RFC 5246, August 2008.
STD 66, RFC 3986, January 2005.
[XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Edition), September 2006. Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth Edition),
September 2006.
9.2. Informative References 9.2. Informative References
[BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- [BGPDOS] Turk, D., "Configuring BGP to Block Denial-of-Service
Service Attacks," RFC 3882, September 2004. Attacks", RFC 3882, September 2004.
[IBECMS] L. Martin and M. Schertler, "Using the Boneh- [IBECMS] Martin, L. and M. Schertler, "Using the Boneh-Franklin
Franklin identity-based encryption algorithm with the Identity-Based Encryption Algorithm with the Cryptographic
Cryptographic Message Syntax (CMS)," draft-ietf- Message Syntax (CMS)", RFC 5409, January 2009.
smime-bfibecms-10.txt, July 2008.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
Configuration Checklist Program for IT Products - Checklist Program for IT Products - Guidance for Checklist
Guidance for Checklist Users and Developers," NIST Users and Developers", NIST Special Publication SP 800-70,
Special Publication SP 800-70, May 2005. May 2005.
[P1363] IEEE P1363, "Standard Specifications for Public-Key [P1363] IEEE P1363, "Standard Specifications for Public-Key
Cryptography," 2001. Cryptography", 2001.
Authors' Addresses Authors' Addresses
Guido Appenzeller Guido Appenzeller
Stanford University Stanford University
Gates Building 3A Gates Building 3A
Stanford, CA 94305 Stanford, CA 94305
Phone: +1 650 732 2273 Phone: +1 650 732 2273
Email: appenz@cs.stanford.edu EMail: appenz@cs.stanford.edu
Luther Martin Luther Martin
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd, Suite 100
Palo Alto CA 94304 Palo Alto, CA 94304
USA USA
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com EMail: martin@voltage.com
Mark Schertler Mark Schertler
Tumbleweed Communications Axway
700 Saginaw Dr 1600 Seaport Blvd, Suite 400
Redwood City CA 94063 Redwood City, CA 94063
USA USA
Phone: +1 650 216 2039 Phone: +1 650 216 2039
Email: mark.schertler@tumbleweed.com EMail: mschertler@us.axway.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 (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.
 End of changes. 176 change blocks. 
861 lines changed or deleted 742 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/