INTERNET-DRAFT                                  John Pawling
draft-ietf-smime-cmskea-03.txt                  J.G. Van Dyke & Associates
2 December 1999
Expires:  2 June 2000


                        CMS KEA and SKIPJACK Conventions

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.  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.


Abstract

This document describes the conventions for using the Key Exchange
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the
Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data
content types.

This draft is being discussed on the 'ietf-smime' mailing list.  To
subscribe, send a message to ietf-smime-request@imc.org with the single
word "subscribe" in the body of the message. There is a Web site for
the mailing list at <http://www.imc.org/ietf-smime/>.


1. Introduction

Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY are
used in capital letters. This conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
make the intent of standards track documents as clear as possible. The
same key words are used in this document to help implementers achieve
interoperability. Software that claims compliance with this document
MUST provide the capabilities as indicated by the MUST, MUST NOT,
SHOULD and MAY terms.  The KEA and SKIPJACK cryptographic algorithms are
described in [SJ-KEA].


2. Content Encryption Process

This section applies to the construction of both the enveloped-data and
encrypted-data content types.  Compliant software MUST meet the
requirements stated in [CMS] Section 6.3, "Content-encryption Process".
The input to the encryption process MUST be padded to a multiple of
eight octets using the padding rules described in [CMS] Section 6.3.
The content MUST be encrypted as a single string using the SKIPJACK
algorithm in 64-bit Cipher Block Chaining (CBC) mode using
randomly-generated 8-byte Initialization Vector (IV) and 80-bit
SKIPJACK content-encryption key (CEK) values.


3. Content Decryption Process

This section applies to the processing of both the enveloped-data and
encrypted-data content types.  The encryptedContent MUST be decrypted as
a single string using the SKIPJACK algorithm in 64-bit CBC mode.  The 80-
bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to the SKIPJACK
decryption process.  Following decryption, the padding MUST be removed
from the decrypted data.  The padding rules are described in [CMS]
Section 6.3, "Content-encryption Process".



4. Enveloped-data Conventions

The CMS enveloped-data content type consists of an encrypted content and
wrapped CEKs for one or more recipients.  Compliant software MUST
meet the requirements for constructing an enveloped-data content type
stated in [CMS] Section 6, "Enveloped-data Content Type".  [CMS] Section 6
should be studied before reading this section, because this section
does not repeat the [CMS] text.

An 8-byte IV and 80-bit CEK MUST be randomly generated for each instance
of an enveloped-data content type as inputs to the SKIPJACK algorithm for
use to encrypt the content.  The SKIPJACK CEK MUST only be used for
encrypting the content of a single instance of an enveloped-data content
type.

KEA and SKIPJACK can be used with the enveloped-data content type using
either of the following key management techniques defined in [CMS]
Section 6:

1) Key Agreement:  The SKIPJACK CEK is uniquely wrapped for each
recipient using a pairwise symmetric key-encryption key (KEK) generated
using KEA using the originator's private KEA key, recipient's public KEA
key and other values. Section 4.2 describes the use of KEA and SKIPJACK
to provide key agreement.

2) "Previously Distributed" Symmetric KEK:  The SKIPJACK CEK is wrapped
using a "previously distributed" symmetric KEK (such as a Mail List Key)
generated using KEA.  The methods by which KEA is used to generate the
symmetric KEK and by which the symmetric KEK is distributed are beyond
the scope of this document. Section 4.3 describes the use of KEA and
SKIPJACK to support "previously distributed" KEKs.

[CMS] Section 6 also defines the concept of the key transport key
management technique.  The key transport technique MUST NOT be used with
KEA.


4.1. EnvelopedData Fields

The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1)
encoded using the EnvelopedData syntax.  The fields of the EnvelopedData
syntax must be populated as follows:

The EnvelopedData version MUST be 2.

If key agreement is being used, then the EnvelopedData originatorInfo
field SHOULD be present and SHOULD include the originator's KEA X.509 v3
certificate containing the KEA public key associated with the KEA private
key used to form each pairwise symmetric KEK used to wrap each copy of
the SKIPJACK CEK.  The issuers' X.509 v3 certificates required to form
the complete certification path for the originator's KEA X.509 v3
certificate MAY be included in the EnvelopedData originatorInfo field.
Self-signed certificates SHOULD NOT be included in the EnvelopedData
originatorInfo field.

The EnvelopedData RecipientInfo CHOICE is dependent on the key management
technique used.  Sections 4.2 and 4.3 provide more information.

The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
algorithm field MUST be the id-fortezzaConfidentialityAlgorithm
object identifier (OID).  The EnvelopedData encryptedContentInfo
contentEncryptionAlgorithm parameters field MUST include the random 8-
byte IV used as the input to the content encryption process.

The EnvelopedData unprotectedAttrs MAY be present.


4.2.  Key Agreement

This section describes the conventions for using KEA and SKIPJACK with
the CMS enveloped-data content type to support key agreement.  When key
agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE
MUST be used.

If the EnvelopedData originatorInfo field does not include the
originator's KEA X.509 v3 certificate, then each recipientInfos
KeyAgreementRecipientInfo originator field MUST include the
issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3
certificate.  If the EnvelopedData originatorInfo field includes the
originator's KEA X.509 v3 certificate, then each recipientInfos
KeyAgreementRecipientInfo originator field MUST include either the
subjectKeyIdentifier CHOICE containing the value from the
subjectKeyIdentifier extension of the originator's KEA v3 X.509
certificate or the issuerAndSerialNumber CHOICE identifying the
originator's KEA X.509 v3 certificate.  To minimize the size of the
EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be
used.

In some environments, the KeyAgreementRecipientInfo originator field MAY
include the originatorKey CHOICE.  The originatorKey CHOICE SHOULD NOT be
used with KEA for e-mail transactions.  Within a controlled security
architecture, a module may produce KEA key pairs for use in conjunction
with internal/local storage of encrypted data.  In this case, there may
not be an X.509 certificate associated with a (possibly) short term or
one time use public KEA key.  When originatorKey is used, then the KEA
public key MUST be conveyed in the publicKey BIT STRING as specified in
[KEA] Section 3.1.2.  The originatorKey algorithm identifier MUST be the
id-keyExchangeAlgorithm OID.  The originatorKey algorithm parameters
field MUST contain the KEA "domain identifier" (ASN.1 encoded as an OCTET
STRING) identifying the KEA algorithm parameters (i.e., p/q/g values)
associated with the KEA public key.  [KEA] Section 3.1.1 describes the
method for computing the KEA domain identifier value.


4.2.1.  SKIPJACK CEK Wrap Process

The SKIPJACK CEK is uniquely wrapped for each recipient of the
EnvelopedData using a pairwise KEK generated using the KEA
material of the originator and the recipient along with the
originator's User Keying Material (UKM) (i.e. Ra).  The CMS
EnvelopedData syntax provides two options for wrapping the SKIPJACK
CEK for each recipient using a KEA-generated KEK.  The "shared
Originator UKM" option SHOULD be used when constructing EnvelopedData
objects.  The "unique originator UKM" option MAY be used when
constructing EnvelopedData objects.  Compliant software MUST be capable
of processing EnvelopedData objects constructed using either option or
both options.

1) Shared Originator UKM Option:  CMS provides the ability for a
single, shared originator's UKM to be used to generate each pairwise
KEK used to wrap the SKIPJACK CEK for each recipient.  When using
the shared originator UKM option, a single RecipientInfo
KeyAgreeRecipientInfo structure MUST be constructed to contain the
wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same
KEA parameters.  The KeyAgreeRecipientInfo structure includes multiple
RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped
for a specific recipient.

2) Unique Originator UKM Option:  CMS also provides the ability for a
unique originator UKM to be used to generate each pairwise KEK used to
wrap the SKIPJACK CEK for each recipient.  When using the unique
originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo
structure MUST be constructed for each recipient.  Each
KeyAgreeRecipientInfo structure includes a single RecipientEncryptedKey
field containing the SKIPJACK CEK wrapped for the recipient.  This
option requires more overhead than the shared UKM option because the
KeyAgreeRecipientInfo fields (i.e. version, originator, ukm,
keyEncryptionAlgorithm) must be repeated for each recipient.

The next two paragraphs apply to both options.

The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST
include the id-kEAKeyEncryptionAlgorithm OID.  The KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm
as specified in [CMS] Appendix A, "ASN.1 Module".  The algorithm field
of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that
the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK
CEK.  The parameters field of KeyWrapAlgorithm MUST be absent.

If the originator is not already an explicit recipient, then a copy of
the SKIPJACK CEK SHOULD be wrapped for the originator and included in
the EnvelopedData.  This allows the originator to decrypt the contents
of the EnvelopedData.


4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM Value

This section describes how a shared originator UKM value is used as an
input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK
for each recipient.

When using the shared originator UKM option, a single RecipientInfo
KeyAgreeRecipientInfo structure MUST be constructed to contain the
wrapped SKIPJACK CEKs for all of the KEA recipients using the same
set of KEA parameters.  If all recipients' KEA public keys were
generated using the same set of KEA parameters, then there MUST only be
a single RecipientInfo KeyAgreeRecipientInfo structure for all of the
KEA recipients.  If the recipients' KEA public keys were generated
using different sets of KEA parameters, then multiple RecipientInfo
KeyAgreeRecipientInfo fields MUST be constructed because the
originatorIdentifierOrKey will be different for each distinct set of
recipients' KEA parameters.

A unique 128-byte originator's UKM MUST be generated for each distinct
set of recipients' KEA parameters.  The originator's UKM MUST be placed
in each KeyAgreeRecipientInfo ukm OCTET STRING.

The originator's and recipient's KEA parameters MUST be identical to use
KEA to successfully generate a pairwise KEK.  [KEA] describes how a KEA
public key is conveyed in an X.509 v3 certificate.  [KEA] states that the
KEA parameters are not included in KEA certificates; instead, a "domain
identifier" is supplied in the subjectPublicKeyInfo algorithm parameters
field of every KEA certificate. The values of the KEA domain identifiers
in the originator's and recipient's KEA X.509 v3 certificates can be
compared to determine if the originator's and recipient's KEA parameters
are identical.

The following steps MUST be repeated for each recipient:

1) KEA MUST be used to generate the pairwise KEK based on the
originator's UKM, originator's private KEA key, recipient's 128 byte
public KEA key (obtained from the recipient's KEA X.509 v3 certificate)
and the recipient's 128-byte public KEA key used as the Rb value.

2) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise
KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit check
value and produces a 96-bit result using the KEA-generated pairwise KEK.

3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the
recipient.

4) The value of the subjectKeyIdentifier extension from the recipient's
KEA X.509 v3 certificate MUST be placed in the recipient's
RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field.  The
KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId.  The date and other
fields MUST be absent from the recipientEncryptedKey rid rKeyId
SEQUENCE.

5) The wrapped SKIPJACK CEK MUST be placed in the recipient's
RecipientEncryptedKey encryptedKey OCTET STRING.

6) The recipient's RecipientEncryptedKey MUST be included in the
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF
RecipientEncryptedKey.


4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values

This section describes how a unique originator UKM value is generated
for each recipient to be used as an input to KEA to generate that
recipient's pairwise KEK.

The following steps MUST be repeated for each recipient:

1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be
constructed.

2) A unique 128-byte originator's UKM MUST be generated.  The
originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET
STRING.

3) KEA MUST be used to generate the pairwise KEK based on the
originator's UKM, originator's private KEA key, recipient's 128-byte
public KEA key and recipient's 128-byte public KEA key used as the Rb
value.

4) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise
KEK as input to the FORTEZZA 80-bit wrap function.  The FORTEZZA 80-bit
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit check
value and produces a 96-bit result using the KEA-generated pairwise KEK.

5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.

6) The value of the subjectKeyIdentifier extension from the recipient's
KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey
rid rKeyId subjectKeyIdentifier field.  The KeyAgreeRecipientIdentifier
CHOICE MUST be rKeyId.  The date and other fields MUST be absent from
the RecipientEncryptedKey rid rKeyId SEQUENCE.

7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey
encryptedKey OCTET STRING.

8) The recipient's RecipientEncryptedKey MUST be the only
RecipientEncryptedKey present in the KeyAgreeRecipientInfo
recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.

9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo
MUST be included in the EnvelopedData RecipientInfos SET OF
RecipientInfo.


4.2.2.  SKIPJACK CEK Unwrap Process

1) Compliant software MUST be capable of processing EnvelopedData
objects constructed using the shared and/or unique originator UKM
options.  To support the shared UKM option, the receiving software MUST
be capable of searching for the recipient's RecipientEncryptedKey in a
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF
RecipientEncryptedKey.  To support the unique UKM option, the receiving
software MUST be capable of searching for the recipient's
RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF
RecipientInfo, with each RecipientInfo containing exactly one
RecipientEncryptedKey.  For each RecipientEncryptedKey, if the rid
rkeyId CHOICE is present, then the receiving software MUST attempt to
match the value of the subjectKeyIdentifier extension from the
recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid
rKeyId subjectKeyIdentifier field.  If the rid issuerAndSerialNumber
CHOICE is present, then the receiving software MUST attempt to match
the values of the issuer name and serial number from the recipient's
KEA X.509 v3 certificate with the RecipientEncryptedKey rid
issuerAndSerialNumber field.

2) The receiving software MUST extract the originator's UKM from the
ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that
includes the recipient's RecipientEncryptedKey.

3) The receiving software MUST locate the originator's KEA X.509 v3
certificate identified by the originator field contained in the same
KeyAgreeRecipientInfo that includes the recipient's
RecipientEncryptedKey.

4) KEA MUST be used to generate the pairwise KEK based on the
originator's UKM, originator's 128-byte public KEA key (extracted from
originator's KEA X.509 v3 certificate), recipient's private KEA key
(associated with recipient's KEA X.509 v3 certificate identified by the
RecipientEncryptedKey rid field) and the originator's 128-byte public KEA
key used as the Rb value.

5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated pairwise
KEK as input to the FORTEZZA 80-bit unwrap function.

6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK
unwrap process and the 8-byte IV obtained from the EnvelopedData
encryptedContentInfo contentEncryptionAlgorithm parameters field are
used as inputs to the SKIPJACK content decryption process to decrypt the
EnvelopedData encryptedContent.


4.3. "Previously Distributed" Symmetric KEK

This section describes the conventions for using KEA and SKIPJACK with
the CMS enveloped-data content type to support "previously distributed"
symmetric KEKs.  When a "previously distributed" symmetric KEK is used to
wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE
MUST be used. The methods by which KEA is used to generate the symmetric
KEK and by which the symmetric KEK is distributed are beyond the scope of
this document.

The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section
6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm
algorithm field MUST be the id-fortezzaWrap80 OID indicating that the
FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK.
The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent.
The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK
wrapped using the "previously distributed" symmetric KEK as input to the
FORTEZZA 80-bit wrap function.


5. Encrypted-data Conventions

The CMS encrypted-data content type consists of an encrypted content,
but no recipient information.  The method for conveying the SKIPJACK CEK
required to decrypt the encrypted-data encrypted content is beyond the
scope of this document.  Compliant software MUST meet the requirements
for constructing an encrypted-data content type stated [CMS] Section 8,
"Encrypted-data Content Type".  [CMS] Section 8 should be studied before
reading this section, because this section does not repeat the [CMS]
text.

The encrypted-data content type is ASN.1 encoded using the EncryptedData
syntax.  The fields of the EncryptedData syntax must be populated as
follows:

The EncryptedData version MUST be set according to [CMS] Section 8.

The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
algorithm field MUST be the id-fortezzaConfidentialityAlgorithm
OID.  The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
parameters field MUST include the random 8-byte IV used as the input to
the content encryption process.

The EncryptedData unprotectedAttrs MAY be present.


6. FORTEZZA 80-bit Wrap Function

The United States Government has not published the description of the
FORTEZZA 80-bit wrap function.


7.   SMIMECapabilities Attribute Conventions

RFC 2633, Section 2.5.2 defines the SMIMECapabilities signed attribute
(defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a
partial list of algorithms that the software announcing the
SMIMECapabilities can support.  When constructing a signedData object,
compliant software MAY include the SMIMECapabilities signed attribute
announcing that it supports the KEA and SKIPJACK algorithms.

The SMIMECapability SEQUENCE representing KEA MUST include the
id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include
a KeyWrapAlgorithm SEQUENCE in the parameters field.  The algorithm field of
KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID.  The parameters field of
KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD
be included in the key management algorithms portion of the
SMIMECapabilities list.  The SMIMECapability SEQUENCE representing KEA MUST
be DER-encoded as follows: 3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648
0165 0201 0117.

The SMIMECapability SEQUENCE representing SKIPJACK MUST include the
id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the
parameters field MUST be absent.  The SMIMECapability SEQUENCE for SKIPJACK
SHOULD be included in the symmetric encryption algorithms portion of the
SMIMECapabilities list.  The SMIMECapability SEQUENCE representing SKIPJACK
MUST be DER-encoded as follows: 300b 0609 6086 4801 6502 0101 0400.



8. Object Identifier Definitions

The following OIDs are specified in [INFO], but are repeated here for
the reader's convenience:

id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaConfidentialityAlgorithm (4)}

As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm
OID is present in the AlgorithmIdentifier algorithm field, then the
AlgorithmIdentifier parameters field MUST be present and MUST include
the SKIPJACK IV ASN.1 encoded using the following syntax:

Skipjack-Parm ::= SEQUENCE { initialization-vector   OCTET STRING }

Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding
conventions for the CMS content types including the enveloped-data and
encrypted-data content types in which the
id-fortezzaConfidentialityAlgorithm OID and parameters will be present.


id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)}


id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1)
fortezzaWrap80Algorithm (23)}


id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) kEAKeyEncryptionAlgorithm (24)}



A. References

[CMS] RFC 2630, Cryptographic Message Syntax, June 1999.

[KEA] RFC 2528, Representation of Key Exchange Algorithm (KEA) Keys in
Internet X.509 Public Key Infrastructure Certificates, March 1999.

[INFO] Registry of INFOSEC Technical Objects, 22 July 1999.

[MUSTSHOULD] RFC 2119, Key Words for Use in RFCs to Indicate
Requirement Levels.

[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0,
http://csrc.nist.gov/encryption/skipjack-kea.htm.

[USSUP1] Allied Communication Publication 120 (ACP120) Common
Security Protocol (CSP) United States (US) Supplement No. 1, June 1998;
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.


B. Acknowledgments

The following people have made significant contributions to this draft:
David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger,
Rich Nicholas, Bob Relyea and Jim Schaad.


C. Changes between CMSKEA-02 and CMSKEA-03:

1) Changed all section references to CMS to include section numbers
rather than just section titles.

2) Added Section 7, SMIMECapabilities Attribute Conventions.


D. Author's Address

John Pawling
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company
141 National Business Pkwy, Suite 210
Annapolis Junction, MD  20701
jsp@jgvandyke.com
(301) 939-2739
(410) 880-6095


E. Full Copyright Statement

   Copyright (C) The Internet Society (date).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process shall be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS 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.