RFC 3369
Cryptographic Message Syntax (CMS)
RFC 3369: Cryptographic Message Syntax (CMS) 🎀
Network Working Group 💖 Request for Comments: 3369 💌
Author: R. Housley, RSA Laboratories 👑 Date: August 2002 🌸 Category: Standards Track ✨ Obsoletes: RFC 2630 and RFC 3211. This one replaces both of them 💅 Updates: nothing listed here
okay bestie, this is part 1 of 10 so we're just getting warmed up 🦋
Status of this Memo ✨
Okay so this doc is an Internet standards track protocol for the whole Internet community 🌍, and it's basically asking for feedback and suggestions for making it better 🫶. If you want the official state of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Also, distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice 🔒
Copyright (C) The Internet Society (2002). All Rights Reserved. 💅
Abstract 🦋
Okay so the big idea here is the Cryptographic Message Syntax (CMS) 🔐. CMS is the format people use to digitally sign, digest, authenticate, or encrypt arbitrary message content. Literally any message, any content, it's giving versatility 💖
Table of Contents 📖
1. Introduction ................................................ 3
1.1 Changes Since RFC 2630 ...................................... 3
1.2 Terminology ................................................. 4
2. General Overview ............................................ 4
3. General Syntax .............................................. 5
4. Data Content Type ........................................... 5
5. Signed-data Content Type .................................... 6
5.1 SignedData Type ............................................. 7
5.2 EncapsulatedContentInfo Type ................................ 9
5.2.1 Compatibility with PKCS #7 ................................ 9
5.3 SignerInfo Type ............................................. 11
5.4 Message Digest Calculation Process .......................... 13
5.5 Signature Generation Process ................................ 14
5.6 Signature Verification Process .............................. 14
6. Enveloped-data Content Type ................................. 14
6.1 EnvelopedData Type .......................................... 16
6.2 RecipientInfo Type .......................................... 18
6.2.1 KeyTransRecipientInfo Type ................................ 19
6.2.2 KeyAgreeRecipientInfo Type ................................ 20
6.2.3 KEKRecipientInfo Type ..................................... 22
6.2.4 PasswordRecipientInfo Type ................................ 23
6.2.5 OtherRecipientInfo Type ................................... 24
6.3 Content-encryption Process .................................. 24
6.4 Key-encryption Process ...................................... 25
7. Digested-data Content Type .................................. 25
8. Encrypted-data Content Type ................................. 26
9. Authenticated-data Content Type ............................. 27
9.1 AuthenticatedData Type ...................................... 28
9.2 MAC Generation .............................................. 29
9.3 MAC Verification ............................................ 31
10. Useful Types ................................................ 31
10.1 Algorithm Identifier Types ................................. 31
10.1.1 DigestAlgorithmIdentifier ................................ 31
10.1.2 SignatureAlgorithmIdentifier ............................. 32
10.1.3 KeyEncryptionAlgorithmIdentifier ......................... 32
10.1.4 ContentEncryptionAlgorithmIdentifier ..................... 32
10.1.5 MessageAuthenticationCodeAlgorithm ....................... 32
10.1.6 KeyDerivationAlgorithmIdentifier ......................... 33
10.2 Other Useful Types ......................................... 33
10.2.1 CertificateRevocationLists ............................... 33
10.2.2 CertificateChoices ....................................... 33
10.2.3 CertificateSet ........................................... 34
10.2.4 IssuerAndSerialNumber .................................... 34
10.2.5 CMSVersion ............................................... 35
10.2.6 UserKeyingMaterial ....................................... 35
10.2.7 OtherKeyAttribute ........................................ 35
11. Useful Attributes ........................................... 35
11.1 Content Type ............................................... 36
11.2 Message Digest ............................................. 36
11.3 Signing Time ............................................... 37
11.4 Countersignature ........................................... 39
12. ASN.1 Modules ............................................... 40
12.1 CMS ASN.1 Module ........................................... 40
12.2 Version 1 Attribute Certificate ASN.1 Module ............... 46
13. References .................................................. 47
14. Security Considerations ..................................... 48
15. Acknowledgments ............................................. 50
16. Author Address .............................................. 50
17. Full Copyright Statement .................................... 511. Introduction ✨
Okay so this doc describes CMS, the Cryptographic Message Syntax 🔐. It's the thing you use to digitally sign, digest, authenticate, or encrypt arbitrary message content. Iconic, honestly 👑
CMS is basically an encapsulation syntax for data protection 🎁. It handles digital signatures and encryption. You can nest one envelope inside another, which is so main character energy 🦋. One party can also sign some data that was already encapsulated 💅. On top of that, you can sign arbitrary attributes, like the signing time, together with the message content ⏰. There are also attributes like countersignatures that can be attached to a signature 🫶.
CMS works with a bunch of different architectures for certificate-based key management. The PKIX working group's architecture [PROFILE] is one example 🌸.
The CMS values are generated using ASN.1 [X.208-88] and BER-encoding [X.209-88] 🧚. Values usually show up as octet strings. Plenty of systems can send arbitrary octet strings reliably, but it's well known that lots of electronic mail systems can't 😭. This document doesn't cover how to encode octet strings so they survive that kind of transmission, so that's a whole other vibe 🙈
CMS is derived from PKCS #7 version 1.5, which is specified in RFC 2315 [PKCS#7] 💜. Backward compatibility is kept wherever it's possible 🫶. Changes were still needed, though, to support version 1 attribute certificate transfer and key agreement, plus symmetric key-encryption key techniques for key management 🔥.
1.1. Changes Since RFC 2630
Okay so this document obsoletes RFC 2630 [OLDCMS] and RFC 3211 [PWRI] 💅. Password-based key management is now part of the CMS spec 🔑. There's also an extension mechanism, so new key management schemes can be added without changing CMS again 🌈. Backward compatibility with RFC 2630 and RFC 3211 is preserved ✨. Version 2 attribute certificate transfer is new, though. Version 1 attribute certificates are deprecated, so bye-bye to those 🥀
S/MIME v2 signatures [OLDMSG] are based on PKCS#7 version 1.5 🍓. They're compatible with S/MIME v3 signatures [MSG], which are based on RFC 2630 💖. There are still some subtle compatibility issues between PKCS#7 version 1.5 signatures and CMS 🙃. Those are covered in section 5.2.1 🔍
Specific cryptographic algorithms aren't discussed in this document 🔐. They were discussed in RFC 2630, but that discussion has been moved to a separate document [CMSALG] 📦. Splitting the protocol and algorithm specs means the IETF can update each one independently 🦋. This specification doesn't require any particular algorithms to be implemented ✨. Instead, protocols that rely on CMS are expected to pick appropriate algorithms for their environment 💜. Those algorithms can come from [CMSALG] or from somewhere else 🌸
1.2. Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [STDWORDS] 📝. These are the capitalised words to watch for, bestie 👀
2. General Overview 🌈
CMS is general enough to support lots of different content types 🎀. This document defines one protection content, called ContentInfo 🎁. ContentInfo wraps a single identified content type, and that type can provide further encapsulation 🪆. This document defines six content types: data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data 💅. Other content types can be defined outside this document too 🦋
An implementation that conforms to this specification MUST implement the protection content, ContentInfo, and MUST implement the data, signed-data, and enveloped-data content types 🔥. The other content types MAY be implemented 💖
Here's the general design philosophy: each content type allows single pass processing using indefinite-length Basic Encoding Rules (BER) encoding ⚡. Single-pass operation matters a lot when the content is large, stored on tapes, or "piped" from another process 🍿. It has one big drawback, though 😩. It's hard to do encode operations with the Distinguished Encoding Rules (DER) [X.509-88] in a single pass, because the lengths of the various components might not be known ahead of time 📏. Even so, signed attributes inside the signed-data content type, and authenticated attributes inside the authenticated-data content type, have to be sent in DER form 🔒. That's so recipients can verify content that has one or more unrecognised attributes 🧐. Signed attributes and authenticated attributes are the only data types in CMS that need DER encoding, so they're the special snowflakes here ❄️🫶
3. General Syntax 🧚
The following object identifier identifies the content information type 🆔:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }CMS links a content type identifier to a piece of content 🔗. The syntax MUST have ASN.1 type ContentInfo 💎:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIERHere's what the ContentInfo fields mean 💁♀️:
contentTypesays what kind of content it is. It's an object identifier, which is a unique string of integers assigned by whichever authority defines that content type 🏷️contentis the associated content itself. Its type can be figured out uniquely fromcontentType🎯. The data, signed-data, enveloped-data, digested-data, encrypted-data, and authenticated-data types are all defined in this document 📚. If other documents define extra content types, the ASN.1 type they define SHOULD NOT be a CHOICE type 🙅♀️
That's the first chunk, bestie. Part 2 is coming with Section 4 and the signed-data stuff 💜🦋
4. Data Content Type 🧚
Okay bestie, the data content type is up next 💖 Its object identifier is:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }This one is meant for arbitrary octet strings, like ASCII text files, and what they actually mean is up to the application 🦋 The strings don't need any internal structure, though they totally could have their own ASN.1 definition or other structure if they want to, iykyk 🌸
S/MIME uses id-data to identify MIME encoded content. The use of this content identifier is specified in RFC 2311 for S/MIME v2 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG] ✨
The data content type is generally wrapped up inside the signed-data, enveloped-data, digested-data, encrypted-data, or authenticated-data content type 🎀
5. Signed-data Content Type 👑
The signed-data content type is giving main character energy 💅 It holds content of any type plus zero or more signature values. Any number of signers can sign any type of content in parallel, no cap 🔥
The typical app for signed-data is one signer's digital signature on content of the data content type. Another typical use is spreading out certificates and certificate revocation lists (CRLs) 🌈
Here's how signed-data gets built, step by step 🦋
- For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information are digested with the signer's message digest algorithm (see Section 5.4), and the result becomes the "message digest."
- For each signer, the message digest is digitally signed using the signer's private key.
- For each signer, the signature value and other signer-specific information are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and those not corresponding to any signer, are collected in this step.
- The message digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1.
On the receiving end, a recipient independently computes the message digest 🫶 That message digest and the signer's public key then get used to verify the signature value. The signer's public key is referenced either by an issuer distinguished name along with an issuer-specific serial number, or by a subject key identifier that uniquely identifies the certificate containing the public key. The signer's certificate can be included in the SignedData certificates field ✨
This section is divided into six parts. The first part describes the top-level type SignedData, the second part describes EncapsulatedContentInfo, and the third part describes the per-signer information type SignerInfo. The fourth, fifth, and sixth parts describe the message digest calculation, signature generation, and signature verification processes, respectively 🧚
5.1. SignedData Type
The object identifier for the signed-data content type is:
id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }The signed-data content type shall have ASN.1 type SignedData 💖
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfoOkay, so here's what each field of SignedData means 🎀
version is the syntax version number 🔢 The right value depends on certificates, eContentType, and SignerInfo. The version MUST be assigned as follows:
IF (certificates is present) AND
(any version 2 attribute certificates are present)
THEN version MUST be 4
ELSE
IF ((certificates is present) AND
(any version 1 attribute certificates are present)) OR
(encapContentInfo eContentType is other than id-data) OR
(any SignerInfo structures are version 3)
THEN version MUST be 3
ELSE version MUST be 1digestAlgorithms is a collection of message digest algorithm identifiers 🌸 There MAY be any number of elements in the collection, including zero. Each element identifies the message digest algorithm, along with any associated parameters, used by one or more signer. The collection is meant to list the message digest algorithms employed by all of the signers, in any order, to make one-pass signature verification easier. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. The message digesting process is described in Section 5.4.
encapContentInfo is the signed content, made up of a content type identifier and the content itself. Details of the EncapsulatedContentInfo type are discussed in section 5.2 🦋
certificates is a collection of certificates. The set of certificates is meant to be enough to contain chains from a recognized "root" or "top-level certification authority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may be certificates enough to contain chains from two or more independent top-level certification authorities. There may also be fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessary certificates (e.g., from a previous set of certificates). The signer's certificate MAY be included. The use of version 1 attribute certificates is strongly discouraged 🙈
crls is a collection of certificate revocation lists (CRLs) 📜 The set is meant to contain information sufficient to determine whether or not the certificates in the certificates field are valid, but that correspondence isn't strictly necessary. There MAY be more CRLs than necessary, and there MAY also be fewer CRLs than necessary.
signerInfos is a collection of per-signer information. There MAY be any number of elements in the collection, including zero. The details of the SignerInfo type are discussed in section 5.3 ✨ Each signer can use a digital signature technique, and future specifications could update the syntax. So all implementations MUST gracefully handle unimplemented versions of SignerInfo 🫶 Also, since all implementations won't support every possible signature algorithm, all implementations MUST gracefully handle unimplemented signature algorithms when they come up 💀
5.2. EncapsulatedContentInfo Type
The content gets represented in the type EncapsulatedContentInfo 🎁
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
ContentType ::= OBJECT IDENTIFIERHere's what the fields of EncapsulatedContentInfo mean 🌈
eContentType is an object identifier. The object identifier uniquely specifies the content type 🔑
eContent is the content itself, carried as an octet string. The eContent need not be DER encoded 🍓
The optional omission of eContent within the EncapsulatedContentInfo field makes it possible to construct "external signatures" 🦋 With external signatures, the content being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present 🧚
In the degenerate case where there are no signers, the EncapsulatedContentInfo value being "signed" is irrelevant 🙈 In this case, the content type within the EncapsulatedContentInfo value being "signed" MUST be id-data (as defined in section 4), and the content field of the EncapsulatedContentInfo value MUST be omitted.
5.2.1 Compatibility with PKCS #7 ✨
okay bestie, this part is a little warning for anyone who wants to support BOTH the CMS and PKCS #7 [PKCS#7] SignedData content types 🫶 Both of them tag the encapsulated content with an object identifier, but in PKCS #7 the ASN.1 type of the content itself is totally variable 💀
PKCS #7 defines content like this:
content [0] EXPLICIT ANY DEFINED BY contentType OPTIONALThe CMS defines eContent like this:
eContent [0] EXPLICIT OCTET STRING OPTIONALThe CMS version is way easier to use in most apps, and it's compatible with both S/MIME v2 and S/MIME v3 💖 Signed S/MIME messages made with CMS and PKCS #7 match up too, because identical signed message formats are specified in RFC 2311 for S/MIME v2 [OLDMSG] and RFC 2633 for S/MIME v3 [MSG]. S/MIME v2 wraps the MIME content in a Data type (that's an OCTET STRING) sitting in the SignedData contentInfo content ANY field, and S/MIME v3 puts the MIME content in the SignedData encapContentInfo eContent OCTET STRING. So in both versions the MIME content lives in an OCTET STRING and the message digest is computed over the same portions of the content 🦋 To be specific, the digest is computed over the octets that make up the value of the OCTET STRING, and the tag and length octets are NOT included, so no sneaking those in 🙈
Now, things get messy when the encapsulated content is NOT formatted using the Data type 😭 For example, when an RFC 2634 [ESS] signed receipt gets encapsulated in the CMS signedData type, the Receipt SEQUENCE goes into the signedData encapContentInfo eContent OCTET STRING, and the message digest is computed over the entire Receipt SEQUENCE encoding (tag, length AND value octets). But if an RFC 2634 signed receipt gets encapsulated in the PKCS #7 signedData type, the Receipt SEQUENCE is DER encoded [X.509-88] in the SignedData contentInfo content ANY field (a SEQUENCE, not an OCTET STRING). That means the message digest is computed using only the value octets of the Receipt SEQUENCE encoding. Different vibes, different digests 🌈
Here's a strategy for backward compatibility with PKCS #7 when you're PROCESSING a SignedData content type. If the implementation can't ASN.1 decode the signedData type using the CMS signedData encapContentInfo eContent OCTET STRING syntax, then the implementation MAY try to decode the signedData type using the PKCS #7 SignedData contentInfo content ANY syntax and compute the message digest accordingly ✨
And here's one for backward compatibility with PKCS #7 when you're CREATING a SignedData content type where the encapsulated content is NOT formatted using the Data type 🎀 Implementations MAY examine the value of the eContentType, and then adjust the expected DER encoding of eContent based on the object identifier value. For example, to support Microsoft AuthentiCode, the following information MAY be included:
eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 }
eContent contains DER encoded AuthentiCode signing information5.3 SignerInfo Type 🧚
Per-signer info is represented in the type SignerInfo:
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
SignatureValue ::= OCTET STRINGHere's what the SignerInfo fields mean 💅
versionis the syntax version number. If the SignerIdentifier is the CHOICE issuerAndSerialNumber, then the version MUST be 1. If the SignerIdentifier is subjectKeyIdentifier, then the version MUST be 3.sidspecifies the signer's certificate (and therefore the signer's public key) 🔑 The recipient needs the signer's public key to verify the signature. SignerIdentifier gives you two options for specifying it. The issuerAndSerialNumber option identifies the certificate by the issuer's distinguished name and the certificate serial number. The subjectKeyIdentifier option identifies the certificate by the X.509 subjectKeyIdentifier extension value.
Implementations MUST support RECEIVING both the issuerAndSerialNumber and subjectKeyIdentifier forms of SignerIdentifier. When GENERATING a SignerIdentifier, implementations MAY support one of the forms (either issuerAndSerialNumber or subjectKeyIdentifier) and always use it, or implementations MAY arbitrarily mix the two forms. Choose your own adventure 🍓
digestAlgorithmidentifies the message digest algorithm, and any associated parameters, that the signer used. The message digest is computed on either the content being signed or the content together with the signed attributes, using the process described in section 5.4. The message digest algorithm SHOULD be among those listed in the digestAlgorithms field of the associated SignerData. Implementations MAY fail to validate signatures that use a digest algorithm that is not included in the SignedData digestAlgorithms set. Rude, but allowed 🙈signedAttrsis a collection of attributes that are signed. The field is optional, BUT it MUST be present if the content type of the EncapsulatedContentInfo value being signed is not id-data. SignedAttributes MUST be DER encoded, even if the rest of the structure is BER encoded. Useful attribute types, like signing time, are defined in Section 11. If the 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 signed. Section 11.1 defines the content-type attribute. However, the content-type attribute MUST NOT be used as part of a countersignature unsigned attribute as defined in section 11.4.
- A message-digest attribute, having as its value the message digest of the content. Section 11.2 defines the message-digest attribute.
signatureAlgorithmidentifies the signature algorithm, and any associated parameters, that the signer used to generate the digital signature.signatureis the result of digital signature generation, using the message digest and the signer's private key. The details depend on the signature algorithm employed 🔐unsignedAttrsis a collection of attributes that are NOT signed. The field is optional. Useful attribute types, like countersignatures, are defined in Section 11.
Here's what the SignedAttribute and UnsignedAttribute fields mean 🌸
attrTypeindicates the type of attribute. It's an object identifier.attrValuesis a set of values that make up the attribute. The type of each value in the set can be figured out uniquely from attrType. The attrType can put restrictions on how many items are in the set.
5.4 Message Digest Calculation Process 💜
The message digest calculation process computes a message digest on either the content being signed or the content together with the signed attributes. Either way, the initial input is the "value" of the encapsulated content being signed. To be exact, the initial input is the encapContentInfo eContent OCTET STRING that the signing process is applied to. ONLY the octets that make up the value of the eContent OCTET STRING go into the message digest algorithm, not the tag or the length octets 🙅♀️
The result depends on whether the signedAttrs field is present. When the field is absent, the result is just the message digest of the content, as described above. When the field IS present, the result is the message digest of the complete DER encoding of the SignedAttrs value contained in the signedAttrs field. Since the SignedAttrs value, when present, must contain the content-type and the message-digest attributes, those values are indirectly included in the result. The content-type attribute MUST NOT be included in a countersignature unsigned attribute as defined in section 11.4.
Quick heads-up: a separate encoding of the signedAttrs field is done for the message digest calculation. The IMPLICIT [0] tag in signedAttrs is NOT used for the DER encoding. Instead, an EXPLICIT SET OF tag is used. That means the DER encoding of the EXPLICIT SET OF tag, NOT of the IMPLICIT [0] tag, MUST be included in the message digest calculation, along with the length and content octets of the SignedAttributes value 🎀
When the signedAttrs field is absent, only the octets making up the value of the signedData encapContentInfo eContent OCTET STRING (for example, the contents of a file) get fed into the message digest calculation. The upside is that the length of the content being signed doesn't need to be known in advance of the signature generation process ✨
Now, even though the tag and length octets of the encapContentInfo eContent OCTET STRING are NOT included in the message digest calculation, they're still protected by other means 🛡️ The length octets are protected by the nature of the message digest algorithm, since it's computationally infeasible to find any two distinct message contents of any length that have the same message digest.
5.5 Signature Generation Process 🔥
The input to the signature generation process includes the result of the message digest calculation process and the signer's private key. The details of signature generation depend on the signature algorithm employed. The object identifier, along with any parameters, that specifies the signature algorithm the signer used is carried in the signatureAlgorithm field. The signature value the signer generates MUST be encoded as an OCTET STRING and carried in the signature field 💖
5.6. Signature Verification Process ✨
okay so this is where the recipient becomes the detective 🕵️♀️💅 The inputs are the result of the message digest calculation process and the signer's public key. The recipient MAY grab the correct public key for the signer by any means, but the preferred move is pulling it from a certificate in the SignedData certificates field 🎀 Picking and validating that key MAY be based on certification path validation (see [PROFILE]) plus other external context, but honestly that's a whole other story and it's beyond the scope of this document 🙈 The details of the signature verification depend on whichever signature algorithm got used.
The recipient MUST NOT rely on any message digest values computed by the originator 💀 Trust your own math, bestie. If the SignedData signerInfo includes signedAttributes, then the content message digest MUST be calculated as described in section 5.4. For the signature to be valid, the message digest value the recipient calculated MUST be the same as the value of the messageDigest attribute included in the signedAttributes of the SignedData signerInfo. Main character energy, but make it verifiable 👑
If the SignedData signerInfo includes signedAttributes, then the content-type attribute value MUST match the SignedData encapContentInfo eContentType value 🫶
6. Enveloped-data Content Type 🧚
okay this one is so iconic 💜 The enveloped-data content type is made of encrypted content of any type, plus encrypted content-encryption keys for one or more recipients. The combo of the encrypted content and one encrypted content-encryption key for a recipient is a "digital envelope" for that recipient 💌 Any type of content can be enveloped for an arbitrary number of recipients, using any of the three key management techniques for each recipient. Literally so flexible 😭
The typical application of the enveloped-data content type will represent one or more recipients' digital envelopes on content of the data or signed-data content types 🌸
Enveloped-data gets built in these steps:
- A content-encryption key for a particular content-encryption algorithm is generated at random 🎲
- The content-encryption key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used, but four general techniques are supported:
- key transport: the content-encryption key is encrypted in the recipient's public key 🔐
- key agreement: the recipient's public key and the sender's private key are used to generate a pairwise symmetric key, then the content-encryption key is encrypted in the pairwise symmetric key 🤝
- symmetric key-encryption keys: the content-encryption key is encrypted in a previously distributed symmetric key-encryption key; and 🗝️
- passwords: the content-encryption key is encrypted in a key-encryption key that is derived from a password or other shared secret value 🙊
- For each recipient, the encrypted content-encryption key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2 🎁
- The content is encrypted with the content-encryption key. Content encryption may require that the content be padded to a multiple of some block size; see Section 6.3 🧁
- The RecipientInfo values for all the recipients are collected together with the encrypted content to form an EnvelopedData value as defined in Section 6.1 ✨
A recipient opens the digital envelope by decrypting one of the encrypted content-encryption keys, and then decrypting the encrypted content with the recovered content-encryption key. Unwrapping era 🎀
This section is divided into four parts. The first part describes the top-level type EnvelopedData, the second part describes the per-recipient information type RecipientInfo, and the third and fourth parts describe the content-encryption and key-encryption processes 🦋
6.1. EnvelopedData Type 💖
The following object identifier identifies the enveloped-data content type 🌈
id-envelopedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }The enveloped-data content type shall have ASN.1 type EnvelopedData:
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF AttributeThe fields of type EnvelopedData have the following meanings:
version is the syntax version number. The appropriate value depends on originatorInfo, RecipientInfo, and unprotectedAttrs. The version MUST be assigned as follows 🧮
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is present) OR
(unprotectedAttrs is present) OR
(any RecipientInfo structures are a version other than 0)
THEN version is 2
ELSE version is 0originatorInfo optionally provides information about the originator. It is present only if required by the key management algorithm. It may contain certificates and CRLs 📜
certsis a collection of certificates.certsmay contain originator certificates associated with several different key management algorithms.certsmay also contain attribute certificates associated with the originator. The certificates contained incertsare intended to be sufficient for all recipients to build certification paths from a recognized "root" or "top-level certification authority." However,certsmay contain more certificates than necessary, and there may be certificates sufficient to make certification paths from two or more independent top-level certification authorities. Alternatively,certsmay contain fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessary certificates (e.g., from a previous set of certificates). 🗂️crlsis a collection of CRLs. It is intended that the set contain information sufficient to determine whether or not the certificates in thecertsfield are valid, but such correspondence is not necessary. There MAY be more CRLs than necessary, and there MAY also be fewer CRLs than necessary. 🧾
recipientInfos is a collection of per-recipient information. There MUST be at least one element in the collection. 👯
encryptedContentInfo is the encrypted content information. ✨
unprotectedAttrs is a collection of attributes that are not encrypted. The field is optional. Useful attribute types are defined in Section 11. 🌸
The fields of type EncryptedContentInfo have the following meanings:
contentType indicates the type of content. 🎀
contentEncryptionAlgorithm identifies the content-encryption algorithm, and any associated parameters, used to encrypt the content. The content-encryption process is described in Section 6.3. The same content-encryption algorithm and content-encryption key are used for all recipients. 🔑
encryptedContent is the result of encrypting the content. The field is optional, and if the field is not present, its intended value must be supplied by other means. 🫧
The recipientInfos field comes before the encryptedContentInfo field so that an EnvelopedData value may be processed in a single pass. Efficiency is so hot right now 🔥
6.2. RecipientInfo Type 💅
Per-recipient information is represented in the type RecipientInfo. RecipientInfo has a different format for each of the supported key management techniques. Any of the key management techniques can be used for each recipient of the same encrypted content. In all cases, the encrypted content-encryption key is transferred to one or more recipients 🦋
Since all implementations will not support every possible key management algorithm, all implementations MUST gracefully handle unimplemented algorithms when they are encountered. For example, if a recipient receives a content-encryption key encrypted in their RSA public key using RSA-OAEP and the implementation only supports RSA PKCS #1 v1.5, then a graceful failure must be implemented. Not every app can do everything, and that's okay, but it has to fail nicely 🙈
Implementations MUST support key transport, key agreement, and previously distributed symmetric key-encryption keys, as represented by ktri, kari, and kekri, respectively. Implementations MAY support the password-based key management as represented by pwri. Implementations MAY support any other key management technique as represented by ori. Since each recipient can employ a different key management technique and future specifications could define additional key management techniques, all implementations MUST gracefully handle unimplemented alternatives within the RecipientInfo CHOICE, all implementations MUST gracefully handle unimplemented versions of otherwise supported alternatives within the RecipientInfo CHOICE, and all implementations MUST gracefully handle unimplemented or unknown ori alternatives. The future is wide open, babe 🌈
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING6.2.1. KeyTransRecipientInfo Type 🔐
okay so this is the key transport one 💌 Per-recipient info that uses key transport gets represented in the type KeyTransRecipientInfo. Each instance of KeyTransRecipientInfo carries the content-encryption key to exactly one recipient. one instance, one person, very personal 🫶
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }Here's what each field is doing ✨
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. so the version basically tells you which identifier style you're looking at 🧚
rid tells you which recipient's certificate or key the sender used to protect the content-encryption key 🦋 RecipientIdentifier gives you two ways to point at that certificate, and through it, the recipient's public key. The recipient's certificate has to contain a key transport public key, so a recipient X.509 version 3 certificate with a key usage extension MUST assert the keyEncipherment bit 🔥 The content-encryption key gets encrypted with that recipient's public key. The issuerAndSerialNumber option finds the cert by the issuer's distinguished name plus the certificate serial number. The subjectKeyIdentifier option finds it by the X.509 subjectKeyIdentifier extension value. For recipient processing, implementations MUST support both of these ways of specifying the recipient's certificate 💅 For sender processing, implementations MUST support at least one of them. no cap, the bar is lowkey low for senders but the receiver has to handle both 😭
keyEncryptionAlgorithm names the key-encryption algorithm, plus 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 🌈
now the key agreement version 🤝 Recipient info that uses key agreement gets represented in the type KeyAgreeRecipientInfo. Each instance will transfer the content-encryption key to one or more recipients who all use the same key agreement algorithm and domain parameters for that algorithm. it's a group chat, but make it cryptographic 💖
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 STRINGthe fields, bestie 👑
version is the syntax version number 🎀 It MUST always be 3. no other number, periodt 💅
originator is a CHOICE with three alternatives that specify the sender's key agreement public key 🦋 The sender uses the matching private key and the recipient's public key to make a pairwise key, and the content-encryption key gets encrypted in that pairwise key. The issuerAndSerialNumber option identifies the sender's certificate, and therefore their public key, by issuer distinguished name plus serial number. The subjectKeyIdentifier option does the same thing using the X.509 subjectKeyIdentifier extension value. The originatorKey option includes the algorithm identifier and the sender's key agreement public key directly. This one allows originator anonymity, since the public key isn't 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 User Keying Material (UKM) so that a different key gets generated each time the same two parties make a pairwise key. Implementations MUST support recipient processing of a KeyAgreeRecipientInfo SEQUENCE that includes a ukm field. Implementations that don't support key agreement algorithms that use UKMs MUST gracefully handle the presence of UKMs 🫶 so even if you can't use it, you still can't crash over it, iykyk
keyEncryptionAlgorithm names the key-encryption algorithm, plus 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 holds a recipient identifier and an encrypted key for one or more recipients 💫 The KeyAgreeRecipientIdentifier is a CHOICE with two alternatives that specify the recipient's certificate, and therefore the recipient's public key, that the sender used to generate a pairwise key-encryption key. The recipient's certificate must contain a key agreement public key, so a recipient X.509 version 3 certificate with a key usage extension MUST assert the keyAgreement bit 🧚 The content-encryption key is encrypted in that pairwise key-encryption key. The issuerAndSerialNumber option identifies the recipient's certificate by issuer distinguished name and serial number, and the RecipientKeyIdentifier is described below. The encryptedKey is the result of encrypting the content-encryption key in the pairwise key-encryption key that came out of the key agreement algorithm. Implementations MUST support both alternatives for specifying the recipient's certificate 🌈
The fields of type RecipientKeyIdentifier mean this 🍓
subjectKeyIdentifier identifies the recipient's certificate by the X.509 subjectKeyIdentifier extension value 💜
date is optional. When it's there, the date tells you which of the recipient's previously distributed UKMs the sender used 📅
other is optional. When it's there, it holds extra info the recipient uses to find the public keying material the sender used 🔍
6.2.3. KEKRecipientInfo Type 🗝️
this one is for recipients who already have a previously distributed symmetric key. Recipient info like this is represented in the type KEKRecipientInfo. Each instance will transfer the content-encryption key to one or more recipients who already 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:
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 names the key-encryption algorithm, plus 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:
keyIdentifier identifies the key-encryption key that was previously distributed to the sender and one or more recipients 🔑
date is optional. When it's there, the date picks out a single key-encryption key from a set that was previously distributed 📆
other is optional. When it's there, it holds extra info the recipient uses to figure out which key-encryption key the sender used 🧩
6.2.4. PasswordRecipientInfo Type 🔒
last one in this batch: recipient info using a password or shared secret value, represented in the type PasswordRecipientInfo. Each instance transfers the content-encryption key to one or more recipients who have that password or shared secret value 🤫
The PasswordRecipientInfo Type is specified in RFC 3211 [PWRI]. It's 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:
version is the syntax version number 🎀 It MUST always be 0. 💖
keyDerivationAlgorithm names the key-derivation algorithm, plus 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 comes from an external source, for example a hardware crypto token like a smart card 💳
keyEncryptionAlgorithm names the encryption algorithm, plus 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 🧚♀️
final stop! Recipient info for additional key management techniques is represented in the type OtherRecipientInfo 🌈 This type lets future documents specify key management techniques that go beyond key transport, key agreement, previously distributed symmetric key-encryption keys, and password-based key management 🚀 Each technique gets uniquely identified by an object identifier.
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }The fields of type OtherRecipientInfo:
oriType identifies the key management technique 🆔
oriValue contains the protocol data elements that a recipient needs in order to use the identified key management technique 📦
6.3. Content-encryption Process ✨
okay so the content-encryption key for whatever content-encryption algorithm you picked gets randomly generated 🎲 bestie. then the data you wanna protect gets padded (more on that rn), and the padded data gets encrypted with that key 🔐. encryption takes any arbitrary string of octets (the data) and turns it into another string of octets (the ciphertext) under control of the content-encryption key 💜. the encrypted data goes into the envelopedData encryptedContentInfo encryptedContent OCTET STRING, periodt 💅
Some content-encryption algorithms assume the input length is a multiple of k octets, where k is greater than one 🧮. for those, the input shall be padded at the trailing end with k-(lth mod k) octets, all having the value k-(lth mod k), where lth is the length of the input. so the input gets one of these tails:
01 -- if lth mod k = k-1
02 02 -- if lth mod k = k-2
.
.
.
k k ... k k -- if lth mod k = 0The 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 handed 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 is content of any type plus a message digest of that content, which is so iconic 🦋
Typically, digested-data 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:
- A message digest is computed on the content with a message-digest algorithm.
- 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 it 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 STRINGthe fields of type DigestedData have these meanings:
versionis 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. 🔢digestAlgorithmidentifies 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. 🧪encapContentInfois the content that is digested, as defined in section 5.2. 📦digestis 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, main character energy ⚡
8. Encrypted-data Content Type 🔒
the encrypted-data content type is encrypted content of any type. Unlike the enveloped-data content type, it has neither recipients nor encrypted content-encryption keys, so keys MUST be managed by other means 🙈
the typical use of encrypted-data is to encrypt data content for local storage, maybe 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 these meanings:
versionis the syntax version number. If unprotectedAttrs is present, then version MUST be 2. If unprotectedAttrs is absent, then version MUST be 0. 🔢encryptedContentInfois the encrypted content information, as defined in Section 6.1. 📦unprotectedAttrsis 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 is content of any type, a message authentication code (MAC), and encrypted authentication keys for one or more recipients. the MAC plus one encrypted authentication key for a recipient is what that recipient needs to verify the integrity of the content. literally any type of content can be integrity protected for any number of recipients 🫶
to build authenticated-data, you do these steps:
- A message-authentication key for a particular message-authentication algorithm is generated at random. 🎲
- The message-authentication key is encrypted for each recipient. The details of this encryption depend on the key management algorithm used. 🔐
- For each recipient, the encrypted message-authentication key and other recipient-specific information are collected into a RecipientInfo value, defined in Section 6.2. 📮
- 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 STRINGthe fields of type AuthenticatedData have these meanings:
versionis the syntax version number. The version MUST be assigned as follows:
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present))
THEN version is 1
ELSE version is 0originatorInfooptionally 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. 🕊️recipientInfosis a collection of per-recipient information, as defined in Section 6.1. There MUST be at least one element in the collection. 📬macAlgorithmis 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. 🧠digestAlgorithmidentifies 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. 🧪encapContentInfois the content that is authenticated, as defined in section 5.2. 📦authAttrsis 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. 🔖
macis the message authentication code. 🔏unauthAttrsis 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 ✨
okay so the MAC calculation process is where the sender cooks up a message authentication code (MAC) 🔥 over either the content itself, or a message digest of the content together with the originator's authenticated attributes. it's literally the whole authentication glow-up 💅
If the authAttrs field is absent, the input to the MAC calculation process is the value of the encapContentInfo eContent OCTET STRING. only the octets that make up the value go into the MAC algorithm. the tag and length octets get left out 🙈 which is iconic, because it means you don't need to know how long the content is before you start generating the MAC 🫶
If the 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. the MAC input is then the DER encoding of authAttrs. the authAttrs field gets encoded a second time for the message digest calculation, and this part is a little plot twist 🦋 the IMPLICIT [2] tag is not used for that DER encoding. an EXPLICIT SET OF tag is used instead. so for the digest calculation, what goes in is the DER encoding of the SET OF tag (not the IMPLICIT [2] tag), along with the length and content octets of the authAttrs value.
The message digest calculation process computes a message digest on the content being authenticated. the starting input is the "value" of the encapsulated content being authenticated. specifically, it's the encapContentInfo eContent OCTET STRING that the authentication process is applied to. only the octets making up the value of that OCTET STRING go into the message digest algorithm, not the tag or length octets. this also means the length of the content doesn't have to be known ahead of time 🌸 the tag and length octets of the eContent OCTET STRING aren't part of the digest, but they're still protected by other means. the length octets are protected by the nature of the message digest algorithm, since it's computationally infeasible to find any two distinct contents of any length that have the same message digest. the digest is basically a bodyguard 🛡️
The input to the MAC calculation process includes the MAC input data we just defined, plus an authentication key that's conveyed in a recipientInfo structure. the exact details of the MAC calculation depend on which MAC algorithm is used (HMAC, for example 🧚). the object identifier, along with any parameters, that identifies the MAC algorithm the originator used gets carried in the macAlgorithm field. the MAC value the originator generates is encoded as an OCTET STRING and carried in the mac field 💖
9.3. MAC Verification
the MAC verification process takes the input data (which depends on whether or not authAttrs is there, as defined in 9.2) plus the authentication key that's conveyed in recipientInfo. the exact details of verification depend on the MAC algorithm employed 🔍
the recipient MUST NOT rely on any MAC values or message digest values computed by the originator. no trusting the sender's homework, periodt 🙅♀️
The content gets authenticated as described in section 9.2. if the originator includes authenticated attributes, then the content of the authAttrs is authenticated as described in section 9.2 too 🎀 for authentication to succeed, the MAC value the recipient calculates MUST be the same as the value of the mac field. and when the authAttrs field is present, the content message digest value the recipient calculates MUST be the same as the message digest value included in the authAttrs message-digest attribute. it's a perfect match or nothing 💅
If the AuthenticatedData includes authAttrs, then the content-type attribute value MUST match the AuthenticatedData encapContentInfo eContentType value. no mismatched vibes allowed 😭
10. Useful Types 🧚
this section is split into two parts. the first part defines algorithm identifiers, and the second part defines other useful types 🌈
10.1. Algorithm Identifier Types
every one of the algorithm identifiers has the same type: AlgorithmIdentifier. the definition of AlgorithmIdentifier is taken from X.509 [X.509-88] 💖
there are many alternatives for each algorithm type 🍓
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 content) to another octet string (the message digest) ✨
DigestAlgorithmIdentifier ::= AlgorithmIdentifier10.1.2. SignatureAlgorithmIdentifier
the SignatureAlgorithmIdentifier type identifies a signature algorithm. examples include RSA, DSA, and ECDSA. a signature algorithm supports signature generation and verification operations. generation uses the message digest and the signer's private key to make a signature value. verification uses the message digest and the signer's public key to figure out whether a signature value is valid. context tells you which operation is meant 🔥
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier10.1.3. KeyEncryptionAlgorithmIdentifier
the KeyEncryptionAlgorithmIdentifier type identifies a key-encryption algorithm, which is the thing that encrypts 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. decryption is just the inverse of that. context tells you which one is intended.
the details of encryption and decryption depend on the key management algorithm being used. key transport, key agreement, previously distributed symmetric key-encrypting keys, and symmetric key-encrypting keys derived from passwords are all supported 🫶
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier10.1.4. ContentEncryptionAlgorithmIdentifier
the ContentEncryptionAlgorithmIdentifier type identifies a content-encryption algorithm. examples include Triple-DES and RC2 ✨ a content-encryption algorithm supports encryption and decryption. encryption maps an octet string (the plaintext) to another octet string (the ciphertext) under control of a content-encryption key. decryption is the inverse, and context tells you which one is meant 💅
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier10.1.5. MessageAuthenticationCodeAlgorithm
the MessageAuthenticationCodeAlgorithm type identifies a message authentication code (MAC) algorithm. examples include DES-MAC and HMAC-SHA-1 🧚 a MAC algorithm supports generation and verification operations. generation and verification both use the same symmetric key, and context tells you which operation is intended 🦋
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier10.1.6. KeyDerivationAlgorithmIdentifier
the KeyDerivationAlgorithmIdentifier type is specified in RFC 3211 [PWRI]. its definition is repeated here "for completeness," which is very thorough of them 🙈
key derivation algorithms turn a password or shared secret value into a key-encryption key 🔑
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier10.2. Other Useful Types
this section defines types that get used in other places in the document. the types aren't listed in any particular order, so no drama 🌸
10.2.1. CertificateRevocationLists
the CertificateRevocationLists type gives a set of certificate revocation lists (CRLs) 📜 the set is meant to hold enough information to tell whether the certificates and attribute certificates it's associated with are revoked. however, there MAY be more CRLs than necessary, or there MAY be fewer CRLs than necessary. yep, both are allowed 🤷♀️
the CertificateList can hold a CRL, an Authority Revocation List (ARL), a Delta CRL, or an Attribute Certificate Revocation List. they all share a common syntax, which is so clean ✨
CRLs are specified in X.509 [X.509-97], and they're profiled for use on the Internet in RFC 3280 [PROFILE] 🌈
the definition of CertificateList is taken from X.509.
CertificateRevocationLists ::= SET OF CertificateList10.2.2. CertificateChoices
the CertificateChoices type gives you one of four things: a PKCS #6 extended certificate [PKCS#6], an X.509 certificate, a version 1 X.509 attribute certificate (ACv1) [X.509-97], or a version 2 X.509 attribute certificate (ACv2) [X.509-00] 🎀
the PKCS #6 extended certificate is obsolete. it's only included for backward compatibility, and PKCS #6 certificates SHOULD NOT be used. ACv1 is obsolete too. it's included for backward compatibility, and ACv1 SHOULD NOT be used. be careful with the old stuff, bestie 😬
the Internet profile of X.509 certificates is specified in the "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile" [PROFILE]. the Internet profile of ACv2 is specified in the "An Internet Attribute Certificate Profile for Authorization" [ACPROFILE] 💜
the definition of Certificate is taken from X.509.
the definitions of AttributeCertificate are taken from X.509-1997 and X.509-2000. the definition from X.509-1997 is assigned to AttributeCertificateV1 (see section 12.2), and the definition from X.509-2000 is assigned to AttributeCertificateV2 🧚
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }10.2.3. CertificateSet
the CertificateSet type provides a set of certificates. the set is meant to be enough to contain chains from a recognized "root" or "top-level certification authority" down to all of the sender certificates it's associated with. however, there may be more certificates than necessary, or there MAY be fewer than necessary 🍓
the precise meaning of a "chain" is outside the scope of this document. some applications may put upper limits on how long a chain can be, and others may enforce certain relationships between the subjects and issuers of certificates in a chain 🌸
CertificateSet ::= SET OF CertificateChoices10.2.4. IssuerAndSerialNumber
the IssuerAndSerialNumber type identifies a certificate, and therefore an entity and a public key, by the distinguished name of the certificate issuer plus an issuer-specific certificate serial number 🪪
the definition of Name is taken from X.501 [X.501-88], and the definition of CertificateSerialNumber is taken from X.509 [X.509-97] ✨
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CertificateSerialNumber ::= INTEGER10.2.5. CMSVersion
the CMSVersion type gives a syntax version number, so things stay compatible with future revisions of this specification 🔢
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }10.2.6. UserKeyingMaterial
the UserKeyingMaterial type gives a syntax for user keying material (UKM) 🔑 some key agreement algorithms need UKMs so that a different key gets generated each time the same two parties make a pairwise key. the sender provides a UKM for use with a specific key agreement algorithm. this is the glue that keeps every handshake unique 💅🌈
UserKeyingMaterial ::= OCTET STRING10.2.7. OtherKeyAttribute
okay so OtherKeyAttribute is the escape hatch 🚪✨ it gives you a syntax for sneaking in other key attributes so the recipient can pick which key the sender used. the attribute object identifier must be registered along with the syntax of the attribute itself. ngl, you should avoid this one when you can, because it might impede interoperability 🙈
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }11. Useful Attributes 💖
this section defines attributes you can use with signed-data, enveloped-data, encrypted-data, or authenticated-data 🎀 the syntax of Attribute is compatible with X.501 [X.501-88] and RFC 3280 [PROFILE]. some of these were originally defined in PKCS #9 [PKCS#9], and others came from an earlier version of this spec [OLDCMS]. the attributes aren't listed in any particular order, so no drama 🦋
more attributes are defined all over the place, especially in the S/MIME Version 3 Message Specification [MSG] and the Enhanced Security Services for S/MIME [ESS]. those also have recommendations on where these attributes should go 🌸
11.1. Content Type
the content-type attribute type specifies the content type of the ContentInfo inside signed-data or authenticated-data 🧚 the content-type attribute type MUST be present whenever signed attributes are present in signed-data, or authenticated attributes are present in authenticated-data. the content-type attribute value MUST match the encapContentInfo eContentType value in the signed-data or authenticated-data. no mismatches, bestie 💅
the content-type attribute MUST be a signed attribute or an authenticated attribute. it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute 🔒
the following object identifier identifies the content-type attribute:
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }content-type attribute values have ASN.1 type ContentType:
ContentType ::= OBJECT IDENTIFIEReven though the syntax is defined as a SET OF AttributeValue, a content-type attribute MUST have a single attribute value. zero or multiple instances of AttributeValue are not permitted 🙅♀️
the SignedAttributes and AuthAttributes syntaxes are each defined as a SET OF Attributes. the SignedAttributes in a signerInfo MUST NOT include multiple instances of the content-type attribute. likewise, the AuthAttributes in an AuthenticatedData MUST NOT include multiple instances of the content-type attribute 💜
11.2. Message Digest
the message-digest attribute type specifies the message digest of the encapContentInfo eContent OCTET STRING being signed in signed-data (see section 5.4) or authenticated in authenticated-data (see section 9.2) 🍓 for signed-data, the message digest is computed using the signer's message digest algorithm. for authenticated-data, it's computed using the originator's message digest algorithm.
inside signed-data, the message-digest signed attribute type MUST be present when there are any signed attributes present. inside authenticated-data, the message-digest authenticated attribute type MUST be present when there are any authenticated attributes present ✨
the message-digest attribute MUST be a signed attribute or an authenticated attribute. it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute 🛡️
the following object identifier identifies the message-digest attribute:
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }message-digest attribute values have ASN.1 type MessageDigest:
MessageDigest ::= OCTET STRINGa message-digest attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. there MUST NOT be zero or multiple instances of AttributeValue present 🫶
the SignedAttributes syntax and AuthAttributes syntax are each defined as a SET OF Attributes. the SignedAttributes in a signerInfo MUST include only one instance of the message-digest attribute. likewise, the AuthAttributes in an AuthenticatedData MUST include only one instance of the message-digest attribute 👑
11.3. Signing Time
the signing-time attribute type specifies the time at which the signer (purportedly) performed the signing process ⏰ it's meant for use in signed-data.
the signing-time attribute MUST be a signed attribute or an authenticated attribute. it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute 🔐
the following object identifier identifies the signing-time attribute:
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }signing-time attribute values have ASN.1 type SigningTime:
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalizedTime GeneralizedTime }Note: The definition of Time matches the one specified in the 1997 version of X.509 [X.509-97].
dates between 1 January 1950 and 31 December 2049 (inclusive) MUST be encoded as UTCTime. any dates with year values before 1950 or after 2049 MUST be encoded as GeneralizedTime 📅
UTCTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYMMDDHHMMSSZ), even where the number of seconds is zero. midnight (GMT) MUST be represented as "YYMMDD000000Z". century information is implicit, and the century MUST be determined as follows:
- where YY is greater than or equal to 50, the year MUST be interpreted as 19YY; and
- where YY is less than 50, the year MUST be interpreted as 20YY.
GeneralizedTime values MUST be expressed in Greenwich Mean Time (Zulu) and MUST include seconds (i.e., times are YYYYMMDDHHMMSSZ), even where the number of seconds is zero. GeneralizedTime values MUST NOT include fractional seconds 🕰️
a signing-time attribute MUST have a single attribute value, even though the syntax is defined as a SET OF AttributeValue. there MUST NOT be zero or multiple instances of AttributeValue present 💅
the SignedAttributes syntax and the AuthAttributes syntax are each defined as a SET OF Attributes. the SignedAttributes in a signerInfo MUST NOT include multiple instances of the signing-time attribute. likewise, the AuthAttributes in an AuthenticatedData MUST NOT include multiple instances of the signing-time attribute 🌈
no requirement is imposed concerning the correctness of the signing time, and accepting a purported signing time is up to the recipient's discretion 🤷♀️ it is expected, however, that some signers, such as time-stamp servers, will be trusted implicitly. big trust energy ⭐
11.4. Countersignature
the countersignature attribute type specifies one or more signatures on the contents octets of the DER encoding of the signatureValue field of a SignerInfo value in signed-data. so basically, the countersignature attribute type countersigns (signs in serial) another signature 🧁
the countersignature attribute MUST be an unsigned attribute. it MUST NOT be a signed attribute, an authenticated attribute, an unauthenticated attribute, or an unprotected attribute 🙌
the following object identifier identifies the countersignature attribute:
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }countersignature attribute values have ASN.1 type Countersignature:
Countersignature ::= SignerInfocountersignature values have the same meaning as SignerInfo values for ordinary signatures, except that:
- the signedAttributes field MUST NOT contain a content-type attribute; there is no content type for countersignatures.
- the signedAttributes field MUST contain a message-digest attribute if it contains any other attributes.
- the input to the message-digesting process is the contents octets of the DER encoding of the signatureValue field of the SignerInfo value with which the attribute is associated.
a countersignature attribute can have multiple attribute values. the syntax is defined as a SET OF AttributeValue, and there MUST be one or more instances of AttributeValue present 🎀
the UnsignedAttributes syntax is defined as a SET OF Attributes. the UnsignedAttributes in a signerInfo may include multiple instances of the countersignature attribute 🦋
a countersignature, since it has type SignerInfo, can itself contain a countersignature attribute. so it's possible to build an arbitrarily long series of countersignatures 🌀🌀🌀
12. ASN.1 Modules ✨
section 12.1 has the ASN.1 module for the CMS, and section 12.2 has the ASN.1 module for the Version 1 Attribute Certificate 💜
12.1. CMS ASN.1 Module ✨
okay so this is the big ASN.1 module for CMS 🎀 it's the official blueprint for every message shape, and the file literally names itself, so bestie you know it's serious 💅
CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Certificate, CertificateList,
CertificateSerialNumber, Name
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) }
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttributeCertificate
FROM PKIXAttributeCertificate { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
attribute-cert(12) }
-- Imports from Appendix B of this document
AttributeCertificateV1
FROM AttributeCertificateVersion1 { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
modules(0) v1AttrCert(15) } ;
-- Cryptographic Message Syntax
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier
SignerInfos ::= SET OF SignerInfo
EncapsulatedContentInfo ::= SEQUENCE {
eContentType ContentType,
eContent [0] EXPLICIT OCTET STRING OPTIONAL }
SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
AttributeValue ::= ANY
SignatureValue ::= OCTET STRING
EnvelopedData ::= SEQUENCE {
version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
OriginatorInfo ::= SEQUENCE {
certs [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
EncryptedContentInfo ::= SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,
encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
EncryptedContent ::= OCTET STRING
UnprotectedAttributes ::= SET SIZE (1..MAX) OF Attribute
RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientInfo,
ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
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
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 }
PasswordRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0
keyDerivationAlgorithm [0] KeyDerivationAlgorithmIdentifier
OPTIONAL,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
OtherRecipientInfo ::= SEQUENCE {
oriType OBJECT IDENTIFIER,
oriValue ANY DEFINED BY oriType }
DigestedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithm DigestAlgorithmIdentifier,
encapContentInfo EncapsulatedContentInfo,
digest Digest }
Digest ::= OCTET STRING
EncryptedData ::= SEQUENCE {
version CMSVersion,
encryptedContentInfo EncryptedContentInfo,
unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
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
DigestAlgorithmIdentifier ::= AlgorithmIdentifier
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
KeyEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
ContentEncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
MessageAuthenticationCodeAlgorithm ::= AlgorithmIdentifier
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
CertificateRevocationLists ::= SET OF CertificateList
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
v1AttrCert [1] IMPLICIT AttributeCertificateV1, -- Obsolete
v2AttrCert [2] IMPLICIT AttributeCertificateV2 }
AttributeCertificateV2 ::= AttributeCertificate
CertificateSet ::= SET OF CertificateChoices
IssuerAndSerialNumber ::= SEQUENCE {
issuer Name,
serialNumber CertificateSerialNumber }
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4) }
UserKeyingMaterial ::= OCTET STRING
OtherKeyAttribute ::= SEQUENCE {
keyAttrId OBJECT IDENTIFIER,
keyAttr ANY DEFINED BY keyAttrId OPTIONAL }
-- The CMS Attributes
MessageDigest ::= OCTET STRING
SigningTime ::= Time
Time ::= CHOICE {
utcTime UTCTime,
generalTime GeneralizedTime }
Countersignature ::= SignerInfo
-- Attribute Object Identifiers
id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3 }
id-messageDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4 }
id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5 }
id-countersignature OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 6 }
-- Obsolete Extended Certificate syntax from PKCS#6
ExtendedCertificateOrCertificate ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate }
ExtendedCertificate ::= SEQUENCE {
extendedCertificateInfo ExtendedCertificateInfo,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature }
ExtendedCertificateInfo ::= SEQUENCE {
version CMSVersion,
certificate Certificate,
attributes UnauthAttributes }
Signature ::= BIT STRING
END -- of CryptographicMessageSyntax12.2. Version 1 Attribute Certificate ASN.1 Module 🦋
and now the second module, the one for the old-school v1 attribute certificates 🌸 it's the little sibling that CMS imports from, so the two files are basically holding hands 🫶
AttributeCertificateVersion1
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) v1AttrCert(15) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All
IMPORTS
-- Imports from RFC 3280 [PROFILE], Appendix A.1
AlgorithmIdentifier, Attribute, CertificateSerialNumber,
Extensions, UniqueIdentifier
FROM PKIX1Explicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-explicit(18) }
-- Imports from RFC 3280 [PROFILE], Appendix A.2
GeneralNames
FROM PKIX1Implicit88 { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
pkix1-implicit(19) }
-- Imports from RFC 3281 [ACPROFILE], Appendix B
AttCertValidityPeriod, IssuerSerial
FROM PKIXAttributeCertificate { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) mod(0)
attribute-cert(12) } ;
-- Definition extracted from X.509-1997 [X.509-97], but
-- different type names are used to avoid collisions.
AttributeCertificateV1 ::= SEQUENCE {
acInfo AttributeCertificateInfoV1,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
AttributeCertificateInfoV1 ::= SEQUENCE {
version AttCertVersionV1 DEFAULT v1,
subject CHOICE {
baseCertificateID [0] IssuerSerial,
-- associated with a Public Key Certificate
subjectName [1] GeneralNames },
-- associated with a name
issuer GeneralNames,
signature AlgorithmIdentifier,
serialNumber CertificateSerialNumber,
attCertValidityPeriod AttCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUniqueID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL }
AttCertVersionV1 ::= INTEGER { v1(0) }
END -- of AttributeCertificateVersion113. References 📚✨
okay bestie, here's the reading list 🤓 Every spec in this doc is pointing at these, so they're all listed with their full details:
- [ACPROFILE] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
- [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3269, August 2002.
- [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
- [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
- [MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
- [OLDCMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
- [OLDMSG] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
- [PROFILE] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and CRL Profile", RFC 3280, April 2002.
- [PKCS#6] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993.
- [PKCS#7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax, Version 1.5.", RFC 2315, March 1998.
- [PKCS#9] RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993.
- [PWRI] Gutmann, P., "Password-based Encryption for S/MIME", RFC 3211, December 2001.
- [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
- [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
- [X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
- [X.501-88] CCITT. Recommendation X.501: The Directory - Models. 1988.
- [X.509-88] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988.
- [X.509-97] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 1997.
- [X.509-00] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000.
14. Security Considerations 🔐💀
okay this section is SERIOUS, so read it slowly 🫶 CMS gives you a way to digitally sign data, digest data, encrypt data, and authenticate data. That's a lot of power, which means a lot of ways to mess it up 😭
Implementations MUST protect the signer's private key 🔑 If someone gets the signer's private key, they can totally pretend to be the signer. Masquerade alert 🚨
Implementations MUST protect the key management private key, the key-encryption key, and the content-encryption key 🔐 If the key management private key or the key-encryption key leaks, everything protected with that key could be disclosed. Same deal with the content-encryption key: if it leaks, the encrypted content tied to it could be exposed 🙈
Implementations MUST protect the key management private key and the message-authentication key 💅 If the key management private key leaks, someone can masquerade as the source of authenticated data. And if the message-authentication key leaks, the content could be changed without anyone noticing, which is so not it 💀
The key management technique used to hand out message-authentication keys MUST itself provide data origin authentication. Otherwise the contents arrive with integrity but from a source nobody can identify 👀 Neither RSA [PKCS#1, NEWPKCS#1] nor Ephemeral-Static Diffie-Hellman [DH-X9.42] gives you the data origin authentication you need. Static-Static Diffie-Hellman [DH-X9.42] does, as long as both the originator and recipient public keys are tied to the right identities in X.509 certificates ✨
When more than two parties share the same message-authentication key, data origin authentication is gone 😬 Anyone who knows that key can compute a valid MAC, so the contents could have come from any one of them. Not the vibe 🙅♀️
Implementations MUST randomly generate content-encryption keys, message-authentication keys, initialization vectors (IVs), and padding 🎲 Generating public/private key pairs also depends on random numbers. If the pseudo-random number generators (PRNGs) are weak, the keys can end up with little or no security. An attacker may find it way easier to recreate the PRNG environment that made the keys and search through that small set of possibilities, instead of brute forcing the entire key space 😱 Generating quality random numbers is genuinely hard. RFC 1750 [RANDOM] has important guidance on this, and Appendix 3 of FIPS Pub 186 [DSS] describes one quality PRNG technique 🌸
When you use key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is set by the weaker of the two 📉 For example, say content is encrypted with Triple-DES using a 168-bit Triple-DES content-encryption key, and that key gets wrapped with RC2 using a 40-bit RC2 key-encryption key. Then you only get at most 40 bits of protection. A trivial search for the 40-bit RC2 key recovers the Triple-DES key, and then the Triple-DES key decrypts the content. Tragic 😭 So implementers MUST ensure that key-encryption algorithms are as strong as or stronger than content-encryption algorithms 💪
Implementers SHOULD be aware that cryptographic algorithms get weaker over time 🕰️ As new cryptanalysis techniques show up and computers get faster, the work factor to break a given algorithm goes down. That's why cryptographic algorithm implementations SHOULD be modular, so new algorithms can be slotted in easily. In other words, implementors SHOULD be prepared for the set of algorithms that MUST be supported to change over time 🦋
The countersignature unsigned attribute includes a digital signature computed over the content signature value, so the countersigning process doesn't need to know the original signed content 🧚 That's a real efficiency win, but it can also let someone countersign an inappropriate signature value 👀 So implementations that perform countersignatures SHOULD either verify the original signature value before countersigning it (which means processing the original content), or SHOULD perform countersigning in a context that makes sure only appropriate signature values get countersigned. Yes, that second option is the other SHOULD, bestie 💖
15. Acknowledgments 🫶🌈
This document is the result of contributions from a whole bunch of professionals 🙌 Huge appreciation for all the hard work of the IETF S/MIME Working Group ✨ Special thanks to Rich Ankney, Simon Blake-Wilson, Tim Dean, Steve Dusse, Carl Ellison, Peter Gutmann, Bob Jueneman, Stephen Henson, Paul Hoffman, Scott Hollenbeck, Don Johnson, Burt Kaliski, John Linn, John Pawling, Blake Ramsdell, Francois Rousseau, Jim Schaad, and Dave Solo for their efforts and support 💜
16. Authors' Address 🎀
Russell Housley
RSA Laboratories
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: rhousley@rsasecurity.com17. Full Copyright Statement 📜
Copyright (C) The Internet Society (2002). 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. 🧚
📦 where this page comes from
- ietf: rfc3369 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms