S/MIME Version 3 Certificate Handling
RFC 2632

Document Type RFC - Proposed Standard (June 1999; No errata)
Obsoleted by RFC 3850
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2632 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                               B. Ramsdell, Editor
Request for Comments: 2632                                    Worldtalk
Category: Standards Track                                     June 1999

                 S/MIME Version 3 Certificate Handling

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. Overview

   S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
   [SMIME-MSG], provides a method to send and receive secure MIME
   messages. Before using a public key to provide security services, the
   S/MIME agent MUST certify that the public key is valid. S/MIME agents
   MUST use PKIX certificates to validate public keys as described in
   the Internet X.509 Public Key Infrastructure (PKIX) Certificate and
   CRL Profile [KEYM]. S/MIME agents MUST meet the certificate
   processing requirements documented in this document in addition to
   those stated in [KEYM].

   This specification is compatible with the Cryptographic Message
   Syntax [CMS] in that it uses the data types defined by CMS. It also
   inherits all the varieties of architectures for certificate-based key
   management supported by CMS.

1.1 Definitions

   For the purposes of this memo, the following definitions apply.

   ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689.

   Attribute Certificate (AC): An X.509 AC is a separate structure from
   a subject's public key X.509 Certificate.  A subject may have
   multiple X.509 ACs associated with each of its public key X.509
   Certificates.  Each X.509 AC binds one or more Attributes with one of
   the subject's public key X.509 Certificates.  The X.509 AC syntax is
   defined in [X.509]

Ramsdell                    Standards Track                     [Page 1]
RFC 2632         S/MIME Version 3 Certificate Handling         June 1999

   BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690.

   Certificate: A type that binds an entity's distinguished name to a
   public key with a digital signature. This type is defined in the
   Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
   Profile [KEYM]. This type also contains the distinguished name of the
   certificate issuer (the signer), an issuer-specific serial number,
   the issuer's signature algorithm identifier, a validity period, and
   extensions also defined in that document.

   Certificate Revocation List (CRL): A type that contains information
   about certificates whose validity an issuer has prematurely revoked.
   The information consists of an issuer name, the time of issue, the
   next scheduled time of issue, a list of certificate serial numbers
   and their associated revocation times, and extensions as defined in
   [KEYM]. The CRL is signed by the issuer. The type intended by this
   specification is the one defined in [KEYM].

   DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
   X.690.

   Receiving agent: software that interprets and processes S/MIME CMS
   objects, MIME body parts that contain CMS objects, or both.

   Sending agent: software that creates S/MIME CMS objects, MIME body
   parts that contain CMS objects, or both.

   S/MIME agent: user software that is a receiving agent, a sending
   agent, or both.

1.2 Compatibility with Prior Practice of S/MIME

   S/MIME version 3 agents should attempt to have the greatest
   interoperability possible with S/MIME version 2 agents. S/MIME
   version 2 is described in RFC 2311 through RFC 2315, inclusive.  RFC
   2311 also has historical information about the development of S/MIME.

1.3 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].

Ramsdell                    Standards Track                     [Page 2]
RFC 2632         S/MIME Version 3 Certificate Handling         June 1999

2. CMS Options

   The CMS message format allows for a wide variety of options in
   content and algorithm support. This section puts forth a number of
   support requirements and recommendations in order to achieve a base
   level of interoperability among all S/MIME implementations. Most of
   the CMS format for S/MIME messages is defined in [SMIME-MSG].

2.1 CertificateRevocationLists

   Receiving agents MUST support the Certificate Revocation List (CRL)
   format defined in [KEYM]. If sending agents include CRLs in outgoing
   messages, the CRL format defined in [KEYM] MUST be used.

   All agents MUST be capable of performing revocation checks using CRLs
Show full document text