RFC 3183

Domain Security Services using S/MIME

📅 published October 2001, from ietf

RFC 3183 📮💖 Domain Security Services using S/MIME

  • Network Working Group 🌸
  • Authors: T. Dean and W. Ottaway, QinetiQ ✨
  • Category: Experimental 🧪
  • Date: October 2001 📅
  • Obsoletes / Updates: nothing listed, so this one doesn't replace or change any earlier RFC 🎀

Status of This Memo ✨

okay so this memo defines an Experimental Protocol for the Internet community 🧪 it is NOT an Internet standard of any kind, so think of it as a draft-ish vibe the community is trying out. they're literally asking for discussion and suggestions for improvement 🫶 and distribution of this memo is unlimited, so share it with everyone bestie 💅

the copyright line says Copyright (C) The Internet Society (2001). All Rights Reserved. 📜 that's the legal part, and it's giving formal energy 💅

Abstract 🦋

this doc explains how the S/MIME (Secure/Multipurpose Internet Mail Extensions) protocol can be processed and generated by a bunch of components in a communication system 🎀 think message transfer agents, guards, and gateways. they all team up to deliver security services, and the whole package is called 'Domain Security Services' 🔥

Acknowledgements 🙈

big thank yous to Luis Barriga, Greg Colla, Trevor Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev 🫶 they left significant comments and the doc is better because of them 💖

1. Introduction 🧚

okay so S/MIME [1] is a whole family of standards that defines a data encapsulation format 🎁 it gives you data integrity, confidentiality, and authentication ✨ it's built for messaging clients so they can deliver security services to distributed messaging apps 💅

this doc is all about the interoperability problems and technical limits that pop up when different security domains want to talk securely 🙈 like when one domain uses X.400 and another uses SMTP/MIME, which are incompatible messaging tech 💀 or when a domain needs to talk securely with one of its own members who's sitting on an untrusted domain 😭 the scenarios covered are domain-to-domain, individual-to-domain, and domain-to-individual 🌈 it also works for orgs and enterprises with internal PKIs that the outside world can't reach, but who still want to interoperate using S/MIME 🔐

now, end-to-end (desktop-to-desktop) security is not always the move 🙅‍♀️ especially between different security domains 🌸 an org thinking about end-to-end security will usually run into some or all of these issues:

  1. Heterogeneous message access methods: users read mail through tools that reformat messages, like web browsers 🌐 when the Message Store reformats stuff, end-to-end encryption and signature validation become impossible 💔
  2. Message screening and audit: server-side stuff like searching for banned words or other content, virus scanning, and auditing doesn't play nice with end-to-end encryption 🦠
  3. PKI deployment issues: there might not be any certificate paths between two orgs 🛤️ or an org might be protective of its PKI and not want it exposed to outside access 🔒 also, rolling out full PKI for every employee can be expensive, unnecessary, or impractical for big orgs 💸 for any of these reasons, direct end-to-end signature validation and encryption are impossible 😭
  4. Heterogeneous message formats: one org uses X.400 series protocols and wants to chat with another org using SMTP 📨 reformatting at the gateways makes end-to-end encryption and signature validation impossible too 💀

this doc describes a way to fix these problems by providing message security at the level of a domain or an organization 🏰 it specifies how these 'domain security services' can be provided using S/MIME ✨ domain security services can replace desktop mechanisms or work alongside them 🫶 for example, a domain might do desktop-to-desktop signatures but domain-to-domain encryption 🔐 or it might allow desktop-to-desktop services inside the domain, but enforce domain-based services for talking to other domains 👑

domain services are also useful for individual members of a corporation who are geographically remote 🌍 they can use them to swap encrypted and/or signed messages with their base 💌

is a domain-based service inherently better or worse than desktop solutions? 🤔 honestly that's an open question, and experts don't all agree 😅 some think only end-to-end solutions can be truly secure 🔒 others say things like content checking at domain boundaries add a ton of practical security for many real systems 🛡️ being able to check signatures at several points along a communications path is another bonus in lots of situations ✨ this debate is outside the scope of this document 🙅‍♀️ what this doc does give you is a set of tools that integrators can tailor in different ways for different needs in different circumstances 🧰💖

⚠️ Security heads-up: message transfer agents (MTAs), guards, firewalls and protocol translation gateways all provide domain security services 🏰 just like desktop solutions, these components have to be resilient against a wide variety of attacks that try to subvert the security services 😱 so careful thought should be given to the security of these components, to make sure their siting and configuration minimises the possibility of attack 🔥

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 [2] 📖 🫶

2. Overview of Domain Security Services 🦋

this section is a chill, informal tour of the security services S/MIME provides between different security domains 🌈 they're delivered by a combo of mechanisms in the sender's domain and the recipient's domain 🤝

later sections spell out exactly how these services map onto elements of the S/MIME protocol 📐

the following security mechanisms are specified in this document:

  1. Domain signature
  2. Review signature
  3. Additional attributes signature
  4. Domain encryption and decryption

the signature types defined in this doc are called DOMSEC defined signatures 🏷️

the term 'security domain' means a collection of hardware and personnel operating under a single security authority and performing a common business function 🏢 members of a security domain will naturally share a high degree of mutual trust, since they have shared aims and objectives 🫶

a security domain is usually shielded from direct outside attack by physical measures 🧱 and from indirect (electronic) attack by a combo of firewalls and guards at the network boundaries 🔥 the interface between two security domains is called a 'security boundary' 🚧 one example of a security domain is an organizational network ('Intranet') 💼

2.1 Domain Signature ✍️

a domain signature is an S/MIME signature generated on behalf of a set of users in a domain 💅 it can be used to authenticate information sent between domains, or between a domain and one of its individuals 🤝 for instance, when two 'Intranets' are connected over the Internet, or when an Intranet is connected to a remote user over the Internet 🌐 it can be used when two domains use incompatible signature schemes internally, or when there are no certification links between their PKIs 🔗 in both cases, messages from the originator's domain are signed over the original message and signature (if present) 📝 using an algorithm, key, and certificate that the recipient(s) or the recipient(s) domain can process 🔑 a domain signature is sometimes called an "organizational signature" 🏷️

2.2 Review Signature 👀

a third party may review messages before they get forwarded to the final recipient(s), who may be in the same or a different security domain 🕵️‍♀️ organizational policy and good security practice often require messages to be reviewed before they're released to external recipients 🚪 once a message has been reviewed, an S/MIME signature gets added to it, and that's the review signature ✅ an agent can check the review signature at the domain boundary to make sure only reviewed messages get released 🛡️ main character gatekeeping energy 👑

2.3 Additional Attributes Signature 🏷️

a third party can add additional attributes to a signed message 💅 an S/MIME signature is used for this, and it's called an additional attributes signature ✍️ an example of an additional attribute is the 'Equivalent Label' attribute defined in ESS [3] 🧾

2.4 Domain Encryption and Decryption 🔐

domain encryption is S/MIME encryption performed on behalf of a collection of users in a domain 🏰 it can protect information between domains, for example when two 'Intranets' are connected over the Internet 🌐 it's also useful when end users don't have PKI/encryption capabilities on their desktops, or when two domains use incompatible encryption schemes internally 🙌 in that last case, messages from the originator's domain are encrypted (or re-encrypted) using an algorithm, key, and certificate that can be decrypted by the recipient(s) or an entity in their domain 🔓 this scheme also covers protecting information between a single domain and one of its members, when both are connected over an untrusted network, like the Internet 🌍 ✨

3. Mapping of the Signature Services to the S/MIME Protocol ✨

okay bestie, this section is where the security services from section 2 finally get mapped onto actual S/MIME bits 💅 ESS [3] brings in the idea of triple-wrapped messages: signed first, then encrypted, then signed again 🎀 This document uses that same triple-wrapping trick too. It also uses something called "signature encapsulation," which is the big one 🦋 Signature encapsulation means a signed or unsigned message gets wrapped inside a signature, and that outer signature covers both the content AND the first (inner) signature, if there is one.

Signature encapsulation MAY be performed on the inner and/or the outer signature of a triple-wrapped message.

Here's an example 🌸 The originator signs a message, then it gets encapsulated with an 'additional attributes' signature, then it all gets encrypted. After that, a reviewer signs the encrypted data, and a domain signature wraps it all up 💖

Some policies might want signatures added in a specific order 👑 Since signatures can only be added by encapsulation, you can tell which order they went on. The layers basically tell the story for you ✨

A DOMSEC defined signature MAY encapsulate a message in one of the following ways:

  1. An unsigned message gets an empty signature layer added to it. In other words, the message is wrapped in a signedData whose signerInfos has no elements. This is for backward compatibility with S/MIME software that doesn't have DOMSEC capability 🫶 Because the signerInfos has no signers, the eContentType inside the EncapsulatedContentInfo MUST be id-data as described in CMS [5]. The twist is that the eContent field holds the unsigned message instead of being left empty like section 5.2 in CMS [5] suggests 😭 That way, when a DOMSEC defined signature gets added (method 2 below), it covers the unsigned message.
  2. Signature Encapsulation wraps the original signed message with a DOMSEC defined signature. This means the DOMSEC defined signature covers the message and all the signatures already on it 🔥 It also means you can tell the DOMSEC defined signature was added after the ones that were already there.

3.1 Naming Conventions and Signature Types

okay, this part is a big deal 🙈 Normally, when you get an S/MIME signed message, you expect the signature to belong to whoever sent it. But the services in this document need the recipient to accept messages signed by other entities AND/OR the originator. So when someone else signs, the name in the certificate won't match the message sender's name. A typical S/MIME implementation would flag a warning for that mismatch. (That check blocks a bunch of masquerade attacks, so it's not being dramatic when it says it matters 💀)

For domain security services, this warning condition SHOULD be suppressed under certain circumstances. Those circumstances are set by a naming convention that spells out the form the signer's name SHOULD adhere to. Following that convention avoids uncontrolled naming and the masquerade attacks that would come with it 🛡️

To help with implementation, there's a signed attribute called the 'signature type' attribute that goes inside the S/MIME signature 🦋 When a message has it, the naming convention checks get invoked.

Implementations conforming to this standard MUST support the naming convention for signature generation and verification. Implementations conforming to this standard MUST recognize the signature type attribute for signature verification. Implementations conforming to this standard MUST support the signature type attribute for signature generation.

3.1.1 Naming Conventions

Here are the naming conventions for agents generating the signatures specified in this document 🎀

  • For a domain signature, an agent generating this signature MUST be named domain-signing-authority
  • For a review signature, an agent generating this signature MUST be named review-authority.
  • For an additional attributes signature, an agent generating this signature MUST be named attribute-authority.

This name shall appear as the common name (CN) component of the subject field in the X.509 certificate. There MUST be only one CN component present. If the certificate also contains an RFC 822 address, this name shall appear in the end entity component of that address, on the left-hand side of the @ symbol 💖

For a domain signature, there's an extra rule called the 'name mapping rule' ✨ It says that for a domain signing authority, the domain part of its name MUST be the same as, or an ascendant of, the domain name of the message originator(s) it represents. The domain part is defined like this:

  • For an X.500 distinguished subject name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name.
  • For an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name.
  • If the certificate contains an RFC 822 address, the domain part is the RFC 822 address component on the right-hand side of the @ symbol.

Let's do an example, because this is where it clicks 🧚 A domain signing authority is acting for John Doe of the Acme corporation. His distinguished name is cn=John Doe,ou=marketing,o=acme,c=us and his e-mail address is John.Doe@marketing.acme.com. The domain signing authority could have a certificate with the distinguished name cn=domain-signing-authority,o=acme,c=us and the RFC 822 address domain-signing-authority@acme.com. If John Doe has the RFC 2247 defined address cn=John Doe,dc=marketing,dc=acme,dc=us, then the address cn=domain-signing-authority,dc=acme,dc=us could be used to represent the domain signing authority 🌈

When the X.500 distinguished subject name has consecutive organizational units and/or localities, the ordering matters a lot 🙈 You have to understand that ordering to figure out whether the domain part of the domain signature is an ascendant. In this case, when you parse the distinguished subject name starting from the most significant component (country, locality or organization), the parsed organizational unit or locality counts as the ascendant of the consecutive (unparsed) organizational units or localities.

When parsing an RFC 2247 subject name from the most significant component (the dc entry that represents the country, locality or organization), the parsed dc entry counts as the ascendant of the consecutive (unparsed) dc entries.

Another example, with a deeper hierarchy 🍓 A domain signing authority is acting for John Doe of the Acme corporation. His distinguished name is cn=John Doe,ou=marketing,ou=defence,o=acme,c=us and his e-mail address is John.Doe@marketing.defence.acme.com. The domain signing authority could have a certificate with the distinguished name cn=domain-signing-authority,ou=defence,o=acme,c=us and the RFC 822 address domain-signing-authority@defence.acme.com. If John Doe has the RFC 2247 defined address cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us, then the domain signing authority could have the distinguished name cn=domain-signing-authority,dc=defence,dc=acme,dc=us.

Any message received where the domain part of the domain signing agent's name does not match, or is not an ascendant of, the originator's domain name MUST be flagged.

This naming rule stops agents from one organization pretending to be domain signing authorities for another organization 🚫 For the other types of signature defined in this document, no name mapping rule is defined.

Implementations conforming to this standard MUST support this name mapping convention as a minimum. Implementations MAY choose to supplement this convention with other locally defined conventions. However, these MUST be agreed between sender and recipient domains prior to secure exchange of messages.

When verifying the signature, a receiving agent MUST ensure that the naming convention has been adhered to. Any message that violates the convention MUST be flagged 💅

3.1.2 Signature Type Attribute

An S/MIME signed attribute is used to indicate the type of signature 🦋 It's meant to be used together with the naming conventions from the previous section. When an S/MIME signed message containing the signature type attribute is received, it triggers the software to verify that the correct naming convention was used.

The ASN.1 [4] notation of this attribute is:

SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

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

-- signature type identifier

If it's present, the SignatureType attribute MUST be a signed attribute, as defined in [5]. If the SignatureType attribute is absent and there are no further encapsulated signatures, the recipient SHOULD assume that the signature is that of the message originator 👑

All of the signatures defined here are generated and processed as described in [5] 🌸 They're told apart by the presence of the following values in the SignatureType signed attribute:

id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 }
-- domain signature.

id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 }
-- additional attributes signature.

id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 }
-- review signature.

For completeness, there's also an attribute type for an originator signature. This signature type is optional, though 🫶 It's defined as follows:

id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 }
-- originator's signature.

All signature types, except the originator type, MUST encapsulate other signatures. Note that a DOMSEC defined signature could be encapsulating an empty signature, as defined in section 3 🙈

A SignerInfo MUST NOT include multiple instances of SignatureType. A signed attribute representing a SignatureType MAY include multiple instances of different SignatureType values as an AttributeValue of attrValues [5], as long as the SignatureType 'additional attributes' is not present.

If there's more than one SignerInfo in a signerInfos (for example, when different algorithms are used), then the SignatureType attribute in all the SignerInfos MUST contain the same content 🔥

The following sections describe the conditions under which each of these types of signature may be generated, and how they are processed 💜

3.2. Domain Signature Generation and Verification

okay so a 'domain signature' is a proxy signature generated on a user's behalf in the user's domain 💅 it MUST follow the naming conventions in 3.1.1, name mapping convention included. it's basically the domain stamping "yep, this left our domain" on a message ✨ before a process signs, it MUST first make sure the originator is legit 🔍 there are two ways to do that. either you check the 'originator's signature' (if S/MIME signatures are used inside the domain), or, if not, you use something outside S/MIME, like the physical address of the originating client or an authenticated IP link 🌸

if the originator checks out by one of those methods AND every other signature present is valid (including the encrypted ones) 🎀 then a 'domain signature' can get added to the message 💖

heads up though: if a 'domain signature' is added and the message hits a Mail List Agent (MLA), it's possible the 'domain signature' gets removed 😭 to stop that, the steps in section 5 MUST be followed 🛡️

an entity generating a domain signature MUST use a certificate whose subject name follows the naming convention in 3.1.1. no exceptions bestie 🙅‍♀️

if the originator's authenticity is NOT verified, or any of the signatures present are NOT valid, then a 'domain signature' MUST NOT be generated 💀 hard stop

on reception, the 'domain signature' SHOULD be used to verify the authenticity of a message ✨ and you MUST check that both the naming convention and the name mapping convention were used the way this standard says 🧚

a recipient can assume that a successful domain signature verification also authenticates the message originator 👑 main character energy

if there's an originator signature present, the name in that certificate SHOULD be used to identify the originator, and that info can then be displayed to the recipient 💜

if there's no originator signature, the only thing you can assume is the domain the message came from 🦋

a domain signer can be assumed to have verified any signatures it encapsulates 🫶 so you don't have to re-verify them before treating the message as authentic. BUT this standard doesn't stop a recipient from trying to verify any other signatures that are present 🔎

the 'domain signature' is indicated by the presence of the value id-sti-domainSig in a 'signature type' signed attribute 🏷️

there MAY be one or more 'domain signature' signatures in an S/MIME encoding 🌈

3.3. Additional Attributes Signature Generation and Verification

the 'additional attributes' signature type says the SignerInfo carries extra attributes that are tied to the message 🎀

ok so ALL attributes in the applicable SignerInfo MUST be treated as additional attributes 📦 and a successful check of an 'additional attributes' signature only means the attributes are authentically bound to the message. a recipient MUST NOT assume that it also authenticates the message originator 🙈 not the same thing, iykyk

an entity generating an 'additional attributes' signature MUST use a certificate whose subject name follows the naming convention in 3.1.1. and on reception, a check MUST be made to ensure the naming convention was used 🧐

a signer MAY include any of the attributes listed in [3] or in this document when generating an 'additional attributes' signature 🍓 these ones have a special meaning when they show up in an 'additional attributes' signature:

  1. Equivalent Label: label values in this attribute are to be treated as equivalent to the security label contained in an encapsulated SignerInfo, if present. 🏷️
  2. Security Label: the label value indicates the aggregate sensitivity of the inner message content plus any encapsulated signedData and envelopedData containers. The label on the original data is indicated by the value in the originator's signature, if present. 🔐

the 'additional attributes' signature is indicated by the presence of the value id-sti-addAttribSig in a 'signature type' signed attribute 💅 and if this value is present, other Object Identifiers MUST NOT be included in the sequence of OIDs 🚫

there MAY be multiple 'additional attributes' signatures in an S/MIME encoding 💖

3.4. Review Signature Generation and Verification

the review signature shows that the signer has reviewed the message 👀 successful verification only means the signer approved the message for onward transmission to the recipient(s). when the recipient is in another domain, a device on a domain boundary (like a Mail Guard or firewall) may be configured to check review signatures 🧱 and a recipient MUST NOT assume that a successful verification also authenticates the message originator. not the vibe, bestie 🙅‍♀️

an entity generating a signed review signature MUST use a certificate whose subject name follows the naming convention in 3.1.1. on reception, a check MUST be made to ensure the naming convention was used ✨

a review signature is indicated by the presence of the value id-sti-reviewSig in a 'signature type' signed attribute 🏷️

there MAY be multiple review signatures in an S/MIME encoding 🦋

3.5. Originator Signature

the 'originator signature' says the signer is the originator of the message and its contents 💜 it's only included in this document for completeness, so don't stress about it too much 🫶 an originator signature is indicated either by the absence of the signature type attribute, OR by the presence of the value id-sti-originatorSig in a 'signature type' signed attribute 🌸

4. Encryption and Decryption 🔒

okay so message encryption can be done by a third party on behalf of a set of originators in a domain. that's called domain encryption 🎀 and message decryption can be done by a third party on behalf of a set of recipients in a domain, which is domain decryption ✨ the third party doing this is called a "Domain Confidentiality Authority" (DCA) in this section 👑 both processes are described here 💖

messages may be encrypted for decryption by the final recipient and/or by a DCA in the recipient's domain 🧚 the message may also be encrypted for decryption by a DCA in the originator's domain (e.g., for content analysis, audit, key word scanning, etc.) 🔎 which one actually happens is a system specific issue that depends on system security policy, so it's outside the scope of this document 🙃 here's the table for these encryption and decryption processes:

 --------------------------------------------------------------------
|                        | Recipient Decryption |  Domain Decryption |
|------------------------|----------------------|--------------------|
| Originator Encryption  |       Case(a)        |       Case(b)      |
| Domain Encryption      |       Case(c)        |       Case(d)      |
 --------------------------------------------------------------------

case (a), originator encryption for decryption by the final recipient(s), is described in CMS [5] 📜 in cases (c) and (d), the encryption is done by the DCA in the originator's domain instead of the originator 🏢 and in cases (b) and (d), the decryption is done by the DCA in the recipient's domain instead of the recipient(s) 🔓

a client implementation that conforms to this standard MUST support case (b) for transmission, case (c) for reception, and case (a) for transmission and reception 💅

a DCA implementation that conforms to this standard MUST support cases (c) and (d) for transmission, and cases (b) and (d) for reception 🫶 in cases (c) and (d) the 'domain signature' SHOULD be applied before the encryption ✨ and in cases (b) and (d) the message SHOULD be decrypted before the originators 'domain signature' is obtained and verified 🔐

the process of encryption and decryption is documented in CMS [5] 📖 the only extra requirement that domain encryption and decryption brings is greater flexibility in managing keys, covered in the subsections below 🗝️ and just like with signatures, a naming convention and name mapping convention are used to locate the correct public key 🎯

the mechanisms below apply to both key agreement and key transport systems, as documented in CMS [5] 🌈 the phrase 'encryption key' is a collective term for the key management keys used by both techniques 🦋

the mechanisms below also apply to individual roving users who want to encrypt messages that get sent back to base 🧳✨

4.1. Domain Confidentiality Naming Conventions

a DCA MUST be named 'domain-confidentiality-authority' 🏷️ this name MUST appear in the 'common name(CN)' component of the subject field in the X.509 certificate. also, if the certificate contains an RFC 822 address, this name MUST appear in the end entity part of the address, i.e., on the left-hand side of the '@' symbol 💌

there's an extra naming rule too: the 'name mapping rule' 🗺️ it says that for a DCA, the domain part of its name MUST be the same as, or an ascendant of (as defined in section 3.1.1), the domain name of the set of entities it represents. the domain part works like this:

  • In the case of an X.500 distinguished name of an X.509 certificate, the domain part is the country, organization, organizational unit, state, and locality components of the distinguished name. 🌍
  • In the case of an RFC 2247 distinguished name, the domain part is the domain components of the distinguished name. 🧩
  • If the certificate contains an RFC 822 address, the domain part is defined to be the RFC 822 address part on the right-hand side of the '@' symbol. 📨

example time 🙈 say a DCA is acting for John Doe of the Acme corporation, whose distinguished name is 'cn=John Doe,ou=marketing,o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com. the DCA could have a certificate with the distinguished name 'cn=domain-confidentiality-authority,o=acme,c=us' and the e-mail address 'domain-confidentiality-authority@acme.com'. and if John Doe has an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us', then the domain signing authority could have a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. the key tied to this certificate would be used for encrypting messages for John Doe 🔑

any message received where the domain part of the domain encrypting agent's name does NOT match, or is NOT an ascendant of, the domain name of the entities it represents MUST be flagged 🚩 this naming rule stops messages from getting encrypted for the wrong domain decryption agent 🙅‍♀️

implementations conforming to this standard MUST support this name mapping convention as a minimum 💖 implementations may choose to supplement this convention with other locally defined conventions. however, these MUST be agreed between sender and recipient domains prior to sending any messages 🤝 no surprises, periodt 💜

4.2. Key Management for DCA Encryption ✨

okay so at the sender's domain, DCA encryption happens using either the recipient DCA's certificate or the end recipient's certificate 🎀. the encrypting process has to be able to find the right certificate for the matching DCA in the recipient's domain, or the one for the end recipient 🔎. once it's located, the encryption happens and the extra info needed for decryption gets sent to the recipient in the recipientInfo field, as CMS [5] describes 💌. a DCA encryption agent MUST be named according to the naming convention in section 4.1 so that its certificate can be found 🫶.

no specific method for finding that certificate is mandated in this document 🙅‍♀️. an implementation can check a local certificate store. or a X.500 or LDAP directory can be used in one of these ways:

  1. The directory may store the DCA certificate in the recipient's directory entry. When the user certificate attribute is requested, this certificate is returned.
  2. The encrypting agent maps the recipient's name to the DCA name in the manner specified in 4.1. The user certificate attribute associated with this directory entry is then obtained.

this document does not mandate either of these processes 🤷‍♀️. whichever one you use, the name mapping conventions must be adhered to, in order to maintain confidentiality 🔐.

having located the correct certificate, the encryption process is then performed. a recipientInfo for the DCA or end recipient is then generated, as described in CMS [5] 💅.

DCA encryption may be performed for decryption by the end recipient and/or by a DCA. end recipient decryption is described in CMS [5]. DCA decryption is described in section 4.3 🦋.

4.3. Key Management for DCA Decryption

okay, DCA decryption uses a private key that belongs to the DCA, plus the necessary info conveyed in the DCA's recipientInfo field 🗝️.

it should be noted that domain decryption can be performed on messages encrypted by the originator and/or by a DCA in the originator's domain 👀. in the first case, the encryption process is described in CMS [5]. in the second case, it's described in 4.2 🧚.

5. Applying a Domain Signature when Mail List Agents are Present.

bestie, this one is seriously important 😭. a message leaving a DOMSEC domain might run into a Mail List Agent (MLA) before it reaches the final recipient. there's a possibility that this strips off the 'domain signature', and we are NOT about that life 🙅‍♀️. so the 'domain signature' must be applied to the message in a way that stops an MLA from removing it 🛡️.

an MLA will search a message for the "outer" signedData layer, as defined in ESS [3] section 4.2, and strip off all the signedData layers that wrap this "outer" signedData layer 🧅. where that "outer" layer is found depends on whether the message has an mlExpansionHistory attribute or an envelopedData layer 🤔.

there's a possibility that a message leaving a DOMSEC domain has already been processed by an MLA. if so, an mlExpansionHistory attribute will be present in the message 📬.

there's also a possibility that the message will contain an envelopedData layer. this happens when the message has been encrypted inside the domain for the domain's "Domain Confidentiality Authority", see section 4.0, and possibly the final recipient too 🔒.

how the 'domain signature' gets applied depends on what's already in the message ✨. before the 'domain signature' can be applied, the message MUST be searched for the "outer" signedData layer. that search is complete when one of these is found:

  • The "outer" signedData layer that includes an mlExpansionHistory attribute or encapsulates an envelopedData object.
  • An envelopedData layer.
  • The original content (that is, a layer that is neither envelopedData nor signedData).

if a signedData layer containing an mlExpansionHistory attribute has been found, then:

  1. Strip off the signedData layer (after remembering the included signedAttributes).
  2. Search the rest of the message until an envelopedData layer or the original content is found.
  3. Next:
    • a) If an envelopedData layer has been found, then:
      • Strip off all the signedData layers down to the envelopedData layer.
      • Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key.
      • Decrypt the encryptedContent using the message key.
      • Encapsulate the decrypted message with a 'domain signature'.
      • If local policy requires the message to be encrypted using S/MIME encryption before leaving the domain, then encapsulate the 'domain signature' with an envelopedData layer containing RecipientInfo structures for each of the recipients and an originatorInfo value built from information describing this DCA.

If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message, then the 'domain signature' MUST be encapsulated by an envelopedData as described above.

An example when it may not be local policy to require S/MIME encryption is when there is a link crypto present.

  • b) If an envelopedData layer has not been found, then:
    • Encapsulate the new message with a 'domain signature'.
  1. Encapsulate the new message in a signedData layer, adding the signedAttributes from the signedData layer that contained the mlExpansionHistory attribute.

if no signedData layer containing an mlExpansionHistory attribute has been found, but an envelopedData has been found, then:

  1. Strip off all the signedData layers down to the envelopedData layer.
  2. Locate the RecipientInfo for the local DCA and use the information it contains to obtain the message key.
  3. Decrypt the encryptedContent using the message key.
  4. Encapsulate the decrypted message with a 'domain signature'.
  5. If local policy requires the message to be encrypted before leaving the domain, then encapsulate the 'domain signature' with an envelopedData layer containing RecipientInfo structures for each of the recipients and an originatorInfo value built from information describing this DCA.

If local policy does not require the message to be encrypted using S/MIME encryption but there is an envelopedData at a lower level within the message, then the 'domain signature' MUST be encapsulated by an envelopedData as described above.

if no signedData layer containing an mlExpansionHistory attribute has been found and no envelopedData has been found, then:

  1. Encapsulate the message in a 'domain signature'.

that's the whole mail list agent glow-up 🌈💖

5.1 Examples of Rule Processing

Okay bestie, these examples show the rules in action 💅 All of the signedData objects here are valid, and none of them are a domain signature 🎀 If a signedData object was a domain signature, you wouldn't need to validate any further signedData objects ✨

  1. Okay so the first one is a message (S1 (Original Content)) (where S = signedData) whose signedData has no mlExpansionHistory attribute, and it needs a 'domain signature' 💖 We verify S1. There's no "outer" signedData to find, because the original content is right there. There's also no envelopedData or mlExpansionHistory attribute. So we make a brand new signedData layer, S2, that holds a 'domain signature', and the message leaving the domain is (S2 (S1 (Original Content))) 🦋
  2. Next, a message (S3 (S2 (S1 (Original Content))) where none of the signedData layers has an mlExpansionHistory attribute, so it gets a 'domain signature' too 🌸 We verify S1, S2 and S3. Again there's no "outer" signedData, since the original content shows up, and no envelopedData or mlExpansionHistory either. We wrap a new signedData layer, S4, with the 'domain signature', and the message leaving is (S4 (S3 (S2 (S1 (Original Content))). Iconic layering, no cap 👑
  3. Now a message (E1 (S1 (Original Content))) (where E = envelopedData) where S1 has no mlExpansionHistory attribute, and it needs a 'domain signature' ✨ There's no original "outer" signedData layer, because envelopedData E1 is the outer layer. We decrypt the encryptedContent, verify S1, and wrap the decrypted content in a new signedData layer, S2, which holds a 'domain signature'. Now if local policy says the message has to be encrypted with S/MIME encryption before it leaves the domain, we wrap it in an envelopedData layer, E2, and the message going out is (E2 (S2 (S1 (Original Content)))) 🔥 If not, we skip the envelopedData wrapper and send (S2 (S1 (Original Content))) 🫶
  4. This one is a message (S2 (E1 (S1 (Original Content)))) where S2 includes an mlExpansionHistory attribute, so it needs a 'domain signature' 🧚 We verify S2, and since the mlExpansionHistory attribute is in S2, S2 is the "outer" signedData. We remember the signed attributes in S2 so we can include them later in the new outer signedData that goes on the message. Then we strip S2 off, decrypt the message, and verify S1. The decrypted message gets wrapped in a signedData layer, S3, which holds a 'domain signature'. If local policy requires S/MIME encryption before the message leaves the domain, we wrap it in an envelopedData layer, E2, and then wrap a new signedData layer, S4, around E2. The message going out is (S4 (E2 (S3 (S1 (Original Content))))). If local policy does not require encryption, we skip the envelopedData layer and just wrap a new signedData layer, S4, around S3, so the message going out is (S4 (S3 (S1 (Original Content)). Either way, the signedData S4 carries the signed attributes from S2 💜
  5. Next up, a message (S3 (S2 (E1 (S1 (Original Content))))) where none of the signedData layers include an mlExpansionHistory attribute, so it needs a 'domain signature' 🦋 We verify S3 and S2, and when we find envelopedData E1 we strip off those signedData objects. Then we decrypt the encryptedContent and verify S1. The decrypted content gets wrapped in a new signedData layer, S4, with a 'domain signature'. If local policy requires S/MIME encryption before it leaves, we wrap the message in an envelopedData layer, E2, and send (E2 (S4 (S1 (Original Content)))). Otherwise we send (S4 (S1 (Original Content))) without the envelopedData wrapper 🌈
  6. Here's a message (S3 (S2 (E1 (S1 (Original Content))))) where S3 includes an mlExpansionHistory attribute, so it needs a 'domain signature' 😭 We verify S3 and S2. Since the mlExpansionHistory attribute is in S3, S3 is the "outer" signedData, and we remember its signed attributes for the new outer signedData we'll apply later. We strip off S3. When we reach envelopedData E1, we strip off S2, decrypt the encryptedContent, and verify S1. The decrypted content gets wrapped in a new signedData layer, S4, with a 'domain signature'. If local policy requires S/MIME encryption before it leaves the domain, we wrap it in an envelopedData layer, E2, then wrap a new signedData layer, S5, around E2, and the message going out is (S5 (E2 (S4 (S1 (Original Content))))). If encryption isn't required, the message is wrapped in a new signedData layer, S5, around S4, so it goes out as (S5 (S4 (S1 (Original Content). Either way, S5 carries the signed attributes from S3 💅
  7. Last one: a message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) where S3 doesn't include an mlExpansionHistory attribute, so it needs a 'domain signature' 🍓 We verify S3, and when we find envelopedData E2 we strip S3 off. Then we decrypt the encryptedContent, verify S2, decrypt the envelopedData E1, and verify S1. The signedData object S2 gets wrapped in a new signedData layer, S4, with a 'domain signature'. Since there's an envelopedData E1 lower down in the message, the new message gets wrapped in an envelopedData layer, E3, and the message going out of the domain is (E3 (S4 (S2 (E1 (S1 (Original Content))))) ✨

6. Security Considerations ✨

Okay, this part is seriously important, so listen up 🫶 This spec relies on a few well known names, like domain-confidentiality-authority. Organizations have to take care with these names, even if they don't support DOMSEC, so that certificates issued in these names only go to legit entities 🔥 If that isn't true, then someone could get a certificate tied to domain-confidentiality-authority@acme.com and as a result might be able to read messages the a DOMSEC client meant for other people 💀

Implementations MUST protect all private keys. If the signer's private key gets compromised, that permits masquerade 😭

Similarly, if the content-encryption key gets compromised, the encrypted content may be disclosed 🙈

Compromised key material is a way more serious issue for domain security services than for an S/MIME client 🚨 That's because a compromised private key may in turn compromise the security of a whole domain. So, great care should be used when thinking about how to protect it 🧚

Domain encryption alone is not secure, and it should be used together with a domain signature to avoid a masquerade attack 💜 In that attack, an attacker who has obtained a DCA certificate could fake a message to that domain while pretending to be another domain.

When an encrypted DOMSEC message is sent to an end user in a way that the end user's DCA decrypts it, the message will be in plain text, so confidentiality could be compromised. Yikes 🙈

If the recipient's DCA is compromised, then the recipient can't guarantee the integrity of the message 😭 And even if the recipient's DCA correctly verifies a message's signatures, a message could still be undetectably modified when there are no signatures on it that the recipient can verify 💀

7. DOMSEC ASN.1 Module 🧚

DOMSECSyntax
 { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) }

 DEFINITIONS IMPLICIT TAGS ::=
 BEGIN

 -- EXPORTS All
 -- The types and values defined in this module are exported for
 -- use in the other ASN.1 modules.  Other applications may use
 -- them for their own purposes.

 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER

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

 id-sti  OBJECT IDENTIFIER ::= { id-smime 9 }   -- signature type
 identifier

 -- Signature Type Identifiers

 id-sti-originatorSig       OBJECT IDENTIFIER ::= { id-sti 1 }
 id-sti-domainSig           OBJECT IDENTIFIER ::= { id-sti 2 }
 id-sti-addAttribSig        OBJECT IDENTIFIER ::= { id-sti 3 }
 id-sti-reviewSig           OBJECT IDENTIFIER ::= { id-sti 4 }

 END -- of DOMSECSyntax

8. References 📚

[1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

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

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

[4] International Telecommunications Union, Recommendation X.208, "Open systems interconnection: specification of Abstract Syntax Notation (ASN.1)", CCITT Blue Book, 1989.

[5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

9. Authors' Addresses 🌸

Tim Dean
QinetiQ
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: +44 (0) 1684 894239
Fax:   +44 (0) 1684 896660
EMail: tbdean@QinetiQ.com

William Ottaway
QinetiQ
St. Andrews Road
Malvern
Worcs
WR14 3PS

Phone: +44 (0) 1684 894079
Fax:   +44 (0) 1684 896660
EMail: wjottaway@QinetiQ.com

Copyright (C) The Internet Society (2001). All Rights Reserved.

Okay so, the legal bit 🧾 (ngl it's giving lawyer energy, but it matters!!). You're allowed to copy this document and share it with others. You can also write derivative works that comment on it, explain it, or help people implement it, and those can be prepared, copied, published, and distributed, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph are included on every copy and every derivative work. 🎀

BUT the document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. The first is developing Internet standards, where you have to follow the copyright procedures in the Internet Standards process. The second is translating it into languages other than English. 🌍

The permissions above are perpetual, and the Internet Society or its successors or assigns will never revoke them. Forever vibes 🦋

The bit below is in all caps for a reason, bestie 💀 This document and the information in it is provided on an "AS IS" basis. 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 🫶

Big thank-you energy here: the RFC Editor function is currently funded by the Internet Society. 🌸

📦 where this page comes from