draft-ietf-smime-bfibecms-04.txt   draft-ietf-smime-bfibecms-05.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: December 2007 Tumbleweed Communications Expires: February 2008 Tumbleweed Communications
August 2007
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-04.txt> <draft-ietf-smime-bfibecms-05.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 2, line 26 skipping to change at page 2, line 26
7.1. Attacks that are outside the scope of this document......10 7.1. Attacks that are outside the scope of this document......10
7.2. Attacks that are within the scope of this document.......11 7.2. Attacks that are within the scope of this document.......11
7.3. Attacks to which the protocols defined in this document are 7.3. Attacks to which the protocols defined in this document are
susceptible...................................................11 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...........................................14 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 [BF] and
Boneh-Boyen [BB1] identity-based encryption (IBE) public-key Boneh-Boyen [BB1] identity-based encryption (IBE) public-key
algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a algorithms in the Cryptographic Message Syntax (CMS) [CMS]. IBE is a
public key technology for encrypting content-encryption keys (CEKs) public key technology for encrypting content-encryption keys (CEKs)
that can be implemented within the framework of the CMS: the that can be implemented within the framework of the CMS: the
skipping to change at page 4, line 15 skipping to change at page 4, line 15
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 algorithm
to encrypt the CEK. This is an IBERecipientInfo type. 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 (1..MAX) OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE SIZE (1..MAX) OF
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 retrieving
the private key that the recipient MUST use. How to retrieve an IBE the private key that the recipient MUST use. How to retrieve an IBE
private key using the steps defined in [IBE] is defined by the private key using the steps defined in [IBE] is defined by the
skipping to change at page 4, line 40 skipping to change at page 4, line 41
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 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 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 21 skipping to change at page 5, line 25
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 [DER] before placing it in the OCTET structure MUST be DER encoded [DER] before placing it in the OCTET
STRING. STRING.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8String, rfc822Email IA5String,
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]. defined by [RFC822]. E-mail addresses that contain non-ASCII
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 9, line 28 skipping to change at page 9, line 28
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 (1..MAX) OF OIDValuePairs OPTIONAL, serverInfo SEQUENCE SIZE (1..MAX) OF
OIDValuePairs OPTIONAL,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district UTF8String, district IA5String,
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 EncryptedKey ::= OCTET STRING
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822Email UTF8String, rfc822Email 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) 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)
ic-schemas(1) pps-uri(1) ic-schemas(1) pps-uri(1)
} }
skipping to change at page 13, line 35 skipping to change at page 13, line 35
[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
 End of changes. 12 change blocks. 
11 lines changed or deleted 19 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/