Use of the KEA and SKIPJACK Algorithms in CMS
RFC 2876

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

Network Working Group                                         J. Pawling
Request for Comments: 2876                     WGSI, A Getronics Company
Category: Informational                                        July 2000

             Use of the KEA and SKIPJACK Algorithms in CMS

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

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

1. Introduction

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

2. Content Encryption Process

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

Pawling                      Informational                      [Page 1]
RFC 2876           KEA and SKIPJACK Algorithms in CMS          July 2000

3. Content Decryption Process

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

4. Enveloped-data Conventions

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

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

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

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

   2) "Previously Distributed" Symmetric KEK:  The SKIPJACK CEK is
      wrapped using a "previously distributed" symmetric KEK (such as a
      Mail List Key).  The methods by which the symmetric KEK is
      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
   management technique.  The key transport technique MUST NOT be used
   with KEA.

Pawling                      Informational                      [Page 2]
RFC 2876           KEA and SKIPJACK Algorithms in CMS          July 2000

4.1. EnvelopedData Fields

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

   The EnvelopedData version MUST be 2.

   If key agreement is being used, then the EnvelopedData originatorInfo
   field SHOULD be present and SHOULD include the originator's KEA X.509
   v3 certificate containing the KEA public key associated with the KEA