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