RFC 3855

Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400

📅 published July 2004, from ietf

RFC 3855 🎀📬

okay bestie, let's get into RFC 3855 💅 It's called Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400, and here's the title-block tea ✨

  • Network Working Group: the stream this was published in
  • Request for Comments: 3855
  • Authors: P. Hoffman (IMC) and C. Bonatti (IECA)
  • Category: Standards Track
  • Date: July 2004
  • Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🦋

Status of This Memo 📜

okay so this one is an Internet standards track protocol for the whole Internet community 🌈 It also asks everyone to discuss it and send ideas for making it better 💖 If you want the official standardization state and status of this protocol, you check the current edition of the "Internet Official Protocol Standards" (STD 1) 👑 And the memo can be distributed with no restrictions at all, so share away 🫶

Copyright (C) The Internet Society (2004). Legal stuff, but it's giving "we own this little piece of paper" 🌸

Abstract ✨

this doc describes protocol options for carrying objects that have been protected with the Cryptographic Message Syntax (CMS) and Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1, sent over an X.400 message transfer system 🧚

1. Introduction 🌷

so the techniques in the Cryptographic Message Syntax [CMS] spec and the message specs can totally be carried over lots of different email systems 💌 This spec is where we pin down the options and values you need so S/MIME messages can move around X.400 systems interoperably. Main character energy 👑

This doc describes a mechanism for using CMS objects as the message content of X.400 messages in a native X.400 environment. Real talk: gateways or other functions that expect to deal with IPMS, like the ones in [MIXER] and [BODYMAP], can't do anything with these messages 🙈 Also, cooperating S/MIME agents must support common forms of message content in order to achieve interoperability, so everyone has to be on the same page 🫶

Defining gateway services that relay CMS objects between X.400 and SMTP environments is out of scope for this doc. Not today, bestie 🍓

1.1. Terminology 💜

The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [MUSTSHOULD].

1.2. Definitions 📖

For the purposes of this document, the following definitions apply, iykyk ✨

  • ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
  • Object Identifier (OID): A globally unique identifier value made of a sequence of integer values, assigned through distributed registration as specified by ISO/IEC 8824. 🔥
  • Transfer Encoding: A reversible transformation made on data so 8-bit or binary data can be sent over a channel that only transmits 7-bit data 🦋

1.3. Compatibility with Existing S/MIME Implementations 🫧

It is a goal of this document to, if possible, maintain backward compatibility with existing X.400 implementations that use S/MIME v3.1 wrappers. Respect for the old systems, periodt 💅

2. S/MIME Packaging 🎀

2.1. The X.400 Message Structure 🧩

okay so this section is a quick refresher on the X.400 message format 📬 An X.400 message has two parts, the envelope and the content, as described in X.402 [X.400]:

  • Envelope -- An information object whose composition changes from one transmittal step to another. It identifies the message's originator and potential recipients, documents its previous conveyance, directs its later conveyance by the Message Transfer System (MTS), and characterizes its content. 💌
  • Content -- The piece of information that the originating User Agent wants delivered to one or more recipients. The MTS doesn't examine or modify the content, except for conversion while the message is being conveyed. MTS conversion doesn't apply to the scenario in this document, because that kind of conversion clashes with CMS protection mechanisms 🔒

One piece of information in the envelope identifies the type of the content. The content type is an identifier (an ASN.1 OID or Integer) that denotes the syntax and semantics of the content as a whole. This is the thing that lets the MTS figure out whether a message can be delivered to particular users, and lets User Agents and Message Stores interpret and process the content ✨

Some X.400 content types go further and structure the content as a set of heading elements and body parts. The Interpersonal Messaging System (IPMS) is one example. IPMS content can carry zero or more arbitrary body parts, each identified by its body part type. The body part type is an ASN.1 OID or Integer that denotes the syntax and semantics of that body part 🧚

2.2. Carrying S/MIME as X.400 Content 💖

When you transport a CMS-protected message in X.400, the preferred approach (except as discussed in section 2.3 below) is to convey the object as X.400 message content 💅 This section explains how S/MIME CMS objects get conveyed as the content part of X.400 messages. This mechanism works for transporting CMS-protected messages no matter what mail content got encapsulated inside 🌈

Implementations MUST include the CMS object in the content field of the X.400 message. Non-negotiable, bestie 🙈

If the CMS object is covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs7(7) 1 }

If the CMS object is not covered by an outer MIME wrapper, the content-type field of the P1 envelope MUST be set to the following CMS-defined value:

id-ct-contentInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2)
      us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
      content-types(1) 6}

2.2.1. Carrying Plaintext MIME objects as X.400 Content 🌸

When you transport a plaintext MIME object in X.400, the preferred approach is to convey the object as X.400 message content 🎀 The content-type field of the P1 envelope MUST be set to the following CMS-defined value:

id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs7(7) 1 }

2.3. Carrying S/MIME as IPMS Body Parts 🦋

Under some circumstances, S/MIME CMS-protected messages can be conveyed inside select body parts of the content. Implementations generally SHOULD NOT embed CMS objects within X.400 body parts 🙅‍♀️ They should convey them as content, like in section 2.2, instead. The one notable exception is forwarding, which is literally the only time it's needed 🔥

In instances where CMS objects get forwarded as part of a message forwarding function, you need a body part. When forwarding a CMS object in an IPMS or IPMS-compatible body part, implementations MUST use the content-body-part as formally defined by [X.400], shown below for reference:

content-body-part {ExtendedContentType:content-type}
    EXTENDED-BODY-PART-TYPE ::= {
        PARAMETERS {ForwardedContentParameters IDENTIFIED BY
            {id-ep-content -- concatenated with content-type -- }},
        DATA {Content IDENTIFIED BY
            {id-et-content -- concatenated with content-type -- }} }

ForwardedContentParameters ::= SET {
    delivery-time     [0] MessageDeliveryTime OPTIONAL,
    delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
    mts-identifier    [2] MessageDeliveryIdentifier OPTIONAL }

id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}

id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}

The implementation MUST copy the CMS object to be forwarded into the Content field of the content-body-part. The direct-reference field of the body part MUST include the OID formed by concatenating the id-et-content value with the following CMS-defined value:

id-ct-contentInfo  OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) content-types(1) 6}

For example, to forward any CMS object, the DATA component of the body part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 } 🧚

The ForwardedContentParameters are optional and MAY be supported at the discretion of the implementor. The OID value id-et-content MAY also be included in the original-encoded-information-types field of the X.400 message envelope, at the discretion of the sending S/MIME agent ✨

In this instance, the content-type field of the P1 envelope MUST be set to the value associated with the forwarding content (e.g., integer 22 for IPMS). Main character energy 👑

2.4. Transfer Encoding 🫧

Per the various S/MIME specs for message wrapping, CMS objects MAY optionally be wrapped in MIME to dynamically support 7-bit transport. This outer wrapping is not required for X.400 transport, and it generally SHOULD NOT be applied in a homogeneous X.400 environment 🌈 Heterogeneous mail systems or other factors MAY require the presence of this outer MIME wrapper

2.5. Encoded Information Type Indication ✨

okay so in [MSG], the application/pkcs7-mime content type plus the optional "smime-type" parameter tell you what security got applied (signed or enveloped) and what's inside 🎀. That's lowkey so helpful for receiving S/MIME implementations, because it helps them process the secured content correctly 💅. More smime-type values are defined in [ESS]. In an X.400 transport environment, MIME typing isn't available 😭, so the same semantic is conveyed with Encoded Information Types (EITs) instead. The EITs ride along in the original-encoded-information-types field of the X.400 message envelope. This memo defines the following smime-types 🌈:

+-----------------------------------------------------+
|                                                     |
|     smime-type           EIT Value (OID)            |
| CMS protection type       Inner Content             |
|                                                     |
+-----------------------------------------------------+
|                                                     |
|  enveloped-data        id-eit-envelopedData         |
|  EnvelopedData         Data                         |
|                                                     |
|  signed-data           id-eit-signedData            |
|  SignedData            Data                         |
|                                                     |
|  certs-only            id-eit-certsOnly             |
|  SignedData            empty (zero-length content)  |
|                                                     |
|  signed-receipt        id-eit-signedReceipt         |
|  SignedData            Receipt                      |
|                                                     |
|  enveloped-x400        id-eit-envelopedx400         |
|  EnvelopedData         X.400 content                |
|                                                     |
|  signed-x400           id-eit-signedx400            |
|  SignedData            X.400 content                |
|                                                     |
|  compressed-data       id-eit-compressedData        |
|  CompressedData        RFC 3274 compression wrapper |
|                                                     |
+-----------------------------------------------------+

Sending agents SHOULD include the appropriate S/MIME EIT OID value. Receiving agents SHOULD recognize S/MIME OID values in the EITs field, and process the message appropriately according to local procedures. 🫶

Next up, the guidelines for assigning new EIT values, so future S/MIME EIT assignments stay consistent 🦋. Values assigned for S/MIME EITs should line up with assigned smime-type values on a one-to-one basis. The restrictions of section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist with other EIT values that further qualify the makeup of the protected content ✨.

2.5.1. Enveloped Data

The enveloped data EIT says the X.400 content field holds a MIME type that got protected by the CMS enveloped-data content type, following [MSG] 💜. The resulting enveloped data CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-envelopedData  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }

2.5.2. Signed Data

The signed data EIT says the X.400 content field holds a MIME type that got protected by the CMS signed-data content type, following [MSG] 🖊️. The resulting signed data CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-signedData  OBJECT IDENTIFIER ::=
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
        pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }

2.5.3. Certs Only

certs-only messages are how you transport certificates and/or CRLs, like when you're answering a registration request 🔐. That's described in [CERT31]. A certs-only message is a single instance of CMS content of type signed-data. The encapContentInfo eContent field MUST be absent, and the signerInfos field MUST be empty 🙈. The resulting certs-only CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-certsOnly  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }

2.5.4. Signed Receipt

The signed receipt EIT says the X.400 content field holds Receipt content that got protected by the CMS signed-data content type, following [ESS] 🧾. The resulting CMS signed-data content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-signedReceipt  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }

2.5.5. Enveloped X.400

The enveloped X.400 EIT says the X.400 content field holds X.400 content that got protected by the CMS enveloped-data content type, following [X400WRAP] 🌸. The resulting enveloped X.400 CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-envelopedX400  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }

2.5.6. Signed X.400

The signed X.400 EIT says the X.400 content field holds X.400 content that got protected by the CMS signed-data content type, following [X400WRAP] 🍓. The resulting signed X.400 CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-signedX400  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }

2.5.7. Compressed Data

The compressed data EIT says the X.400 content field holds another type that got compressed by the compressed-data content type, following [COMPRESS] 🗜️. The resulting CMS content is conveyed according to section 2.2. This EIT should be indicated by the following OID value:

   id-eit-compressedData  OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }

2.6. Interaction with X.400 Elements of Service 🧚

Be careful about which X.400 services you pair with CMS objects 👀. Services that change the content, expand Distribution Lists (DLs), or redirect messages can interact badly with the services provided by the "EnvelopedData" and "SignedData" CMS content types. Lowkey a big deal.

2.6.1. MTS Conversion Services

MTS conversion doesn't apply to the scenario in this document, because conversion is incompatible with CMS protection mechanisms 🙅‍♀️. X.400 systems that implement conversion services should generally be unable to attempt conversion of CMS content types, because those types don't conform to X.420 structure rules. Still, when you transport CMS objects inside an X.400 environment, the Conversion Prohibition service SHOULD be selected 🔒.

2.6.2. Message Redirection Services

X.400 message redirection services can have an indirect impact on applying the CMS "EnvelopedData" content type 🦋. There are several forms of redirection in X.400, including:

  • Originator Requested Alternate Recipient (ORAR)
  • Alternate Recipient Assignment
  • Redirection of Incoming Messages

Any auto-forwarding services that aren't security-aware may have the same problem 🙈. An auto-forwarding implementation that removes the EnvelopedData and reapplies it for the forwarded recipient isn't affected by this problem. The normal case is that the private key isn't available when the human user isn't present, so decryption isn't possible. But if the private key is present, forwarding can be used instead 🔑.

When the "EnvelopedData" content type protects message contents, you need an instance of RecipientInfo for each recipient and alternate recipient to get the access you want. A RecipientInfo for the originator is a good practice, just in case the MTS returns the whole message 💌.

If ORAR is used, the originator knows who the alternate recipient is and SHOULD include a corresponding RecipientInfo element 🫶. For other forms of redirection (including non-security-aware auto-forwarding), the alternate recipient must either have access to the intended recipient's keys (not recommended) or must relay the message to the intended recipient by other means 📬.

2.6.3. DL Expansion

X.400 DLs can have an indirect impact on applying the CMS "EnvelopedData" content type 📋. When "EnvelopedData" protects message contents, you need an instance of RecipientInfo for each recipient to get the access you want. Messages to a DL would typically include only a single RecipientInfo, tied to the DL. Unlike the Mail Lists (MLs) described in [ESS], X.400 DLs aren't generally security-aware, and they don't regenerate RecipientInfo elements for the DL members 😬. It is recommended that a security-aware ML conforming to [ESS] be used in preference to X.400 DLs. When transporting CMS objects inside an X.400 environment, the DL Expansion Prohibited service SHOULD be selected 🚫.

3. Security Considerations 🚨

This specification introduces no new security concerns to the CMS or S/MIME models. Security issues are identified in section 5 of [MSG], section 6 of [ESS] and the Security Considerations section of [CMS]. Go read those, seriously 🔐💀.

4. References 📚

4.1. Normative References

[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.

[COMPRESS] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.

[ESS] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.

[X.400] ITU-T X.400 Series of Recommendations, Information technology - Message Handling Systems (MHS). X.400: System and Service Overview; X.402: Overall Architecture; X.411: Message Transfer System: Abstract Service Definition and Procedures; X.420: Interpersonal Messaging System; 1996.

4.2. Informative References ✨

Okay so these are the bonus reads, the stuff that's good to know but you don't need it to get the main spec. 💅

[BODYMAP]    Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
             Message Bodies", RFC 2157, January 1998.

[MIXER]      Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
             Mapping between X.400 and RFC 822/MIME", RFC 2156,
             January 1998.

[X400WRAP]   Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400
             Content with Secure/Multipurpose Internet Mail
             Extensions (S/MIME), RFC 3854, July 2004.

5. Authors' Addresses 💖

Meet the two bestie authors who wrote this one! 🫶

Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060  USA

EMail: phoffman@imc.org
Chris Bonatti
IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD  20878-3640  USA

EMail: bonattic@ieca.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. 🎀

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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. 🦋

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔥

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information 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