S/MIME Version 3 Message Specification
RFC 2633
Document | Type |
RFC - Proposed Standard
(June 1999; Errata)
Obsoleted by RFC 3851
Was draft-ietf-smime-msg (smime WG)
|
|
---|---|---|---|
Author | Blake Ramsdell | ||
Last updated | 2020-01-21 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2633 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group B. Ramsdell, Editor Request for Comments: 2633 Worldtalk Category: Standards Track June 1999 S/MIME Version 3 Message Specification 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 (1999). All Rights Reserved. 1. Introduction S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. 1.1 Specification Overview This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content type of Internet messages and allows extensions for new content type applications. Ramsdell Standards Track [Page 1] RFC 2633 S/MIME Version 3 Message Specification June 1999 This memo defines how to create a MIME body part that has been cryptographically enhanced according to CMS [CMS], which is derived from PKCS #7 [PKCS-7]. This memo also defines the application/pkcs7- mime MIME type that can be used to transport those body parts. This memo also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. This memo also defines the application/pkcs7-signature MIME type, which is also used to transport S/MIME signed messages. In order to create S/MIME messages, an S/MIME agent has to follow specifications in this memo, as well as the specifications listed in the Cryptographic Message Syntax [CMS]. Throughout this memo, 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. The separation for requirements on receiving agents and sending agents also derives from the likelihood 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 an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [MUSTSHOULD]. 1.3 Definitions For the purposes of this memo, the following 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. Ramsdell Standards Track [Page 2] RFC 2633 S/MIME Version 3 Message Specification June 1999 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, whereShow full document text