RFC 2311

S/MIME Version 2 Message Specification

📅 published March 1998, from ietf

part 1 of 6 🎀

RFC 2311: S/MIME Version 2 Message Specification 💌

okay bestie, here's the title block so you know who's behind this one 🫶

  • RFC: 2311
  • Title: S/MIME Version 2 Message Specification
  • Authors: S. Dusse (RSA Data Security), P. Hoffman (Internet Mail Consortium), B. Ramsdell (Worldtalk), L. Lundblade (Qualcomm), and L. Repka (Netscape)
  • Category: Informational 📚
  • Date: March 1998
  • Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🦋

Status of this Memo ✨

ngl this memo is historical info for the Internet community 📜 It does not specify an Internet standard of any kind 🙈 and distribution of it is unlimited 💅

Copyright (C) The Internet Society (1998). All Rights Reserved. 🫶

1. Introduction 🦋

okay so S/MIME (Secure/Multipurpose Internet Mail Extensions) is the consistent way to send and receive secure MIME data 💌 Built on the popular Internet MIME standard, it gives messaging apps these cryptographic security services:

  • authentication
  • message integrity
  • non-repudiation of origin (using digital signatures)
  • privacy and data security (using encryption) 🔐

S/MIME can be used by traditional mail user agents (MUAs) to add crypto security to mail that gets sent, and to interpret that security in mail that gets received 📬 But it's not just for mail!! It works with any transport that carries MIME data, like HTTP 🌐 Because it uses the object-based features of MIME, secure messages can be exchanged in mixed-transport systems, which is giving flexibility 🦋

Automated message transfer agents can use these services too, with no human intervention needed 🤖 Think signing software-generated documents, or encrypting FAX messages sent over the Internet 📠💅

🙈 Please note: this info is historical material published for the public record, and it is not an IETF standard. When this document says "standard," it means a standard for adopters of S/MIME version 2, not an IETF standard.

1.1 Specification Overview ✨

This document describes a protocol for adding cryptographic signature and encryption services to MIME data 💖 The MIME standard [MIME-SPEC] gives the general structure for the content type of Internet messages, and it allows extensions for new content type applications.

This memo defines how to create a MIME body part that has been cryptographically enhanced according to PKCS #7 [PKCS-7]. It also defines the application/pkcs7-mime MIME type that transports those body parts. Plus, it defines how to create certification requests that conform to PKCS #10 [PKCS-10], and the application/pkcs10 MIME type for transporting those requests 🧚

This memo also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. It also defines the application/pkcs7-signature MIME type, which is also used to transport S/MIME signed messages 🎀 This specification is compatible with PKCS #7 because it uses the data types defined by PKCS #7 ✨

To create S/MIME messages, an agent has to follow the specifications in this memo, plus some of the specs in these documents:

  • "PKCS #1: RSA Encryption", [PKCS-1]
  • "PKCS #7: Cryptographic Message Syntax", [PKCS-7]
  • "PKCS #10: Certification Request Syntax", [PKCS-10]

Throughout this memo, there are requirements and recommendations for how receiving agents handle incoming messages. There are separate ones for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send" 🫶 Most requirements land on handling incoming messages, while recommendations mostly land on creating outgoing ones.

The split between receiving and sending agents also comes from the fact that there will be S/MIME systems that involve software other than traditional Internet mail clients 🤖 S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive one at all, for example 💀 So the requirements and recommendations for the two types of agents are listed separately when that makes sense.

1.2 Terminology 💅

Throughout this memo, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are written in capital letters 🔥 This follows the definitions in [MUSTSHOULD]. [MUSTSHOULD] explains how these key words make the intent of standards track documents as clear as possible. The same key words are used here so implementors can nail interoperability 🦋

1.3 Definitions 📖

For the purposes of this memo, these definitions apply:

  • ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.
  • BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.
  • Certificate: a type that binds an entity's distinguished name to a public key with a digital signature.
  • DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509.
  • 7-bit data: text data with lines less than 998 characters long, where none of the characters have the 8th bit set and there are no NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
  • 8-bit data: text data with lines less than 998 characters, where none of the characters are NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
  • Binary data: arbitrary data.
  • Transfer Encoding: a reversible transformation made on data so 8-bit or binary data may be sent via a channel that only transmits 7-bit data. 🌸

1.4 Compatibility with Prior Practice of S/MIME 🧚

Appendix C has the important info on how S/MIME agents following this specification need to act in order to get the greatest interoperability with earlier S/MIME implementations 💖

2. PKCS #7 Options 🌈

The PKCS #7 message format allows for a wild range of options in content and algorithm support 🤯 This section puts forth a bunch of support requirements and recommendations to get a base level of interoperability across all S/MIME implementations 👑

2.1 DigestAlgorithmIdentifier 🍓

Receiving agents MUST support SHA-1 [SHA1] and MD5 [MD5].

Sending agents SHOULD use SHA-1.

2.2 DigestEncryptionAlgorithmIdentifier ✨

Receiving agents MUST support rsaEncryption, defined in [PKCS-1]. Receiving agents MUST support verification of signatures using RSA public key sizes from 512 bits to 1024 bits.

Sending agents MUST support rsaEncryption. Outgoing messages are signed with a user's private key. The size of the private key is determined during key generation. 🔑

2.3 KeyEncryptionAlgorithmIdentifier 🎀

Receiving agents MUST support rsaEncryption. Incoming encrypted messages contain symmetric keys which are to be decrypted with a user's private key. The size of the private key is determined during key generation.

Sending agents MUST support rsaEncryption. Sending agents MUST support encryption of symmetric keys with RSA public keys at key sizes from 512 bits to 1024 bits. 🔐

2.4 General Syntax 🦋

The PKCS #7 defines six distinct content types: "data", "signedData", "envelopedData", "signedAndEnvelopedData", "digestedData", and "encryptedData". Receiving agents MUST support the "data", "signedData" and "envelopedData" content types. Sending agents may or may not send out any of the content types, depending on the services that the agent supports 🌈

2.4.1 Data Content Type 💌

Sending agents MUST use the "data" content type as the content within other content types to indicate the message content which has had security services applied to it.

2.4.2 SignedData Content Type ✍️

Sending agents MUST use the signedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates.

2.4.3 EnvelopedData Content Type 🫣

This content type is used to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient to use this service. This content type does not provide authentication. 💜

2.5 Attribute SignerInfo Type 🍭

The SignerInfo type allows the inclusion of unauthenticated and authenticated attributes to be included along with a signature.

Receiving agents MUST be able to handle zero or one instance of each of the signed attributes described in this section.

Sending agents SHOULD be able to generate one instance of each of the signed attributes described in this section, and SHOULD include these attributes in each signed message sent.

Additional attributes and values for these attributes may be defined in the future. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner. 🧁

2.5.1 Signing-Time Attribute ⏰

The signing-time attribute is used to convey the time that a message was signed. Until there are trusted timestamping services, the time of signing will most likely be created by a message originator, and therefore it is only as trustworthy as the originator 🤷‍♀️

Sending agents MUST encode signing time through the year 2049 as UTCTime. Signing times in 2050 or later MUST be encoded as GeneralizedTime. Agents MUST interpret the year field (YY) as follows: if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY 😭✨

2.5.2 S/MIME Capabilities Attribute ✨

Okay bestie, this attribute is where you list everything you can actually do 💅 Signature algorithms (like md5WithRSAEncryption), symmetric algorithms (like DES-CBC), and key encipherment algorithms (like rsaEncryption) all go in here. There's also one non-algorithm capability: your preference for signedData 🎀. SMIMECapabilities was built to be super flexible and extensible, so later on you can add stuff like certificates without breaking current clients 🦋 (nobody gets left on read 😭).

The list is a partial list of what the announcing client can support 💜. You don't have to list every capability you've got, and honestly you probably shouldn't, or the list gets way too long. In an SMIMECapabilities encoding, the OIDs go in order of preference, but they SHOULD be logically separated by category (signature algorithms, symmetric algorithms, key encipherment algorithms, etc.) 🌸

The structure is designed for simple table lookups and binary comparisons when figuring out matches 🔍. For example, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded no matter which implementation made it 💖.

For symmetric algorithms, the parameters attached to the OID MUST specify everything needed to tell two instances of the same algorithm apart 🧚. For RC5, for example, you need the number of rounds and the block size on top of the key length 🙈.

There's a centrally maintained list of OIDs, the registered SMIMECapability list, and it lives outside this memo 📚. The Internet Mail Consortium maintains it at <http://www.imc.org/ietf-smime/oids.html>.

OIDs for algorithms SHOULD use the same OID as the actual algorithm, unless the algorithm's usage is ambiguous from the OID 🎯. For instance, rsaEncryption was ambiguous in an earlier memo, since it could mean a signature algorithm or a key encipherment algorithm 🤷‍♀️. If an OID is ambiguous, the maintainer of the registered S/MIME capabilities list has to arbitrate which type of algorithm gets the OID, and a new OID MUST be allocated under the smimeCapabilities OID to cover the other use 👑.

The registered list specifies parameters for OIDs that need them, most notably key lengths for variable-length symmetric ciphers 🔑. If there are no differentiating parameters for a particular OID, the parameters MUST be omitted, and MUST NOT be encoded as NULL 🚫.

Additional values for SMIMECapability may be defined in the future 🌈. Receiving agents MUST handle a SMIMECapabilities object that has values they don't recognize in a graceful manner 🫶.

2.6 ContentEncryptionAlgorithmIdentifier 🔐

Receiving agents MUST support decryption using RC2 [RC2] or a compatible algorithm at a key size of 40 bits, which we'll call "RC2/40" 🔐. Receiving agents SHOULD support decryption using DES EDE3 CBC, which we'll call "tripleDES" [3DES] [DES] 💪.

Sending agents SHOULD support encryption with RC2/40 and tripleDES ✨.

2.6.1 Deciding Which Encryption Method To Use 🧠

When a sending agent creates an encrypted message, it has to decide which type of encryption to use 💭. That decision uses info from the capabilities lists in messages received from the recipient, plus out-of-band stuff like private agreements, user preferences, legal restrictions, and so on 📋.

Section 2.5 defines a method by which a sending agent can optionally announce (among other things) its decrypting capabilities in order of preference. The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used 🧠.

  • If the receiving agent hasn't created a list of capabilities for the sender's public key yet, then, after verifying the signature on the incoming message and checking the timestamp, the receiving agent SHOULD create a new list containing at least the signing time and the symmetric capabilities 📝.
  • If such a list already exists, the receiving agent SHOULD verify that the signing time in the incoming message is greater than the signing time stored in the list, and that the signature is valid. If so, the receiving agent SHOULD update both the signing time and capabilities in the list. Signing time values that lie far in the future (a greater discrepancy than any reasonable clock skew), or capabilities lists in messages whose signature could not be verified, MUST NOT be accepted 🚨.

The list of capabilities SHOULD be stored for future use when creating messages 💾.

Before sending a message, the sending agent MUST decide whether it's willing to use weak encryption for the particular data in the message 🤔. If the sending agent decides weak encryption is unacceptable for this data, then it MUST NOT use a weak algorithm such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use 🛑.

Sections 2.6.2.1 through 2.6.2.4 describe the decisions a sending agent SHOULD use in deciding which type of encryption should be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given 📜.

2.6.2.1 Rule 1: Known Capabilities 🥇

If the sending agent has received a set of capabilities from the recipient for the message it's about to encrypt, then the sending agent SHOULD use that information by selecting the first capability in the list (that is, the capability most preferred by the intended recipient) for which the sending agent knows how to encrypt. The sending agent SHOULD use one of the capabilities in the list if it reasonably expects the recipient to be able to decrypt the message 💖.

2.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption 🕵️

If:

  • the sending agent has no knowledge of the encryption capabilities of the recipient,
  • and the sending agent has received at least one message from the recipient,
  • and the last encrypted message received from the recipient had a trusted signature on it,

then the outgoing message SHOULD use the same encryption algorithm as was used on the last signed and encrypted message received from the recipient 🕵️.

2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption 🎲

If:

  • the sending agent has no knowledge of the encryption capabilities of the recipient,
  • and the sending agent is willing to risk that the recipient may not be able to decrypt the message,

then the sending agent SHOULD use tripleDES 🎲.

2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption 😬

If:

  • the sending agent has no knowledge of the encryption capabilities of the recipient,
  • and the sending agent is not willing to risk that the recipient may not be able to decrypt the message,

then the sending agent MUST use RC2/40 😬.

2.6.3 Choosing Weak Encryption 🥺

Like all algorithms that use 40-bit keys, RC2/40 is considered by many to be weak encryption 🥺. A sending agent that is controlled by a human SHOULD let the human sender understand the risks of sending data with RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly let the human switch to a stronger method such as tripleDES 💅.

2.6.4 Multiple Recipients 📨

If a sending agent is composing an encrypted message to a group of recipients where some of the recipients' encryption capabilities don't overlap, the sending agent is forced to send more than one message 📨. It should be noted that if the sending agent chooses to send a message encrypted with a strong algorithm, and then sends the same message encrypted with a weak algorithm, someone watching the communications channel can decipher the contents of the strongly-encrypted message simply by decrypting the weakly-encrypted one 👀.

🚨 Bestie, this one's a big deal. Sending the same message twice, once strong and once weak, hands the weak version to anyone watching the channel, and that's enough to read the strong one too. 😭

3. Creating S/MIME Messages ✨

This section describes the S/MIME message formats and how they're created 💌. S/MIME messages are a combination of MIME bodies and PKCS objects, and several MIME types as well as several PKCS objects are used. The data being secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to PKCS processing facilities, which produce a PKCS object. The PKCS object is then wrapped in MIME 🎁.

S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data 🌈. Several formats are required to cover several environments, especially for signed messages. The criteria for choosing among these formats are described too ✨.

The reader is expected to understand MIME as described in [MIME-SPEC] and [MIME-SECURE] 📖.

3.1 Preparing the MIME Entity for Signing or Enveloping 🦋

S/MIME is used to secure MIME entities 🦋. A MIME entity may be a sub-part, sub-parts of a message, or the whole message with all its sub-parts. A MIME entity that is the whole message includes only the MIME headers and MIME body, and does not include the RFC-822 headers. S/MIME can also be used to secure MIME entities used in applications other than Internet mail 💫.

The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it's the "innermost" object in what is possibly a larger MIME message 🪆. Processing "outside" MIME entities into PKCS #7 objects is described in Section 3.2, 3.4 and elsewhere.

The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here, with some additional restrictions when signing. The descriptions of the procedures from [MIME-SPEC] are repeated here, but you should refer to that document for the exact procedure. This section also describes additional requirements 📚.

A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped 🔁. Some additional steps are recommended to defend against known corruptions that can occur during mail transport, and those matter a lot for clear-signing using the multipart/signed format. It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages, so the message can be forwarded to any environment without modification 🛡️.

These steps are descriptive rather than prescriptive. The implementor is free to use any procedure as long as the result is the same 🧩.

Step 1. The MIME entity is prepared according to the local
        conventions

Step 2. The leaf parts of the MIME entity are converted to
        canonical form

Step 3. Appropriate transfer encoding is applied to the leaves of
        the MIME entity

When an S/MIME message is received, the security services on the message are removed, and the result is the MIME entity 📬. That MIME entity is typically passed to a MIME-capable user agent, where it is further decoded and presented to the user or receiving application 💖.

3.1.1 Canonicalization 💖

okay bestie, first things first: every MIME entity MUST be converted into a canonical form that can be represented uniquely and unambiguously in the environment where the signature is created AND the environment where it gets verified 🫶. MIME entities MUST be canonicalized for enveloping too, not just signing. no cap, that's thorough ✨

The exact details depend on the actual MIME type and subtype of the entity, and they aren't spelled out here. Instead you go check the standard for that particular MIME type 📚. Like, canonicalizing text/plain is totally different from canonicalizing audio/basic. Most non-text types have just one representation no matter the computing platform, so that one counts as canonical 🦋. Generally the sending agent does the canonicalization, not the S/MIME implementation 💅

Text is the big one 🌸. MIME entities of major type "text" must have both their line endings and their character set canonicalized. The line ending has to be the pair of characters <CR><LF>, and the charset should be a registered charset [CHARSETS]. All the nitty-gritty is in [MIME-SPEC]. The chosen charset SHOULD be named in the charset parameter so the receiving agent can tell exactly which charset was used, no guessing 🔍

Also, some charsets like ISO-2022 can write the same characters in more than one way 🙈. So when you're prepping text for signing, the canonical representation specified for that charset MUST be used. periodt 💜

3.1.2 Transfer Encoding 🎀

When you're generating any of the secured MIME entities below, EXCEPT signing with the multipart/signed format, you don't need any transfer encoding at all ✨. S/MIME implementations MUST be able to deal with binary MIME objects, bestie 💪. If there's no Content-Transfer-Encoding header, the transfer encoding should be considered 7BIT.

S/MIME implementations SHOULD still use the transfer encoding from section 3.1.3 for every MIME entity they secure 🧚. Why secure only 7-bit entities, even for enveloped data that never gets exposed to the transport? Because then the MIME entity can be handled in any environment without changing it 💖. For example, a trusted gateway might strip the envelope (but leave the signature) and forward the signed message to the end recipient so they can verify the signatures directly. If the transport inside the site isn't 8-bit clean, like a wide-area network with a single mail gateway, you literally can't verify the signature unless the original MIME entity was only 7-bit data 😭

3.1.3 Transfer Encoding for Signing Using multipart/signed 🦋

okay this one is serious. If a multipart/signed entity is EVER going to be sent over the standard Internet SMTP infrastructure, or any other transport that's limited to 7-bit text, it MUST have transfer encoding applied so it's represented as 7-bit text 🔥. MIME entities that are already 7-bit data need no transfer encoding. Stuff like 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding 🌈

The main reason for the 7-bit rule is that the Internet mail transport infrastructure can't guarantee it'll carry 8-bit or binary data. Yes, lots of segments handle 8-bit and even binary now, but sometimes you just can't know if the path is 8-bit clear 🙈. If a message with 8-bit data hits a message transfer agent that can't transmit 8-bit or binary, that agent has three options, and none of them are acceptable for a clear-signed message:

  • The agent could change the transfer encoding. That would invalidate the signature 💀
  • The agent could transmit the data anyway, which would most likely corrupt the 8th bit. That too would invalidate the signature 💀
  • The agent could return the message to the sender.

[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. So if a compliant agent that can't transmit 8-bit or binary data runs into a multipart/signed message with 8-bit or binary data in the first part, it has to return the message to the sender as undeliverable 😤

3.1.4 Sample Canonical MIME Entity 🍓

Here's a multipart/mixed message with full transfer encoding ✨. It has a text part and an attachment. The sample text has characters that aren't US-ASCII, so they have to be transfer encoded. Even though it isn't shown below, the end of each line is <CR><LF> 🎀. The line endings on the MIME headers, the text, and the transfer encoded parts all have to be <CR><LF>.

Heads up: this example is NOT an S/MIME message 🙈

Content-Type: multipart/mixed; boundary=bar

--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

=A1Hola Michael!

How do you like the new S/MIME specification?

I agree. It's generally a good idea to encode lines that begin with
From=20because some mail transport agents will insert a greater-
than (>) sign, thus invalidating the signature.

Also, in some cases it might be desirable to encode any   =20
trailing whitespace that occurs on lines in order to ensure  =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20

--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=

--bar--

3.2 The application/pkcs7-mime Type 🧚

The application/pkcs7-mime type carries PKCS #7 objects of several kinds, including envelopedData and signedData 💖. The later sections explain how to build these entities. This section just covers the general characteristics of application/pkcs7-mime 📚.

This MIME type always carries a single PKCS #7 object. That object must always be BER encoding of the ASN.1 syntax describing it. The contentInfo field of the carried PKCS #7 object always holds a MIME entity prepared as described in section 3.1 ✨. The contentInfo field must never be empty 🙅‍♀️

Since PKCS #7 objects are binary data, base-64 transfer encoding is usually the move, especially with SMTP transport 🦋. Which transfer encoding you use depends on the transport the object is sent through. It's not a characteristic of the MIME type itself.

Note: this part is about the transfer encoding of the PKCS #7 object, the "outside" MIME entity 👀. It's totally separate from, and unrelated to, the transfer encoding of the MIME entity that the PKCS #7 object secures, the "inside" object, which is covered in section 3.1 🫶

Because there are several kinds of application/pkcs7-mime objects, a sending agent SHOULD do as much as it can to help the receiving agent know what's inside, without forcing the receiver to decode the ASN.1 💅. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime-type" parameter, as described in the following sections 🌸

3.2.1 The name and filename Parameters 🎀

For application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter on the Content-Type field for compatibility with older systems 🕰️. Sending agents SHOULD also emit the optional Content-Disposition field [CONTDISP] with the "filename" parameter. If a sending agent emits those parameters, their values SHOULD be a file name with the right extension:

MIME Type                      File Extension

application/pkcs7-mime              .p7m
(signedData, envelopedData)

application/pkcs7-mime              .p7c
(degenerate signedData
"certs-only" message)

application/pkcs7-signature         .p7s

application/pkcs10                  .p10

Also, the file name SHOULD be limited to eight characters followed by a three letter extension 📁. The eight character base can be any distinct name, but using the base "smime" SHOULD be used to show the MIME entity is associated with S/MIME 🧁

Why bother with a file name? Two reasons, babe 💅. It makes S/MIME objects easier to use as files on disk. It also helps carry type info across gateways 🌈. When a MIME entity of type application/pkcs7-mime (for example) hits a gateway that doesn't know anything about S/MIME, the gateway defaults the type to application/octet-stream and treats it as a generic attachment, so the type info gets lost 😭. But the suggested filename for an attachment often survives the trip across a gateway, and that can help the receiving system figure out which app to hand it to, like a stand-alone S/MIME processing app ✨. Just know this is a convenience for certain environments. A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on the file extensions 🙅‍♀️

3.3 Creating an Enveloped-only Message 🦋

This section explains the format for enveloping a MIME entity without signing it 💖.

  Step 1. The MIME entity to be enveloped is prepared according to
          section 3.1.

  Step 2. The MIME entity and other required data is processed into a
          PKCS #7 object of type envelopedData.

  Step 3. The PKCS #7 object is inserted into an application/pkcs7-
          mime MIME entity.

For enveloped-only messages, the smime-type parameter is "enveloped-data" 💜. The file extension for this kind of message is ".p7m" 📁.

A sample message looks like this 🍓:

Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
     name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V

3.4 Creating a Signed-only Message 🧚

There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed 🎀. Generally, the multipart/signed form is the one you'll want to send ✨. Receiving agents SHOULD be able to handle both, though 🫶

3.4.1 Choosing a Format for Signed-only Messages ✨

Okay so there's no hard-and-fast rule for picking a signed-only format 🤷‍♀️. It really depends on what all the receivers can handle, and how much it matters to you that S/MIME-capable folks can verify the signature versus how much it matters that people without S/MIME software can still read the message 💅.

Messages signed with the multipart/signed format are always readable by the receiver, whether they have S/MIME software or not 🦋. They're readable in a MIME-native user agent too, or if a gateway has translated the message 🌸. Here, "be viewed" just means the message can be processed basically as if it weren't signed at all, including any other MIME structure it might have 🧚.

Messages signed with the signedData format can't be read by a recipient unless they have S/MIME facilities 😭. BUT if they do have those facilities, these messages can always be verified, as long as nothing changed them in transit 🔥.

3.4.2 Signing Using application/pkcs7-mime and SignedData 🎀

This signing format uses the application/pkcs7-mime MIME type 💖. Here's how you make it:

  • Step 1. The MIME entity is prepared according to section 3.1
  • Step 2. The MIME entity and other required data is processed into a PKCS #7 object of type signedData
  • Step 3. The PKCS #7 object is inserted into an application/pkcs7-mime MIME entity

The smime-type parameter for messages using application/pkcs7-mime and SignedData is signed-data. The file extension for this type of message is .p7m 🍓.

Here's a sample message, bestie 👑:

    Content-Type: application/pkcs7-mime; smime-type=signed-data;
         name=smime.p7m
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename=smime.p7m

    567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
    77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
    HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
    6YT64V0GhIGfHfQbnj75

3.4.3 Signing Using the multipart/signed Format 🦋

This one is a clear-signing format, and it's giving accessibility 🫶. Recipients with no S/MIME or PKCS processing facilities at all can still view the message. It uses the multipart/signed MIME type described in [MIME-SECURE]. The multipart/signed MIME type has two parts. The first part holds the MIME entity being signed, and the second part holds the signature, which is a PKCS #7 detached signature ✨.

3.4.3.1 The application/pkcs7-signature MIME Type 💜

This MIME type always contains a single PKCS #7 object of type signedData. The contentInfo field of the PKCS #7 object must be empty. The signerInfos field holds the signatures for the MIME entity. You can find the details of the registered type in Appendix D 📚.

The file extension for signed-only messages using application/pkcs7-signature is .p7s 🌈.

3.4.3.2 Creating a multipart/signed Message 🧚

  • Step 1. The MIME entity to be signed is prepared according to section 3.1, taking special care for clear-signing.
  • Step 2. The MIME entity is presented to PKCS #7 processing in order to get an object of type signedData with an empty contentInfo field.
  • Step 3. The MIME entity is inserted into the first part of a multipart/signed message, with no processing other than what's described in section 3.1.
  • Step 4. Transfer encoding is applied to the detached signature, and then it's inserted into a MIME entity of type application/pkcs7-signature.
  • Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.

The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter 🔥.

The protocol parameter MUST be application/pkcs7-signature. Quotation marks are required around the protocol parameter, because MIME requires that the "/" character in the parameter value MUST be quoted 🙈.

The micalg parameter allows for one-pass processing when the signature is being verified. Its value depends on the message digest algorithm used in calculating the Message Integrity Check. The value of the micalg parameter SHOULD be one of the following:

Algorithm used     Value
--------------     ---------
MD5                md5
SHA-1              sha1
any other          unknown

(Historical note: some early implementations of S/MIME emitted and expected rsa-md5 and rsa-sha1 for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they don't recognize 💅.

3.4.3.3 Sample multipart/signed Message 🎀

       Content-Type: multipart/signed;
          protocol="application/pkcs7-signature";
          micalg=sha1; boundary=boundary42

       --boundary42
       Content-Type: text/plain

       This is a clear-signed message.

       --boundary42
       Content-Type: application/pkcs7-signature; name=smime.p7s
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p7s

       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       7GhIGfHfYT64VQbnj756

       --boundary42--

3.5 Signing and Encrypting 🌸

Signing and enveloping can be combined 💞. To do that, any of the signed-only and encrypted-only formats can be nested inside each other. This works because all of the above formats are MIME entities, and because they all secure MIME entities 🫶.

An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient's computer 🔥.

You can either sign a message first or envelope it first, and it's up to the implementor and the user to decide 🤍. When you sign first, the signatories are securely hidden by the enveloping 🙈. When you envelope first, the signatories are exposed, but you can verify signatures without removing the enveloping 🦋. That can be useful in an environment where automatic signature verification is wanted, since no private key material is needed to verify a signature ✨.

3.6 Creating a Certificates-only Message 🧚

A certificates-only message, or MIME entity, is used to transport certificates, for example in response to a registration request 🎀. This format can also be used to convey CRLs 💜.

  • Step 1. The certificates are made available to the PKCS #7 generating process, which creates a PKCS #7 object of type signedData. The contentInfo and signerInfos fields must be empty.
  • Step 2. The PKCS #7 signedData object is enclosed in an application/pkcs7-mime MIME entity.

The smime-type parameter for a certs-only message is certs-only. The file extension for this type of message is .p7c 🍓.

3.7 Creating a Registration Request 💅

A typical application that lets a user generate cryptographic information has to submit that information to a certification authority, which turns it into a certificate 👑. PKCS #10 describes a syntax for certification requests. The application/pkcs10 body type MUST be used to transfer a PKCS #10 certification request 🌈.

The details of certification requests and of getting a certificate are beyond the scope of this memo 🤷‍♀️. Instead, this only defines the format of the data used in application/pkcs10 📚.

3.7.1 Format of the application/pkcs10 Body 💖

PKCS #10 defines the ASN.1 type CertificationRequest for use in submitting a certification request. So when the MIME content type application/pkcs10 is used, the body MUST be a CertificationRequest, encoded using the Basic Encoding Rules (BER) 🎀.

BER is what's specified here, not the more restrictive DER. Still, a typical application will use DER, since the CertificationRequest's CertificationRequestInfo has to be DER-encoded in order to be signed 🧚. A robust application SHOULD output DER, but allow BER or DER on input ✨.

Data produced by BER or DER is 8-bit, but lots of transports are limited to 7-bit data 😭. So a suitable 7-bit Content-Transfer-Encoding SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be used with application/pkcs10, although any 7-bit transfer encoding may work 🦋.

3.7.2 Sending and Receiving an application/pkcs10 Body Part 🌷

To send a certificate-signing request, the application/pkcs10 message format MUST be used to convey a PKCS #10 certificate-signing request. Also, for sending certificates and CRLs without any signed content, the application/pkcs7-mime message format MUST be used to convey a degenerate PKCS #7 signedData "certs-only" message 💜.

To send an application/pkcs10 body, the application generates the cryptographic information for the user. The details of that cryptographic information are beyond the scope of this memo 🫶.

  • Step 1. The cryptographic information is placed within a PKCS #10 CertificationRequest.
  • Step 2. The CertificationRequest is encoded according to BER or DER (typically DER).
  • Step 3. As a typical step, the DER-encoded CertificationRequest is also base64 encoded, so that it's 7-bit data suitable for transfer in SMTP. This then becomes the body of an application/pkcs10 body part.

The result might look something like this 🌈:

       Content-Type: application/pkcs10; name=smime.p10
       Content-Transfer-Encoding: base64
       Content-Disposition: attachment; filename=smime.p10

       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
       0GhIGfHfQbnj756YT64V

A typical application only needs to send a certification request 🙌. It's a certification authority that has to receive and process the request. The steps for recovering the CertificationRequest from the message are straightforward, but they aren't presented here. The procedures for processing the certification request are beyond the scope of this document 🫠.

3.8 Identifying an S/MIME Message 🔍

S/MIME works in non-MIME environments too, so several different mechanisms carry the type information, which makes S/MIME messages kinda tricky to spot 😭. The table below lists the criteria for deciding whether a message is an S/MIME message. A message counts as an S/MIME message if it matches any of them 💖.

The file suffix in the table comes from the "name" parameter in the content-type header, or from the "filename" parameter on the content-disposition header. Those parameters that give the file suffix aren't listed below as part of the parameters section 📎.

MIME type:   application/pkcs7-mime
parameters:  any
file suffix: any

MIME type:   application/pkcs10
parameters:  any
file suffix: any

MIME type:   multipart/signed
parameters:  protocol="application/pkcs7-signature"
file suffix: any

MIME type:   application/octet-stream
parameters:  any
file suffix: p7m, p7s, aps, p7c, p10

4. Certificate Processing ✨

okay bestie, a receiving agent MUST provide some certificate retrieval mechanism so it can actually get its hands on certs for the recipients of digital envelopes 🫶 this doc doesn't go into how S/MIME agents handle certificates. It only covers what they do after a cert has been validated or rejected 💅 cert stuff lives in a different document, so that's where you'd look for the rest 📚

at the very least, for the first S/MIME rollout, a user agent could automatically send a message to the intended recipient asking for their cert in a signed return message 📬 and receiving and sending agents SHOULD also give users a way to "store and protect" certs for their people so they can be retrieved later on 🔐 main character energy for sure

4.1 Key Pair Generation

an S/MIME agent (or some related admin utility or function) MUST be capable of generating RSA key pairs on behalf of the user 🔑 each key pair MUST be generated from a good source of non-deterministic random input and then protected in a secure fashion 🛡️

a user agent SHOULD generate RSA key pairs with a minimum key size of 768 bits and a maximum key size of 1024 bits 📏 a user agent MUST NOT generate RSA key pairs less than 512 bits long 🚫 some agents made in the United States went with 512 bit keys to get more favorable export licenses, but lots of people consider 512 bit keys cryptographically insecure 💀 not it

implementors should be aware that multiple (active) key pairs may be associated with a single individual 🌈 for example, one key pair could support confidentiality while a different key pair handles authentication. iykyk, it's giving multi-tasker 🧚

5. Security Considerations 🚨

this entire memo is about security, so this section is where we talk about the extra stuff that didn't fit anywhere else 😭 pay attention, it matters

40-bit encryption is considered weak by most cryptographers 💀 using weak cryptography in S/MIME offers basically no real security over just sending plaintext 🙈 but other features of S/MIME, like the spec for tripleDES and the ability to announce stronger crypto capabilities to the people you talk to, let senders make messages that use strong encryption ✨ using weak cryptography is never recommended unless the only other option is no cryptography at all. when it's doable, sending and receiving agents should tell senders and recipients how strong the cryptography on a message is 🔥

it's impossible for most software or people to estimate the value of a message 🤷‍♀️ it's also impossible for most of them to estimate the actual cost of decrypting a message encrypted with a key of a particular size. and it's pretty hard to figure out the cost of a failed decryption if a recipient can't decode a message 😵 so choosing between key sizes (or choosing to just use plaintext) is also impossible to do perfectly. however, people make decisions based on these criteria all the time, so this memo gives a framework for using those estimates when choosing algorithms 🧮

if a sending agent sends the same message using different strengths of cryptography, an attacker watching the communications channel can work out the contents of the strongly-encrypted message by decrypting the weakly-encrypted version 😱 so a sender should not send a copy of a message using weaker cryptography than they'd use for the original 🙅‍♀️

A. Object Identifiers and Syntax 🧚

the syntax for SMIMECapability is:

SMIMECapability ::= SEQUENCE {
    capabilityID OBJECT IDENTIFIER,
    parameters OPTIONAL ANY DEFINED BY capabilityID }

SMIMECapabilities ::= SEQUENCE OF SMIMECapability

A.1 Content Encryption Algorithms

RC2-CBC OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2}

for the effective-key-bits (key size) greater than 32 and less than 256, the RC2-CBC algorithm parameters are encoded as:

RC2-CBC parameter ::=  SEQUENCE {
 rc2ParameterVersion  INTEGER,
 iv                   OCTET STRING (8)}

for the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, 58 respectively 🎀

DES-EDE3-CBC OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}

for DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:

CBCParameter :: IV

where IV ::= OCTET STRING -- 8 octets.

A.2 Digest Algorithms

md5 OBJECT IDENTIFIER ::=
 {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}

sha-1 OBJECT IDENTIFIER ::=
 {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}

A.3 Asymmetric Encryption Algorithms

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

rsa OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}

A.4 Signature Algorithms

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

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

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

A.5 Signed Attributes

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

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

B. References 📚

  • [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
  • [CHARSETS] Character sets assigned by IANA. See ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.
  • [CONTDISP] Troost, R., Dorner, S and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
  • [DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983.
  • [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April 1992.
  • [MIME-SPEC] The primary definition of MIME.
    • Freed, N., and N. Borenstein, "MIME Part 1: Format of Internet Message Bodies", RFC 2045, November 1996.
    • Freed, N., and N. Borenstein, "MIME Part 2: Media Types", RFC 2046, November 1996.
    • Moore, K., "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
    • Freed, N., Klensin, J., and J. Postel, "MIME Part 4: Registration Procedures", RFC 2048, November 1996.
    • Freed, N., and N. Borenstein, "MIME Part 5: Conformance Criteria and Examples", RFC 2049, November 1996.
  • [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
  • [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC 2313, March 1998.
  • [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
  • [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, March 1998.
  • [RC2] Rivest, R., "Description of the RC2(r) Encryption Algorithm", RFC 2268, January 1998.
  • [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, DRAFT, 31 May 1994.

C. Compatibility with Prior Practice in S/MIME 🎀

S/MIME was originally developed by RSA Data Security, Inc. 🏛️ lots of developers built S/MIME agents before this document was published, so all S/MIME receiving agents SHOULD make every attempt to interoperate with these earlier implementations 🫶 we stan being nice to older versions

C.1 Early MIME Types

some early S/MIME agents used these MIME types:

application/x-pkcs7-mime
application/x-pkcs7-signature
application/x-pkcs10

in each case, the "x-" subtypes correspond to the subtypes described in this document without the "x-" 🧩

C.2 Profiles

early S/MIME documentation had two encryption profiles: "restricted" and "unrestricted" 🗂️ the difference came about because of US Government export regulations, which I'll explain at the end of this section. it's expected that in the future there will be very few agents that only use the restricted profile 🔮

briefly, the restricted profile required the ability to encrypt and decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit keys. the unrestricted profile required the ability to encrypt and decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-bit keys, AND to encrypt and decrypt using tripleDES 🔐 the restricted profile also had non-mandatory suggestions for other algorithms, but those weren't widely implemented 🥲

it's important to note that lots of current S/MIME implementations use the restricted profile 👀

C.2.1 Historical Reasons for the Existence of Two Encryption Profiles

due to US Government export regulations, an S/MIME agent that supports a strong content encryption algorithm such as DES wouldn't be freely exportable outside of North America 🌎 so US software makers were basically forced to include an exportable, "restricted" content encryption algorithm to make a widely exportable version of their product 📦 S/MIME agents made in the US for US domestic use (or use under special State Department export licenses) can use stronger, "unrestricted" content encryption. but to get interoperability, those agents still need to support whatever exportable algorithm is in the restricted S/MIME agents 🤝

the RC2 symmetric encryption algorithm has been approved by the US Government for "expedited" export licensing at certain key sizes. because of that, support for the RC2 algorithm in CBC mode is required for baseline interoperability in all S/MIME implementations 💅 support for other strong symmetric encryption algorithms, like RC5 CBC, DES CBC and DES EDE3-CBC for content encryption, is strongly encouraged where possible ✨

D. Request for New MIME Subtypes 💌

D.1 application/pkcs7-mime

this is the registration template for the application/pkcs7-mime media type, ready to send to ietf-types@iana.org 💖

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-mime

MIME media type name: application

MIME subtype name: pkcs7-mime

Required parameters: none

Optional parameters: name, filename, smime-type

Encoding considerations: Will be binary data, therefore should use
base64 encoding

Security considerations: Described in [PKCS-7]

Interoperability considerations: Designed to carry data formatted
with PKCS-7, as described in [PKCS-7]

Published specification: RFC 2311

Applications which use this media type: Secure Internet mail and
other secure data transports.

Additional information:
File extension(s): .p7m and .p7c
Macintosh File Type Code(s):

Person & email address to contact for further information:
Steve Dusse, spock@rsa.com

Intended usage: COMMON

D.2 application/pkcs7-signature

okay so this one is the sibling of the last registration form, just for the signature side 💖 same vibe, same paperwork, different slay 💅

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs7-signature

MIME media type name: application

MIME subtype name: pkcs7-signature

Required parameters: none
Optional parameters: name, filename

Encoding considerations: Will be binary data, therefore should use
base64 encoding

Security considerations: Described in [PKCS-7]

Interoperability considerations: Designed to carry digital
signatures with PKCS-7, as described in [PKCS-7]

Published specification: RFC 2311

Applications which use this media type: Secure Internet mail and
other secure data transports.

Additional information:
File extension(s): .p7s
Macintosh File Type Code(s):

Person & email address to contact for further information:
Steve Dusse, spock@rsa.com

Intended usage: COMMON

D.3 application/pkcs10

and now the certificate side 🎀 same energy, just with certificates instead of signatures 🫶

To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs10

MIME media type name: application

MIME subtype name: pkcs10

Required parameters: none

Optional parameters: name, filename

Encoding considerations: Will be binary data, therefore should use
base64 encoding

Security considerations: Described in [PKCS-10]

Interoperability considerations: Designed to carry digital
certificates formatted with PKCS-10, as described in [PKCS-10]

Published specification: RFC 2311

Applications which use this media type: Secure Internet mail and
other transports where certificates are required.

Additional information:
File extension(s): .p10
Macintosh File Type Code(s):

Person & email address to contact for further information:
Steve Dusse, spock@rsa.com

Intended usage: COMMON

E. Encapsulating Signed Messages for Internet Transport

so why are there multiple formats for signing?? 🤔 it comes down to two things: the MIME subtype defaulting rules for the application and multipart top-level types, and how the gateways and mail user agents already out there actually behave 🌸

ideally, multipart/signed would be the only format anyone used, because it's a truly backwards compatible way to sign MIME entities 💅 in a pure MIME world with super capable user agents, that would totally work. but the world is messier than that 😭

okay so the first big problem is gateways that talk to non-MIME environments 🚧 the gateway usually isn't S/MIME aware, it doesn't recognize multipart/signed, and it just falls back to multipart/mixed, which is what the MIME standard says to do. here's where it gets ugly 💀: if the gateway also converts the MIME structure of the original message (the bit sitting in the first part of the multipart/signed structure), like turning text and attachments into the local format, then the message has been taken apart and transformed. the signature was computed over the original MIME structure, so now it just won't verify 🙃 and since the same set of body parts can be MIME-encoded a bunch of different ways, there's no way to rebuild the original MIME entity the signature was made over. not me... being stuck like that 😭

same vibe with user agents 🫠 say you try to bolt an existing mail user agent onto a standalone S/MIME tool. most user agents can hand leaf MIME entities off to "viewer" apps, but they can't hand a multipart sub-entity to a standalone app the same way. the MIME standard doesn't require that, so almost nobody built it. net result: most user agents just can't pass the whole multipart/signed entity to a standalone app. iconic behavior, honestly 💀

E.1 Solutions to the Problem

the fix? 🎀 use application/pkcs7-mime! going through a gateway, it gets defaulted to application/octet-stream and treated as one single opaque entity. so the message just gets treated as an attachment of unknown type, converted to the local attachment format, and it reaches an S/MIME facility completely intact 🧚 a user agent can get the same result by treating the application/pkcs7-mime entity as a simple leaf node in the MIME structure and handing it to viewer apps. main character energy for the message 👑

another option 🦋: wrap the multipart/signed entity inside a MIME entity the gateway won't wreck. when this memo was written, there was a proposal for an "application/mime" entity to do exactly that. ngl though, no S/MIME implementations actually use this kind of wrapping 😬

E.2 Encapsulation in an Non-MIME Environment

this doc is mostly about the Internet, but it's still useful to write and receive S/MIME messages in non-MIME environments 🌈 especially when you want security end-to-end. other parts of this doc cover receiving S/MIME messages in non-MIME environments, and this section is the composing side for multipart/signed entities.

sending from a non-MIME environment: build the multipart/signed entity like we already described 💖 then treat it as an opaque stream of bits and attach it to the message. it must have a file name ending in ".aps", since that's the only way the receiving agent can recognize it as an S/MIME message 🔥

when it lands in a MIME environment, it's likely to show up as application/octet-stream, with MIME parameters giving the attachment's filename 📎 if the gateway in the middle kept the file type, the name will still end in ".aps" and it'll get recognized as an S/MIME message 🥰

F. Acknowledgements

huge thanks 🫶 to everyone who helped shape this memo, especially Jim Schaad, Jeff Thompson, and Jeff Weinstein. significant contributions 💜

G. Authors' Addresses

here's who to thank (and who to DM) 💌

Steve Dusse
RSA Data Security, Inc.
100 Marine Parkway, #500
Redwood City, CA  94065  USA

Phone: (415) 595-8782
EMail: spock@rsa.com


Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060

Phone: (408) 426-9827
EMail: phoffman@imc.org


Blake Ramsdell
Worldtalk
13122 NE 20th St., Suite C
Bellevue, WA 98005

Phone: (425) 882-8861
EMail: blaker@deming.com


Laurence Lundblade
QUALCOMM Incorporated
Eudora Division
6455 Lusk Boulevard
San Diego, California 92121-2779

Phone: (800) 238-3672
EMail: lgl@qualcomm.com
Lisa Repka
Netscape Communications Corporation
501 East Middlefield Road
Mountain View, CA  94043

Phone: (415) 254-1900
EMail: repka@netscape.com

Copyright (C) The Internet Society (1998). 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.

📦 where this page comes from