idnits 2.17.1 draft-ietf-smime-domsec-06.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 802 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 5 instances of too long lines in the document, the longest one being 3 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 785 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 (~~), 4 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-06.txt W Ottaway 3 Expires 12th January 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 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 series and SMTP/MIME, or when a 37 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 term 'security domain' as used in this document is defined as a 148 collection of hardware and personnel operating under a single security 149 authority and performing a common business function. Members of a 150 security domain will of necessity share a high degree of mutual trust, 151 due to their shared aims and objectives. 153 A security domain is typically protected from direct outside attack by 154 physical measures and from indirect (electronic) attack by a combination 155 of firewalls and guards at network boundaries. The interface between two 156 security domains is termed a 'security boundary'. One example of a 157 security domain is an organisational network ('Intranet'). 159 2.1 Domain Signature 161 A Domain signature is an S/MIME signature generated on behalf of a set 162 of users in a domain. A Domain signature can be used to authenticate 163 information sent between domains or between a certain domain and one of 164 its individuals, for example, when two 'Intranets' are connected using 165 the Internet, or when an Intranet is connected to a remote user over the 166 Internet. It can be used when two domains employ incompatible signature 167 schemes internally or when there are no certification links between their 168 PKIs. In both cases messages from the originator's domain are signed over 169 the original message and signature (if present) using an algorithm, key, 170 and certificate which can be processed by the recipient(s). A domain 171 signature is sometimes referred to as an "organisational signature". 173 2.2 Review Signature 175 A third party may review messages before they are forwarded to the final 176 recipient(s) who may be in the same or a different security domain. 177 Organisational policy and good security practice often require that 178 messages be reviewed before they are released to external recipients. 179 Having reviewed a message, an S/MIME signature is added to it - a review 180 signature. An agent could check the review signature at the domain 181 boundary, to ensure that only reviewed messages are released. 183 2.3 Additional Attributes Signature 185 A third party can add additional attributes to a signed message. An 186 S/MIME signature is used for this purpose - an additional attributes 187 signature. An example of an additional attribute is the 'Equivalent 188 Label' attribute defined in ESS [3]. 190 2.4 Domain Encryption and Decryption 192 Domain encryption is S/MIME encryption performed on behalf of a 193 collection of users in a domain. Domain encryption can be used to 194 protect information between domains, for example, when two 'Intranets' 195 are connected using the Internet. It can also be used when end users do 196 not have PKI/encryption capabilities at the desktop, or when two 197 domains employ incompatible encryption schemes internally. In the latter 198 case messages from the originator's domain are (re-)encrypted using an 199 algorithm, key, and certificate which can be decrypted by the 200 recipient(s) or an entity in their domain. This scheme also applies to 201 protecting information between a single domain and one of its members 202 when both are connected using an untrusted network, e.g the Internet. 204 3. Mapping of the Signature Services to the S/MIME Protocol 206 This section describes the S/MIME protocol elements that are used to 207 provide the security services described above. ESS [3] introduces the 208 concept of triple-wrapped messages that are first signed, then 209 encrypted, then signed again. This document also uses this concept of 210 triple-wrapping. In addition, this document also uses the concept of 211 'signature encapsulation'. 'Signature encapsulation' denotes a signed 212 or unsigned message that is wrapped in a signature, this signature 213 covering both the content and the first (inner) signature, if present. 215 Signature encapsulation MAY be performed on the inner and/or the outer 216 signature of a triple-wrapped message. 218 For example, the originator signs a message which is then encapsulated 219 with an 'additional attributes' signature. This is then encrypted. A 220 reviewer then signs this encrypted data, which is then encapsulated by 221 a domain signature. 223 A DOMSEC signature MAY encapsulate a message in one of the following 224 ways: 226 1) An unsigned message has an empty signature layer added to it (i.e. 227 the message is wrapped in a signedData that has a signerInfos which 228 contains no elements). This is to enable backward compatibility with 229 S/MIME software that does not have a DOMSEC capability. Since the 230 signerInfos will contain no signers the eContentType, within the 231 EncapsulatedContentInfo, MUST be id-data as described in CMS [5]. 232 However, the eContent field will contain the unsigned message instead 233 of being left empty as suggested in section 5.2 in CMS [5]. This is so 234 that when the DOMSEC signature is added, as defined in method 2) 235 below, the signature will cover the unsigned message. 237 2) Signature Encapsulation is used to wrap the original signed message 238 with a 'domain signature'. 240 3.1 Naming Conventions and Signature Types 242 An entity receiving an S/MIME signed message would normally expect the 243 signature to be that of the originator of the message. However, the 244 message security services defined in this document require the recipient 245 to be able to accept messages signed by other entities and/or the 246 originator. When other entities sign the message the name in the 247 certificate will not match the message sender's name. An S/MIME 248 compliant implementation would normally flag a warning if there were a 249 mismatch between the name in the certificate and the message sender's 250 name. (This check prevents a number of types of masquerade attack.) 252 In the case of domain security services, this warning condition SHOULD 253 be suppressed under certain circumstances. These circumstances are 254 defined by a naming convention that specifies the form that the signers 255 name SHOULD adhere to. Adherence to this naming convention avoids the 256 problems of uncontrolled naming and the possible masquerade attacks that 257 this would produce. 259 As an assistance to implementation, a signed attribute is defined to be 260 included in the S/MIME signature - the 'signature type' attribute. On 261 receiving a message containing this attribute, the naming convention 262 checks are invoked. 264 Implementations conforming to this standard MUST support the naming 265 convention for signature generation and verification. Implementations 266 conforming to this standard MUST recognise the signature type attribute 267 for signature verification. Implementations conforming to this standard 268 MUST support the signature type attribute for signature generation. 270 3.1.1 Naming Conventions 272 The following naming conventions are specified for agents generating 273 signatures specified in this document: 275 * For a domain signature, an agent generating this signature MUST be 276 named 'domain-signing-authority' 278 * For a review signature, an agent generating this signature MUST be 279 named 'review-authority'. 281 * For an additional attributes signature, an agent generating this 282 signature MUST be named 'attribute-authority'. 284 This name shall appear as the 'common name (CN)' component of the 285 subject field in the X.509 certificate. There MUST be only one CN 286 component present. Additionally, if the certificate contains an RFC 822 287 address, this name shall appear in the end entity component of the 288 address - on the left-hand side of the '@' symbol. 290 In the case of a domain signature, an additional naming rule is 291 defined: the 'name mapping rule'. The name mapping rule states that 292 for a domain signing authority, the domain component of its name MUST be 293 the same as, or an ascendant of, the domain name of the message 294 originator(s) that it is representing. The domain component is defined 295 as follows: 297 * In the case of an X.500 distinguished subject name of an X.509 298 certificate, the domain component is the country, organisation, 299 organisational unit, state, and locality components of the 300 distinguished name. 302 * If the certificate contains an RFC 822 address, the domain 303 component is defined to be the RFC 822 address component on the right- 304 hand side of the '@' symbol. 306 For example, a domain signing authority acting on behalf of John Doe of 307 the Acme corporation, whose distinguished name is 'cn=John Doe, 308 ou=marketing,o=acme,c=us' and whose e-mail address is 309 John.Doe@marketing.acme.com, could have a certificate containing a 310 distinguished name of 'cn=domain-signing-authority,o=acme,c=us' and a 311 RFC 822 address of 'domain-signing-authority@acme.com'. 313 When the X.500 distinguished subject name has consecutive organisational 314 units and/or localities it is important to understand the ordering of 315 these values in order to determine if the domain component of the domain 316 signature is an ascendant. In this case, when parsing the distinguished 317 subject name from the root (i.e. country, locality or organisation) the 318 parsed organisational unit or locality is deemed to be the ascendant of 319 consecutive (unparsed) organisational units or localities. 321 For example, a domain signing authority acting on behalf of John Doe of 322 the Acme corporation, whose distinguished name is 'cn=John Doe, 323 ou=marketing,ou=defence,o=acme,c=us' and whose e-mail address is 324 John.Doe@marketing.defence.acme.com, could have a certificate containing 325 a distinguished name of 'cn=domain-signing-authority,ou=defence,o=acme, 326 c=us' and a RFC 822 address of 327 'domain-signing-authority@defence.acme.com'. 329 Any message received where the domain component of the domain signing 330 agents name does not match, or is not an ascendant of, the originator's 331 domain name MUST be rejected. 333 This naming rule prevents agents from one organisation masquerading as 334 domain signing authorities on behalf of another. For the other types of 335 signature defined in this document, no such named mapping rule is 336 defined. 338 Implementations conforming to this standard MUST support this name 339 mapping convention as a minimum. Implementations MAY choose to 340 supplement this convention with other locally defined conventions. 341 However, these MUST be agreed between sender and recipient domains prior 342 to secure exchange of messages. 344 On verifying the signature, a receiving agent MUST ensure that the 345 naming convention has been adhered to. Any message that violates the 346 convention should be flagged. 348 3.1.2 Signature Type Attribute 350 An S/MIME signed attribute is used to indicate the type of signature. 351 This should be used in conjunction with the naming conventions specified 352 in the previous section. When an S/MIME signed message containing the 353 signature type attribute is received it triggers the software to verify 354 that the correct naming convention has been used. 356 The ASN.1 [4] notation of this attribute is: - 358 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 360 id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) 361 us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} 363 If present, the SignatureType attribute MUST be a signed attribute, as 364 defined in [5]. If the SignatureType attribute is absent the recipient 365 SHOULD assume that the signature is that of the message originator. 367 All of the signatures defined here are generated and processed as 368 described in [5]. They are distinguished by the presence of the 369 following values in the SignatureType signed attribute: 371 id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 2 } 372 -- domain signature. 374 id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 375 3} -- additional attributes signature. 377 id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} -- 378 review signature. 380 For completeness, an attribute type is also specified for an originator 381 signature. However, this signature type is optional. It is defined as 382 follows: 384 id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 1} 385 -- originator's signature. 387 All signature types, except the originator type, MUST encapsulate other 388 signature types specified in this document MUST encapsulate other 389 signatures. Note the domain signature could be encapsulating an empty 390 signature as defined in section 3. 392 A SignerInfo MUST NOT include multiple instances of SignatureType. A 393 signed attribute representing a SignatureType MAY include multiple 394 instances of different SignatureType values as an AttributeValue of 395 attrValues [5], as long as the SignatureType 'additional attributes' is 396 not present. 398 If there is more than one SignerInfo in a signerInfos (i.e. when 399 different algorithms are used) then the SignatureType attribute in all 400 the SignerInfos MUST contain the same content. 402 The following sections describe the conditions under which each of these 403 types of signature may be generated, and how they are processed. 405 3.2 Domain Signature Generation and Verification 407 A 'domain signature' is a proxy signature generated on a user's behalf 408 in the user's domain. The signature MUST adhere to the naming 409 conventions in 3.1.1, including the name mapping convention. A 'domain 410 signature' on a message authenticates the fact that the message has 411 originated in that domain. Before signing, a process generating a 412 'domain signature' MUST first satisfy itself of the authenticity of the 413 message originator. This is achieved by one of two methods. Either the 414 'originator's signature' is checked, if S/MIME signatures are used 415 inside a domain. Or if not, some mechanism external to S/MIME is used, 416 such as the physical address of the originating client or an 417 authenticated IP link. 419 If the originator's authenticity is successfully verified by one of the 420 above methods and all other signatures present are valid, a 'domain 421 signature' MAY be added to a message. 423 An entity generating a domain signature MUST do so using a certificate 424 containing a subject name that follows the naming convention specified 425 in 3.1.1. 427 When a 'domain signature' is applied the mlExpansionHistory and 428 eSSSecurityLabel attributes MUST be copied from other signerInfos as 429 stated in [3]. 431 If the originator's authenticity is not successfully verified or all 432 the signatures present are not valid, a 'domain signature' MUST NOT be 433 generated. 435 On reception, the 'domain signature' SHOULD be used to verify the 436 authenticity of a message. A check MUST be made to ensure that both the 437 naming convention and the name mapping convention have been used as 438 specified in this standard. 440 A recipient can assume that successful verification of the domain 441 signature also authenticates the message originator. 443 If there is an originator signature present, the name in that 444 certificate SHOULD be used to identify the originator. This information 445 can then be displayed to the recipient. 447 If there is no originator signature present, the only assumption that can 448 be made is the domain the message originated from. 450 A domain signer can be assumed to have verified any signatures that it 451 encapsulates. Therefore, it is not necessary to verify these signatures 452 before treating the message as authentic. However, this standard does 453 not preclude a recipient from attempting to verify any other signatures 454 that are present. 456 The 'domain signature' is indicated by the presence of the value 457 id-aa-sigtype-domain-sig in a 'signature type' signed attribute. 459 There MAY be one or more 'domain signature' signatures in an S/MIME 460 encoding. 462 3.3 Additional Attributes Signature Generation and Verification 464 The 'additional attributes' signature type indicates that the 465 SignerInfo contains additional attributes that are associated with the 466 message. 468 All attributes in the applicable SignerInfo MUST be treated as 469 additional attributes. Successful verification of an 'additional 470 attributes' signature means only that the attributes are authentically 471 bound to the message. A recipient MUST NOT assume that its successful 472 verification also authenticates the message originator. 474 An entity generating an 'additional attributes' signature MUST do so 475 using a certificate containing a subject name that follows the naming 476 convention specified in 3.1.1. On reception, a check MUST be made to 477 ensure that the naming convention has been used. 479 A signer MAY include any of the attributes listed in [3] or in this 480 document when generating an 'additional attributes' signature. The 481 following attributes have a special meaning, when present in an 482 'additional attributes' signature: 484 1) Equivalent Label: label values in this attribute are to be treated as 485 equivalent to the security label contained in an encapsulated 486 SignerInfo, if present. 488 2) Security Label: the label value indicates the aggregate sensitivity 489 of the inner message content plus any encapsulated signedData and 490 envelopedData containers. The label on the original data is indicated 491 by the value in the originator's signature, if present. 493 An 'additional attributes' signature is indicated by the presence of the 494 value id-aa-sigtype-add-attrib-sig in a 'signature type' signed 495 attribute. Other Object Identifiers MUST NOT be included in the sequence 496 of OIDs if this value is present. 498 There MAY be multiple 'additional attributes' signatures in an S/MIME 499 encoding. 501 3.4 Review Signature Generation and Verification 503 The review signature indicates that the signer has reviewed the message. 504 Successful verification of a review signature means only that the signer 505 has approved the message for onward transmission to the recipient(s). 506 When the recipient is in another domain, a device on a domain boundary 507 such as a Mail Guard or firewall may be configured to check review 508 signatures. A recipient MUST NOT assume that its successful verification 509 also authenticates the message originator. 511 An entity generating a signed review signature MUST do so using a 512 certificate containing a subject name that follows the naming convention 513 specified in 3.1.1. On reception, a check MUST be made to ensure that 514 the naming convention has been used. 516 A review signature is indicated by the presence of the value 517 id-aa-sigtype-review-sig in a 'signature type' signed attribute. 519 There MAY be multiple review signatures in an S/MIME encoding. 521 3.5 Originator Signature 523 The 'originator signature' is used to indicate that the signer is the 524 originator of the message and its contents. It is included in this 525 document for completeness only. An originator signature is indicated 526 either by the absence of the signature type attribute, or by the 527 presence of the value id-aa-sigtype-originator-sig in a 'signature type' 528 signed attribute. 530 4. Encryption and Decryption 532 Message encryption may be performed by a third party on behalf of a set 533 of originators in a domain. This is referred to as domain encryption. 534 Message decryption may be performed by a third party on behalf of a set 535 of recipients in a domain. This is referred to as domain decryption. 536 The third party that performs these processes is referred to in this 537 section as a "Domain Confidentiality Authority" (DCA). Both of these 538 processes are described in this section. 540 Messages may be encrypted for decryption by the final recipient and/or 541 by a DCA in the recipient's domain. The message may also be encrypted 542 for decryption by a DCA in the originator's domain (e.g. for content 543 analysis, audit, key word scanning, etc.). The choice of which of these 544 is actually performed is a system specific issue that depends on system 545 security policy. It is therefore outside the scope of this document. 546 These processes of encryption and decryption processes are shown in the 547 following table. 549 -------------------------------------------------------------------- 550 | | Recipient Decryption | Domain Decryption | 551 |------------------------|----------------------|--------------------| 552 | Originator Encryption | Case(a) | Case(b) | 553 | Domain Encryption | Case(c) | Case(d) | 554 -------------------------------------------------------------------- 556 Case (a), encryption of messages by the originator for decryption by the 557 final recipient(s), is described in CMS [5]. In cases (c) and (d), 558 encryption is performed not by the originator but by the DCA in the 559 originator's domain. In Cases (b) and (d), decryption is performed not 560 by the recipient(s) but by the DCA in the recipient's domain. 562 A client implementation that conforms to this standard MUST support 563 case (b) for transmission, case (c) for reception and case (a) for 564 transmission and reception. 566 A DCA implementation that conforms to this standard MUST support cases 567 (c) and (d), for transmission, and cases (b) and (d) for reception. 569 The process of encryption and decryption is documented in CMS [5]. The 570 only additional requirement introduced by domain encryption and 571 decryption is for greater flexibility in the management of keys, as 572 described in the following subsections. As with signatures, a naming 573 convention and name mapping convention are used to locate the correct 574 public key. 576 The mechanisms described below are applicable both to key agreement and 577 key transport systems, as documented in CMS [5]. The phrase 'encryption 578 key' is used as a collective term to cover the key management keys used 579 by both techniques. 581 The mechanisms below are also applicable to individual roving users who 582 wish to encrypt messages that are sent back to base. 584 4.1 Domain Confidentiality Naming Conventions 586 A DCA MUST be named 'domain-confidentiality-authority'. This name MUST 587 appear in the 'common name(CN)' component of the subject field in the 588 X.509 certificate. Additionally, if the certificate contains an RFC 822 589 address, this name MUST appear in the end entity component of the 590 address - on the left-hand side of the '@' symbol. 592 Along with this naming convention, an additional naming rule is defined: 593 the 'name mapping rule'. The name mapping rule states that for a DCA, 594 the domain component of its name MUST be the same as, or an ascendant 595 of, the domain name of the set of entities that it represents. The 596 domain component is defined as follows: 598 * In the case of an X.500 distinguished name of an X.509 certificate, 599 the domain component is the country, organisation, organisational 600 unit, state, and locality components of the distinguished name. 602 * If the certificate contains an RFC 822 address, the domain component 603 is defined to be the RFC 822 address component on the right-hand side 604 of the '@' symbol. 606 For example, a DCA acting on behalf of John Doe of the Acme 607 corporation, whose distinguished name is 'cn=John Doe, ou=marketing, 608 o=acme,c=us' and whose e-mail address is John.Doe@marketing.acme.com, 609 could have a certificate containing a distinguished name of 610 'cn=domain-confidentiality-authority, o=acme,c=us' and an e-mail 611 address of 'domain-confidentiality-authority@acme.com'. The key 612 associated with this certificate would be used for encrypting messages 613 for John Doe. 615 Any message received where the domain component of the domain encrypting 616 agents name does not match, or is not an ascendant of, the domain name 617 of the entities it represents MUST be rejected. 619 This naming rule prevents messages being encrypted for the wrong domain 620 decryption agent. 622 Implementations conforming to this standard MUST support this name 623 mapping convention as a minimum. Implementations may choose to 624 supplement this convention with other locally defined conventions. 625 However, these MUST be agreed between sender and recipient domains 626 prior to sending any messages. 628 4.2 Key Management for DCA Encryption 630 At the sender's domain, DCA encryption is achieved using the recipient 631 DCA's certificate or the end recipient's certificate. For this, the 632 encrypting process must be able to correctly locate the certificate to 633 the corresponding DCA in the recipient's domain or the one corresponding 634 to the end recipient. Having located the correct certificate, the 635 encryption process is then performed and additional information required 636 for decryption is conveyed to the recipient in the recipientInfo field 637 as specified in CMS [5]. A DCA encryption agent MUST be named according 638 to the naming convention specified in section 4.1. This is so that the 639 corresponding certificate can be used on eventual reply to a DCA 640 encrypted message. 642 DCA encryption may be performed for decryption by the end recipient 643 and/or by a DCA. End recipient decryption is described in CMS [5]. DCA 644 decryption is described in section 4.3. 646 4.3 Key Management for DCA Decryption 648 DCA decryption uses a private-key from the recipient's domain and the 649 necessary information conveyed in the recipientInfo field. The 650 private-key is owned by the DCA for the recipient domain. This is 651 achieved using the naming conventions specified in 4.1. It is vital that 652 these conventions are adhered to, in order to maintain confidentiality. 654 It should be noted that domain decryption can be performed on messages 655 encrypted by the originator and/or by a DCA in the originator's domain. 656 In the first case, the encryption process is described in CMS [5]; in 657 the second case, the encryption process is described in 4.2. 659 No specific method for locating this certificate is mandated in this 660 document. An implementation may choose to access a local certificate 661 store to locate the correct certificate. Alternatively, a directory may 662 be used in one of the following ways: 664 1. The directory may store the DCA certificate in the recipient's 665 directory entry. When the user certificate attribute is requested, 666 this certificate is returned. 668 2. The encrypting agent maps the recipient`s name to the DCA name in the 669 manner specified in 4.1. The user certificate attribute associated 670 with this directory entry is then obtained. 672 This document does not mandate either of these processes. Whichever one 673 is used, the name mapping conventions must be adhered to, in order to 674 maintain confidentiality. 676 Having located the correct certificate, the encryption process is then 677 performed. A recipientInfo for the DCA is then generated, as described 678 in CMS [5]. 680 5. Security Considerations 682 Implementations MUST protect all private keys. Compromise of the 683 signer's private key permits masquerade. 685 Similarly, compromise of the content-encryption key may result in 686 disclosure of the encrypted content. 688 Compromise of key material is regarded as an even more serious issue for 689 domain security services than for an S/MIME client. This is because 690 compromise of the private key may in turn compromise the security of a 691 whole domain. Therefore, great care should be used when considering its 692 protection. 694 Domain encryption alone is not secure and should be used in conjuction 695 with a domain signature to avoid a masquerade attack, where an attacker 696 that has obtain a DCA cert can fake a message to that domain pretending 697 to be another domain. 699 6. DOMSEC ASN.1 Module 701 DOMSECSyntax 702 { iso(1) member-body(2) us(840) rsadsi(113549) 703 pkcs(1) pkcs-9(9) smime(16) modules(0) domsec(10) } 705 DEFINITIONS IMPLICIT TAGS ::= 706 BEGIN 708 -- EXPORTS All 709 -- The types and values defined in this module are exported for 710 -- use in the other ASN.1 modules. Other applications may use 711 -- them for their own purposes. 713 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 715 id-aa-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) 716 us (840) rsadsi (113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 28} 718 id-aa-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-aa-signatureType 719 2 } -- domain signature. 721 id-aa-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { 722 id-aa-signatureType 3} -- additional attributes signature. 724 id-aa-sigtype-review OBJECT IDENTIFIER ::= { id-aa-signatureType 4} 725 -- review signature. 727 id-aa-sigtype-originator-sig OBJECT IDENTIFIER ::= { 728 id-aa-signatureType 1} -- originator's signature. 730 END -- of DOMSECSyntax 732 7. References 734 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC2633, 735 June 1999. 737 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 738 Levels", BCP 14, RFC 2119, March 1997. 740 [3] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, 741 June 1999. 743 [4] International Telecommunications Union, Recommendation X.208, "Open 744 systems interconnection: specification of Abstract Syntax Notation 745 (ASN.1)", CCITT Blue Book, 1989. 747 [5] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 749 8. Authors' Addresses 751 Tim Dean 752 DERA Malvern 753 St. Andrews Road 754 Malvern 755 Worcs 756 WR14 3PS 758 Phone: +44 (0) 1684 894239 759 Fax: +44 (0) 1684 896660 760 Email: t.dean@eris.dera.gov.uk 762 William Ottaway 763 DERA Malvern 764 St. Andrews Road 765 Malvern 766 Worcs 767 WR14 3PS 769 Phone: +44 (0) 1684 894079 770 Fax: +44 (0) 1684 896660 771 Email: w.ottaway@eris.dera.gov.uk 773 8. Full Copyright Statement 775 "Copyright (C) The Internet Society (2000). All Rights Reserved. 777 This document and translations of it may be copied and furnished to 778 others, and derivative works that comment on or otherwise explain it or 779 assist in its implmentation may be prepared, copied, published and 780 distributed, in whole or in part, without restriction of any kind, 781 provided that the above copyright notice and this paragraph are included 782 on all such copies and derivative works. However, this document itself 783 may not be modified in any way, such as by removing the copyright notice 784 or references to the Internet Society or other Internet organizations, 785 except as needed for the purpose of developing Internet standards in 786 which case the procedures for copyrights defined in the Internet 787 Standards process must be followed, or as required to translate it into 788 languages other than English. 790 The limited permissions granted above are perpetual and will not be 791 revoked by the Internet Society or its successors or assigns. 793 This document and the information contained herein is provided on an 794 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 795 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 796 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 797 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 798 FITNESS FOR A PARTICULAR PURPOSE." 800 This draft expires 12th January 2001