draft-ietf-smime-bfibecms-03.txt   draft-ietf-smime-bfibecms-04.txt 
L. Martin L. Martin
S/MIME Working Group M. Schertler S/MIME Working Group Voltage Security
Internet Draft Voltage Security Internet Draft Mark Schertler
Expires: December 2007 Tumbleweed Communications
Using the Boneh-Franklin and Boneh-Boyen identity-based encryption Using the Boneh-Franklin and Boneh-Boyen identity-based encryption
algorithms with the Cryptographic Message Syntax (CMS) algorithms with the Cryptographic Message Syntax (CMS)
<draft-ietf-smime-bfibecms-03.txt> <draft-ietf-smime-bfibecms-04.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 that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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 Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 39
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-Franklin
(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in (BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in
the Cryptographic Message Syntax (CMS) to encrypt content encryption the Cryptographic Message Syntax (CMS) to encrypt content-encryption
keys. Object identifiers and the convention for encoding a keys. Object identifiers and the convention for encoding a
recipient's identity are also defined. 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...........................6
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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 the IBE
public key that was used to encrypt the content-encryption key. This public key that was used to encrypt the content-encryption key. This
MUST be an IBEIdentityInfo type. This recipientIdentity is used to MUST be an IBEIdentityInfo type. This recipientIdentity is used to
calculate IBE public and private keys as described in [IBCS]. calculate IBE public and private keys as described in [IBCS].
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district UTF8STRING, district UTF8String,
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 to
construct the URI for the location of the necessary IBE public construct the URI for the location of the necessary IBE public
parameters. The construction and use of this URI is defined in [IBE]. parameters. The construction and use of this URI is defined in [IBE].
skipping to change at page 5, line 17 skipping to change at page 5, line 17
set to cmsIdentityOID to indicate that identityData contains an set to cmsIdentityOID to indicate that identityData contains an
EmailIdentitySchema type. 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) rfc822email(1)
} }
The identityData field contains the identify information for the The identityData field contains the identify information for the
recipient. If the contents of the field is an ASN.1 structure, the recipient. If the contents of the field is an ASN.1 structure, the
structure MUST be DER encoded before placing it in the OCTET STRING. structure MUST be DER encoded [DER] before placing it in the OCTET
STRING.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING, rfc822Email UTF8String,
time GeneralizedTime time GeneralizedTime
} }
The rfc822Email is the e-mail address of the recipient in the format The rfc822Email is the e-mail address of the recipient in the format
defined by [RFC822]. E-mail addresses that contain non-ASCII defined by [RFC822].
characters MUST be encoded using punycode [RFC3492].
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 wants to
let the recipient decrypt the message, so it may be called the "not- let the recipient decrypt the message, so it may be called the "not-
before" time. This is usually set to the time when the message is before" time. This is usually set to the time when the message is
encrypted, but MAY be set to a future time. UTC time values are encrypted, but MAY be set to a future time. UTC time values are
expressed to the nearest second. 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 this time
rounded to a time interval to create a key lifetime. A key lifetime rounded to a time interval to create a key lifetime. A key lifetime
reduces the number of IBE private keys that a recipient needs to reduces the number of IBE private keys that a recipient needs to
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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 algorithm is
used to encrypt the CEK. 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-encryption
keys performs the following steps: 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 subsequent
steps in accordance with his local security policy. He then steps in accordance with his local security policy. He then
determines the URI where the public parameters can be obtained using determines the URI where the public parameters can be obtained using
the process described in [IBE]. This information MUST be encoded in the process described in [IBE]. This information MUST be encoded in
the IBEIdentityInfo as described in Section 2. 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 their
appropriate values as described in Section 2. 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] using this
IBEIdentityInfo as the identity information. 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 content-
encryption key (CEK), using the algorithms that are defined in encryption key (CEK), using the algorithms that are defined in
[IBCS]. [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 set to the
appropriate OID for the IBE algorithm that was used (see Section 3). appropriate OID for the IBE algorithm that was used (see Section 3).
5. Processing by the receiver 5. Processing by the receiver
skipping to change at page 9, line 8 skipping to change at page 9, line 8
5. Obtains the IBE private key needed to decrypt the encrypted CEK 5. Obtains the IBE private key needed to decrypt the encrypted CEK
using the process defined in [IBE]. 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 Step 4
using the algorithms described in [IBCS]. 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) organization(1)identicrypt(114334) ibcs(1) cms(4)
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)
skipping to change at page 9, line 33 skipping to change at page 9, line 33
IBERecipientInfo ::= SEQUENCE { IBERecipientInfo ::= SEQUENCE {
cmsVersion INTEGER { v3(3) }, cmsVersion INTEGER { v3(3) },
keyFetchMethod OBJECT IDENTIFIER, keyFetchMethod OBJECT IDENTIFIER,
recipientIdentity IBEIdentityInfo, recipientIdentity IBEIdentityInfo,
serverInfo SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE (1..MAX) OF OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district UTF8STRING, district UTF8String,
serial INTEGER, serial INTEGER,
identitySchema OBJECT IDENTIFIER, identitySchema OBJECT IDENTIFIER,
identityData OCTET STRING identityData OCTET STRING
} }
OIDValuePairs ::= SEQUENCE { OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER, fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING fieldData OCTET STRING
} }
EncryptedKey ::= OCTET STRING
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8STRING, rfc822Email UTF8String,
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) rfc822email(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)
skipping to change at page 13, line 15 skipping to change at page 13, line 15
9. References 9. References
9.1. Normative references 9.1. Normative references
[ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding [ASN1] CCITT, "Recommendation X.209: Specification of Basic Encoding
Rules for Abstract Syntax Notation One (ASN.1)," 1998. Rules for Abstract Syntax Notation One (ASN.1)," 1998.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3369, August
2002. 2002.
[DER] ITU-T Recommendation X.680: Information Technology - Abstract
Syntax Notation One, 1997.
[IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard [IBCS] X. Boyen, L. Martin, "Identity-based Cryptography Standard
(IBCS) #1: Supersingular Curve Implementations of the BF (IBCS) #1: Supersingular Curve Implementations of the BF
and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt. and BB1 Cryptosystems," draft-ieft-martin-ibcs-03.txt.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-based
Encryption Architecture," draft-ietf-ibearch-01.txt. Encryption Architecture," draft-ietf-ibearch-01.txt.
[KEYWORDS] S. Brander, "Key Words for Use in RFCs to Indicate [KEYWORDS] 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.
[RFC822] D. Crocker, "Standard for the format of ARPA internet text [RFC822] D. Crocker, "Standard for the format of ARPA internet text
messages," RFC 822, August 1982. messages," RFC 822, August 1982.
[RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering: [RFC2827] P. Ferguson and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing," RFC 2827, BCP 38, May 2000. Address Spoofing," RFC 2827, BCP 38, May 2000.
[RFC3492] A. Costello, "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications (IDNA),"
RFC 3492, March 2003.
[RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service [RFC3882] D. Turk, "Configuring BGP to Block Denial-of-Service
Attacks," RFC 3882, September 2004. Attacks," RFC 3882, September 2004.
[TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) [TLS] T. Dierks and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1," RFC 4346, April 2006. Protocol Version 1.1," RFC 4346, April 2006.
9.2. Informative references 9.2. Informative references
[NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration [NIST] M. Souppaya, J. Wack and K. Kent, "Security Configuration
Checklist Program for IT Products - Guidance for Checklist Checklist Program for IT Products - Guidance for Checklist
skipping to change at page 14, line 16 skipping to change at page 14, line 16
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
Mark Schertler Mark Schertler
Voltage Security Tumbleweed Communications
1070 Arastradero Rd Suite 100 700 Saginaw Dr
Palo Alto CA 94304 Redwood City CA 94063
Phone: +1 650 543 1280 Phone: +1 650 216 2039
Email: mark@voltage.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 of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 17 change blocks. 
24 lines changed or deleted 26 lines changed or added

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