S/MIME Working Group Z. Cheng
Internet Draft Middlesex U.
Expires: December 11, 2007 B. Dan
Olym Tech.
June 11, 2007
Use of the Identity-Based Cryptographic Algorithms in CMS
draft-cheng-smime-ibccms-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any 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 aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use 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
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 11, 2007.
Abstract
This document describes the conventions for using identity-based
cryptography algorithms in the Cryptographic Message Syntax (CMS).
Table of Contents
1. Introduction..................................................2
1.1. Terminology..............................................3
2. Identity Information Structure................................3
2.1. IBCIdentityInfo Structure................................3
2.2. Double DER-en/decoding...................................6
Cheng & Dan Expires December 11, 2007 [Page 1]
Internet-Draft Using IBC with CMS May 2007
3. Using IBS with CMS............................................6
3.1. Signed-Data Content Type for IBS.........................6
3.2. Signature Generation Process.............................7
3.3. Signature Verification Process...........................7
4. Using IBE with CMS............................................8
4.1. Enveloped-Data Content Type for IBE......................8
4.2. CEK Encryption Process...................................9
4.3. CEK Decryption Process..................................10
4.4. Authenticated-Enveloped-Data Content Type for IBE.......11
5. ASN.1 Module.................................................11
6. Security Considerations......................................13
7. IANA Considerations..........................................14
8. Acknowledgments..............................................14
9. References...................................................14
9.1. Normative References....................................14
Author's Addresses..............................................15
Intellectual Property Statement.................................15
Disclaimer of Validity..........................................16
1. Introduction
Identity-Based Cryptography (IBC) is a type of public key
cryptography in which a public and private key pair is set up in a
special way. In an IBC system, there exits a Key Generation Center
(KGC), which chooses a master secret and a set of system public
parameters. Each user has a unique identifier which can be an
arbitrary string. The public key of the user is the identifier or a
prescribed unique variant of the user identifier. The corresponding
private key is created by using an identity-based key extraction
algorithm, which binds the user identifier or the prescribed unique
identifier variant with the master secret of the KGC.
This document describes the cryptographic message syntax for using
identity-based cryptography (IBC) including identity-based encryption
(IBE) algorithms and also identity-based signature (IBS) algorithms.
The design goal of this set of message syntax's is to make sure that
IBE and IBS protected messages can be encoded with the existing CMS
[RFC3852] and the emerging new standard [Hou] without difficulty.
The CMS described in this document takes a unified approach to
support both IBE and IBS. Specifically, the subjectKeyIdentifier
field in both the SignedData structure [RFC3852], the EnvelopedData
structure [RFC3852] and the AuthEnvelopedData structure [Hou] is used
to carry the necessary IBC identity information. Such information
SHOULD include the user identifier, a set of system public parameters
Cheng & Dan Expires December 11, 2007 [Page 2]
Internet-Draft Using IBC with CMS May 2007
or the system parameter identity and other optional information such
as identity-based encryption policies.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
2. Identity Information Structure
To represent the necessary identity information required by IBC
algorithms, a generic identity information structure is defined. All
the IBC user identity information is organized within this generic
structure. Each concrete type of identity encoding schema, which
describes a specific identifier format, SHOULD be defined separately
and the use of the identity information MAY vary with each IBC
algorithm.
2.1. IBCIdentityInfo Structure
IBCIdentityInfo defines a generic identity information structure for
IBC, which provides the necessary information for a signature
verifier or an encrypted-message recipient to locate the IBC system
public parameters and to reconstruct the signer or the recipient's
encoded identifier used in the signing or the encryption process
respectively. The definition has considered the general requirements
of an IBC system and the proposals in [AMS][MS].
IBCIdentityInfo ::= SEQUENCE {
version INTEGER { v1(1) },
domain OCTET STRING,
serial INTEGER,
serverInfo ServerAttributes OPTIONAL,
keyFetchMethod [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
identitySchema [2] IMPLICIT OBJECT IDENTIFIER,
identityData ANY DEFINED BY identitySchema
}
Cheng & Dan Expires December 11, 2007 [Page 3]
Internet-Draft Using IBC with CMS May 2007
ServerAttributes ::= SET SIZE {1..MAX} Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
domain and serial are used to uniquely identify a set of IBC system
public parameters. The system public parameters MAY vary with each
IBC algorithm.
serverInfo provides information of the server which is in charge of
the IBC service in the domain. A server MAY act as a KGC to publish
the system parameters and provide private keys to users, or it MAY
just publish the system public parameters.
keyFetchMethod defines a method to retrieve the private key
corresponding to the user encoded identifier defined in identityData.
This field is designed to be compatible with the IBE architecture
[AMS]. The value SHOULD be the following OBJECT IDENTIFIER defined in
[MS] if the key fetch method defined in [AMS] is used.
cmsPPSOID OBJECT IDENTIFIER ::= { joint-iso-itu(2) country(16)
us(840) organization(1) identicrypt(114334) pps-schemas(3) ic-
schemas(1) pps-uri(1)}
or other OBJECT IDENTIFIER defined in a separate document.
identitySchema defines the format that is used to encode the
information included in identityData to represent a user encoded
identifier. The value can be the following OBJECT IDENTIFIER:
cmsECSchemaOID OBJECT IDENTIFIER ::= TBD
If the cmsECSchemaOID schema is used, identityData MUST carry the
value of the following ECIdentitySchema structure, which includes the
user identifier or a unique identity variant and other optional
information.
ECIdentitySchema ::= SEQUENCE {
idString ECEncodeID,
Cheng & Dan Expires December 11, 2007 [Page 4]
Internet-Draft Using IBC with CMS May 2007
decTime GeneralizedTime OPTIONAL,
policyInfo PolicyAttributes OPTIONAL
}
ECEncodeID ::= CHOICE {
ecSignerID ECSignerID,
ecRecipientID [0] ECRecipientID
}
ECSignerID ::= SEQUENCE{
idTag OCTET STRING {"SIGN="},
basicID OCTET STRING
}
ECRecipientID ::= SEQUENCE{
idTag OCTET STRING {"RECP="},
basicID OCTET STRING
}
PolicyAttributes ::= SET SIZE {1..MAX} Attribute
idString defines the user encoded identifier used in the IBE or IBS
algorithms.
basicID is the raw user identifier, which can be an arbitrary OCTET
STRING such as an email address that uniquely identifies a user.
decTime specifies the time after which the recipient is enabled to
decrypt the message. Refer to Section 11.3. in [RFC3852] for the
format of GeneralizedTime.
The encoded identifier is formatted as idTag|basicID if decTime and
policyInfo are not present. | represents concatenating the values of
two OCTET STRING's. For example, if the basicID field carries the
value of an email address "ALICE@NETWORK.COM", then the encoded
signer identifier is "SIGN=ALICE@NETWORK.COM" and the encoded
Cheng & Dan Expires December 11, 2007 [Page 5]
Internet-Draft Using IBC with CMS May 2007
recipient identifier is "RECP=ALICE@NETWORK.COM". If decTime is
present, then the encoded identifier is formatted as follows.
idTag|basicID|"DECTIME="|DECTIME. Some systems MAY choose to use the
same encoded identifier for both signature and encryption.
policyInfo specifies other encryption policies which control the
recipient's decryption process. How to apply a policy and how the
policy affects the encoded identifier should be defined in separate
documents.
2.2. Double DER-en/decoding
Field subjectKeyIdentifier in the SignData, the EnvelopedData and the
AuthEnvelopedData content type in CMS [RFC3852, Hou] is of the type
SubjectKeyIdentifier, which is encoded as an OCTET STRING. To carry
the value of IBCIdentityInfo in subjectKeyIdentifier, a double-
encoding method, namely, a type of data is first BER-encoded with the
defined type and then the result is further BER-encoded as an OCTET
STRING, MUST be used.
The encoding and decoding process of SubjectKeyIdentifier are
specified as follows:
Encoding the field subjectKeyIdentifier
1. DER-encode the IBCIdentityInfo.
2. DER-encode the output of Step 1 as the data of an OCTET STRING.
Decoding the field subjectKeyIdentifier
1. DER-decode the field as an OCTET STRING
2. DER-decode the output value of Step 1 to an IBCIdentityInfo.
Note that, Step 2 in the decoding procedure is only executed when an
IBC algorithm is used.
3. Using IBS with CMS
3.1. Signed-Data Content Type for IBS
If a signer uses an IBS algorithm, the fields in SignerInfo in the
SignedData content type in CMS [RFC3852] have the following meanings:
o version is always set to 3, because the subjectKeyIdentifier is
used.
Cheng & Dan Expires December 11, 2007 [Page 6]
Internet-Draft Using IBC with CMS May 2007
o sid is of the type SubjectKeyIdentifier and the field carries the
output of double-DER encoding the IBCIdentityInfo structure as
defined in Section 2.2.
o digestAlgorithm identifies the message digest algorithm, and any
associated parameters, used by the IBS algorithm.
o signedAttrs, as defined in CMS [RFC3852], is a collection of
attributes that are signed.
o signatureAlgorithm identifies the used IBS algorithm.
o signature is the result of digital signature generation. The
details of the signature depend on the used IBS algorithm.
o unsignedAttrs, as defined in CMS [RFC3852], is a collection of
attributes that are not signed.
3.2. Signature Generation Process
The identity-based signature generation process works as follows:
1. Calculate the message digest by following the procedure defined in
Section 5.4. in CMS [RFC3852].
2. Choose a set of system public parameters, and encode the signer's
identifier by following the chosen identitySchema, and obtain the
identity-based private key corresponding to the encoded signer
identifier.
3. Generate the signature value with the chosen IBS algorithm given
the result of Step 1 and 2.
4. Prepares the value of IBCIdentityInfo. The information stored in
the structure SHOULD enable the verifier to identify the used
system public parameters and reconstruct the encoded signer
identifier used for signing. The structure MAY include the
information of the server that is in charge of the domain, which
MAY further provide information of the system public parameters.
5. Set the value of each field in SignerInfo. The sid field MUST
carry the output of double-encoding IBCIdentityInfo.
3.3. Signature Verification Process
The identity-based signature verification process works as follows:
Cheng & Dan Expires December 11, 2007 [Page 7]
Internet-Draft Using IBC with CMS May 2007
1. Decode the fields in SignerInfo with the process as required in
CMS [RFC3852].
2. Calculate the message digest as defined in Section 5.4. in CMS
[RFC3852].
3. If signatureAlgorithm field indicates that the signer used an IBS
algorithm, then
a. Decode the octet string value of sid with the type
IBCIdentityInfo. If the output is not an IBCIdentityInfo
structure, the signature verification process fails.
b. Use the identity information in the IBCIdentityInfo structure
to obtain the system public parameters, and to reconstruct the
signer's encoded identifier by following the specified
identitySchema. The domain and serial field provide the unique
identity of the used system public parameters. The verifier
MAY obtain the parameters by any means. Field serverInfo MAY
provide information for the parameter retrieval. If the system
public parameters can't be retrieved, the signature
verification process fails.
4. Verify the signature value with the chosen IBS algorithm given the
signature value, the signer's encoded identifier and the system
public parameters.
4. Using IBE with CMS
4.1. Enveloped-Data Content Type for IBE
If a sender uses an IBE algorithm to encrypt the content-encryption
key (CEK), the fields in the EnvelopedData content type in CMS
[RFC3852] have the following meaning:
o version is always set to 3
o originator MUST be omitted.
o recipientInfos MUST be of the type KeyAgreeRecipientInfo.
o other fields are as defined in Section 6. in CMS [RFC3852].
The meanings of fields in KeyAgreeRecipientInfo are defined as
follows:
o version is always set to 3.
Cheng & Dan Expires December 11, 2007 [Page 8]
Internet-Draft Using IBC with CMS May 2007
o originator MUST be of type SubjectKeyIdentifier. The value of the
field varies with the used IBE algorithm. If the used IBE
algorithm uses the sender's identifier, then the field carries the
output of double-encoding the sender's IBCIdentityInfo. Otherwise,
the value of the field MUST be a DER-encoded OCTET STRING of value
NULL.
o ukm depends on the IBE algorithm used.
o keyEncryptionAlgorithm identifies the IBE algorithm used.
o recipientEncryptedKeys, as defined in CMS [RFC3852], includes a
recipient identifier and encrypted key for one or more recipients.
Each field in the structure has the following meaning:
o rid MUST be of type RecipientKeyIdentifier, and each field in
the structure has the following meaning:
subjectKeyIdentifier carries the output of double-
encoding the recipient's identity information structure
IBCIdentityInfo.
date has the meaning as defined in CMS [RFC3852].
other has the meaning as defined in CMS [RFC3852].
o encryptedKey is the ciphertext of encrypting CEK with the IBE
algorithm, and which varies with each IBE algorithm.
4.2. CEK Encryption Process
To encrypt a CEK to a recipient, in general the sender performs the
following steps:
1. If the algorithm involves the sender's identity. Choose a set of
system public parameters and encode the sender's identifier for
encryption by following the chosen identitySchema, and MAY obtain
the identity-based private key corresponding to the sender's
encoded identifier.
2. Choose a set of system public parameters for the intended
recipient. If Step 1 has chosen a parameter set, the same
parameter set MUST be used for the recipient. Encode the recipient
identifier by following the chosen identitySchema.
Cheng & Dan Expires December 11, 2007 [Page 9]
Internet-Draft Using IBC with CMS May 2007
3. Compute the ciphertext as the value of encryptedKey by the IBE
encryption algorithm given the recipient's encoded identitifier,
the system public parameters, CEK, the optional sender's encoded
identifier and the corresponding private key and the optional
encryption policy. Note that enforcing the decryption time after
which that the recipient can decrypt the encryptedKey is also an
encryption policy. Which encryption policies that should be
applied depends on the application requirements. How to apply the
policies varies with IBE algorithms and applications.
4. Set the fields of KeyAgreeRecipientInfo as defined in Section 4.1.
How to represent the encryption policies in ECIdentitySchema
should be specified in separate documents.
4.3. CEK Decryption Process
To decrypt a CEK, the recipient performs the following steps in
general.
1. Decode originator as an OCTET STRING as required in CMS [RFC3852].
The result value MAY be NULL.
2. If the used algorithm is an IBE algorithm then
a. If the output value of Step 1 is not NULL, then further decode
the output as an IBCIdentityInfo.
b. Decode the output value of decoding RecipientKeyIdentifier's
subjectKeyIdentifier as an IBCIdentityInfo.
3. Obtain a set of system public parameters uniquely identified by
the domain name and serial number in the recipieint's
IBCIdentityInfo. The recipient MAY obtain the system public
parameters by any means. The IBCIdentityInfo MAY provide
information to help the recipient to retrieve such information. If
sender's IBCIdentityInfo is present, then it MUST refer to the
same set of parameters as in the recipient's IBCIdentityInfo and
the sender's encoded identifier should be reconstructed.
4. Obtains the private key corresponding to the recipient's encoded
identifier which is specified by the chosen identitySchema and
other optional keys that are required to apply encryption policies.
The recipient MAY obtain these keys by any means. The serverInfo
and keyFetchMethod fields if present SHOULD provide the
information necessary to locate private keys. But to retrieve
these keys MUST rely on other credentials that are own by the
recipient.
Cheng & Dan Expires December 11, 2007 [Page 10]
Internet-Draft Using IBC with CMS May 2007
5. Apply other policies that do not require corresponding keys. How
to enforce those polices varies with the system and applications.
6. Decrypt the encryptedKey to recover the CEK with the IBE
decryption algorithm given the private keys, system public
parameters, recipient encoded identifier, the optional encoded
sender identifier and the optional policies
4.4. Authenticated-Enveloped-Data Content Type for IBE
[Hou] defines a new AuthEnvelopedData content type. One MAY choose to
use this content type for an IBE.
o originatorInfo and recipientInfos in the AuthEnvelopedData content
type have the same meaning as in the EnvelopedData content type
defined in Section 4.1.
o Other fields have the same meaning as defined in [Hou].
The process of field version, originatorInfo and recipientInfos
follows the same procedure as defined in Section 4.2 and 4.3 for
EnvelopedData respectively.
The process of field authEncryptedContentInfo, authAttrs, mac and
unauthAttrs follows the same procedure as defined in [Hou].
5. ASN.1 Module
IBCIdentityInfo ::= SEQUENCE {
version INTEGER { v1(1) },
domain OCTET STRING,
serial INTEGER,
serverInfo ServerAttributes OPTIONAL,
keyFetchMethod [1] IMPLICIT OBJECT IDENTIFIER OPTIONAL,
identitySchema [2] IMPLICIT OBJECT IDENTIFIER,
identityData ANY DEFINED BY identitySchema
}
ServerAttributes ::= SET SIZE {1..MAX} Attribute
Cheng & Dan Expires December 11, 2007 [Page 11]
Internet-Draft Using IBC with CMS May 2007
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
cmsECSchemaOID OBJECT IDENTIFIER ::= TBD
ECIdentitySchema ::= SEQUENCE {
idString ECEncodeID,
decTime GeneralizedTime OPTIONAL,
policyInfo PolicyAttributes OPTIONAL
}
ECEncodeID ::= CHOICE {
ecSignerID ECSignerID,
ecRecipientID [0] ECRecipientID
}
ECSignerID ::= SEQUENCE{
idTag OCTET STRING {"SIGN="},
basicID OCTET STRING
}
ECRecipientID ::= SEQUENCE{
idTag OCTET STRING {"RECP="},
basicID OCTET STRING
}
PolicyAttributes ::= SET SIZE {1..MAX} Attribute
Cheng & Dan Expires December 11, 2007 [Page 12]
Internet-Draft Using IBC with CMS May 2007
6. Security Considerations
This document describes the use of cryptographic message syntax for
the SignedData, EnvelopedData and AuthEnvelopedData content type with
IBC algorithms. Hence the relevant security considerations in CMS
[RFC3852] and [Hou] apply.
Generally the following rules MUST be observed:
o The chosen IBC algorithm MUST be secure and the appropriate
security level MUST be chosen. The attack on specific IBC
algorithm is beyond the scope of the document.
o The IBC system public parameters MUST be authentic and any
parameter retrieving process MUST be secure against modification
and impersonation. In particular, the verifier of an identity-
based signature MUST be assured it has obtained authentic system
public parameters identified by the domain name and the serial
number. Otherwise, an adversary can deceive the verifier into
accepting a forged signature in the following way:
1. Generate a master secret and the corresponding set of system
public parameters.
2. Generate the private key corresponding to the signer's
encoded identifier by using the identity-based key extraction
algorithm and the master secret from Step 1.
3. Generate the signature in SignerInfo using the IBS algorithm
and the private key from Step 2.
4. Deceive the verifier into accepting the system public
parameter from Step 1 and then the verification process will
conclude that the signature from Step 3 is therefore
authentic.
Similarly, in the enveloping data process the sender MUST obtain
authentic system public parameters used by the intended
recipient. Otherwise, an adversary can decrypt a message in the
following way:
1. Generate a master secret and the corresponding set of system
public parameters.
2. Deceive the sender into accepting the system public parameter
from Step 1 and then the sender will encrypt the content-
encryption key with false parameters.
Cheng & Dan Expires December 11, 2007 [Page 13]
Internet-Draft Using IBC with CMS May 2007
3. Generate the private key corresponding to the recipient's
encoded identifier by using the identity-based key extraction
algorithm and the master secret from Step 1.
4. Decrypt encryptedKey with the IBE algorithm and the private
key from Step 3, in order to decrypt encryptedContentInfo.
o The master secret owned by the KGC MUST be well protected. If the
master key is compromised, the adversary can generate the private
key corresponding to a signer or recipient's encoded identifier,
and hence forge signatures or decrypt messages. Protection of the
master key is beyond the scope of this document.
o Any private key retrieving process MUST be protected from
information leakage or impersonation or modification. The IBE
architecture [AMS] supports online private key retrieving. Such
process MUST be protected, otherwise, the leak of IBE private key
will compromise the security of encryptedContentInfo.
o The signer's private key MUST be protected from leakage in any
implementation.
o The recipient's private key MUST be protected from leakage in any
implementation.
o The content-encryption key MUST be protected from leakage and MUST
be generated randomly in any implementation.
7. IANA Considerations
cmsECSchemaOID should have an OBJECT IDENTIFIER assigned.
8. Acknowledgments
The author would like to thank Richard Read and Manos Nistazakis for
their comments.
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.1. Normative References
[AMS] G. Appenzeller, L. Martin, M. Schertler, "Identity-based
Encryption Architecture", draft-ietf-ibearch-03.txt.
Cheng & Dan Expires December 11, 2007 [Page 14]
Internet-Draft Using IBC with CMS May 2007
[ASN1] CCITT, "Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1)",
1998.
[Hou] R. Housley, "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type",
<draft-ietf-smime-cms-auth-enveloped-04.txt
[MS] L. Martin and M. Schertler, "Using the Boneh-Franklin and
Boneh-Boyen identity-based encryption algorithms with the
Cryptographic Message Syntax (CMS)", draft-ietf-smime-
bfibecms-03.txt.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3852] R. Housley, "Cryptographic Message Syntax", RFC 3852, July
2004.
Author's Addresses
Zhaohui Cheng
Middlesex University
The Burroughs Hendon, London NW4 4BT, UK
Phone: +44 20 84114932
Email: m.z.cheng@mdx.ac.uk
Bo Dan
Olym Tech.
International Technology Center, Industrial Park,
The 10th Keji Nan Road, Shenzhen, P.R.C.
Phone: +86 755 26727161
Email: danbo@gtmessage.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
Cheng & Dan Expires December 11, 2007 [Page 15]
Internet-Draft Using IBC with CMS May 2007
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
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 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 (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Cheng & Dan Expires December 11, 2007 [Page 16]