draft-ietf-smime-bfibecms-08.txt   draft-ietf-smime-bfibecms-09.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: May 2008 Tumbleweed Communications Intended status: Standards Track Tumbleweed Communications
November 2007 Using the Boneh-Franklin and Boneh-Boyen Identity-based
Encryption Algorithms with the Cryptographic Message Syntax
Using the Boneh-Franklin and Boneh-Boyen identity-based
encryption algorithms with the Cryptographic Message Syntax
(CMS) (CMS)
<draft-ietf-smime-bfibecms-08.txt> <draft-ietf-smime-bfibecms-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 11 skipping to change at page 2, line 11
(CMS) to encrypt content-encryption keys. Object identifiers (CMS) to encrypt content-encryption keys. Object identifiers
and the convention for encoding a recipient's identity are and the convention for encoding a recipient's identity are
also defined. 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.........................4 2. Using identity-based encryption.........................4
3. Key encryption algorithm identifiers....................7 3. Key encryption algorithm identifiers....................8
4. Processing by the sender................................8 4. Processing by the sender................................8
5. Processing by the receiver..............................8 5. Processing by the receiver..............................9
6. ASN.1 module............................................9 6. ASN.1 module............................................9
7. Security considerations................................11 7. Security considerations................................11
7.1. Attacks that are outside the scope of this 7.1. Attacks that are outside the scope of this
document...............................................11 document...............................................11
7.2. Attacks that are within the scope of this 7.2. Attacks that are within the scope of this
document...............................................12 document...............................................12
7.3. Attacks to which the protocols defined in this 7.3. Attacks to which the protocols defined in this
document are susceptible...............................12 document are susceptible...............................12
8. IANA considerations....................................13 8. IANA considerations....................................13
9. References.............................................14 9. References.............................................14
skipping to change at page 3, line 19 skipping to change at page 3, line 19
message recipient. message recipient.
CMS values and identity objects are defined using ASN.1 CMS values and identity objects are defined using ASN.1
[ASN1]. [ASN1].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as and "OPTIONAL" in this document are to be interpreted as
described in RFC-2119 [KEYWORDS]. described in RFC 2119 [KEYWORDS].
1.2. IBE overview 1.2. IBE overview
In addition to the client components that are described in In addition to the client components that are described in
this document, the following additional components are this document, the following additional components are
required for a 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, cryptographic material, known as a master secret,
for generating an individual's IBE private key. A for generating an individual's IBE private key. A
skipping to change at page 4, line 16 skipping to change at page 4, line 16
To use IBE, the ori field in RecipientInfo MUST be used. The To use IBE, the ori field in RecipientInfo MUST be used. The
fields are set as follows: oriType is set to ibeORIType; fields are set as follows: oriType is set to ibeORIType;
oriValue is set to 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 ibeORIType defines the object identifier (OID) that
indicates that the subsequent ibeORIValue is the information indicates that the subsequent ibeORIValue is the information
necessary to decrypt the message using IBE. This field MUST necessary to decrypt the message using IBE. This field MUST
be set to be set to the following:
ibeORIType OBJECT IDENTIFIER ::= { ibeORIType OBJECT IDENTIFIER ::= {
joint-iso-itu(2) country(16) us(840) joint-iso-itu(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
ibcs(1) cms(4) ori-oid(1) ibcs(1) cms(4) ori-oid(1)
} }
ibeORIValue defines the identity that was used in the IBE ibeORIValue defines the identity that was used in the IBE
algorithm to encrypt the CEK. This is an IBERecipientInfo algorithm to encrypt the CEK. This is an IBERecipientInfo
type. type, which is defined as follows:
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 MUST be set as follows.
The cmsVersion MUST be set to 3. The cmsVersion MUST be set to 3.
The keyFetchMethod is the OID that defines the method of The keyFetchMethod is the OID that defines the method of
retrieving the private key that the recipient MUST use. How retrieving the private key that the recipient MUST use. How
to retrieve an IBE private key using the steps defined in to retrieve an IBE private key using the steps defined in
[IBE] is defined by the keyFetchMethod OID. The method for [IBE] is defined by the keyFetchMethod OID. The method for
retrieving private keys that is specified in [IBE] is retrieving private keys that is specified in [IBE] is
defined by cmsPPSOID. defined by cmsPPSOID, which is defined to be the following:
cmsPPSOID OBJECT IDENTIFIER ::= { cmsPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) pps-schemas(3) ic-schemas(1) pps-uri(1)
} }
The recipientIdentity is the data that was used to calculate The recipientIdentity is the data that was used to calculate
the IBE public key that was used to encrypt the content- the IBE public key that was used to encrypt the content-
encryption key. This MUST be an IBEIdentityInfo type. This encryption key. This recipientIdentity is used to calculate
recipientIdentity is used to calculate IBE public and IBE public and private keys as described in [IBCS]. This
private keys as described in [IBCS]. MUST be an IBEIdentityInfo type, which is defined as
follows:
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 The district and serial are unique identifiers that are used
to construct the URI for the location of the necessary IBE to construct the URI for the location of the necessary IBE
public parameters. The construction and use of this URI is public parameters. The construction and use of this URI is
defined in [IBE]. defined in [IBE]. Internationalized Resource Identifiers
(IRIs) MUST be handled according to the procedures specified
in Section 7.4 of [PKIX].
The identitySchema defines the format that is used to encode The identitySchema defines the format that is used to encode
the information that defines the identity of the recipient. the information that defines the identity of the recipient.
This MUST be set to cmsIdentityOID to indicate that This MUST be set to cmsIdentityOID to indicate that
identityData contains an EmailIdentitySchema type. identityData contains an EmailIdentitySchema type. The value
of cmsIdentityOID is the following:
cmsIdentityOID OBJECT IDENTIFIER ::= { cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) RFC822email(1) keyschemas(2) icschemas(1) rfc822Name(1)
} }
The identityData field contains the identify information for The identityData field contains the identify information for
the recipient. If the contents of the field is an ASN.1 the recipient, the contents of which is an ASN.1 structure
structure, the structure MUST be DER encoded [DER] before which MUST be DER encoded [DER] before placing it in the
placing it in the OCTET STRING. OCTET STRING.
If identitySchema is set to the cmsIdentityOID OBJECT
IDENTIFIER, the identityData MUST be an EmailIdentitySchema
type, which is defined as follows:
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
RFC822Email IA5String, rfc822Name IA5String,
time GeneralizedTime time GeneralizedTime
} }
The RFC822email is the e-mail address of the recipient in The rfc822Name field is the e-mail address of the recipient
the format defined by [TEXTMSG]. E-mail addresses that in the format defined in Section 4.2.1.6 of [PKIX] for the
contain non-ASCII characters MUST be encoded using punycode rfc822Name subjectAltName variant. Rules for encoding
[PUNYCODE]. Internet mail addresses that include internationalized
domain names are specified in Section 7.5 of [PKIX].
The value of "time" is the UTC time after which the sender The value of the time field is the UTC time after which the
wants to let the recipient decrypt the message, so it may be sender wants to let the recipient decrypt the message, so it
called the "not-before" time. This is usually set to the may be called the "not-before" time. This is usually set to
time when the message is encrypted, but MAY be set to a the time when the message is encrypted, but MAY be set to a
future time. UTC time values are expressed to the nearest future time. The value of "time" MUST be expressed in
second. Greenwich Mean Time(Zulu), MUST include seconds (i.e. times
are always YYYYMMDDHHMMSSZ), even where the number of
seconds is equal to zero and MUST be expressed to the
nearest second.
The sender of an IBE-encrypted message may want to express The sender of an IBE-encrypted message may want to express
this time rounded to a time interval to create a key this time rounded to a time interval to create a key
lifetime. A key lifetime reduces the number of IBE private lifetime. A key lifetime reduces the number of IBE private
keys that a recipient needs to retrieve, but still forces keys that a recipient needs to retrieve, but still forces
the IBE user to periodically re-authenticate. Based on the the IBE user to periodically re-authenticate. Based on the
time interval chosen a recipient would only have to retrieve time interval chosen a recipient would only have to retrieve
a new IBE key once during the interval. To do this, follow a new IBE key once during the interval. To do this, follow
the following steps. Let "time-interval" be the number of the following steps. Let "time-interval" be the number of
seconds in this larger time interval. seconds in this larger time interval.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
seconds since January 1, 1970. Call this seconds since January 1, 1970. Call this
"total-time." "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 An example of this algorithm for computing a one week time
interval is as follows. interval is as follows.
1. Say the GeneralizedTime is 20020401000000Z. 1. Suppose that 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 4. This gives the GeneralizedTime form of the
form of the reduced-time of 20020328000000Z. reduced-time of 20020328000000Z.
When issuing IBE private keys, a PKG SHOULD NOT issue them When issuing IBE private keys, a PKG SHOULD NOT issue them
too far into the future. This restriction is to prevent an too far into the future. This restriction is to prevent an
adversary who obtains an IBE user's authentication adversary who obtains an IBE user's authentication
credentials from requesting private keys far into the future credentials from requesting private keys far into the future
and therefore negating the periodic IBE user re- and therefore negating the periodic IBE user re-
authentication that key lifetime provides. For example if a authentication that key lifetime provides. For example if a
one week period is chosen for the key lifetime, then IBE one week period is chosen for the key lifetime, then IBE
private keys should not be issued more than 1 week in private keys should not be issued more than 1 week in
advance. Otherwise once an adversary gains access to the PKG advance. Otherwise once an adversary gains access to the PKG
via the stolen IBE user credentials they can request all via the stolen IBE user credentials they can request all
future keys and negate the IBE user authentication future keys and negate the IBE user authentication
restraints in place. restraints in place.
The serverInfo is an optional series of OID-value pairs that The serverInfo is an optional sequence of OID-value pairs
can be used to convey any other information that might be that are defined to be the following:
used by a PKG. Examples of such information could include
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
These can be used to convey any other information that might
be used by a PKG. Examples of such information could include
the user interface that the recipient will experience. the user interface that the recipient will experience.
Differences in the user interface could include localization Differences in the user interface could include localization
information or commercial branding information. information or commercial branding information.
OIDValuePairs ::= SEQUENCE {
fieldID OBJECT IDENTIFIER,
fieldData OCTET STRING
}
The encryptedKey is the result of encrypting the CEK with an The encryptedKey is the result of encrypting the CEK with an
IBE 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 The BF and BB1 algorithms as defined in [IBCS] have the
following object identifiers. These object identifiers are following object identifiers. These object identifiers are
also defined in the ASN.1 module in [IBCS]. also defined in the ASN.1 module in [IBCS].
bf OBJECT IDENTIFIER ::= { bf OBJECT IDENTIFIER ::= {
skipping to change at page 10, line 48 skipping to change at page 10, line 48
} }
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, rfc822Name IA5String,
time GeneralizedTime time GeneralizedTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { cmsIdentityOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
keyschemas(2) icschemas(1) RFC822email(1) keyschemas(2) icschemas(1) RFC2821email(1)
} }
cmsPPSOID OBJECT IDENTIFIER ::= { cmsPPSOID OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) organization(1) identicrypt(114334)
pps-schemas(3) ic-schemas(1) pps-uri(1) pps-schemas(3) ic-schemas(1) pps-uri(1)
} }
END END
skipping to change at page 13, line 36 skipping to change at page 13, line 36
SHOULD take the appropriate countermeasures [DOS, BGPDOS] SHOULD take the appropriate countermeasures [DOS, BGPDOS]
that their use of IBE requires. that their use of IBE requires.
The IBE user authentication method used by an IBE PKG SHOULD The IBE user authentication method used by an IBE PKG SHOULD
be of sufficient strength to prevent attackers from easily be of sufficient strength to prevent attackers from easily
guessing the IBE user's authentication credentials through guessing the IBE user's authentication credentials through
trial and error. trial and error.
8. IANA considerations 8. IANA considerations
All of the object identifiers used in this document were No further action by the IANA is necessary for this
assigned by the National Institute of Standards and 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] ITU-T Recommendation X.680: Information Technology - [ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997. Abstract Syntax Notation One (ASN.1):
Specification of Basic Notation," July 2002.
[CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852, [CMS] R. Housley, "Cryptographic Message Syntax," RFC 3852,
July 2004. July 2004.
[DER] CCITT, "Recommendation X.209: Specification of Basic [DER] ITU-T Recommendation X.690: OSI Networking and System
Encoding Rules for Abstract Syntax Notation One Aspects: Abstract Syntax Notation One (ASN.1),
(ASN.1)," 1998. July 2002.
[DOS] P. Ferguson and D. Senie, "Network Ingress Filtering: [DOS] P. Ferguson and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ Defeating Denial of Service Attacks which employ
IP Source Address Spoofing," RFC 2827, BCP 38, May IP Source Address Spoofing," RFC 2827, BCP 38, May
2000. 2000.
[IBCS] X. Boyen, L. Martin, "Identity-based Cryptography [IBCS] X. Boyen and L. Martin, "Identity-based Cryptography
Standard (IBCS) #1: Supersingular Curve Standard (IBCS) #1: Supersingular Curve
Implementations of the BF and BB1 Cryptosystems," Implementations of the BF and BB1 Cryptosystems,"
draft-martin-ibcs-06.txt. RFC 5091, December 2007.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity- [IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
based Encryption Architecture," draft-ietf-smime- based Encryption Architecture," draft-ietf-smime-
ibearch-08.txt. ibearch-06.txt.
[KEYWORDS] S. Brander, "Key Words for Use in RFCs to [KEYWORDS] S. Brander, "Key Words for Use in RFCs to
Indicate Requirement Levels," BCP 14, RFC 2119, Indicate Requirement Levels," BCP 14, RFC 2119,
March 1997. March 1997.
[TEXTMSG] D. Crocker, "Standard for the format of ARPA [PKIX] D. Cooper, et al., "Internet X.509 Public Key
internet text messages," RFC 2822, April 2001. Infrastructure Certificate and Certificate
Revocation List (CRL) Profile," RFC 5280, May
[PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of 2008.
Unicode for Internationalized Domain Names in
Applications (IDNA)," RFC 3492, March 2003.
[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, Security (TLS) Protocol Version 1.1," RFC 4346,
April 2006. April 2006.
9.2. Informative references 9.2. Informative references
[BGPDOS] D. Turk, "Configuring BGP to Block Denial-of- [BGPDOS] D. Turk, "Configuring BGP to Block Denial-of-
Service Attacks," RFC 3882, September 2004. Service Attacks," RFC 3882, September 2004.
skipping to change at page 16, line 27 skipping to change at page 16, line 25
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
A PARTICULAR PURPOSE. A PARTICULAR PURPOSE.
Copyright statement Copyright statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set forth restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights. therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by Funding for the RFC Editor function is currently provided by
the Internet Society. the Internet Society.
 End of changes. 31 change blocks. 
59 lines changed or deleted 78 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/