RFC 2312 (rfc2312) - Page 2 of 20
S/MIME Version 2 Certificate Handling
Alternative Format: Original Text Document
RFC 2312 S/MIME Version 2 Certificate Handling March 1998
Please note: The information in this document is historical material
being published for the public record. It is not an IETF standard.
The use of the word "standard" in this document indicates a standard
for adopters of S/MIME version 2, not an IETF standard.
1.1 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. This type is defined in CCITT
X.509 [X.509]. This type also contains the distinguished name of the
certificate issuer (the signer), an issuer-specific serial number,
the issuer's signature algorithm identifier, and a validity period.
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, and a list of certificate serial
numbers and their associated revocation times. 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 CCITT
X.509.
1.2 Compatibility with Prior Practice of S/MIME
Appendix C contains important information about how S/MIME agents
following this specification should act in order to have the greatest
interoperability with earlier implementations of S/MIME.
1.3 Terminology
Throughout this memo, the terms MUST, MUST NOT, SHOULD, and SHOULD
NOT are used in capital letters. This conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to
help make the intent of standards track documents as clear as
possible. The same key words are used in this document to help
implementors achieve interoperability.
Dusse, et. al. Informational