draft-ietf-smime-cmskea-04.txt   rfc2876.txt 
INTERNET-DRAFT John Pawling
draft-ietf-smime-cmskea-04.txt J.G. Van Dyke & Associates
8 December 1999
Expires: 8 June 2000
CMS KEA and SKIPJACK Conventions Network Working Group J. Pawling
Request for Comments: 2876 WGSI, A Getronics Company
Category: Informational July 2000
Status of this Memo Use of the KEA and SKIPJACK Algorithms in CMS
This document is an Internet-Draft and is in full conformance with all Status of this Memo
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 This memo provides information for the Internet community. It does
and may be updated, replaced, or obsoleted by other documents at any not specify an Internet standard of any kind. Distribution of this
time. It is inappropriate to use Internet-Drafts as reference material memo is unlimited.
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2000). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes the conventions for using the Key Exchange This document describes the conventions for using the Key Exchange
Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with
Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-
content types. 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 1. Introduction
Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY are Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY
used in capital letters. This conforms to the definitions in are used in capital letters. This conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
make the intent of standards track documents as clear as possible. The make the intent of standards track documents as clear as possible.
same key words are used in this document to help implementers achieve The same key words are used in this document to help implementers
interoperability. Software that claims compliance with this document achieve interoperability. Software that claims compliance with this
MUST provide the capabilities as indicated by the MUST, MUST NOT, document MUST provide the capabilities as indicated by the MUST, MUST
SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are NOT, SHOULD and MAY terms. The KEA and SKIPJACK cryptographic
described in [SJ-KEA]. algorithms are described in [SJ-KEA].
2. Content Encryption Process 2. Content Encryption Process
This section applies to the construction of both the enveloped-data and This section applies to the construction of both the enveloped-data
encrypted-data content types. Compliant software MUST meet the and encrypted-data content types. Compliant software MUST meet the
requirements stated in [CMS] Section 6.3, "Content-encryption Process". requirements stated in [CMS] Section 6.3, "Content-encryption
The input to the encryption process MUST be padded to a multiple of Process". The input to the encryption process MUST be padded to a
eight octets using the padding rules described in [CMS] Section 6.3. multiple of eight octets using the padding rules described in [CMS]
The content MUST be encrypted as a single string using the SKIPJACK Section 6.3. The content MUST be encrypted as a single string using
algorithm in 64-bit Cipher Block Chaining (CBC) mode using the SKIPJACK algorithm in 64-bit Cipher Block Chaining (CBC) mode
randomly-generated 8-byte Initialization Vector (IV) and 80-bit using randomly-generated 8-byte Initialization Vector (IV) and 80-bit
SKIPJACK content-encryption key (CEK) values. SKIPJACK content-encryption key (CEK) values.
3. Content Decryption Process 3. Content Decryption Process
This section applies to the processing of both the enveloped-data and This section applies to the processing of both the enveloped-data and
encrypted-data content types. The encryptedContent MUST be decrypted as encrypted-data content types. The encryptedContent MUST be decrypted
a single string using the SKIPJACK algorithm in 64-bit CBC mode. The 80- as a single string using the SKIPJACK algorithm in 64-bit CBC mode.
bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to the SKIPJACK The 80-bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to
decryption process. Following decryption, the padding MUST be removed the SKIPJACK decryption process. Following decryption, the padding
from the decrypted data. The padding rules are described in [CMS] MUST be removed from the decrypted data. The padding rules are
Section 6.3, "Content-encryption Process". described in [CMS] Section 6.3, "Content-encryption Process".
4. Enveloped-data Conventions 4. Enveloped-data Conventions
The CMS enveloped-data content type consists of an encrypted content and The CMS enveloped-data content type consists of an encrypted content
wrapped CEKs for one or more recipients. Compliant software MUST and wrapped CEKs for one or more recipients. Compliant software MUST
meet the requirements for constructing an enveloped-data content type meet the requirements for constructing an enveloped-data content type
stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS] Section 6 stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS]
should be studied before reading this section, because this section Section 6 should be studied before reading this section, because this
does not repeat the [CMS] text. section does not repeat the [CMS] text.
An 8-byte IV and 80-bit CEK MUST be randomly generated for each instance An 8-byte IV and 80-bit CEK MUST be randomly generated for each
of an enveloped-data content type as inputs to the SKIPJACK algorithm for instance of an enveloped-data content type as inputs to the SKIPJACK
use to encrypt the content. The SKIPJACK CEK MUST only be used for algorithm for use to encrypt the content. The SKIPJACK CEK MUST only
encrypting the content of a single instance of an enveloped-data content be used for encrypting the content of a single instance of an
type. enveloped-data content type.
KEA and SKIPJACK can be used with the enveloped-data content type using KEA and SKIPJACK can be used with the enveloped-data content type
either of the following key management techniques defined in [CMS] using either of the following key management techniques defined in
Section 6: [CMS] Section 6:
1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for each 1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for each
recipient using a pairwise symmetric key-encryption key (KEK) generated recipient using a pairwise symmetric key-encryption key (KEK)
using KEA using the originator's private KEA key, recipient's public KEA generated using KEA using the originator's private KEA key,
key and other values. Section 4.2 provides additional details. recipient's public KEA key and other values. Section 4.2 provides
additional details.
2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped 2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is
using a "previously distributed" symmetric KEK (such as a Mail List Key). wrapped using a "previously distributed" symmetric KEK (such as a
The methods by which the symmetric KEK is generated and distributed are Mail List Key). The methods by which the symmetric KEK is
beyond the scope of this document. Section 4.3 provides more details. generated and distributed are beyond the scope of this document.
Section 4.3 provides more details.
[CMS] Section 6 also defines the concept of the key transport key [CMS] Section 6 also defines the concept of the key transport key
management technique. The key transport technique MUST NOT be used with management technique. The key transport technique MUST NOT be used
KEA. with KEA.
4.1. EnvelopedData Fields 4.1. EnvelopedData Fields
The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1) The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1)
encoded using the EnvelopedData syntax. The fields of the EnvelopedData encoded using the EnvelopedData syntax. The fields of the
syntax must be populated as follows: EnvelopedData syntax must be populated as follows:
The EnvelopedData version MUST be 2. The EnvelopedData version MUST be 2.
If key agreement is being used, then the EnvelopedData originatorInfo If key agreement is being used, then the EnvelopedData originatorInfo
field SHOULD be present and SHOULD include the originator's KEA X.509 v3 field SHOULD be present and SHOULD include the originator's KEA X.509
certificate containing the KEA public key associated with the KEA private v3 certificate containing the KEA public key associated with the KEA
key used to form each pairwise symmetric KEK used to wrap each copy of private key used to form each pairwise symmetric KEK used to wrap
the SKIPJACK CEK. The issuers' X.509 v3 certificates required to form each copy of the SKIPJACK CEK. The issuers' X.509 v3 certificates
the complete certification path for the originator's KEA X.509 v3 required to form the complete certification path for the originator's
certificate MAY be included in the EnvelopedData originatorInfo field. KEA X.509 v3 certificate MAY be included in the EnvelopedData
Self-signed certificates SHOULD NOT be included in the EnvelopedData originatorInfo field. Self-signed certificates SHOULD NOT be included
originatorInfo field. in the EnvelopedData originatorInfo field.
The EnvelopedData RecipientInfo CHOICE is dependent on the key management The EnvelopedData RecipientInfo CHOICE is dependent on the key
technique used. Sections 4.2 and 4.3 provide more information. management technique used. Sections 4.2 and 4.3 provide more
information.
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
algorithm field MUST be the id-fortezzaConfidentialityAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm
object identifier (OID). The EnvelopedData encryptedContentInfo object identifier (OID). The EnvelopedData encryptedContentInfo
contentEncryptionAlgorithm parameters field MUST include the random 8- contentEncryptionAlgorithm parameters field MUST include the random
byte IV used as the input to the content encryption process. 8-byte IV used as the input to the content encryption process.
The EnvelopedData unprotectedAttrs MAY be present. The EnvelopedData unprotectedAttrs MAY be present.
4.2. Key Agreement 4.2. Key Agreement
This section describes the conventions for using KEA and SKIPJACK with This section describes the conventions for using KEA and SKIPJACK
the CMS enveloped-data content type to support key agreement. When key with the CMS enveloped-data content type to support key agreement.
agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE When key agreement is used, then the RecipientInfo
MUST be used. keyAgreeRecipientInfo CHOICE MUST be used.
If the EnvelopedData originatorInfo field does not include the If the EnvelopedData originatorInfo field does not include the
originator's KEA X.509 v3 certificate, then each recipientInfos originator's KEA X.509 v3 certificate, then each recipientInfos
KeyAgreementRecipientInfo originator field MUST include the KeyAgreementRecipientInfo originator field MUST include the
issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3 issuerAndSerialNumber CHOICE identifying the originator's KEA X.509
certificate. If the EnvelopedData originatorInfo field includes the v3 certificate. If the EnvelopedData originatorInfo field includes
originator's KEA X.509 v3 certificate, then each recipientInfos the originator's KEA X.509 v3 certificate, then each recipientInfos
KeyAgreementRecipientInfo originator field MUST include either the KeyAgreementRecipientInfo originator field MUST include either the
subjectKeyIdentifier CHOICE containing the value from the subjectKeyIdentifier CHOICE containing the value from the
subjectKeyIdentifier extension of the originator's KEA X.509 v3 subjectKeyIdentifier extension of the originator's KEA X.509 v3
certificate or the issuerAndSerialNumber CHOICE identifying the certificate or the issuerAndSerialNumber CHOICE identifying the
originator's KEA X.509 v3 certificate. To minimize the size of the originator's KEA X.509 v3 certificate. To minimize the size of the
EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE
used. be used.
In some environments, the KeyAgreementRecipientInfo originator field MAY In some environments, the KeyAgreementRecipientInfo originator field
include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be MAY include the originatorKey CHOICE. The originatorKey CHOICE
used with KEA for e-mail transactions. Within a controlled security SHOULD NOT be used with KEA for e-mail transactions. Within a
architecture, a module may produce KEA key pairs for use in conjunction controlled security architecture, a module may produce KEA key pairs
with internal/local storage of encrypted data. In this case, there may for use in conjunction with internal/local storage of encrypted data.
not be an X.509 certificate associated with a (possibly) short term or In this case, there may not be an X.509 certificate associated with a
one time use public KEA key. When originatorKey is used, then the KEA (possibly) short term or one time use public KEA key. When
public key MUST be conveyed in the publicKey BIT STRING as specified in originatorKey is used, then the KEA public key MUST be conveyed in
[KEA] Section 3.1.2. The originatorKey algorithm identifier MUST be the the publicKey BIT STRING as specified in [KEA] Section 3.1.2. The
id-keyExchangeAlgorithm OID. The originatorKey algorithm parameters originatorKey algorithm identifier MUST be the id-
field MUST contain the KEA "domain identifier" (ASN.1 encoded as an OCTET keyExchangeAlgorithm OID. The originatorKey algorithm parameters
STRING) identifying the KEA algorithm parameters (i.e., p/q/g values) field MUST contain the KEA "domain identifier" (ASN.1 encoded as an
associated with the KEA public key. [KEA] Section 3.1.1 describes the OCTET STRING) identifying the KEA algorithm parameters (i.e., p/q/g
method for computing the KEA domain identifier value. 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 4.2.1. SKIPJACK CEK Wrap Process
The SKIPJACK CEK is uniquely wrapped for each recipient of the The SKIPJACK CEK is uniquely wrapped for each recipient of the
EnvelopedData using a pairwise KEK generated using the KEA EnvelopedData using a pairwise KEK generated using the KEA material
material of the originator and the recipient along with the of the originator and the recipient along with the originator's User
originator's User Keying Material (UKM) (i.e. Ra). The CMS Keying Material (UKM) (i.e. Ra). The CMS EnvelopedData syntax
EnvelopedData syntax provides two options for wrapping the SKIPJACK provides two options for wrapping the SKIPJACK CEK for each recipient
CEK for each recipient using a KEA-generated KEK. The "shared using a KEA-generated KEK. The "shared Originator UKM" option SHOULD
Originator UKM" option SHOULD be used when constructing EnvelopedData be used when constructing EnvelopedData objects. The "unique
objects. The "unique originator UKM" option MAY be used when originator UKM" option MAY be used when constructing EnvelopedData
constructing EnvelopedData objects. Compliant software MUST be capable objects. Compliant software MUST be capable of processing
of processing EnvelopedData objects constructed using both options. EnvelopedData objects constructed using both options.
1) Shared Originator UKM Option: CMS provides the ability for a 1) Shared Originator UKM Option: CMS provides the ability for a
single, shared originator's UKM to be used to generate each pairwise single, shared originator's UKM to be used to generate each pairwise
KEK used to wrap the SKIPJACK CEK for each recipient. When using KEK used to wrap the SKIPJACK CEK for each recipient. When using the
the shared originator UKM option, a single RecipientInfo shared originator UKM option, a single RecipientInfo
KeyAgreeRecipientInfo structure MUST be constructed to contain the KeyAgreeRecipientInfo structure MUST be constructed to contain the
wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same
KEA parameters. The KeyAgreeRecipientInfo structure includes multiple KEA parameters. The KeyAgreeRecipientInfo structure includes
RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped multiple RecipientEncryptedKey fields that each contain the SKIPJACK
for a specific recipient. CEK wrapped for a specific recipient.
2) Unique Originator UKM Option: CMS also provides the ability for a 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 unique originator UKM to be used to generate each pairwise KEK used
wrap the SKIPJACK CEK for each recipient. When using the unique to wrap the SKIPJACK CEK for each recipient. When using the unique
originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo
structure MUST be constructed for each recipient. Each structure MUST be constructed for each recipient. Each
KeyAgreeRecipientInfo structure includes a single RecipientEncryptedKey KeyAgreeRecipientInfo structure includes a single
field containing the SKIPJACK CEK wrapped for the recipient. This RecipientEncryptedKey field containing the SKIPJACK CEK wrapped for
option requires more overhead than the shared UKM option because the the recipient. This option requires more overhead than the shared
KeyAgreeRecipientInfo fields (i.e. version, originator, ukm, UKM option because the KeyAgreeRecipientInfo fields (i.e. version,
keyEncryptionAlgorithm) must be repeated for each recipient. originator, ukm, keyEncryptionAlgorithm) must be repeated for each
recipient.
The next two paragraphs apply to both options. The next two paragraphs apply to both options.
The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST
include the id-kEAKeyEncryptionAlgorithm OID. The KeyAgreeRecipientInfo include the id-kEAKeyEncryptionAlgorithm OID. The
keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field MUST
as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field contain a KeyWrapAlgorithm as specified in [CMS] Appendix A, "ASN.1
of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that Module". The algorithm field of KeyWrapAlgorithm MUST be the id-
the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function
CEK. Since the FORTEZZA 80-bit wrap function includes an integrity is used to wrap the 80-bit SKIPJACK CEK. Since the FORTEZZA 80-bit
check value, the wrapped SKIPJACK key is 96 bits long. The parameters wrap function includes an integrity check value, the wrapped SKIPJACK
field of KeyWrapAlgorithm MUST be absent. key is 96 bits long. The parameters field of KeyWrapAlgorithm MUST
be absent.
If the originator is not already an explicit recipient, then a copy of If the originator is not already an explicit recipient, then a copy
the SKIPJACK CEK SHOULD be wrapped for the originator and included in of the SKIPJACK CEK SHOULD be wrapped for the originator and included
the EnvelopedData. This allows the originator to decrypt the contents in the EnvelopedData. This allows the originator to decrypt the
of the EnvelopedData. contents of the EnvelopedData.
4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM Value 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 This section describes how a shared originator UKM value is used as
input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK an input to KEA to generate each pairwise KEK used to wrap the
for each recipient. SKIPJACK CEK for each recipient.
When using the shared originator UKM option, a single RecipientInfo When using the shared originator UKM option, a single RecipientInfo
KeyAgreeRecipientInfo structure MUST be constructed to contain the KeyAgreeRecipientInfo structure MUST be constructed to contain the
wrapped SKIPJACK CEKs for all of the KEA recipients using the same wrapped SKIPJACK CEKs for all of the KEA recipients using the same
set of KEA parameters. If all recipients' KEA public keys were set of KEA parameters. If all recipients' KEA public keys were
generated using the same set of KEA parameters, then there MUST only be generated using the same set of KEA parameters, then there MUST only
a single RecipientInfo KeyAgreeRecipientInfo structure for all of the be a single RecipientInfo KeyAgreeRecipientInfo structure for all of
KEA recipients. If the recipients' KEA public keys were generated the KEA recipients. If the recipients' KEA public keys were
using different sets of KEA parameters, then multiple RecipientInfo generated using different sets of KEA parameters, then multiple
KeyAgreeRecipientInfo fields MUST be constructed because the RecipientInfo KeyAgreeRecipientInfo fields MUST be constructed
originatorIdentifierOrKey will be different for each distinct set of because the originatorIdentifierOrKey will be different for each
recipients' KEA parameters. distinct set of recipients' KEA parameters.
A unique 128-byte originator's UKM MUST be generated for each distinct A unique 128-byte originator's UKM MUST be generated for each
set of recipients' KEA parameters. The originator's UKM MUST be placed distinct set of recipients' KEA parameters. The originator's UKM
in each KeyAgreeRecipientInfo ukm OCTET STRING. MUST be placed in each KeyAgreeRecipientInfo ukm OCTET STRING.
The originator's and recipient's KEA parameters MUST be identical to use The originator's and recipient's KEA parameters MUST be identical to
KEA to successfully generate a pairwise KEK. [KEA] describes how a KEA use KEA to successfully generate a pairwise KEK. [KEA] describes how
public key is conveyed in an X.509 v3 certificate. [KEA] states that the a KEA public key is conveyed in an X.509 v3 certificate. [KEA]
KEA parameters are not included in KEA certificates; instead, a "domain states that the KEA parameters are not included in KEA certificates;
identifier" is supplied in the subjectPublicKeyInfo algorithm parameters instead, a "domain identifier" is supplied in the
field of every KEA certificate. The values of the KEA domain identifiers subjectPublicKeyInfo algorithm parameters field of every KEA
in the originator's and recipient's KEA X.509 v3 certificates can be certificate. The values of the KEA domain identifiers in the
compared to determine if the originator's and recipient's KEA parameters originator's and recipient's KEA X.509 v3 certificates can be
are identical. compared to determine if the originator's and recipient's KEA
parameters are identical.
The following steps MUST be repeated for each recipient: The following steps MUST be repeated for each recipient:
1) KEA MUST be used to generate the pairwise KEK based on the 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 originator's UKM, originator's private KEA key, recipient's 128
public KEA key (obtained from the recipient's KEA X.509 v3 certificate) byte public KEA key (obtained from the recipient's KEA X.509 v3
and the recipient's 128-byte public KEA key used as the Rb value. 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 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 KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a
checkvalue and produces a 96-bit result using the KEA-generated pairwise 16-bit integrity checkvalue and produces a 96-bit result using the
KEK. KEA-generated pairwise KEK.
3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the 3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the
recipient. recipient.
4) The value of the subjectKeyIdentifier extension from the recipient's 4) The value of the subjectKeyIdentifier extension from the
KEA X.509 v3 certificate MUST be placed in the recipient's recipient's KEA X.509 v3 certificate MUST be placed in the
RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The recipient's RecipientEncryptedKey rid rKeyId subjectKeyIdentifier
KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId.
fields MUST be absent from the recipientEncryptedKey rid rKeyId The date and other fields MUST be absent from the
SEQUENCE. recipientEncryptedKey rid rKeyId SEQUENCE.
5) The wrapped SKIPJACK CEK MUST be placed in the recipient's 5) The wrapped SKIPJACK CEK MUST be placed in the recipient's
RecipientEncryptedKey encryptedKey OCTET STRING. RecipientEncryptedKey encryptedKey OCTET STRING.
6) The recipient's RecipientEncryptedKey MUST be included in the 6) The recipient's RecipientEncryptedKey MUST be included in the
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF
RecipientEncryptedKey. RecipientEncryptedKey.
4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values 4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values
This section describes how a unique originator UKM value is generated 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 for each recipient to be used as an input to KEA to generate that
recipient's pairwise KEK. recipient's pairwise KEK.
The following steps MUST be repeated for each recipient: The following steps MUST be repeated for each recipient:
1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be 1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be
constructed. constructed.
2) A unique 128-byte originator's UKM MUST be generated. The 2) A unique 128-byte originator's UKM MUST be generated. The
originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm
STRING. OCTET STRING.
3) KEA MUST be used to generate the pairwise KEK based on the 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 originator's UKM, originator's private KEA key, recipient's 128-
public KEA key and recipient's 128-byte public KEA key used as the Rb byte public KEA key and recipient's 128-byte public KEA key used
value. as the Rb value.
4) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise 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 KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a
integrity check value and produces a 96-bit result using the 16-bit integrity check value and produces a 96-bit result using
KEA-generated pairwise KEK. the KEA-generated pairwise KEK.
5) A new RecipientEncryptedKey SEQUENCE MUST be constructed. 5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.
6) The value of the subjectKeyIdentifier extension from the recipient's 6) The value of the subjectKeyIdentifier extension from the
KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey recipient's KEA X.509 v3 certificate MUST be placed in the
rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The
CHOICE MUST be rKeyId. The date and other fields MUST be absent from KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and
the RecipientEncryptedKey rid rKeyId SEQUENCE. other fields MUST be absent from the RecipientEncryptedKey rid
rKeyId SEQUENCE.
7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey 7) The wrapped SKIPJACK CEK MUST be placed in the
encryptedKey OCTET STRING. RecipientEncryptedKey encryptedKey OCTET STRING.
8) The recipient's RecipientEncryptedKey MUST be the only 8) The recipient's RecipientEncryptedKey MUST be the only
RecipientEncryptedKey present in the KeyAgreeRecipientInfo RecipientEncryptedKey present in the KeyAgreeRecipientInfo
recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey. recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo 9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo
MUST be included in the EnvelopedData RecipientInfos SET OF MUST be included in the EnvelopedData RecipientInfos SET OF
RecipientInfo. RecipientInfo.
4.2.2. SKIPJACK CEK Unwrap Process 4.2.2. SKIPJACK CEK Unwrap Process
This section describes the recipient processing using KEA to generate the This section describes the recipient processing using KEA to generate
SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK. the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK.
1) Compliant software MUST be capable of processing EnvelopedData 1) Compliant software MUST be capable of processing EnvelopedData
objects constructed using both the shared and the unique originator UKM objects constructed using both the shared and the unique
options. To support the shared UKM option, the receiving software MUST originator UKM options. To support the shared UKM option, the
be capable of searching for the recipient's RecipientEncryptedKey in a receiving software MUST be capable of searching for the
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF recipient's RecipientEncryptedKey in a KeyAgreeRecipientInfo
RecipientEncryptedKey. To support the unique UKM option, the receiving recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey. To
software MUST be capable of searching for the recipient's support the unique UKM option, the receiving software MUST be
RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF capable of searching for the recipient's RecipientEncryptedKey in
RecipientInfo, with each RecipientInfo containing exactly one the EnvelopedData recipientInfos SET OF RecipientInfo, with each
RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid RecipientInfo containing exactly one RecipientEncryptedKey. For
rkeyId CHOICE is present, then the receiving software MUST attempt to each RecipientEncryptedKey, if the rid rkeyId CHOICE is present,
match the value of the subjectKeyIdentifier extension from the then the receiving software MUST attempt to match the value of the
recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid subjectKeyIdentifier extension from the recipient's KEA X.509 v3
rKeyId subjectKeyIdentifier field. If the rid issuerAndSerialNumber certificate with the RecipientEncryptedKey rid rKeyId
CHOICE is present, then the receiving software MUST attempt to match subjectKeyIdentifier field. If the rid issuerAndSerialNumber
the values of the issuer name and serial number from the recipient's CHOICE is present, then the receiving software MUST attempt to
KEA X.509 v3 certificate with the RecipientEncryptedKey rid match the values of the issuer name and serial number from the
issuerAndSerialNumber field. 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 2) The receiving software MUST extract the originator's UKM from the
ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that
includes the recipient's RecipientEncryptedKey. includes the recipient's RecipientEncryptedKey.
3) The receiving software MUST locate the originator's KEA X.509 v3 3) The receiving software MUST locate the originator's KEA X.509 v3
certificate identified by the originator field contained in the same certificate identified by the originator field contained in the
KeyAgreeRecipientInfo that includes the recipient's same KeyAgreeRecipientInfo that includes the recipient's
RecipientEncryptedKey. RecipientEncryptedKey.
4) KEA MUST be used to generate the pairwise KEK based on the 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 UKM, originator's 128-byte public KEA key (extracted
originator's KEA X.509 v3 certificate), recipient's private KEA key from originator's KEA X.509 v3 certificate), recipient's private
(associated with recipient's KEA X.509 v3 certificate identified by the KEA key (associated with recipient's KEA X.509 v3 certificate
RecipientEncryptedKey rid field) and the originator's 128-byte public KEA identified by the RecipientEncryptedKey rid field) and the
key used as the Rb value. originator's 128-byte public KEA key used as the Rb value.
5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated pairwise 5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated
KEK as input to the FORTEZZA 80-bit unwrap function. pairwise KEK as input to the FORTEZZA 80-bit unwrap function.
6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK 6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK
unwrap process and the 8-byte IV obtained from the EnvelopedData unwrap process and the 8-byte IV obtained from the EnvelopedData
encryptedContentInfo contentEncryptionAlgorithm parameters field are encryptedContentInfo contentEncryptionAlgorithm parameters field
used as inputs to the SKIPJACK content decryption process to decrypt the are used as inputs to the SKIPJACK content decryption process to
EnvelopedData encryptedContent. decrypt the EnvelopedData encryptedContent.
4.3. "Previously Distributed" Symmetric KEK 4.3. "Previously Distributed" Symmetric KEK
This section describes the conventions for using SKIPJACK with This section describes the conventions for using SKIPJACK with the
the CMS enveloped-data content type to support "previously distributed" CMS enveloped-data content type to support "previously distributed"
symmetric KEKs. When a "previously distributed" symmetric KEK is used to symmetric KEKs. When a "previously distributed" symmetric KEK is
wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE used to wrap the SKIPJACK CEK, then the RecipientInfo
MUST be used. The methods used to generate and distribute the symmetric KEK KEKRecipientInfo CHOICE MUST be used. The methods used to generate
are beyond the scope of this document. and distribute the symmetric KEK are beyond the scope of this
document.
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section The KEKRecipientInfo fields MUST be populated as specified in [CMS]
6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm Section 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo
algorithm field MUST be the id-fortezzaWrap80 OID indicating that the keyEncryptionAlgorithm algorithm field MUST be the id-fortezzaWrap80
FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. The OID indicating that the FORTEZZA 80-bit wrap function is used to wrap
KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. the 80-bit SKIPJACK CEK. The KEKRecipientInfo keyEncryptionAlgorithm
The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK parameters field MUST be absent. The KEKRecipientInfo encryptedKey
wrapped using the "previously distributed" symmetric KEK as input to the field MUST include the SKIPJACK CEK wrapped using the "previously
FORTEZZA 80-bit wrap function. distributed" symmetric KEK as input to the FORTEZZA 80-bit wrap
function.
5. Encrypted-data Conventions 5. Encrypted-data Conventions
The CMS encrypted-data content type consists of an encrypted content, The CMS encrypted-data content type consists of an encrypted content,
but no recipient information. The method for conveying the SKIPJACK CEK but no recipient information. The method for conveying the SKIPJACK
required to decrypt the encrypted-data encrypted content is beyond the CEK required to decrypt the encrypted-data encrypted content is
scope of this document. Compliant software MUST meet the requirements beyond the scope of this document. Compliant software MUST meet the
for constructing an encrypted-data content type stated [CMS] Section 8, requirements for constructing an encrypted-data content type stated
"Encrypted-data Content Type". [CMS] Section 8 should be studied before [CMS] Section 8, "Encrypted-data Content Type". [CMS] Section 8
reading this section, because this section does not repeat the [CMS] should be studied before reading this section, because this section
text. does not repeat the [CMS] text.
The encrypted-data content type is ASN.1 encoded using the EncryptedData The encrypted-data content type is ASN.1 encoded using the
syntax. The fields of the EncryptedData syntax must be populated as EncryptedData syntax. The fields of the EncryptedData syntax must be
follows: populated as follows:
The EncryptedData version MUST be set according to [CMS] Section 8. The EncryptedData version MUST be set according to [CMS] Section 8.
The EncryptedData encryptedContentInfo contentEncryptionAlgorithm The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
algorithm field MUST be the id-fortezzaConfidentialityAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm OID.
OID. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
parameters field MUST include the random 8-byte IV used as the input to parameters field MUST include the random 8-byte IV used as the input
the content encryption process. to the content encryption process.
The EncryptedData unprotectedAttrs MAY be present. The EncryptedData unprotectedAttrs MAY be present.
6. FORTEZZA 80-bit Wrap Function 6. FORTEZZA 80-bit Wrap Function
The United States Government has not published the description of the The United States Government has not published the description of the
FORTEZZA 80-bit wrap function. FORTEZZA 80-bit wrap function.
7. SMIMECapabilities Attribute Conventions 7. SMIMECapabilities Attribute Conventions
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed
(defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be
partial list of algorithms that the software announcing the used to specify a partial list of algorithms that the software
SMIMECapabilities can support. When constructing a signedData object, announcing the SMIMECapabilities can support. When constructing a
compliant software MAY include the SMIMECapabilities signed attribute signedData object, compliant software MAY include the
announcing that it supports the KEA and SKIPJACK algorithms. SMIMECapabilities signed attribute announcing that it supports the
KEA and SKIPJACK algorithms.
The SMIMECapability SEQUENCE representing KEA MUST include the The SMIMECapability SEQUENCE representing KEA MUST include the id-
id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST
a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of include a KeyWrapAlgorithm SEQUENCE in the parameters field. The
KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID. The parameters field of algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80
KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD OID. The parameters field of KeyWrapAlgorithm MUST be absent. The
be included in the key management algorithms portion of the SMIMECapability SEQUENCE for KEA SHOULD be included in the key
SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST management algorithms portion of the SMIMECapabilities list. The
be DER-encoded as the following hexadecimal string: SMIMECapability SEQUENCE representing KEA MUST be DER-encoded as the
3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117. following hexadecimal string:
The SMIMECapability SEQUENCE representing SKIPJACK MUST include the 3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117
id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the
parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK The SMIMECapability SEQUENCE representing SKIPJACK MUST include the
SHOULD be included in the symmetric encryption algorithms portion of the id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and
SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK the parameters field MUST be absent. The SMIMECapability SEQUENCE
MUST be DER-encoded as the following hexadecimal string: for SKIPJACK SHOULD be included in the symmetric encryption
300b 0609 6086 4801 6502 0101 0400. algorithms portion of the SMIMECapabilities list. The
SMIMECapability SEQUENCE representing SKIPJACK MUST be DER-encoded as
the following hexadecimal string:
300b 0609 6086 4801 6502 0101 0400
8. Object Identifier Definitions 8. Object Identifier Definitions
The following OIDs are specified in [INFO], but are repeated here for The following OIDs are specified in [INFO], but are repeated here for
the reader's convenience: the reader's convenience:
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1) country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)} 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-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16) id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
fortezzaWrap80Algorithm (23)} infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}
id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-
country(16) us(840) organization(1) gov(101) dod(2) infosec(1) iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
algorithms(1) kEAKeyEncryptionAlgorithm (24)} infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-iso- As specified in [USSUP1], when the id-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) fortezzaConfidentialityAlgorithm OID is present in the
algorithms(1) fortezzaConfidentialityAlgorithm (4)} AlgorithmIdentifier algorithm field, then the AlgorithmIdentifier
parameters field MUST be present and MUST include the SKIPJACK IV
ASN.1 encoded using the following syntax:
As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
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.
Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding References
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.
A. References [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[CMS] RFC 2630, Cryptographic Message Syntax, June 1999. [KEA] Housley, R. and W. Polk, "Representation of Key Exchange
Algorithm (KEA) Keys in Internet X.509 Public Key
Infrastructure Certificates", RFC 2528, March 1999.
[KEA] RFC 2528, Representation of Key Exchange Algorithm (KEA) Keys in [INFO] Registry of INFOSEC Technical Objects, 22 July 1999.
Internet X.509 Public Key Infrastructure Certificates, March 1999.
[INFO] Registry of INFOSEC Technical Objects, 22 July 1999. [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
[MSG] RFC 2633, S/MIME Version 3 Message Specification, June 1999. [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] RFC 2119, Key Words for Use in RFCs to Indicate [SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0,
Requirement Levels. http://csrc.nist.gov/encryption/skipjack-kea.htm.
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0, [USSUP1] Allied Communication Publication 120 (ACP120) Common
http://csrc.nist.gov/encryption/skipjack-kea.htm. Security Protocol (CSP) United States (US) Supplement
No. 1, June 1998;
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.
[USSUP1] Allied Communication Publication 120 (ACP120) Common Acknowledgments
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
memo: David Dalkowski, Phillip Griffin, Russ Housley, Pierce
Leonberger, Rich Nicholas, Bob Relyea and Jim Schaad.
The following people have made significant contributions to this draft: Author's Address
David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger,
Rich Nicholas, Bob Relyea and Jim Schaad.
C. Author's Address John Pawling
Wang Government Services, Inc. (WGSI),
A Getronics Company
141 National Business Pkwy, Suite 210
Annapolis Junction, MD 20701
John Pawling Phone: (301) 939-2739
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company (410) 880-6095
141 National Business Pkwy, Suite 210 EMail: john.pawling@wang.com
Annapolis Junction, MD 20701
john.pawling@wang.com
(301) 939-2739
(410) 880-6095
D. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This revoked by the Internet Society or its successors or assigns.
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK This document and the information contained herein is provided on an
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 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. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 98 change blocks. 
409 lines changed or deleted 420 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/