⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2630.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 5 页
字号:

Housley                     Standards Track                    [Page 22]

RFC 2630              Cryptographic Message Syntax             June 1999


9  Authenticated-data Content Type

   The authenticated-data content type consists of content of any type,
   a message authentication code (MAC), and encrypted authentication
   keys for one or more recipients.  The combination of the MAC and one
   encrypted authentication key for a recipient is necessary for that
   recipient to verify the integrity of the content.  Any type of
   content can be integrity protected for an arbitrary number of
   recipients.

   The process by which authenticated-data is constructed involves the
   following steps:

      1.  A message-authentication key for a particular message-
      authentication algorithm is generated at random.

      2.  The message-authentication key is encrypted for each
      recipient.  The details of this encryption depend on the key
      management algorithm used.

      3.  For each recipient, the encrypted message-authentication key
      and other recipient-specific information are collected into a
      RecipientInfo value, defined in Section 6.2.

      4.  Using the message-authentication key, the originator computes
      a MAC value on the content.  If the originator is authenticating
      any information in addition to the content (see Section 9.2), a
      message digest is calculated on the content, the message digest of
      the content and the other information are authenticated using the
      message-authentication key, and the result becomes the "MAC
      value."

9.1  AuthenticatedData Type

   The following object identifier identifies the authenticated-data
   content type:

      id-ct-authData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
          ct(1) 2 }











Housley                     Standards Track                    [Page 23]

RFC 2630              Cryptographic Message Syntax             June 1999


   The authenticated-data content type shall have ASN.1 type
   AuthenticatedData:

      AuthenticatedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        macAlgorithm MessageAuthenticationCodeAlgorithm,
        digestAlgorithm [1] DigestAlgorithmIdentifier OPTIONAL,
        encapContentInfo EncapsulatedContentInfo,
        authenticatedAttributes [2] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthenticatedAttributes [3] IMPLICIT UnauthAttributes OPTIONAL }

      AuthAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnauthAttributes ::= SET SIZE (1..MAX) OF Attribute

      MessageAuthenticationCode ::= OCTET STRING

   The fields of type AuthenticatedData have the following meanings:

      version is the syntax version number.  It shall be 0.

      originatorInfo optionally provides information about the
      originator.  It is present only if required by the key management
      algorithm.  It may contain certificates, attribute certificates,
      and CRLs, as defined in Section 6.1.

      recipientInfos is a collection of per-recipient information, as
      defined in Section 6.1.  There must be at least one element in the
      collection.

      macAlgorithm is a message authentication code (MAC) algorithm
      identifier.  It identifies the MAC algorithm, along with any
      associated parameters, used by the originator.  Placement of the
      macAlgorithm field facilitates one-pass processing by the
      recipient.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used to compute a message digest on the
      encapsulated content if authenticated attributes are present.  The
      message digesting process is described in Section 9.2.  Placement
      of the digestAlgorithm field facilitates one-pass processing by
      the recipient.  If the digestAlgorithm field is present, then the
      authenticatedAttributes field must also be present.





Housley                     Standards Track                    [Page 24]

RFC 2630              Cryptographic Message Syntax             June 1999


      encapContentInfo is the content that is authenticated, as defined
      in section 5.2.

      authenticatedAttributes is a collection of authenticated
      attributes.  The authenticatedAttributes structure is optional,
      but it must be present if the content type of the
      EncapsulatedContentInfo value being authenticated is not id-data.
      If the authenticatedAttributes field is present, then the
      digestAlgorithm field must also be present.  Each
      AuthenticatedAttribute in the SET must be DER encoded.  Useful
      attribute types are defined in Section 11.  If the
      authenticatedAttributes field is present, it must contain, at a
      minimum, the following two attributes:

         A content-type attribute having as its value the content type
         of the EncapsulatedContentInfo value being authenticated.
         Section 11.1 defines the content-type attribute.

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.

      mac is the message authentication code.

      unauthenticatedAttributes is a collection of attributes that are
      not authenticated.  The field is optional.  To date, no attributes
      have been defined for use as unauthenticated attributes, but other
      useful attribute types are defined in Section 11.

9.2  MAC Generation

   The MAC calculation process computes a message authentication code
   (MAC) on either the message being authenticated or a message digest
   of message being authenticated together with the originator's
   authenticated attributes.

   If authenticatedAttributes field is absent, the input to the MAC
   calculation process is the value of the encapContentInfo eContent
   OCTET STRING.  Only the octets comprising the value of the eContent
   OCTET STRING are input to the MAC algorithm; the tag and the length
   octets are omitted.  This has the advantage that the length of the
   content being authenticated need not be known in advance of the MAC
   generation process.

   If authenticatedAttributes field is present, the content-type
   attribute (as described in Section 11.1) and the message-digest
   attribute (as described in section 11.2) must be included, and the
   input to the MAC calculation process is the DER encoding of



Housley                     Standards Track                    [Page 25]

RFC 2630              Cryptographic Message Syntax             June 1999


   authenticatedAttributes.  A separate encoding of the
   authenticatedAttributes field is performed for message digest
   calculation.  The IMPLICIT [2] tag in the authenticatedAttributes
   field is not used for the DER encoding, rather an EXPLICIT SET OF tag
   is used.  That is, the DER encoding of the SET OF tag, rather than of
   the IMPLICIT [2] tag, is to be included in the message digest
   calculation along with the length and content octets of the
   authenticatedAttributes value.

   The message digest calculation process computes a message digest on
   the content being authenticated.  The initial input to the message
   digest calculation process is the "value" of the encapsulated content
   being authenticated.  Specifically, the input is the encapContentInfo
   eContent OCTET STRING to which the authentication process is applied.
   Only the octets comprising the value of the encapContentInfo eContent
   OCTET STRING are input to the message digest algorithm, not the tag
   or the length octets.  This has the advantage that the length of the
   content being authenticated need not be known in advance.  Although
   the encapContentInfo eContent OCTET STRING tag and length octets are
   not included in the message digest calculation, they are still
   protected by other means.  The length octets are protected by the
   nature of the message digest algorithm since it is computationally
   infeasible to find any two distinct messages of any length that have
   the same message digest.

   The input to the MAC calculation process includes the MAC input data,
   defined above, and an authentication key conveyed in a recipientInfo
   structure.  The details of MAC calculation depend on the MAC
   algorithm employed (e.g., HMAC).  The object identifier, along with
   any parameters, that specifies the MAC algorithm employed by the
   originator is carried in the macAlgorithm field.  The MAC value
   generated by the originator is encoded as an OCTET STRING and carried
   in the mac field.

9.3  MAC Verification

   The input to the MAC verification process includes the input data
   (determined based on the presence or absence of the
   authenticatedAttributes field, as defined in 9.2), and the
   authentication key conveyed in recipientInfo.  The details of the MAC
   verification process depend on the MAC algorithm employed.

   The recipient may not rely on any MAC values or message digest values
   computed by the originator.  The content is authenticated as
   described in section 9.2.  If the originator includes authenticated
   attributes, then the content of the authenticatedAttributes is
   authenticated as described in section 9.2.  For authentication to
   succeed, the message MAC value calculated by the recipient must be



Housley                     Standards Track                    [Page 26]

RFC 2630              Cryptographic Message Syntax             June 1999


   the same as the value of the mac field.  Similarly, for
   authentication to succeed when the authenticatedAttributes field is
   present, the content message digest value calculated by the recipient
   must be the same as the message digest value included in the
   authenticatedAttributes message-digest attribute.

10  Useful Types

   This section is divided into two parts.  The first part defines
   algorithm identifiers, and the second part defines other useful
   types.

10.1  Algorithm Identifier Types

   All of the algorithm identifiers have the same type:
   AlgorithmIdentifier.  The definition of AlgorithmIdentifier is
   imported from X.509 [X.509-88].

   There are many alternatives for each type of algorithm listed.  For
   each of these five types, Section 12 lists the algorithms that must
   be included in a CMS implementation.

10.1.1  DigestAlgorithmIdentifier

   The DigestAlgorithmIdentifier type identifies a message-digest
   algorithm.  Examples include SHA-1, MD2, and MD5.  A message-digest
   algorithm maps an octet string (the message) to another octet string
   (the message digest).

      DigestAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.2  SignatureAlgorithmIdentifier

   The SignatureAlgorithmIdentifier type identifies a signature
   algorithm.  Examples include DSS and RSA.  A signature algorithm
   supports signature generation and verification operations.  The
   signature generation operation uses the message digest and the
   signer's private key to generate a signature value.  The signature
   verification operation uses the message digest and the signer's
   public key to determine whether or not a signature value is valid.
   Context determines which operation is intended.

      SignatureAlgorithmIdentifier ::= AlgorithmIdentifier








Housley                     Standards Track                    [Page 27]

RFC 2630              Cryptographic Message Syntax             June 1999


10.1.3  KeyEncryptionAlgorithmIdentifier

   The KeyEncryptionAlgorithmIdentifier type identifies a key-encryption
   algorithm used to encrypt a content-encryption key.  The encryption
   operation maps an octet string (the key) to another octet string (the
   encrypted key) under control of a key-encryption key.  The decryption
   operation is the inverse of the encryption operation.  Context
   determines which operation is intended.

   The details of encryption and decryption depend on the key management
   algorithm used.  Key transport, key agreement, and previously
   distributed symmetric key-encrypting keys are supported.

      KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier

10.1.4  ContentEncryptionAlgorithmIdentifier

   The ContentEncryptionAlgorithmIdentifier type identifies a content-
   encryption algorithm.  Examples include Triple-

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -