idnits 2.17.1 draft-ietf-smime-domsec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1060 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 900 has weird spacing: '...the new outer...' == Line 1043 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2633 (ref. '1') (Obsoleted by RFC 3851) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2630 (ref. '5') (Obsoleted by RFC 3369, RFC 3370) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT T Dean 2 draft-ietf-smime-domsec-08.txt W Ottaway 3 Expires 01 September 2001 DERA 5 Domain Security Services using S/MIME 7 Status of this memo 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of section 10 of RFC 2026. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 This document describes how the S/MIME protocol can be processed and 29 generated by a number of components of a communication system, such as 30 message transfer agents, guards and gateways to deliver security 31 services. These services are collectively referred to as 'Domain 32 Security Services'. The mechanisms described in this document are 33 designed to solve a number of interoperability problems and technical 34 limitations that arise when different security domains wish to 35 communicate securely, for example when two domains use incompatible 36 messaging technologies such as the X.400 series and SMTP/MIME, or when 37 a single domain wishes to communicate securely with one of its members 38 residing on an untrusted domain. The scenarios covered by this document 39 are domain-to-domain, individual-to-domain and domain-to-individual 40 communications. This document is also applicable to organisations and 41 enterprises that have internal PKIs which are not accessible by the 42 outside world, but wish to interoperate securely using the S/MIME 43 protocol. 45 This draft is being discussed on the 'ietf-smime' mailing list. To 46 subscribe, send a message to: 47 ietf-smime-request@imc.org 48 with the single word 49 subscribe 50 in the body of the message. There is a Web site for the mailing list at 51 . 53 Acknowledgements 55 Significant comments were made by Luis Barriga, Greg Colla, Trevor 56 Freeman, Russ Housley, Dave Kemp, Jim Schaad and Michael Zolotarev. 58 1. Introduction 60 The S/MIME [1] series of standards define a data encapsulation format 61 for the provision of a number of security services including data 62 integrity, confidentiality, and authentication. S/MIME is designed for 63 use by messaging clients to deliver security services to distributed 64 messaging applications. 66 There are many circumstances when it is not desirable or practical to 67 provide end-to-end (desktop-to-desktop) security services, particularly 68 between different security domains. An organisation that is considering 69 providing end-to-end security services will typically have to deal with 70 some if not all of the following issues: 72 1) Heterogeneous message access methods: Users are accessing mail using 73 mechanisms which re-format messages, such as using Web browsers. 74 Message reformatting in the Message Store makes end-to-end encryption 75 and signature validation impossible. 77 2) Message screening and audit: Server-based mechanisms such as 78 searching for prohibited words or other content, virus scanning, and 79 audit, are incompatible with end-to-end encryption. 81 3) PKI deployment issues: There may not be any certificate paths between 82 two organisations. Or an organisation may be sensitive about aspects 83 of its PKI and unwilling to expose them to outside access. Also, full 84 PKI deployment for all employees, may be expensive, not necessary or 85 impractical for large organisations. For any of these reasons, direct 86 end-to-end signature validation and encryption are impossible. 88 4) Heterogeneous message formats: One organisation using X.400 series 89 protocols wishes to communicate with another using SMTP. Message 90 reformatting at gateways makes end-to-end encryption and signature 91 validation impossible. 93 This document describes an approach to solving these problems by 94 providing message security services at the level of a domain or an 95 organisation. This document specifies how these 'domain security 96 services' can be provided using the S/MIME protocol. Domain security 97 services may replace or complement mechanisms at the desktop. For 98 example, a domain may decide to provide desktop-to-desktop signatures 99 but domain-to-domain encryption services. Or it may allow desktop-to- 100 desktop services for intra-domain use, but enforce domain-based services 101 for communication with other domains. 103 Domain services can also be used by individual members of a corporation 104 who are geographically remote and who wish to exchange encrypted and/or 105 signed messages with their base. 107 Whether or not a domain based service is inherently better or worse than 108 desktop based solutions is an open question. Some experts believe that 109 only end-to-end solutions can be truly made secure, while others believe 110 that the benefits offered by such things as content checking at domain 111 boundaries offers considerable increase in practical security for many 112 real systems. The additional service of allowing signature checking at 113 several points on a communications path is also an extra benefit in many 114 situations. This debate is outside the scope of this document. What is 115 offered here is a set of tools that integrators can tailor in different 116 ways to meet different needs in different circumstances. 118 Message transfer agents (MTAs), guards, firewalls and protocol 119 translation gateways all provide domain security services. As with 120 desktop based solutions, these components must be resilient against a 121 wide variety of attacks intended to subvert the security services. 122 Therefore, careful consideration should be given to security of these 123 components, to make sure that their siting and configuration minimises 124 the possibility of attack. 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [2]. 130 2. Overview of Domain Security Services 132 This section gives an informal overview of the security services that 133 are provided by S/MIME between different security domains. These 134 services are provided by a combination of mechanisms in the sender's and 135 recipient's domains. 137 Later sections describe definitively how these services map onto 138 elements of the S/MIME protocol. 140 The following security mechanisms are specified in this document: 142 1. Domain signature 143 2. Review signature 144 3. Additional attributes signature 145 4. Domain encryption and decryption 147 The signature types defined in this document are referred to as DOMSEC 148 defined signatures. 150 The term 'security domain' as used in this document is defined as a 151 collection of hardware and personnel operating under a single security 152 authority and performing a common business function. Members of a 153 security domain will of necessity share a high degree of mutual trust, 154 due to their shared aims and objectives. 156 A security domain is typically protected from direct outside attack by 157 physical measures and from indirect (electronic) attack by a combination 158 of firewalls and guards at network boundaries. The interface between two 159 security domains is termed a 'security boundary'. One example of a 160 security domain is an organisational network ('Intranet'). 162 2.1 Domain Signature 164 A domain signature is an S/MIME signature generated on behalf of a set 165 of users in a domain. A domain signature can be used to authenticate 166 information sent between domains or between a certain domain and one of 167 its individuals, for example, when two 'Intranets' are connected using 168 the Internet, or when an Intranet is connected to a remote user over the 169 Internet. It can be used when two domains employ incompatible signature 170 schemes internally or when there are no certification links between 171 their PKIs. In both cases messages from the originator's domain are 172 signed over the original message and signature (if present) using an 173 algorithm, key, and certificate which can be processed by the 174 recipient(s) or the recipient(s) domain. A domain signature is sometimes 175 referred to as an "organisational signature". 177 2.2 Review Signature 179 A third party may review messages before they are forwarded to the final 180 recipient(s) who may be in the same or a different security domain. 181 Organisational policy and good security practice often require that 182 messages be reviewed before they are released to external recipients. 183 Having reviewed a message, an S/MIME signature is added to it - a review 184 signature. An agent could check the review signature at the domain 185 boundary, to ensure that only reviewed messages are released. 187 2.3 Additional Attributes Signature 189 A third party can add additional attributes to a signed message. An 190 S/MIME signature is used for this purpose - an additional attributes 191 signature. An example of an additional attribute is the 'Equivalent 192 Label' attribute defined in ESS [3]. 194 2.4 Domain Encryption and Decryption 196 Domain encryption is S/MIME encryption performed on behalf of a 197 collection of users in a domain. Domain encryption can be used to 198 protect information between domains, for example, when two 'Intranets' 199 are connected using the Internet. It can also be used when end users do 200 not have PKI/encryption capabilities at the desktop, or when two 201 domains employ incompatible encryption schemes internally. In the latter 202 case messages from the originator's domain are encrypted (or 203 re-encrypted) using an algorithm, key, and certificate which can be 204 decrypted by the recipient(s) or an entity in their domain. This scheme 205 also applies to protecting information between a single domain and one 206 of its members when both are connected using an untrusted network, 207 e.g. the Internet. 209 3. Mapping of the Signature Services to the S/MIME Protocol 211 This section describes the S/MIME protocol elements that are used to 212 provide the security services described above. ESS [3] introduces the 213 concept of triple-wrapped messages that are first signed, then 214 encrypted, then signed again. This document also uses this concept of 215 triple-wrapping. In addition, this document also uses the concept of 216 'signature encapsulation'. 'Signature encapsulation' denotes a signed 217 or unsigned message that is wrapped in a signature, this signature 218 covering both the content and the first (inner) signature, if present. 220 Signature encapsulation MAY be performed on the inner and/or the outer 221 signature of a triple-wrapped message. 223 For example, the originator signs a message which is then encapsulated 224 with an 'additional attributes' signature. This is then encrypted. A 225 reviewer then signs this encrypted data, which is then encapsulated by 226 a domain signature. 228 There is a possibility that some policies will require signatures to be 229 added in a specific order. By only allowing signatures to be added by 230 encapsulation it is possible to determine the order in which the 231 signatures have been added. 233 A DOMSEC defined signature MAY encapsulate a message in one of the 234 following ways: 236 1) An unsigned message has an empty signature layer added to it (i.e. 237 the message is wrapped in a signedData that has a signerInfos which 238 contains no elements). This is to enable backward compatibility with 239 S/MIME software that does not have a DOMSEC capability. Since the 240 signerInfos will contain no signers the eContentType, within the 241 EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. 242 However, the eContent field will contain the unsigned message instead 243 of being left empty as suggested in section 5.2 in CMS [5]. This is 244 so that when the DOMSEC defined signature is added, as defined in 245 method 2) below, the signature will cover the unsigned message. 247 2) Signature Encapsulation is used to wrap the original signed message 248 with a DOMSEC defined signature. This is so that the DOMSEC defined 249 signature covers the message and all the previously added signatures. 250 Also, it is possible to determine that the DOMSEC defined signature 251 was added after the signatures that are already there. 253 3.1 Naming Conventions and Signature Types 255 An entity receiving an S/MIME signed message would normally expect the 256 signature to be that of the originator of the message. However, the 257 message security services defined in this document require the recipient 258 to be able to accept messages signed by other entities and/or the 259 originator. When other entities sign the message the name in the 260 certificate will not match the message sender's name. An S/MIME 261 compliant implementation would normally flag a warning if there were a 262 mismatch between the name in the certificate and the message sender's 263 name. (This check prevents a number of types of masquerade attack.) 265 In the case of domain security services, this warning condition SHOULD 266 be suppressed under certain circumstances. These circumstances are 267 defined by a naming convention that specifies the form that the signers 268 name SHOULD adhere to. Adherence to this naming convention avoids the 269 problems of uncontrolled naming and the possible masquerade attacks that 270 this would produce. 272 As an assistance to implementation, a signed attribute is defined to be 273 included in the S/MIME signature - the 'signature type' attribute. On 274 receiving a message containing this attribute, the naming convention 275 checks are invoked. 277 Implementations conforming to this standard MUST support the naming 278 convention for signature generation and verification. Implementations 279 conforming to this standard MUST recognise the signature type attribute 280 for signature verification. Implementations conforming to this standard 281 MUST support the signature type attribute for signature generation. 283 3.1.1 Naming Conventions 285 The following naming conventions are specified for agents generating 286 signatures specified in this document: 288 * For a domain signature, an agent generating this signature MUST be 289 named 'domain-signing-authority' 291 * For a review signature, an agent generating this signature MUST be 292 named 'review-authority'. 294 * For an additional attributes signature, an agent generating this 295 signature MUST be named 'attribute-authority'. 297 This name shall appear as the 'common name (CN)' component of the 298 subject field in the X.509 certificate. There MUST be only one CN 299 component present. Additionally, if the certificate contains an RFC 822 300 address, this name shall appear in the end entity component of the 301 address - on the left-hand side of the '@' symbol. 303 In the case of a domain signature, an additional naming rule is 304 defined: the 'name mapping rule'. The name mapping rule states that 305 for a domain signing authority, the domain part of its name MUST be the 306 same as, or an ascendant of, the domain name of the message 307 originator(s) that it is representing. The domain part is defined 308 as follows: 310 * In the case of an X.500 distinguished subject name of an X.509 311 certificate, the domain part is the country, organisation, 312 organisational unit, state, and locality components of the 313 distinguished name. 315 * In the case of an RFC 2247 distinguished name, the domain part 316 is the domain components of the distinguished name. 318 * If the certificate contains an RFC 822 address, the domain 319 part is defined to be the RFC 822 address component on the right- 320 hand side of the '@' symbol. 322 For example, a domain signing authority acting on behalf of John Doe of 323 the Acme corporation, whose distinguished name is 'cn=John Doe, 324 ou=marketing,o=acme,c=us' and whose e-mail address is 325 John.Doe@marketing.acme.com, could have a certificate containing a 326 distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and an 327 RFC 822 address of 'domain-signing-authority@acme.com'. If John Doe has 328 an RFC 2247 defined address of 'cn=John Doe,dc=marketing,dc=acme,dc=us' 329 then an address of 'cn=domain-signing-authority,dc=acme,dc=us' could be 330 used to represent the domain signing authority. 332 When the X.500 distinguished subject name has consecutive organisational 333 units and/or localities it is important to understand the ordering of 334 these values in order to determine if the domain part of the domain 335 signature is an ascendant. In this case, when parsing the distinguished 336 subject name from the most significant component (i.e. country, locality 337 or organisation) the parsed organisational unit or locality is deemed to 338 be the ascendant of consecutive (unparsed) organisational units or 339 localities. 341 When parsing an RFC 2247 subject name from the most significant 342 component (i.e. the 'dc' entry that represents the country, locality or 343 organisation) the parsed 'dc' entry is deemed to be the ascendant of 344 consecutive (unparsed) 'dc' entries. 346 For example, a domain signing authority acting on behalf of John Doe of 347 the Acme corporation, whose distinguished name is 'cn=John Doe, 348 ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is 349 John.Doe@marketing.defence.acme.com, could have a certificate containing 350 a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme, 351 c=us' and an RFC 822 address of 352 'domain-signing-authority@defence.acme.com'. If John Doe has an RFC 2247 353 defined address of 'cn=John Doe,dc=marketing,dc=defense,dc=acme,dc=us' 354 then the domain signing authority could have a distinguished name of 355 'cn=domain-signing-authority,dc=defence,dc=acme,dc=us'. 357 Any message received where the domain part of the domain signing agent's 358 name does not match, or is not an ascendant of, the originator's domain 359 name MUST be flagged. 361 This naming rule prevents agents from one organisation masquerading as 362 domain signing authorities on behalf of another. For the other types of 363 signature defined in this document, no such named mapping rule is 364 defined. 366 Implementations conforming to this standard MUST support this name 367 mapping convention as a minimum. Implementations MAY choose to 368 supplement this convention with other locally defined conventions. 369 However, these MUST be agreed between sender and recipient domains prior 370 to secure exchange of messages. 372 On verifying the signature, a receiving agent MUST ensure that the 373 naming convention has been adhered to. Any message that violates the 374 convention MUST be flagged. 376 3.1.2 Signature Type Attribute 378 An S/MIME signed attribute is used to indicate the type of signature. 379 This should be used in conjunction with the naming conventions specified 380 in the previous section. When an S/MIME signed message containing the 381 signature type attribute is received it triggers the software to verify 382 that the correct naming convention has been used. 384 The ASN.1 [4] notation of this attribute is: - 386 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 388 id-sti OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 389 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 9 } 390 -- signature type identifier 392 If present, the SignatureType attribute MUST be a signed attribute, as 393 defined in [5]. If the SignatureType attribute is absent and there are 394 no further encapsulated signatures the recipient SHOULD assume that the 395 signature is that of the message originator. 397 All of the signatures defined here are generated and processed as 398 described in [5]. They are distinguished by the presence of the 399 following values in the SignatureType signed attribute: 401 id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } 402 -- domain signature. 404 id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 } 405 -- additional attributes signature. 407 id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 } 408 -- review signature. 410 For completeness, an attribute type is also specified for an originator 411 signature. However, this signature type is optional. It is defined as 412 follows: 414 id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 } 415 -- originator's signature. 417 All signature types, except the originator type, MUST encapsulate other 418 signatures. Note a DOMSEC defined signature could be encapsulating an 419 empty signature as defined in section 3. 421 A SignerInfo MUST NOT include multiple instances of SignatureType. A 422 signed attribute representing a SignatureType MAY include multiple 423 instances of different SignatureType values as an AttributeValue of 424 attrValues [5], as long as the SignatureType 'additional attributes' is 425 not present. 427 If there is more than one SignerInfo in a signerInfos (i.e. when 428 different algorithms are used) then the SignatureType attribute in all 429 the SignerInfos MUST contain the same content. 431 The following sections describe the conditions under which each of these 432 types of signature may be generated, and how they are processed. 434 3.2 Domain Signature Generation and Verification 436 A 'domain signature' is a proxy signature generated on a user's behalf 437 in the user's domain. The signature MUST adhere to the naming 438 conventions in 3.1.1, including the name mapping convention. A 'domain 439 signature' on a message authenticates the fact that the message has 440 been released from that domain. Before signing, a process generating a 441 'domain signature' MUST first satisfy itself of the authenticity of the 442 message originator. This is achieved by one of two methods. Either the 443 'originator's signature' is checked, if S/MIME signatures are used 444 inside a domain. Or if not, some mechanism external to S/MIME is used, 445 such as the physical address of the originating client or an 446 authenticated IP link. 448 If the originator's authenticity is successfully verified by one of the 449 above methods and all other signatures present are valid, including 450 those that have been encrypted, a 'domain signature' can be added to a 451 message. 453 If a 'domain signature' is added and the message is received by a Mail 454 List Agent (MLA) there is a possibility that the 'domain signature' 455 will be removed. To stop the 'domain signature' from being removed the 456 steps in section 5 MUST be followed. 458 An entity generating a domain signature MUST do so using a certificate 459 containing a subject name that follows the naming convention specified 460 in 3.1.1. 462 If the originator's authenticity is not successfully verified or all 463 the signatures present are not valid, a 'domain signature' MUST NOT be 464 generated. 466 On reception, the 'domain signature' SHOULD be used to verify the 467 authenticity of a message. A check MUST be made to ensure that both the 468 naming convention and the name mapping convention have been used as 469 specified in this standard. 471 A recipient can assume that successful verification of the domain 472 signature also authenticates the message originator. 474 If there is an originator signature present, the name in that 475 certificate SHOULD be used to identify the originator. This information 476 can then be displayed to the recipient. 478 If there is no originator signature present, the only assumption that 479 can be made is the domain the message originated from. 481 A domain signer can be assumed to have verified any signatures that it 482 encapsulates. Therefore, it is not necessary to verify these signatures 483 before treating the message as authentic. However, this standard does 484 not preclude a recipient from attempting to verify any other signatures 485 that are present. 487 The 'domain signature' is indicated by the presence of the value 488 id-sti-domainSig in a 'signature type' signed attribute. 490 There MAY be one or more 'domain signature' signatures in an S/MIME 491 encoding. 493 3.3 Additional Attributes Signature Generation and Verification 495 The 'additional attributes' signature type indicates that the 496 SignerInfo contains additional attributes that are associated with the 497 message. 499 All attributes in the applicable SignerInfo MUST be treated as 500 additional attributes. Successful verification of an 'additional 501 attributes' signature means only that the attributes are authentically 502 bound to the message. A recipient MUST NOT assume that its successful 503 verification also authenticates the message originator. 505 An entity generating an 'additional attributes' signature MUST do so 506 using a certificate containing a subject name that follows the naming 507 convention specified in 3.1.1. On reception, a check MUST be made to 508 ensure that the naming convention has been used. 510 A signer MAY include any of the attributes listed in [3] or in this 511 document when generating an 'additional attributes' signature. The 512 following attributes have a special meaning, when present in an 513 'additional attributes' signature: 515 1) Equivalent Label: label values in this attribute are to be treated as 516 equivalent to the security label contained in an encapsulated 517 SignerInfo, if present. 519 2) Security Label: the label value indicates the aggregate sensitivity 520 of the inner message content plus any encapsulated signedData and 521 envelopedData containers. The label on the original data is indicated 522 by the value in the originator's signature, if present. 524 An 'additional attributes' signature is indicated by the presence of the 525 value id-sti-addAttribSig in a 'signature type' signed 526 attribute. Other Object Identifiers MUST NOT be included in the sequence 527 of OIDs if this value is present. 529 There MAY be multiple 'additional attributes' signatures in an S/MIME 530 encoding. 532 3.4 Review Signature Generation and Verification 534 The review signature indicates that the signer has reviewed the message. 535 Successful verification of a review signature means only that the signer 536 has approved the message for onward transmission to the recipient(s). 537 When the recipient is in another domain, a device on a domain boundary 538 such as a Mail Guard or firewall may be configured to check review 539 signatures. A recipient MUST NOT assume that its successful verification 540 also authenticates the message originator. 542 An entity generating a signed review signature MUST do so using a 543 certificate containing a subject name that follows the naming convention 544 specified in 3.1.1. On reception, a check MUST be made to ensure that 545 the naming convention has been used. 547 A review signature is indicated by the presence of the value 548 id-sti-reviewSig in a 'signature type' signed attribute. 550 There MAY be multiple review signatures in an S/MIME encoding. 552 3.5 Originator Signature 554 The 'originator signature' is used to indicate that the signer is the 555 originator of the message and its contents. It is included in this 556 document for completeness only. An originator signature is indicated 557 either by the absence of the signature type attribute, or by the 558 presence of the value id-sti-originatorSig in a 'signature type' 559 signed attribute. 561 4. Encryption and Decryption 563 Message encryption may be performed by a third party on behalf of a set 564 of originators in a domain. This is referred to as domain encryption. 565 Message decryption may be performed by a third party on behalf of a set 566 of recipients in a domain. This is referred to as domain decryption. 567 The third party that performs these processes is referred to in this 568 section as a "Domain Confidentiality Authority" (DCA). Both of these 569 processes are described in this section. 571 Messages may be encrypted for decryption by the final recipient and/or 572 by a DCA in the recipient's domain. The message may also be encrypted 573 for decryption by a DCA in the originator's domain (e.g. for content 574 analysis, audit, key word scanning, etc.). The choice of which of these 575 is actually performed is a system specific issue that depends on system 576 security policy. It is therefore outside the scope of this document. 577 These processes of encryption and decryption processes are shown in the 578 following table. 580 -------------------------------------------------------------------- 581 | | Recipient Decryption | Domain Decryption | 582 |------------------------|----------------------|--------------------| 583 | Originator Encryption | Case(a) | Case(b) | 584 | Domain Encryption | Case(c) | Case(d) | 585 -------------------------------------------------------------------- 587 Case (a), encryption of messages by the originator for decryption by the 588 final recipient(s), is described in CMS [5]. In cases (c) and (d), 589 encryption is performed not by the originator but by the DCA in the 590 originator's domain. In Cases (b) and (d), decryption is performed not 591 by the recipient(s) but by the DCA in the recipient's domain. 593 A client implementation that conforms to this standard MUST support 594 case (b) for transmission, case (c) for reception and case (a) for 595 transmission and reception. 597 A DCA implementation that conforms to this standard MUST support cases 598 (c) and (d), for transmission, and cases (b) and (d) for reception. In 599 cases (c) and (d) the 'domain signature' SHOULD be applied before the 600 encryption. In cases (b) and (d) the message SHOULD be decrypted before 601 the originators 'domain signature' is obtained and verified. 603 The process of encryption and decryption is documented in CMS [5]. The 604 only additional requirement introduced by domain encryption and 605 decryption is for greater flexibility in the management of keys, as 606 described in the following subsections. As with signatures, a naming 607 convention and name mapping convention are used to locate the correct 608 public key. 610 The mechanisms described below are applicable both to key agreement and 611 key transport systems, as documented in CMS [5]. The phrase 'encryption 612 key' is used as a collective term to cover the key management keys used 613 by both techniques. 615 The mechanisms below are also applicable to individual roving users who 616 wish to encrypt messages that are sent back to base. 618 4.1 Domain Confidentiality Naming Conventions 620 A DCA MUST be named 'domain-confidentiality-authority'. This name MUST 621 appear in the 'common name(CN)' component of the subject field in the 622 X.509 certificate. Additionally, if the certificate contains an RFC 822 623 address, this name MUST appear in the end entity part of the address, 624 i.e. on the left-hand side of the '@' symbol. 626 Along with this naming convention, an additional naming rule is defined: 627 the 'name mapping rule'. The name mapping rule states that for a DCA, 628 the domain part of its name MUST be the same as, or an ascendant of (as 629 defined in section 3.1.1), the domain name of the set of entities that 630 it represents. The domain part is defined as follows: 632 * In the case of an X.500 distinguished name of an X.509 certificate, 633 the domain part is the country, organisation, organisational 634 unit, state, and locality components of the distinguished name. 636 * In the case of an RFC 2247 distinguished name, the domain part 637 is the domain components of the distinguished name. 639 * If the certificate contains an RFC 822 address, the domain part is 640 defined to be the RFC 822 address part on the right-hand side of the 641 '@' symbol. 643 For example, a DCA acting on behalf of John Doe of the Acme 644 corporation, whose distinguished name is 'cn=John Doe, ou=marketing, 645 o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, 646 could have a certificate containing a distinguished name of 647 'cn=domain-confidentiality-authority,o=acme,c=us' and an e-mail 648 address of 'domain-confidentiality-authority@acme.com'. If John Doe 649 has an RFC 2247 defined address of 'cn=John Doe,dc=marketing, 650 dc=defense,dc=acme,dc=us' then the domain signing authority could have 651 a distinguished name of 'cn=domain-signing-authority,dc=defence,dc=acme, 652 dc=us'. The key associated with this certificate would be used for 653 encrypting messages for John Doe. 655 Any message received where the domain part of the domain encrypting 656 agents name does not match, or is not an ascendant of, the domain name 657 of the entities it represents MUST be flagged. 659 This naming rule prevents messages being encrypted for the wrong domain 660 decryption agent. 662 Implementations conforming to this standard MUST support this name 663 mapping convention as a minimum. Implementations may choose to 664 supplement this convention with other locally defined conventions. 665 However, these MUST be agreed between sender and recipient domains 666 prior to sending any messages. 668 4.2 Key Management for DCA Encryption 670 At the sender's domain, DCA encryption is achieved using the recipient 671 DCA's certificate or the end recipient's certificate. For this, the 672 encrypting process must be able to correctly locate the certificate for 673 the corresponding DCA in the recipient's domain or the one corresponding 674 to the end recipient. Having located the correct certificate, the 675 encryption process is then performed and additional information required 676 for decryption is conveyed to the recipient in the recipientInfo field 677 as specified in CMS [5]. A DCA encryption agent MUST be named according 678 to the naming convention specified in section 4.1. This is so that the 679 corresponding certificate can be found. 681 No specific method for locating the certificate to the corresponding 682 DCA in the recipient's domain or the one corresponding to the end 683 recipient is mandated in this document. An implementation may choose 684 to access a local certificate store to locate the correct certificate. 685 Alternatively, a X.500 or LDAP directory may be used in one of the 686 following ways: 688 1. The directory may store the DCA certificate in the recipient's 689 directory entry. When the user certificate attribute is requested, 690 this certificate is returned. 692 2. The encrypting agent maps the recipient's name to the DCA name in the 693 manner specified in 4.1. The user certificate attribute associated 694 with this directory entry is then obtained. 696 This document does not mandate either of these processes. Whichever one 697 is used, the name mapping conventions must be adhered to, in order to 698 maintain confidentiality. 700 Having located the correct certificate, the encryption process is then 701 performed. A recipientInfo for the DCA or end recipient is then 702 generated, as described in CMS [5]. 704 DCA encryption may be performed for decryption by the end recipient 705 and/or by a DCA. End recipient decryption is described in CMS [5]. DCA 706 decryption is described in section 4.3. 708 4.3 Key Management for DCA Decryption 710 DCA decryption uses a private-key belonging to the DCA and the necessary 711 information conveyed in the DCA's recipientInfo field. 713 It should be noted that domain decryption can be performed on messages 714 encrypted by the originator and/or by a DCA in the originator's domain. 715 In the first case, the encryption process is described in CMS [5]; in 716 the second case, the encryption process is described in 4.2. 718 5. Applying a Domain Signature when Mail List Agents are Present. 720 It is possible that a message leaving a DOMSEC domain may encounter a 721 Mail List Agent (MLA) before it reaches the final recipient. There is a 722 possibility that this would result in the 'domain signature' being 723 stripped off the message. We do not want a MLA to remove the 'domain 724 signature'. Therefore, the 'domain signature' must be applied to the 725 message in such a way that will prevent a MLA from removing it. 727 A MLA will search a message for the "outer" signedData layer, as defined 728 in ESS [3] section 4.2, and strip off all signedData layers that 729 encapsulate this "outer" signedData layer. Where this "outer" signedData 730 layer is found will depend on whether the message contains a 731 mlExpansionHistory attribute or an envelopedData layer. 733 There is a possibility that a message leaving a DOMSEC domain has 734 already been processed by a MLA, in which case a 'mlExpansionHistory' 735 attribute will be present within the message. 737 There is a possibility that the message will contain an envelopedData 738 layer. This will be the case when the message has been encrypted within 739 the domain for the domain's "Domain Confidentiality Authority", see 740 section 4.0, and, possibly, the final recipient. 742 How the 'domain signature' is applied will depend on what is already 743 present within the message. Before the 'domain signature' can be 744 applied the message MUST be searched for the "outer" signedData layer, 745 this search is complete when one of the following is found: - 747 - The "outer" signedData layer that includes an mlExpansionHistory 748 attribute or encapsulates an envelopedData object. 749 - An envelopedData layer. 750 - The original content (that is, a layer that is neither 751 envelopedData nor signedData. 753 If a signedData layer containing a mlExpansionHistory attribute has 754 been found then: - 756 1) Strip off the signedData layer (after remembering the included 757 signedAttributes). 759 2) Search the rest of the message until an envelopedData layer or 760 the original content is found. 762 3) a) If an envelopedData layer has been found then: - 764 - Strip off all the signedData layers down to the envelopedData 765 layer. 766 - Locate the RecipientInfo for the local DCA and use the 767 information it contains to obtain the message key. 768 - Decrypt the encryptedContent using the message key. 769 - Encapsulate the decrypted message with a 'domain 770 signature' 771 - If local policy requires the message to be encrypted using 772 S/MIME encryption before leaving the domain then encapsulate 773 the 'domain signature' with an envelopedData layer containing 774 RecipientInfo structures for each of the recipients and an 775 originatorInfo value built from information describing this 776 DCA. 778 If local policy does not require the message to be encrypted 779 using S/MIME encryption but there is an envelopedData at a 780 lower level within the message then the 'domain signature' 781 MUST be encapsulated by an envelopedData as described above. 783 An example when it may not be local policy to require S/MIME 784 encryption is when there is a link crypto present. 786 b) If an envelopedData layer has not been found then: - 788 - Encapsulate the new message with a 'domain signature'. 790 4) Encapsulate the new message in a signedData layer, adding the 791 signedAttributes from the signedData layer that contained the 792 mlExpansionHistory attribute. 794 If no signedData layer containing a mlExpansionHistory attribute has 795 been found but an envelopedData has been found then: - 797 1) Strip off all the signedData layers down to the envelopedData 798 layer. 799 2) Locate the RecipientInfo for the local DCA and use the information 800 it contains to obtain the message key. 801 3) Decrypt the encryptedContent using the message key. 802 4) Encapsulate the decrypted message with a 'domain signature' 803 5) If local policy requires the message to be encrypted before 804 leaving the domain then encapsulate the 'domain signature' with an 805 envelopedData layer containing RecipientInfo structures for each 806 of the recipients and an originatorInfo value built from 807 information describing this DCA. 809 If local policy does not require the message to be encrypted using 810 S/MIME encryption but there is an envelopedData at a lower level 811 within the message then the 'domain signature' MUST be 812 encapsulated by an envelopedData as described above. 814 If no signedData layer containing a mlExpansionHistory attribute has 815 been found and no envelopedData has been found then: - 817 1) Encapsulate the message in a 'domain signature'. 819 5.1 Examples of Rule Processing 821 The following examples help explain the above rules. All of the signedData 822 objects are valid and none of them are a domain signature. If a signedData 823 object was a domain signature then it would not be necessary to validate any 824 further signedData objects. 826 1) A message (S1 (Original Content)) (where S = signedData) in which the 827 signedData does not include an mlExpansionHistory attribute is to 828 have a 'domain signature' applied. The signedData, S1, is verified. 829 No "outer" signedData is found, after searching for one as defined 830 above, since the original content is found, nor is an envelopedData 831 or a mlExpansionHistory attribute found. A new signedData layer, S2, 832 is created that contains a 'domain signature', resulting in the 833 following message sent out of the domain (S2 (S1 (Original Content))). 835 2) A message (S3 (S2 (S1 (Original Content))) in which none of the 836 signedData layers includes an mlExpansionHistory attribute is to have 837 a 'domain signature' applied. The signedData objects S1, S2 and S3 838 are verified. There is not an original, "outer" signedData layer 839 since the original content is found, nor is an envelopedData or a 840 mlExpansionHistory attribute found. A new signedData layer, S4, is 841 created that contains a 'domain signature', resulting in the 842 following message sent out of the domain (S4 (S3 (S2 (S1 (Original 843 Content))). 845 3) A message (E1 (S1 (Original Content))) (where E = envelopedData) in 846 which S1 does not include a mlExpansionHistory attribute is to have 847 a 'domain signature' applied. There is not an original, received 848 "outer" signedData layer since the envelopedData, E1, is found at the 849 outer layer. The encryptedContent is decrypted. The signedData, S1, 850 is verified. The decrypted content is wrapped in a new signedData 851 layer, S2, which contains a 'domain signature'. If local policy 852 requires the message to be encrypted, using S/MIME encryption, before 853 it leaves the domain then this new message is wrapped in an 854 envelopedData layer, E2, resulting in the following message sent out 855 of the domain (E2 (S2 (S1 (Original Content)))), else the message is 856 not wrapped in an envelopedData layer resulting in the following 857 message (S2 (S1 (Original Content))) being sent. 859 4) A message (S2 (E1 (S1 (Original Content)))) in which S2 includes a 860 mlExpansionHistory attribute is to have a 'domain signature' 861 applied. The signedData object S2 is verified. The mlExpansionHistory 862 attribute is found in S2, so S2 is the "outer" signedData. The signed 863 attributes in S2 are remembered for later inclusion in the new outer 864 signedData that is applied to the message. S2 is stripped off and the 865 message is decrypted. The signedData object S1 is verified. The 866 decrypted message is wrapped in a signedData layer, S3, which 867 contains a 'domain signature'. If local policy requires the message 868 to be encrypted, using S/MIME encryption, before it leaves the 869 domain then this new message is wrapped in an envelopedData layer, 870 E2. A new signedData layer, S4, is then wrapped around the 871 envelopedData, E2, resulting in the following message sent out of 872 the domain (S4 (E2 (S3 (S1 (Original Content))))). If local policy 873 does not require the message to be encrypted, using S/MIME 874 encryption, before it leaves the domain then the message is not 875 wrapped in an envelopedData layer but is wrapped in a new signedData 876 layer, S4, resulting in the following message sent out of the domain 877 (S4 (S3 (S1 (Original Content). The signedData S4, in both cases, 878 contains the signed attributes from S2. 880 5) A message (S3 (S2 (E1 (S1 (Original Content))))) in which none of 881 the signedData layers include a mlExpansionHistory attribute is to 882 have a 'domain signature' applied. The signedData objects S3 and S2 883 are verified. When the envelopedData E1 is found the signedData 884 objects S3 and S2 are stripped off. The encryptedContent is 885 decrypted. The signedData object S1 is verified. The decrypted 886 content is wrapped in a new signedData layer, S4, which contains a 887 'domain signature'. If local policy requires the message to be 888 encrypted, using S/MIME encryption, before it leaves the domain 889 then this new message is wrapped in an envelopedData layer, E2, 890 resulting in the following message sent out of the domain (E2 (S4 891 (S1 (Original Content)))), else the message is not wrapped in an 892 envelopedData layer resulting in the following message (S4 (S1 893 (Original Content))) being sent. 895 6) A message (S3 (S2 (E1 (S1 (Original Content))))) in which S3 896 includes a mlExpansionHistory attribute is to have a 'domain 897 signature' applied. The signedData objects S3 and S2 are verified. 898 The mlExpansionHistory attribute is found in S3, so S3 is the 899 "outer" signedData. The signed attributes in S3 are remembered 900 for later inclusion in the new outer signedData that is applied to 901 the message. The signedData object S3 is stripped off. When the 902 envelopedData layer, E1, is found the signedData object S2 is 903 stripped off. The encryptedContent is decrypted. The signedData 904 object S1 is verified. The decrypted content is wrapped in a new 905 signedData layer, S4, which contains a 'domain signature'. If local 906 policy requires the message to be encrypted, using S/MIME encryption, 907 before it leaves the domain then this new message is wrapped in an 908 envelopedData layer, E2. A new signedData layer, S5, is then wrapped 909 around the envelopedData, E2, resulting in the following message sent 910 out of the domain (S5 (E2 (S4 (S1 (Original Content))))). If local 911 policy does not require the message to be encrypted, using S/MIME 912 encryption, before it leaves the domain then the message is not 913 wrapped in an envelopedData layer but is wrapped in a new signedData 914 layer, S5, resulting in the following message sent out of the domain 915 (S5 (S4 (S1 (Original Content). The signedData S5, in both cases, 916 contains the signed attributes from S3. 918 7) A message (S3 (E2 (S2 (E1 (S1 (Original Contnent)))))) in which S3 919 does not include a mlExpansionHistory attribute is to have a 920 'domain signature' applied. The signedData object S3 is verified. 921 When the envelopedData E2 is found the signedData object S3 is 922 stripped off. The encryptedContent is decrypted. The signedData 923 object S2 is verified, the envelopedData E1 is decrytped and the 924 signedData object S1 is verified. The signedData object S2 is 925 wrapped in a new signedData layer S4, which contains a 926 'domain signature'. Since there is an envelopedData E1 lower down 927 in the message, the new message is wrapped in an envelopedData 928 layer, E3, resulting in the following message sent out of the domain 929 (E3 (S4 (S2 (E1 (S1 (Original Content)))))). 931 6. Security Considerations 933 This specification relies on the existence of several well known names, 934 such as domain-confidentiality-authority. Organisations must take care 935 with these names, even if they do not support DOMSEC, so that 936 certificates issued in these names are only issued to legitimate 937 entities. If this is not true then an individual could get a certificate 938 associated with domain-confidentiality-authority@acme.com and as a 939 result might be able to read messages the a DOMSEC client intended for 940 others. 942 Implementations MUST protect all private keys. Compromise of the 943 signer's private key permits masquerade. 945 Similarly, compromise of the content-encryption key may result in 946 disclosure of the encrypted content. 948 Compromise of key material is regarded as an even more serious issue for 949 domain security services than for an S/MIME client. This is because 950 compromise of the private key may in turn compromise the security of a 951 whole domain. Therefore, great care should be used when considering its 952 protection. 954 Domain encryption alone is not secure and should be used in conjunction 955 with a domain signature to avoid a masquerade attack, where an attacker 956 that has obtained a DCA certificate can fake a message to that domain 957 pretending to be another domain. 959 7. DOMSEC ASN.1 Module 961 DOMSECSyntax 962 { iso(1) member-body(2) us(840) rsadsi(113549) 963 pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) } 965 DEFINITIONS IMPLICIT TAGS ::= 966 BEGIN 968 -- EXPORTS All 969 -- The types and values defined in this module are exported for 970 -- use in the other ASN.1 modules. Other applications may use 971 -- them for their own purposes. 973 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 975 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 976 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 } 978 id-sti OBJECT IDENTIFIER ::= { id-smime 9 } -- signature type 979 identifier 981 -- Signature Type Identifiers 983 id-sti-originatorSig OBJECT IDENTIFIER ::= { id-sti 1 } 984 id-sti-domainSig OBJECT IDENTIFIER ::= { id-sti 2 } 985 id-sti-addAttribSig OBJECT IDENTIFIER ::= { id-sti 3 } 986 id-sti-reviewSig OBJECT IDENTIFIER ::= { id-sti 4 } 988 END -- of DOMSECSyntax 990 8. References 992 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, 993 June 1999. 995 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 996 Levels", BCP 14, RFC 2119, March 1997. 998 [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, 999 June 1999. 1001 [4] International Telecommunications Union, Recommendation X.208, "Open 1002 systems interconnection: specification of Abstract Syntax Notation 1003 (ASN.1)", CCITT Blue Book, 1989. 1005 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 1007 9. Authors' Addresses 1009 Tim Dean 1010 DERA Malvern 1011 St. Andrews Road 1012 Malvern 1013 Worcs 1014 WR14 3PS 1016 Phone: +44 (0) 1684 894239 1017 Fax: +44 (0) 1684 896660 1018 Email: t.dean@eris.dera.gov.uk 1020 William Ottaway 1021 DERA Malvern 1022 St. Andrews Road 1023 Malvern 1024 Worcs 1025 WR14 3PS 1027 Phone: +44 (0) 1684 894079 1028 Fax: +44 (0) 1684 896660 1029 Email: w.ottaway@eris.dera.gov.uk 1031 10. Full Copyright Statement 1033 "Copyright (C) The Internet Society (2000). All Rights Reserved. 1035 This document and translations of it may be copied and furnished to 1036 others, and derivative works that comment on or otherwise explain it or 1037 assist in its implementation may be prepared, copied, published and 1038 distributed, in whole or in part, without restriction of any kind, 1039 provided that the above copyright notice and this paragraph are included 1040 on all such copies and derivative works. However, this document itself 1041 may not be modified in any way, such as by removing the copyright notice 1042 or references to the Internet Society or other Internet organizations, 1043 except as needed for the purpose of developing Internet standards in 1044 which case the procedures for copyrights defined in the Internet 1045 Standards process must be followed, or as required to translate it into 1046 languages other than English. 1048 The limited permissions granted above are perpetual and will not be 1049 revoked by the Internet Society or its successors or assigns. 1051 This document and the information contained herein is provided on an 1052 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1053 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1054 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1055 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1056 FITNESS FOR A PARTICULAR PURPOSE." 1058 This draft expires 01 September 2001