rfc3370.txt

RFC 的详细文档！

Housley                     Standards Track                     [Page 6]

RFC 3370                     CMS Algorithms                  August 2002


   For key agreement of RC2 key-encryption keys, 128 bits MUST be
   generated as input to the key expansion process used to compute the
   RC2 effective key [RC2].

   Key agreement algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm fields.

   Key wrap algorithm identifiers are located in the KeyWrapAlgorithm
   parameters within the EnvelopedData RecipientInfos
   KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields.

   Wrapped content-encryption keys are located in the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
   encryptedKey field.  Wrapped message-authentication keys are located
   in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   RecipientEncryptedKeys encryptedKey field.

4.1.1  X9.42 Ephemeral-Static Diffie-Hellman

   Ephemeral-Static Diffie-Hellman key agreement is defined in RFC 2631
   [DH-X9.42].  When using Ephemeral-Static Diffie-Hellman, the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as
   follows:

      version MUST be 3.

      originator MUST be the originatorKey alternative.  The
      originatorKey algorithm field MUST contain the dh-public-number
      object identifier with absent parameters.  The originatorKey
      publicKey field MUST contain the sender's ephemeral public key.
      The dh-public-number object identifier is:

         dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) ansi-x942(10046) number-type(2) 1 }

      ukm may be present or absent.  CMS implementations MUST support
      ukm being absent, and CMS implementations SHOULD support ukm being
      present.  When present, the ukm is used to ensure that a different
      key-encryption key is generated when the ephemeral private key
      might be used more than once.








Housley                     Standards Track                     [Page 7]

RFC 3370                     CMS Algorithms                  August 2002


      keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
      identifier.  The algorithm identifier parameter field for id-alg-
      ESDH is KeyWrapAlgorithm, and this parameter MUST be present.  The
      KeyWrapAlgorithm denotes the symmetric encryption algorithm used
      to encrypt the content-encryption key with the pairwise key-
      encryption key generated using the X9.42 Ephemeral-Static Diffie-
      Hellman key agreement algorithm. Triple-DES and RC2 key wrap
      algorithms are described in RFC 3217 [WRAP].  The id-alg-ESDH
      algorithm identifier and parameter syntax is:

         id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             alg(3) 5 }

         KeyWrapAlgorithm ::= AlgorithmIdentifier

      recipientEncryptedKeys contains an identifier and an encrypted key
      for each recipient.  The RecipientEncryptedKey
      KeyAgreeRecipientIdentifier MUST contain either the
      issuerAndSerialNumber identifying the recipient's certificate or
      the RecipientKeyIdentifier containing the subject key identifier
      from the recipient's certificate.  In both cases, the recipient's
      certificate contains the recipient's static public key.
      RecipientEncryptedKey EncryptedKey MUST contain the
      content-encryption key encrypted with the X9.42 Ephemeral-Static
      Diffie-Hellman generated pairwise key-encryption key using the
      algorithm specified by the KeyWrapAlgorithm.

4.1.2  X9.42 Static-Static Diffie-Hellman

   Static-Static Diffie-Hellman key agreement is defined in RFC 2631
   [DH-X9.42].  When using Static-Static Diffie-Hellman, the
   EnvelopedData RecipientInfos KeyAgreeRecipientInfo and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo fields are
   used as follows:

      version MUST be 3.

      originator MUST be either the issuerAndSerialNumber or
      subjectKeyIdentifier alternative.  In both cases, the originator's
      certificate contains the sender's static public key.  RFC 3279
      [CERTALGS] specifies the AlgorithmIdentifier parameters syntax and
      values that are included in the originator's certificate.  The
      originator's certificate subject public key information field MUST
      contain the dh-public-number object identifier:

         dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) ansi-x942(10046) number-type(2) 1 }



Housley                     Standards Track                     [Page 8]

RFC 3370                     CMS Algorithms                  August 2002


      ukm MUST be present.  The ukm ensures that a different key-
      encryption key is generated for each message between the same
      sender and recipient.

      keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm
      identifier.  The algorithm identifier parameter field for id-alg-
      SSDH is KeyWrapAlgorihtm, and this parameter MUST be present.  The
      KeyWrapAlgorithm denotes the symmetric encryption algorithm used
      to encrypt the content-encryption key with the pairwise key-
      encryption key generated using the X9.42 Static-Static Diffie-
      Hellman key agreement algorithm.  Triple-DES and RC2 key wrap
      algorithms are described in RFC 3217 [WRAP].  The id-alg-SSDH
      algorithm identifier and parameter syntax is:

         id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
             us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
             alg(3) 10 }

         KeyWrapAlgorithm ::= AlgorithmIdentifier

      recipientEncryptedKeys contains an identifier and an encrypted key
      for each recipient.  The RecipientEncryptedKey
      KeyAgreeRecipientIdentifier MUST contain either the
      issuerAndSerialNumber identifying the recipient's certificate or
      the RecipientKeyIdentifier containing the subject key identifier
      from the recipient's certificate.  In both cases, the recipient's
      certificate contains the recipient's static public key.
      RecipientEncryptedKey EncryptedKey MUST contain the content-
      encryption key encrypted with the X9.42 Static-Static Diffie-
      Hellman generated pairwise key-encryption key using the algorithm
      specified by the KeyWrapAlgortihm.

4.2  Key Transport Algorithms

   This section specifies the conventions employed by CMS
   implementations that support key transport using RSA (PKCS #1 v1.5).

   Key transport algorithm identifiers are located in the EnvelopedData
   RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field.

   Key transport encrypted content-encryption keys are located in the
   EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey
   field.








Housley                     Standards Track                     [Page 9]

RFC 3370                     CMS Algorithms                  August 2002


4.2.1  RSA (PKCS #1 v1.5)

   The RSA key transport algorithm is the RSA encryption scheme defined
   in RFC 2313 [PKCS#1], block type is 02, where the message to be
   encrypted is the content-encryption key.  The algorithm identifier
   for RSA (PKCS #1 v1.5) is:

      rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }

   The AlgorithmIdentifier parameters field MUST be present, and the
   parameters field MUST contain NULL.

   When using a Triple-DES content-encryption key, CMS implementations
   MUST adjust the parity bits for each DES key comprising the Triple-
   DES key prior to RSA encryption.

   The use of RSA (PKCS #1 v1.5) encryption, as defined in RFC 2313
   [PKCS#1], to provide confidentiality has a known vulnerability.  The
   vulnerability is primarily relevant to usage in interactive
   applications rather than to store-and-forward environments.  Further
   information and proposed countermeasures are discussed in the
   Security Considerations section of this document and RFC 3218 [MMA].

   Note that the same RSA encryption scheme is also defined in RFC 2437
   [NEWPKCS#1].  Within RFC 2437, this RSA encryption scheme is called
   RSAES-PKCS1-v1_5.

4.3  Symmetric Key-Encryption Key Algorithms

   This section specifies the conventions employed by CMS
   implementations that support symmetric key-encryption key management
   using Triple-DES or RC2 key-encryption keys.  When RC2 is supported,
   RC2 128-bit keys MUST be used as key-encryption keys, and they MUST
   be used with the RC2ParameterVersion parameter set to 58.  A CMS
   implementation MAY support mixed key-encryption and content-
   encryptionalgorithms.  For example, a 40-bit RC2 content-encryption
   key MAY be wrapped with a 168-bit Triple-DES key-encryption key or
   with a 128-bit RC2 key-encryption key.

   Key wrap algorithm identifiers are located in the EnvelopedData
   RecipientInfos KEKRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KEKRecipientInfo
   keyEncryptionAlgorithm fields.







Housley                     Standards Track                    [Page 10]

RFC 3370                     CMS Algorithms                  August 2002


   Wrapped content-encryption keys are located in the EnvelopedData
   RecipientInfos KEKRecipientInfo encryptedKey field.  Wrapped
   message-authentication keys are located in the AuthenticatedData
   RecipientInfos KEKRecipientInfo encryptedKey field.

   The output of a key agreement algorithm is a key-encryption key, and
   this key-encryption key is used to encrypt the content-encryption
   key.  To support key agreement, key wrap algorithm identifiers are
   located in the KeyWrapAlgorithm parameter of the EnvelopedData
   RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
   AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
   keyEncryptionAlgorithm fields.  However, only key agreement
   algorithms that inherently provide authentication ought to be used
   with AuthenticatedData.  Wrapped content-encryption keys are located
   in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
   RecipientEncryptedKeys encryptedKey field, wrapped message-
   authentication keys are located in the AuthenticatedData
   RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
   encryptedKey field.

4.3.1  Triple-DES Key Wrap

   A CMS implementation MAY support mixed key-encryption and content-
   encryption algorithms.  For example, a 128-bit RC2 content-encryption
   key MAY be wrapped with a 168-bit Triple-DES key-encryption key.

   Triple-DES key encryption has the algorithm identifier:

      id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }

   The AlgorithmIdentifier parameter field MUST be NULL.

   The key wrap algorithm used to encrypt a Triple-DES content-
   encryption key with a Triple-DES key-encryption key is specified in
   section 3.1 of RFC 3217 [WRAP].  The corresponding key unwrap
   algorithm is specified in section 3.2 of RFC 3217 [WRAP].

   Out-of-band distribution of the Triple-DES key-encryption key used to
   encrypt the Triple-DES content-encryption key is beyond the scope of
   this document.










Housley                     Standards Track                    [Page 11]

RFC 3370                     CMS Algorithms                  August 2002


4.3.2  RC2 Key Wrap

   A CMS implementation MAY support mixed key-encryption and content-
   encryption algorithms.  For example, a 128-bit RC2 content-encryption
   key MAY be wrapped with a 168-bit Triple-DES key-encryption key.
   Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with a
   128-bit RC2 key-encryption key.

   RC2 key encryption has the algorithm identifier:

      id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }

   The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:

      RC2wrapParameter ::= RC2ParameterVersion

      RC2ParameterVersion ::= INTEGER

   The RC2 effective-key-bits (key size) greater than 32 and less than
   256 is encoded in the RC2ParameterVersion.  For the effective-key-
   bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
   and 58 respectively.  These values are not simply the RC2 key length.
   Note that the value 160 must be encoded as two octets (00 A0),
   because the one octet (A0) encoding represents a negative number.

   RC2 128-bit keys MUST be used as key-encryption keys, and they MUST
   be used with the RC2ParameterVersion parameter set to 58.

   The key wrap algorithm used to encrypt a RC2 content-encryption key
   with a RC2 key-encryption key is specified in section 4.1 of RFC 3217
   [WRAP].  The corresponding key unwrap algorithm is specified 4.2 of
   RFC 3217 [WRAP].

   Out-of-band distribution of the RC2 key-encryption key used to
   encrypt the RC2 content-encryption key is beyond of the scope of this
   document.

4.4  Key Derivation Algorithms

   This section specifies the conventions employed by CMS
   implementations that support password-based key management using
   PBKDF2.

   Key derivation algorithms are used to convert a password into a key-
   encryption key as part of the password-based key management
   technique.




Housley                     Standards Track                    [Page 12]