idnits 2.17.1 draft-melnikov-smime-msa-to-mda-04.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2014) is 3705 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 (~~), 2 warnings (==), 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: September 6, 2014 Isode Ltd 6 March 5, 2014 8 Domain-based signing and encryption using S/MIME 9 draft-melnikov-smime-msa-to-mda-04 11 Abstract 13 The S/MIME protocols Message Specification (RFC 5751), Cryptographic 14 Message Syntax (RFC 5652), S/MIME Certificate Handling (RFC 5750) and 15 Enhanced Security Services for S/MIME (RFC 2634) specify a consistent 16 way to securely send and receive MIME messages providing end to end 17 integrity, authentication, non-repudiation and confidentiality. This 18 document identifies a number of interoperability, technical, 19 procedural and policy related issues that may result in end-to-end 20 security services not being achievable. To resolve such issues, this 21 document profiles domain-based signing and encryption using S/MIME, 22 such as specifying how S/MIME signing and encryption can be applied 23 between a Message Submission Agent (MSA) and a Message Delivery Agent 24 (MDA) or between 2 Message Transfer Agents (MTA). 26 This document is also registering 2 URI scheme: "smtp" and "submit" 27 which are used for designating SMTP/SMTP Submission servers 28 (respectively), as well as SMTP/Submission client accounts. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 6, 2014. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 78 2.1. Domain Signature . . . . . . . . . . . . . . . . . . . . 6 79 2.2. Review Signature . . . . . . . . . . . . . . . . . . . . 6 80 2.3. Additional Attributes Signature . . . . . . . . . . . . . 6 81 2.4. Domain Encryption and Decryption . . . . . . . . . . . . 6 82 2.5. Signature Encapsulation . . . . . . . . . . . . . . . . . 7 83 2.6. Naming Conventions . . . . . . . . . . . . . . . . . . . 8 84 3. Domain-Based S/MIME Signing . . . . . . . . . . . . . . . . . 8 85 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 3.2. Signature Type Attribute . . . . . . . . . . . . . . . . 9 87 3.3. Domain Signature Generation and Verification . . . . . . 11 88 3.4. Additional Attributes Signature Generation and 89 Verification . . . . . . . . . . . . . . . . . . . . . . 12 90 3.5. Review Signature Generation and Verification . . . . . . 13 91 3.6. Originator Signature . . . . . . . . . . . . . . . . . . 13 92 3.7. Delegated Originator Signature . . . . . . . . . . . . . 13 93 4. Domain-based S/MIME Encryption and Decryption . . . . . . . . 14 94 4.1. Key Management for DCA Encryption . . . . . . . . . . . . 15 95 4.2. Key Management for DCA Decryption . . . . . . . . . . . . 16 96 5. Applying a Domain Signature when Mail List Agents are Present 16 97 5.1. Examples of Rule Processing . . . . . . . . . . . . . . . 19 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 6.1. SMTP URI registration . . . . . . . . . . . . . . . . . . 21 100 6.2. SUBMIT URI registration . . . . . . . . . . . . . . . . . 22 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 24 104 8.2. Informative References . . . . . . . . . . . . . . . . . 24 105 Appendix A. Changes from RFC 3183 . . . . . . . . . . . . . . . 26 106 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 The S/MIME [RFC5750][RFC5751] series of standards define a data 111 encapsulation format for the provision of a number of security 112 services including data integrity, confidentiality, and 113 authentication. S/MIME is designed for use by messaging clients to 114 deliver security services to distributed messaging applications. 116 The mechanisms described in this document are designed to solve a 117 number of interoperability problems and technical limitations that 118 arise when different security domains wish to communicate securely, 119 for example when two domains use incompatible messaging technologies 120 such as the X.400 series and SMTP/MIME [RFC5322], or when a single 121 domain wishes to communicate securely with one of its members 122 residing on an untrusted domain. The main scenario covered by this 123 document is domain-to-domain, although it is also applicable to 124 individual-to-domain and domain-to-individual communications. This 125 document is also applicable to organizations and enterprises that 126 have internal PKIs which are not accessible by the outside world, but 127 wish to interoperate securely using the S/MIME protocol. 129 There are many circumstances when it is not desirable or practical to 130 provide end-to-end (MUA-to-MUA) security services, particularly 131 between different security domains. An organization that is 132 considering providing end-to-end security services will typically 133 have to deal with some if not all of the following issues: 135 1. Message screening and audit: Server-based mechanisms such as 136 searching for prohibited words or other unauthorized content, 137 virus scanning, and audit, are incompatible with end-to-end 138 encryption. It is generally not acceptable to allow content in/ 139 out of an organization without checking, so boundary decryption 140 is vital. 142 2. PKI deployment issues: There may not be any certificate paths 143 between two organizations. Or an organization may be sensitive 144 about aspects of its PKI and unwilling to expose them to outside 145 access. Also, full PKI deployment for all employees, may be 146 expensive, not necessary or impractical for large organizations. 147 For any of these reasons, direct end-to-end signature validation 148 and encryption are impossible. 150 3. Heterogeneous message formats: One organization using X.400 151 series protocols wishes to communicate with another using SMTP 152 [RFC5321]. Message reformatting at gateways makes end-to-end 153 encryption and signature validation impossible. 155 4. Heterogeneous message access methods: Users are accessing mail 156 using mechanisms which re-format messages, such as using Web 157 browsers. Message reformatting in the Message Store makes end- 158 to-end encryption and signature validation impossible. 160 5. Problems deploying fully S/MIME capable email clients on some 161 platforms. Signature verification at a border MTA can be coupled 162 with use of Authentication-Results header field [RFC7001] to 163 convey results of verification. 165 This document describes an approach to solving these problems by 166 providing message security services at the level of a domain or an 167 organization. Such domain-based or organization-based message 168 security services are referred to as domain security services. This 169 document specifies how these 'domain security services' can be 170 provided using the S/MIME protocol. Domain security services may 171 replace or complement mechanisms at the desktop/mobile device. For 172 example, a domain may decide to provide MUA-to-MUA signatures but 173 domain-to-domain encryption services. Or it may allow MUA-to-MUA 174 services for intra-domain use, but enforce domain-based services for 175 communication with other domains. 177 Domain services can also be used by individual members of a 178 corporation who are geographically remote and who wish to exchange 179 encrypted and/or signed messages with their base. 181 Whether or not a domain based service is inherently better or worse 182 than desktop based solutions is an open question. Some experts 183 believe that only end-to-end solutions can be truly made secure, 184 while others believe that the benefits offered by such things as 185 content checking at domain boundaries offers considerable increase in 186 practical security for many real systems. The additional service of 187 allowing signature checking at several points on a communications 188 path is also an extra benefit in many situations. This debate is 189 outside the scope of this document. What is offered is a 190 specification for how domain-based S/MIME signing and encryption can 191 be applied in different ways to meet different needs in different 192 circumstances. 194 Message Transfer Agents (MTAs), Message Submission Agents (MSAs), 195 Message Delivery Agents (MDAs), guards, firewalls and protocol 196 translation gateways can provide domain security services. As with 197 MUA based solutions, these components must be resilient against a 198 wide variety of attacks intended to subvert the security services. 199 Therefore, careful consideration should be given to security of these 200 components, to make sure that their siting and configuration 201 minimises the possibility of attack. 203 2. Conventions Used in This Document 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 The signature types defined in this document are referred to as 210 DOMSEC defined signatures. 212 The term 'security domain' as used in this document is defined as a 213 collection of hardware and personnel operating under a single 214 security authority and performing a common business function. 215 Members of a security domain will of necessity share a high degree of 216 mutual trust, due to their shared aims and objectives. 218 A security domain is typically protected from direct outside attack 219 by physical measures and from indirect (electronic) attack by a 220 combination of firewalls and guards at network boundaries. The 221 interface between two security domains is termed a 'security 222 boundary'. One example of a security domain is an organizational 223 network ('Intranet'). 225 Domain-based Sending Agent - an MSA or sending domain MTA performing 226 Domain-based service(s). 228 Domain-based Receiving Agent - a receiving domain MTA or MDA 229 performing Domain-based service(s). 231 Message encryption may be performed by a third party on behalf of a 232 set of originators in a domain. This is referred to as domain 233 encryption. Message decryption may be performed by a third party on 234 behalf of a set of recipients in a domain. This is referred to as 235 domain decryption. The third party that performs these processes is 236 referred to in this document as a "Domain Confidentiality Authority" 237 (DCA). As per above, a DCA can be a Domain-based Sending Agent or a 238 Domain-based Receiving Agent. 240 2.1. Domain Signature 242 A domain signature is an S/MIME signature generated on behalf of a 243 set of users in a domain. A domain signature can be used to 244 authenticate information sent between domains or between a certain 245 domain and one of its individuals, for example, when two 'Intranets' 246 are connected using the Internet, or when an Intranet is connected to 247 a remote user over the Internet. It can be used when two domains 248 employ incompatible signature schemes internally or when there are no 249 certification links between their PKIs. In both cases messages from 250 the originator's domain are signed over the original message and 251 signature (if present) using an algorithm, key, and certificate which 252 can be processed by the recipient(s) or the recipient(s) domain. A 253 domain signature is sometimes referred to as an "organizational 254 signature". 256 2.2. Review Signature 258 A third party may review messages before they are forwarded to the 259 final recipient(s) who may be in the same or a different security 260 domain. Organizational policy and security practice often require 261 that messages be reviewed before they are released to external 262 recipients. Having reviewed a message, an S/MIME signature is added 263 to it - a review signature. An agent could check the review 264 signature at the domain boundary, to ensure that only reviewed 265 messages are released. 267 2.3. Additional Attributes Signature 269 A third party can add additional attributes to a signed message. An 270 S/MIME signature is used for this purpose - an additional attributes 271 signature. An example of an additional attribute is the 'Equivalent 272 Label' attribute defined in ESS [RFC2634]. 274 2.4. Domain Encryption and Decryption 276 Domain encryption is S/MIME encryption performed on behalf of a 277 collection of users in a domain. Domain encryption can be used to 278 protect information between domains, for example, when two 279 'Intranets' are connected using the Internet. It can also be used 280 when end users do not have PKI/encryption capabilities at the 281 desktop, or when two domains employ incompatible encryption schemes 282 internally. In the latter case messages from the originator's domain 283 are encrypted (or re-encrypted) using an algorithm, key, and 284 certificate which can be decrypted by the recipient(s) or an entity 285 in their domain. This scheme also applies to protecting information 286 between a single domain and one of its members when both are 287 connected using an untrusted network, e.g., the Internet. 289 2.5. Signature Encapsulation 291 ESS [RFC2634] introduces the concept of triple-wrapped messages that 292 are first signed, then encrypted, then signed again. This document 293 also uses this concept of triple-wrapping. In addition, this 294 document also uses the concept of 'signature encapsulation'. 295 'Signature encapsulation' denotes a signed or unsigned message that 296 is wrapped in a signature, this signature covering both the content 297 and the first (inner) signature, if present. 299 Signature encapsulation can be performed on the inner and/or the 300 outer signature of a triple-wrapped message. 302 For example, the originator signs a message which is then 303 encapsulated with an 'additional attributes' signature. This is then 304 encrypted. A reviewer then signs this encrypted data, which is then 305 encapsulated by a domain signature. 307 There is a possibility that some policies will require signatures to 308 be added in a specific order. By only allowing signatures to be 309 added by encapsulation it is possible to determine the order in which 310 the signatures have been added. 312 A DOMSEC defined signature MAY encapsulate a message in one of the 313 following ways: 315 1. An unsigned message has an empty signature layer added to it 316 (i.e., the message is wrapped in a signedData that has a 317 signerInfos which contains no elements). This is to enable 318 backward compatibility with S/MIME software that does not have a 319 DOMSEC capability. Since the signerInfos will contain no signers 320 the eContentType, within the EncapsulatedContentInfo, MUST be id- 321 data as described in CMS [RFC5652]. However, the eContent field 322 will contain the unsigned message instead of being left empty as 323 suggested in section 5.2 in CMS [RFC5652]. This is so that when 324 the DOMSEC defined signature is added, as defined in method 2) 325 below, the signature will cover the unsigned message. 327 2. Signature Encapsulation is used to wrap the original signed 328 message with a DOMSEC defined signature. This is so that the 329 DOMSEC defined signature covers the message and all the 330 previously added signatures. Also, it is possible to determine 331 that the DOMSEC defined signature was added after the signatures 332 that are already there. 334 2.6. Naming Conventions 336 The subject name of the Domain-based sending agent's X.509 337 certificate is not restricted as specified in RFC 3183 [RFC3183]. In 338 order for a verifier to recognize a signing/encrypting certificate as 339 the Domain-based sending agent's certificate, it MUST contain 340 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/ 344 encrypting MSA/MTA. is "submit" for MSAs and "smtp" for 345 MTAs.) 347 Any message received where the domain part of the domain signing 348 agent's name does not match, or is not an ascendant of, the 349 originator's domain name MUST be flagged to the user. 351 This naming rule prevents agents from one organization masquerading 352 as domain signing or encryption authorities on behalf of another. 353 For the other types of signature defined in future documents, no such 354 namin rule is defined. 356 Implementations conforming to this standard MUST support this naming 357 convention as a minimum. Implementations MAY choose to supplement 358 this convention with other locally defined conventions. However, 359 these MUST be agreed between sender and recipient domains prior to 360 secure exchange of messages. 362 On verifying the signature, a receiving agent MUST ensure that the 363 naming convention has been adhered to. Any message that violates the 364 convention MUST be flagged to the user. 366 Note that a X.509 certificate of a signing Domain-based sending agent 367 can be distinguished from a certificate of encrypting domain-based 368 sending agent by checking for keyUsage as specified in [RFC5280] 369 Section 4.2.1.3. 371 3. Domain-Based S/MIME Signing 373 3.1. General 375 An entity receiving an S/MIME signed message would normally expect 376 the signature to be that of the originator of the message. However, 377 the message security services defined in this document require the 378 recipient to be able to accept messages signed by other entities and/ 379 or the originator. When other entities sign the message the name in 380 the certificate will not match the message sender's name. An S/MIME 381 compliant implementation would normally flag a warning if there were 382 a mismatch between the name in the certificate and the message 383 sender's name. (This check prevents a number of types of masquerade 384 attack.) 386 In the case of domain security services, this warning condition 387 SHOULD be suppressed under certain circumstances. These 388 circumstances are defined by a naming convention that specifies the 389 form that the signers name SHOULD adhere to. Adherence to this 390 naming convention avoids the problems of uncontrolled naming and the 391 possible masquerade attacks that this would produce. 393 As an assistance to implementation, a signed attribute is defined to 394 be included in the S/MIME signature - the 'signature type' attribute 395 Section 3.2. On receiving a message containing this attribute, the 396 naming convention (see Section 2.6) checks are invoked. 398 Implementations conforming to this standard MUST support the naming 399 convention specified in Section 2.6 for signature generation and 400 verification. Implementations conforming to this standard MUST 401 recognize the signature type attribute for signature verification. 402 Implementations conforming to this standard MUST support the 403 signature type attribute for signature generation. 405 3.2. Signature Type Attribute 407 An S/MIME signed attribute is used to indicate the type of signature. 408 This should be used in conjunction with the naming conventions 409 specified in Section 2.6. When an S/MIME signed message containing 410 the signature type attribute is received it triggers the software to 411 verify that the correct naming convention has been used. 413 The following object identifier identifies the SignatureType 414 attribute: 416 id-aa-signatureType OBJECT IDENTIFIER ::= { iso(1) 417 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 28 } 419 The ASN.1 [ASN.1] notation of this attribute is: - 421 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 423 id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 424 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 } 425 -- signature type identifier 427 If present, the SignatureType attribute MUST be a signed attribute, 428 as defined in [RFC5652]. If the SignatureType attribute is absent 429 and there are no further encapsulated signatures the recipient SHOULD 430 assume that the signature is that of the message originator. 432 All of the signatures defined here are generated and processed as 433 described in [RFC5652]. They are distinguished by the presence of 434 the following values in the SignatureType signed attribute: 436 id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } 437 -- domain signature. 439 id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 } 440 -- additional attributes signature. 442 id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 } 443 -- review signature. 445 id-sti-delegatedOriginatorSig OBJECT IDENTIFIER ::= { id-sti 5 } 446 -- delegated originator signature. 448 For completeness, an attribute type is also specified for an 449 originator signature. However, this signature type is optional. It 450 is defined as follows: 452 id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 } 453 -- originator's signature. 455 All signature types, except the originator and the delegated 456 originator types, MUST encapsulate other signatures. Note a DOMSEC 457 defined signature could be encapsulating an empty signature as 458 defined in Section 2.5. 460 A SignerInfo MUST NOT include multiple instances of SignatureType. A 461 signed attribute representing a SignatureType MAY include multiple 462 instances of different SignatureType values as an AttributeValue of 463 attrValues [RFC5652], as long as the SignatureType 'additional 464 attributes' is not present. 466 If there is more than one SignerInfo in a signerInfos (i.e., when 467 different algorithms are used) then the SignatureType attribute in 468 all the SignerInfos MUST contain the same content. 470 The following sections describe the conditions under which each of 471 these types of signature may be generated, and how they are 472 processed. 474 3.3. Domain Signature Generation and Verification 476 A 'domain signature' is a signature generated on behalf of a set of 477 users who belong to the specific domain. The signature MUST adhere 478 to the naming conventions in Section 2.6. A 'domain signature' on a 479 message authenticates the fact that the message has been released 480 from that domain. (It also provides integrity and non-repudiation of 481 message between Domain-based Sending Agents and Receiving Agents.) 482 Before signing, a process generating a 'domain signature' MUST first 483 satisfy itself of the authenticity of the message originator. This 484 is achieved by one of two methods. Either the 'originator's 485 signature' is checked, if S/MIME signatures are used inside a domain. 486 Or if not, some mechanism external to S/MIME is used, such as SMTP 487 authentication credentials [RFC4954], authentication provided by 488 STARTTLS [RFC3207] (possibly combined with SMTP authentication), the 489 physical address of the originating client or an authenticated IP 490 link, etc. 492 If the originator's authenticity is successfully verified by one of 493 the above methods and all other signatures present are valid, 494 including those that have been encrypted, a 'domain signature' can be 495 added to a message. 497 If a 'domain signature' is added and the message is received by a 498 Mail List Agent (MLA) there is a possibility that the 'domain 499 signature' will be removed. To stop the 'domain signature' from 500 being removed the steps in Section 5 MUST be followed. 502 An entity generating a domain signature MUST do so using a 503 certificate containing a subject name that follows the naming 504 convention specified in Section 2.6. 506 If the originator's authenticity is not successfully verified or all 507 the signatures present are not valid, a 'domain signature' MUST NOT 508 be generated. 510 On reception, the 'domain signature' SHOULD be used to verify the 511 authenticity of a message. A check MUST be made to ensure that the 512 naming convention has been used as specified in Section 2.6. 514 A recipient can assume that successful verification of the domain 515 signature also authenticates the message originator. 517 If there is an originator signature present, the name in that 518 certificate SHOULD be used to identify the originator. This 519 information can then be displayed to the recipient. 521 If there is no originator signature present, the only assumption that 522 can be made is the domain the message originated from. 524 A domain signer can be assumed to have verified any signatures that 525 it encapsulates. Therefore, it is not necessary to verify these 526 signatures before treating the message as authentic. However, this 527 standard does not preclude a recipient from attempting to verify any 528 other signatures that are present. 530 The 'domain signature' is indicated by the presence of the value id- 531 sti-domainSig in a 'signature type' signed attribute. 533 There MAY be one or more 'domain signature' signatures in an S/MIME 534 encoding. 536 3.4. Additional Attributes Signature Generation and Verification 538 The 'additional attributes' signature type indicates that the 539 SignerInfo contains additional attributes that are associated with 540 the message. 542 All attributes in the applicable SignerInfo MUST be treated as 543 additional attributes. Successful verification of an 'additional 544 attributes' signature means only that the attributes are 545 authentically bound to the message. A recipient MUST NOT assume that 546 its successful verification also authenticates the message 547 originator. 549 An entity generating an 'additional attributes' signature MUST do so 550 using a certificate that follows the naming convention specified in 551 Section 2.6. On reception, a check MUST be made to ensure that the 552 naming convention has been used. 554 A signer MAY include any of the attributes listed in [RFC2634] or in 555 this document when generating an 'additional attributes' signature. 556 The following attributes have a special meaning, when present in an 557 'additional attributes' signature: 559 1. Equivalent Label: label values in this attribute are to be 560 treated as equivalent to the security label contained in an 561 encapsulated SignerInfo, if present. 563 2. Security Label: the label value indicates the aggregate 564 sensitivity of the inner message content plus any encapsulated 565 signedData and envelopedData containers. The label on the 566 original data is indicated by the value in the originator's 567 signature, if present. 569 An 'additional attributes' signature is indicated by the presence of 570 the value id-sti-addAttribSig in a 'signature type' signed attribute. 571 Other Object Identifiers MUST NOT be included in the sequence of OIDs 572 if this value is present. 574 There can be multiple 'additional attributes' signatures in an S/MIME 575 encoding. 577 3.5. Review Signature Generation and Verification 579 The review signature indicates that the signer has reviewed the 580 message. Successful verification of a review signature means only 581 that the signer has approved the message for onward transmission to 582 the recipient(s). When the recipient is in another domain, an agent 583 on a domain boundary such as a Mail Guard or firewall may be 584 configured to check review signatures. A recipient MUST NOT assume 585 that its successful verification also authenticates the message 586 originator. 588 An entity generating a review signature MUST do so using a 589 certificate that follows the naming convention specified in 590 Section 2.6. On reception, a check MUST be made to ensure that the 591 naming convention has been used. 593 A review signature is indicated by the presence of the value id-sti- 594 reviewSig in a 'signature type' signed attribute. 596 There can be multiple review signatures in an S/MIME encoding. 598 3.6. Originator Signature 600 The 'originator signature' is used to indicate that the signer is the 601 originator of the message and its contents. It is included in this 602 document for completeness only. An originator signature is indicated 603 either by the absence of the signature type attribute, or by the 604 presence of the value id-sti-originatorSig in a 'signature type' 605 signed attribute. 607 3.7. Delegated Originator Signature 609 The 'delegated originator signature' is similar to the 'domain 610 signature' (Section 3.3), but it also indicates that MSA signed 611 message with a unique originator-specific key. 613 If the originator's authenticity is successfully verified as 614 specified in Section 3.3 and all other signatures present are valid, 615 including those that have been encrypted, a 'delegated originator 616 signature' can be added to a message. 618 If a 'delegated originator signature' is added and the message is 619 received by a Mail List Agent (MLA) there is a possibility that the 620 'delegated originator signature' will be removed. To stop the 621 'delegated originator signature' from being removed the steps in 622 Section 5 MUST be followed. 624 An entity generating a delegated originator signature MUST do so 625 using a certificate that follows the naming convention specified in 626 Section 2.6. On reception, a check MUST be made to ensure that the 627 naming convention has been used. 629 If the originator's authenticity is not successfully verified or all 630 the signatures present are not valid, a 'delegated originator 631 signature' MUST NOT be generated. 633 A delegated originator signature is indicated by the presence of the 634 value id-sti-delegatedOriginatorSig in a 'signature type' signed 635 attribute. 637 4. Domain-based S/MIME Encryption and Decryption 639 Messages may be encrypted for decryption by the final recipient and/ 640 or by a DCA in the recipient's domain. The message may also be 641 encrypted for decryption by a DCA in the originator's domain (e.g., 642 for content analysis, audit, key word scanning, etc.). The choice of 643 which of these is actually performed is a system specific issue that 644 depends on system security policy. It is therefore outside the scope 645 of this document. These processes of encryption and decryption are 646 shown in the following table. 648 +-----------------------+----------------------+-------------------+ 649 | | Recipient Decryption | Domain Decryption | 650 +-----------------------+----------------------+-------------------+ 651 | Originator Encryption | Case(a) | Case(b) | 652 | | | | 653 | Domain Encryption | Case(c) | Case(d) | 654 +-----------------------+----------------------+-------------------+ 656 Case (a), encryption of messages by the originator for decryption by 657 the final recipient(s), is described in CMS [RFC5652]. In cases (c) 658 and (d), encryption is performed not by the originator but by the DCA 659 in the originator's domain. In cases (b) and (d), decryption is 660 performed not by the recipient(s) but by the DCA in the recipient's 661 domain. 663 A client implementation that conforms to this standard MUST support 664 case (b) for transmission, case (c) for reception and case (a) for 665 transmission and reception. 667 A DCA implementation that conforms to this standard MUST support 668 cases (c) and (d), for transmission, and cases (b) and (d) for 669 reception. In cases (c) and (d) the 'domain signature' SHOULD be 670 applied before the encryption. In cases (b) and (d) the message 671 SHOULD be decrypted before the originators 'domain signature' is 672 obtained and verified. 674 The process of encryption and decryption is documented in CMS 675 [RFC5652]. The only additional requirement introduced by domain 676 encryption and decryption is for greater flexibility in the 677 management of keys, as described in the following subsections. As 678 with signatures, a naming convention is used to locate the correct 679 public key. 681 The mechanisms described below are applicable both to key agreement 682 and key transport systems, as documented in CMS [RFC5652]. The 683 phrase 'encryption key' is used as a collective term to cover the key 684 management keys used by both techniques. 686 The mechanisms below are also applicable to individual roving users 687 who wish to encrypt messages that are sent back to base. 689 4.1. Key Management for DCA Encryption 691 At the sender's domain, DCA encryption is achieved using the 692 recipient DCA's certificate or the end recipient's certificate. For 693 this, the encrypting process must be able to correctly locate the 694 certificate for the corresponding DCA in the recipient's domain or 695 the one corresponding to the end recipient. Having located the 696 correct certificate, the encryption process is then performed and 697 additional information required for decryption is conveyed to the 698 recipient in the recipientInfo field as specified in CMS [RFC5652]. 699 A DCA encryption agent MUST be named according to the naming 700 convention specified in Section 2.6. This is so that the 701 corresponding certificate can be found. 703 No specific method for locating the certificate to the corresponding 704 DCA in the recipient's domain or the one corresponding to the end 705 recipient is mandated in this document. An implementation may choose 706 to access a local certificate store to locate the correct 707 certificate. Alternatively, a X.500 or LDAP [RFC4510] directory may 708 be used in one of the following ways: 710 1. The directory may store the DCA certificate in the recipient's 711 directory entry. When the user certificate attribute is 712 requested, this certificate is returned. 714 2. The encrypting agent maps the recipient's name to the DCA name in 715 the manner specified in Section 2.6. The user certificate 716 attribute associated with the DCA's directory entry is then 717 obtained. 719 This document does not mandate either of these processes. Whichever 720 one is used, the naming conventions must be adhered to, in order to 721 maintain confidentiality. 723 Having located the correct certificate, the encryption process is 724 then performed. A recipientInfo for the DCA or end recipient is then 725 generated, as described in CMS [RFC5652]. 727 DCA encryption may be performed for decryption by the end recipient 728 and/or by a DCA. End recipient decryption is described in CMS 729 [RFC5652]. DCA decryption is described in Section 4.2. 731 4.2. Key Management for DCA Decryption 733 DCA decryption uses a private-key belonging to the DCA and the 734 necessary information conveyed in the DCA's recipientInfo field. 736 It should be noted that domain decryption can be performed on 737 messages encrypted by the originator and/or by a DCA in the 738 originator's domain. In the first case, the encryption process is 739 described in CMS [RFC5652]; in the second case, the encryption 740 process is described in Section 4.1. 742 5. Applying a Domain Signature when Mail List Agents are Present 744 It is possible that a message leaving a DOMSEC domain may encounter a 745 Mail List Agent (MLA) before it reaches the final recipient. There 746 is a possibility that this would result in the 'domain signature' 747 being stripped off the message. We do not want a MLA to remove the 748 'domain signature'. Therefore, the 'domain signature' must be 749 applied to the message in such a way that will prevent a MLA from 750 removing it. 752 A MLA will search a message for the "outer" signedData layer, as 753 defined in ESS [RFC2634] section 4.2, and strip off all signedData 754 layers that encapsulate this "outer" signedData layer. Where this 755 "outer" signedData layer is found will depend on whether the message 756 contains a mlExpansionHistory attribute or an envelopedData layer. 758 There is a possibility that a message leaving a DOMSEC domain has 759 already been processed by a MLA, in which case a 'mlExpansionHistory' 760 attribute will be present within the message. 762 There is a possibility that the message will contain an envelopedData 763 layer. This will be the case when the message has been encrypted 764 within the domain for the domain's "Domain Confidentiality Authority" 765 (see Section 4), and, possibly, the final recipient. 767 How the 'domain signature' is applied will depend on what is already 768 present within the message. Before the 'domain signature' can be 769 applied the message MUST be searched for the "outer" signedData 770 layer, this search is complete when one of the following is found: 772 o The "outer" signedData layer that includes an mlExpansionHistory 773 attribute or encapsulates an envelopedData object. 775 o An envelopedData layer. 777 o The original content (that is, a layer that is neither 778 envelopedData nor signedData). 780 If a signedData layer containing a mlExpansionHistory attribute has 781 been found, then: 783 1. Strip off the signedData layer (after remembering the included 784 signedAttributes). 786 2. Search the rest of the message until an envelopedData layer or 787 the original content is found. 789 3. 791 A. If an envelopedData layer has been found, then: 793 + Strip off all the signedData layers down to the 794 envelopedData layer. 796 + Locate the RecipientInfo for the local DCA and use the 797 information it contains to obtain the message key. 799 + Decrypt the encryptedContent using the message key. 801 + Encapsulate the decrypted message with a 'domain 802 signature'. 804 + If local policy requires the message to be encrypted using 805 S/MIME encryption before leaving the domain then 806 encapsulate the 'domain signature' with an envelopedData 807 layer containing RecipientInfo structures for each of the 808 recipients and an originatorInfo value built from 809 information describing this DCA. 811 If local policy does not require the message to be 812 encrypted using S/MIME encryption but there is an 813 envelopedData at a lower level within the message then the 814 'domain signature' MUST be encapsulated by an 815 envelopedData as described above. 817 An example when it may not be local policy to require S/ 818 MIME encryption is when there is a link crypto present. 820 B. If an envelopedData layer has not been found, then: 822 - Encapsulate the new message with a 'domain signature'. 824 4. Encapsulate the new message in a signedData layer, adding the 825 signedAttributes from the signedData layer that contained the 826 mlExpansionHistory attribute. 828 If no signedData layer containing a mlExpansionHistory attribute has 829 been found but an envelopedData has been found, then: - 831 1. Strip off all the signedData layers down to the envelopedData 832 layer. 834 2. Locate the RecipientInfo for the local DCA and use the 835 information it contains to obtain the message key. 837 3. Decrypt the encryptedContent using the message key. 839 4. Encapsulate the decrypted message with a 'domain signature'. 841 5. If local policy requires the message to be encrypted before 842 leaving the domain then encapsulate the 'domain signature' with 843 an envelopedData layer containing RecipientInfo structures for 844 each of the recipients and an originatorInfo value built from 845 information describing this DCA. 847 6. If local policy does not require the message to be encrypted 848 using S/MIME encryption but there is an envelopedData at a lower 849 level within the message then the 'domain signature' MUST be 850 encapsulated by an envelopedData as described above. 852 If no signedData layer containing a mlExpansionHistory attribute has 853 been found and no envelopedData has been found, then: - 855 1. Strip off all the signedData layers down to the envelopedData 856 Encapsulate the message in a 'domain signature'. 858 5.1. Examples of Rule Processing 860 The following examples help explain the above rules. All of the 861 signedData objects are valid and none of them are a domain signature. 862 If a signedData object was a domain signature then it would not be 863 necessary to validate any further signedData objects. 865 1. A message (S1 (Original Content)) (where S = signedData) in which 866 the signedData does not include an mlExpansionHistory attribute 867 is to have a 'domain signature' applied. The signedData, S1, is 868 verified. No "outer" signedData is found, after searching for 869 one as defined above, since the original content is found, nor is 870 an envelopedData or a mlExpansionHistory attribute found. A new 871 signedData layer, S2, is created that contains a 'domain 872 signature', resulting in the following message sent out of the 873 domain (S2 (S1 (Original Content))). 875 2. A message (S3 (S2 (S1 (Original Content))) in which none of the 876 signedData layers includes an mlExpansionHistory attribute is to 877 have a 'domain signature' applied. The signedData objects S1, S2 878 and S3 are verified. There is not an original, "outer" 879 signedData layer since the original content is found, nor is an 880 envelopedData or a mlExpansionHistory attribute found. A new 881 signedData layer, S4, is created that contains a 'domain 882 signature', resulting in the following message sent out of the 883 domain (S4 (S3 (S2 (S1 (Original Content))). 885 3. A message (E1 (S1 (Original Content))) (where E = envelopedData) 886 in which S1 does not include a mlExpansionHistory attribute is to 887 have a 'domain signature' applied. There is not an original, 888 received "outer" signedData layer since the envelopedData, E1, is 889 found at the outer layer. The encryptedContent is decrypted. 890 The signedData, S1, is verified. The decrypted content is 891 wrapped in a new signedData layer, S2, which contains a 'domain 892 signature'. If local policy requires the message to be 893 encrypted, using S/MIME encryption, before it leaves the domain 894 then this new message is wrapped in an envelopedData layer, E2, 895 resulting in the following message sent out of the domain (E2 (S2 896 (S1 (Original Content)))), else the message is not wrapped in an 897 envelopedData layer resulting in the following message (S2 (S1 898 (Original Content))) being sent. 900 4. A message (S2 (E1 (S1 (Original Content)))) in which S2 includes 901 a mlExpansionHistory attribute is to have a 'domain signature' 902 applied. The signedData object S2 is verified. The 903 mlExpansionHistory attribute is found in S2, so S2 is the "outer" 904 signedData. The signed attributes in S2 are remembered for later 905 inclusion in the new outer signedData that is applied to the 906 message. S2 is stripped off and the message is decrypted. The 907 signedData object S1 is verified. The decrypted message is 908 wrapped in a signedData layer, S3, which contains a 'domain 909 signature'. If local policy requires the message to be 910 encrypted, using S/MIME encryption, before it leaves the domain 911 then this new message is wrapped in an envelopedData layer, E2. 912 A new signedData layer, S4, is then wrapped around the 913 envelopedData, E2, resulting in the following message sent out of 914 the domain (S4 (E2 (S3 (S1 (Original Content))))). If local 915 policy does not require the message to be encrypted, using S/MIME 916 encryption, before it leaves the domain then the message is not 917 wrapped in an envelopedData layer but is wrapped in a new 918 signedData layer, S4, resulting in the following message sent out 919 of the domain (S4 (S3 (S1 (Original Content). The signedData S4, 920 in both cases, contains the signed attributes from S2. 922 5. A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of 923 the signedData layers include a mlExpansionHistory attribute is 924 to have a 'domain signature' applied. The signedData objects S3 925 and S2 are verified. When the envelopedData E1 is found the 926 signedData objects S3 and S2 are stripped off. The 927 encryptedContent is decrypted. The signedData object S1 is 928 verified. The decrypted content is wrapped in a new signedData 929 layer, S4, which contains a 'domain signature'. If local policy 930 requires the message to be encrypted, using S/MIME encryption, 931 before it leaves the domain then this new message is wrapped in 932 an envelopedData layer, E2, resulting in the following message 933 sent out of the domain (E2 (S4 (S1 (Original Content)))), else 934 the message is not wrapped in an envelopedData layer resulting in 935 the following message (S4 (S1 (Original Content))) being sent. 937 6. A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 938 includes a mlExpansionHistory attribute is to have a 'domain 939 signature' applied. The signedData objects S3 and S2 are 940 verified. The mlExpansionHistory attribute is found in S3, so S3 941 is the "outer" signedData. The signed attributes in S3 are 942 remembered for later inclusion in the new outer signedData that 943 is applied to the message. The signedData object S3 is stripped 944 off. When the envelopedData layer, E1, is found the signedData 945 object S2 is stripped off. The encryptedContent is decrypted. 946 The signedData object S1 is verified. The decrypted content is 947 wrapped in a new signedData layer, S4, which contains a 'domain 948 signature'. If local policy requires the message to be 949 encrypted, using S/MIME encryption, before it leaves the domain 950 then this new message is wrapped in an envelopedData layer, E2. 951 A new signedData layer, S5, is then wrapped around the 952 envelopedData, E2, resulting in the following message sent out of 953 the domain (S5 (E2 (S4 (S1 (Original Content))))). If local 954 policy does not require the message to be encrypted, using S/MIME 955 encryption, before it leaves the domain then the message is not 956 wrapped in an envelopedData layer but is wrapped in a new 957 signedData layer, S5, resulting in the following message sent out 958 of the domain (S5 (S4 (S1 (Original Content). The signedData S5, 959 in both cases, contains the signed attributes from S3. 961 7. A message (S3 (E2 (S2 (E1 (S1 (Original Content)))))) in which S3 962 does not include a mlExpansionHistory attribute is to have a 963 'domain signature' applied. The signedData object S3 is 964 verified. When the envelopedData E2 is found the signedData 965 object S3 is stripped off. The encryptedContent is decrypted. 966 The signedData object S2 is verified, the envelopedData E1 is 967 decrypted and the signedData object S1 is verified. The 968 signedData object S2 is wrapped in a new signedData layer S4, 969 which contains a 'domain signature'. Since there is an 970 envelopedData E1 lower down in the message, the new message is 971 wrapped in an envelopedData layer, E3, resulting in the following 972 message sent out of the domain (E3 (S4 (S2 (E1 (S1 (Original 973 Content)))))). 975 6. IANA Considerations 977 This document registers 2 URI schemes, described in subsections of 978 this section. IANA is requested to add them to the list of Permanent 979 URI schemes. 981 6.1. SMTP URI registration 983 URI scheme name: smtp 985 Status: permanent 987 URI scheme syntax: 988 smtpuri = "smtp://" authority ["/" [ "?" query ]] 989 authority = 990 query = 991 If : is omitted from authority, the port defaults to 25. 992 The query component is reserved for future extensions. 994 URI scheme semantics: 995 The smtp: URI scheme is used to designate SMTP servers (e.g. 996 listener endpoints, S/MIME agents performing Domain signing), SMTP 997 accounts. 998 There is no MIME type associated with this URI. 1000 Encoding considerations: 1002 SMTP user names are UTF-8 strings and MUST be percent-encoded as 1003 required by the URI specification [RFC3986], Section 2.1. 1005 Applications/protocols that use this URI scheme name: 1006 The smtp: URI is intended to be used by applications that might 1007 need access to an SMTP server (for example email clients or MTAs) 1008 or for SMTP servers to describe their listener endpoints. 1010 Interoperability considerations: 1011 Several implementations are already using smtp: URIs for server 1012 configuration. 1014 Security considerations: Clients resolving smtp: URIs that wish to 1015 achieve data confidentiality and/or integrity SHOULD use the 1016 STARTTLS command (if supported by the server) before starting 1017 authentication, or use a SASL mechanism, such as GSSAPI, that 1018 provides a confidentiality security layer. 1020 Contact: Alexey Melnikov 1022 Author/Change controller: IESG 1024 References: [[This document]] and [RFC5321]. 1026 6.2. SUBMIT URI registration 1028 URI scheme name: submit 1030 Status: permanent 1032 URI scheme syntax: 1033 submituri = "submit://" authority ["/" [ "?" query ]] 1034 authority = 1035 query = 1036 If : is omitted from authority, the port defaults to 587. 1037 The query component is reserved for future extensions. 1039 URI scheme semantics: 1040 The submit: URI scheme is used to designate SMTP Submission 1041 servers (e.g. listener endpoints, S/MIME agents performing Domain 1042 signing), SMTP accounts. 1043 There is no MIME type associated with this URI. 1045 Encoding considerations: 1046 SMTP user names are UTF-8 strings and MUST be percent-encoded as 1047 required by the URI specification [RFC3986], Section 2.1. 1049 Applications/protocols that use this URI scheme name: 1050 The submit: URI is intended to be used by applications that might 1051 need access to an SMTP Submission server (for example email 1052 clients) or for SMTP Submission servers to describe their listener 1053 endpoints. 1055 Interoperability considerations: 1056 None. 1058 Security considerations: Clients resolving submit: URIs that wish 1059 to achieve data confidentiality and/or integrity SHOULD use the 1060 STARTTLS command (if supported by the server) before starting 1061 authentication, or use a SASL mechanism, such as GSSAPI, that 1062 provides a confidentiality security layer. 1064 Contact: Alexey Melnikov 1066 Author/Change controller: IESG 1068 References: [[This document]] and [RFC6409]. 1070 7. Security Considerations 1072 Implementations MUST protect all private keys. Compromise of the 1073 signer's private key permits masquerade attacks. 1075 Similarly, compromise of the content-encryption key may result in 1076 disclosure of the encrypted content. 1078 Compromise of key material is regarded as an even more serious issue 1079 for domain security services than for an S/MIME client. This is 1080 because compromise of the private key may in turn compromise the 1081 security of a whole domain. Therefore, great care should be used 1082 when considering its protection. 1084 Domain encryption alone is not secure and should be used in 1085 conjunction with a domain signature to avoid a masquerade attack, 1086 where an attacker that has obtained a DCA certificate can fake a 1087 message to that domain pretending to be another domain. 1089 When an encrypted DOMSEC message is sent to an end user in such a way 1090 that the message is decrypted by the end users DCA the message will 1091 be in plain text and therefore confidentiality could be compromised. 1092 If the recipient's DCA is compromised then the recipient can not 1093 guarantee the integrity of the message. Furthermore, even if the 1094 recipient's DCA correctly verifies a message's signatures, then a 1095 message could be undetectably modified, when there are no signatures 1096 on a message that the recipient can verify. 1098 8. References 1100 8.1. Normative References 1102 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1103 Requirement Levels", BCP 14, RFC 2119, March 1997. 1105 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 1106 2634, June 1999. 1108 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1109 RFC 5652, September 2009. 1111 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1112 Housley, R., and W. Polk, "Internet X.509 Public Key 1113 Infrastructure Certificate and Certificate Revocation List 1114 (CRL) Profile", RFC 5280, May 2008. 1116 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1117 Mail Extensions (S/MIME) Version 3.2 Certificate 1118 Handling", RFC 5750, January 2010. 1120 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1121 Mail Extensions (S/MIME) Version 3.2 Message 1122 Specification", RFC 5751, January 2010. 1124 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1125 October 2008. 1127 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1128 STD 72, RFC 6409, November 2011. 1130 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1131 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1132 3986, January 2005. 1134 [ASN.1] International Telecommunications Union, , "Open systems 1135 interconnection: specification of Abstract Syntax Notation 1136 (ASN.1)", CCITT Recommendation X.208, 1989. 1138 8.2. Informative References 1140 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 1141 Transport Layer Security", RFC 3207, February 2002. 1143 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1144 for Authentication", RFC 4954, July 2007. 1146 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 1147 October 2008. 1149 [RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S 1150 /MIME", RFC 3183, October 2001. 1152 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol 1153 (LDAP): Technical Specification Road Map", RFC 4510, June 1154 2006. 1156 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 1157 Message Authentication Status", RFC 7001, September 2013. 1159 Appendix A. Changes from RFC 3183 1161 Unlike RFC 3183, subject names of domain signing/encrypting X.509 1162 certificates don't have to have a specific form. But Subject 1163 Alternative Names need to include URIs for domain being protected. 1165 A new signature type was added for the case when MSA signs/encrypts a 1166 message on behalf of a user with a user specific key. 1168 Incorporated erratum 3757 resolution. 1170 Updated references and some minor editorial corrections. 1172 Appendix B. Acknowledgements 1174 This document contains lots of text from RFC 3183. 1176 Editors would like to thank Steve Kille, David Wilson, Alan Ross and 1177 Vijay K. Gurbani for comments and corrections. 1179 Authors' Addresses 1181 William Ottaway 1182 QinetiQ 1183 St. Andrews Road 1184 Malvern, Worcs WR14 3PS 1185 UK 1187 EMail: wjottaway@QinetiQ.com 1189 Alexey Melnikov (editor) 1190 Isode Ltd 1191 5 Castle Business Village 1192 36 Station Road 1193 Hampton, Middlesex TW12 2BX 1194 UK 1196 EMail: Alexey.Melnikov@isode.com