Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)
RFC 3854
Document | Type | RFC - Proposed Standard (July 2004; No errata) | |
---|---|---|---|
Authors | Paul Hoffman , Chistopher Bonatti , Anders Eggen | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3854 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Russ Housley | ||
IESG note | and RFC 3855 | ||
Send notices to | <turners@ieca.com>, <blake@brutesquadlabs.com> |
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 2004 1.3. Definitions For the purposes of this document, the following definitions apply. ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. Certificate: A type that binds an entity's distinguished name to a public key with a digital signature.Show full document text