rfc2876.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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
   private key used to form each pairwise symmetric KEK used to wrap
   each copy of the SKIPJACK CEK.  The issuers' X.509 v3 certificates
   required to form the complete certification path for the originator's
   KEA X.509 v3 certificate MAY be included in the EnvelopedData
   originatorInfo field. Self-signed certificates SHOULD NOT be included
   in the EnvelopedData originatorInfo field.

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

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

   The EnvelopedData unprotectedAttrs MAY be present.

4.2.  Key Agreement

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

   If the EnvelopedData originatorInfo field does not include the
   originator's KEA X.509 v3 certificate, then each recipientInfos
   KeyAgreementRecipientInfo originator field MUST include the
   issuerAndSerialNumber CHOICE identifying the originator's KEA X.509
   v3 certificate.  If the EnvelopedData originatorInfo field includes
   the originator's KEA X.509 v3 certificate, then each recipientInfos
   KeyAgreementRecipientInfo originator field MUST include either the
   subjectKeyIdentifier CHOICE containing the value from the
   subjectKeyIdentifier extension of the originator's KEA X.509 v3
   certificate or the issuerAndSerialNumber CHOICE identifying the




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


   originator's KEA X.509 v3 certificate.  To minimize the size of the
   EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE
   be used.

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

4.2.1.  SKIPJACK CEK Wrap Process

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

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









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


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

   The next two paragraphs apply to both options.

   The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST
   include the id-kEAKeyEncryptionAlgorithm OID.  The
   KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field MUST
   contain a KeyWrapAlgorithm as specified in [CMS] Appendix A, "ASN.1
   Module".  The algorithm field of KeyWrapAlgorithm MUST be the id-
   fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function
   is used to wrap the 80-bit SKIPJACK CEK.  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 the SKIPJACK CEK SHOULD be wrapped for the originator and included
   in the EnvelopedData.  This allows the originator to decrypt the
   contents of the EnvelopedData.

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

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

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




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


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

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

   The following steps MUST be repeated for each recipient:

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

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

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

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

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

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






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


4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values

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

   The following steps MUST be repeated for each recipient:

   1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be
      constructed.

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

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

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