rfc2876.txt

RFC 的详细文档！

      the KEA-generated pairwise KEK.

   5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.

   6) The value of the subjectKeyIdentifier extension from the
      recipient's KEA X.509 v3 certificate MUST be placed in the
      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.

   7) The wrapped SKIPJACK CEK MUST be placed in the
      RecipientEncryptedKey encryptedKey OCTET STRING.

   8) The recipient's RecipientEncryptedKey MUST be the only
      RecipientEncryptedKey present in the KeyAgreeRecipientInfo
      recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.

   9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo
      MUST be included in the EnvelopedData RecipientInfos SET OF
      RecipientInfo.






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


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
      objects constructed using both the shared and the unique
      originator UKM options.  To support the shared UKM option, the
      receiving software MUST be capable of searching for the
      recipient's RecipientEncryptedKey in a KeyAgreeRecipientInfo
      recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.  To
      support the unique UKM option, the receiving software MUST be
      capable of searching for the recipient's RecipientEncryptedKey in
      the EnvelopedData recipientInfos SET OF RecipientInfo, with each
      RecipientInfo containing exactly one RecipientEncryptedKey.  For
      each RecipientEncryptedKey, if the rid rkeyId CHOICE is present,
      then the receiving software MUST attempt to match the value of the
      subjectKeyIdentifier extension from the recipient's KEA X.509 v3
      certificate with the RecipientEncryptedKey rid rKeyId
      subjectKeyIdentifier field.  If the rid issuerAndSerialNumber
      CHOICE is present, then the receiving software MUST attempt to
      match the values of the issuer name and serial number from the
      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
      ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that
      includes the recipient's RecipientEncryptedKey.

   3) The receiving software MUST locate the originator's KEA X.509 v3
      certificate identified by the originator field contained in the
      same KeyAgreeRecipientInfo that includes the recipient's
      RecipientEncryptedKey.

   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 KEA X.509 v3 certificate), recipient's private
      KEA key (associated with recipient's KEA X.509 v3 certificate
      identified by the RecipientEncryptedKey rid field) and the
      originator's 128-byte public KEA key used as the Rb value.

   5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated
      pairwise KEK as input to the FORTEZZA 80-bit unwrap function.








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


   6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK
      unwrap process and the 8-byte IV obtained from the EnvelopedData
      encryptedContentInfo contentEncryptionAlgorithm parameters field
      are used as inputs to the SKIPJACK content decryption process to
      decrypt the EnvelopedData encryptedContent.

4.3. "Previously Distributed" Symmetric KEK

   This section describes the conventions for using SKIPJACK with the
   CMS enveloped-data content type to support "previously distributed"
   symmetric KEKs.  When a "previously distributed" symmetric KEK is
   used to wrap the SKIPJACK CEK, then the RecipientInfo
   KEKRecipientInfo CHOICE MUST be used. The methods used to generate
   and distribute the symmetric KEK are beyond the scope of this
   document.

   The KEKRecipientInfo fields MUST be populated as specified in [CMS]
   Section 6.2.3, "KEKRecipientInfo Type". 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. The KEKRecipientInfo encryptedKey
   field MUST include the SKIPJACK CEK wrapped using the "previously
   distributed" symmetric KEK as input to the FORTEZZA 80-bit wrap
   function.

5. Encrypted-data Conventions

   The CMS encrypted-data content type consists of an encrypted content,
   but no recipient information.  The method for conveying the SKIPJACK
   CEK required to decrypt the encrypted-data encrypted content is
   beyond the scope of this document.  Compliant software MUST meet the
   requirements for constructing an encrypted-data content type stated
   [CMS] Section 8, "Encrypted-data Content Type".  [CMS] Section 8
   should be studied before reading this section, because this section
   does not repeat the [CMS] text.

   The encrypted-data content type is ASN.1 encoded using the
   EncryptedData syntax.  The fields of the EncryptedData syntax must be
   populated as follows:

   The EncryptedData version MUST be set according to [CMS] Section 8.

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



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


   The EncryptedData unprotectedAttrs MAY be present.

6. FORTEZZA 80-bit Wrap Function

   The United States Government has not published the description of the
   FORTEZZA 80-bit wrap function.

7.   SMIMECapabilities Attribute Conventions

   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 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 the
   following hexadecimal string:

      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
   the following hexadecimal string:

      300b 0609 6086 4801 6502 0101 0400

8. Object Identifier Definitions

   The following OIDs are specified in [INFO], but are repeated here for
   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)}




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


   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-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
   infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}

   As specified in [USSUP1], when the id-
   fortezzaConfidentialityAlgorithm 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.

References

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                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.

   [INFO]       Registry of INFOSEC Technical Objects, 22 July 1999.

   [MSG]        Ramsdell, B., "S/MIME Version 3 Message Specification",
                RFC 2633, June 1999.

   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SJ-KEA]     SKIPJACK and KEA Algorithm Specifications, Version 2.0,
                http://csrc.nist.gov/encryption/skipjack-kea.htm.







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


   [USSUP1]     Allied Communication Publication 120 (ACP120) Common
                Security Protocol (CSP) United States (US) Supplement
                No. 1, June 1998;
  http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.

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.

Author's Address

   John Pawling
   Wang Government Services, Inc. (WGSI),
   A Getronics Company
   141 National Business Pkwy, Suite 210
   Annapolis Junction, MD  20701

   Phone: [phone]
          [phone]
   EMail: [e-mail]





























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


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Pawling                      Informational                     [Page 13]