RFC 3850

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling

📅 published July 2004, from ietf

Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling 🎀

okay bestie, let's get into RFC 3850! 🦋 It was written by B. Ramsdell (the editor) at Sendmail, Inc. and published in July 2004. It's a Standards Track doc in the Network Working Group, and it obsoletes RFC 2632 (the old S/MIME v3 one) 💅 That's the main vibe check: this one replaces the older spec.

Status of this Memo ✨

This doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

Copyright (C) The Internet Society (2004).

Abstract 🌈

So this doc lays down the rules for using X.509 certificates in Secure/Multipurpose Internet Mail Extensions (S/MIME) agents 🧚 S/MIME is how you send and receive secure MIME messages, and certificates are literally a core part of how S/MIME agents do their thing 🔐 The agents validate certificates the way RFC 3280 describes (the Internet X.509 Public Key Infrastructure Certificate and CRL Profile), and they've gotta meet the certificate processing requirements in this doc plus the ones in RFC 3280. No skipping steps! 💅

Table of Contents 🍓

1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
    1.1.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  2
    1.2.  Compatibility with Prior Practice of S/MIME. . . . . . .  3
    1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
    1.4.  Changes Since S/MIME v3 (RFC 2632) . . . . . . . . . . .  3
2.  CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . .  4
    2.1 . CertificateRevocationLists . . . . . . . . . . . . . . .  4
    2.2.  CertificateChoices . . . . . . . . . . . . . . . . . . .  4
    2.3.  CertificateSet . . . . . . . . . . . . . . . . . . . . .  5
3. Using Distinguished Names for Internet Mail . . . . . . . . . .  6
4.  Certificate Processing . . . . . . . . . . . . . . . . . . . .  7
    4.1.  Certificate Revocation Lists . . . . . . . . . . . . . .  8
    4.2.  Certification Path Validation. . . . . . . . . . . . . .  8
    4.3.  Certificate and CRL Signing Algorithms . . . . . . . . .  9
    4.4.  PKIX Certificate Extensions. . . . . . . . . . . . . . .  9
5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 11
A.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
    A.1.  Normative References . . . . . . . . . . . . . . . . . . 13
    A.2.  Informative References . . . . . . . . . . . . . . . . . 14
B.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
C.  Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16

1. Overview 🦋

okay so S/MIME (described in [SMIME-MSG]) is the method for sending and receiving secure MIME messages 📨 Before you use a public key to provide any security services, the S/MIME agent MUST verify that the public key is valid. Non-negotiable! 🙅‍♀️ S/MIME agents MUST use PKIX certificates to validate public keys the way the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM] describes. And they MUST meet the certificate processing requirements in this doc in addition to the ones in [KEYM] 💖

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

1.1. Definitions 📚

For this doc, the following definitions apply. Let's get the vocab down 🧠

ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208 [X.208-88].

Attribute Certificate (AC): An X.509 AC is a separate structure from a subject's public key X.509 Certificate. A subject can 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 [ACAUTH] 🎀

Certificate: A type that binds an entity's 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 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. Lots of details, bestie 🫶

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 this spec intends is the one defined in [KEYM].

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.1 agents should try to have the greatest interoperability possible with agents for prior versions of S/MIME, because nobody wants to be the one who broke the group chat 🫠 S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive, and S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive. RFC 2311 also has historical info about how S/MIME was developed, so it's a fun read if you're into lore 📜

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]. These are the official requirement words, so read them carefully 👀

1.4. Changes Since S/MIME v3 (RFC 2632) 🔄

Here's the tea on what changed since RFC 2632 ☕

  • Version 1 and Version 2 CRLs MUST be supported.
  • Multiple CA certificates with the same subject and public key, but with overlapping validity periods, MUST be supported.
  • Version 2 attribute certificates SHOULD be supported, and version 1 attributes certificates MUST NOT be used.
  • The use of the MD2 digest algorithm for certificate signatures is discouraged, and security language was added. Hard pass on MD2 now 🙅‍♀️
  • Email address use in certificates got clarified. Certificates that do not contain an email address have no requirements for verifying the email address associated with the certificate.
  • Receiving agents SHOULD display certificate information when displaying the results of signature verification.
  • Receiving agents MUST NOT accept a signature made with a certificate that does not have the digitalSignature or nonRepudiation bit set. Strict but fair 🔐
  • There are clarifications for how to interpret the key usage and extended key usage extensions 🧐

2. CMS Options 🎛️

The CMS message format allows for a wide variety of options in content and algorithm support, which is a lot of choices lowkey 😵‍💫 This section puts forth a number of support requirements and recommendations so everyone gets a base level of interoperability across 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. In all cases, both v1 and v2 CRLs MUST be supported. Iykyk, and this is a must-have 💅

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. Save those for later, it's giving resourceful 🧠

2.2. CertificateChoices 🏷️

Receiving agents MUST support v1 X.509 and v3 X.509 identity certificates as profiled in [KEYM]. End entity certificates MAY include an Internet mail address, as described in section 3 📧

Receiving agents SHOULD support X.509 version 2 attribute certificates. See [ACAUTH] for details about the profile for attribute certificates. Main character energy for version 2 🦋

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 [PKCS6], and PKIX Attribute Certificates. So there are options, but not all of them are the move anymore 🙈

The PKCS #6 format is not in widespread use. Plus, PKIX certificate extensions cover much of the same functionality and flexibility that PKCS #6 was meant to give, so sending and receiving agents MUST NOT use PKCS #6 extended certificates. Basically retired, no cap 💀

X.509 version 1 attribute certificates are also not widely implemented, and they've been superseded by version 2 attribute certificates. Sending agents MUST NOT send version 1 attribute certificates. Version 2 is the one that's giving 👑

Part 1 of 4 is done, bestie 🎀 Part 2 is where we keep going, so stay tuned! 🧚

2.3. CertificateSet ✨

Okay bestie, receiving agents MUST be able to handle an arbitrary number of certificates 📜, with any relationship to the message sender and to each other, in any order 🌀. Often the certs in a signed message form a chain from the sender up to some particular root 🌳. Other times the certs are unrelated and just tossed in for convenience 💁‍♀️.

Sending agents SHOULD include any certificates for the user's public key(s) and the associated issuer certificates 🔐. This makes it way more likely the recipient can establish trust in the originator's public key(s). It's especially important when messaging people who might not be able to reach the sender's public key any other way, or when sending a signed message to someone new 🫶. You can skip including certs in outgoing messages if S/MIME objects only move around a group of correspondents who already have each other's certs through some other means, like a shared directory or manual cert distribution. Receiving S/MIME agents SHOULD be able to handle messages without certificates by 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 MUST be able to handle an arbitrarily large number of certificates and chains 🌈.

Agents MAY send CA certificates, meaning certs that can be considered the "root" of other chains, and these MAY be self-signed 🌸. Heads up, though: receiving agents SHOULD NOT simply trust any self-signed certificate as a valid CA 🚫. Instead they SHOULD use some other mechanism to figure out whether it's a CA worth trusting. Also, when certificates contain DSA public keys, the parameters may be located in the root certificate 🧩. That means the recipient needs both the end-entity certificate and the root certificate to do a signature verification. It's a valid example of a case where sending 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 ✨.

Receiving agents SHOULD support decoding X.509 attribute certificates included in CMS objects 💖. Everything else about generating and using X.509 attribute certificates is outside the scope of this specification, so that's a whole different party. One specification that addresses attribute certificate use is [SECLABEL] 🦋.

3. Using Distinguished Names for Internet Mail ✨

End-entity certificates MAY contain an Internet mail address as described in [RFC-2822] 💌. The address must be an "addr-spec" as defined in Section 3.4.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 and accept certificates that contain no email address 💜. Agents are allowed to offer an alternative way to associate an email address with a certificate that doesn't have one, like through the agent's address book, if one is available 📒. Receiving agents MUST recognize email addresses in the subjectAltName field 🔥. Receiving agents MUST also recognize email addresses in the Distinguished Name field, in the PKCS #9 [PKCS9] emailAddress attribute:

   pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }

Note that this attribute MUST be encoded as IA5String 🧾.

Sending agents SHOULD make the address in the From or Sender header of 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, if present, in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit alternate processing if this comparison fails 🚨. That could mean showing the recipient the addresses in the certificate or other certificate details, so they can see what's up 👀.

A receiving agent SHOULD display a subject name or other certificate details when showing an indication of successful or unsuccessful signature verification ✅.

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

4. Certificate Processing ✨

A receiving agent needs some certificate retrieval mechanism to get access to certificates for recipients of digital envelopes 📬. There are lots of ways to build one. X.500 directory service is a great example of a retrieval-only mechanism that's compatible with classic X.500 Distinguished Names 🗂️. Another idea the IETF is looking at is offering certificate retrieval as part of the existing Domain Name System (DNS) 🌐. Until those mechanisms are widely used, their usefulness may be limited by how few of a correspondent's certificates can be retrieved 😭. At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient asking for that recipient's certificate in a signed return message 💌.

Receiving and sending agents SHOULD also provide a mechanism that lets a user "store and protect" certificates for correspondents, so they can be retrieved later 🦋. In lots of environments, it may be desirable to link the retrieval and storage mechanisms together in some sort of certificate database 🌸. In its simplest form, a certificate database would be local to a particular user and work like an "address book" that stores a user's frequent correspondents 📒. That way, the retrieval mechanism is limited to certificates the user has stored (presumably from incoming messages). A comprehensive retrieval/storage solution may combine two or more mechanisms for the greatest flexibility and utility 🧚. For instance, a secure Internet mail agent may check a centralized retrieval mechanism for a certificate if it can't be found in the user's local certificate storage/retrieval database 🔍.

Receiving and sending agents SHOULD provide a mechanism for the import and export of certificates, using a CMS certs-only message 📦. This allows import and export of full certificate chains, instead of just a single certificate. This is described in [SMIME-MSG] 💖.

Agents MUST handle multiple valid Certification Authority (CA) certificates that contain the same subject name and the same public keys but have overlapping validity intervals 🫶.

4.1. Certificate Revocation Lists ✨

In general, it's always better to get the latest CRL information from a CA than to rely on information stored 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 certification paths 🔎. A receiving or sending agent SHOULD also provide a mechanism that lets a user store incoming certificate revocation information for correspondents, so it can be retrieved later 🗃️.

Receiving and sending agents SHOULD retrieve and use CRL information every time a certificate is verified as part of a certification path validation, even if that certificate was already verified in the past 🔁. However, in many instances (like off-line verification), getting the latest CRL information may be difficult or impossible 😩. So how much CRL information gets used may be dictated by the value of the information being protected ⚖️. The value of CRL information in a particular context is beyond the scope of this specification, but may be governed by the policies associated with particular certification paths 📜.

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. Certification Path Validation ✨

When you're building a user agent for secure messaging, certificate, CRL, and certification path validation SHOULD be highly automated, while still acting in the best interests of the user 👑. Certificate, CRL, and path validation MUST be performed as per [KEYM] when validating a correspondent's public key 🫧. This is necessary before using a public key to provide security services such as: verifying a signature; encrypting a content-encryption key (ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a content-encryption key 🔥.

Certificates and CRLs are made available to the path 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, nor are they required to be in any way related 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 path 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 path 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 [CMSALG] 🦋.

A receiving agent MUST be capable of verifying the signatures on certificates and CRLs made with md5WithRSAEncryption and sha1WithRSAEncryption signature algorithms, with key sizes from 512 bits to 2048 bits described in [CMSALG] 🌸.

Because of the security issues surrounding MD2 [RC95], and in light of current use, md2WithRSAEncryption MAY be supported 🧚.

4.4. PKIX Certificate Extensions ✨

okay so PKIX is basically an extensible framework, which means the basic certificate info can get extra add-ons, and those add-ons control how certs get issued and validated 🧚 the PKIX Working Group is always cooking up new extensions for specific certification environments, and people are actively working on PKIX certs for business stuff too 💼 this doc picks out the minimum required set of cert extensions that matter most in the S/MIME environment. The syntax and semantics for every one of them live in [KEYM] 📖

Sending and receiving agents MUST correctly handle the basic constraints, key usage, authority key identifier, subject key identifier, and subject alternative names certificate extensions when they show up in end-entity and CA certificates 🫶 some mechanism SHOULD exist to gracefully handle any other certificate extensions that show up in end-entity or CA certificates. no drama, just be prepared 💖

certs issued for the S/MIME environment SHOULD NOT contain any critical extensions (the ones with the critical field set to TRUE) other than the ones 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 cert. other extensions can be included, but they SHOULD NOT be marked as critical. it's giving "only the essentials, bestie" 💅

interpretation and syntax for all extensions MUST follow [KEYM], unless something here says otherwise. ✨

4.4.1. Basic Constraints Certificate Extension

the basic constraints extension is the one that spells out the role and position an issuing authority or end-entity cert plays in a certification path 🦋

for example, certs issued to CAs and subordinate CAs carry a basic constraints extension that marks them as issuing authority certs 👑 end-entity certs carry an extension that stops them from being issuing authority certs. main character energy for CAs, background energy for everyone else 🫠

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 in a valid cert can be used for 🔐 issuing authority certs may include a key usage extension that restricts the key to signing certificates, certificate revocation lists, and other data. 📜

for example, a certification authority can make subordinate issuer certs whose key usage extension says the public key can be used to sign end user certs and sign CRLs. it's like giving the key a very specific job description 💼

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

S/MIME receiving agents MUST NOT accept the signature of a message if it was verified using a certificate which contains the key usage extension without either the digitalSignature or nonRepudiation bit set. 🙅‍♀️ sometimes S/MIME gets used as a secure message transport for apps beyond interpersonal messaging, and in those cases the S/MIME-enabled application can specify extra requirements about the digitalSignature or nonRepudiation bits in this extension 🧩

If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set. 🫶

4.4.3. Subject Alternative Name Extension

in S/MIME, the subject alternative name extension is the preferred way to carry the RFC-2822 email address(es) that match the entity for this cert 💌 any RFC-2822 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-2822 email addresses MAY be present. it's a whole email party in there 🥳

4.4.4. Extended Key Usage Extension

the extended key usage extension also limits the technical purposes a public key in a valid cert can be used for 🔑 so the set of technical purposes for the cert is the intersection of the uses listed in the key usage and extended key usage extensions. think of it as a VIP list where only the overlap gets in 👑

for example, if the cert has a key usage extension indicating digital signature and an extended key usage extension that includes the email protection OID, then the cert can be used for signing but not encrypting S/MIME messages ✍️ if the cert has a key usage extension indicating digital signature but no extended key usage extension, then the cert can also be used to sign but not encrypt S/MIME messages. same vibe, different setup 🌈

If the extended key usage extension is present in the certificate, then interpersonal message S/MIME receiving agents MUST check that it contains either the emailProtection or the anyExtendedKeyUsage OID as defined in [KEYM]. 🔍 S/MIME uses other than interpersonal messaging MAY require the explicit presence of the extended key usage extension, or other OIDs to be present in the extension, or both. 🧚

5. Security Considerations 🚨

all of the security issues any cryptographic app has to face, an S/MIME agent has to face too 😭 that includes 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 full list is way beyond this doc, but here are some big concerns 💀

when processing certificates, there are lots of situations where things might fail. since the processing could be done by a user agent, a security gateway, or some other program, there isn't one single way to handle every failure 🫠 but just because the handling isn't listed here doesn't mean those failures don't matter. the opposite is true! if a cert isn't provably valid and associated with the message, the processing software should take immediate and noticeable steps to tell 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, if the certificate contains at least one mail address 📧
  • 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 definitely other ways a cert can be invalid, and it's the processing software's job to check them all thoroughly and decide what to do if a check fails 🧹

at the Selected Areas in Cryptography '95 conference in May 1995, Rogier and Chauvaud presented an attack on MD2 that can nearly find collisions [RC95] 😳 a collision is when you can find two different messages that generate the same message digest. a checksum operation in MD2 is the only thing left standing in the way of the attack succeeding. because of this, using MD2 for new applications is discouraged 🙅‍♀️ it's still reasonable to use MD2 to verify existing signatures, though, since being able to find collisions in MD2 doesn't let an attacker find new messages that have a previously computed hash value. the existing stuff is fine, just don't start new things with it 🫶

it's possible for there to be multiple unexpired CRLs for a CA. if an agent is checking CRLs for certificate validation, it SHOULD make sure the most recently issued CRL for that CA is the one being consulted 🕵️‍♀️ this matters because an S/MIME message sender could deliberately include an older unexpired CRL in an S/MIME message. that older CRL might not include recently revoked certs, which could lead an agent to accept a cert that's been revoked in a later CRL. not a vibe 💀

when determining the time for a certificate validity check, agents have to be really careful to use a reliable time. unless it comes from a trusted agent, this time MUST NOT be the SigningTime attribute found in an S/MIME message ⏳ for most sending agents, the SigningTime attribute could be deliberately set to point the receiving agent at a CRL with out-of-date revocation status for a cert, or to cause an improper result when checking the Validity field of a certificate. time is a weapon, and attackers know it 🧨

A. References 📚

A.1. Normative References

  • [ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
  • [CMS] Housely, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
  • [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
  • [KEYM] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
  • [KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
  • [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
  • [RFC-2822], Resnick, P., "Internet Message Format", RFC 2822, April 2001.
  • [SMIME-MSG] Ramsdell, B., Ed., "S/MIME Version 3.1 Message Specification", RFC 3851, July 2004.
  • [x.208-88] ITU-T. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.

A.2. Informative References

  • [CERTV2] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, "S/MIME Version 2 Certificate Handling", RFC 2312, March 1998.
  • [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax Standard", November 1993.
  • [RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 is not collision free," Presented at Selected Areas in Cryptography '95, May 1995.
  • [SECLABEL] Nicolls, W., "Implementing Company Classification Policy with the S/MIME Security Label", RFC 3114, May 2002.
  • [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 ✨

Okay bestie, huge thank yous to the other authors of the S/MIME v2 RFC: Steve Dusse, Paul Hoffman and Jeff Weinstein 🫶. Without v2, there wouldn't be a v3 💖.

A bunch of the S/MIME Working Group folks also worked SO hard on this doc and contributed. Any list of people is doomed to leave someone out, so I'm sorry in advance 🥺. In alphabetical order, these people stand out to me because they made direct contributions to this document:

  • Bill Flanigan
  • Trevor Freeman
  • Elliott Ginsburg
  • Paul Hoffman
  • Russ Housley
  • David P. Kemp
  • Michael Myers
  • John Pawling
  • Denis Pinkas
  • Jim Schaad

C. Editor's Address 🎀

The editor is Blake Ramsdell, and here's where to reach him 📬:

Blake Ramsdell
Sendmail, Inc.
704 228th Ave NE #775
Sammamish, WA  98074

EMail: blake@sendmail.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

The disclaimer is legal text, so I'm keeping it word for word 💅:

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🦋

The IETF doesn't take a side on whether any Intellectual Property Rights (the patents, copyrights and other stuff people can claim over this tech) are valid or how far they reach, and it can't say whether you'd be able to get a license to use them 🙈. It also hasn't done any independent digging to find out what rights exist. If you want the rules for rights in RFC documents, check out BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, are kept in the IETF's online IPR repository at http://www.ietf.org/ipr. You can also find the results of anyone trying to get a general license or permission to use these rights so implementers or users can work with this spec 👀.

The IETF invites anyone to let it know about any copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 🌈

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

📦 where this page comes from