idnits 2.17.1 draft-ietf-smime-domsec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. == 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 687 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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: 6 errors (**), 0 flaws (~~), 3 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-03.txt W Ottaway 3 Expires 19th April 2000 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 RFC2026. 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 X.400 and SMTP/MIME. This document is 37 also applicable to organisations and enterprises that have internal PKIs 38 which are not accessible by the outside world, but wish to interoperate 39 securely using the S/MIME protocol. 41 This draft is being discussed on the 'ietf-smime' mailing list. To 42 subscribe, send a message to: 43 ietf-smime-request@imc.org 44 with the single word 45 subscribe 46 in the body of the message. There is a Web site for the mailing list at 47 . 49 Acknowledgements 51 Significant comments were made by Trevor Freeman, Russ Housley, 52 Dave Kemp, Jim Schaad, Greg Colla and Michael Zolotarev. 54 1. Introduction 56 The S/MIME [1] series of standards define a data encapsulation format 57 for the provision of a number of security services including data 58 integrity, confidentiality, and authentication. S/MIME is designed for 59 use by messaging clients to deliver security services to distributed 60 messaging applications. 62 There are many circumstances when it is not desirable or practical to 63 provide end-to-end (desktop-to-desktop) security services, particularly 64 between different security domains. An organisation that is considering 65 providing end-to-end security services will typically have to deal with 66 some if not all of the following issues: 68 1) Heterogeneous Message Access Methods: Users are accessing mail using 69 mechanisms which re-format messages, such as using Web browsers. 70 Message reformatting in the Message Store makes end-to-end encryption 71 and signature validation impossible. 73 2) Message screening and audit: Server-based mechanisms such as 74 searching for prohibited words or other content, virus scanning, and 75 audit, are incompatible with end-to-end encryption. 77 3) PKI deployment issues: There may not be any certificate paths between 78 two organisations. Or an organisation may be sensitive about aspects 79 of its PKI and unwilling to expose them to outside access. For either 80 of these reasons, direct end-to-end signature validation and 81 encryption are impossible. 83 4) Heterogeneous Message transports: One organisation using X.400 wishes 84 to communicate with another using SMTP. Message reformatting at 85 gateways makes end-to-end encryption and signature validation 86 impossible. 88 This document describes an approach to solving these problems by 89 providing message security services at the level of a domain or an 90 organisation. This document specifies how these 'domain security 91 services' can be provided using the S/MIME protocol. Domain security 92 services may replace or complement mechanisms at the desktop. For 93 example, a domain may decide to provide desktop-to-desktop signatures 94 but domain-to-domain encryption services. Or it may allow desktop-to- 95 desktop services for intra-domain use, but enforce domain-based services 96 for communication with other domains. 98 Whether or not a domain based service is inherently better or worse than 99 desktop based solutions is an open question. Some experts believe that 100 only end-to-end solutions can be truly made secure, while others believe 101 that the benefits offered by such things as content checking at domain 102 boundaries offers considerable increase in practical security for many 103 real systems. The additional service of allowing signature checking at 104 several points on a communications path is also an extra benefit in many 105 situations. This debate is outside the scope of this document. What is 106 offered here is a set of tools that integrators can tailor in different 107 ways to meet different needs in different circumstances. 109 Message transfer agents (MTAs), guards, firewalls and protocol 110 translation gateways all provide domain security services. As with 111 desktop based solutions, these components must be resilient against a 112 wide variety of attacks intended to subvert the security services. 113 Therefore, careful consideration should be given to security of these 114 components, to make sure that their siting and configuration minimises 115 the possibility of attack. 117 Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD are used 118 in capital letters. This conforms to the definitions in [2]. 120 2. Overview of Domain Security Services 122 This section gives an informal overview of the security services that 123 are provided by S/MIME between different security domains. These 124 services are provided by a combination of mechanisms in the sender's and 125 recipient's domains. 127 Later sections describe definitively how these services map onto 128 elements of the S/MIME protocol. 130 The following security mechanisms are specified in this document: 132 1. Domain signature 133 2. Review signature 134 3. Additional attributes signature 135 4. Domain encryption and decryption 137 The term 'security domain' as used in this document is defined as a 138 collection of hardware and personnel operating under a single security 139 authority and performing a common business function. Members of a 140 security domain will of necessity share a high degree of mutual trust, 141 due to their shared aims and objectives. 143 A security domain is typically protected from direct outside attack by 144 physical measures and from indirect (electronic) attack by a combination 145 of firewalls and guards at network boundaries. The interface between two 146 security domains is termed a 'security boundary'. One example of a 147 security domain is an organisational network ('Intranet'). 149 2.1 Domain Signature 151 A Domain signature is an S/MIME signature generated on behalf of a set 152 of users in a domain. A Domain signature can be used to authenticate 153 information sent between domains, for example, when two 'Intranets' are 154 connected using the Internet. It can be used when two domains employ 155 incompatible signature schemes internally or when there are no 156 certification links between their PKIs. In both cases messages from the 157 originator's domain are signed over the original message and signature 158 (if present) using an algorithm, key, and certificate which can be 159 processed by the recipient(s). A domain signature is sometimes referred 160 to as an "organisational signature". 162 2.2 Review Signature 164 A third party may review messages before they are forwarded to the final 165 recipient(s) who may be in the same or a different security domain. 166 Organisational policy and good security practice often require that 167 messages be reviewed before they are released to external recipients. 168 Having reviewed a message, an S/MIME signature is added to it - a review 169 signature. An agent MAY check the review signature at the domain 170 boundary, to ensure that only reviewed messages are released. 172 2.3 Additional Attributes Signature 174 A third party MAY add additional attributes to a signed message. An 175 S/MIME signature is used for this purpose - an additional attributes 176 signature. An example of an additional attribute is the 'Equivalent 177 Label' attribute defined in ESS [3]. 179 2.4 Domain Encryption and Decryption 181 Domain encryption is S/MIME encryption performed on behalf of a 182 collection of users in a domain. Domain encryption can be used to 183 protect information between domains, for example, when two 'Intranets' 184 are connected using the Internet. It can also be used when end users do 185 not have encryption capabilities at the desktop, or when two domains 186 employ incompatible encryption schemes internally. In the latter case 187 messages from the originator's domain are re-encrypted using an 188 algorithm, key, and certificate which can be decrypted by the 189 recipient(s) or an entity in their domain. 191 3. Mapping of the Signature Services to the S/MIME Protocol 193 This section describes the S/MIME Protocol elements that are used to 194 provide the security services described above. ESS [3] introduces the 195 concept of triple-wrapped messages that are first signed, then 196 encrypted, then signed again. This document also uses this concept of 197 triple-wrapping. In addition, this document also uses the concept of 198 'signature encapsulation'. 'Signature encapsulation' denotes a complete 199 signed message that is wrapped in a second signature, the second 200 signature covering both the content and the first (inner) signature. 202 Signature Encapsulation MAY be performed on the inner and/or the outer 203 signature of a triple-wrapped message. The term 'parallel signatures' 204 means two or more signatures calculated over the same content. This 205 capability is described in CMS [3], where a set of one or more 206 SignerInfos can be attached to signed data. 208 For example, the originator signs a message which is then encapsulated 209 with an 'additional attributes' signature. This is then encrypted. A 210 reviewer then signs this encrypted data, which is then encapsulated by 211 a domain signature. 213 3.1 Naming conventions and Signature Types 215 An entity receiving an S/MIME signed message would normally expect the 216 signature to be that of the originator of the message. However, the 217 message security services defined in this draft require the recipient to 218 be able accept messages signed by other entities and the originator. 219 When other entities sign the message the name in the certificate will 220 not match the message senders name. An S/MIME implementation would flag 221 an error if there were a mismatch between the name in the certificate 222 and the message sender's name. (This check prevents a number of types of 223 masquerade attack.) 225 To resolve this incompatibility, this document defines a naming 226 convention that specifies the form that the signing agents name SHOULD 227 take. Adherence to this naming convention avoids the problems of 228 uncontrolled naming and the possible masquerade attacks that this would 229 produce. 231 As an assistance to implementation, a signed attribute is defined to be 232 included in the S/MIME signature - the 'signature type' attribute. On 233 receiving a message containing this attribute, the naming convention 234 checks are invoked. 236 Implementations conforming to this standard MUST support the naming 237 convention for signature generation and verification. Implementations 238 conforming to this standard MUST recognise the signature type attribute 239 for signature verification. Implementations conforming to this standard 240 SHOULD support the signature type attribute for signature generation; 241 however, this is not mandated. 243 3.1.1 Naming conventions 245 The following naming conventions are specified for agents generating 246 signatures specified in this document: 248 * For a domain signature, an agent generating this signature MUST be 249 named 'domain-signing-authority' 251 * For a review signature, an agent generating this signature MUST be 252 named 'review-authority'. 254 * For an additional attributes signature, an agent generating this 255 signature MUST be named 'attribute-authority'. 257 This name shall appear in the 'common name (CN)' component of the 258 subject field in the X.509 certificate. Additionally, if the 259 certificate contains an SMTP e-mail address, this name shall appear in 260 the end entity component of the address - on the left-hand side of the 261 '@' symbol. 263 In the case of a domain signature, an additional naming rule is 264 defined: the 'name mapping rule'. The name mapping rule states that 265 for a domain signing authority, the domain component of its name MUST be 266 the same as, or an ascendant of, the domain name of the message 267 originator(s) that it is representing. The domain component is defined 268 as follows: 270 * In the case of an X.500 distinguished subject name of an X.509 271 certificate, the domain component is the country, organisation, 272 organisational unit, state, and locality components of the 273 distinguished name. 275 * If the certificate contains an SMTP e-mail address, the domain 276 component is defined to be the SMTP address component on the right- 277 hand side of the '@' symbol. 279 For example, a domain signing authority acting on behalf of John Doe of 280 the Acme corporation, whose distinguished name is 'cn=John Doe, 281 ou=marketing,o=acme,c=us' and whose e-mail address is 282 John.Doe@marketing.acme.com, could have a certificate containing a 283 distinguished name of 'cn=domain-signing-authority, o=acme,c=us' and an 284 e-mail address of 'domain-signing-authority@acme.com'. 286 Any message received where the domain component of the domain signing 287 agents name does not match, or is not an ascendant of, the originator's 288 domain name MUST be rejected. 290 This naming rule prevents agents from one organisation masquerading as 291 domain signing authorities on behalf of another. For the other types of 292 signature defined in this document, no such named mapping rule is 293 defined. 295 Implementations conforming to this standard MUST support this name 296 mapping convention as a minimum. Implementations MAY choose to 297 supplement this convention with other locally defined conventions. 298 However, these MUST be agreed between sender and recipient domains prior 299 to secure exchange of messages. 301 On verifying the signature, a receiving agent MUST ensure that the 302 naming convention has been adhered to. Any message that violates the 303 convention shall be rejected as invalid. 305 3.1.2 Signature type attribute 307 An S/MIME authenticated attribute is also used to indicate the type of 308 signature. This should be used in conjunction with the naming 309 conventions specified in the previous section. When an S/MIME signed 310 message containing the signature type attribute is received it triggers 311 the software to verify that the correct naming convention has been used. 313 The ASN.1 [4] notation of this attribute is: - 315 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 317 id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) 318 us (840) rsadsi (113549) } 320 If present, the SignatureType attribute MUST be an authenticated 321 attribute, as defined in [5]. If the SignatureType attribute is absent 322 the recipient SHOULD assume that the signature is that of the message 323 originator. 325 Each of the signature types defined here are generated and processed 326 exactly as described in [5]. They are distinguished by the presence of 327 the following values in the SignatureType authenticated attribute: 329 id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } for a 330 domain signature. 332 id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3} 333 for an additional attributes signature. 335 id-sigtype-review OBJECT IDENTIFIER ::= { id-signatureType 4} for a 336 review signature. 338 For completeness, an attribute type is also specified for an originator 339 signature. However, this signature type is optional. It is defined as 340 follows: 342 id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1} 343 for an originator's signature. 345 The originator signature MUST NOT encapsulate other signatures. The 346 other signature types specified in this document MAY encapsulate other 347 signatures. All the signature types MAY be added in parallel to other 348 signatures as documented in [5]. 350 A SignerInfo MUST NOT include multiple instances of SignatureType. An 351 authenticated attribute representing a SignatureType MAY include 352 multiple instances of different SignatureType values as an 353 AttributeValue of attrValues [5], as long as the SignatureType 354 'additional attributes' is not present. 356 The following sections describe the conditions under which each of these 357 types of signature may be generated, and how they are processed. 359 3.2 Domain Signature Generation and Verification 361 A 'domain signature' is a proxy signature generated on a user's behalf 362 in the user's domain. The signature MUST adhere to the naming 363 conventions in 3.1.1, including the name mapping convention. A 'domain 364 signature' on a message authenticates the fact that the message has 365 originated in that domain. Before signing, a process generating a 366 'domain signature' MUST first satisfy itself of the authenticity of the 367 message originator. This is achieved by one of two methods. Either the 368 'originator's signature' is checked, if S/MIME signatures are used 369 inside a domain. Or if not, some mechanism external to S/MIME is used, 370 such as the physical address of the originating client or an 371 authenticated IP link. 373 If the originator's authenticity is successfully verified by one of the 374 above methods and all other signatures present are valid, a 'domain 375 signature' MAY be added to a message in one of the following ways: 377 1) An unsigned message has a null signature added to it (i.e. the 378 message is wrapped in a signedData that has no signerInfo attached), 379 and then a 'domain signature' is added as defined in methods 2) or 3) 380 below. The originator's information is included as part of a header 381 field in the encapsulated message. 383 2) Signature Encapsulation is used to wrap the original signed message 384 with a 'domain signature'. 386 3) The original signed message has a 'domain signature' added in 387 parallel. 389 An entity generating a domain signature MUST do so using a certificate 390 containing a subject name that follows the naming convention specified 391 in 3.1.1. 393 When a 'domain signature' is applied the mlExpansionHistory and 394 eSSSecurityLabel attributes MUST be copied from other signerInfos as 395 stated in [3]. 397 If the originator's authenticity is not successfully verified or all 398 the signatures present are not valid, a 'domain signature' MUST NOT be 399 generated. 401 On reception, the 'domain signature' SHOULD be used to verify the 402 authenticity of a message. A check MUST be made to ensure that both the 403 naming convention and the name mapping convention have been used as 404 specified in this standard. 406 A recipient MAY assume that successful verification of the domain 407 signature also authenticates the message originator. 409 If there is an originator signature present, the name in that 410 certificate SHOULD be used to identify the originator. This information 411 can then be displayed to the recipient. 413 Alternatively, if a 'domain signature' has encapsulated a complete 414 MIME-encoded message, the originator information (SMTP 'From' field) 415 contained within it denotes the originator of the message. 417 If neither of these cases is true no assumptions can be made about the 418 originator. 420 A domain signer can be assumed to have verified any signatures that it 421 encapsulates. Therefore, it is not necessary to verify these signatures 422 before treating the message as authentic. However, this standard does 423 not preclude a recipient from attempting to verify any other signatures 424 that are present. 426 The 'domain signature' is indicated by the presence of the value 427 Id-at-sigtype-domain-sig in a 'signature type' authenticated attribute. 429 There MAY be multiple 'domain signature' signatures in an S/MIME 430 encoding. 432 3.3 Additional Attributes Signature generation and verification 434 The 'additional attributes' signature type indicates that the 435 SignerInfo contains additional attributes that are associated with the 436 message. 438 All attributes in the applicable SignerInfo MUST be treated as 439 additional attributes. Successful verification of an 'additional 440 attributes' signature means only that the attributes are authentically 441 bound to the message. A recipient MUST NOT assume that its successful 442 verification also authenticates the message originator. 444 An entity generating an 'additional attributes' signature MUST do so 445 using a certificate containing a subject name that follows the naming 446 convention specified in 3.1.1. On reception, a check MUST be made to 447 ensure that the naming convention has been used. 449 A signer MAY include any of the attributes listed in [5] or in this 450 document when generating an 'additional attributes' signature. The 451 following attributes have a special meaning, when present in an 452 'additional attributes' signature: 454 1) Equivalent Label: label values in this attribute are to be treated as 455 equivalent to the security label contained in an encapsulated 456 SignerInfo, if present. 458 2) Security Label: the label value indicates the aggregate sensitivity 459 of the inner message content plus any encapsulated signedData and 460 envelopedData containers. The label on the original data is indicated 461 by the value in the originator's signature, if present. 463 An 'additional attributes' signature is indicated by the presence of the 464 value Id-at-sigtype-add-attrib-sig in a 'signature type' authenticated 465 attribute. No other Object Identifiers MAY be included in the sequence 466 of OIDs if this value is present. An 'additional attributes' signature 467 MAY be added in parallel with other signatures in a SET OF SignerInfos. 469 There MAY be multiple 'additional attributes' signatures in an S/MIME 470 encoding. 472 3.4 Review Signature generation and verification 474 The review signature indicates that the signer has reviewed the message. 475 Successful verification of a review signature means only that the signer 476 has approved the message for onward transmission to the recipient(s). 477 When the recipient is in another domain, a device on a domain boundary 478 such as a Mail Guard or firewall may be configured to check review 479 signatures. A recipient MUST NOT assume that its successful verification 480 also authenticates the message originator. 482 An entity generating a signed review signature MUST do so using a 483 certificate containing a subject name that follows the naming convention 484 specified in 3.1.1. On reception, a check MUST be made to ensure that 485 the naming convention has been used. 487 A review signature is indicated by the presence of the value 488 Id-at-sigtype-review-sig in a 'signature type' authenticated attribute. 490 There MAY be multiple review signatures in an S/MIME encoding. 492 3.5 Originator Signature 494 The 'originator signature' is used to indicate that the signer is the 495 originator of the message and its contents. It is included in this 496 document for completeness only. An originator signature is indicated 497 either by the absence of the signature type attribute, or by the 498 presence of the value id-sigtype-originator-sig in a 'signature type' 499 authenticated attribute. There MUST be only one 'originator signature' 500 signature present in an S/MIME encoding and it MUST be one of the inner 501 most signatures. 503 4. Encryption and Decryption 505 Domain encryption is encryption performed by a third party on behalf of 506 a set of originators in a domain. Domain decryption is decryption 507 performed by a third party on behalf of a set of recipients in a domain. 509 Depending on security policy, messages may be encrypted for decryption 510 by the final recipient and by a domain decryption agent in the 511 originator's and/or the recipient's domain. This is achieved by 512 generating a RecipientInfo for each type of agent that is transmitted 513 along with the encrypted message. 515 The processes of domain encryption and decryption may be performed in 516 combination, as shown below. 518 -------------------------------------------------------------------- 519 | | Recipient Decryption | Domain Decryption | 520 |------------------------|----------------------|--------------------| 521 | Originator Encryption | Case(a) | Case(c) | 522 | Domain Encryption | Case(b) | Case(d) | 523 -------------------------------------------------------------------- 525 Case (a), encryption of messages by the originator for decryption by the 526 final recipient(s), is described in CMS [5]. In Cases (b) and (d), 527 encryption is performed not by the originator but by a third party in 528 the sending domain. In Cases (c) and (d), decryption is performed not by 529 the recipient(s) but by a third party in the destination domain. 531 A client implementation that conforms to this standard MUST support 532 cases (a) and (c) for transmission, and cases (a) and (b) for reception. 534 A Domain Encryption implementation that conforms to this standard MUST 535 support cases (b) and (d), for transmission, and cases (c) and (d) for 536 reception. 538 The process of encryption and decryption is documented in CMS [5]. The 539 only additional requirement introduced by domain encryption and 540 decryption is for greater flexibility in the management of keys, as 541 described in the following subsections. As with signatures, a naming 542 convention and name mapping convention are used to locate the correct 543 key. 545 The mechanisms described below are applicable both to key agreement and 546 key transport systems, as documented in CMS [5]. The phrase 'encryption 547 key' is used as a collective term to cover the key management keys used 548 by both techniques. 550 4.1 Domain Encryption Naming Conventions 552 A domain encryption agent MUST be named 'domain-confidentiality- 553 authority'. Also a domain decryption agent MUST be named 'domain- 554 confidentiality-authority'. This name MUST appear in the 'common name 555 (CN)' component of the subject field in the X.509 certificate. 556 Additionally, if the certificate contains an SMTP e-mail address, this 557 name MUST appear in the end entity component of the address - on the 558 left-hand side of the '@' symbol. 560 Along with this naming convention, an additional naming rule is defined: 561 the 'name mapping rule'. The name mapping rule states that for an 562 encryption agent, the domain component of its name MUST be the same as, 563 or an ascendant of, the domain name of the set of entities that it 564 represents. The domain component is defined as follows: 566 * In the case of an X.500 distinguished name of an X.509 certificate, 567 the domain component is the country, organisation, organisational 568 unit, state, and locality components of the distinguished name. 570 * If the certificate contains an SMTP e-mail address, the domain 571 component is defined to be the SMTP address component on the right- 572 hand side of the '@' symbol. 574 For example, an encryption authority acting on behalf of John Doe of the 575 Acme corporation, whose distinguished name is 'cn=John Doe,ou=marketing, 576 o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, 577 could have a certificate containing a distinguished name of 578 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail address 579 of 'domain-confidentiality-authority@acme.com'. The key associated with 580 this certificate would be used for encrypting messages for John Doe. 582 Any message received where the domain component of the domain encrypting 583 agents name does not match, or is not an ascendant of, the domain name 584 of the entities it represents MUST be rejected. 586 This naming rule prevents messages being encrypted for the wrong domain 587 decryption agent. 589 Implementations conforming to this standard MUST support this name 590 mapping convention as a minimum. Implementations may choose to 591 supplement this convention with other locally defined conventions. 592 However, these MUST be agreed between sender and recipient domains 593 prior to sending any messages. 595 4.2 Domain Encryption Key Management 597 Domain encryption is encryption performed by a third party on behalf of 598 a set of originators in a domain. Domain Encryption is shown as cases 599 (b) and (d) in the above table. 601 Domain encryption uses a domain-wide encryption key from the sender's 602 domain. Information about this key is conveyed to the recipient in the 603 RecipientInfo field as specified in CMS [5]. A domain encryption agent 604 MUST be named according to the naming convention specified in section 605 4.1. This is so that the same key can be used on reply to a domain- 606 encrypted message. 608 The domain encryption agent extracts the recipients address from the 609 message and uses this to obtain the recipients domain-confidentiality- 610 authority public key and/or the recipients public key. For example, 611 the recipients address is used as an index for a directory search. The 612 directory search MAY return the recipients certificate and/or a domain- 613 confidentiality-authority attribute that contains the location of the 614 recipient's domain decrytping agents certificate. If the directory 615 search returns no certificates then encryption can not be performed and 616 the message MUST NOT be sent. If one or both certificates are available 617 then the originator's domain encrypting agent encrypts the message for 618 the recipient and the recipient's domain decrypting agent. 620 4.3 Domain Decryption Key Management 622 Domain decryption is decryption performed by a third party on behalf of 623 a set of recipients in a domain. 625 Domain Decryption is shown as cases (c) and (d) in the above table. In 626 these cases, the encryption process has used a domain-wide encryption 627 key for the recipient(s)' domain, that has been obtained by using the 628 recipient's address (See example in section 4.2). 630 5. Security Considerations 632 Implementations MUST protect all private keys. Compromise of the 633 signer's private key permits masquerade. 635 Similarly, compromise of the content-encryption key may result in 636 disclosure of the encrypted content. 638 Compromise of key material is regarded as an even more serious issue for 639 domain security services than for an S/MIME client. This is because 640 compromise of the private key may in turn compromise the security of a 641 whole domain. Therefore, great care should be used when considering its 642 protection. 644 6. References 646 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, 647 June 1999. 649 [2] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, March 1997. 652 [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, 653 June 1999. 655 [4] International Telecommunications Union, Recommendation X.208, "Open 656 systems interconnection: specification of Abstract Syntax Notation 657 (ASN.1)", CCITT Blue Book, 1989. 659 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 661 7. Authors' Addresses 663 Tim Dean 664 DERA Malvern 665 St. Andrews Road 666 Malvern 667 Worcs 668 WR14 3PS 670 Phone: +44 (0) 1684 894239 671 Fax: +44 (0) 1684 896660 672 Email: t.dean@eris.dera.gov.uk 674 William Ottaway 675 DERA Malvern 676 St. Andrews Road 677 Malvern 678 Worcs 679 WR14 3PS 681 Phone: +44 (0) 1684 894079 682 Fax: +44 (0) 1684 896660 683 Email: w.ottaway@eris.dera.gov.uk 685 This draft expires 19th April 2000