[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5758

PKIX Working Group                                     Q. Dang (NIST)
Internet Draft                               S. Santesson (Microsoft)
Intended Category: Standards Track                  K. Moriarty (RSA)
                                            D. Brown (Certicom Corp.)
Expires: April 30, 2009                                T. Polk (NIST)
                                                    October 30, 2008






 Internet X.509 Public Key Infrastructure: Additional
         Algorithms and Identifiers for DSA and ECDSA
           <draft-ietf-pkix-sha2-dsa-ecdsa-05.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.

   Copyright Notice



   Copyright (C) The IETF Trust (2008).




Dang, et al.            Expires April 30, 2009                 [Page 1]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


   Abstract

   This document supplements RFC 3279. It specifies algorithm
   identifiers and ASN.1 encoding rules for the Digital
   Signature Algorithm (DSA) and Elliptic Curve Digital
   Signature Algorithm (ECDSA) digital signatures when using
   SHA-224, SHA-256, SHA-384 or SHA-512 as hashing algorithm.
   This specification applies to the Internet X.509 Public Key
   Infrastructure (PKI) when digital signatures are used to
   sign certificates and certificate revocation lists (CRLs).

   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].


Table of Contents


   1. Introduction...................................................2
   2. One-way Hash Functions.........................................3
   3. Signature Algorithms...........................................4
      3.1   DSA Signature Algorithm..................................4
      3.2   ECDSA Signature Algorithm................................6
   4. ASN.1 Module...................................................7
   5. Security Considerations........................................8
   6. References....................................................10
      6.1   Normative references:...................................10
      6.2   Informative references..................................11
   7. Authors' Addresses............................................11
   8. IANA Considerations...........................................12
   9. Intellectual Property.........................................12
   10.Copyright Statement...........................................13





1. Introduction

This specification supplements [RFC 3279], "Algorithms and Identifiers
for the Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile" and extends the list of
algorithms defined for use in the Internet PKI. This document specifies
algorithm identifiers and ASN.1 [X.660] encoding rules for DSA and ECDSA


Dang, et al.            Expires April 30, 2009                 [Page 2]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


digital signatures in certificates and CRLs when using one of the SHA-2
hash algorithms (SHA-224, SHA-256, SHA-384, and SHA-512) as the hash
algorithm.

This specification defines the contents of the signatureAlgorithm,
signatureValue and signature fields within Internet X.509 certificates
and CRLs when these objects are signed using DSA or ECDSA with a SHA-2
hash algorithm. These fields are more fully described in [RFC 5280].

This document profiles material presented in the ''Secure Hash Standard
'' [FIPS 180-3], "Public Key Cryptography for the Financial Services
Industry: The Elliptic Curve Digital Signature Standard (ECDSA)"
[X9.62], and the ''Digital Signature Standard'' [FIPS 186-3].

Algorithm identifiers and encoding rules for RSA, DSA and ECDSA when
used with SHA-1 are specified in [RFC 3279]. Algorithm identifiers and
encoding rules for RSA when used with SHA-2 are specified in [RFC 4055].

2. One-way Hash Functions

This section identifies four additional hash algorithms for use with DSA
and ECDSA in the Internet X.509 certificate and CRL profile [RFC 5280].

SHA-224, SHA-256, SHA-384, and SHA-512 produce a 224-bit, 256-bit, 384-
bit and 512-bit "hash" of the input respectively and are fully described
in the Federal Information Processing Standard 180-3 [FIPS 180-3].

The listed one-way hash functions are identified by the following object
identifiers (OIDs):

   id-sha224  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16)
   us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
   4 }

   id-sha256  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16)
   us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
   1 }

   id-sha384  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16)
   us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
   2 }

   id-sha512  OBJECT IDENTIFIER  ::=  { joint-iso-itu-t(2) country(16)
   us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
   3 }




Dang, et al.            Expires April 30, 2009                 [Page 3]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


When one of these OIDs appears in an AlgorithmIdentifier, all
implementations MUST accept both NULL and absent parameters as legal and
equivalent encodings.

3. Signature Algorithms

Certificates and CRLs conforming to [RFC 5280] may be signed with any
public key signature algorithm. The certificate or CRL indicates the
algorithm through an identifier, which appears in the signatureAlgorithm
field within the Certificate or CertificateList. This algorithm
identifier is an OID and has optionally associated parameters. This
section denotes algorithm identifiers and parameters that MUST be used
in the signatureAlgorithm field in a Certificate or CertificateList.

Signature algorithms are always used in conjunction with a one-way hash
function. This section identifies OIDs for DSA and ECDSA with SHA-224,
SHA-256, SHA-384, and SHA-512. The contents of the parameters component
for each signature algorithm vary; details are provided for each
algorithm.

The data to be signed (e.g., the one-way hash function output value) is
formatted for the signature algorithm to be used. Then, a private key
operation (e.g., DSA encryption) is performed to generate the signature
value. This signature value is then ASN.1 encoded as a BIT STRING and
included in the Certificate or CertificateList in the signature field.
More detail on how digital signatures are generated can be found in
[FIPS 186-3].

Entities that validate DSA signatures MUST support SHA-224 and SHA-256.
Entities that validate ECDSA signatures MUST support SHA-224 and SHA-256
and should support SHA-384 and SHA-512.

3.1 DSA Signature Algorithm

The DSA is defined in the Digital Signature Standard (DSS) [FIPS 186-3].
DSA was developed by the U.S. Government, and can be used in conjunction
with a SHA2 one-way hash function such as SHA-224 or SHA-256. DSA is
fully described in [FIPS 186-3].

[FIPS 186-3] specifies four size-choices for a DSA key pair of the form
(public key size, private key size) in bits. The four choices are (1024,
160), (2048, 224), (2048, 256), and (3072, 256). More information can be
found in [FIPS 186-3]. For the remainder of this specification, each and
every key pair of the DSA key pairs is referred to by the size of its
public key.




Dang, et al.            Expires April 30, 2009                 [Page 4]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


DSA key pairs of 1024 and 2048 bits may be used with SHA-224. DSA key
pairs of any of the four sizes may use SHA-256. The following are the
OIDs of the DSA digital signature algorithm when used with SHA-224 or
SHA-256.

   When SHA-224 is used, the OID is:

   id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
   country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
   id-dsa-with-sha2(3) 1 }

   When SHA-256 is used, the OID is:

   id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
   country(16) us(840) organization(1) gov(101) csor(3) algorithms(4)
   id-dsa-with-sha2(3) 2 }

The(3072, 256) DSA key pair provides 128 bits of security and provides
the most security among all the four sizes of DSA key pairs. More
information on security strength assessments of DSA and other
cryptographic algorithms can be found in [SP 800-57]. A digital
signature algorithm has the same security strength as its asymmetric key
algorithm like DSA or ECDSA only if its hashing algorithm has at least
the same security strength as the asymmetric key algorithm. Therefore, a
128-bit security strength hashing algorithm which is SHA-256 will be
sufficient to build a 128-bit security strength DSA digital signature
algorithm when a DSA key pair of the size (3072, 256) is used.
Therefore, it is only needed to specify DSA with SHA-224 and SHA-256
because SHA-256 provides sufficient security for using with any DSA key
pair of any of the four size choices. More information on security
strengths of the hash functions SHAs specified in [FIPS 180-3] and the
digital signature algorithms specified in [FIPS 186-3] can be found in
[SP 800-107] and [SP 800-57].

When the id-dsa-with-sha224 or id-dsa-with-sha256 algorithm identifier
appears in the algorithm field as an AlgorithmIdentifier, the encoding
SHALL omit the parameters field. That is, the AlgorithmIdentifier SHALL
be a SEQUENCE of one component, the OID id-dsa-with-sha224 or id-dsa-
with-sha256.

Encoding rules for DSA signature values are specified in [RFC 3279]. For
completeness, this information is repeated below:

When signing, the DSA algorithm generates two values commonly referred
to as r and s. To easily transfer these two values as one signature,
they SHALL be ASN.1 encoded using the following ASN.1 structure:



Dang, et al.            Expires April 30, 2009                 [Page 5]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


Dss-Sig-Value  ::=  SEQUENCE  {
                                r       INTEGER,
                                s       INTEGER
                              }

The DSA parameters in the subjectPublicKeyInfo field of the certificate
of the issuer SHALL apply to the verification of the signature.

3.2 ECDSA Signature Algorithm

The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in,
"Public Key Cryptography for the Financial Services Industry: The
Elliptic Curve Digital Signature Standard (ECDSA)" [X9.62]. The ASN.1
OIDs used to specify that an ECDSA signature was generated using SHA224,
SHA256, SHA384 or SHA 512 are respectively:

   ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 }

   ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 }

   ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 }

   ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
   us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }

When the ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512 algorithm identifier appears in the algorithm field as
an AlgorithmIdentifier, the encoding MUST omit the parameters field.
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component,
the OID ecdsa-with-SHA224, ecdsa-with-SHA256, ecdsa-with-SHA384 or
ecdsa-with-SHA512.

Conforming CA implementations MUST specify the hash algorithm
explicitly, using the OIDs specified above, when encoding ECDSA/SHA-2
signatures in certificates and CRLs.

Conforming client implementations that process ECDSA signatures with any
of the SHA-2 hash algorithms when processing certificates and CRLs MUST
recognize the corresponding OIDs specified above.

[X9.62] has defined additional OIDs for the ECDSA signature algorithm.

Encoding rules for ECDSA signature values are specified in [RFC 3279].
For completeness, this information is repeated below:




Dang, et al.            Expires April 30, 2009                 [Page 6]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


When signing, the ECDSA algorithm generates two values commonly referred
to as r and s. To easily transfer these two values as one signature,
they MUST be ASN.1 encoded using the following ASN.1 structure:

Ecdsa-Sig-Value  ::=  SEQUENCE  {
                                  r     INTEGER,
                                  s     INTEGER
                                }

The elliptic curve parameters in the subjectPublicKeyInfo field of the
certificate of the issuer MUST be applied to the verification of the
signature. The subjectPublicKeyInfo field must be compliant with
requirements for Subject Public Key Information field in [Elliptic
Curve].


4. ASN.1 Module



DEFINITIONS EXPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --
-- All types and values defined in this module are
-- exported for use in other ASN.1 modules.

IMPORTS

   NONE

id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
4 }

id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
1 }

id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
2 }

id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2)
3 }



Dang, et al.            Expires April 30, 2009                 [Page 7]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


--
-- DSA with SHA-224 and SHA-256 signature algorithms
--

id-dsa-with-sha224 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
        country(16) us(840) organization(1) gov(101) csor(3)
        algorithms(4) id-dsa-with-sha2(3) 1 }

id-dsa-with-sha256 OBJECT IDENTIFIER ::= { joint-iso-ccitt(2)
        country(16) us(840) organization(1) gov(101) csor(3)
        algorithms(4) id-dsa-with-sha2(3) 2 }

--
--   ECDSA Signatures with SHA-2 Hashes, from X9.62
--

ecdsa-with-SHA224 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045)
        signatures(4) ecdsa-with-SHA2(3) 1 }

ecdsa-with-SHA256 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045)
        signatures(4) ecdsa-with-SHA2(3) 2 }

ecdsa-with-SHA384 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045)
        signatures(4) ecdsa-with-SHA2(3) 3 }

ecdsa-with-SHA512 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045)
        signatures(4) ecdsa-with-SHA2(3) 4 }


END -- Definitions


5. Security Considerations

This specification supplements [RFC 3279]. This document covers the DSA
and ECDSA algorithms with SHA2 hash functions and the associated
considerations.

The appropriate use of the hash functions in terms of the algorithm
strengths and expected time frames for secure use as defined by NIST can
be found in Special Publications (SPs) 800-78-1 [SP 800-78-1], 800-57
[SP 800-57] and 800-107 [SP 800-107].

FIPS 186-3 fully specifies the DSA digital signature algorithm and
defines security requirements for the DSA and ECDSA digital signature
algorithms; details can be found in [FIPS 186-3]. ECDSA is fully
specified in [X9.62].[FIPS 186-3] also specifies three types of elliptic


Dang, et al.            Expires April 30, 2009                 [Page 8]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


curves for use in conjunction with one of the described hash functions:
curves over prime fields, curves over binary fields, and Koblitz curves
(anomalous binary curves). FIPS 186-3 provides a table listing the uses
and time periods for each algorithm and key size combinations for
various applications. The DSA and ECDSA private keys must be generated
from pseudorandom functions whose security strengths meet or exceed the
desired security strengths for the digital signature algorithms.
Guidelines on building these NIST-approved pseudorandom functions can be
found in SP 800-90 [SP 800-90]. The hash functions must meet or exceed
the desired security strengths of the digital signature algorithms. More
guidelines can be found in SP 800-57 [SP 800-57] and SP 800-107 [SP 800-
107].

The one-way hash algorithms discussed in this document, SHA-224, SHA-
256, SHA-384, and SHA-512 each have a recommended lifetime when used in
combination with a digital signature algorithm. NIST provides
information on the appropriate time periods for which each combination
should be used based upon the security needs of the service and
information being protected in NIST Special Publication 800-57. A table
outlines the year in which NIST deems it is no longer safe to use
specific combinations of key lengths and algorithms of various strengths
for RSA, DSA, and ECDSA. NIST also provides Recommendation for using
NIST-approved hash algorithms in the digital signature applications in
[SP 800-107].

The Special Publication 800-57 also provides guidelines for key
management to be used by both developers and system administrators. The
document covers the aspects of key management from algorithm selection
and key sizes with associated key usage period to key usage (preventing
key overlap), the compromise of keys and keying material, and key
destruction. Specific guidelines are offered for key usage periods such
as the lifetime of a private signature key may be shorter than the
lifetime of the public verification key for practical applications. The
specification also provides recommendations on the number of years
various key types should be used such as public and private signature
keys, public and private authentication keys, etc.

NIST Special Publication 800-78-1 also lists time frames for the use of
combined hash algorithms and digital signature algorithms for specific
key types, but differentiates some security requirements between digital
signature and authentication keys.

The recommendation for the size of digital signature keys and key
management keys is more restrictive than that of authentication keys,
because they are used to protect data for longer periods of time.


Dang, et al.            Expires April 30, 2009                 [Page 9]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


Therefore, the transition dates to larger key sizes are earlier in
general.

Guidelines for the protection of domain parameters, initialization
vectors (IVs), and per message secret numbers for use with digital
signature algorithms, DSA and ECSDA are provided in [FIPS 186-3]. An
assurance of integrity should be obtained prior to using all keying
material for the generation of digital signatures using DSA and ECDSA.
Recommendation for Obtaining Assurances for Digital Signature
Applications can be found in [SP 800-89]. The purpose of this is to
ensure the keying material is in the proper format, the domain
parameters are valid, the possession of the private key, the validity of
the public key, and that the request is coming from an authorized
source.

Certificate Authorities (CAs) that issue certificates using the DSA and
ECDSA algorithms for key generation SHOULD adhere to the recommended
security guidelines for key management in the NIST Special Publication
800-57. When signing a digital signature certificate, a CA should use
the same or greater size hash function than the hash function in the
digital signature algorithm in the certificate.



6. References

   6.1   Normative references:

   [RFC 2119]   Bradner, S., "Key Words for Use in RFCs to Indicate
                Requirement Levels", RFC 2119, March 1997.

   [RFC 3279]   Bassham, L., Polk, W., and R. Housley, "Algorithms and
                Identifiers for the Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 3279, April 2002.

   [RFC 5280]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S.
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation
                List (CRL) Profile", RFC 5280, May 2008.

   [X9.62]      X9.62-2005, "Public Key Cryptography for the Financial
                Services Industry: The Elliptic Curve Digital Signature
                Standard (ECDSA)", November, 2005.

   [Elliptic Curve]Turner S., Brown D., Yiu K., Housley R., and Polk W.,
                "Elliptic Curve Cryptography Subject Public Key


Dang, et al.            Expires April 30, 2009                [Page 10]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


                Information" draft-ietf-pkix-ecc-subpubkeyinfo-08.txt
                (work in progress), September 2008.

   [FIPS 180-3] Federal Information Processing Standards Publication
                (FIPS PUB) 180-3, Secure Hash Standard (SHS), October
                2008.

   [FIPS 186-3] Federal Information Processing Standards Publication
                (FIPS PUB) 186-3, Digital Signature Standard (DSS),
                (draft) 13 March 2006.

   6.2   Informative references

   [SP 800-107] Q. Dang, NIST, "Recommendation for Applications Using
                Approved Hash Algorithms", (draft) July 2008.

   [SP 800-78-1]  W. Timothy Polk, Donna, F. Dodson, William E. Burr,
                NIST, "Cryptographic Standards and Key Sizes for
                Personal Identity Verification", August 2007.

   [SP 800-57]  Elaine Barker, William Barker, William E. Burr, NIST,
                "Recommendation for Key Management", August 2005.

   [SP 800-89]  Elaine Barker, NIST, "Recommendation for Obtaining
                Assurances for Digital Signature Applications",
                November 2006.

   [SP 800-90]  Elaine Barker, John Kelsey, NIST, ''Recommendation for
                Random Number Generation Using Deterministic Random Bit
                Generators'', March 2007.

   [RFC 4055]   Schaad, J., Kaliski, B., and Housley, R., "Additional
                Algorithms and Identifiers for RSA Cryptography for use
                in the Internet X. 509 Public Key Infrastructure
                Certificate and Certificate Revocation List (CRL)
                Profile", RFC 4055, June 2005.



7. Authors' Addresses

      Quynh Dang

      NIST
      100 Bureau Drive, Stop 8930
      Gaithersburg, MD 20899-8930
      USA

      Email: quynh.dang@nist.gov


Dang, et al.            Expires April 30, 2009                [Page 11]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008






      Stefan Santesson
      Microsoft
      Tuborg Boulevard 12
      2900 Hellerup
      Denmark
      EMail: stefans@microsoft.com

      Kathleen M. Moriarty
      RSA, The Security Division of EMC
      174 Middlesex Turnpike
      Bedford, MA 01730
      Email: kathleen.moriarty@rsa.com

      Daniel R. L. Brown
      Certicom Corp.
      5520 Explorer Drive
      Mississaug, ON L4W 5L1
      Email: dbrown@certicom.com

      Tim Polk
      NIST
      100 Bureau Drive, Stop 8930
      Gaithersburg, MD 20899-8930
      USA
      Email: tim.polk@nist.gov




8. IANA Considerations

This document has no actions for IANA.

9. Intellectual Property



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 on the



Dang, et al.            Expires April 30, 2009                [Page 12]

Internet-Draft       DSA/ECDSA Algorithm Identifiers       October 2008


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.



10.Copyright Statement

Copyright (C) The IETF Trust (2008).

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.

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.

















Dang, et al.            Expires April 30, 2009                [Page 13]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/