draft-ietf-smime-cmskea-03.txt   draft-ietf-smime-cmskea-04.txt 
INTERNET-DRAFT John Pawling INTERNET-DRAFT John Pawling
draft-ietf-smime-cmskea-03.txt J.G. Van Dyke & Associates draft-ietf-smime-cmskea-04.txt J.G. Van Dyke & Associates
2 December 1999 8 December 1999
Expires: 2 June 2000 Expires: 8 June 2000
CMS KEA and SKIPJACK Conventions CMS KEA and SKIPJACK Conventions
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at line 95 skipping to change at line 95
encrypting the content of a single instance of an enveloped-data content encrypting the content of a single instance of an enveloped-data content
type. 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 using
either of the following key management techniques defined in [CMS] either of the following key management techniques defined in [CMS]
Section 6: 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) generated
using KEA using the originator's private KEA key, recipient's public KEA 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 key and other values. Section 4.2 provides additional details.
to provide key agreement.
2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped 2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped
using a "previously distributed" symmetric KEK (such as a Mail List Key) 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 The methods by which the symmetric KEK is generated and distributed are
symmetric KEK and by which the symmetric KEK is distributed are beyond beyond the scope of this document. Section 4.3 provides more details.
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 [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 with
KEA. 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 EnvelopedData
syntax must be populated as follows: syntax must be populated as follows:
skipping to change at line 153 skipping to change at line 150
MUST be used. 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 v3
certificate. If the EnvelopedData originatorInfo field includes the certificate. If the EnvelopedData originatorInfo field includes 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 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 v3 X.509 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 be
used. used.
In some environments, the KeyAgreementRecipientInfo originator field MAY In some environments, the KeyAgreementRecipientInfo originator field MAY
include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be
used with KEA for e-mail transactions. Within a controlled security used with KEA for e-mail transactions. Within a controlled security
architecture, a module may produce KEA key pairs for use in conjunction architecture, a module may produce KEA key pairs for use in conjunction
with internal/local storage of encrypted data. In this case, there may with internal/local storage of encrypted data. In this case, there may
skipping to change at line 185 skipping to change at line 182
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 of the originator and the recipient along with the material of the originator and the recipient along with the
originator's User Keying Material (UKM) (i.e. Ra). The CMS originator's User Keying Material (UKM) (i.e. Ra). The CMS
EnvelopedData syntax provides two options for wrapping the SKIPJACK EnvelopedData syntax provides two options for wrapping the SKIPJACK
CEK for each recipient using a KEA-generated KEK. The "shared CEK for each recipient using a KEA-generated KEK. The "shared
Originator UKM" option SHOULD be used when constructing EnvelopedData Originator UKM" option SHOULD be used when constructing EnvelopedData
objects. The "unique originator UKM" option MAY be used when objects. The "unique originator UKM" option MAY be used when
constructing EnvelopedData objects. Compliant software MUST be capable constructing EnvelopedData objects. Compliant software MUST be capable
of processing EnvelopedData objects constructed using either option or of processing EnvelopedData objects constructed using both options.
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 shared originator UKM option, a single RecipientInfo 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 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 multiple
RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped
for a specific recipient. for a specific recipient.
skipping to change at line 217 skipping to change at line 213
keyEncryptionAlgorithm) must be repeated for each recipient. 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 KeyAgreeRecipientInfo
keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm
as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field
of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that
the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK
CEK. The parameters field of KeyWrapAlgorithm MUST be absent. CEK. Since the FORTEZZA 80-bit wrap function includes an integrity
check value, the wrapped SKIPJACK 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 of
the SKIPJACK CEK SHOULD be wrapped for the originator and included in the SKIPJACK CEK SHOULD be wrapped for the originator and included in
the EnvelopedData. This allows the originator to decrypt the contents the EnvelopedData. This allows the originator to decrypt the contents
of the EnvelopedData. 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 an
input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK
skipping to change at line 265 skipping to change at line 263
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 byte
public KEA key (obtained from the recipient's KEA X.509 v3 certificate) 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. 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 80-bit
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit check wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity
value and produces a 96-bit result using the KEA-generated pairwise KEK. checkvalue and produces a 96-bit result using the 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 recipient's
KEA X.509 v3 certificate MUST be placed in the recipient's KEA X.509 v3 certificate MUST be placed in the recipient's
RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The
KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other
fields MUST be absent from the recipientEncryptedKey rid rKeyId fields MUST be absent from the recipientEncryptedKey rid rKeyId
SEQUENCE. SEQUENCE.
skipping to change at line 307 skipping to change at line 306
originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET
STRING. 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-byte
public KEA key and recipient's 128-byte public KEA key used as the Rb public KEA key and recipient's 128-byte public KEA key used as the Rb
value. 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 80-bit
wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit check wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit
value and produces a 96-bit result using the KEA-generated pairwise KEK. integrity check value and produces a 96-bit result using 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 recipient's
KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey
rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier
CHOICE MUST be rKeyId. The date and other fields MUST be absent from CHOICE MUST be rKeyId. The date and other fields MUST be absent from
the RecipientEncryptedKey rid rKeyId SEQUENCE. 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 RecipientEncryptedKey
skipping to change at line 331 skipping to change at line 331
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
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 the shared and/or unique originator UKM objects constructed using both the shared and the unique originator UKM
options. To support the shared UKM option, the receiving software MUST options. To support the shared UKM option, the receiving software MUST
be capable of searching for the recipient's RecipientEncryptedKey in a be capable of searching for the recipient's RecipientEncryptedKey in a
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF
RecipientEncryptedKey. To support the unique UKM option, the receiving RecipientEncryptedKey. To support the unique UKM option, the receiving
software MUST be capable of searching for the recipient's software MUST be capable of searching for the recipient's
RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF
RecipientInfo, with each RecipientInfo containing exactly one RecipientInfo, with each RecipientInfo containing exactly one
RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid
rkeyId CHOICE is present, then the receiving software MUST attempt to rkeyId CHOICE is present, then the receiving software MUST attempt to
match the value of the subjectKeyIdentifier extension from the match the value of the subjectKeyIdentifier extension from the
skipping to change at line 377 skipping to change at line 380
KEK as input to the FORTEZZA 80-bit unwrap function. 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 are
used as inputs to the SKIPJACK content decryption process to decrypt the used as inputs to the SKIPJACK content decryption process to decrypt the
EnvelopedData encryptedContent. EnvelopedData encryptedContent.
4.3. "Previously Distributed" Symmetric KEK 4.3. "Previously Distributed" Symmetric KEK
This section describes the conventions for using KEA and SKIPJACK with This section describes the conventions for using SKIPJACK with
the CMS enveloped-data content type to support "previously distributed" the 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 used to
wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE
MUST be used. The methods by which KEA is used to generate the symmetric MUST be used. The methods used to generate and distribute the symmetric KEK
KEK and by which the symmetric KEK is distributed are beyond the scope of are beyond the scope of this document.
this document.
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section
6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm
algorithm field MUST be the id-fortezzaWrap80 OID indicating that the 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. FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. The
The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent.
The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK
wrapped using the "previously distributed" symmetric KEK as input to the wrapped using the "previously distributed" symmetric KEK as input to the
FORTEZZA 80-bit wrap function. 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 CEK
required to decrypt the encrypted-data encrypted content is beyond the required to decrypt the encrypted-data encrypted content is beyond the
scope of this document. Compliant software MUST meet the requirements scope of this document. Compliant software MUST meet the requirements
skipping to change at line 426 skipping to change at line 428
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, Section 2.5.2 defines the SMIMECapabilities signed attribute RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute
(defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a
partial list of algorithms that the software announcing the partial list of algorithms that the software announcing the
SMIMECapabilities can support. When constructing a signedData object, SMIMECapabilities can support. When constructing a signedData object,
compliant software MAY include the SMIMECapabilities signed attribute compliant software MAY include the SMIMECapabilities signed attribute
announcing that it supports the KEA and SKIPJACK algorithms. 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-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include
a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of 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 the id-fortezzaWrap80 OID. The parameters field of
KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD
be included in the key management algorithms portion of the be included in the key management algorithms portion of the
SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST
be DER-encoded as follows: 3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 be DER-encoded as the following hexadecimal string:
0165 0201 0117. 3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117.
The SMIMECapability SEQUENCE representing SKIPJACK MUST include the The SMIMECapability SEQUENCE representing SKIPJACK MUST include the
id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the
parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK
SHOULD be included in the symmetric encryption algorithms portion of the SHOULD be included in the symmetric encryption algorithms portion of the
SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK
MUST be DER-encoded as follows: 300b 0609 6086 4801 6502 0101 0400. 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)
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)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-iso- id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1) ccitt(2) country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaConfidentialityAlgorithm (4)} algorithms(1) fortezzaConfidentialityAlgorithm (4)}
As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm
OID is present in the AlgorithmIdentifier algorithm field, then the OID is present in the AlgorithmIdentifier algorithm field, then the
AlgorithmIdentifier parameters field MUST be present and MUST include AlgorithmIdentifier parameters field MUST be present and MUST include
the SKIPJACK IV ASN.1 encoded using the following syntax: the SKIPJACK IV ASN.1 encoded using the following syntax:
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING } Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding
conventions for the CMS content types including the enveloped-data and conventions for the CMS content types including the enveloped-data and
encrypted-data content types in which the encrypted-data content types in which the
id-fortezzaConfidentialityAlgorithm OID and parameters will be present. 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 A. References
[CMS] RFC 2630, Cryptographic Message Syntax, June 1999. [CMS] RFC 2630, Cryptographic Message Syntax, June 1999.
[KEA] RFC 2528, Representation of Key Exchange Algorithm (KEA) Keys in [KEA] RFC 2528, Representation of Key Exchange Algorithm (KEA) Keys in
Internet X.509 Public Key Infrastructure Certificates, March 1999. Internet X.509 Public Key Infrastructure Certificates, March 1999.
[INFO] Registry of INFOSEC Technical Objects, 22 July 1999. [INFO] Registry of INFOSEC Technical Objects, 22 July 1999.
[MSG] RFC 2633, S/MIME Version 3 Message Specification, June 1999.
[MUSTSHOULD] RFC 2119, Key Words for Use in RFCs to Indicate [MUSTSHOULD] RFC 2119, Key Words for Use in RFCs to Indicate
Requirement Levels. Requirement Levels.
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0, [SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0,
http://csrc.nist.gov/encryption/skipjack-kea.htm. http://csrc.nist.gov/encryption/skipjack-kea.htm.
[USSUP1] Allied Communication Publication 120 (ACP120) Common [USSUP1] Allied Communication Publication 120 (ACP120) Common
Security Protocol (CSP) United States (US) Supplement No. 1, June 1998; Security Protocol (CSP) United States (US) Supplement No. 1, June 1998;
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs. http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.
B. Acknowledgments B. Acknowledgments
The following people have made significant contributions to this draft: The following people have made significant contributions to this draft:
David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger, David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger,
Rich Nicholas, Bob Relyea and Jim Schaad. Rich Nicholas, Bob Relyea and Jim Schaad.
C. Changes between CMSKEA-02 and CMSKEA-03: C. Author's Address
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 John Pawling
J.G. Van Dyke & Associates, Inc., a Wang Government Services Company J.G. Van Dyke & Associates, Inc., a Wang Government Services Company
141 National Business Pkwy, Suite 210 141 National Business Pkwy, Suite 210
Annapolis Junction, MD 20701 Annapolis Junction, MD 20701
jsp@jgvandyke.com john.pawling@wang.com
(301) 939-2739 (301) 939-2739
(410) 880-6095 (410) 880-6095
E. Full Copyright Statement D. Full Copyright Statement
Copyright (C) The Internet Society (date). 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 included on all such copies and derivative works. However, this are 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
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/