draft-ietf-smime-ibearch-08.txt   draft-ietf-smime-ibearch-09.txt 
G. Appenzeller G. Appenzeller
Stanford University Stanford University
S/MIME Working Group L. Martin S/MIME Working Group L. Martin
Internet Draft Voltage Security Internet Draft Voltage Security
Intended status: Standards Track M. Schertler Intended status: Standards Track M. Schertler
Expires: March 2009 Tumbleweed Communications Expires: April 2009 Tumbleweed Communications
September 2008 October 2008
Identity-based Encryption Architecture and Supporting Data Identity-based Encryption Architecture and Supporting Data
Structures Structures
<draft-ietf-smime-ibearch-08.txt> <draft-ietf-smime-ibearch-09.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 he that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in which he or she becomes aware will be disclosed, 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4. Public Parameter Lookup.............................11 4. Public Parameter Lookup.............................11
4.1. Request Method.................................12 4.1. Request Method.................................12
4.2. Parameter and Policy Format....................12 4.2. Parameter and Policy Format....................12
4.3. The application/ibe-pp-data MIME type..........16 4.3. The application/ibe-pp-data MIME type..........16
5. Private Key Request Protocol........................17 5. Private Key Request Protocol........................17
5.1. Overview.......................................17 5.1. Overview.......................................17
5.2. Private Key Request............................18 5.2. Private Key Request............................18
5.3. Request Structure..............................18 5.3. Request Structure..............................18
5.4. The application/ibe-key-request+xml MIME type..20 5.4. The application/ibe-key-request+xml MIME type..20
5.5. Authentication.................................21 5.5. Authentication.................................21
5.6. Server Response Format.........................22 5.6. Server Response Format.........................21
5.6.1. The IBE100 responseCode...................22 5.6.1. The IBE100 responseCode...................22
5.6.2. The IBE101 responseCode...................24 5.6.2. The IBE101 responseCode...................23
5.6.3. The IBE201 responseCode...................24 5.6.3. The IBE201 responseCode...................23
5.6.4. The IBE300 responseCode...................25 5.6.4. The IBE300 responseCode...................24
5.6.5. The IBE301 responseCode...................25 5.6.5. The IBE301 responseCode...................24
5.6.6. The IBE303 responseCode...................25 5.6.6. The IBE303 responseCode...................25
5.6.7. The IBE304 responseCode...................26 5.6.7. The IBE304 responseCode...................25
5.7. The application/ibe-pkg-reply+xml MIME type....26 5.7. The application/ibe-pkg-reply+xml MIME type....25
6. ASN.1 Module........................................27 6. ASN.1 Module........................................26
7. Security Considerations.............................29 7. Security Considerations.............................28
7.1. Attacks outside the scope of this document.....29 7.1. Attacks outside the scope of this document.....28
7.2. Attacks within the scope of this document......30 7.2. Attacks within the scope of this document......29
7.2.1. Attacks on the protocols defined in this 7.2.1. Attacks on the protocols defined in this
document.........................................30 document.........................................29
8. IANA Considerations.................................31 8. IANA Considerations.................................30
8.1. Media types....................................31 8.1. Media types....................................30
8.2. XML namespace..................................31 8.2. XML namespace..................................30
9. References..........................................33 9. References..........................................32
9.1. Normative References...........................33 9.1. Normative References...........................32
9.2. Informative References.........................34 9.2. Informative References.........................33
Authors' Addresses.....................................35 Authors' Addresses.....................................34
Intellectual Property Statement........................35 Intellectual Property Statement........................34
Disclaimer of Validity.................................36 Disclaimer of Validity.................................35
Copyright Statement....................................36 Copyright Statement....................................35
Acknowledgment.........................................36 Acknowledgment.........................................35
1. Introduction 1. Introduction
This document describes the security architecture required This document describes the security architecture required
to implement identity-based encryption, a public-key to implement identity-based encryption, a public-key
encryption technology that uses a user's identity as a encryption technology that uses a user's identity as a
public key. It also defines data structures that are public key. It also defines data structures that are
required to implement the technology. Objects used in this required to implement the technology. Objects used in this
implementation are defined using ASN.1 [ASN1] and XML implementation are defined using ASN.1 [ASN1] and XML
[XML]. [XML].
skipping to change at page 16, line 20 skipping to change at page 16, line 20
4.3. The application/ibe-pp-data MIME type 4.3. The application/ibe-pp-data MIME type
The following summarizes the properties of the The following summarizes the properties of the
application/ibe-pp-data MIME type. application/ibe-pp-data MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-pp-data MIME subtype name: ibe-pp-data
Mandatory parameters: The single required parameter is a Mandatory parameters: none
base64-encoded DER-encoded IBESysParams structure.
Optional parameters: There are no optional parameters. Optional parameters: none
Encoding considerations: This media type MUST be encoded as Encoding considerations: This media type MUST be encoded as
7bit (us-ascii text [ASCII]). 7bit (us-ascii text [ASCII]).
Security considerations: The data conveyed as this media Security considerations: The data conveyed as this media
type are the public parameters needed for the operation of type are the public parameters needed for the operation of
a cryptographic system. To ensure that the parameters can a cryptographic system. To ensure that the parameters can
be trusted, the request for these parameters must take be trusted, the request for these parameters must take
place over a secure protocol, TLS 1.1 or its successors. To place over a secure protocol, TLS 1.1 or its successors. To
ensure the validity of the server, the client MUST verify ensure the validity of the server, the client MUST verify
skipping to change at page 16, line 47 skipping to change at page 16, line 46
content and does not use compression. content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known
interoperability considerations for this media type. interoperability considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that
implement IBE in compliance with this specification will implement IBE in compliance with this specification will
use this media type. The most commonly-used of these use this media type. The most commonly-used of these
applications are encrypted email and file encryption. applications are encrypted email and file encryption.
Additional information: This media type is used for the Additional information: none
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 Person and email address for further information: Luther
Martin, martin@voltage.com. Martin, martin@voltage.com.
Intended usage: COMMON. Intended usage: COMMON
Author/Change controller: Luther Martin, Author/Change controller: Luther Martin,
martin@voltage.com. martin@voltage.com.
5. Private Key Request Protocol 5. Private Key Request Protocol
5.1. Overview 5.1. Overview
When requesting a private key, a client has to transmit When requesting a private key, a client has to transmit
three parameters: three parameters:
skipping to change at page 20, line 16 skipping to change at page 20, line 16
5.4. The application/ibe-key-request+xml MIME type 5.4. The application/ibe-key-request+xml MIME type
The following summarizes the properties of the application/ The following summarizes the properties of the application/
ibe-key-request+xml MIME type. ibe-key-request+xml MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-key-request+xml MIME subtype name: ibe-key-request+xml
Mandatory parameters: The required parameters are the Mandatory parameters: none
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 Optional parameters: none
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 Encoding considerations: This media type MUST be encoded as
us-ascii [ASCII]. us-ascii [ASCII].
Security considerations: The data conveyed in this media Security considerations: The data conveyed in this media
type may contain authentication credentials. Because of type may contain authentication credentials. Because of
this, its confidentiality and integrity is extremely this, its confidentiality and integrity is extremely
important. To ensure this, the request for an IBE private important. To ensure this, the request for an IBE private
key must take place over a secure protocol, TLS 1.1 or its key must take place over a secure protocol, TLS 1.1 or its
successors. To ensure the validity of the server, the successors. To ensure the validity of the server, the
skipping to change at page 21, line 13 skipping to change at page 20, line 42
contains no active content and does not use compression. contains no active content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known
interoperability considerations for this media type. interoperability considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that
implement IBE in compliance with this specification will implement IBE in compliance with this specification will
use this media type. The most commonly-used of these use this media type. The most commonly-used of these
applications are encrypted email and file encryption. applications are encrypted email and file encryption.
Additional information: This media type is used for the Additional information: none
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 Person and email address for further information: Luther
Martin, martin@voltage.com. Martin, martin@voltage.com.
Intended usage: COMMON. Intended usage: COMMON
Author/Change controller: Luther Martin, Author/Change controller: Luther Martin,
martin@voltage.com. martin@voltage.com.
5.5. Authentication 5.5. Authentication
When a client requests a key from a PKG, the PKG MUST When a client requests a key from a PKG, the PKG MUST
authenticate 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.
skipping to change at page 26, line 39 skipping to change at page 26, line 9
5.7. The application/ibe-pkg-reply+xml MIME type 5.7. The application/ibe-pkg-reply+xml MIME type
The following summarizes the properties of the The following summarizes the properties of the
application/ibe-pkg-reply+xml MIME type. application/ibe-pkg-reply+xml MIME type.
MIME media type name: application MIME media type name: application
MIME subtype name: ibe-pkg-reply+xml MIME subtype name: ibe-pkg-reply+xml
Mandatory parameters: The only required parameter is a Mandatory parameters: none
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. Optional parameters: none
Encoding considerations: This media type MUST be encoded as Encoding considerations: This media type MUST be encoded as
us-ascii [ASCII]. us-ascii [ASCII].
Security considerations: The data conveyed as this media Security considerations: The data conveyed as this media
type is an IBE private key, so its confidentiality and type is an IBE private key, so its confidentiality and
integrity is extremely important. To ensure this, the integrity is extremely important. To ensure this, the
response from the server that contains an IBE private key response from the server that contains an IBE private key
must take place over a secure protocol, TLS 1.1 or its must take place over a secure protocol, TLS 1.1 or its
successors. To ensure the validity of the server, the successors. To ensure the validity of the server, the
skipping to change at page 27, line 24 skipping to change at page 26, line 35
contains no active content and does not use compression. contains no active content and does not use compression.
Interoperability considerations: There are no known Interoperability considerations: There are no known
interoperability considerations for this media type. interoperability considerations for this media type.
Applications that use this media type: Applications that Applications that use this media type: Applications that
implement IBE in compliance with this specification will implement IBE in compliance with this specification will
use this media type. The most commonly-used of these use this media type. The most commonly-used of these
applications are encrypted email and file encryption. applications are encrypted email and file encryption.
Additional information: This media type is used for the Additional information: none
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 Person and email address for further information: Luther
Martin, martin@voltage.com. Martin, martin@voltage.com.
Intended usage: COMMON. Intended usage: COMMON
Author/Change controller: Luther Martin, Author/Change controller: Luther Martin,
martin@voltage.com. martin@voltage.com.
6. ASN.1 Module 6. ASN.1 Module
The following ASN.1 module summarizes the ASN.1 definitions The following ASN.1 module summarizes the ASN.1 definitions
discussed in this document. 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)
skipping to change at page 31, line 41 skipping to change at page 30, line 41
through trial and error. through trial and error.
8. IANA Considerations 8. IANA Considerations
8.1. Media types 8.1. Media types
This specification proposes the registration of three media This specification proposes the registration of three media
types in the standard registration tree. These are types in the standard registration tree. These are
application/ibe-pp-data, application/ibe-key-request+xml, application/ibe-pp-data, application/ibe-key-request+xml,
and application/ibe-pkg-reply+xml. The media type and application/ibe-pkg-reply+xml. The media type
application/ibe-pp-data is defined in Section 3.3 of this application/ibe-pp-data is defined in Section 4.3 of this
document. The media type application/ibe-key-request+xml is document. The media type application/ibe-key-request+xml is
defined in Section 4.4 of this document. The media type defined in Section 5.4 of this document. The media type
application/ibe-pkg-reply+xml is defined in Section 4.7 of application/ibe-pkg-reply+xml is defined in Section 5.7 of
this document. this document.
8.2. XML namespace 8.2. XML namespace
The IANA is requested to register the following namespace The IANA is requested to register the following namespace
identifier: identifier:
urn:ietf:params:xml:ns:ibe urn:ietf:params:xml:ns:ibe
Registrant Contact: Registrant Contact:
skipping to change at page 34, line 31 skipping to change at page 33, line 31
5091, December 2007. 5091, December 2007.
[IRI] M. Deurst and M. Suignard, "Internationalized [IRI] M. Deurst and M. Suignard, "Internationalized
Resource Identifiers (IRIs)," RFC 3987, January 2005. 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.
[PKIX] D. Cooper, et al., "Internet X.509 Public Key [PKIX] D. Cooper, et al., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
[SMTP] J. Klensin (ed.), "Simple Mail Transfer Protocol," [SMTP] J. Klensin, "Simple Mail Transfer Protocol," RFC
RFC 2821, April 2001. 5321, October 2008.
[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, April Security (TLS) Protocol Version 1.1," RFC 4346, April
2006. 2006.
[URI] T. Berners-Lee, R. Fielding, and L. Masinter, [URI] T. Berners-Lee, R. Fielding, and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth [XML] W3C, Extensible Markup Language (XML) 1.0 (Fourth
 End of changes. 21 change blocks. 
77 lines changed or deleted 43 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/