draft-ietf-smime-bfibecms-05.txt   draft-ietf-smime-bfibecms-06.txt 
L. Martin L. Martin
S/MIME Working Group Voltage Security S/MIME Working Group Voltage Security
Internet Draft Mark Schertler Internet Draft Mark Schertler
Expires: February 2008 Tumbleweed Communications Expires: March 2008 Tumbleweed Communications
August 2007 September 2007
Using the Boneh-Franklin and Boneh-Boyen identity-based encryption Using the Boneh-Franklin and Boneh-Boyen identity-based
algorithms with the Cryptographic Message Syntax (CMS) encryption algorithms with the Cryptographic Message Syntax
(CMS)
<draft-ietf-smime-bfibecms-05.txt> <draft-ietf-smime-bfibecms-06.txt>
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents
applicable patent or other IPR claims of which he or she is aware that any applicable patent or other IPR claims of which he
have been or will be disclosed, and any of which he or she becomes or she is aware have been or will be disclosed, and any of
aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute working
Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of
and may be updated, replaced, or obsoleted by other documents at any six months and may be updated, replaced, or obsoleted by
time. It is inappropriate to use Internet-Drafts as reference other documents at any time. It is inappropriate to use
material or to cite them other than as "work in progress." 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 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 accessed at The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes the conventions for using the Boneh-Franklin This document describes the conventions for using the Boneh-
(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in Franklin (BF) and Boneh-Boyen (BB1) identity-based
the Cryptographic Message Syntax (CMS) to encrypt content-encryption encryption algorithms in the Cryptographic Message Syntax
keys. Object identifiers and the convention for encoding a (CMS) to encrypt content-encryption keys. Object identifiers
recipient's identity are also defined. and the convention for encoding a recipient's identity are
also defined.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction............................................2
1.1. Terminology...............................................3 1.1. Terminology........................................3
1.2. IBE overview..............................................3 1.2. IBE overview.......................................3
2. Using identity-based encryption................................3 2. Using identity-based encryption.........................3
3. Key encryption algorithm identifiers...........................6 3. Key encryption algorithm identifiers....................7
4. Processing by the sender.......................................7 4. Processing by the sender................................7
5. Processing by the receiver.....................................7 5. Processing by the receiver..............................8
6. ASN.1 module...................................................9 6. ASN.1 module............................................9
7. Security considerations.......................................10 7. Security considerations................................10
7.1. Attacks that are outside the scope of this document......10 7.1. Attacks that are outside the scope of this document10
7.2. Attacks that are within the scope of this document.......11 7.2. Attacks that are within the scope of this document11
7.3. Attacks to which the protocols defined in this document are 7.3. Attacks to which the protocols defined in this
susceptible...................................................11 document are susceptible...............................11
8. IANA considerations...........................................12 8. IANA considerations....................................12
9. References....................................................13 9. References.............................................13
9.1. Normative references.....................................13 9.1. Normative references..............................13
9.2. Informative references...................................13 9.2. Informative references............................13
Authors' Addresses...............................................14 Authors' Addresses........................................14
Intellectual property statement..................................14 Intellectual property statement...........................14
Disclaimer of validity...........................................15 Disclaimer of validity....................................15
Copyright statement..............................................15 Copyright statement.......................................15
Acknowledgment...................................................15 Acknowledgment............................................15
1. Introduction 1. Introduction
This document defines the way to use the Boneh-Franklin [BF] and This document defines the way to use the Boneh-Franklin
Boneh-Boyen [BB1] identity-based encryption (IBE) public-key [IBCS] and Boneh-Boyen [IBCS] identity-based encryption
algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a (IBE) public-key algorithms in the Cryptographic Message
public key technology for encrypting content-encryption keys (CEKs) Syntax (CMS) [CMS]. IBE is a public key technology for
that can be implemented within the framework of the CMS: the encrypting content-encryption keys (CEKs) that can be
recipient's identity is incorporated into the EnvelopedData CMS implemented within the framework of the CMS: the recipient's
content type using the OtherRecipientInfo CHOICE in the RecipientInfo identity is incorporated into the EnvelopedData CMS content
field as defined in section 6.2.5 of [CMS]. This document does not type using the OtherRecipientInfo CHOICE in the
describe the implementation of the BF and BB1 algorithms, which are RecipientInfo field as defined in section 6.2.5 of [CMS].
described in detail in [IBCS]. This document does not describe the implementation of the BF
and BB1 algorithms, which are described in detail in [IBCS].
IBE algorithms are a type of public-key cryptographic algorithm in IBE algorithms are a type of public-key cryptographic
which the public key is calculated directly from a user's identity algorithm in which the public key is calculated directly
instead of being generated randomly. This requires a different set of from a user's identity instead of being generated randomly.
steps for encryption and decryption than would be used with other This requires a different set of steps for encryption and
public-key algorithms, and these steps are defined in Sections 4 and decryption than would be used with other public-key
5 of this document respectively. algorithms, and these steps are defined in Sections 4 and 5
of this document respectively.
This document also defines the object identifiers and syntax of the This document also defines the object identifiers and syntax
object that is used to define the identity of a message recipient. of the object that is used to define the identity of a
message recipient.
CMS values and identity objects are defined using ASN.1 [ASN1]. CMS values and identity objects are defined using ASN.1
[ASN1].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
document are to be interpreted as described in RFC-2119 [KEYWORDS]. and "OPTIONAL" in this document are to be interpreted as
described in RFC-2119 [KEYWORDS].
1.2. IBE overview 1.2. IBE overview
In addition to the client components that are described in this In addition to the client components that are described in
document, the following additional components are required for a this document, the following additional components are
complete IBE messaging system: required for a complete IBE messaging system:
o A Private-key Generator (PKG). The PKG contains the o A Private-key Generator (PKG). The PKG contains the
cryptographic material, known as a master secret, for cryptographic material, known as a master secret,
generating an individual's IBE private key. A PKG accepts an for generating an individual's IBE private key. A
IBE user's private key request and, after successfully PKG accepts an IBE user's private key request and,
authenticating them in some way, returns their IBE private after successfully authenticating them in some way,
key. returns their IBE private key.
o A Public Parameter Server (PPS). IBE System Parameters o A Public Parameter Server (PPS). IBE System
include publicly sharable cryptographic material, known as Parameters include publicly sharable cryptographic
IBE public parameters, and policy information for the PKG. A material, known as IBE public parameters, and
PPS provides a well-known location for secure distribution policy information for the PKG. A PPS provides a
of IBE public parameters and policy information for the IBE well-known location for secure distribution of IBE
PKG. public parameters and policy information for the
IBE PKG.
The interaction of senders and receivers of IBE-encrypted messages The interaction of senders and receivers of IBE-encrypted
are described in [IBE]. messages are described in [IBE].
2. Using identity-based encryption 2. Using identity-based encryption
To use IBE, the ori field in RecipientInfo MUST be used. The fields To use IBE, the ori field in RecipientInfo MUST be used. The
are set as follows: oriType is set to ibeORIType; oriValue is set to fields are set as follows: oriType is set to ibeORIType;
ibeORIValue. oriValue is set to ibeORIValue.
These fields have the following meanings: These fields have the following meanings:
ibeORIType defines the object identifier (OID) that indicates that ibeORIType defines the object identifier (OID) that
the subsequent ibeORIValue is the information necessary to decrypt indicates that the subsequent ibeORIValue is the information
the message using IBE. This field MUST be set to necessary to decrypt the message using IBE. This field MUST
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16) be set to
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2)
country(16)
us(840) organization(1) identicrypt(114334) ibcs(1) us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1) } cms(4) ori-oid(1) }
ibeORIValue defines the identity that was used in the IBE algorithm ibeORIValue defines the identity that was used in the IBE
to encrypt the CEK. This is an IBERecipientInfo type. algorithm to encrypt the CEK. This is an IBERecipientInfo
type.
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL, OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
The fields of IBERecipientInfo have the following meanings: The fields of IBERecipientInfo have the following meanings:
The cmsVersion MUST be set to 3. The cmsVersion MUST be set to 3.
The keyFetchMethod is the OID that defines the method of retrieving The keyFetchMethod is the OID that defines the method of
the private key that the recipient MUST use. How to retrieve an IBE retrieving the private key that the recipient MUST use. How
private key using the steps defined in [IBE] is defined by the to retrieve an IBE private key using the steps defined in
keyFetchMethod OID. The method for retrieving private keys that is [IBE] is defined by the keyFetchMethod OID. The method for
specified in [IBE] is defined by cmsPPSOID. retrieving private keys that is specified in [IBE] is
defined by cmsPPSOID.
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3) us(840) organization(1) identicrypt(114334) pps-schemas(3)
ic-schemas(1) pps-uri(1) ic-schemas(1) pps-uri(1)
} }
The recipientIdentity is the data that was used to calculate the IBE The recipientIdentity is the data that was used to calculate
public key that was used to encrypt the content-encryption key. This the IBE public key that was used to encrypt the content-
MUST be an IBEIdentityInfo type. This recipientIdentity is used to encryption key. This MUST be an IBEIdentityInfo type. This
calculate IBE public and private keys as described in [IBCS]. recipientIdentity is used to calculate IBE public and
private keys as described in [IBCS].
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district IA5String, district IA5String,
serial INTEGER, serial INTEGER,
identitySchema OBJECT IDENTIFIER, identitySchema OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
The fields of IBEIdentityInfo have the following meanings. The fields of IBEIdentityInfo have the following meanings.
The district and serial are unique identifiers that are used to The district and serial are unique identifiers that are used
construct the URI for the location of the necessary IBE public to construct the URI for the location of the necessary IBE
parameters. The construction and use of this URI is defined in [IBE]. public parameters. The construction and use of this URI is
defined in [IBE].
The identitySchema defines the format that is used to encode the The identitySchema defines the format that is used to encode
information that defines the identity of the recipient. This MUST be the information that defines the identity of the recipient.
set to cmsIdentityOID to indicate that identityData contains an This MUST be set to cmsIdentityOID to indicate that
EmailIdentitySchema type. identityData contains an EmailIdentitySchema type.
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16)
us(840) organization(1) identicrypt(114334) keyschemas(2) us(840) organization(1) identicrypt(114334) keyschemas(2)
icschemas(1) rfc822email(1) icschemas(1) TEXTMSGemail(1)
} }
The identityData field contains the identify information for the The identityData field contains the identify information for
recipient. If the contents of the field is an ASN.1 structure, the the recipient. If the contents of the field is an ASN.1
structure MUST be DER encoded [DER] before placing it in the OCTET structure, the structure MUST be DER encoded [DER] before
STRING. placing it in the OCTET STRING.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email IA5String, TEXTMSGEmail IA5String,
time GeneralizedTime time GeneralizedTime
} }
The rfc822Email is the e-mail address of the recipient in the format The TEXTMSGEmail is the e-mail address of the recipient in
defined by [RFC822]. E-mail addresses that contain non-ASCII the format defined by [TEXTMSG]. E-mail addresses that
characters MUST be encoded using punycode [RFC3492]. contain non-ASCII characters MUST be encoded using punycode
[PUNYCODE].
The value of "time" is the UTC time after which the sender wants to The value of "time" is the UTC time after which the sender
let the recipient decrypt the message, so it may be called the "not- wants to let the recipient decrypt the message, so it may be
before" time. This is usually set to the time when the message is called the "not-before" time. This is usually set to the
encrypted, but MAY be set to a future time. UTC time values are time when the message is encrypted, but MAY be set to a
expressed to the nearest second. future time. UTC time values are expressed to the nearest
second.
The sender of an IBE-encrypted message may want to express this time The sender of an IBE-encrypted message may want to express
rounded to a time interval to create a key lifetime. A key lifetime this time rounded to a time interval to create a key
reduces the number of IBE private keys that a recipient needs to lifetime. A key lifetime reduces the number of IBE private
retrieve, but still forces the IBE user to periodically re- keys that a recipient needs to retrieve, but still forces
authenticate. Based on the time interval chosen a recipient would the IBE user to periodically re-authenticate. Based on the
only have to retrieve a new IBE key once during the interval. To do time interval chosen a recipient would only have to retrieve
this, follow the following steps. Let "time-interval" be the number a new IBE key once during the interval. To do this, follow
of seconds in this larger time interval. the following steps. Let "time-interval" be the number of
seconds in this larger time interval.
1. Find the GeneralizedTime for the not-before value. 1. Find the GeneralizedTime for the not-before value.
2. Convert this GeneralizedTime into the number of seconds 2. Convert this GeneralizedTime into the number of
seconds
since January 1, 1970. Call this "total-time." since January 1, 1970. Call this "total-time."
3. Calculate reduced-time = (floor (total-time / 3. Calculate reduced-time = (floor (total-time /
time-interval)) * time-interval. time-interval)) * time-interval.
4. Convert reduced-time to a GeneralizedTime to get the 4. Convert reduced-time to a GeneralizedTime to get the
not-before "time" value. not-before "time" value.
An example of this algorithm for computing a one week time interval An example of this algorithm for computing a one week time
is as follows. interval is as follows.
1. Say the GeneralizedTime is 20020401000000Z. 1. Say the GeneralizedTime is 20020401000000Z.
2. Then the total-time is 1017612000. 2. Then the total-time is 1017612000.
3. A time-interval of 1 week is 604800 seconds. 3. A time-interval of 1 week is 604800 seconds.
So the reduced-time = (floor(1017612000/604800))* So the reduced-time = (floor(1017612000/604800))*
604800 = 1017273600. 604800 = 1017273600.
4. This gives the reduced-time GeneralizedTime form of the 4. This gives the reduced-time GeneralizedTime form of
the
reduced-time of 20020328000000Z. reduced-time of 20020328000000Z.
When issuing IBE private keys, a PKG SHOULD NOT issue them too far When issuing IBE private keys, a PKG SHOULD NOT issue them
into the future. This restriction is to prevent an adversary who too far into the future. This restriction is to prevent an
obtains an IBE user's authentication credentials from requesting adversary who obtains an IBE user's authentication
private keys far into the future and therefore negating the periodic credentials from requesting private keys far into the future
IBE user re-authentication that key lifetime provides. For example if and therefore negating the periodic IBE user re-
a one week period is chosen for the key lifetime, then IBE private authentication that key lifetime provides. For example if a
keys should not be issued more than 1 week in advance. Otherwise once one week period is chosen for the key lifetime, then IBE
an adversary gains access to the PKG via the stolen IBE user private keys should not be issued more than 1 week in
credentials they can request all future keys and negate the IBE user advance. Otherwise once an adversary gains access to the PKG
authentication restraints in place. via the stolen IBE user credentials they can request all
future keys and negate the IBE user authentication
restraints in place.
The serverInfo is an optional series of OID-value pairs that can be The serverInfo is an optional series of OID-value pairs that
used to convey any other information that might be used by a PKG. can be used to convey any other information that might be
Examples of such information could include the user interface that used by a PKG. Examples of such information could include
the recipient will experience. Differences in the user interface the user interface that the recipient will experience.
could include localization information or commercial branding Differences in the user interface could include localization
information. information or commercial branding information.
The encryptedKey is the result of encrypting the CEK with an IBE The encryptedKey is the result of encrypting the CEK with an
algorithm using recipientIdentity as the IBE public key. IBE algorithm using recipientIdentity as the IBE public key.
3. Key encryption algorithm identifiers 3. Key encryption algorithm identifiers
The BF and BB1 algorithms as defined in [IBCS] have the following The BF and BB1 algorithms as defined in [IBCS] have the
object identifiers. These object identifiers are also defined in the following object identifiers. These object identifiers are
ASN.1 module in [IBCS]. also defined in the ASN.1 module in [IBCS].
bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) bf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
ibe-algorithms(2) bf(1) } ibe-algorithms(2) bf(1) }
This is the object identifier that MUST be inserted in the This is the object identifier that MUST be inserted in the
keyEncryptionAlgorithm field in the CMS when the BF algorithm is used keyEncryptionAlgorithm field in the CMS when the BF
to encrypt the CEK. algorithm is used to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334) ibcs(1) ibcs1(1)
ibe-algorithms(2) bb1(2) } ibe-algorithms(2) bb1(2) }
This is the object identifier that MUST be inserted in the This is the object identifier that MUST be inserted in the
keyEncryptionAlgorithm field in the CMS when the BB1 algorithm is keyEncryptionAlgorithm field in the CMS when the BB1
used to encrypt the CEK. algorithm is used to encrypt the CEK.
4. Processing by the sender 4. Processing by the sender
The sender of a message that uses IBE to encrypt content-encryption The sender of a message that uses IBE to encrypt content-
keys performs the following steps: encryption keys performs the following steps:
1. Selects a set of IBE public parameters to use in the subsequent 1. Selects a set of IBE public parameters to use in the
steps in accordance with his local security policy. He then subsequent steps in accordance with his local security
determines the URI where the public parameters can be obtained using policy. He then determines the URI where the public
the process described in [IBE]. This information MUST be encoded in parameters can be obtained using the process described in
the IBEIdentityInfo as described in Section 2. [IBE]. This information MUST be encoded in the
IBEIdentityInfo as described in Section 2.
2. Sets the fields of an OtherRecipientInfo object to their 2. Sets the fields of an OtherRecipientInfo object to
appropriate values as described in Section 2. their appropriate values as described in Section 2.
3. Calculates an IBE public key as defined in [IBCS] using this 3. Calculates an IBE public key as defined in [IBCS]
IBEIdentityInfo as the identity information. using this IBEIdentityInfo as the identity information.
4. This IBE public key is then used to encrypt the content- 4. This IBE public key is then used to encrypt the
encryption key (CEK), using the algorithms that are defined in content-encryption key (CEK), using the algorithms that are
[IBCS]. defined in [IBCS].
5. Sets encryptedKey to the IBE-encrypted CEK. 5. Sets encryptedKey to the IBE-encrypted CEK.
6. Within the CMS, keyEncryptionAlgorithm MUST then be set to the 6. Within the CMS, keyEncryptionAlgorithm MUST then be
appropriate OID for the IBE algorithm that was used (see Section 3). set to the appropriate OID for the IBE algorithm that was
used (see Section 3).
5. Processing by the receiver 5. Processing by the receiver
Upon receiving a message that has a CEK encrypted with IBE, the Upon receiving a message that has a CEK encrypted with IBE,
recipient performs the following steps to decrypt the CEK: the recipient performs the following steps to decrypt the
CEK:
1. Determines that the CEK is IBE-encrypted by noting that the 1. Determines that the CEK is IBE-encrypted by noting that
oriType of the OtherRecipientInfo type is set to ibeORIType. the oriType of the OtherRecipientInfo type is set to
ibeORIType.
2. Determines that the recipientIdentity was used as the identity 2. Determines that the recipientIdentity was used as the
in IBE encryption of the CEK. identity in IBE encryption of the CEK.
3. Determines the location of the IBE public parameters and the 3. Determines the location of the IBE public parameters
IBE Private Key Generator as described in [IBE]. and the IBE Private Key Generator as described in
[IBE].
4. Obtains the IBE public parameters from the location determined 4. Obtains the IBE public parameters from the location
in Step 3 using the process defined in [IBE]. determined in Step 3 using the process defined in
[IBE].
5. Obtains the IBE private key needed to decrypt the encrypted CEK 5. Obtains the IBE private key needed to decrypt the
using the process defined in [IBE]. encrypted CEK using the process defined in [IBE].
6. Decrypts the CEK using the IBE private key obtained in Step 4 6. Decrypts the CEK using the IBE private key obtained in
using the algorithms described in [IBCS]. Step 4 using the algorithms described in [IBCS].
6. ASN.1 module 6. ASN.1 module
IBECMS-module { joint-iso-itu-t(2) country(16) us(840) IBECMS-module { joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) cms(4) organization(1) identicrypt(114334) ibcs(1) cms(4)
module(5) version(1) module(5) version(1)
} }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
IBEOtherRecipientInfo ::= SEQUENCE { IBEOtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER, oriType OBJECT IDENTIFIER,
oriValue IBERecipientInfo oriValue IBERecipientInfo
} }
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16)
us(840) organization(1) identicrypt(114334) ibcs(1) us(840) organization(1) identicrypt(114334) ibcs(1)
cms(4) ori-oid(1) cms(4) ori-oid(1)
} }
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE SIZE (1..MAX) OF serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL, OIDValuePairs OPTIONAL,
skipping to change at page 9, line 48 skipping to change at page 9, line 49
} }
OIDValuePairs ::= SEQUENCE { OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER, fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING fieldData OCTET STRING
} }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email IA5String, TEXTMSGEmail IA5String,
time GeneralizedTime time GeneralizedTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16)
us(840) organization(1) identicrypt(114334) keyschemas(2) us(840) organization(1) identicrypt(114334) keyschemas(2)
icschemas(1) rfc822email(1) icschemas(1) TEXTMSGemail(1)
} }
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3) us(840) organization(1) identicrypt(114334) pps-schemas(3)
ic-schemas(1) pps-uri(1) ic-schemas(1) pps-uri(1)
} }
END END
7. Security considerations 7. Security considerations
This document is based on [CMS] and [IBCS], and the relevant security This document is based on [CMS] and [IBCS], and the relevant
considerations of those documents apply. security considerations of those documents apply.
7.1. Attacks that are outside the scope of this document 7.1. Attacks that are outside the scope of this document
Attacks on the cryptographic algorithms that are used to implement Attacks on the cryptographic algorithms that are used to
IBE are outside the scope of this document. Such attacks are detailed implement IBE are outside the scope of this document. Such
in [IBCS], which defines parameters that give 80-bit, 112-bit, 128- attacks are detailed in [IBCS], which defines parameters
bit and 256-bit encryption strength. We assume that capable that give 80-bit, 112-bit, 128-bit and 256-bit encryption
administrators of an IBE system will select parameters that provide a strength. We assume that capable administrators of an IBE
sufficient resistance to cryptanalytic attacks by adversaries. 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 Attacks that give an adversary the ability to access or
information on a PPS or PKG, especially the cryptographic material change the information on a PPS or PKG, especially the
(referred to in this document as the master secret), will defeat the cryptographic material (referred to in this document as the
security of an IBE system. In particular, if the cryptographic master secret), will defeat the security of an IBE system.
material is compromised the adversary will have the ability to In particular, if the cryptographic material is compromised
recreate any user's private key and therefore decrypt all messages the adversary will have the ability to recreate any user's
protected with the corresponding public key. To address this concern, private key and therefore decrypt all messages protected
it is highly RECOMMENDED that best practices for physical and with the corresponding public key. To address this concern,
operational security for PPS and PKG servers be followed and that it is highly RECOMMENDED that best practices for physical
these servers be configured (sometimes known as hardened) in and operational security for PPS and PKG servers be followed
accordance with best current practices [NIST]. An IBE system SHOULD and that these servers be configured (sometimes known as
be operated in an environment where illicit access to the PPS and PKG hardened) in accordance with best current practices [NIST].
is infeasible for attackers to obtain. An IBE system SHOULD be operated in an environment where
illicit access to the PPS and PKG is infeasible for
attackers to obtain.
Attacks that require administrative or IBE user equivalent access to Attacks that require administrative or IBE user equivalent
machines used by either the client or the server components defined access to machines used by either the client or the server
in this document are also outside the scope of this document. components defined in this document are also outside the
scope of this document.
We also assume that all administrators of a system implementing the We also assume that all administrators of a system
protocols that are defined in this document are trustworthy and will implementing the protocols that are defined in this document
not abuse their authority to bypass the security provided by an IBE are trustworthy and will not abuse their authority to bypass
system. This is of particular importance with an IBE system, for an the security provided by an IBE system. This is of
administrator of a PKG could potentially abuse his authority and particular importance with an IBE system, for an
configure the PKG to grant him any IBE private key that the PKG is administrator of a PKG could potentially abuse his authority
capable of calculating. To minimize the possibility of administrators and configure the PKG to grant him any IBE private key that
doing this, a system implementing IBE SHOULD implement n-out-of-m the PKG is capable of calculating. To minimize the
control for critical administrative functions and SHOULD maintain possibility of administrators doing this, a system
auditable logs of all security-critical events that occur in an implementing IBE SHOULD implement n-out-of-m control for
operating IBE system. critical administrative functions and SHOULD maintain
auditable logs of all security-critical events that occur in
an operating IBE system.
Similarly, we assume that users of an IBE system will behave Similarly, we assume that users of an IBE system will behave
responsibly, not sharing their authentication credentials with responsibly, not sharing their authentication credentials
others. Thus attacks that require such assumptions are outside the with others. Thus attacks that require such assumptions are
scope of this document. outside the scope of this document.
7.2. Attacks that are within the scope of this document 7.2. Attacks that are within the scope of this document
Attacks within the scope of this document are those that allow an Attacks within the scope of this document are those that
adversary to: allow an adversary to:
o passively monitor information transmitted between users of o passively monitor information transmitted between
an IBE system and the PPS and PKG users of an IBE system and the PPS and PKG
o masquerade as a PPS or PKG o masquerade as a PPS or PKG
o perform a DOS attack on a PPS or PKG o perform a DOS attack on a PPS or PKG
o easily guess an IBE user's authentication credential o easily guess an IBE user's authentication
credential
7.3. Attacks to which the protocols defined in this document are 7.3. Attacks to which the protocols defined in this document
susceptible are susceptible
All communications between users of an IBE system and the PPS or PKG All communications between users of an IBE system and the
are protected using TLS [TLS]. The IBE system defined in this PPS or PKG are protected using TLS [TLS]. The IBE system
document provides no additional security for the communications defined in this document provides no additional security for
between IBE users and the PPS or PKG. Therefore the described IBE the communications between IBE users and the PPS or PKG.
system is completely dependent on the TLS security mechanisms for Therefore the described IBE system is completely dependent
authentication of the PKG or PPS server and for confidentiality and on the TLS security mechanisms for authentication of the PKG
integrity of the communications. Should there be a compromise of the or PPS server and for confidentiality and integrity of the
TLS security mechanisms, the integrity of all communications between communications. Should there be a compromise of the TLS
an IBE user and the PPS or PKG will be suspect. 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 The protocols defined in this document do not explicitly
against an attacker masquerading as a legitimate IBE PPS or PKG. The defend against an attacker masquerading as a legitimate IBE
protocols rely on the server authentication mechanism of TLS [TLS]. PPS or PKG. The protocols rely on the server authentication
In addition to the TLS server authentication mechanism IBE client mechanism of TLS [TLS]. In addition to the TLS server
software can provide protection against this possibility by providing authentication mechanism IBE client software can provide
user interface capabilities that allows users to visually determine protection against this possibility by providing user
that a connection to PPS and PKG servers is legitimate. This interface capabilities that allows users to visually
additional capability can help ensure that users cannot easily be determine that a connection to PPS and PKG servers is
tricked into providing valid authorization credentials to an legitimate. This additional capability can help ensure that
attacker. users cannot easily be tricked into providing valid
authorization credentials to an attacker.
The protocols defined in this document are also vulnerable to attacks The protocols defined in this document are also vulnerable
against an IBE PPS or PKG. Denial of service attacks against either to attacks against an IBE PPS or PKG. Denial of service
component can result in users unable to encrypt or decrypt using IBE, attacks against either component can result in users unable
and users of an IBE system SHOULD take the appropriate to encrypt or decrypt using IBE, and users of an IBE system
countermeasures [RFC2827, RFC3882] that their use of IBE requires. SHOULD take the appropriate countermeasures [DOS, BGPDOS]
that their use of IBE requires.
The IBE user authentication method used by an IBE PKG SHOULD be of The IBE user authentication method used by an IBE PKG SHOULD
sufficient strength to prevent attackers from easily guessing the IBE be of sufficient strength to prevent attackers from easily
user's authentication credentials through trial and error. guessing the IBE user's authentication credentials through
trial and error.
8. IANA considerations 8. IANA considerations
All of the object identifiers used in this document were assigned by All of the object identifiers used in this document were
the National Institute of Standards and Technology (NIST), so no assigned by the National Institute of Standards and
further action by the IANA is necessary for this document. Technology (NIST), so no further action by the IANA is
necessary for this document.
9. References 9. References
9.1. Normative references 9.1. Normative references
[ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852,
Rules for Abstract Syntax Notation One (ASN.1)," 1998. July 2004.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering:
2002. Defeating Denial of Service Attacks which employ
IP Source Address Spoofing," RFC 2827, BCP 38, May
2000.
[DER] ITU-T Recommendation X.680: Information Technology - Abstract [KEYWORDS] S. Brander, "Key Words for Use in RFCs to
Syntax Notation One, 1997. Indicate Requirement Levels," BCP 14, RFC 2119,
March 1997.
[IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard [PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of
(IBCS) #1: Supersingular Curve Implementations of the BF Unicode for Internationalized Domain Names in
and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt. Applications (IDNA)," RFC 3492, March 2003.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based [TEXTMSG] D. Crocker, "Standard for the format of ARPA
Encryption Architecture," draft-ietf-ibearch-01.txt. internet text messages," RFC 2822, April 2001.
[KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate [TLS] T. Dierks and E. Rescorla, "The Transport Layer
Requirement Levels," BCP 14, RFC 2119, March 1997. Security (TLS) Protocol Version 1.1," RFC 4346,
April 2006.
[RFC822] D. Crocker, "Standard for the format of ARPA internet text 9.2. Informative references
messages," RFC 822, August 1982.
[RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering: [ASN1] CCITT, "Recommendation X.209: Specification of Basic
Defeating Denial of Service Attacks which employ IP Source Encoding Rules for Abstract Syntax Notation One
Address Spoofing," RFC 2827, BCP 38, May 2000. (ASN.1)," 1998.
[RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode [DER] ITU-T Recommendation X.680: Information Technology -
for Internationalized Domain Names in Applications (IDNA)," Abstract Syntax Notation One, 1997.
RFC 3492, March 2003.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography
Attacks," RFC 3882, September 2004. Standard (IBCS) #1: Supersingular Curve
Implementations of the BF and BB1 Cryptosystems,"
draft-martin-ibcs-06.txt.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
Protocol Version 1.1," RFC 4346, April 2006. based Encryption Architecture," draft-ietf-smime-
ibearch-04.txt.
9.2. Informative references [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
Service Attacks," RFC 3882, September 2004.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration [NIST] M. Souppaya, J. Wack and K. Kent, "Security
Checklist Program for IT Products - Guidance for Checklist Configuration Checklist Program for IT Products -
Users and Developers," NIST Special Publication SP 800-70, Guidance for Checklist Users and Developers," NIST
May 2005. Special Publication SP 800-70, May 2005.
Authors' Addresses Authors' Addresses
Luther Martin Luther Martin
Voltage Security Voltage Security
1070 Arastradero Rd Suite 100 1070 Arastradero Rd Suite 100
Palo Alto CA 94304 Palo Alto CA 94304
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
skipping to change at page 14, line 25 skipping to change at page 14, line 30
Mark Schertler Mark Schertler
Tumbleweed Communications Tumbleweed Communications
700 Saginaw Dr 700 Saginaw Dr
Redwood City CA 94063 Redwood City CA 94063
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 scope of any The IETF takes no position regarding the validity or scope
Intellectual Property Rights or other rights that might be claimed to of any Intellectual Property Rights or other rights that
pertain to the implementation or use of the technology described in might be claimed to pertain to the implementation or use of
this document or the extent to which any license under such rights the technology described in this document or the extent to
might or might not be available; nor does it represent that it has which any license under such rights might or might not be
made any independent effort to identify any such rights. Information available; nor does it represent that it has made any
on the procedures with respect to rights in RFC documents can be independent effort to identify any such rights. Information
found in BCP 78 and BCP 79. 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 Copies of IPR disclosures made to the IETF Secretariat and
assurances of licenses to be made available, or the result of an any assurances of licenses to be made available, or the
attempt made to obtain a general license or permission for the use of result of an attempt made to obtain a general license or
such proprietary rights by implementers or users of this permission for the use of such proprietary rights by
specification can be obtained from the IETF on-line IPR repository at implementers or users of this specification can be obtained
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 attention any The IETF invites any interested party to bring to its
copyrights, patents or patent applications, or other proprietary attention any copyrights, patents or patent applications, or
rights that may cover technology that may be required to implement other proprietary rights that may cover technology that may
this standard. Please address the information to the IETF at be required to implement this standard. Please address the
ietf-ipr@ietf.org. information to the IETF at ietf-ipr@ietf.org.
Disclaimer of validity Disclaimer of validity
This document and the information contained herein are provided on an This document and the information contained herein are
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS provided on an "AS IS" basis and THE CONTRIBUTOR, THE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and
contained in BCP 78, and except as set forth therein, the authors restrictions contained in BCP 78, and except as set forth
retain all their rights. therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by
Internet Society. the Internet Society.
 End of changes. 96 change blocks. 
331 lines changed or deleted 391 lines changed or added

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