draft-ietf-smime-bfibecms-07.txt   draft-ietf-smime-bfibecms-08.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: March 2008 Tumbleweed Communications Expires: May 2008 Tumbleweed Communications
September 2007 November 2007
Using the Boneh-Franklin and Boneh-Boyen identity-based Using the Boneh-Franklin and Boneh-Boyen identity-based
encryption algorithms with the Cryptographic Message Syntax encryption algorithms with the Cryptographic Message Syntax
(CMS) (CMS)
<draft-ietf-smime-bfibecms-07.txt> <draft-ietf-smime-bfibecms-08.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 10 skipping to change at page 2, line 10
encryption algorithms in the Cryptographic Message Syntax encryption algorithms in the Cryptographic Message Syntax
(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.........................3 2. Using identity-based encryption.........................4
3. Key encryption algorithm identifiers....................7 3. Key encryption algorithm identifiers....................7
4. Processing by the sender................................7 4. Processing by the sender................................8
5. Processing by the receiver..............................8 5. Processing by the receiver..............................8
6. ASN.1 module............................................9 6. ASN.1 module............................................9
7. Security considerations................................10 7. Security considerations................................11
7.1. Attacks that are outside the scope of this document10 7.1. Attacks that are outside the scope of this
7.2. Attacks that are within the scope of this document11 document...............................................11
7.2. Attacks that are within the scope of this
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...............................11 document are susceptible...............................12
8. IANA considerations....................................12 8. IANA considerations....................................13
9. References.............................................13 9. References.............................................14
9.1. Normative references..............................13 9.1. Normative references..............................14
9.2. Informative references............................13 9.2. Informative references............................14
Authors' Addresses........................................14 Authors' Addresses........................................15
Intellectual property statement...........................14 Intellectual property statement...........................15
Disclaimer of validity....................................15 Disclaimer of validity....................................16
Copyright statement.......................................15 Copyright statement.......................................16
Acknowledgment............................................15 Acknowledgment............................................16
1. Introduction 1. Introduction
This document defines the way to use the Boneh-Franklin This document defines the way to use the Boneh-Franklin
[IBCS] and Boneh-Boyen [IBCS] identity-based encryption [IBCS] and Boneh-Boyen [IBCS] identity-based encryption
(IBE) public-key algorithms in the Cryptographic Message (IBE) public-key algorithms in the Cryptographic Message
Syntax (CMS) [CMS]. IBE is a public key technology for Syntax (CMS) [CMS]. IBE is a public key technology for
encrypting content-encryption keys (CEKs) that can be encrypting content-encryption keys (CEKs) that can be
implemented within the framework of the CMS: the recipient's implemented within the framework of the CMS: the recipient's
identity is incorporated into the EnvelopedData CMS content identity is incorporated into the EnvelopedData CMS content
skipping to change at page 3, line 23 skipping to change at page 3, line 25
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
PKG accepts an IBE user's private key request and, PKG accepts an IBE user's private key request and,
after successfully authenticating them in some way, after successfully authenticating them in some way,
returns their IBE private key. returns their IBE private key.
o A Public Parameter Server (PPS). IBE System o A Public Parameter Server (PPS). IBE System
Parameters include publicly sharable cryptographic Parameters include publicly sharable cryptographic
material, known as IBE public parameters, and material, known as IBE public parameters, and
policy information for the PKG. A PPS provides a policy information for the PKG. A PPS provides a
well-known location for secure distribution of IBE well-known location for distribution of IBE public
public parameters and policy information for the parameters and policy information for the IBE PKG.
IBE PKG.
The interaction of senders and receivers of IBE-encrypted The interaction of senders and receivers of IBE-encrypted
messages are described in [IBE]. messages are described in [IBE]. All communications
between users of an IBE system and the PPS or PKG MUST be
protected using TLS [TLS] as described in [IBE]. This
provides confidentiality and integrity of all information
that is delivered to users as well as authentication of
the PPS and PKG.
2. Using identity-based encryption 2. Using identity-based encryption
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
ibeORIType OBJECT IDENTIFIER ::= { joint-iso-itu(2) ibeORIType OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) ibcs(1) organization(1) identicrypt(114334)
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.
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
skipping to change at page 4, line 39 skipping to change at page 5, line 5
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.
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) cmsPPSOID OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu-t(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) pps-schemas(3) organization(1) identicrypt(114334)
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 MUST be an IBEIdentityInfo type. This
recipientIdentity is used to calculate IBE public and recipientIdentity is used to calculate IBE public and
private keys as described in [IBCS]. private keys as described in [IBCS].
IBEIdentityInfo ::= SEQUENCE { IBEIdentityInfo ::= SEQUENCE {
district IA5String, district IA5String,
skipping to change at page 5, line 24 skipping to change at page 5, line 36
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].
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.
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) cmsIdentityOID OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu-t(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) keyschemas(2) organization(1) identicrypt(114334)
icschemas(1) rfc822email(1) keyschemas(2) icschemas(1) RFC822email(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. If the contents of the field is an ASN.1
structure, the structure MUST be DER encoded [DER] before structure, the structure MUST be DER encoded [DER] before
placing it in the OCTET STRING. placing it in the OCTET STRING.
EmailIdentitySchema ::= SEQUENCE { EmailIdentitySchema ::= SEQUENCE {
rfc822email IA5String, RFC822Email IA5String,
time GeneralizedTime time GeneralizedTime
} }
The rfc822email is the e-mail address of the recipient in The RFC822email is the e-mail address of the recipient in
the format defined by [TEXTMSG]. E-mail addresses that the format defined by [TEXTMSG]. E-mail addresses that
contain non-ASCII characters MUST be encoded using punycode contain non-ASCII characters MUST be encoded using punycode
[PUNYCODE]. [PUNYCODE].
The value of "time" is the UTC time after which the sender The value of "time" is the UTC time after which the sender
wants to let the recipient decrypt the message, so it may be wants to let the recipient decrypt the message, so it may be
called the "not-before" time. This is usually set to the called the "not-before" time. This is usually set to the
time when the message is encrypted, but MAY be set to a time when the message is encrypted, but MAY be set to a
future time. UTC time values are expressed to the nearest future time. UTC time values are expressed to the nearest
second. second.
skipping to change at page 6, line 17 skipping to change at page 6, line 34
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.
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 2. Convert this GeneralizedTime into the number of
seconds seconds since January 1, 1970. Call this
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. 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 4. This gives the reduced-time GeneralizedTime
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
skipping to change at page 7, line 17 skipping to change at page 7, line 42
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 ::= { joint-iso-itu-t(2) country(16) bf OBJECT IDENTIFIER ::= {
us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334)
ibe-algorithms(2) bf(1) } ibcs(1) ibcs1(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 keyEncryptionAlgorithm field in the CMS when the BF
algorithm is used to encrypt the CEK. algorithm is used to encrypt the CEK.
bb1 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) bb1 OBJECT IDENTIFIER ::= {
us(840) joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334) ibcs(1) ibcs1(1) organization(1) identicrypt(114334)
ibe-algorithms(2) bb1(2) } ibcs(1) ibcs1(1) 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 keyEncryptionAlgorithm field in the CMS when the BB1
algorithm is 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- The sender of a message that uses IBE to encrypt content-
encryption keys performs the following steps: encryption keys performs the following steps:
skipping to change at page 9, line 7 skipping to change at page 9, line 24
[IBE]. [IBE].
5. Obtains the IBE private key needed to decrypt the 5. Obtains the IBE private key needed to decrypt the
encrypted CEK 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 6. Decrypts the CEK using the IBE private key obtained in
Step 4 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) The following ASN.1 module summarizes the ASN.1 definitions
organization(1) identicrypt(114334) ibcs(1) cms(4) discussed in this document.
module(5) version(1)
IBECMS-module {
joint-iso-itu-t(2) country(16) us(840)
organization(1) identicrypt(114334)
ibcs(1) cms(4) 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) ibeORIType OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu-t(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) ibcs(1) organization(1) identicrypt(114334)
cms(4) ori-oid(1) ibcs(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,
encryptedKey EncryptedKey encryptedKey EncryptedKey
} }
skipping to change at page 9, line 49 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, RFC822Email IA5String,
time GeneralizedTime time GeneralizedTime
} }
cmsIdentityOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) cmsIdentityOID OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu-t(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) keyschemas(2) organization(1) identicrypt(114334)
icschemas(1) rfc822email(1) keyschemas(2) icschemas(1) RFC822email(1)
} }
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) cmsPPSOID OBJECT IDENTIFIER ::= {
country(16) joint-iso-itu-t(2) country(16) us(840)
us(840) organization(1) identicrypt(114334) pps-schemas(3) organization(1) identicrypt(114334)
ic-schemas(1) pps-uri(1) pps-schemas(3) 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 This document is based on [CMS] and [IBCS], and the relevant
security 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
skipping to change at page 10, line 46 skipping to change at page 11, line 46
master secret), will defeat the security of an IBE system. master secret), will defeat the security of an IBE system.
In particular, if the cryptographic material is compromised In particular, if the cryptographic material is compromised
the adversary will have the ability to recreate any user's the adversary will have the ability to recreate any user's
private key and therefore decrypt all messages protected private key and therefore decrypt all messages protected
with the corresponding public key. To address this concern, with the corresponding public key. To address this concern,
it is highly RECOMMENDED that best practices for physical it is highly RECOMMENDED that best practices for physical
and operational security for PPS and PKG servers be followed and operational security for PPS and PKG servers be followed
and that these servers be configured (sometimes known as and that these servers be configured (sometimes known as
hardened) in accordance with best current practices [NIST]. hardened) in accordance with best current practices [NIST].
An IBE system SHOULD be operated in an environment where An IBE system SHOULD be operated in an environment where
illicit access to the PPS and PKG is infeasible for illicit access to the PKG or the ability to modify the
information distributed by the PPS is infeasible for
attackers to obtain. attackers to obtain.
Attacks that require administrative or IBE user equivalent Attacks that require administrative or IBE user equivalent
access to machines used by either the client or the server access to machines used by either the client or the server
components defined in this document are also outside the components defined in this document are also outside the
scope of this document. scope of this document.
We also assume that all administrators of a system We also assume that all administrators of a system
implementing the protocols that are defined in this document implementing the protocols that are defined in this document
are trustworthy and will not abuse their authority to bypass are trustworthy and will not abuse their authority to bypass
skipping to change at page 13, line 9 skipping to change at page 14, line 9
All of the object identifiers used in this document were All of the object identifiers used in this document were
assigned by the National Institute of Standards and assigned by the National Institute of Standards and
Technology (NIST), so no further action by the IANA is Technology (NIST), so no further action by the IANA is
necessary for this document. necessary for this document.
9. References 9. References
9.1. Normative references 9.1. Normative references
[ASN1] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997.
[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
Encoding Rules for Abstract Syntax Notation One
(ASN.1)," 1998.
[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
Standard (IBCS) #1: Supersingular Curve
Implementations of the BF and BB1 Cryptosystems,"
draft-martin-ibcs-06.txt.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
based Encryption Architecture," draft-ietf-smime-
ibearch-08.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
internet text messages," RFC 2822, April 2001.
[PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of [PUNYCODE] A. Costello, "Punycode: A Bootstring encoding of
Unicode for Internationalized Domain Names in Unicode for Internationalized Domain Names in
Applications (IDNA)," RFC 3492, March 2003. Applications (IDNA)," RFC 3492, March 2003.
[TEXTMSG] D. Crocker, "Standard for the format of ARPA
internet text messages," RFC 2822, April 2001.
[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
[ASN1] CCITT, "Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One
(ASN.1)," 1998.
[DER] ITU-T Recommendation X.680: Information Technology -
Abstract Syntax Notation One, 1997.
[IBCS] X. Boyen, L. Martin, "Identity-based Cryptography
Standard (IBCS) #1: Supersingular Curve
Implementations of the BF and BB1 Cryptosystems,"
draft-martin-ibcs-06.txt.
[IBE] G. Appenzeller, L. Martin and M. Schertler, "Identity-
based Encryption Architecture," draft-ietf-smime-
ibearch-04.txt.
[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.
[NIST] M. Souppaya, J. Wack and K. Kent, "Security [NIST] M. Souppaya, J. Wack and K. Kent, "Security
Configuration Checklist Program for IT Products - Configuration Checklist Program for IT Products -
Guidance for Checklist Users and Developers," NIST Guidance for Checklist Users and Developers," NIST
Special Publication SP 800-70, 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
USA
Phone: +1 650 543 1280 Phone: +1 650 543 1280
Email: martin@voltage.com Email: martin@voltage.com
Mark Schertler Mark Schertler
Tumbleweed Communications Tumbleweed Communications
700 Saginaw Dr 700 Saginaw Dr
Redwood City CA 94063 Redwood City CA 94063
USA
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 The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use of might be claimed to pertain to the implementation or use of
the technology described in this document or the extent to the technology described in this document or the extent to
 End of changes. 32 change blocks. 
86 lines changed or deleted 101 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/