Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
Extracted elements (19)
In multipart/signed the control information is in the second body part, while in multipart/encrypted the control information is in the first body part. This asymmetry reflects that decryption requires the key/control data before the encrypted payload can be processed.
The 7-bit constraint for SMTP-transported signed objects exists because conversion of 8bit/binary content to 7bit would necessarily invalidate the signature. Since conversion is not viable and the only alternative is a non-delivery notification, the content must be pre-encoded to 7 bits before signing.
The framework delegates all security semantics to an external protocol document identified by the protocol parameter. This allows the framework to be extended to accommodate a variety of protocols simply by registering new protocol parameter values, without modifying this specification.
The micalg parameter is explicitly placed on the multipart/signed Content-Type header to support one-pass processing: implementations can compute MIC values while reading the first body part and stop when the second body part boundary is found, without needing to backtrack.
A MIME agent that does not recognize the value of the protocol parameter cannot process the security multipart, but may continue to process any other body parts that may be present in the enclosing message.
A MIME implementation should not attempt to display the received form of the second body part of a multipart/encrypted because encryption transforms the content in a way not described by MIME headers. Implementations must wait until encryption is removed before displaying the content.
If a multipart/signed object is ever to be transferred over the standard Internet SMTP infrastructure, the MIME body is constrained to 7 bits. Material requiring 8bit or binary content-transfer-encoding MUST be encoded using quoted-printable or base64.
If the MIC algorithm is specified in both the micalg parameter and the control information body part and the two values disagree, it must be treated as an error.
The entire contents of a multipart/signed container MUST be treated as opaque while in transit from originator to recipient. Intermediate message transfer agents must not alter the content in any way, including changing content transfer encodings.
The MIME headers of the body part to be signed (multipart/signed) or encrypted (multipart/encrypted) are included in the cryptographic operation to protect the integrity or confidentiality of the MIME labeling of the protected data.
The value of the protocol parameter and the processing it requires MUST be specified in the document defining the security protocol used. That document must also precisely specify the contents of the control information body part.
A complete MIME-based security protocol specification must include a mechanism for distributing cryptographic material (e.g., public keys for digital signature). The specification suggests optionally defining two additional body part types: one to request and one to return cryptographic information.
multipart/encrypted is a new MIME subtype containing exactly two body parts: the first carries decryption control information (labeled per the protocol parameter), and the second carries the encrypted data always labeled application/octet-stream. Required parameters are boundary and protocol.
multipart/signed is a new MIME subtype containing exactly two body parts: the first is the signed data (including its MIME headers), and the second contains the control information necessary to verify the digital signature. Required parameters are boundary, protocol, and micalg.
The digital signature in a multipart/signed applies only to material actually within the multipart/signed object. It does not apply to any enclosing message material nor to entities referenced (e.g., via MIME message/external-body) rather than included in the signed content.
This specification enhances MIME to support signed and encrypted body parts; the entire document is framed as a security mechanism. Actual security guarantees depend entirely on the specific security protocol referenced by the protocol parameter value.
In multipart/encrypted, the second body part containing encrypted data is always labeled application/octet-stream. The encrypted content itself is a nested MIME body part whose true Content-Type is described in the control information of the first body part, not in its own MIME headers.
The micalg parameter (multipart/signed only) specifies the Message Integrity Check algorithm(s) as a comma-separated list of tokens. The comma character is explicitly excluded from valid token characters. If multiple algorithms are listed, their purpose is defined by the protocol.
The protocol parameter in both multipart/signed and multipart/encrypted is encoded as: protocol = <"> type "/" subtype <">, where type/subtype matches the Content-Type of the control information body part. This parameter is required to be present.