idnits 2.17.1 draft-ietf-smime-domsec-01.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-25) 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 521 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 1 character in excess of 72. 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) == Outdated reference: A later version (-08) exists of draft-ietf-smime-msg-04 == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-05 == Outdated reference: A later version (-12) exists of draft-ietf-smime-ess-06 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 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-01.txt W Ottaway 3 November 17, 1998 DERA 4 Expires in six months 6 Domain Security Services using S/MIME 8 Status of this memo 10 This document is an Internet-Draft. 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 To view the entire list of Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net ( Northern Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 24 ftp.isi.edu(US West Coast). 26 Abstract 28 This document describes how the S/MIME protocol can be processed and 29 generated by a number of components of a messaging 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 do not have 38 encryption or signing capabilities at the desktop, but wish to 39 interoperate 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, Dave 52 Kemp and Jim Schaad. 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 feasible or practical to 63 provide end-to-end ('desktop-to-desktop') security services, 64 particularly between different security domains. An organisation which 65 is considering providing end-to-end security services will typically 66 have to deal with 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) Cross-certification problems: There may not be any cross-certificate 78 links between two organisations. Or an organisation may be sensitive 79 about parts of its PKI and unwilling to expose them to outside 80 access. For either of these reasons, end-to-end encryption and 81 signature validation 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 5) Cost: providing the necessary key management infrastructure and other 89 items such as hardware tokens for all users may be too expensive. 91 One solution to these problems is to provide message security services 92 at the level of a domain or an organisation. This document specifies how 93 these 'domain security services' can be provided using the S/MIME 94 protocol. Domain security services may replace or complement mechanisms 95 at the desktop. For example, a domain may decide to provide desktop-to- 96 desktop signatures but domain-to-domain encryption services. Or it may 97 allow desktop-to-desktop services for intra-domain use, but enforce 98 domain-based services for communication with other domains. 100 Messages can be processed and generated by a number of components of a 101 messaging system, such as message transfer agents, guards and gateways. 102 Any of these agents may provide domain security services. 104 The term 'Third Party' as used in this document means any entity in a 105 messaging system other than the originator and final recipient(s) that 106 processes messages. This includes Message Transfer Agents (MTAs), 107 domain mail servers, guards and firewalls operating at security 108 boundaries, and gateways that translate between different protocol 109 formats. A third party may sign, encrypt, decrypt, and check signatures 110 on a message. 112 Throughout this draft the terms MAY, MUST, MUST NOT and SHOULD NOT are 113 used in capital letters. This conforms to the definitions in [2]. 115 2. Overview of Domain Security Services 117 In a distributed system, a message is sent from an originator to a set 118 of recipients that may be in the same or different security domains. 119 This section first defines what is meant by a security domain. It then 120 gives an informal overview of the security services that are provided by 121 S/MIME between different security domains. These services are provided 122 by a combination of mechanisms in the sender's and recipient's domains. 123 Later sections describe definitively how these services map onto 124 elements of the S/MIME protocol. 126 2.1 Definition of a Security Domain 128 A 'security domain' is defined as a collection of hardware and personnel 129 operating under a single security authority and performing a common 130 business function. Members of a security domain will of necessity share 131 a high degree of mutual trust, due to their shared aims and objectives. 132 A security domain is typically protected from direct outside attack by 133 physical measures and from indirect (electronic) attack by a combination 134 of firewalls and guards at network boundaries. The interface between two 135 security domains is termed a 'security boundary'. One example of a 136 security domain is an organisational network ('Intranet'). 138 2.2 Signing by a third party 140 A third-party may sign messages for one or more of the following reasons: 142 1. When messages need to be reformatted inside the message transfer 143 system. Message reformatting is needed at gateways between X.400 and 144 SMTP-MIME domains, or on conversion between HTTP-MIME and SMTP-MIME 145 message representations. The third party signature is needed because 146 the reformatting process renders the originator's signature 147 unverifiable by the recipient(s). 149 2. To bridge between two domains that have incompatible or disconnected 150 signature systems, such as when there are no cross-certificate links 151 between their Public Key Infrastructures (PKIs). The third party 152 signature is needed because the originator's signature is not 153 directly verifiable by the recipient(s). It is typically created at 154 the boundary between the domains. 156 3. When end users do not have signing capabilities at the desktop. 158 A third party may wish to convey the signature semantics to the 159 recipient(s) when creating its digital signature. This document 160 specifies three signature types to convey these semantics, as follows. 162 A third party may sign a message, and optionally add additional 163 attributes to it. An example is the addition of the 'Equivalent Label' 164 attribute defined in ESS [4]. In this case the 'additional attributes' 165 signature is used. 167 A third party may wish to declare that it is acting as a proxy on 168 behalf of an originator in a domain. In this case the 'Domain' 169 Signature is used. 171 A third party may review messages before they are released from a 172 domain. This is used when organisational policy or good security 173 practice require that messages be reviewed before they are released to 174 external recipients. Having reviewed a message, a 'review and release' 175 signature is added to it. The review and release signature may be 176 checked by a firewall at the domain boundary, to ensure that only 177 reviewed messages are released. 179 2.3 Domain Encryption 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. In the latter case messages 187 from the originator's domain are re-encrypted using an algorithm, key, 188 and certificate which can be decrypted by the recipient(s). 190 3. Mapping of Domain Security Services to the S/MIME Protocol 192 This section describes the S/MIME Protocol elements that are used to 193 provide the security services described above. ESS [4] introduces the 194 concept of triple-wrapped messages that are first signed, then 195 encrypted, then signed again. This document also uses this concept of 196 triple-wrapping. In addition, this document also uses the concept of 197 'signature encapsulation'. 'Signature encapsulation' denotes a complete 198 signed message that is wrapped in a second signature, the second 199 signature covering both the content and the first (inner) signature. 200 Signature Encapsulation may be performed on the inner or the outer 201 signature of a triple-wrapped message. The term 'parallel signatures' 202 means two or more signatures calculated over the same content. This 203 capability is described in CMS [3], where a set of one or more 204 SignerInfos can be attached to signed data. 206 3.1 Signature Types 208 An authenticated attribute is used to indicate the type of signature. 209 The ASN.1 [5] notation of this attribute is:- 211 SignatureType ::= SEQUENCE OF OBJECT IDENTIFIER 213 id-signatureType OBJECT IDENTIFIER ::= { iso (1) member-body (2) 214 us (840) rsadsi (113549) } 216 If present, the SignatureType attribute MUST be an authenticated 217 attribute, as defined in [3]. If the SignatureType attribute is absent 218 the recipient SHOULD NOT make any assumptions about the type of 219 signature. 221 This section specifies the following types of signature: 223 1) Originator Signature 224 2) Domain Signature 225 3) Additional Attributes Signature 226 4) Review and Release Signature 228 Each of these signature types is generated and processed exactly as 229 described in [3]. They are distinguished by the presence of the 230 following values in the SignatureType authenticated attribute: 232 id-sigtype-originator-sig OBJECT IDENTIFIER ::= { id-signatureType 1} 233 id-sigtype-domain-sig OBJECT IDENTIFIER ::= { id-signatureType 2 } 234 id-sigtype-add-attrib-sig OBJECT IDENTIFIER ::= { id-signatureType 3} 235 id-sigtype-review-release-sig OBJECT IDENTIFIER ::= { id-signatureType 236 4} 238 These signature types may encapsulate other signatures, or any other 239 type of content, or may be added in parallel to other signatures as 240 documented in [3]. 242 A SignerInfo MUST NOT include multiple instances of SignatureType. An 243 authenticated attribute representing a SignatureType MAY include 244 multiple instances of different SignatureType values as an 245 AttributeValue of attrValues [3], as long as the SignatureType 246 'additional attributes' is not present. 248 The following sections describe the conditions under which each of 249 these types of signature may be generated, and how they are processed. 251 3.1.1 Originator Signature 253 The 'originator signature' is used to indicate that the signer is the 254 originator of the message and its contents. The 'originator signature' 255 is indicated by the presence of the value id-sigtype-originator-sig in 256 the 'signature type' authenticated attribute. There MUST be only one 257 'originator signature' signature present in a S/MIME encoding. 259 3.1.2 Domain Signature 261 A 'domain signature' is a proxy signature generated on a user's behalf in 262 a domain. A 'domain signature' on a message authenticates the fact that 263 the message has originated in that domain. Before signing, a process 264 generating a 'domain signature' MUST first satisfy itself of the 265 authenticity of the message originator. This is achieved by one of two 266 methods. Either the 'originator's signature' is checked, if S/MIME 267 signatures are used inside a domain. Or if not, some mechanism external 268 to S/MIME is used, such as the physical address of the originating 269 client or an authenticated IP link. 271 If the originator's authenticity is successfully verified by one of the 272 above methods and all other signatures present are valid, a 'domain 273 signature' may be added to a message in one of the following ways: 275 1) An unsigned message is wrapped in a SignedData, and a SignerInfo is 276 attached containing the 'domain signature'. The originator's 277 information is included as part of a header field in the encapsulated 278 message. 280 2) Signature Encapsulation is used to wrap the original signed message 281 with a 'domain signature'. 283 3) The original signed message has a 'domain signature' added in 284 parallel. 286 When a 'domain signature' is applied the mlExpansionHistory and 287 eSSSecurityLabel attributes MUST be copied from other signerInfos as 288 stated in [4]. 290 If the originator's authenticity is not successfully verified, a 'domain 291 signature' MUST NOT be generated. 293 On reception, the 'domain signature' may be used to verify the 294 authenticity of a message. If there is a SignerInfo with the signature 295 type 'originator', its certificate should be used to identify the 296 originator. This information can then be displayed to the recipient. 297 Alternatively, if a 'domain signature' has encapsulated a complete 298 MIME-encoded message, the originator information (SMTP 'From' field) 299 contained within it denotes the originator of the message. If neither 300 of these cases is true no assumptions can be made about the originator. 302 A domain signer can be assumed to have verified any signatures that it 303 encapsulates. Therefore, it is not necessary to verify these signatures 304 before treating the message as authentic. However, this standard does 305 not preclude a recipient from attempting to verify any other signatures 306 that are present. 308 The 'domain signature' is indicated by the presence of the value Id-at- 309 sigtype-domain-sig in the 'signature type' authenticated attribute. 310 There MAY be multiple 'domain signature' signatures in a S/MIME encoding. 312 3.1.3 Additional Attributes Signature 314 The 'additional attributes' signature type indicates that the SignerInfo 315 contains additional attributes that are associated with the message. 316 All attributes in the applicable SignerInfo MUST be treated as 317 additional attributes. Successful verification of an 'additional 318 attributes' signature means only that the attributes are authentically 319 bound to the message. A recipient MUST NOT assume that its successful 320 verification also authenticates the message originator. The authenticity 321 of the message originator should be verified by checking the signature of 322 the appropriate type, if present. 324 A signer may include any of the attributes listed in [3] or this document 325 when generating an 'additional attributes' signature. The following 326 attributes have a special meaning, when present in an 'additional 327 attributes' signature: 329 1) Equivalent Label: label values in this attribute are to be treated as 330 equivalent to the security label contained in an encapsulated 331 SignerInfo, if present. 333 2) Security Label: the label value indicates the aggregate sensitivity 334 of the inner message content plus any encapsulated signedData and 335 envelopedData containers. The label on the original data is indicated 336 by the value in the originator's signature, if present. 338 An 'additional attributes' signature is indicated by the presence of the 339 value Id-at-sigtype-add-attrib-sig in the 'signature type' authenticated 340 attribute. No other Object Identifiers may be included in the sequence 341 of OIDs if this value is present. An 'additional attributes' signature 342 may be added in parallel with other signatures in a SET OF SignerInfos. 343 There MAY be multiple 'additional attributes' signatures in a S/MIME 344 encoding. 346 3.1.4 Review and Release 348 The 'review and release' signature indicates that the signer has 349 reviewed the message. Successful verification of a 'review and release' 350 signature means only that the signer has approved the message for 351 release from a domain. A device on a domain boundary such as a Mail 352 Guard or firewall may be configured to check review and release 353 signatures. A recipient MUST NOT assume that its successful verification 354 also authenticates the message originator. The authenticity of the 355 message originator should be verified by checking the signature 356 identified as the originators, if present. 358 A 'review and release' signature is indicated by the presence of the 359 value Id-at-sigtype-review-release-sig in the 'signature type' 360 authenticated attribute. There MAY be multiple 'review and release' 361 signatures in a S/MIME encoding. 363 3.2 Domain Encryption and Decryption 365 Domain encryption is encryption performed by a third party on behalf of 366 a set of originators in a domain. Domain decryption is decryption 367 performed by a third party on behalf of a set of recipients in a domain. 368 These processes may be performed in combination, as shown below. 370 -------------------------------------------------------------------- 371 | | Recipient Decryption | Domain Decryption | 372 |------------------------|----------------------|--------------------| 373 | Originator Encryption | Case(a) | Case(c) | 374 | Domain Encryption | Case(b) | Case(d) | 375 -------------------------------------------------------------------- 377 Case (a), encryption of messages by the originator for decryption by the 378 final recipient(s), is described in CMS [3]. In Cases (b) and (d), 379 encryption is performed not by the originator but by a third party in 380 the sending domain. In Cases (c) and (d), decryption is performed not 381 by the recipient(s) but by a third party in the destination domain. 383 A client implementation that conforms to this standard MUST support 384 cases (a) and (c) for transmission, and cases (a) and (b) for reception. 385 A Domain Encryption implementation that conforms to this standard MUST 386 support cases (b) and (d), for transmission, and cases (c) and (d) for 387 reception. 389 The process of encryption and decryption is documented in CMS [3]. The 390 only additional requirement introduced by domain encryption and 391 decryption is for greater flexibility in the management of keys, as 392 described in the following subsections. 394 The mechanisms described below are applicable both to key agreement and 395 key transport systems, as documented in CMS. The phrase 'encryption 396 key' is used as a collective term to cover the key management keys used 397 by both techniques. 399 3.2.1 Domain Encryption Key Management 401 Domain Encryption is shown as cases (b) and (d) in the above table. 402 Domain Encryption uses a domain-wide encryption key from the sender's 403 domain. Information about this key is conveyed to the recipient by 404 one of two methods:- 406 1) Public information about this key is held in a certificate and 407 conveyed to the recipient(s) in the 'Certs' field of the 408 OriginatorInfo in the Envelope. 410 2) The recipient(s) looks up the key for the users domain by replacing 411 the originator's name within the address with the domain encryption 412 name [6]. 414 For example :- 416 a) If the originator is originator@foo.com then lookup key for 417 domain-encrypting-authority@foo.com. 419 b) If the originator is c=us;a=com;p=foo;s=originator then look up 420 key for c=us;a=com;p=foo;s=domain-encrypting-authority. 422 c) If the originator is c=gb;o=foo;cn=originator then look up key for 423 c=gb;o=foo;cn=domain-encrypting-authority. 425 An implementation conforming to this standard MUST support both methods. 427 The name in the encryption certificate may not match the name in any 428 encapsulated signatures. For example, when a message is signed by the 429 originator and is encrypted by the domain. An implementation that 430 conforms to this standard MUST allow for this possibility. This includes 431 both a client and a third party implementation. 433 3.2.2 Domain Decryption Key Management 435 Domain Decryption is shown as cases (c) and (d) in the above table. In 436 these cases, the encryption process uses a domain-wide encryption key 437 for the recipient(s)' domain. The selection of this key is achieved by 438 one of two methods: 440 1) The sending process explicitly searches for a certificate containing 441 the domain encryption key of the recipient(s)' domain. This is 442 achieved by mapping the recipient(s)' name to a domain name and then 443 locating the encryption certificate containing that domain name. 444 Mapping from recipient names to Domain names, and conventions for 445 domain names are outside the scope of this standard. 447 2) All the members of the receiving domain are issued with certificates 448 containing a single key. The private component of that key is held 449 by an entity in the domain that performs the decryption process 450 on their behalf. By selecting the appropriate certificate, a sending 451 process will implicitly encrypt for decryption by the Domain 452 Decryption process. 454 An implementation that conforms to this standard MUST support mechanism 455 (1). It may also support mechanism (2). This includes both a client and 456 a third party implementation. 458 4. Security Considerations 460 Domain Security Services provide a method for digitally 461 signing data, digesting data, encrypting data, and authenticating 462 data. 464 Implementations must protect the signer's private key. Compromise of 465 the signer's private key permits masquerade. 467 Implementations must protect the key management private key and the 468 content-encryption key. Compromise of the key management private key 469 may result in the disclosure of all messages protected with that key. 470 Similarly, compromise of the content-encryption key may result in 471 disclosure of the encrypted content. 473 5. References 475 [1] Ramsdell, B., "S/MIME Version 3 Message Specification", Internet 476 Draft draft-ietf-smime-msg-04, May 1998. 478 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [3] Housley, R., "Cryptographic Message Syntax", Internet Draft 482 draft-ietf-smime-cms-05.txt, March 1998. 484 [4] Hoffman, P., "Enhanced Security Services for S/MIME", Internet Draft 485 draft-ietf-smime-ess-06.txt, May 1998. 487 [5] International Telecommunications Union, Recommendation X.208, "Open 488 systems interconnection: specification of Abstract Syntax Notation 489 (ASN.1)", CCITT Blue Book, 1989. 491 [6] Ramsdell, B., "Role Names in X.509 Certificates", Internet Draft 492 draft-ramsdell-role-names, April 29 1998. 494 6. Authors' Addresses 496 Tim Dean 497 DERA Malvern 498 St. Andrews Road 499 Malvern 500 Worcs 501 WR14 3PS 503 Phone: +44 (0)1684 894239 504 Fax: +44 (0)1684 6113 505 Email: t.dean@eris.dera.gov.uk 507 William Ottaway 508 DERA Malvern 509 St. Andrews Road 510 Malvern 511 Worcs 512 WR14 3PS 514 Phone: +44 (0)1684 894079 515 Fax: +44 (0)1684 896113 516 Email: w.ottaway@eris.dera.gov.uk