RFC 2632

S/MIME Version 3 Certificate Handling

📅 published June 1999, from ietf

RFC 2632: S/MIME Version 3 Certificate Handling 🎀

okay bestie, this one is S/MIME version 3 certificate handling ✨ It's from the Network Working Group, published as Request for Comments 2632 in June 1999. It's a Standards Track document, so it's a real Internet protocol spec 💅 B. Ramsdell is the editor, and they're at Worldtalk. The header doesn't list any Obsoletes or Updates entries, so this doc isn't replacing or changing anything else 🫶

Status of this Memo 🌸

So this is an Internet standards track protocol for the whole Internet community, and they're literally asking everyone to discuss it and suggest improvements 🗣️ For the current standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. 🫶

1. Overview ✨

S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], is what lets you send and receive secure MIME messages 💌 Before you use a public key for any security stuff, the S/MIME agent MUST certify that the 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]. On top of what's in [KEYM], S/MIME agents MUST meet the certificate processing requirements written in this document 💅

This spec is compatible with the Cryptographic Message Syntax [CMS] because it uses the data types CMS defines. It also inherits all the varieties of architectures for certificate-based key management that CMS supports 🦋

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): okay so an X.509 AC is its own structure, separate from a subject's public key X.509 Certificate 🪪 A subject can have multiple X.509 ACs tied to each of its public key X.509 Certificates. Each X.509 AC binds one or more Attributes to one of the subject's public key X.509 Certificates. The X.509 AC syntax is defined in [X.509]
  • 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]. It also holds 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 lists 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 🗝️

Okay, so when this doc uses the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", they're meant exactly the way [MUSTSHOULD] describes them. No vibes-based interpretation allowed 🙈

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 so that all S/MIME implementations get a base level of interoperability 🫶 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 as specified in [KEYM]. All agents MUST perform revocation status checking in accordance with [KEYM]. Receiving agents MUST recognize CRLs in received S/MIME messages 👀

Agents SHOULD store CRLs received in messages for use in processing later messages 💾

Agents MUST handle multiple valid Certificate Authority (CA) certificates containing the same subject name and the same public keys but with overlapping validity intervals 🌀

2.2 CertificateChoices 📜

Receiving agents MUST support PKIX v1 and PKIX v3 certificates. See [KEYM] for details about the profile for certificate formats. End entity certificates MAY include an Internet mail address, as described in section 3.1 💌

Receiving agents SHOULD support X.509 attribute certificates 🪪

2.2.1 Historical Note About CMS Certificates 🏛️

The CMS message format supports a choice of certificate formats for public key content types: PKIX, PKCS #6 Extended Certificates and X.509 Attribute Certificates. The PKCS #6 format is not in widespread use. PKIX certificate extensions also cover much of the same functionality and flexibility that PKCS #6 was meant to give, so it's kind of redundant now 🙄 Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates. ❌

2.3 CertificateSet 📦

Receiving agents MUST be able to handle an arbitrary number of certificates, with arbitrary relationships to the message sender and to each other, in arbitrary order 🌪️ A lot of the time, the certificates in a signed message form a chain of certification from the sender to some particular root. But sometimes the certificates in a signed message are unrelated and only included for convenience.

Sending agents SHOULD include any certificates for the user's public key(s) and associated issuer certificates. This makes it more likely that the intended recipient can establish trust in the originator's public key(s) 🫶 It's especially important when sending to recipients who may not have access to the sender's public key any other way, or when sending a signed message to a new recipient. Certificates can be left out of outgoing messages if S/MIME objects are going around a group of correspondents who already have access to each other's certificates by some other means, like a shared directory or manual certificate distribution. Receiving S/MIME agents SHOULD be able to handle messages without certificates using a database or directory lookup scheme 🔍

A sending agent SHOULD include at least one chain of certificates up to, but not including, a Certificate Authority (CA) that it believes the recipient may trust as authoritative. A receiving agent SHOULD be able to handle an arbitrarily large number of certificates and chains 🧶

Agents MAY send CA certificates, meaning certificates that are self-signed and can be considered the "root" of other chains 👑 Note that receiving agents SHOULD NOT simply trust any self-signed certificates as valid CAs, but SHOULD use some other mechanism to determine if this is a CA that should be trusted. Also note that for DSA certificates the parameters may be located in the root certificate. That means the recipient needs the root certificate to do a signature verification, so it's a valid example of a case where transmitting the root certificate may be required ✨

Receiving agents MUST support chaining based on the distinguished name fields. Other methods of building certificate chains may be supported but are not currently recommended 🙅‍♀️

Receiving agents SHOULD support the decoding of X.509 attribute certificates included in CMS objects. All other issues about generating and using X.509 attribute certificates are outside the scope of this specification 🚪

3. Using Distinguished Names for Internet Mail 📬

End-entity certificates MAY contain an Internet mail address as described in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 of that specification. The email address SHOULD be in the subjectAltName extension, and SHOULD NOT be in the subject distinguished name 💅

Receiving agents MUST recognize email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 emailAddress attribute 👀

Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate 💌 Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing of the message if this comparison fails. That could be showing the recipient the addresses in the certificate or other certificate details 🚨

All subject and issuer names MUST be populated (i.e. not an empty SEQUENCE) in S/MIME-compliant PKIX certificates. The exception is that the subject DN in a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE, in which case the subjectAltName extension will include the subject's identifier and MUST be marked as critical 🎀

4. Certificate Processing ✨

okay bestie, so a receiving agent needs some way to actually get the certificates of people who sent it digital envelopes 📬. There are a bunch of ways to build a certificate retrieval mechanism 💅. X.500 directory service is literally the iconic example of a retrieval-only mechanism that works with classic X.500 Distinguished Names 🎀. The PKIX Working Group is also looking into other stuff, like directory servers 🔍. Another idea the IETF is considering is adding certificate retrieval to the existing Domain Name System (DNS) 🌐. Until these mechanisms are widely used, though, their usefulness is kinda limited by how few of your correspondents' certificates can actually be retrieved 🥺. At the very least, for initial S/MIME deployment, a user agent could automatically send a message to the intended recipient asking for their certificate in a signed return message 💌. That's the bare minimum, babe.

Receiving and sending agents SHOULD also provide a way for a user to "store and protect" certificates for correspondents, so they can be retrieved later on 🔐. In lots of environments, it makes sense to link the retrieval and storage mechanisms together in some kind of certificate database 🗂️. In its simplest form, a certificate database lives locally with one user and works like an "address book" for their frequent correspondents 📒. That means the retrieval mechanism is limited to the certificates the user has stored, which presumably came from incoming messages 📥. A full certificate retrieval/storage solution can combine two or more mechanisms to give the user the most flexibility and utility 💯. For example, a secure Internet mail agent might check a centralized certificate retrieval mechanism for a certificate if it can not be found in the user's local certificate storage/retrieval database 🕵️‍♀️.

Receiving and sending agents SHOULD provide a mechanism for importing and exporting certificates using a CMS certs-only message 📦. This lets you import and export full certificate chains instead of just a single certificate, which is so much more complete 🧩. It's described in [SMIME-MSG].

4.1 Certificate Revocation Lists

In general, it is always better to get the latest CRL information from a CA than to rely on information stored away from incoming messages 🙅‍♀️. A receiving agent SHOULD have access to some certificate-revocation list (CRL) retrieval mechanism, so it can get certificate-revocation information when validating certificate chains 🔎. A receiving or sending agent SHOULD also provide a way for a user to store incoming certificate-revocation information for correspondents, guaranteeing it can be retrieved later 💾.

Receiving and sending agents SHOULD retrieve and use CRL information every single time a certificate is verified as part of a certificate chain validation, even if that certificate was already verified in the past 🔁. However, in lots of situations (like off-line verification) getting the latest CRL information might be hard or totally impossible 📵. So how much CRL information gets used may depend on how valuable the protected information is 💎. The value of CRL information in a particular context is beyond the scope of this memo, but it may be governed by the policies attached to particular certificate hierarchies 📜.

All agents MUST be capable of performing revocation checks using CRLs as specified in [KEYM] 🛡️. All agents MUST perform revocation status checking in accordance with [KEYM] 💅. Receiving agents MUST recognize CRLs in received S/MIME messages ✅.

4.2 Certificate Chain Validation

When making a user agent for secure messaging, certificate, CRL, and certificate chain validation SHOULD be highly automated while still acting in the user's best interests 🤖💖. Certificate, CRL, and chain validation MUST be performed as per [KEYM] when validating a correspondent's public key 🔑. This is necessary before using a public key for security services like: verifying a signature ✍️; encrypting a content-encryption key (ex: RSA) 🔐; or forming a pairwise symmetric key (ex: Diffie-Hellman) that's used to encrypt or decrypt a content-encryption key 🧁.

Certificates and CRLs get made available to the chain validation procedure in two ways: a) incoming messages, and b) certificate and CRL retrieval mechanisms 📨. Certificates and CRLs in incoming messages are not required to be in any particular order, and they are not required to be related in any way to the sender or recipient of the message (although in most cases they will be related to the sender) 🌀. Incoming certificates and CRLs SHOULD be cached for use in chain validation, and optionally stored for later use 🗃️. This temporary certificate and CRL cache SHOULD be used to augment any other certificate and CRL retrieval mechanisms for chain validation on incoming signed messages 🧠.

4.3 Certificate and CRL Signing Algorithms

Certificates and Certificate-Revocation Lists (CRLs) are signed by the certificate issuer ✍️. A receiving agent MUST be capable of verifying the signatures on certificates and CRLs made with id-dsa-with-sha1 [DSS] 🧾.

A receiving agent SHOULD be capable of verifying the signatures on certificates and CRLs made with md2WithRSAEncryption, md5WithRSAEncryption, and sha-1WithRSAEncryption signature algorithms, with key sizes from 512 bits to 2048 bits, as described in [PKCS#1V2] 🔏.

4.4 PKIX Certificate Extensions

PKIX describes an extensible framework where the basic certificate information can be extended, and it explains how those extensions can be used to control the process of issuing and validating certificates 🧩. The PKIX Working Group is ongoing with efforts to identify and create extensions that have value in particular certification environments 🌱. There are also active efforts underway to issue PKIX certificates for business purposes 💼. This document identifies the minimum required set of certificate extensions that have the greatest value in the S/MIME environment 🎯. The syntax and semantics of all the identified extensions are defined in [KEYM] 📖.

Sending and receiving agents MUST correctly handle the Basic Constraints Certificate Extension, the Key Usage Certificate Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when they appear in end-user certificates 👑. Some mechanism SHOULD exist to handle the defined certificate extensions when they appear in intermediate or CA certificates 🪜.

Certificates issued for the S/MIME environment SHOULD NOT contain any critical extensions (extensions that have the critical field set to TRUE) other than those listed here 🚫. These extensions SHOULD be marked as non-critical, unless proper handling of the extension is deemed critical to the correct interpretation of the associated certificate 🙈. Other extensions may be included, but those extensions SHOULD NOT be marked as critical 🌸.

Interpretation and syntax for all extensions MUST follow [KEYM], unless otherwise specified here 📘.

4.4.1 Basic Constraints Certificate Extension

The basic constraints extension is what delimits the role and position of an issuing authority or end-entity certificate in a chain of certificates 🧭.

For example, certificates issued to CAs and subordinate CAs contain a basic constraint extension that identifies them as issuing authority certificates 🏛️. End-entity certificates contain an extension that stops the certificate from being an issuing authority certificate 🙅‍♀️.

Certificates SHOULD contain a basicConstraints extension in CA certificates, and SHOULD NOT contain that extension in end entity certificates 💖.

4.4.2 Key Usage Certificate Extension

The key usage extension limits the technical purposes a public key listed in a valid certificate may be used for 🗝️. Issuing authority certificates may contain a key usage extension that restricts the key to signing certificates, certificate revocation lists, and other data 📝.

For example, a certification authority may create subordinate issuer certificates that contain a keyUsage extension specifying that the corresponding public key can be used to sign end user certs and sign CRLs ✍️.

If a key usage extension is included in a PKIX certificate, then it MUST be marked as critical ⚠️.

4.4.2.1 Key Usage in Diffie-Hellman Key Exchange Certificates

For Diffie-Hellman key exchange certificates (certificates where the subject public key algorithm is dhpublicnumber), if the keyUsage keyAgreement bit is set to 1 AND the public key is going to be used to form a pairwise key to decrypt data, then the S/MIME agent MUST only use the public key if the keyUsage encipherOnly bit is set to 0 🧁. If the keyUsage keyAgreement bit is set to 1 AND the key is going to be used to form a pairwise key to encrypt data, then the S/MIME agent MUST only use the public key if the keyUsage decipherOnly bit is set to 0 🎀.

4.4.3 Subject Alternative Name Extension

The subject alternative name extension is used in S/MIME as the preferred way to convey the RFC-822 email address(es) that correspond to the entity for this certificate 📧. Any RFC-822 email addresses present MUST be encoded using the rfc822Name CHOICE of the GeneralName type 🔤. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple RFC-822 email addresses MAY be present 💅.

5. Security Considerations 🔐

All of the security issues faced by any cryptographic application must be faced by an S/MIME agent 😬. Among these issues are protecting the user's private key, preventing various attacks, and helping the user avoid mistakes like accidentally encrypting a message for the wrong recipient 🙀. The entire list of security considerations is beyond the scope of this document, but some significant concerns are listed here 📋.

When processing certificates, there are lots of situations where the processing might fail 💀. Because the processing may be done by a user agent, a security gateway, or some other program, there is no single way to handle these failures 🫠. Just because the methods to handle the failures aren't listed here, the reader should not assume they aren't important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it 🚨.

Some of the many places where signature and certificate checking might fail include:

  • no Internet mail addresses in a certificate match the sender of a message
  • no certificate chain leads to a trusted CA
  • no ability to check the CRL for a certificate
  • an invalid CRL was received
  • the CRL being checked is expired
  • the certificate is expired
  • the certificate has been revoked

There are certainly other instances where a certificate may be invalid, and it is the responsibility of the processing software to check them all thoroughly and to decide what to do if a check fails 🧐💜.

A. References 📚

  • [CERTV2] Dusse, S., Hoffman, P. and B. Ramsdell, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998. 💌
  • [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 🔐
  • [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. ✍️
  • [KEYM] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. 📜
  • [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🗝️
  • [PKCS#1V2] Kaliski, B., "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998. 🧮
  • [RFC-822] Crocker, D., "Standard For The Format Of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 📨
  • [SMIME-MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999. 💖
  • [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services. 🗂️
  • [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, Information technology - Open Systems Interconnection - The Directory: Models. 🧩
  • [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, Information technology - Open Systems Interconnection - The Directory: Authentication framework. 🛡️
  • [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, Information technology - Open Systems Interconnection - The Directory: Selected attribute types. 🏷️

B. Acknowledgements 🫶

Huge thank-you to the other authors of the S/MIME v2 RFC: Steve Dusse, Paul Hoffman and Jeff Weinstein. Honestly, without v2 there would be no v3, so they're iconic. 👑

A bunch of people in the S/MIME Working Group also worked super hard on this document. Any list of people is going to miss someone, and the author apologizes in advance for that. 🙏 These folks stand out because they made direct contributions to the document, and they're listed alphabetically:

  • Bill Flanigan
  • Elliott Ginsburg
  • Paul Hoffman
  • Russ Housley
  • Michael Myers
  • John Pawling
  • Denis Pinkas
  • Jim Schaad

Editor's Address 📬

Blake Ramsdell Worldtalk 17720 NE 65th St Ste 201 Redmond, WA 98052

Phone: +1 425 376 0225 EMail: blaker@deming.com

Copyright (C) The Internet Society (1999). All Rights Reserved. 🌸

You're allowed to copy this document and hand it out to others. You can also write derivative works that comment on or explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work. 🦋

The document itself can't be modified in any way. That includes removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions: you can change it when needed to develop Internet standards, but then the copyright procedures defined in the Internet Standards process must be followed, and you can change it to translate it into a language other than English. 🌈

The permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. ♾️

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🧚

📦 where this page comes from