idnits 2.17.1 draft-melnikov-smime-msa-to-mda-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2014) is 3755 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5750 (Obsoleted by RFC 8550) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 7001 (Obsoleted by RFC 7601) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Ottaway 3 Internet-Draft QinetiQ 4 Intended status: Standards Track A. Melnikov, Ed. 5 Expires: July 18, 2014 Isode Ltd 6 January 14, 2014 8 MSA and MTA S/MIME signing & encryption 9 draft-melnikov-smime-msa-to-mda-02 11 Abstract 13 This document specifies how S/MIME signing and encryption can be 14 applied between a Message Submission Agent (MSA) and a Message 15 Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 53 2.1. Domain Signature . . . . . . . . . . . . . . . . . . . . 5 54 2.2. Domain Encryption and Decryption . . . . . . . . . . . . 5 55 2.3. Signature Encapsulation . . . . . . . . . . . . . . . . . 5 56 2.4. Naming Conventions . . . . . . . . . . . . . . . . . . . 6 57 3. MSA/MTA S/MIME signing . . . . . . . . . . . . . . . . . . . 7 58 3.1. Naming Conventions and Signature Types . . . . . . . . . 7 59 3.1.1. Signature Type Attribute . . . . . . . . . . . . . . 8 60 3.2. Domain Signature Generation and Verification . . . . . . 9 61 4. MSA-to-MDA S/MIME Encryption and Decryption . . . . . . . . . 10 62 4.1. Key Management for DCA Encryption . . . . . . . . . . . . 11 63 4.2. Key Management for DCA Decryption . . . . . . . . . . . . 12 64 5. Applying a Domain Signature when Mail List Agents are Present 12 65 5.1. Examples of Rule Processing . . . . . . . . . . . . . . . 15 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 70 8.2. Informative References . . . . . . . . . . . . . . . . . 18 71 Appendix A. Changes from RFC 3183 . . . . . . . . . . . . . . . 20 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 74 1. Introduction 76 The S/MIME [RFC5750][RFC5751] series of standards define a data 77 encapsulation format for the provision of a number of security 78 services including data integrity, confidentiality, and 79 authentication. S/MIME is designed for use by messaging clients to 80 deliver security services to distributed messaging applications. 82 The mechanisms described in this document are designed to solve a 83 number of interoperability problems and technical limitations that 84 arise when different security domains wish to communicate securely, 85 for example when two domains use incompatible messaging technologies 86 such as the X.400 series and SMTP/MIME [RFC5322], or when a single 87 domain wishes to communicate securely with one of its members 88 residing on an untrusted domain. The main scenario covered by this 89 document is domain-to-domain, although it is also applicable to 90 individual-to-domain and domain-to-individual communications. This 91 document is also applicable to organizations and enterprises that 92 have internal PKIs which are not accessible by the outside world, but 93 wish to interoperate securely using the S/MIME protocol. 95 There are many circumstances when it is not desirable or practical to 96 provide end-to-end (MUA-to-MUA) security services, particularly 97 between different security domains. An organization that is 98 considering providing end-to-end security services will typically 99 have to deal with some if not all of the following issues: 101 1. Message screening and audit: Server-based mechanisms such as 102 searching for prohibited words or other unauthorized content, 103 virus scanning, and audit, are incompatible with end-to-end 104 encryption. 106 2. PKI deployment issues: There may not be any certificate paths 107 between two organizations. Or an organization may be sensitive 108 about aspects of its PKI and unwilling to expose them to outside 109 access. Also, full PKI deployment for all employees, may be 110 expensive, not necessary or impractical for large organizations. 111 For any of these reasons, direct end-to-end signature validation 112 and encryption are impossible. 114 3. Heterogeneous message formats: One organization using X.400 115 series protocols wishes to communicate with another using SMTP 116 [RFC5321]. Message reformatting at gateways makes end-to-end 117 encryption and signature validation impossible. 119 4. Heterogeneous message access methods: Users are accessing mail 120 using mechanisms which re-format messages, such as using Web 121 browsers. Message reformatting in the Message Store makes end- 122 to-end encryption and signature validation impossible. 124 5. Problems deploying fully S/MIME capable email clients on some 125 platforms. Signature verification at a border MTA can be coupled 126 with use of Authentication-Results header field [RFC7001] to 127 convey results of verification. 129 This document describes an approach to solving these problems by 130 providing message security services at the level of a domain or an 131 organization. This document specifies how these 'domain security 132 services' can be provided using the S/MIME protocol. Domain security 133 services may replace or complement mechanisms at the desktop/mobile 134 device. For example, a domain may decide to provide MUA-to-MUA 135 signatures but domain-to-domain encryption services. Or it may allow 136 MUA-to-MUA services for intra-domain use, but enforce domain-based 137 services for communication with other domains. 139 Domain services can also be used by individual members of a 140 corporation who are geographically remote and who wish to exchange 141 encrypted and/or signed messages with their base. 143 Whether or not a domain based service is inherently better or worse 144 than desktop based solutions is an open question. Some experts 145 believe that only end-to-end solutions can be truly made secure, 146 while others believe that the benefits offered by such things as 147 content checking at domain boundaries offers considerable increase in 148 practical security for many real systems. The additional service of 149 allowing signature checking at several points on a communications 150 path is also an extra benefit in many situations. This debate is 151 outside the scope of this document. What is offered here is a set of 152 tools that integrators can tailor in different ways to meet different 153 needs in different circumstances. 155 Message Transfer Agents (MTAs), guards, firewalls and protocol 156 translation gateways all provide domain security services. As with 157 MUA based solutions, these components must be resilient against a 158 wide variety of attacks intended to subvert the security services. 159 Therefore, careful consideration should be given to security of these 160 components, to make sure that their siting and configuration 161 minimises the possibility of attack. 163 2. Conventions Used in This Document 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 The signature type defined in this document are referred to as DOMSEC 170 defined signatures. 172 The term 'security domain' as used in this document is defined as a 173 collection of hardware and personnel operating under a single 174 security authority and performing a common business function. 175 Members of a security domain will of necessity share a high degree of 176 mutual trust, due to their shared aims and objectives. 178 A security domain is typically protected from direct outside attack 179 by physical measures and from indirect (electronic) attack by a 180 combination of firewalls and guards at network boundaries. The 181 interface between two security domains is termed a 'security 182 boundary'. One example of a security domain is an organizational 183 network ('Intranet'). 185 Message encryption may be performed by a third party on behalf of a 186 set of originators in a domain. This is referred to as domain 187 encryption. Message decryption may be performed by a third party on 188 behalf of a set of recipients in a domain. This is referred to as 189 domain decryption. The third party that performs these processes is 190 referred to in this section as a "Domain Confidentiality Authority" 191 (DCA). 193 2.1. Domain Signature 195 A domain signature is an S/MIME signature generated on behalf of a 196 set of users in a domain. A domain signature can be used to 197 authenticate information sent between domains or between a certain 198 domain and one of its individuals, for example, when two 'Intranets' 199 are connected using the Internet, or when an Intranet is connected to 200 a remote user over the Internet. It can be used when two domains 201 employ incompatible signature schemes internally or when there are no 202 certification links between their PKIs. In both cases messages from 203 the originator's domain are signed over the original message and 204 signature (if present) using an algorithm, key, and certificate which 205 can be processed by the recipient(s) or the recipient(s) domain. A 206 domain signature is sometimes referred to as an "organizational 207 signature". 209 2.2. Domain Encryption and Decryption 211 Domain encryption is S/MIME encryption performed on behalf of a 212 collection of users in a domain. Domain encryption can be used to 213 protect information between domains, for example, when two 214 'Intranets' are connected using the Internet. It can also be used 215 when end users do not have PKI/encryption capabilities at the 216 desktop, or when two domains employ incompatible encryption schemes 217 internally. In the latter case messages from the originator's domain 218 are encrypted (or re-encrypted) using an algorithm, key, and 219 certificate which can be decrypted by the recipient(s) or an entity 220 in their domain. This scheme also applies to protecting information 221 between a single domain and one of its members when both are 222 connected using an untrusted network, e.g., the Internet. 224 2.3. Signature Encapsulation 226 ESS [RFC2634] introduces the concept of triple-wrapped messages that 227 are first signed, then encrypted, then signed again. This document 228 also uses this concept of triple-wrapping. In addition, this 229 document also uses the concept of 'signature encapsulation'. 230 'Signature encapsulation' denotes a signed or unsigned message that 231 is wrapped in a signature, this signature covering both the content 232 and the first (inner) signature, if present. 234 Signature encapsulation can be performed on the inner and/or the 235 outer signature of a triple-wrapped message. 237 For example, the originator signs a message which is then 238 encapsulated with an 'additional attributes' signature. This is then 239 encrypted. A reviewer then signs this encrypted data, which is then 240 encapsulated by a domain signature. 242 There is a possibility that some policies will require signatures to 243 be added in a specific order. By only allowing signatures to be 244 added by encapsulation it is possible to determine the order in which 245 the signatures have been added. 247 A DOMSEC defined signature MAY encapsulate a message in one of the 248 following ways: 250 1. An unsigned message has an empty signature layer added to it 251 (i.e., the message is wrapped in a signedData that has a 252 signerInfos which contains no elements). This is to enable 253 backward compatibility with S/MIME software that does not have a 254 DOMSEC capability. Since the signerInfos will contain no signers 255 the eContentType, within the EncapsulatedContentInfo, MUST be id- 256 data as described in CMS [RFC5652]. However, the eContent field 257 will contain the unsigned message instead of being left empty as 258 suggested in section 5.2 in CMS [RFC5652]. This is so that when 259 the DOMSEC defined signature is added, as defined in method 2) 260 below, the signature will cover the unsigned message. 262 2. Signature Encapsulation is used to wrap the original signed 263 message with a DOMSEC defined signature. This is so that the 264 DOMSEC defined signature covers the message and all the 265 previously added signatures. Also, it is possible to determine 266 that the DOMSEC defined signature was added after the signatures 267 that are already there. 269 2.4. Naming Conventions 271 The subject name of the Originating S/MIME MSA/MTA's X.509 272 certificate is not restricted as specified in RFC 3183 [RFC3183]. In 273 order for a verifier to recognize a signing/encrypting certificate as 274 the Originating S/MIME MSA/MTA's certificate, it MUST contain 275 uniformResourceIdentifier GeneralName of the format "://" and/or dNSName of the format in its SubjectAltName [RFC5280]. (Here is the domain that is being served by the signing/ 279 encrypting MSA/MTA. is "submit" for MSAs and "smtp" for 280 MTAs.) 282 Any message received where the domain part of the domain signing 283 agent's name does not match, or is not an ascendant of, the 284 originator's domain name MUST be flagged to the user. 286 This naming rule prevents agents from one organization masquerading 287 as domain signing or encryption authorities on behalf of another. 288 For the other types of signature defined in future documents, no such 289 named mapping rule is defined. 291 Implementations conforming to this standard MUST support this naming 292 convention as a minimum. Implementations MAY choose to supplement 293 this convention with other locally defined conventions. However, 294 these MUST be agreed between sender and recipient domains prior to 295 secure exchange of messages. 297 On verifying the signature, a receiving agent MUST ensure that the 298 naming convention has been adhered to. Any message that violates the 299 convention MUST be flagged to the user. 301 Note that a X.509 certificate of a signing MSA/MTA can be 302 distinguished from a certificate of encrypting MSA/MTA by checking 303 for keyUsage. 305 3. MSA/MTA S/MIME signing 307 3.1. Naming Conventions and Signature Types 309 An entity receiving an S/MIME signed message would normally expect 310 the signature to be that of the originator of the message. However, 311 the message security services defined in this document require the 312 recipient to be able to accept messages signed by other entities and/ 313 or the originator. When other entities sign the message the name in 314 the certificate will not match the message sender's name. An S/MIME 315 compliant implementation would normally flag a warning if there were 316 a mismatch between the name in the certificate and the message 317 sender's name. (This check prevents a number of types of masquerade 318 attack.) 320 In the case of domain security services, this warning condition 321 SHOULD be suppressed under certain circumstances. These 322 circumstances are defined by a naming convention that specifies the 323 form that the signers name SHOULD adhere to. Adherence to this 324 naming convention avoids the problems of uncontrolled naming and the 325 possible masquerade attacks that this would produce. 327 As an assistance to implementation, a signed attribute is defined to 328 be included in the S/MIME signature - the 'signature type' attribute 329 Section 3.1.1. On receiving a message containing this attribute, the 330 naming convention (see Section 2.4) checks are invoked. 332 Implementations conforming to this standard MUST support the naming 333 convention specified in Section 2.4 for signature generation and 334 verification. Implementations conforming to this standard MUST 335 recognize the signature type attribute for signature verification. 336 Implementations conforming to this standard MUST support the 337 signature type attribute for signature generation. 339 3.1.1. Signature Type Attribute 341 An S/MIME signed attribute is used to indicate the type of signature. 342 This should be used in conjunction with the naming conventions 343 specified in the previous section. When an S/MIME signed message 344 containing the signature type attribute is received it triggers the 345 software to verify that the correct naming convention has been used. 347 The following object identifier identifies the SignatureType 348 attribute: 350 id-aa-signatureType OBJECT IDENTIFIER ::= { iso(1) 351 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 28 } 353 The ASN.1 [ASN.1] notation of this attribute is: - 355 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 357 id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 358 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 } 359 -- signature type identifier 361 If present, the SignatureType attribute MUST be a signed attribute, 362 as defined in [RFC5652]. If the SignatureType attribute is absent 363 and there are no further encapsulated signatures the recipient SHOULD 364 assume that the signature is that of the message originator. 366 All of the signatures defined here are generated and processed as 367 described in [RFC5652]. They are distinguished by the presence of 368 the following values in the SignatureType signed attribute: 370 id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } 371 -- domain signature. 373 A domain signature MUST encapsulate other signatures. Note a DOMSEC 374 defined signature could be encapsulating an empty signature as 375 defined in Section 2.3. 377 A SignerInfo MUST NOT include multiple instances of SignatureType. A 378 signed attribute representing a SignatureType MAY include multiple 379 instances of different SignatureType values as an AttributeValue of 380 attrValues [RFC5652], as long as the SignatureType 'additional 381 attributes' is not present. 383 If there is more than one SignerInfo in a signerInfos (i.e., when 384 different algorithms are used) then the SignatureType attribute in 385 all the SignerInfos MUST contain the same content. 387 3.2. Domain Signature Generation and Verification 389 A 'domain signature' is a proxy signature generated on a user's 390 behalf in the user's domain. The signature MUST adhere to the naming 391 conventions in Section 2.4. A 'domain signature' on a message 392 authenticates the fact that the message has been released from that 393 domain. Before signing, a process generating a 'domain signature' 394 MUST first satisfy itself of the authenticity of the message 395 originator. This is achieved by one of two methods. Either the 396 'originator's signature' is checked, if S/MIME signatures are used 397 inside a domain. Or if not, some mechanism external to S/MIME is 398 used, such as the physical address of the originating client or an 399 authenticated IP link, SMTP authentication credentials, etc. 401 If the originator's authenticity is successfully verified by one of 402 the above methods and all other signatures present are valid, 403 including those that have been encrypted, a 'domain signature' can be 404 added to a message. 406 If a 'domain signature' is added and the message is received by a 407 Mail List Agent (MLA) there is a possibility that the 'domain 408 signature' will be removed. To stop the 'domain signature' from 409 being removed the steps in Section 5 MUST be followed. 411 An entity generating a domain signature MUST do so using a 412 certificate containing a subject name that follows the naming 413 convention specified in Section 2.4. 415 If the originator's authenticity is not successfully verified or all 416 the signatures present are not valid, a 'domain signature' MUST NOT 417 be generated. 419 On reception, the 'domain signature' SHOULD be used to verify the 420 authenticity of a message. A check MUST be made to ensure that the 421 naming convention have been used as specified in this standard. 423 A recipient can assume that successful verification of the domain 424 signature also authenticates the message originator. 426 If there is an originator signature present, the name in that 427 certificate SHOULD be used to identify the originator. This 428 information can then be displayed to the recipient. 430 If there is no originator signature present, the only assumption that 431 can be made is the domain the message originated from. 433 A domain signer can be assumed to have verified any signatures that 434 it encapsulates. Therefore, it is not necessary to verify these 435 signatures before treating the message as authentic. However, this 436 standard does not preclude a recipient from attempting to verify any 437 other signatures that are present. 439 The 'domain signature' is indicated by the presence of the value id- 440 sti-domainSig in a 'signature type' signed attribute. 442 There MAY be one or more 'domain signature' signatures in an S/MIME 443 encoding. 445 4. MSA-to-MDA S/MIME Encryption and Decryption 447 Message encryption may be performed by a third party on behalf of a 448 set of originators in a domain. This is referred to as domain 449 encryption. Message decryption may be performed by a third party on 450 behalf of a set of recipients in a domain. This is referred to as 451 domain decryption. The third party that performs these processes is 452 referred to in this section as a "Domain Confidentiality Authority" 453 (DCA). Both of these processes are described in this section. 455 Messages may be encrypted for decryption by the final recipient and/ 456 or by a DCA in the recipient's domain. The message may also be 457 encrypted for decryption by a DCA in the originator's domain (e.g., 458 for content analysis, audit, key word scanning, etc.). The choice of 459 which of these is actually performed is a system specific issue that 460 depends on system security policy. It is therefore outside the scope 461 of this document. These processes of encryption and decryption 462 processes are shown in the following table. 464 +-----------------------+----------------------+-------------------+ 465 | | Recipient Decryption | Domain Decryption | 466 +-----------------------+----------------------+-------------------+ 467 | Originator Encryption | Case(a) | Case(b) | 468 | | | | 469 | Domain Encryption | Case(c) | Case(d) | 470 +-----------------------+----------------------+-------------------+ 472 Case (a), encryption of messages by the originator for decryption by 473 the final recipient(s), is described in CMS [RFC5652]. In cases (c) 474 and (d), encryption is performed not by the originator but by the DCA 475 in the originator's domain. In cases (b) and (d), decryption is 476 performed not by the recipient(s) but by the DCA in the recipient's 477 domain. 479 A client implementation that conforms to this standard MUST support 480 case (b) for transmission, case (c) for reception and case (a) for 481 transmission and reception. 483 A DCA implementation that conforms to this standard MUST support 484 cases (c) and (d), for transmission, and cases (b) and (d) for 485 reception. In cases (c) and (d) the 'domain signature' SHOULD be 486 applied before the encryption. In cases (b) and (d) the message 487 SHOULD be decrypted before the originators 'domain signature' is 488 obtained and verified. 490 The process of encryption and decryption is documented in CMS 491 [RFC5652]. The only additional requirement introduced by domain 492 encryption and decryption is for greater flexibility in the 493 management of keys, as described in the following subsections. As 494 with signatures, a naming convention is used to locate the correct 495 public key. 497 The mechanisms described below are applicable both to key agreement 498 and key transport systems, as documented in CMS [RFC5652]. The 499 phrase 'encryption key' is used as a collective term to cover the key 500 management keys used by both techniques. 502 The mechanisms below are also applicable to individual roving users 503 who wish to encrypt messages that are sent back to base. 505 4.1. Key Management for DCA Encryption 507 At the sender's domain, DCA encryption is achieved using the 508 recipient DCA's certificate or the end recipient's certificate. For 509 this, the encrypting process must be able to correctly locate the 510 certificate for the corresponding DCA in the recipient's domain or 511 the one corresponding to the end recipient. Having located the 512 correct certificate, the encryption process is then performed and 513 additional information required for decryption is conveyed to the 514 recipient in the recipientInfo field as specified in CMS [RFC5652]. 515 A DCA encryption agent MUST be named according to the naming 516 convention specified in Section 2.4. This is so that the 517 corresponding certificate can be found. 519 No specific method for locating the certificate to the corresponding 520 DCA in the recipient's domain or the one corresponding to the end 521 recipient is mandated in this document. An implementation may choose 522 to access a local certificate store to locate the correct 523 certificate. Alternatively, a X.500 or LDAP [RFC4510] directory may 524 be used in one of the following ways: 526 1. The directory may store the DCA certificate in the recipient's 527 directory entry. When the user certificate attribute is 528 requested, this certificate is returned. 530 2. The encrypting agent maps the recipient's name to the DCA name in 531 the manner specified in Section 2.4. ! The user certificate 532 attribute associated with this directory entry is then obtained. 534 This document does not mandate either of these processes. Whichever 535 one is used, the naming conventions must be adhered to, in order to 536 maintain confidentiality. 538 Having located the correct certificate, the encryption process is 539 then performed. A recipientInfo for the DCA or end recipient is then 540 generated, as described in CMS [RFC5652]. 542 DCA encryption may be performed for decryption by the end recipient 543 and/or by a DCA. End recipient decryption is described in CMS 544 [RFC5652]. DCA decryption is described in Section 4.2. 546 4.2. Key Management for DCA Decryption 548 DCA decryption uses a private-key belonging to the DCA and the 549 necessary information conveyed in the DCA's recipientInfo field. 551 It should be noted that domain decryption can be performed on 552 messages encrypted by the originator and/or by a DCA in the 553 originator's domain. In the first case, the encryption process is 554 described in CMS [RFC5652]; in the second case, the encryption 555 process is described in Section 4.1. 557 5. Applying a Domain Signature when Mail List Agents are Present 559 It is possible that a message leaving a DOMSEC domain may encounter a 560 Mail List Agent (MLA) before it reaches the final recipient. There 561 is a possibility that this would result in the 'domain signature' 562 being stripped off the message. We do not want a MLA to remove the 563 'domain signature'. Therefore, the 'domain signature' must be 564 applied to the message in such a way that will prevent a MLA from 565 removing it. 567 A MLA will search a message for the "outer" signedData layer, as 568 defined in ESS [RFC2634] section 4.2, and strip off all signedData 569 layers that encapsulate this "outer" signedData layer. Where this 570 "outer" signedData layer is found will depend on whether the message 571 contains a mlExpansionHistory attribute or an envelopedData layer. 573 There is a possibility that a message leaving a DOMSEC domain has 574 already been processed by a MLA, in which case a 'mlExpansionHistory' 575 attribute will be present within the message. 577 There is a possibility that the message will contain an envelopedData 578 layer. This will be the case when the message has been encrypted 579 within the domain for the domain's "Domain Confidentiality Authority" 580 (see Section 4), and, possibly, the final recipient. 582 How the 'domain signature' is applied will depend on what is already 583 present within the message. Before the 'domain signature' can be 584 applied the message MUST be searched for the "outer" signedData 585 layer, this search is complete when one of the following is found: 587 o The "outer" signedData layer that includes an mlExpansionHistory 588 attribute or encapsulates an envelopedData object. 590 o An envelopedData layer. 592 o The original content (that is, a layer that is neither 593 envelopedData nor signedData). 595 If a signedData layer containing a mlExpansionHistory attribute has 596 been found then: 598 1. Strip off the signedData layer (after remembering the included 599 signedAttributes). 601 2. Search the rest of the message until an envelopedData layer or 602 the original content is found. 604 3. 606 A. If an envelopedData layer has been found then: 608 + Strip off all the signedData layers down to the 609 envelopedData layer. 611 + Locate the RecipientInfo for the local DCA and use the 612 information it contains to obtain the message key. 614 + Decrypt the encryptedContent using the message key. 616 + Encapsulate the decrypted message with a 'domain 617 signature'. 619 + If local policy requires the message to be encrypted using 620 S/MIME encryption before leaving the domain then 621 encapsulate the 'domain signature' with an envelopedData 622 layer containing RecipientInfo structures for each of the 623 recipients and an originatorInfo value built from 624 information describing this DCA. 626 If local policy does not require the message to be 627 encrypted using S/MIME encryption but there is an 628 envelopedData at a lower level within the message then the 629 'domain signature' MUST be encapsulated by an 630 envelopedData as described above. 632 An example when it may not be local policy to require S/ 633 MIME encryption is when there is a link crypto present. 635 B. If an envelopedData layer has not been found then: 637 - Encapsulate the new message with a 'domain signature'. 639 4. Encapsulate the new message in a signedData layer, adding the 640 signedAttributes from the signedData layer that contained the 641 mlExpansionHistory attribute. 643 If no signedData layer containing a mlExpansionHistory attribute has 644 been found but an envelopedData has been found then: - 646 1. Strip off all the signedData layers down to the envelopedData 647 layer. 649 2. Locate the RecipientInfo for the local DCA and use the 650 information it contains to obtain the message key. 652 3. Decrypt the encryptedContent using the message key. 654 4. Encapsulate the decrypted message with a 'domain signature'. 656 5. If local policy requires the message to be encrypted before 657 leaving the domain then encapsulate the 'domain signature' with 658 an envelopedData layer containing RecipientInfo structures for 659 each of the recipients and an originatorInfo value built from 660 information describing this DCA. 662 6. If local policy does not require the message to be encrypted 663 using S/MIME encryption but there is an envelopedData at a lower 664 level within the message then the 'domain signature' MUST be 665 encapsulated by an envelopedData as described above. 667 If no signedData layer containing a mlExpansionHistory attribute has 668 been found and no envelopedData has been found then: - 670 1. Strip off all the signedData layers down to the envelopedData 671 Encapsulate the message in a 'domain signature'. 673 5.1. Examples of Rule Processing 675 The following examples help explain the above rules. All of the 676 signedData objects are valid and none of them are a domain signature. 677 If a signedData object was a domain signature then it would not be 678 necessary to validate any further signedData objects. 680 1. A message (S1 (Original Content)) (where S = signedData) in which 681 the signedData does not include an mlExpansionHistory attribute 682 is to have a 'domain signature' applied. The signedData, S1, is 683 verified. No "outer" signedData is found, after searching for 684 one as defined above, since the original content is found, nor is 685 an envelopedData or a mlExpansionHistory attribute found. A new 686 signedData layer, S2, is created that contains a 'domain 687 signature', resulting in the following message sent out of the 688 domain (S2 (S1 (Original Content))). 690 2. A message (S3 (S2 (S1 (Original Content))) in which none of the 691 signedData layers includes an mlExpansionHistory attribute is to 692 have a 'domain signature' applied. The signedData objects S1, S2 693 and S3 are verified. There is not an original, "outer" 694 signedData layer since the original content is found, nor is an 695 envelopedData or a mlExpansionHistory attribute found. A new 696 signedData layer, S4, is created that contains a 'domain 697 signature', resulting in the following message sent out of the 698 domain (S4 (S3 (S2 (S1 (Original Content))). 700 3. A message (E1 (S1 (Original Content))) (where E = envelopedData) 701 in which S1 does not include a mlExpansionHistory attribute is to 702 have a 'domain signature' applied. There is not an original, 703 received "outer" signedData layer since the envelopedData, E1, is 704 found at the outer layer. The encryptedContent is decrypted. 705 The signedData, S1, is verified. The decrypted content is 706 wrapped in a new signedData layer, S2, which contains a 'domain 707 signature'. If local policy requires the message to be 708 encrypted, using S/MIME encryption, before it leaves the domain 709 then this new message is wrapped in an envelopedData layer, E2, 710 resulting in the following message sent out of the domain (E2 (S2 711 (S1 (Original Content)))), else the message is not wrapped in an 712 envelopedData layer resulting in the following message (S2 (S1 713 (Original Content))) being sent. 715 4. A message (S2 (E1 (S1 (Original Content)))) in which S2 includes 716 a mlExpansionHistory attribute is to have a 'domain signature' 717 applied. The signedData object S2 is verified. The 718 mlExpansionHistory attribute is found in S2, so S2 is the "outer" 719 signedData. The signed attributes in S2 are remembered for later 720 inclusion in the new outer signedData that is applied to the 721 message. S2 is stripped off and the message is decrypted. The 722 signedData object S1 is verified. The decrypted message is 723 wrapped in a signedData layer, S3, which contains a 'domain 724 signature'. If local policy requires the message to be 725 encrypted, using S/MIME encryption, before it leaves the domain 726 then this new message is wrapped in an envelopedData layer, E2. 727 A new signedData layer, S4, is then wrapped around the 728 envelopedData, E2, resulting in the following message sent out of 729 the domain (S4 (E2 (S3 (S1 (Original Content))))). If local 730 policy does not require the message to be encrypted, using S/MIME 731 encryption, before it leaves the domain then the message is not 732 wrapped in an envelopedData layer but is wrapped in a new 733 signedData layer, S4, resulting in the following message sent out 734 of the domain (S4 (S3 (S1 (Original Content). The signedData S4, 735 in both cases, contains the signed attributes from S2. 737 5. A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of 738 the signedData layers include a mlExpansionHistory attribute is 739 to have a 'domain signature' applied. The signedData objects S3 740 and S2 are verified. When the envelopedData E1 is found the 741 signedData objects S3 and S2 are stripped off. The 742 encryptedContent is decrypted. The signedData object S1 is 743 verified. The decrypted content is wrapped in a new signedData 744 layer, S4, which contains a 'domain signature'. If local policy 745 requires the message to be encrypted, using S/MIME encryption, 746 before it leaves the domain then this new message is wrapped in 747 an envelopedData layer, E2, resulting in the following message 748 sent out of the domain (E2 (S4 (S1 (Original Content)))), else 749 the message is not wrapped in an envelopedData layer resulting in 750 the following message (S4 (S1 (Original Content))) being sent. 752 6. A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 753 includes a mlExpansionHistory attribute is to have a 'domain 754 signature' applied. The signedData objects S3 and S2 are 755 verified. The mlExpansionHistory attribute is found in S3, so S3 756 is the "outer" signedData. The signed attributes in S3 are 757 remembered for later inclusion in the new outer signedData that 758 is applied to the message. The signedData object S3 is stripped 759 off. When the envelopedData layer, E1, is found the signedData 760 object S2 is stripped off. The encryptedContent is decrypted. 761 The signedData object S1 is verified. The decrypted content is 762 wrapped in a new signedData layer, S4, which contains a 'domain 763 signature'. If local policy requires the message to be 764 encrypted, using S/MIME encryption, before it leaves the domain 765 then this new message is wrapped in an envelopedData layer, E2. 766 A new signedData layer, S5, is then wrapped around the 767 envelopedData, E2, resulting in the following message sent out of 768 the domain (S5 (E2 (S4 (S1 (Original Content))))). If local 769 policy does not require the message to be encrypted, using S/MIME 770 encryption, before it leaves the domain then the message is not 771 wrapped in an envelopedData layer but is wrapped in a new 772 signedData layer, S5, resulting in the following message sent out 773 of the domain (S5 (S4 (S1 (Original Content). The signedData S5, 774 in both cases, contains the signed attributes from S3. 776 7. A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3 777 does not include a mlExpansionHistory attribute is to have a 778 'domain signature' applied. The signedData object S3 is 779 verified. When the envelopedData E2 is found the signedData 780 object S3 is stripped off. The encryptedContent is decrypted. 781 The signedData object S2 is verified, the envelopedData E1 is 782 decrypted and the signedData object S1 is verified. The 783 signedData object S2 is wrapped in a new signedData layer S4, 784 which contains a 'domain signature'. Since there is an 785 envelopedData E1 lower down in the message, the new message is 786 wrapped in an envelopedData layer, E3, resulting in the following 787 message sent out of the domain (E3 (S4 (S2 (E1 (S1 (Original 788 Content)))))). 790 6. IANA Considerations 792 This document doesn't require any action from IANA. 794 7. Security Considerations 796 Implementations MUST protect all private keys. Compromise of the 797 signer's private key permits masquerade. 799 Similarly, compromise of the content-encryption key may result in 800 disclosure of the encrypted content. 802 Compromise of key material is regarded as an even more serious issue 803 for domain security services than for an S/MIME client. This is 804 because compromise of the private key may in turn compromise the 805 security of a whole domain. Therefore, great care should be used 806 when considering its protection. 808 Domain encryption alone is not secure and should be used in 809 conjunction with a domain signature to avoid a masquerade attack, 810 where an attacker that has obtained a DCA certificate can fake a 811 message to that domain pretending to be another domain. 813 When an encrypted DOMSEC message is sent to an end user in such a way 814 that the message is decrypted by the end users DCA the message will 815 be in plain text and therefore confidentiality could be compromised. 816 If the recipient's DCA is compromised then the recipient can not 817 guarantee the integrity of the message. Furthermore, even if the 818 recipient's DCA correctly verifies a message's signatures, then a 819 message could be undetectably modified, when there are no signatures 820 on a message that the recipient can verify. 822 8. References 824 8.1. Normative References 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, March 1997. 829 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 830 2634, June 1999. 832 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 833 RFC 5652, September 2009. 835 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 836 Housley, R., and W. Polk, "Internet X.509 Public Key 837 Infrastructure Certificate and Certificate Revocation List 838 (CRL) Profile", RFC 5280, May 2008. 840 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 841 Mail Extensions (S/MIME) Version 3.2 Certificate 842 Handling", RFC 5750, January 2010. 844 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 845 Mail Extensions (S/MIME) Version 3.2 Message 846 Specification", RFC 5751, January 2010. 848 [ASN.1] International Telecommunications Union, , "Open systems 849 interconnection: specification of Abstract Syntax Notation 850 (ASN.1)", CCITT Recommendation X.208, 1989. 852 8.2. Informative References 854 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 855 October 2008. 857 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 858 October 2008. 860 [RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S 861 /MIME", RFC 3183, October 2001. 863 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 864 (LDAP): Technical Specification Road Map", RFC 4510, June 865 2006. 867 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 868 Message Authentication Status", RFC 7001, September 2013. 870 Appendix A. Changes from RFC 3183 872 This document only includes domain signatures from RFC 3183 (i.e. 873 Additional Attributes Signatures and Review Signatures are not 874 mentioned). 876 Unlike RFC 3183, subject names of domain signing/encrypting X.509 877 certificates don't have to have a specific form. But Subject 878 Alternative Names need to include URIs for domain being protected. 880 Incorporated erratum 3757 resolution. 882 Updated references and some minor editorial corrections. 884 Appendix B. Acknowledgements 886 This document contains lots of text from RFC 3183. 888 Editors would like to thank Steve Kille and David Wilson for comments 889 and corrections. 891 Authors' Addresses 893 William Ottaway 894 QinetiQ 895 St. Andrews Road 896 Malvern, Worcs WR14 3PS 897 UK 899 EMail: wjottaway@QinetiQ.com 901 Alexey Melnikov (editor) 902 Isode Ltd 903 5 Castle Business Village 904 36 Station Road 905 Hampton, Middlesex TW12 2BX 906 UK 908 EMail: Alexey.Melnikov@isode.com