draft-ietf-smime-cmskea-02.txt   draft-ietf-smime-cmskea-03.txt 
INTERNET-DRAFT John Pawling INTERNET-DRAFT John Pawling
draft-ietf-smime-cmskea-02.txt J.G. Van Dyke & Associates draft-ietf-smime-cmskea-03.txt J.G. Van Dyke & Associates
29 July 1999 2 December 1999
Expires: 29 January 2000 Expires: 2 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 55 skipping to change at line 55
same key words are used in this document to help implementers achieve same key words are used in this document to help implementers achieve
interoperability. Software that claims compliance with this document interoperability. Software that claims compliance with this document
MUST provide the capabilities as indicated by the MUST, MUST NOT, MUST provide the capabilities as indicated by the MUST, MUST NOT,
SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are
described in [SJ-KEA]. 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 and
encrypted-data content types. Compliant software MUST meet the encrypted-data content types. Compliant software MUST meet the
requirements stated in the [CMS] "Content-encryption Process" section. requirements stated in [CMS] Section 6.3, "Content-encryption Process".
The input to the encryption process MUST be padded to a multiple of The input to the encryption process MUST be padded to a multiple of
eight octets using the padding rules described in the [CMS] "Content- eight octets using the padding rules described in [CMS] Section 6.3.
encryption Process" section. The content MUST be encrypted as a single The content MUST be encrypted as a single string using the SKIPJACK
string using the SKIPJACK algorithm in 64-bit Cipher Block Chaining (CBC) algorithm in 64-bit Cipher Block Chaining (CBC) mode using
mode using randomly-generated 8-byte Initialization Vector (IV) and 80- randomly-generated 8-byte Initialization Vector (IV) and 80-bit
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 as
a single string using the SKIPJACK algorithm in 64-bit CBC mode. The 80- 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 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 decryption process. Following decryption, the padding MUST be removed
from the decrypted data. The padding rules are described in the [CMS] from the decrypted data. The padding rules are described in [CMS]
"Content-encryption Process" section. 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 and
wrapped CEKs for one or more recipients. Compliant software MUST 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]. The [CMS] "Enveloped-data Content Type" section stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS] Section 6
should be studied before reading this section, because this section should be studied before reading this section, because this section
does not repeat the [CMS] text. 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 instance
of an enveloped-data content type as inputs to the SKIPJACK algorithm for 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 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 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
skipping to change at line 214 skipping to change at line 214
field containing the SKIPJACK CEK wrapped for the recipient. This field containing the SKIPJACK CEK wrapped for the recipient. This
option requires more overhead than the shared UKM option because the option requires more overhead than the shared UKM option because the
KeyAgreeRecipientInfo fields (i.e. version, originator, ukm, KeyAgreeRecipientInfo fields (i.e. version, originator, ukm,
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]. The algorithm field of KeyWrapAlgorithm MUST as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field
be the id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that
wrap function is used to wrap the 80-bit SKIPJACK CEK. The parameters the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK
field of KeyWrapAlgorithm MUST be absent. CEK. 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 385 skipping to change at line 385
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 KEA and 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 by which KEA is used to generate the symmetric
KEK and by which the symmetric KEK is distributed are beyond the scope of KEK and by which the symmetric KEK is distributed are beyond the scope of
this document. this document.
The KEKRecipientInfo fields MUST be populated as specified in the [CMS] The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section
"KEKRecipientInfo Type" section. 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 KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. The 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
for constructing an encrypted-data content type stated in [CMS]. The for constructing an encrypted-data content type stated [CMS] Section 8,
[CMS] "Encrypted-data Content Type" section should be studied before "Encrypted-data Content Type". [CMS] Section 8 should be studied before
reading this section, because this section does not repeat the [CMS] reading this section, because this section does not repeat the [CMS]
text. text.
The encrypted-data content type is ASN.1 encoded using the EncryptedData The encrypted-data content type is ASN.1 encoded using the EncryptedData
syntax. The fields of the EncryptedData syntax must be populated as syntax. The fields of the EncryptedData syntax must be populated as
follows: follows:
The EncryptedData version MUST be set according to [CMS]. 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. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm OID. 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 to
the content encryption process. 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. Object Identifier Definitions 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 following OIDs are specified in [INFO], but are repeated here for
the reader's convenience: the reader's convenience:
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: The [CMS] "General Overview" section 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) 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) id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) country(16)
us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1) us(840) organization(1) gov(101) dod(2) infosec(1) algorithms(1)
skipping to change at line 482 skipping to change at line 508
[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-01 and CMSKEA-02: C. Changes between CMSKEA-02 and CMSKEA-03:
1) Section 4.2.1, 5th paragraph, second sentence: Changed as follows:
OLD: "The KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters
field MUST be the id-fortezzaWrap80 OID indicating that the FORTEZZA
80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK."
NEW: "The KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field
MUST contain a KeyWrapAlgorithm as specified in [CMS]. 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."
Thanks to Pierce Leonberger for pointing this out.
2) Change Section 4.3, 2nd paragraph, 2nd sentence as follows (This makes
the use of the id-fortezzaWrap80 OID consistent in both sections):
OLD: "The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be
the id-fortezzaWrap80 OID (with NULL parameters) indicating that the
FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK."
NEW: "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."
3) Clarified definition of Skipjack-Parm and changed
"initialization_vector" to "initialization-vector" because underscore
is invalid ASN.1. Thanks to Phil Griffin for pointing this out.
4) Updated [CMS] and [INFO] reference definitions. 1) Changed all section references to CMS to include section numbers
rather than just section titles.
5) Added [USSUP1] reference definition. 2) Added Section 7, SMIMECapabilities Attribute Conventions.
D. Author's Address 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 jsp@jgvandyke.com
(301) 939-2739 (301) 939-2739
(410) 880-6095 (410) 880-6095
 End of changes. 

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