Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
Securing X.400 Content with Secure/Multipurpose Internet Mail
Extensions (S/MIME)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a protocol for adding cryptographic signature
and encryption services to X.400 content with Secure/Multipurpose
Internet Mail Extensions (S/MIME).
1. Introduction
The techniques described in the Cryptographic Message Syntax [CMS]
specification are general enough to support many different content
types. The [CMS] specification thus provides many options for
providing different security mechanisms. In order to ensure
interoperability of systems within the X.400 community, it is
necessary to specify the use of CMS features to protect X.400 content
(called "CMS-X.400" in this document).
1.1. Specification Overview
This document is intended to be similar to the S/MIME Version 3.1
Message Specification [MSG] except that it is tailored to the
requirements of X.400 content rather than Multipurpose Internet Mail
Extensions (MIME).
Hoffman, et al. Standards Track [Page 1]RFC 3854 Securing X.400 with S/MIME July 2004
This document defines how to create an X.400 content type that has
been cryptographically enhanced according to [CMS]. In order to
create S/MIME messages carrying X.400 content, an S/MIME agent has to
follow specifications in this document, as well as the specifications
listed in [CMS]. This memo also defines new parameter values for the
application/pkcs7-mime MIME type that can be used to transport those
body parts.
Throughout this document, there are requirements and recommendations
made for how receiving agents handle incoming messages. There are
separate requirements and recommendations 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
of the requirements are placed on the handling of incoming messages
while the recommendations are mostly on the creation of outgoing
messages.
This document does not address transport of CMS-X.400 content. It is
assumed that CMS-X.400 content would be transported by Internet mail
systems, X.400, or other suitable transport.
This document describes applying security services to the content of
entire X.400 messages, which may or may not be IPMS messages. These
objects can be carried by several means, including SMTP-based mail
and X.400 mail. Note that cooperating S/MIME agents must support
common forms of message content in order to achieve interoperability.
If the CMS objects are sent as parts of an RFC 822 message, a
standard MIXER gateway [MIXER] will most likely choose to encapsulate
the message. This is not likely to be a format that is usable by an
X.400 recipient. MIXER is specifically focused on translation
between X.420 Interpersonal Messages and non-secure RFC822/MIME
messages. The discussion of security-related body parts in sections
7.3 and 7.4 of [BODYMAP] is relevant to CMS messages.
Definition of gateway services to support relay of CMS object between
X.400 and SMTP environments is beyond the scope of this document.
1.2. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in BCP
14, RFC 2119 [MUSTSHOULD].
Hoffman, et al. Standards Track [Page 2]RFC 3854 Securing X.400 with S/MIME July 20041.3. Definitions
For the purposes of this document, the following definitions apply.
datatracker.ietf.org