draft-ietf-smime-ibearch-06.txt   draft-ietf-smime-ibearch-07.txt 
G. Appenzeller G. Appenzeller
L. Martin Stanford University
S/MIME Working Group Voltage Security S/MIME Working Group L. Martin
Internet Draft M. Schertler Internet Draft Voltage Security
Expires: May 2008 Tumbleweed Communications Intended status: Standards Track M. Schertler
November 2007 Expires: February 2009 Tumbleweed Communications
August 2008
Identity-based Encryption Architecture Identity-based Encryption Architecture and Supporting Data
Structures
<draft-ietf-smime-ibearch-06.txt> <draft-ietf-smime-ibearch-07.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which that any applicable patent or other IPR claims of which he
he or she is aware have been or will be disclosed, and or she is aware have been or will be disclosed, and any of
any of which he or she becomes aware will be disclosed, which he or she becomes aware will be disclosed, in
in accordance with Section 6 of BCP 79. accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute groups. Note that other groups may also distribute working
working documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum Internet-Drafts are draft documents valid for a maximum of
of six months and may be updated, replaced, or obsoleted six months and may be updated, replaced, or obsoleted by
by other documents at any time. It is inappropriate to other documents at any time. It is inappropriate to use
use Internet-Drafts as reference material or to cite them Internet-Drafts as reference material or to cite them other
other than as "work in progress." than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be The list of Internet-Draft Shadow Directories can be
accessed at accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
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
public key. also defines data structures that can be used to implement the
technology.
Table of Contents Table of Contents
1. Introduction.........................................3 1. Introduction.........................................4
1.1. Terminology.....................................3 1.1. Terminology.....................................4
2. Identity-based Encryption............................3 2. Identity-based Encryption............................4
2.1. Overview........................................3 2.1. Overview........................................4
2.2. Sending a Message that is IBE-encrypted.........4 2.2. Sending a Message that is IBE-encrypted.........6
2.2.1. Sender Obtains Public Parameters...........5 2.2.1. Sender Obtains Public Parameters...........6
2.2.2. Construct and Send IBE-encrypted Message...6 2.2.2. Construct and Send IBE-encrypted Message...7
2.3. Receiving and Viewing an IBE-encrypted Message..6 2.3. Receiving and Viewing an IBE-encrypted Message..8
2.3.1. Recipient Obtains Public Parameters........7 2.3.1. Recipient Obtains Public Parameters........9
2.3.2. Recipient Obtains IBE Private Key..........8 2.3.2. Recipient Obtains IBE Private Key..........9
2.3.3. Recipient Decrypts IBE-encrypted Message...8 2.3.3. Recipient Decrypts IBE-encrypted Message..10
3. Public Parameter Lookup..............................9 3. Identity Format.....................................10
3.1. Request Method.................................10 4. Public Parameter Lookup.............................11
3.2. Parameter and Policy Format....................10 4.1. Request Method.................................12
4. Private Key Request Protocol........................13 4.2. Parameter and Policy Format....................12
4.1. Overview.......................................13 4.3. The application/ibe-pp-data MIME type..........16
4.2. Private Key Request............................14 5. Private Key Request Protocol........................17
4.3. Request Structure..............................14 5.1. Overview.......................................17
4.4. Authentication.................................15 5.2. Private Key Request............................18
4.5. Server Response Format.........................16 5.3. Request Structure..............................18
4.6. Response Containing a Private Key..............16 5.4. The application/ibe-key-request+xml MIME type..20
4.7. Responses Containing a Redirect................18 5.5. Authentication.................................21
4.8. Responses Indicating an Error..................18 5.6. Server Response Format.........................22
5. ASN.1 Module........................................19 5.6.1. The IBE100 responseCode...................22
6. Security Considerations.............................21 5.6.2. The IBE101 responseCode...................24
6.1. Attacks that are outside the scope of this 5.6.3. The IBE201 responseCode...................24
document............................................21 5.6.4. The IBE300 responseCode...................25
6.2. Attacks that are within the scope of this 5.6.5. The IBE301 responseCode...................25
document............................................22 5.6.6. The IBE303 responseCode...................25
6.2.1. Attacks to which the protocols defined in 5.6.7. The IBE304 responseCode...................26
this document are susceptible....................22 5.7. The application/ibe-pkg-reply+xml MIME type....26
7. IANA Considerations.................................23 6. ASN.1 Module........................................27
8. References..........................................24 7. Security Considerations.............................29
8.1. Normative References...........................24 7.1. Attacks outside the scope of this document.....29
8.2. Informative References.........................25 7.2. Attacks within the scope of this document......30
Authors' Addresses.....................................26 7.2.1. Attacks on the protocols defined in this
Intellectual Property Statement........................26 document.........................................30
Disclaimer of Validity.................................27 8. IANA Considerations.................................31
Copyright Statement....................................27 8.1. Media types....................................31
Acknowledgment.........................................27 8.2. XML namespace..................................31
9. References..........................................33
9.1. Normative References...........................33
9.2. Informative References.........................34
Authors' Addresses.....................................35
Intellectual Property Statement........................35
Disclaimer of Validity.................................36
Copyright Statement....................................36
Acknowledgment.........................................36
1. Introduction 1. Introduction
This document describes the security architecture This document describes the security architecture required
required to implement identity-based encryption, a to implement identity-based encryption, a public-key
public-key encryption technology that uses a user's encryption technology that uses a user's identity as a
identity as a public key. Objects used in this public key. It also defines data structures that are
implementation are defined using ASN.1 [ASN1]. required to implement the technology. Objects used in this
implementation are defined using ASN.1 [ASN1] and 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"MAY", and "OPTIONAL" in this document are to be and "OPTIONAL" in this document are to be interpreted as
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 Identity-based encryption (IBE) is a public-key encryption
encryption technology that allows a public key to be technology that allows a public key to be calculated from
calculated from an identity and the corresponding private an identity and a set of public mathematical parameters and
key to be calculated from the public key. A public key for the corresponding private key to be calculated from an
can be calculated by anyone who has the necessary identity, a set of public mathematical parameters and a
mathematical parameters that are needed for the domain-wide secret value. An IBE public key can be
calculation; a cryptographic secret is needed to calculated by anyone who has the necessary public
calculate a private key, and the calculation can only be parameters; a cryptographic secret is needed to calculate
an IBE private key, and the calculation can only be
performed by a trusted server which has this secret. performed by a trusted server which has this secret.
Calculation of both the public and private keys in an Calculation of both the public and private keys in an IBE
IBE-based system can occur as needed, resulting in just- system can occur as needed, resulting in just-in-time
in-time key material. This contrasts with other public- creation of both public and private keys. This contrasts
key systems [P1363], in which keys are generated randomly with other public-key systems [P1363], in which keys are
and distributed prior to secure communication commencing. generated randomly and distributed prior to secure
The ability to calculate a recipient's public key, in communication commencing, and in which private encryption
particular, eliminates the need for the sender and keys need to be securely archived to allow for their
receiver in an IBE-based messaging system to interact recovery if they are lost or destroyed. The ability to
with each other, either directly or through a proxy such calculate a recipient's public key, in particular,
as a directory server, before sending secure messages. eliminates the need for the sender and receiver to interact
with each other, either directly or through a proxy such as
a directory server, before sending secure messages.
This document describes an IBE-based messaging system and A characteristic of IBE systems that differentiates them
how the components of the system work together. The from other server-based cryptographic systems is that once
components required for a complete IBE messaging system a set of public parameters is fetched, encryption is
possible with no further communication with a server during
the validity period of the public parameters. Other server-
based systems may require a connection to a server for each
encryption operation.
This document describes an IBE-based messaging system, how
the components of such a system work together, and defines
data structures that support the operation of such a
system. The server components required for such a system
are the following: are the following:
o A Private-key Generator (PKG). The PKG contains o A Public Parameter Server (PPS). IBE Public
the cryptographic material, known as a master parameters include publicly-sharable cryptographic
secret, which is used for generating an material, known as IBE public parameters, and
individual's IBE private key. A PKG accepts an policy information for an associated PKG. A PPS
IBE user's private key request, and after provides a well-known location for secure
successfully authenticating them in some way distribution of IBE public parameters and policy
returns, their IBE private key. information that describe the operation of a PKG.
Section 4 of this document describes the protocol
that a client uses to communicate with a PPS.
o A Public Parameter Server (PPS). IBE System o A Private-key Generator (PKG). The PKG stores and
Parameters include publicly-sharable uses cryptographic material, known as a master
cryptographic material, known as IBE public secret, which is used for generating a user's IBE
parameters, and policy information for an private key. A PKG accepts an IBE user's private
associated PKG. A PPS provides a well-known key request, and after successfully authenticating
location for secure distribution of IBE public them in some way, returns their IBE private key.
parameters and policy information for the IBE Section 5 of this document describes the protocol
PKG. that a client uses to communicate with a PKG.
A logical architecture would be to have a PKG/PPS per a A logical architecture of such an IBE system would be to
name space, such as a DNS zone. The organization that have a PKG and PPS per name space, such as a DNS zone. The
controls the DNS zone would also control the PKG/PPS and organization that controls the DNS zone would also control
thus the determination of which PKG/PSS to use when the PKG and PPS and thus the determination of which PKG or
creating public and private keys for the organization's PSS to use when creating public and private keys for the
members. In this case the PPS URI can be uniquely created organization's members. In this case the PPS URI/IRI can be
by the form of the identity that it supports. This uniquely created from a user-friendly name for the form of
architecture would make it clear which set of public identity that it supports. This architecture would make it
parameters to use and where to retrieve them for a given clear which set of public parameters to use and where to
identity (for example, an RFC 2822 address [TEXTMSG]). 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 Cryptographic Message Syntax [CMS]. How to such as the Cryptographic Message Syntax [CMS]. How to use
use IBE with CMS is defined in [IBECMS]. IBE with the CMS to encrypt e-mail messages is defined in
[IBECMS].
Note that IBE algorithms are used only for encryption, so Note that IBE algorithms are used only for encryption, so
if digital signatures are required they will need to be if digital signatures are required they will need to be
provided by an additional mechanism. provided by an additional mechanism.
Section 3 of this document describes the identity format
that all PPS and PKG servers MUST support.
2.2. Sending a Message that is IBE-encrypted 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 following steps: perform the following steps:
1. Obtain the recipient's public parameters 1. Obtain the recipient's public parameters
A user of an IBE system is capable of calculating The public parameters of the recipient's system are
the public key of a recipient after he obtains the needed to perform IBE operations. Once a user obtains
public parameters for their IBE system. Once the these public parameters, he can perform IBE
public parameters are obtained, IBE-encrypted encryption operations. These public parameters may be
messages can be sent. available at a PPS that is operated by the user's
organization, one that is operated by the sender's
organization, or by a different organization
entirely.
2. Construct and Send IBE-encrypted Message 2. Construct and Send IBE-encrypted Message
In addition to the IBE public parameters, all that In addition to the IBE public parameters, all that is
is needed to construct an IBE-encrypted message is needed to construct an IBE-encrypted message is the
the recipient's identity, which can be used to recipient's identity, the form of which is defined by
generate their public key. When this identity is the public parameters. When this identity is the same
the same as the identity that a message would be as the identity that a message would be addressed to,
addressed to, then no more information is needed then no more information is needed from a user to
from a user to send them a secure message then is send them an encrypted message then is needed to send
needed to send them an unsecured message. This is them an unencrypted message. This is one of the major
one of the major benefits of an IBE-based secure benefits of an IBE-based secure messaging system.
messaging system. Examples of identities can be an Examples of identities can be an individual, group,
individual, group, or role identifiers. 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 needs for calculating the IBE public key of the that he needs from a PPS that is hosted at a well-known URI
recipient from a PPS that is hosted at a well-known URI. or IRI. The IBE public parameters contain all of the
The IBE public parameters contain all of the information information that the sender needs to create an IBE-
that the sender needs to create an IBE-encrypted message encrypted message except for the identity of the recipient.
except for the identity of the recipient. Section 3 of Section 4 of this document describes the URI [URI] or IRI
this document describes the URI [URI] where a PPS is [IRI] of a PPS, the format of IBE public parameters, and
located, the format of IBE public parameters, and how to how to obtain them from a PPS. The URI or IRI from which
obtain them. The URI from which users obtain IBE public users obtain IBE public parameters MUST be authenticated in
parameters MUST be authenticated in some way; PPS servers some way. PPS servers MUST support TLS 1.1 [TLS] to satisfy
MUST support TLS 1.1 [TLS] to satisfy this requirement. this requirement. This step is shown below in Figure 1.
Section 3 also describes the way in which identity
formats are defined and a minimum interoperable format
that all PPSs and PKGs MUST support. This step is shown
below in Figure 1.
IBE Public Parameter Request 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 corresponding PKG based on his local security policy. The sender of an IBE-encrypted message selects the PPS and
Different PPSs may provide public parameters that specify corresponding PKG based on his local security policy.
different IBE algorithms or different key strengths, for Different PPS servers may provide public parameters that
example, or require the use of PKGs that require specify different IBE algorithms or different key
different levels of authentication before granting IBE strengths, for example, or require the use of PKG servers
private keys. that require different levels of authentication before
granting IBE private keys.
2.2.2. Construct and Send IBE-encrypted Message 2.2.2. Construct and Send 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 (CEK) and uses it to encrypt his message encryption key (CEK) and uses it to encrypt his message and
and then encrypts the CEK with the recipient's IBE public then encrypts the CEK with the recipient's IBE public key
key as described in [CMS]. This operation is shown below as described in [CMS]. This operation is shown below in
in Figure 2. [IBCS] describes the algorithms needed to Figure 2. The document [IBCS] describes the algorithms
implement two forms of IBE and [IBECMS] describes how to needed to implement two forms of IBE and [IBECMS] describes
use the Cryptographic Message Syntax (CMS) to encapsulate how to use the Cryptographic Message Syntax (CMS) to
the encrypted message along with the IBE information that encapsulate the encrypted message along with the IBE
the recipient needs to decrypt the 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
skipping to change at page 6, line 34 skipping to change at page 8, line 4
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 2.3. Receiving and Viewing an IBE-encrypted Message
In order to read an encrypted message, a recipient of an In order to read an IBE-encrypted message, a recipient of
IBE-encrypted message parses the message as described in such a message parses the message to find the URI or IRI he
[IBECMS]. This gives him the URI he needs to obtain the needs to obtain the IBE public parameters that are required
IBE public parameters that are required to perform IBE to perform IBE calculations as well as a component of the
calculations as well as a component of the identity that identity that was used to encrypt the message. Next the
was used to encrypt the message. Next the recipient must recipient carries out the following steps:
carry out the following steps:
1. Obtain the recipient's 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 public and private keys. The uniquely create public and private keys. The
recipient of an IBE-encrypted message can decrypt recipient of an IBE-encrypted message can decrypt an
an IBE-encrypted message if he has both the IBE IBE-encrypted message if he has both the IBE public
public parameters and the necessary IBE private parameters and the necessary IBE private key. The
key. The PPS can also provide the URI of the PKG public parameters also provide the URI or IRI of the
where the recipient of an IBE-encrypted message can PKG where the recipient of an IBE-encrypted message
obtain the IBE 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 public parameters the recipient needs to the IBE public parameters, the recipient needs to
obtain the private key that corresponds to the obtain the private key that corresponds to the public
public key that the sender used. The IBE private key that the sender used. The IBE private key is
key is obtained after successfully authenticating obtained after successfully authenticating to a
to a private key generator (PKG), a trusted third private key generator (PKG), a trusted third party
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 then receives the IBE private key over a secure
secure connection. connection.
3. Decrypt IBE-encrypted message 3. Decrypt IBE-encrypted message
The IBE private key decrypts the CEK (see section The IBE private key decrypts the CEK (see Section
2.2.2). The CEK is then used to decrypt encrypted 2.2.2). The CEK is then used to decrypt encrypted
message. message.
The PKG may allow users other than the intended recipient It may be useful for a PKG to allow users other than the
to receive some IBE private keys. Giving a mail filtering intended recipient to receive some IBE private keys. Giving
appliance permission to obtain IBE private keys on behalf a mail filtering appliance permission to obtain IBE private
of users, for example, can allow the appliance to decrypt keys on behalf of users, for example, can allow the
and scan encrypted messages for viruses or other appliance to decrypt and scan encrypted messages for
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 that he has received, the recipient of an IBE- message that he has received, the recipient of an IBE-
encrypted message needs to obtain the IBE public encrypted message needs to obtain the IBE public parameters
parameters that were used in the encryption operation. that were used in the encryption operation. This 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 public parameters is vital to the overall security of an
overall security of an IBE system, IBE public parameters IBE system, IBE public parameters MUST be transported to
MUST be transported to recipients over a secure protocol. recipients over a secure protocol. PPS servers MUST support
PPSs MUST support TLS 1.1 [TLS] or its successors, using TLS 1.1 [TLS] or its successors, using the latest version
the latest version supported by both parties, for supported by both parties, for transport of IBE public
transport of IBE public parameters. In addition, users parameters. In addition, users MUST verify that the subject
MUST verify that the subject name in the server name in the server certificate matches the URI/IRI of the
certificate matches the URI of the PPS. The comments in PPS. The comments in Section 2.2.1 also apply to this
Section 2.2.1 also apply to this operation. 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 message provides the IBE public key used to encrypted message provides the IBE public key used to
encrypt the message and their authentication credentials encrypt the message and their authentication credentials to
to a PKG and requests the private key that corresponds to a PKG and requests the private key that corresponds to the
the IBE public key. Section 4 of this document defines IBE public key. Section 5 of this document defines the
the protocol for communicating with a PKG as well as a protocol for communicating with a PKG as well as a minimum
minimum interoperable way to authenticate to a PKG that interoperable way to authenticate to a PKG that all IBE
all IBE implementations MUST support. Because the implementations MUST support. Because the security of IBE
security of IBE private keys is vital to the overall private keys is vital to the overall security of an IBE
security of an IBE system, IBE private keys MUST be system, IBE private keys MUST be transported to recipients
transported to recipients over a secure protocol. PKGs over a secure protocol. PKG servers MUST support TLS 1.1
MUST support TLS 1.1 [TLS] or its successors, using the [TLS] or its successors, using the latest version supported
latest version supported by both parties, for transport by both parties, for transport of IBE private keys. This
of IBE private keys. This operation is shown below in operation is shown below in Figure 4.
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 that IBE private key and the corresponding recipient uses that IBE private key and the corresponding
IBE public parameters to decrypt the CEK. This operation IBE public parameters to decrypt the CEK. This operation is
is shown below in Figure 5. He then uses the CEK to shown below in Figure 5. He then uses the CEK to decrypt
decrypt the encrypted message content as specified in the encrypted message content. An example of how to do this
[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. Public Parameter Lookup 3. Identity Format
For an identity-based encryption (IBE) system to operate, An IBEIdentityInfo type MUST be used to represent the
the sender, receiver and the private key generator (PKG) identity of a recipient. This is defined to be the
must agree on a number of parameters, specifically: following:
1. The Public Parameters of the PKG. The public IBEIdentityInfo ::= SEQUENCE {
parameters are part of the encryption (and in some district IA5String,
cases decryption) operation of the IBE system. serial INTEGER,
Generation of public parameters and the master identityType OBJECT IDENTIFIER,
secret, as well as the mathematical structure of the identityData OCTET STRING
public parameters for the BF and BB1 algorithms are }
described in [IBCS].
2. The URI of the PKG. Knowledge of this URI allows An IBEIdentityInfo type is used to calculate public and
recipients to request a private key as described in private IBE keys. Because of this, such a structure is
Section 4 of this document. typically DER-encoded [DER].
3. The schema to format the identity strings. When The fields of an IBEIdentityInfo structure have the
issuing a private key, the PKG often wants to limit following meanings.
who can obtain private keys. For example for an
identity string that contains "bob@example.com,"
only the owner of the identity string should be able
to request the private key. To ensure that the PKG
can interpret the identity string for which a
private key is requested, the encryption engine and
the PKG have to use the same schema for identity
strings. Identity schemas are described in [IBECMS]
This section specifies how a component of an IBE system The district is an IA5String that represents the URI [URI]
can retrieve these parameters. A sending or receiving or IRI [IRI] where the recipient of an IBE-encrypted
client MUST allow configuration of these parameters message can retrieve the IBE public parameters needed to
manually, e.g. through editing a configuration file. encrypt or decrypt a message encrypted for this identity.
However for simplified configuration a client MAY also Applications MUST support the method described in Section 4
implement the PP URI request method described in this for doing this and MAY support other methods. IRIs MUST be
document to fetch the system parameters based on a handled according to the procedures specified in Section
configured URI. This is especially useful for federating 7.4 of [PKIX].
between IBE systems. By specifying a single URI a client
can be configured to fetch all the relevant parameters
for a remote PKG. These public parameters can then be
used to encrypt messages to recipients who authenticate
to and retrieve private keys from that PKG.
The following section outlines the URI request method to The serial is an INTEGER that defines a unique set of IBE
retrieve a parameter block and describes the structure of public parameters in the event that more than one set of
the parameter block itself. parameters is used by a single district.
3.1. Request Method identityType is an OBJECT IDENTIFIER that defines the
format that the identityData field is encoded with.
The configuration URI SHOULD be an HTTPS URI [HTTP] of An example of a useful IBEIdentityInfo type is given in
the format: [IBECMS]. This example is tailored to the use of IBE in
encrypting e-mail. Because the information that comprises
an identity is very dependent on the application, this
document does not define an identityType that all
applications MUST support.
http_URI = "https:" "//" host [ ":" port ] [ abs_path ] 4. Public Parameter Lookup
An example URI for ibe system parameters is This section specifies how a component of an IBE system can
retrieve these parameters. A sending or receiving client
MUST allow configuration of these parameters manually, for
example, through editing a configuration file. However for
simplified configuration a client SHOULD also implement the
public parameter URI/IRI request method described in this
document to fetch the public parameters based on a
configured URI/IRI. This is especially useful for
federating between IBE systems. By specifying a single
URI/IRI, a client can be configured to fetch all the
relevant parameters for a remote PKG. These public
parameters can then be used to encrypt messages to
recipients who authenticate to and retrieve private keys
from that PKG.
https://ibe-0000.example.com/example.com.pp The following section outlines the URI/IRI request method
to retrieve a parameter block and describes the structure
of the parameter block itself. The technique for fetching
IBE public parameters using the process defined in this
section is indicated by the OBJECT IDENTIFIER uriPPSOID,
which is defined to be the following:
To retrieve the IBE system parameters, the client SHOULD uriPPSOID OBJECT IDENTIFIER ::= {
use the HTTP GET method as defined in [HTTP]. The request joint-iso-itu-t(2) country(16) us(840)
MUST happen over a secure protocol. The requesting client organization(1) identicrypt(114334)
MUST support TLS 1.1 [TLS] or its successors and SHOULD pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
use the latest version supported by both parties. When }
requesting the URI the client MUST only accept the system
4.1. Request Method
The configuration URI/IRI SHOULD be an HTTPS URI [HTTP] and
MAY additionally support IRIs [IRI] for this purpose. To
retrieve the IBE public parameters, the client SHOULD use
the HTTP GET method as defined in [HTTP]. The request MUST
happen over a secure protocol. The requesting client MUST
support TLS 1.1 [TLS] or its successors and SHOULD use the
latest version supported by both parties. When requesting
the URI/IRI the client MUST only accept the system
parameter block if the server identity was verified parameter block if the server identity was verified
successfully by TLS 1.1 [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
encoding of the DER-encoded [DER] IBESysParams structure [B64] encoding of the DER-encoded [DER] IBESysParams
that is described in the next section. This structure structure that is described in the next section. This
MUST be served as an application/octet-stream MIME type structure MUST be encoded as an application/ibe-pp-data
[MIME]. MIME type.
3.2. Parameter and Policy Format 4.2. Parameter and Policy Format
The IBE Public parameters are a structure of the form
The IBE System 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,
ibeIdentitySchema OBJECT IDENTIFIER, ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL ibeParamExtensions IBEParamExtensions OPTIONAL
} }
The version specifies the version of the IBESysParams The fields of an IBESysParams structure have the following
format. For the format described in this document it MUST meanings.
be set to 2. The district name is an IA5String that MUST
be a valid domain name as defined by [DOM]. The
districtSerial is a serial number that represents a
unique set of IBE public parameters. If new parameters
are published for a district, it MUST be increased to a
number greater than the previously-used serial number.
The validity period or lifetime of a specific instance of The version field specifies the version of the IBESysParams
the IBESysParams is defined as follows: format. For the format described in this document, this
MUST be set to 2.
The districtName field is an IA5String that MUST be an
encoding of an URI [URI] or IRI [IRI]. IRIs MUST be handled
according to the procedures specified in Section 7.4 of
[PKIX].
The districtSerial field is an integer that represents a
unique set of IBE public parameters that are available at
the URI or IRI defined by the districtName. If new
parameters are published for a districtName, the
districtSerial MUST be increased to a number greater than
the previously-used districtSerial.
The validity field defines lifetime of a specific instance
of the IBESysParams and is defined to be the following:
ValidityPeriod ::= SEQUENCE { ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime notAfter GeneralizedTime
} }
A client MUST verify that the date on which it utilizes A client MUST verify that the date on which it uses the IBE
the IBE system parameters falls between the notBefore public parameters falls between the notBefore time and the
time and the notAfter time of the IBE system parameters notAfter time of the IBE public parameters and MUST NOT use
and SHOULD not use the parameters if they do not. the parameters for IBE encryption operations if they do
not.
IBE system parameters MUST be regenerated and republished IBE public parameters MUST be regenerated and republished
whenever the ibePublicParameters, ibeIdentitySchema, or whenever the values of ibePublicParameters,
ibeParamExtensions change for a district. A client SHOULD ibeIdentityType, or ibeParamExtensions change for a
refetch the IBE system parameters at an application- district. A client SHOULD refetch the IBE public parameters
configurable interval to ensure that it has the most at an application-configurable interval to ensure that it
current version on the IBE system parameters. has the most current version on the IBE public 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 component, as described in [IBECMS]. If such have a time component, as described in [IBECMS], for
an identity is used, the time component of the identity example. If such an identity is used, the time component of
MUST fall between the notBefore time and the notAfter the identity MUST fall between the notBefore time and the
times of the IBE system parameters. notAfter times of the IBE public parameters.
IBEPublicParameters is a structure containing public IBEPublicParameters is a structure containing public
parameters that correspond to IBE algorithms that the PKG parameters that correspond to IBE algorithms that the PKG
associated with this district understands. supports. This structure is defined to be following:
IBEPublicParameters ::= SEQUENCE (1..MAX) OF 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 OID specifies an IBE algorithm. The The ibeAlgorithm OBJECT IDENTIFIER specifies an IBE
publicParameterData is a DER-encoded [DER] structure that algorithm. The OIDs for two IBE algorithms, the Boneh-
contains the actual cryptographic parameters. Its Franklin and Boneh-Boyen algorithms and their
specific structure depends on the algorithm. The OIDs for publicParameterData structures are defined in [IBCS].
two IBE algorithms, the Boneh-Franklin and Boneh-Boyen
algorithms and their publicParameterData structures are
defined in [IBCS].
The IBESysParams of a district MUST contain at least one The publicParameterData is a DER-encoded [DER] structure
algorithm and MAY contain several algorithms. It MUST NOT that contains the actual cryptographic parameters. Its
contain two or more IBEPublicParameter entries with the specific structure depends on the algorithm.
same algorithm. A client that wants to use IBESysParams
can chose any of the algorithms specified in the
publicParameterData structure. A client MUST implement at
least the Boneh-Franklin algorithm and MAY implement the
Boneh-Boyen and other algorithms. If a client does not
support any of the supported algorithms it MUST generate
an error message and fail.
ibeIdentitySchema is an OID that defines the type of The IBESysParams of a district MUST contain an OID that
identifies at least one algorithm and MAY contain OIDs that
identify more than one algorithm. It MUST NOT contain two
or more IBEPublicParameter entries with the same algorithm.
A client that wants to use IBESysParams can chose any of
the algorithms specified in the publicParameterData
structure. A client MUST implement at least the Boneh-
Franklin algorithm [IBCS] and MAY implement the Boneh-Boyen
[IBCS] and other algorithms. If a client does not support
any of the supported algorithms it MUST generate an error
message and fail.
ibeIdentityType is an OID that defines the type of
identities that are used with this district. The OIDs and identities that are used with this district. The OIDs and
the required and optional fields for each OID are the required and optional fields for each OID are
described in [IBECMS]. application dependent. An example of this is given in
[IBECMS], which defines an identity format suitable for use
in encrypting e-mail.
IBEParamExtensions is a set of extensions that can be IBEParamExtensions is a set of extensions that can be used
used to define additional parameters that particular to define additional parameters that particular
implementations may require. implementations may require. This structure is defined as
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 are defined by the The contents of the octet string ibeParamExtensionValue are
specific extension type. The System Parameters of a defined by the specific ibeParamExtensionOID. The
district MAY have any number of extensions, including IBEParamExtensions of a district MAY have any number of
zero. extensions, including zero. One example of extensions that
have been used in practice is to provide a URI where an
encrypted message can be decrypted and viewed by users of
webmail systems. Another example is to provide commercial
branding information, so that a bank can provide a
different user interface for customers of different lines
of business.
The IBEParamExtension pkgURI defines the URI of the If a client receives Public parameters that contain an
Private Key Generator of the district. If the PKG is extension that it is unable to process, it MUST NOT use the
publicly accessible, this extension SHOULD be present to values in the IBESysParams structure for any cryptographic
allow the automatic retrieval of private keys for operations. Clients MUST be able to process an IBESysParams
recipients of encrypted messages. For this extension the structure that contains no IBEParamExtensions.
OCTET STRING is an IA5String containing the URI of the
key server. The pkgURI OBJECT IDENTIFIER that is defined below defines
an IBEParamExtensions structure that contains the URI or
IRI of a Private Key Generator. The presence of this OBJECT
IDENTIFIER in an IBEParamExtension indicates that clients
MUST use the protocol defined in Section 5 of this document
to obtain IBE private keys from the PKG and do so using the
URI/IRI that is defined by the value defined by the
ibeParamExtensionValue in the IBEParamExtension.
If the PKG is publicly-accessible, this extension SHOULD be
present to allow the automatic retrieval of private keys
for recipients of encrypted messages. For this extension
the ibeParamExtensionValue OCTET STRING is an IA5String
containing the URI [URI] or IRI [IRI] of the PKG where IBE
private keys can be obtained. IRIs MUST be handled
according to the procedures specified in Section 7.4 of
[PKIX].
ibeParamExt OBJECT IDENTIFIER ::= { 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. Private Key Request Protocol 4.3. The application/ibe-pp-data MIME type
4.1. Overview The following summarizes the properties of the
application/ibe-pp-data MIME type.
In an identity-based encryption (IBE) system messages are MIME media type name: application
encrypted using a public key that is locally calculated
from public parameters and a user`s identity and MIME subtype name: ibe-pp-data
decrypted using a private key that corresponds to the
user`s public key. These private keys are generated by a Mandatory parameters: The single required parameter is a
private key generator (PKG) based on a global secret base64-encoded DER-encoded IBESysParams structure.
called a master secret.
Optional parameters: There are no optional parameters.
Encoding considerations: This media type MUST be encoded as
7bit (us-ascii text [ASCII]).
Security considerations: The data conveyed as this media
type are the public parameters needed for the operation of
a cryptographic system. To ensure that the parameters can
be trusted, the request for these parameters must take
place over a secure protocol, TLS 1.1 or its successors. To
ensure the validity of the server, the client MUST verify
the server certificate and MUST abort the parameter request
if the verification of the server certificate of the TLS
connection fails. This media type contains no active
content and does not use compression.
Interoperability considerations: There are no known
interoperability considerations for this media type.
Applications that use this media type: Applications that
implement IBE in compliance with this specification will
use this media type. The most commonly-used of these
applications are encrypted email and file encryption.
Additional information: This media type is used for the
response from a public parameter server after receiving a
request for IBE public parameters. This media type contains
no active content and does not use compression.
Person and email address for further information: Luther
Martin, martin@voltage.com.
Intended usage: COMMON.
Author/Change controller: Luther Martin,
martin@voltage.com.
5. Private Key Request Protocol
5.1. Overview
When requesting a private key, a client has to transmit When requesting a private key, a client has to transmit
two parameters: three parameters:
1. The identity for which it is requesting a key 1. The IBE algorithm for which the key is being
requested
2. Authentication credentials for the individual 2. The identity for which it is requesting a key
3. Authentication credentials for the individual
requesting the key requesting the key
These two are often not the same as a single user may
have access to multiple aliases. For example an email These two are often not the same as a single user may have
user may have access to the keys that correspond to two access to multiple aliases. For example an email user may
different email addresses, e.g. bob@example.com and have access to the keys that correspond to two different
email addresses, e.g. bob@example.com and
bob.smith@example.com. bob.smith@example.com.
This section defines the protocol to request private This section defines the protocol to request private keys,
keys, a minimum user authentication method for a minimum user authentication method for interoperability,
interoperability, and how to pass authentication and how to pass authentication credentials to the server.
credentials to the server. It assumes that a client has It assumes that a client has already determined the URI/IRI
already determined the URI of the PKG. This can be done of the PKG. This can be done from information included in
from hints included in the IBE message format [IBECMS] the IBE message format and the public parameters of the IBE
and the system parameters of the IBE system. system.
4.2. Private Key Request The technique for fetching an IBE private key using the
process defined in this section is indicated by the OBJECT
IDENTIFIER pkgURI, which is defined to be the following:
To request a private key, a client performs a HTTP POST ibcs OBJECT IDENTIFIER ::= {
method as defined in [HTTP]. The request MUST happen over joint-iso-itu-t(2) country(16) us(840)
a secure protocol. The requesting client MUST support TLS organization(1) identicrypt(114334) ibcs(1)
1.1 [TLS] or its successors, using the latest version }
ibeParamExt OBJECT IDENTIFIER ::= {
ibcs ibcs3(3) parameter-extensions(2)
}
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
5.2. Private Key Request
To request a private key, a client MUST perform a HTTP POST
method as defined in [HTTP]. The request MUST take place
over a secure protocol. The requesting client MUST support
TLS 1.1 [TLS] or its successors, using the latest version
supported by both the client and the PKG. When requesting supported by both the client and the PKG. When requesting
the URI the client MUST verify the server certificate the URI/IRI the client MUST verify the server certificate
[HTTPTLS], and MUST abort the key request if the server [HTTPTLS], and MUST abort the key request if 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 so is critical to protect the authentication credentials
credentials and the private key against man-in-the-middle and the private key against man-in-the-middle attacks when
attacks when it is transmitted from the key server to the it is transmitted from the key server to the client.
client.
4.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 MUST be encoded as an structure that MUST be encoded as an application/ibe-key-
application/xhtml+xml MIME type [XHTML]: 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>
<oid> algorithmOID </oid> algorithmOID
</ibe:algorithm> </ibe:algorithm>
<ibe:id> <ibe:id>
ibeIdentityInfo ibeIdentityInfo
</ibe:id> </ibe:id>
</ibe:keyRequest> </ibe:keyRequest>
<ibe:authData>
ibeAuthData
</ibe:authData>
</ibe:body> </ibe:body>
</ibe:request> </ibe:request>
A <ibe:request> SHOULD include a <ibe:clientID> element, A <ibe:request> SHOULD include an <ibe:client> element in
an ASCII string that identifies the client type and the <ibe:header> part of a key request that contains an
client version. ASCII string that identifies the client type and client
version.
A key request MUST contain a valid ibeIdentityInfo that A key request MUST contain an <ibe:oid> element that
the private key is requested for. This identity is the contains the base64 [B64] encoding of a DER-encoded [DER]
base64 encoding of the DER encoding [DER] of the object identifier that identifies the algorithm for which a
structure IBEIdentityInfo, an example of which is defined key is requested. OIDs for the BB1 and BF algorithms are
in [IBECMS]. listed in [IBCS].
A key request MUST contain a <ibe:algorithmOID> element A key request MUST contain an <ibe:id> element that
that contains a DER-encoded [DER] OBJECT IDENTIFIER that contains the identity that the private key is being
identifies the algorithm for which a key is requested. requested for. This identity is the base64 [B64] encoding
OIDs for the BB1 and BF algorithms are listed in [IBCS]. of a DER-encoded [DER] ASN.1 structure. This structure
defines a user's identity in a way appropriate for the
application. An example of such a structure that is
appropriate for use in encrypting e-mail is defined in
[IBECMS].
A key request MAY contain an <ibe:authData> element. This
element contains authentication information that the PKG
can use to determine whether or not a request for a
particular IBE private key should be granted.
A client MAY include optional additional XML elements in A client MAY include optional additional XML elements in
the <ibe:body> part of the key request. the <ibe:body> part of the key request. A PKG MUST be able
to process key requests that contain no such optional
elements.
4.4. Authentication 5.4. The application/ibe-key-request+xml MIME type
When a client requests a key from a PKG, the PKG SHOULD The following summarizes the properties of the application/
ibe-key-request+xml MIME type.
MIME media type name: application
MIME subtype name: ibe-key-request+xml
Mandatory parameters: The required parameters are the
identity for which an IBE private key is being requested
and an object identifier that identifies which
cryptographic algorithm the key is being requested for. The
identity is the base64-encoding of a DER-encoded
ibeIdentityInfo structure. The object identifier is the
base64-encoding of a DER-encoded object identifier, like
those defined in [IBCS].
Optional parameters: Any optional parameters may be defined
by an administrator of a particular PKG. The most common
optional parameter is an authentication credential. A PKG
may redirect a request for an IBE private key to an
external authentication mechanism, the reply from which is
then included as this optional parameter in a subsequent
key request. Other optional parameters may include other
information as required by particular implementations. An
example of this from an existing implementation is a bank
that has clients pass branding information along with a key
request so that mortgage customers see a different user
interface than non-mortgage customers do, for example.
Encoding considerations: This media type MUST be encoded as
us-ascii [ASCII].
Security considerations: The data conveyed in this media
type may contain authentication credentials. Because of
this, its confidentiality and integrity is extremely
important. To ensure this, the request for an IBE private
key must take place over a secure protocol, TLS 1.1 or its
successors. To ensure the validity of the server, the
client MUST verify the server certificate and MUST abort
the key request if the verification of the server
certificate of the TLS connection fails. This media type
contains no active content and does not use compression.
Interoperability considerations: There are no known
interoperability considerations for this media type.
Applications that use this media type: Applications that
implement IBE in compliance with this specification will
use this media type. The most commonly-used of these
applications are encrypted email and file encryption.
Additional information: This media type is used for the
data that is passed to an IBE PKG by a client requesting an
IBE private key. This media type contains no active content
and does not use compression.
Person and email address for further information: Luther
Martin, martin@voltage.com.
Intended usage: COMMON.
Author/Change controller: Luther Martin,
martin@voltage.com.
5.5. Authentication
When a client requests a key from a PKG, the PKG MUST
authenticate the client before issuing the key. authenticate the client before issuing the key.
Authentication may either be done through the key request Authentication may either be done through the key request
structure or as part of the secure transport protocol. structure or as part of the secure transport protocol.
A client or server implementing the request protocol MUST A client or server implementing the request protocol MUST
support HTTP Basic Auth as described in [AUTH]. A client support HTTP Basic Auth [AUTH] and SHOULD also support HTTP
and server SHOULD also support HTTP Digest Auth as Digest Auth [AUTH]. Applications MAY also use other means
defined in [AUTH]. of authentication that are appropriate for the application.
An e-mail application, for example, might rely on deployed
e-mail infrastructure for this, for example.
For authentication methods that are not done by the For authentication methods that are not done by the
transport protocol, a client MAY include additional transport protocol, a client MAY include additional
authentication information in xml elements in the body authentication information in XML elements in the
part of the key request. If a client does not know how to <ibe:authData> element of a key request. If a client does
authenticate to a server, the client MAY send a key not know how to authenticate to a server, the client MAY
request without authentication information. If the key send a key request without authentication information. If
server requires the client to authenticate externally, it the key server requires the client to authenticate
MAY reply with a 201 response code as defined below to externally, it MAY reply with an IBE201 responseCode as
redirect the client to the correct authentication defined below to redirect the client to the correct
mechanism. authentication mechanism. After receiving an authentication
credential from this external mechanism, a client can then
use the credential to form a key request that contains the
additional authentication data.
4.5. 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 the response contains a client error or response. If the response contains a client error or server
server error status code, the client MUST abort the key error status code, the client MUST abort the key request
request and fail. and fail.
If the PKG replies with a HTTP response that has a status If the PKG replies with an HTTP response that has a status
code indicating success, the body of the reply MUST code indicating success, the body of the reply MUST contain
contain the following XML structure that MUST be encoded the following XML structure that MUST be encoded as an
as an application/xhtml+xml MIME type [XHTML]: 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 describes the type of response from the The responseCode attribute contains an ASCII string that
key server. The list of currently defined response codes describes the type of response from the key server. The
is: list of currently-defined responseCodes and their
associated meanings is:
100 KEY_FOLLOWS IBE100 KEY_FOLLOWS
101 RESERVED IBE101 RESERVED
201 FOLLOW_ENROLL_URI IBE201 FOLLOW_ENROLL_URI
300 SYSTEM_ERROR IBE300 SYSTEM_ERROR
301 INVALID_REQUEST IBE301 INVALID_REQUEST
303 CLIENT_OBSOLETE IBE303 CLIENT_OBSOLETE
304 AUTHORIZATION DENIED IBE304 AUTHORIZATION DENIED
4.6. Response Containing a Private Key 5.6.1. The IBE100 responseCode
If the key request was successful, the key server If the key request was successful, the key server responds
responds with KEY FOLLOWS, and the <ibe:body> must with a responseCode of IBE100, and the <ibe:body> MUST
contain a <ibe:privateKey> tag with a valid private key. contain a <ibe:privateKey> element that contains a valid
An example of this is shown below. private key. An 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="100"/> <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] of the following structure: encoding [DER] 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,
critical BOOLEAN DEFAULT FALSE,
optionValue OCTET STRING optionValue OCTET STRING
} }
The pkgIdentity is an IBEIdentityInfo structure as The pkgIdentity is an IBEIdentityInfo structure that MUST
defined in [IBECMS]. It MUST be identical to the be identical to the IBEIdentityInfo structure that was sent
IBEIdentityInfo structure that was sent in the key in the key request.
request.
The pkgAlgorithm is an OID that identifies the algorithm The pkgAlgorithm is an OID that identifies the algorithm of
of the returned private key. The OIDs for the BB and BF the returned private key. The OIDs for the BB and BF
algorithms are defined in [IBCS]. algorithms are 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 formats for the BB and BF private key. Private-key formats for the BB and BF
algorithms are defined in [IBCS]. algorithms are defined in [IBCS].
A server MAY pass back additional information to a client A server MAY pass back additional information to a client
in the pkgOptions structure. in the pkgOptions structure. A client that receives a
IBEPrivateKeyReply from a PKG that contains information in
a pkgOptions structure that it is unable process MUST NOT
use the IBE private key in the IBEPrivateKeyReply structure
for any cryptographic operations. A client MUST be able to
process an IBEPrivateKeyReply that contains no PKGOptions
structure.
4.7. Responses Containing a Redirect 5.6.2. The IBE101 responseCode
A Key Server MAY support authenticating user to external The responseCode IBE101 is reserved to ensure
authentication mechanism. If this is the case, the server interoperability with earlier versions of the protocol that
replies to the client with response code 201 and the body is described in this document. An example of such a
MUST contain a <ibe:location> element that specifies the response is shown below. A response with the IBE101
URI of the authentication mechanism. Such a response MUST responseCode SHOULD contain no body. If information is
be encoded as an application/xhtml+xml MIME type [XHTML]. contained in the body of such a response, the client
An example of such a response is shown below. 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="201"/> <ibe:responseType value="IBE101"/>
<ibe:body>
This message must be discarded by the recipient
</ibe:body
</ibe:response>
5.6.3. The IBE201 responseCode
A PKG MAY support authenticating users to external
authentication mechanisms. If this is the case, the server
replies to the client with responseCode IBE201 and the body
of the response MUST contain a <ibe:location> element that
specifies the URI of the authentication mechanism. An
example of such a response is shown below.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="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 authentication mechanism The client can now contact the URI returned in such a
to obtain authentication credentials. Once the client has response using the same mechanisms as defined in Section
obtained the credential, it sends a new key request to 4.2 to obtain an authentication credential. Once the client
the PKG with the correct authentication credentials has obtained the credential from the authentication
contained in the request. mechanism at this URI, it sends a new key request to the
PKG with the correct authentication credentials contained
in the request, placing the authentication credential in
the <ibe:authData> element of a key request as described in
Section 4.4.
4.8. Responses Indicating an Error 5.6.4. The IBE300 responseCode
If the server replies with an error code from 300 through The IBE300 responseCode indicates that an internal server
399, the client MUST abort the request and discard any error has occurred. Information that may help diagnose the
data that is part of the response. error MAY be included in the body of such a response. An
example of such a response is shown below. Upon receiving a
IBE300 responseCode, the client MUST abort the key request
and discard any data that was included in the body of the
response.
The meaning of the response codes for errors is as <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
follows: <ibe:responseType value="IBE300"/>
<ibe:body>
Widget phlebotomy failure
</ibe:body>
</ibe:response>
300 - This indicates an internal server error of the PKG. 5.6.5. The IBE301 responseCode
301 - The request to the server is invalid or the server The IBE303 responseCode indicates that an invalid key
is not able to fulfill this type of request. request has been received by the server. Information that
may help diagnose the error MAY be included in the body of
such a response. An example of such a response is shown
below. Upon receiving an IBE301 responseCode, the client
MUST abort the key request and discard any data that was
included in the body of the response.
303 - The server is not able to serve key requests for <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
this type of client. A client with a newer version of the <ibe:responseType value="IBE301"/>
protocol is required. <ibe:body>
Some additional stuff
</ibe:body>
</ibe:response>
304 - The key request was processed correctly, but the 5.6.6. The IBE303 responseCode
authentication credentials provided by the user were
invalid, could not be verified, or do not allow access to
keys for this identity.
5. ASN.1 Module The IBE303 responseCode indicates that the server is unable
to correctly process the request because the version of the
request is no longer supported by the server. Information
that may help diagnose the error MAY be included in the
body of such a response. An example of such a response is
shown below. Upon receiving an IBE303 responseCode, the
client MUST abort the key request and discard any data that
was included in the body of the response.
The following ASN.1 module summarizes the ASN.1 <ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
definitions discussed in this document. <ibe:responseType value="IBE303"/>
<ibe:body>
Version 3.3 or later needed
</ibe:body>
</ibe:response>
5.6.7. The IBE304 responseCode
The IBE304 responseCode indicates that a valid key request
has been received by the server but the authentication
credentials provided were invalid. Information that may
help diagnose the error MAY be included in the body of such
a response. An example of such a response is shown below.
Upon receiving an IBE304 responseCode, the client MUST
abort the key request and discard any data that was
included in the body of the response.
<ibe:response xmlns:ibe="urn:ietf:params:xml:ns:ibe">
<ibe:responseType value="IBE304"/>
<ibe:body>
Helpful error message
</ibe:body>
</ibe:response>
5.7. The application/ibe-pkg-reply+xml MIME type
The following summarizes the properties of the
application/ibe-pkg-reply+xml MIME type.
MIME media type name: application
MIME subtype name: ibe-pkg-reply+xml
Mandatory parameters: The only required parameter is a
response code which indicates the status of a key request.
Other parameters may be also required, depending on the
nature of the response from the PKG. For example, for the
responseCode IBE100 ("key follows"), an IBE private key is
also a required parameter.
Optional parameters: None.
Encoding considerations: This media type MUST be encoded as
us-ascii [ASCII].
Security considerations: The data conveyed as this media
type is an IBE private key, so its confidentiality and
integrity is extremely important. To ensure this, the
response from the server that contains an IBE private key
must take place over a secure protocol, TLS 1.1 or its
successors. To ensure the validity of the server, the
client MUST verify the server certificate and MUST abort
the key request if the verification of the server
certificate of the TLS connection fails. This media type
contains no active content and does not use compression.
Interoperability considerations: There are no known
interoperability considerations for this media type.
Applications that use this media type: Applications that
implement IBE in compliance with this specification will
use this media type. The most commonly-used of these
applications are encrypted email and file encryption.
Additional information: This media type is used for the
response from a PKG after receiving a request for an IBE
private key. This media type contains no active content and
does not use compression.
Person and email address for further information: Luther
Martin, martin@voltage.com.
Intended usage: COMMON.
Author/Change controller: Luther Martin,
martin@voltage.com.
6. ASN.1 Module
The following ASN.1 module summarizes the ASN.1 definitions
discussed in this document.
IBEARCH-module { joint-iso-itu-t(2) country(16) us(840) 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) },
districtName IA5String, districtName IA5String,
districtSerial INTEGER, districtSerial INTEGER,
validity ValidityPeriod, validity ValidityPeriod,
ibePublicParameters IBEPublicParameters, ibePublicParameters IBEPublicParameters,
ibeIdentitySchema OBJECT IDENTIFIER, ibeIdentityType OBJECT IDENTIFIER,
ibeParamExtensions IBEParamExtensions OPTIONAL ibeParamExtensions IBEParamExtensions OPTIONAL
} }
ValidityPeriod ::= SEQUENCE { ValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime, notBefore GeneralizedTime,
notAfter GeneralizedTime notAfter GeneralizedTime
} }
IBEPublicParameters ::= SEQUENCE (1..MAX) OF IBEPublicParameters ::= SEQUENCE (1..MAX) OF
IBEPublicParameter IBEPublicParameter
skipping to change at page 21, line 13 skipping to change at page 29, line 13
pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) } pkgURI OBJECT IDENTIFIER ::= { ibeParamExt pkgURI(1) }
IBEPrivateKeyReply ::= SEQUENCE { IBEPrivateKeyReply ::= SEQUENCE {
pkgIdentity IBEIdentityInfo, pkgIdentity IBEIdentityInfo,
pgkAlgorithm OBJECT IDENTIFIER, pgkAlgorithm OBJECT IDENTIFIER,
pkgKeyData OCTET STRING, pkgKeyData OCTET STRING,
pkgOptionsSEQUENCE SIZE (1..MAX) OF PKGOption pkgOptionsSEQUENCE SIZE (1..MAX) OF PKGOption
} }
PKGOption ::= SEQUENCE { PKGOption ::= SEQUENCE {
optionID OBJECT IDENTIFIER, optionID OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
optionValue OCTET STRING optionValue OCTET STRING
} }
uriPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) version(1)
}
IBEIdentityInfo ::= SEQUENCE {
district IA5String,
serial INTEGER,
identityType OBJECT IDENTIFIER,
identityData OCTET STRING
}
END END
6. Security Considerations 7. Security Considerations
6.1. Attacks that are 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 IBE are outside the scope of this document. implement IBE are outside the scope of this document. Such
Such attacks are detailed in [IBCS], which defines attacks are detailed in [IBCS], which defines parameters
parameters that give 80-bit, 112-bit and 128-bit that give 80-bit, 112-bit and 128-bit encryption strength.
encryption strength. We assume that capable We assume that capable administrators of an IBE system will
administrators of an IBE system will select parameters select parameters that provide a sufficient resistance to
that provide a sufficient resistance to cryptanalytic cryptanalytic attacks by adversaries.
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 information on a PPS or PKG, especially the change the information on a PPS or PKG, especially the
cryptographic material (referred to in this document as cryptographic material (referred to in this document as the
the master secret), will defeat the security of an IBE master secret), will defeat the security of an IBE system.
system. In particular, if the cryptographic material is In particular, if the cryptographic material is compromised
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 private key and therefore decrypt all messages protected
messages protected with the corresponding public key. To with the corresponding public key. To address this concern,
address this concern, it is highly RECOMMENDED that best it is highly RECOMMENDED that best practices for physical
practices for physical and operational security for PPS and operational security for PPS and PKG servers be
and PKG servers be followed and that these servers be followed and that these servers be configured (sometimes
configured (sometimes known as hardened) in accordance known as hardened) in accordance with best current
with best current practices [NIST]. An IBE system SHOULD practices [NIST]. An IBE system SHOULD be operated in an
be operated in an environment where illicit access is environment where illicit access is infeasible for
infeasible for attackers to obtain. attackers to obtain.
Attacks that require administrative or IBE user Attacks that require administrative or IBE user equivalent
equivalent access to machines used by either the client access to machines used by either the client or the server
or the server components defined in this document are components defined in this document are also outside the
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 protocols that are defined in this implementing the protocols that are defined in this
document are trustworthy and will not abuse their document are trustworthy and will not abuse their authority
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 Similarly, we assume that users of an IBE system will
will behave responsibly, not sharing their authentication behave responsibly, not sharing their authentication
credentials with others. Thus attacks that require such credentials with others. Thus attacks that require such
assumptions are outside the scope of this document. assumptions are outside the scope of this document.
6.2. Attacks that are 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 adversary to: allow an adversary to:
o passively monitor information transmitted o passively monitor information transmitted between
between users of an IBE system and the PPS and users of an IBE system and the PPS and PKG
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 DOS attack on a PPS or PKG
o easily guess an IBE users authentication o easily guess an IBE users authentication
credential credential
6.2.1. Attacks to which the protocols defined in this 7.2.1. Attacks on the protocols defined in this document
document are susceptible
All communications between users of an IBE system and the All communications between users of an IBE system and the
PPS or PKG are protected using TLS 1.1 [TLS]. The IBE PPS or PKG are protected using TLS 1.1 [TLS]. The IBE
system defined in this document provides no additional system defined in this document provides no additional
security protections for the communications between IBE security protections for the communications between IBE
users and the PPS or PKG. Therefore the described IBE users and the PPS or PKG. Therefore the 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 mechanisms for authentication of the PKG or PPS server and
and for confidentiality and integrity of the for confidentiality and integrity of the communications.
communications. Should there be a compromise of the TLS Should there be a compromise of the TLS security
security mechanisms, the integrity of all communications mechanisms, the integrity of all communications between an
between an IBE user and the PPS or PKG will be 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 against an attacker masquerading as a legitimate defend against an attacker masquerading as a legitimate IBE
IBE PPS or PKG. The protocols rely on the server PPS or PKG. The protocols rely on the server authentication
authentication mechanism of TLS [TLS]. In addition to the mechanism of TLS [TLS]. In addition to the TLS server
TLS server authentication mechanism IBE client software authentication mechanism IBE client software can provide
can provide protection against this possibility by protection against this possibility by providing user
providing user interface capabilities that allows users interface capabilities that allows users to visually
to visually determine that a connection to PPS and PKG determine that a connection to PPS and PKG servers is
servers is legitimate. This additional capability can legitimate. This additional capability can help ensure that
help ensure that users cannot easily be tricked into users cannot easily be tricked into providing valid
providing valid authorization credentials to an attacker. authorization credentials to an attacker.
The protocols defined in this document are also The protocols defined in this document are also vulnerable
vulnerable to attacks against an IBE PPS or PKG. Denial to attacks against an IBE PPS or PKG. Denial of service
of service attacks against either component can result in attacks against either component can result in users unable
users unable to encrypt or decrypt using IBE, and users to encrypt or decrypt using IBE, and users of an IBE system
of an IBE system SHOULD take the appropriate SHOULD take the appropriate countermeasures [DOS, BGPDOS]
countermeasures [DOS, BGPDOS] that their use of IBE that their use of IBE requires.
requires.
The IBE user authentication method selected by an IBE PKG The IBE user authentication method selected by an IBE PKG
SHOULD be of sufficient strength to prevent attackers SHOULD be of sufficient strength to prevent attackers from
from easily guessing the IBE user's authentication easily guessing the IBE user's authentication credentials
credentials through trial and error. through trial and error.
7. IANA Considerations 8. IANA Considerations
The XML defined in this document will be registered with 8.1. Media types
the IANA per the instructions in RFC 3688, The IETF XML
Registry.
URI: This specification proposes the registration of three media
types in the standard registration tree. These are
application/ibe-pp-data, application/ibe-key-request+xml,
and application/ibe-pkg-reply+xml. The media type
application/ibe-pp-data is defined in Section 3.3 of this
document. The media type application/ibe-key-request+xml is
defined in Section 4.4 of this document. The media type
application/ibe-pkg-reply+xml is defined in Section 4.7 of
this document.
8.2. XML namespace
The IANA is requested to register the following namespace
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
skipping to change at page 24, line 13 skipping to change at page 33, line 13
XML: XML:
BEGIN BEGIN
<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>
<oid> algorithmOID </oid> algorithmOID
</ibe:algorithm> </ibe:algorithm>
<ibe:id> <ibe:id>
ibeIdentityInfo ibeIdentityInfo
</ibe:id> </ibe:id>
</ibe:keyRequest> </ibe:keyRequest>
<ibe:authData>
ibeAuthData
</ibe:authData>
</ibe:body> </ibe:body>
</ibe:request> </ibe:request>
<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>
END END
8. References 9. References
8.1. Normative References 9.1. Normative References
[ASN1] ITU-T Recommendation X.680: Information Technology [ASCII] ISO/IEC 646:1991 - Information Technology - ISO 7-
- Abstract Syntax Notation One, 1997. bit Coded Character Set for Information Exchange
[ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997.
[AUTH] J. Franks, et al., "HTTP Authentication: Basic and [AUTH] J. Franks, et al., "HTTP Authentication: Basic and
Digest Access Authentication", RFC 2617, June 1999. Digest Access Authentication", RFC 2617, June 1999.
[B64] N. Freed and N. Borenstein, Multipurpose Internet [B64] N. Freed and N. Borenstein, "Multipurpose Internet
Mail Extensions(MIME) Part One: Format of Internet Mail Extensions(MIME) Part One: Format of Internet
Message Bodies," RFC 2045, November 1996. Message Bodies," RFC 2045, November 1996.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC [CMS] R. Housley, "Cryptographic Message Syntax (CMS)," RFC
3852, July 2004. 3852, July 2004.
[DER] CCITT, "Recommendation X.209: Specification of [DER] ITU-T Recommendation X.690: OSI Networking and System
Basic Encoding Rules for Abstract Syntax Notation Aspects: Abstract Syntax Notation One (ASN.1), July
One (ASN.1)," 1998. 2002.
[DOM] P. Mockapetris, "Domain Names - Implementation and [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering:
Specification," RFC 1035, November 1987. Defeating Denial of Service Attacks which employ IP
Source Address Spoofing," RFC 2827, BCP 38, May 2000.
[DOS] P. Ferguson and D. Senie, "Network Ingress [HTTP] R. Fielding, et al., "Hypertext Transfer Protocol --
Filtering: Defeating Denial of Service Attacks HTTP/1.1", RFC 2616, June 1999.
which employ IP Source Address Spoofing," RFC 2827,
BCP 38, May 2000.
[HTTP] R. Fielding, et al., "Hypertext Transfer Protocol [HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May 2000.
-- HTTP/1.1", RFC 2616, June 1999.
[HTTPTLS] E. Rescorla, "HTTP over TLS," RFC 2818, May [IBCS] X. Boyen and L. Martin, "Identity-Based Cryptography
2000. Standard (IBCS) #1: Supersingular Curve
Implementations of the BF and BB1 Cryptosystems," RFC
5091, December 2007.
[IRI] M. Deurst and M. Suignard, "Internationalized
Resource Identifiers (IRIs)," RFC 3987, January 2005.
[KEY] S. Brander, "Key Words for Use in RFCs to Indicate [KEY] S. Brander, "Key Words for Use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[MIME] N. Freed and N. Borenstein, "Multipurpose Internet [PKIX] D. Cooper, et al., "Internet X.509 Public Key
Mail Extensions (MIME) Part Two: Media Types," RFC Infrastructure Certificate and Certificate Revocation
2046, November 1996. [SMTP] J. Klensin (ed.), "Simple Mail Transfer Protocol,"
RFC 2821, April 2001.
[TEXTMSG] D. Crocker, "Standard for the format of ARPA
internet text messages," RFC 2822, April 2001.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer [TLS] T. Dierks and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1," RFC 4346, Security (TLS) Protocol Version 1.1," RFC 4346, April
April 2006. 2006.
[URI] T. Berners-Lee, R. Fielding, and L. Masinter, [URI] T. Berners-Lee, R. Fielding, and L. Masinter,
"Uniform Resource Identifiers (URI): Generic "Uniform Resource Identifier (URI): Generic Syntax",
Syntax", RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[XHTML] M. Baker and P. Stark, "The [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth
'application/xhtml+xml' Media Type," RFC 3236, Edition), September 2006.
January 2002.
8.2. Informative References 9.2. Informative References
[BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
Service Attacks," RFC 3882, September 2004. Service Attacks," RFC 3882, September 2004.
[IBCS] X. Boyen and L. Martin, "Identity-Based
Cryptography Standard (IBCS) #1: Supersingular
Curve Implementations of the BF and BB1
Cryptosystems," draft-martin-ibcs-06.txt, September
2007.
[IBECMS] L. Martin and M. Schertler, "Using the Boneh- [IBECMS] L. Martin and M. Schertler, "Using the Boneh-
Franklin identity-based encryption algorithm with Franklin identity-based encryption algorithm with the
the Cryptographic Message Syntax (CMS)," draft- Cryptographic Message Syntax (CMS)," draft-ietf-
ietf-smime-bfibecms-06.txt, September 2007. 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 Checklist Program for IT Products - Configuration Checklist Program for IT Products -
Guidance for Checklist Users and Developers," NIST Guidance for Checklist Users and Developers," NIST
Special Publication SP 800-70, May 2005. Special Publication SP 800-70, May 2005.
[P1363] IEEE P1363, "Standards Specifications for Public- [P1363] IEEE P1363, "Standard Specifications for Public-Key
Key Cryptography," 2001. Cryptography," 2001.
Authors' Addresses Authors' Addresses
Guido Appenzeller Guido Appenzeller
Voltage Security Stanford University
1070 Arastradero Rd Suite 100 Gates Building 3A
Palo Alto CA 94304 Stanford, CA 94305
Phone: +1 650 543 1280 Phone: +1 650 732 2273
Email: guido@voltage.com 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
skipping to change at page 26, line 48 skipping to change at page 35, line 48
Tumbleweed Communications Tumbleweed Communications
700 Saginaw Dr 700 Saginaw Dr
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: mark.schertler@tumbleweed.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or The IETF takes no position regarding the validity or scope
scope of any Intellectual Property Rights or other rights of any Intellectual Property Rights or other rights that
that might be claimed to pertain to the implementation or might be claimed to pertain to the implementation or use of
use of the technology described in this document or the the technology described in this document or the extent to
extent to which any license under such rights might or which any license under such rights might or might not be
might not be available; nor does it represent that it has available; nor does it represent that it has made any
made any independent effort to identify any such rights. independent effort to identify any such rights.
Information on the procedures with respect to rights in Information on the procedures with respect to rights in RFC
RFC documents can be found in BCP 78 and BCP 79. documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat Copies of IPR disclosures made to the IETF Secretariat and
and any assurances of licenses to be made available, or any assurances of licenses to be made available, or the
the result of an attempt made to obtain a general license result of an attempt made to obtain a general license or
or permission for the use of such proprietary rights by permission for the use of such proprietary rights by
implementers or users of this specification can be implementers or users of this specification can be obtained
obtained from the IETF on-line IPR repository at from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, attention any copyrights, patents or patent applications,
or other proprietary rights that may cover technology or other proprietary rights that may cover technology that
that may be required to implement this standard. Please may be required to implement this standard. Please address
address the information to the IETF at ietf-ipr@ietf.org. the information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights. therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided Funding for the RFC Editor function is currently provided
by the Internet Society. by the Internet Society.
 End of changes. 159 change blocks. 
615 lines changed or deleted 993 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/