rfc-2480

Gateways and MIME Security Multiparts

N. Freed
date1999-01 streamLegacy statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc2480 doi10.17487/RFC2480
This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]

Extracted elements (10)

design-rationale §4

Since no single solution can satisfy all three conflicting requirements, the only viable approach is to require that gateways provide multiple solutions, allowing selection based on the specific security and interoperability requirements of a given deployment.

security, email

design-rationale §3

The three requirements for security multiparts through gateways — applying security to entire MIME objects, converting MIME to non-MIME formats, and deploying security end-to-end — are fundamentally in conflict. It is possible to satisfy two at once but not all three simultaneously, and no compromise optimizes all three because real-world situations exist where any one requirement may be absolute.

security, email

interoperability-note §3

Gateways often transform MIME type information into other forms such as file extensions or OIDs, and must take apart composite MIME objects into component parts, potentially converting multi-level MIME structures into a sequential list of parts for non-MIME environments.

email

normative-requirement §4 MAY

Gateways MAY provide facilities to check signatures and decrypt encrypted content, but such facilities MUST NOT be enabled by default; the potential security exposure must be assessed before such capabilities are used.

security, email, crypto

normative-requirement §4 MAY

Gateways MAY provide facilities to sign and/or encrypt material passing from the non-MIME side to the MIME side, but such facilities MUST NOT be enabled by default, as the security exposure of transferring unsecured content within the application domain behind the gateway must be assessed first.

security, email, crypto

normative-requirement §4 MUST

Gateways MUST provide the ability to take apart multipart/signed objects, exposing the content and ruining the signature. When this approach is selected, gateways SHOULD NOT remove the signature but SHOULD keep it intact and add a note that it will probably be invalid for checking message contents.

security, email

normative-requirement §4 MUST

Gateways MUST provide the ability to tunnel multipart/signed and multipart/encrypted objects as monolithic entities if there is any chance that MIME capabilities exist on the non-MIME side. No changes to the multipart content are permitted, even when the content is itself a composite MIME object.

security, email

normative-requirement §4 SHOULD

Gateways SHOULD provide the ability to select between tunneling and taking apart multipart/signed objects on a per-user basis.

security, email

security-consideration §3

A signature that covers only object data and not the object's MIME labels would allow someone to tamper with the labels in an undetectable fashion; failure to encrypt MIME label information exposes content metadata that could facilitate traffic analysis.

security, email, privacy

security-consideration §3

An integrity service deployed at something other than a connection end point creates a region where object tampering is possible; a confidentiality service deployed away from an end point creates a region where the object is transferred in the clear, and distributed private keys may enable private key theft.

security, email, crypto