subjectKeyIdentifier [0] SubjectKeyIdentifier }
The fields of type KeyTransRecipientInfo have the following meanings:
version is the syntax version number. If the RecipientIdentifier
is the CHOICE issuerAndSerialNumber, then the version MUST be 0.
If the RecipientIdentifier is subjectKeyIdentifier, then the
version MUST be 2.
rid specifies the recipient’s certificate or key that was used by
the sender to protect the content-encryption key. The content-
encryption key is encrypted with the recipient’s public key. The
RecipientIdentifier provides two alternatives for specifying the
recipient’s certificate, and thereby the recipient’s public key.
The recipient’s certificate must contain a key transport public
key. Therefore, a recipient X.509 version 3 certificate that
contains a key usage extension MUST assert the keyEncipherment
bit. The issuerAndSerialNumber alternative identifies the
recipient’s certificate by the issuer’s distinguished name and the
certificate serial number; the subjectKeyIdentifier identifies the
recipient’s certificate by a key identifier. When an X.509
certificate is referenced, the key identifier matches the X.509
subjectKeyIdentifier extension value. When other certificate
formats are referenced, the documents that specify the certificate
format and their use with the CMS must include details on matching
the key identifier to the appropriate certificate field. For
recipient processing, implementations MUST support both of these
alternatives for specifying the recipient’s certificate. For
sender processing, implementations MUST support at least one of
these alternatives.
keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content-
encryption key for the recipient. The key-encryption process is
described in Section 6.4.
encryptedKey is the result of encrypting the content-encryption
key for the recipient.
6.2.2. KeyAgreeRecipientInfo Type
Recipient information using key agreement is represented in the type
KeyAgreeRecipientInfo. Each instance of KeyAgreeRecipientInfo will
transfer the content-encryption key to one or more recipients that
use the same key agreement algorithm and domain parameters for that
algorithm.
KeyAgreeRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 3
originator [0] EXPLICIT OriginatorIdentifierOrKey,
ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
recipientEncryptedKeys RecipientEncryptedKeys }
OriginatorIdentifierOrKey ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier,
originatorKey [1] OriginatorPublicKey }
OriginatorPublicKey ::= SEQUENCE {
algorithm AlgorithmIdentifier,
publicKey BIT STRING }
RecipientEncryptedKeys ::= SEQUENCE OF RecipientEncryptedKey
RecipientEncryptedKey ::= SEQUENCE {
rid KeyAgreeRecipientIdentifier,
encryptedKey EncryptedKey }
KeyAgreeRecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
rKeyId [0] IMPLICIT RecipientKeyIdentifier }
RecipientKeyIdentifier ::= SEQUENCE {
subjectKeyIdentifier SubjectKeyIdentifier,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
SubjectKeyIdentifier ::= OCTET STRING
The fields of type KeyAgreeRecipientInfo have the following meanings:
version is the syntax version number. It MUST always be 3.
originator is a CHOICE with three alternatives specifying the
sender’s key agreement public key. The sender uses the
corresponding private key and the recipient’s public key to
generate a pairwise key. The content-encryption key is encrypted
in the pairwise key. The issuerAndSerialNumber alternative
identifies the sender’s certificate, and thereby the sender’s
public key, by the issuer’s distinguished name and the certificate
serial number. The subjectKeyIdentifier alternative identifies
the sender’s certificate, and thereby the sender’s public key, by
a key identifier. When an X.509 certificate is referenced, the
key identifier matches the X.509 subjectKeyIdentifier extension
value. When other certificate formats are referenced, the
documents that specify the certificate format and their use with
the CMS must include details on matching the key identifier to the
appropriate certificate field. The originatorKey alternative
includes the algorithm identifier and sender’s key agreement
public key. This alternative permits originator anonymity since
the public key is not certified. Implementations MUST support all
three alternatives for specifying the sender’s public key.
ukm is optional. With some key agreement algorithms, the sender
provides a User Keying Material (UKM) to ensure that a different
key is generated each time the same two parties generate a
pairwise key. Implementations MUST accept a KeyAgreeRecipientInfo
SEQUENCE that includes a ukm field. Implementations that do not
support key agreement algorithms that make use of UKMs MUST
gracefully handle the presence of UKMs.
keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content-
encryption key with the key-encryption key. The key-encryption
process is described in Section 6.4.
recipientEncryptedKeys includes a recipient identifier and
encrypted key for one or more recipients. The
KeyAgreeRecipientIdentifier is a CHOICE with two alternatives
specifying the recipient’s certificate, and thereby the
recipient’s public key, that was used by the sender to generate a
pairwise key-encryption key. The recipient’s certificate must
contain a key agreement public key. Therefore, a recipient X.509
version 3 certificate that contains a key usage extension MUST
assert the keyAgreement bit. The content-encryption key is
encrypted in the pairwise key-encryption key. The
issuerAndSerialNumber alternative identifies the recipient’s
certificate by the issuer’s distinguished name and the certificate
serial number; the RecipientKeyIdentifier is described below. The
encryptedKey is the result of encrypting the content-encryption
key in the pairwise key-encryption key generated using the key
agreement algorithm. Implementations MUST support both
alternatives for specifying the recipient’s certificate.
The fields of type RecipientKeyIdentifier have the following
meanings:
subjectKeyIdentifier identifies the recipient’s certificate by a
key identifier. When an X.509 certificate is referenced, the key
identifier matches the X.509 subjectKeyIdentifier extension value.
When other certificate formats are referenced, the documents that
specify the certificate format and their use with the CMS must
include details on matching the key identifier to the appropriate
certificate field.
date is optional. When present, the date specifies which of the
recipient’s previously distributed UKMs was used by the sender.
other is optional. When present, this field contains additional
information used by the recipient to locate the public keying
material used by the sender.
6.2.3. KEKRecipientInfo Type
Recipient information using previously distributed symmetric keys is
represented in the type KEKRecipientInfo. Each instance of
KEKRecipientInfo will transfer the content-encryption key to one or
more recipients who have the previously distributed key-encryption
key.
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
The fields of type KEKRecipientInfo have the following meanings:
version is the syntax version number. It MUST always be 4.
kekid specifies a symmetric key-encryption key that was previously
distributed to the sender and one or more recipients.
keyEncryptionAlgorithm identifies the key-encryption algorithm,
and any associated parameters, used to encrypt the content-
encryption key with the key-encryption key. The key-encryption
process is described in Section 6.4.
encryptedKey is the result of encrypting the content-encryption
key in the key-encryption key.
The fields of type KEKIdentifier have the following meanings:
keyIdentifier identifies the key-encryption key that was
previously distributed to the sender and one or more recipients.
date is optional. When present, the date specifies a single key-
encryption key from a set that was previously distributed.
other is optional. When present, this field contains additional
information used by the recipient to determine the key-encryption
key used by the sender.
6.2.4. PasswordRecipientInfo Type
Recipient information using a password or shared secret value is
represented in the type PasswordRecipientInfo. Each instance of
PasswordRecipientInfo will transfer the content-encryption key to one
or more recipients who possess the password or shared secret value.
The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. The
PasswordRecipientInfo structure is repeated here for completeness.
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- Always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
The fields of type PasswordRecipientInfo have the following meanings:
version is the syntax version number. It MUST always be 0.
keyDerivationAlgorithm identifies the key-derivation algorithm,
and any associated parameters, used to derive the key-encryption
key from the password or shared secret value. If this field is
absent, the key-encryption key is supplied from an external
source, for example a hardware crypto token such as a smart card.
keyEncryptionAlgorithm identifies the encryption algorithm, and
any associated parameters, used to encrypt the content-encryption
key with the key-encryption key.
encryptedKey is the result of encrypting the content-encryption
key with the key-encryption key.
6.2.5. OtherRecipientInfo Type
Recipient information for additional key management techniques are
represented in the type OtherRecipientInfo. The OtherRecipientInfo
type allows key management techniques beyond key transport, key
agreement, previously distributed symmetric key-encryption keys, and
password-based key management to be specified in future documents.
An object identifier uniquely identifies such key management
techniques.
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
The fields of type OtherRecipientInfo have the following meanings:
oriType identifies the key management technique.
oriValue contains the protocol data elements needed by a recipient
using the identified key management technique.
6.3. Content-encryption Process
The content-encryption key for the desired content-encryption
algorithm is randomly generated. The data to be protected is padded
as described below, then the padded data is encrypted using the
content-encryption key. The encryption operation maps an arbitrary
string of octets (the data) to another string of octets (the
ciphertext) under control of a content-encryption key. The encrypted
data is included in the EnvelopedData encryptedContentInfo
encryptedContent OCTET STRING.
Some content-encryption algorithms assume the input length is a
multiple of k octets, where k is greater than one. For such
algorithms, the input shall be padded at the trailing end with k-(lth
mod k) octets all having value k-(lth mod k), where lth is the length
of the input. In other words, the input is padded at the trailing
end with one of the following strings:
01 -- if lth mod k = k-1
02 02 -- if lth mod k = k-2
.
.
.
k k ... k k -- if lth mod k = 0
The padding can be removed unambiguously since all input is padded,
including input values that are already a multiple of the block size,
and no padding string is a suffix of another. This padding method is
well defined if and only if k is less than 256.
6.4. Key-encryption Process
The input to the key-encryption process -- the value supplied to the
recipient’s key-encryption algorithm -- is just the "value" of the
content-encryption key.
Any of the aforementioned key management techniques can be used for
each recipient of the same encrypted content.
7. Digested-data Content Type
The digested-data content type consists of content of any type and a
message digest of the content.
Typically, the digested-data content type is used to provide content
integrity, and the result generally becomes an input to the
enveloped-data content type.
The following steps construct digested-data:
1. A message digest is computed on the content with a message-
digest algorithm.
2. The message-digest algorithm and the message digest are
collected together with the content into a DigestedData value.
A recipient verifies the message digest by comparing the message
digest to an independently computed message digest.
The following object identifier identifies the digested-data content
type:
id-digestedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 5 }
The digested-data content type shall have ASN.1 type DigestedData:
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
Digest ::= OCTET STRING
The fields of type DigestedData have the following meanings:
version is the syntax version number. If the encapsulated content
type is id-data, then the value of version MUST be 0; however, if
the encapsulated content type is other than id-data, then the
value of version MUST be 2.
digestAlgorithm identifies the message digest algorithm, and any
associated parameters, under which the content is digested. The
message-digesting process is the same as in Section 5.4 in the
case when there are no signed attributes.
encapContentInfo is the content that is digested, as defined in
section 5.2.
digest is the result of the message-digesting process.
The ordering of the digestAlgorithm field, the encapContentInfo
field, and the digest field makes it possible to process a
DigestedData value in a single pass.
8. Encrypted-data Content Type
The encrypted-data content type consists of encrypted content of any
type. Unlike the enveloped-data content type, the encrypted-data
content type has neither recipients nor encrypted content-encryption
keys. Keys MUST be managed by other means.
The typical application of the encrypted-data content type will be to
encrypt the content of the data content type for local storage,
perhaps where the encryption key is derived from a password.
The following object identifier identifies the encrypted-data content
type:
id-encryptedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 6 }
The encrypted-data content type shall have ASN.1 type EncryptedData:
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
The fields of type EncryptedData have the following meanings:
version is the syntax version number. If unprotectedAttrs is
present, then version MUST be 2. If unprotectedAttrs is absent,
then version MUST be 0.
encryptedContentInfo is the encrypted content information, as
defined in Section 6.1.
unprotectedAttrs is a collection of attributes that are not
encrypted. The field is optional. Useful attribute types are
defined in Section 11.
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 }
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,
authAttrs [2] IMPLICIT AuthAttributes OPTIONAL,
mac MessageAuthenticationCode,
unauthAttrs [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. The version MUST be
assigned as follows:
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 3
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present))
THEN version is 1
ELSE version is 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
authAttrs field MUST also be present.
encapContentInfo is the content that is authenticated, as defined
in section 5.2.
authAttrs is a collection of authenticated attributes. The
authAttrs structure is optional, but it MUST be present if the
content type of the EncapsulatedContentInfo value being
authenticated is not id-data. If the authAttrs field is present,
then the digestAlgorithm field MUST also be present. The
AuthAttributes structure MUST be DER encoded, even if the rest of
the structure is BER encoded. Useful attribute types are defined
in Section 11. If the authAttrs 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.
unauthAttrs 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 content being authenticated or a message digest
of content being authenticated together with the originator’s
authenticated attributes.
If authAttrs 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 authAttrs 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 authAttrs. A separate
encoding of the authAttrs field is performed for message digest
calculation. The IMPLICIT [2] tag in the authAttrs field is not used