idnits 2.17.1 draft-ietf-smime-ess-00.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-27) 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. ** 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 1419 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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.) ** There are 258 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 29 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '...lopedData object MUST be encapsulated ...' RFC 2119 keyword, line 150: '...request MUST be in the inside signatur...' RFC 2119 keyword, line 182: '...yLabel attribute MUST NOT be used in a...' RFC 2119 keyword, line 203: '...Inner or outer MUST BE authenticated...' RFC 2119 keyword, line 248: '...e receiving user agent software SHOULD...' (62 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 208 has weird spacing: '...entType eithe...' -- 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.) -- The document date (November 18, 1997) is 9657 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'MSP' on line 30 looks like a reference -- Missing reference section? 'SMIME2' on line 1247 looks like a reference -- Missing reference section? 'SMIME3' on line 1251 looks like a reference -- Missing reference section? 'CMS' on line 1304 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 596 looks like a reference -- Missing reference section? '0' on line 1216 looks like a reference -- Missing reference section? '1' on line 1217 looks like a reference -- Missing reference section? 'MTSABS' on line 1397 looks like a reference -- Missing reference section? 'MSP4' on line 1235 looks like a reference -- Missing reference section? 'ACP120' on line 1397 looks like a reference -- Missing reference section? '2' on line 1219 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Paul Hoffman 2 draft-ietf-smime-ess-00.txt Internet Mail Consortium 3 November 18, 1997 4 Expires in six months 6 Enhanced Security Services for S/MIME 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its areas, and its working 12 groups. Note that other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months and 16 may be updated, replaced, or obsoleted by other documents at any time. It 17 is inappropriate to use Internet-Drafts as reference material or to cite 18 them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 23 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 24 Coast). 26 1. Introduction 28 This document describes three optional security service extensions for 29 S/MIME. These services provide functionality that is similar to the Message 30 Security Protocol [MSP], but are useful in many other environments, 31 particularly business and finance. The services are: 32 - signed receipts 33 - security labels 34 - secure mailing lists 36 The services described here are extensions to S/MIME version 2 [SMIME2] and 37 S/MIME version 3 [SMIME3]. Most of this document can be used with S/MIME 38 version 2, which relies on PKCS #7 version 1.5 [PKCS7-1.5]. A small number 39 of the services require mechanisms described in Cryptographic Message 40 Syntax [CMS]. 42 This draft is being discussed on the ''ietf-smime'' mailing list. To 43 subscribe, send a message to: 44 ietf-smime-request@imc.org 45 with the single word 46 subscribe 47 in the body of the message. There is a Web site for the mailing list at 48 . 50 1.1 Triple Wrapping 52 Some of the features of each service use the concept of a "triple wrapped" 53 message. A triple wrapped message is one that has been signed, then 54 encrypted, then signed again. The signers of the inner and outer signatures 55 may be different entities or the same entity. Note that the S/MIME 56 specification does not limit the number of nested encapsulations, so there 57 may be more than three wrappings. 59 1.1.1 Purpose of Triple Wrapping 61 Not all messages need to be triple wrapped. Triple wrapping is used when a 62 signed and encrypted message must be signed, then encrypted, and then 63 processed by other agents that have to be authenticated by the final 64 recipient. 66 The inside signature is used for content integrity, non-repudiation with 67 proof of origin, and binding attributes (such as a security label) to the 68 original content. These attributes go from the originator to the recipient, 69 regardless of the number of intermediate entities such as mail list agents 70 that process the message. The authenticated attributes can be used for 71 access control to the inner body. Requests for signed receipts by the 72 originator are carried in the inside signature as well. 74 The encrypted body provides confidentiality, including confidentiality of 75 the attributes that are carried in the inside signature. 77 The outside signature provides authentication and integrity for information 78 that is processed hop-by-hop, where each hop is an intermediate entity such 79 as a mail list agent. The outer signature binds attributes (such as a 80 security label) to the encrypted body. These attributes can be used for 81 access control and routing decisions. 83 1.1.2 Steps for Triple Wrapping 85 The steps to create a triple wrapped message are: 87 1. Start with a message body, called the "original content". 89 2. Encapsulate the original content with the appropriate MIME headers. An 90 exception to this MIME encapsulation rule is that a signed receipt is not 91 put in MIME headers. 93 3. Sign the result of step 2 (the MIME headers and the original content), 94 turning it into a application/pkcs7-mime body part, and add the appropriate 95 MIME headers. The application/pkcs7-mime body part is called the "inside 96 signature". 98 4. Encrypt the result of step 3 (the MIME headers and the inside signature) 99 as a single block, turning it into another (larger) application/pkcs7-mime 100 body part, and add the appropriate MIME headers. The application/pkcs7-mime 101 body part is called the "encrypted body". 103 5. Sign the result of step 4 (the MIME headers and the encrypted body) as a 104 single block, turning it into another (even larger) application/pkcs7-mime 105 body part, and add the appropriate MIME headers. The application/pkcs7-mime 106 body part is called the "outside signature". 108 6. The result of step 5 (the MIME headers and the outside signature) is the 109 triple wrapped message. 111 1.2 Format of a Triple Wrapped Message 113 A triple wrapped message has eight layers of encapsulation. Starting from 114 the innermost layer and working outwards, the layers are: 116 Original content ("Hello, world!") 117 MIME entity 118 ContentInfo: data type 119 Inner SignedData block 120 MIME entity 121 ContentInfo: data type 122 EnvelopedData block 123 MIME entity 124 ContentInfo: data type 125 Outer SignedData block 126 MIME entity 128 Note that both the inner and outer signed blocks use the SignedData 129 construct of S/MIME. As defined in [PKCS7-1.5] and [CMS], each SignedData 130 and EnvelopedData object MUST be encapsulated by a ContentInfo SEQUENCE. 131 There is no purpose to use the multipart/signed format in inner case 132 because it is known that the recipient is known to be able to process 133 S/MIME messages (because they decrypted the middle wrapper). There may be a 134 purpose in using multipart/signed in the outer layer, but only so that a 135 non-S/MIME agent could see that the next inner layer is encrypted. However, 136 this is not of great value, since all it shows the recipient is that he or 137 she wouldn't have been able to read the message anyways. 139 1.3 Security Services and Triple Wrapping 141 The three security services described in this document are used with triple 142 wrapped messages in different ways. This section briefly describes the 143 relationship of each service with triple wrapping; the other sections of 144 the document go into greater detail. 146 1.3.1 Signed Receipts and Triple Wrapping 148 A signed receipt may be requested in any SignedData object. However, if a 149 signed receipt is requested for a triple wrapped message, the receipt 150 request MUST be in the inside signature, not in the outside signature. A 151 secure mailing list agent may change the receipt policy in the outside 152 signature of a triple wrapped message when that message is processed by the 153 mailing list. 155 Note: the signed receipts and receipt requests described in this draft 156 differ from those described in the work done by the IETF Receipt 157 Notification Working Group. The output of that Working Group, when 158 finished, is not expected to work well with triple wrapped messages as 159 described in this document. 161 1.3.2 Security Labels and Triple Wrapping 163 A security label may be included in the authenticated attributes of a 164 SignedData object. A security label attribute may be included in either the 165 inner signature, outer signature, or both. 167 The inner security label is used for access control decisions related to 168 the plaintext original content. The inner signature provides authentication 169 and cryptographically protects the original signer's security label that is 170 on the inside body. This strategy facilitates the forwarding of messages 171 because the original signer's security label is included in the SignedData 172 block which can be forwarded to a third party that can verify the inner 173 signature which will cover the inner security label. The confidentiality 174 security service can be applied to the inner security label by encrypting 175 the entire inner SignedData block within an EnvelopedData block. 177 A security label may also be included in the authenticated attributes of 178 the outer SignedData block which will include the sensitivities of the 179 encrypted message. The outer security label is used for access control and 180 routing decisions related to the encrypted message. Note that a security 181 label attribute can only be used in an authenticatedAttributes block. A 182 securityLabel attribute MUST NOT be used in an EnvelopedData or 183 unauthenticated attributes. 185 1.3.3 Secure Mailing Lists and Triple Wrapping 187 Secure mail list message processing depends on the structure of S/MIME 188 layers present in the message sent to the mail list agent. The agent never 189 changes the data that was hashed to form the inner signature, if such a 190 signature is present. If an outer signature is present, then the agent will 191 modify the data that was hashed to form that outer signature. In all cases, 192 the agent adds or updates an mlExpansionHistory attribute to document the 193 agent's processing, and ultimately adds or replaces the outer signature on 194 the message to be distributed. 196 1.3.4 Placement of Attributes 198 Certain attributes should be placed in the inner or outer SignedData 199 message; some attributes can be in either. Further, some attributes must be 200 authenticated, while authentication is optional for others. The following 201 table summarizes the recommendation of this profile. 203 Attribute Inner or outer MUST BE authenticated 204 contentHints either no 205 contentIdentifier either no 206 contentType either no 207 counterSignature either no 208 encapsulatedContentType either no 209 messageDigest either yes 210 mlExpansionHistory outer only yes 211 receiptRequest inner only yes 212 signingTime either yes 213 smimeCapabilities either yes 214 securityLabel either yes 216 Note that the inner and outer signatures are for different senders, so that 217 the same attribute in the two signatures could lead to very different 218 consequences. 220 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique 221 identifier assigned to the message. EncapsulatedContentType is an attribute 222 used to carry the content type of the encapsulated content. These 223 attributes are needed in addition to the fields carried in the 224 receiptRequest attribute. 226 1.4 Object Identifiers 228 The object identifiers for many of the objects described in this draft are 229 found in the registry kept at . 230 When this draft moves to standards track within the IETF, it is intended 231 that the IANA will maintain this registry. 233 2. Signed Receipts 235 Returning a signed receipt provides proof of delivery to the originator of 236 a message and allows the originator to demonstrate to a third party that 237 the recipient received the message. This receipt is bound to the original 238 message through the signature; consequently, this service may be requested 239 only if a message is signed. The receipt sender may optionally also encrypt 240 a receipt to provide confidentiality between the receipt sender and the 241 receipt recipient. 243 2.1 Signed Receipt Concepts 245 The originator of a message may request a signed receipt from the message's 246 recipients. The request is indicated by adding a receiptRequest attribute 247 to the authenticatedAttributes field of the SignerInfo object for which the 248 receipt is requested. The receiving user agent software SHOULD 249 automatically create a signed receipt when requested to do so, and return 250 the receipt in accordance with mailing list expansion options, local 251 security policies, and configuration options. 253 Because receipts involve the interaction of two parties, the terminology 254 can sometimes be confusing. In this section, the "sender" is the agent that 255 sent the original message that included a request for a receipt. The 256 "receiver" is the party that received that message and generated the 257 receipt. 259 The steps in a typical transaction are: 261 1. Sender creates a signed message including a receipt request attribute 262 (Section 2.2). 264 2. Sender transmits the resulting message to the recipient or recipients. 266 3. Recipient receives message and determines if there is a valid signature 267 and receipt request in the message (Section 2.3). 269 4. Recipient creates a signed receipt (Section 2.4). 271 5. Recipient transmits the resulting signed receipt message to the sender 272 (Section 2.5). 274 6. Sender receives the message and validates that it contains a signed 275 receipt for the original message (Section 2.6). This validation relies on 276 the sender having kept a digest value of the original message (Section 2.7) 277 or a copy of the original message. 279 The ASN.1 syntax for the receipt request is given in Section 2.8; the ASN.1 280 syntax for the receipt is given in Section 2.9. 282 Note that an agent SHOULD remember when it has sent a receipt so that it 283 can avoid re-sending a receipt each time it processes the message. 285 2.2 Receipt Request Creation 287 Multi-layer S/MIME messages may contain multiple SignedData layers. 288 However, receipts may be requested only for the innermost SignedData layer 289 in a multi-layer S/MIME message, such as a triple wrapped message. Only one 290 receiptRequest attribute can be included in the authenticatedAttributes of 291 a SignerInfo. A sender requests receipts by placing a receiptRequest 292 attribute in the authenticated attributes of a signerInfo as follows: 294 1. A receiptRequest data structure is created. 296 2. The encapsulated content type is optionally noted in the 297 encapsulatedContentType field. 299 3. A signed content identifier for the message is created and assigned to 300 the signedContentIdentifier field. The signedContentIdentifier is used to 301 associate the signed receipt with the message requesting the signed 302 receipt. 304 4. The entities requested to return a signed receipt are noted in the 305 receiptsFrom field. 307 5. If receipts are to be returned to entities other than or in addition to 308 the message originator, a list of receipt recipients is assigned to the 309 receiptsTo field. The originator's name(s) MUST be included in the 310 receiptsTo list if receipt recipients in addition to the originator are 311 requested. 313 6. The completed receiptRequest attribute is placed in the 314 authenticatedAttributes field of the SignerInfo object. 316 2.2.1 Multiple Receipt Requests 318 There can be multiple SignerInfos within a SignedData object, and each 319 SignerInfo may include authenticatedAttributes. Therefore, a single 320 SignedData object may include multiple SignerInfos, each SignerInfo having 321 a receiptRequest attribute. For example, an originator can send a signed 322 message with two SignerInfos, one containing a DSS signature, the other 323 containing an RSA signature. 325 Each recipient SHOULD return only one signed receipt. 327 Not all of the SignerInfos need to include receipt requests, but in all of 328 the SignerInfos that do conatin receipt requests, the receipt requests MUST 329 be identical. 331 2.3 Receipt Request Processing 333 A receiptRequest is associated only with the SignerInfo object in which the 334 receipt request attribute is directly attached. Processing software SHOULD 335 examine the authenticatedAttributes field of each of the SignerInfos for 336 which it verifies a signature in the innermost signedData object to 337 determine if a receipt is requested. This may result in the receiving agent 338 processing multiple receiptRequest attributes included in a single 339 SignedData object. Because all receiptRequest attributes in a SignedData 340 object must be identical, the receiving application fully processes (as 341 described in the following paragraphs) the first receiptRequest that it 342 encounters in a SignerInfo that it can verify, and it then ensures that all 343 other receiptRequests are identical to the first one encountered. 345 If a receiptRequest attribute is absent from the authenticated attributes, 346 then a signed receipt has not been requested from any of the message 347 recipients and MUST NOT be created. If a receiptRequest attribute is 348 present in the authenticated attributes, then a signed receipt has been 349 requested from some or all of the message recipients. Note that in some 350 cases, a receiving agent might receive two almost-identical messages, one 351 with a receipt request and the other without one. In this case, the 352 receiving agent may choose whether or not to send a receipt. 354 If a receiptRequest attribute is present in the authenticated attributes, 355 the following process SHOULD be used to determine if a message recipient 356 has been requested to return a signed receipt. 358 1. If an mlExpansionHistory attribute is present in the outermost 359 signedData block, do one of the following two steps, based on the absence 360 or presence of mlReceiptPolicy: 362 1.1. If an mlReceiptPolicy value is absent from the last MLData 363 element, a Mail List receipt policy has not been specified and 364 the processing software SHOULD examine the receiptRequest 365 attribute value to determine if a receipt should be created and 366 returned. 368 1.2. If an mlReceiptPolicy value is present in the last MLData 369 element, do one of the following two steps, based on the value 370 of mlReceiptPolicy: 372 1.2.1. If the mlReceiptPolicy value is none, then the 373 receipt policy of the Mail List supersedes the originator's 374 request for a signed receipt and a signed receipt MUST NOT 375 be created. 377 1.2.2. If the mlReceiptPolicy value is insteadOf or 378 inAdditionTo, the processing software SHOULD examine the 379 receiptsFrom value from the receiptRequest attribute to 380 determine if a receipt should be created and returned. If a 381 receipt is created, the insteadOf and inAdditionTo fields 382 identify entities that SHOULD be sent the receipt instead of 383 or in addition to the originator. 385 2. If the receiptsFrom value of the receiptRequest attribute is allOrNone, 386 do one of the following three steps based on the value of allOrNone. 388 2.1. If the value of allOrNone is noReceipt, then a signed 389 receipt MUST NOT be created. 391 2.2. If the value of allOrNone is allReceipts, then a signed 392 receipt SHOULD be created. 394 2.3. If the value of allOrNone is firstTierRecipients, do one of 395 the following two steps based on the presence of an 396 mlExpansionHistory attribute: 398 2.3.1. If an mlExpansionHistory attribute is present, then 399 this recipient is not a first tier recipient and a signed 400 receipt MUST NOT be created. 402 2.3.2. If an mlExpansionHistory attribute is not present, 403 then a signed receipt SHOULD be created. 405 3. If the receiptsFrom value of the receiptRequest attribute is a 406 receiptList: 408 3.1. If receiptList contains one of the GeneralNames of the 409 recipient, then a signed receipt should be created. 411 3.2. If receiptList does not contain one of the GeneralNames of 412 the recipient, then a signed receipt MUST NOT be created. 414 A flow chart for the above steps to be executed for each signerInfo for 415 which the receiving agent verifies the signature would be: 417 0. Receipt Request attribute present? 418 YES -> 1. 419 NO -> STOP 420 1. Has mlExpansionHistory? 421 YES -> 1.1. 422 NO -> 2. 423 1.1. mlReceiptPolicy absent? 424 YES -> examine receiptRequest, then -> 2. 425 NO -> 1.2. 426 1.2. Pick based on value of mlReceiptPolicy. 427 none -> 1.2.1. 428 insteadOf or inAdditionTo -> 1.2.2. 429 1.2.1. Use ML's policy, then -> STOP 430 1.2.2. Examine receiptsFrom for name, determine if a receipt 431 should be created, create it if required, then -> STOP. 432 2. Is value of receiptsFrom allOrNone. 433 YES -> Pick based on value of allOrNone. 434 noReceipt -> 2.1. 435 allReceipts -> 2.2. 436 firstTierRecipients -> 2.3. 437 NO -> 3. 438 2.1. STOP. 439 2.2. Create a receipt, then -> STOP. 440 2.3. Has mlExpansionHistory? 441 YES -> 2.3.1. 442 NO -> 2.3.2. 443 2.3.1. STOP. 444 2.3.2. Create a receipt, then -> STOP. 445 3. Is receiptsFrom value of receiptRequest a receiptList? 446 YES -> 3.1. 447 NO -> STOP. 448 3.1. Does receiptList contain the recipient? 449 YES -> Create a receipt, then -> STOP. 450 NO -> 3.2. 451 3.2. STOP. 453 2.4 Receipt Creation 455 A signed receipt is created as follows: 457 1. The signature of the original message is validated. A receipt MUST NOT 458 be created for a message with an invalid signature. 460 2. A Receipt structure is created. 462 2.1. The value of the version field is set to 1. 464 2.2. The encapsulatedContentType and signedContentIdentifier 465 values are copied from the SignerInfo's receiptRequest 466 attribute to the corresponding fields in the Receipt structure. 468 2.3. The signatureValue (i.e. digital signature or MAC) from the 469 original message SignerInfo structure is copied to the 470 originatorSignatureValue field in the receipt structure. 472 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1. 474 4. D1 is concatenated to the end of the ASN.1 encoded original message 475 content to produce a data stream, D2. The "ASN.1 encoded original message 476 content" is the data composing the SignedData contentInfo content ANY. For 477 example, if SignedData is being used to sign MIME-encapsulated data, then 478 the signedData ContentInfo content ANY field will include a Data content 479 type (i.e. OCTET STRING). In that case, the "ASN.1 encoded original message 480 content" is the DER encoded value of the Data OCTET STRING. The Data OCTET 481 STRING tag and length octets are not included in the hashing. 483 5. D2 is digested to produce a digest value, H2, for the receipt. 485 6. The Receipt structure MUST be directly included within a SignedData 486 structure using H2 as the message digest to be signed. This results in a 487 single ASN.1 encoded object composed of a SignedData including the Receipt 488 content type. The Receipt MUST NOT be encapsulated in a MIME header or any 489 other header prior to being encoded as part of the SignedData object. 491 6.1. A contentHints attribute is created and SHOULD be added to 492 the SignerInfo structure's authenticated attributes. 494 The signed message that contains the signed receipt SHOULD have a 495 signingTime attribute so that the recipient knows when the receipt was 496 created. 498 2.5 Determining the Recipients of the Signed Receipt 500 If a signed receipt was created by the process described in the sections 501 above, then the software MUST use the following process to determine to 502 whom the signed receipt should be sent. 504 1. If the receiptsTo is present in the Receipt Request attribute, then the 505 software initiates the sequence of recipients with the value(s) of 506 receiptsTo; otherwise, the software initiates the sequence of recipients 507 with the signer (that is, the originator) of the SignerInfo that includes 508 the Receipt Request attribute. 510 2. If the MlExpansionHistory attribute is present in the outer SignedData 511 block, and the last MLData contains an MLReceiptPolicy value of insteadOf, 512 then the software replaces the sequence of recipients with the value(s) of 513 insteadOf. 515 3. If the MlExpansionHistory attribute is present in the outer SignedData 516 block and the last MLData contains an MLReceiptPolicy value of 517 inAdditionTo, then the software adds the value(s) of inAdditionTo to the 518 sequence of recipients. 520 2.6 Receipt Validation 522 A receipt is validated as follows: 524 1. The signed receipt is communicated as a single ASN.1 encoded object 525 composed of a SignedData directly including a Receipt content type. ASN.1 526 decode the signedData object including the Receipt. 528 2. Retrieve the encapsulatedContentType and signedContentIdentifier values 529 from the Receipt data structure to identify the message being receipted. 531 3. Acquire H2 based on the message identification information. 533 3.1. If H2 has been saved locally, it must be located and 534 retrieved. 536 3.2. If H2 has not been saved, the original message must be 537 located and H2 must be recreated from the original message and 538 related information as described in the "Receipt Digest Value" 539 section. 541 4. Obtain the alleged receipt signature value from the receipt's 542 signatureValue field and validate the signature using the retrieved 543 signature value and H2, the calculated hash value. 545 [More is needed here or in an appendix detailing how to do this for each 546 kind of signature.] 548 2.7 Receipt Digest Value 550 The requester of a signed receipt must retain either the message for which 551 a receipt is being requested, or a receipt digest value (hash value) 552 derived from the message for later receipt validation. Retaining the digest 553 value usually requires less local storage than retaining a message because 554 digest values typically contain fewer bytes than the messages they are 555 derived from. 557 Message content and message identity information are used to calculate a 558 receipt digest value as follows: 560 1. The encapsulated content type, signed content identifier, and encrypted 561 digest value (signature value) derived from the message content are copied 562 from the SignerInfo including the receiptRequest into a Receipt structure. 563 The Receipt structure version field is set to 1. 565 2. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1, 566 as described in the "Receipt Creation" section. 568 3. D1 is concatenated to the end of the ASN.1 encoded original message 569 content to produce a data stream, D2. 571 4. D2 is digested to produce a digest value, H2, for the receipt. 573 2.8 Receipt Request Syntax 575 A receiptRequest attribute value has ASN.1 type receiptRequest. Use the 576 receiptRequest attribute only within the authenticated attributes 577 associated with a signed message. 579 receiptRequest ::= SEQUENCE { 580 encapsulatedContentType EncapsulatedContentType OPTIONAL, 581 signedContentIdentifier ContentIdentifier, 582 receiptsFrom ReceiptsFrom, 583 receiptsTo SEQUENCE (SIZE (1..ub-receiptsTo)) 584 OF GeneralNames OPTIONAL } 585 ub-receiptsTo INTEGER ::= 16 587 The encapsulatedContentType field identifies the content type of the 588 original message. In BuiltinContentType, the values of 0 and 1 have been 589 deprecated and SHOULD NOT be used. 591 EncapsulatedContentType ::= CHOICE { 592 built-in BuiltinContentType, 593 external ExternalContentType, 594 externalWithSubtype ExternalContentWithSubtype } 596 BuiltinContentType ::= [APPLICATION 6] INTEGER { 597 unidentified (0), 598 external (1), 599 interpersonal-messaging-1984 (2), 600 interpersonal-messaging-1988 (22), 601 edi-messaging (35), 602 voice-messaging (40)} (0..ub-built-in-content-type) 603 ub-built-in-content-type INTEGER ::= 32767 605 ExternalContentType ::= OBJECT IDENTIFIER 607 ExternalContentWithSubtype ::= SEQUENCE { 608 external ExternalContentType, 609 subtype INTEGER } 611 A signedContentIdentifier MUST be created by the message originator when 612 creating a receipt request. To ensure global uniqueness, the minimal 613 signedContentIdentifier SHOULD contain a concatenation of user-specific 614 identification information (such as a user name or public keying material 615 identification information), a GeneralizedTime string, and a random number. 617 The receiptsFrom field is used by the originator to specify the recipients 618 requested to return a signed receipt. A CHOICE is provided to allow 619 specification of: 620 - no receipts are requested 621 - receipts from all recipients are requested 622 - receipts from first tier (recipients that did not receive the 623 message as members of a mailing list) recipients are requested 624 - receipts from a specific list of recipients are requested 626 ReceiptsFrom ::= CHOICE { 627 allOrNone [0] AllOrNone, 628 receiptList [1] SEQUENCE OF GeneralNames } 630 AllOrNone ::= INTEGER { 631 noReceipt (0), 632 allReceipts (1), 633 firstTierRecipients (2) } 635 The receiptsTo field is used by the originator to identify the user(s) to 636 whom the identified recipient should send signed receipts. Use the field 637 only if receipts must be sent to users other than, or in addition to, the 638 originator. If the receiptsTo field is used to designate recipients in 639 addition to the originator, then the originator's name(s) MUST be included 640 in the receiptsTo list. 642 2.9 Receipt Syntax 644 Receipts are represented using a new content type, receipt. The receipt 645 content type shall have ASN.1 type Receipt. Receipts must be encapsulated 646 within a SignedData message. 648 Receipt := SEQUENCE { 649 version Version, 650 encapsulatedContentType EncapsulatedContentType OPTIONAL, 651 signedContentIdentifier OCTET STRING, 652 originatorSignatureValue OCTET STRING } 654 The version field defines the syntax version number, which is 1 for this 655 version of the standard. 657 The encapsulatedContentType and signedContentIdentifier fields are copied 658 from the receiptRequest attribute of the SignerInfo contained within the 659 message being receipted, and are used to link the receipt to the original 660 signed message. The originatorSignatureValue field contains the 661 signatureValue copied from the SignerInfo requesting the signed receipt. 663 2.10 Content Hints 665 Many applications find it useful to have information that describes the 666 innermost signed content of a multi-layer message available on the 667 outermost signature layer. The contentHints attribute provides such 668 information. 670 Content-hints attribute values have ASN.1 type contentHints. 672 contentHints ::= SEQUENCE { 673 contentDescription DirectoryString [ ub-conDesc } OPTIONAL, 674 receipt BOOLEAN DEFAULT FALSE } 676 ub-conDesc INTEGER ::= 128 678 DirectoryString { INTEGER : maxSize } ::= CHOICE { 679 teletexString TeletexString (SIZE (1..maxSize)), 680 printableString PrintableString (SIZE (1..maxSize)), 681 bmpString BMPString (SIZE (1..maxSize)), 682 universalString UniversalString (SIZE (1..maxSize)) } 684 Messages that contain a signed receipt MUST include this attribute with the 685 receipt value set to TRUE. The contentDescription field may be used to 686 provide information that the recipient may use to select protected messages 687 for processing, such as a message subject. 689 3. Security Labels 691 This section describes the syntax to be used for security labels that can 692 optionally be associated with S/MIME encapsulated data. A security label is 693 a set of security information regarding the sensitivity of the content that 694 is protected by S/MIME encapsulation. 696 "Authorization" is the act of granting rights and/or privileges to users 697 permitting them access to an object. "Access control" is a means of 698 enforcing these authorizations. The sensitivity information in a security 699 label can be compared with a user's authorizations to determine if the user 700 is allowed to access the content that is protected by S/MIME encapsulation. 702 Security labels may be used for other purposes such as a source of routing 703 information. The labels are often priority based ("secret", "confidential", 704 "restricted", and so on) or role-based, describing which kind of people can 705 see the information ("patient's health-care team", "medical billing 706 agents", "unrestricted", and so on). 708 3.1 Security Label Processing Rules 710 A sending agent may include a security label attribute in the authenticated 711 attributes of a signedData object. A receiving agent examines the security 712 label on a recevied message and determines whether or not the recipinet is 713 allowed to see the contents of the message. 715 3.1.1 Adding Security Labels 717 A sending agent that is using security labels MUST put the security label 718 attribute in the authenticatedAttributes field of a SignerInfo block. The 719 security label attribute MUST NOT be included in the unauthenticated 720 attributes. Integrity and authentication security services MUST be applied 721 to the security label, therefore it MUST be included as an authenticated 722 attribute, if used. This causes the security label attribute to be part of 723 the data that is hashed to form the SignerInfo signature value. A 724 SignerInfo block MUST NOT have more than one security label authenticated 725 attribute. 727 When there are multiple SignedData blocks applied to a message, a security 728 label attribute may be included in either the inner signature, outer 729 signature, or both. A security label authenticated attribute may be 730 included in a authenticatedAttributes field within the inner SignedData 731 block. The inner security label will include the sensitivities of the 732 original content and will be used for access control decisions related to 733 the plaintext encapsulated content. The inner signature provides 734 authentication of the inner security label and cryptographically protects 735 the original signer's inner security label of the original content. 737 When the originator signs the plaintext content and authenticated 738 attributes, the inner security label is bound to the plaintext content. An 739 intermediate entity cannot change the inner security label without 740 invalidating the inner signature. The confidentiality security service can 741 be applied to the inner security label by encrypting the entire inner 742 signedData object within an EnvelopedData block. 744 A security label authenticated attribute may also be included in a 745 authenticatedAttributes field within the outer SignedData block. The outer 746 security label will include the sensitivities of the encrypted message and 747 will be used for access control decisions related to the encrypted message 748 and for routing decisions. The outer signature provides authentication of 749 the outer security label (as well as for the encapsulated content which may 750 include nested S/MIME messages). 752 There can be multiple SignerInfos within a SignedData object, and each 753 SignerInfo may include authenticatedAttributes. Therefore, a single 754 SignedData object may include multiple security labels, each SignerInfo 755 having a securityLabel attribute. For example, an originator can send a 756 signed message with two SignerInfos, one containing a DSS signature, the 757 other containing an RSA signature. Not all of the SignerInfos need to 758 include security labels, but in all of the SignerInfos that do conatin 759 security labels, the security labels MUST be identical. 761 A recipient SHOULD process a securityLabel attribute only if the recipient 762 can verify the signature of the SignerInfo which covers the securityLabel 763 attribute. A recipient SHOULD NOT use a security label that the recipient 764 cannot authenticate. 766 3.1.2 Processing Security Labels 768 A receiving agent that processes security labels MUST process the 769 securityLabel attribute, if present, in each SignerInfo in the SignedData 770 object for which it verifies the signature. This may result in the 771 receiving agent processing multiple security labels included in a single 772 SignedData object. Because all security labels in a SignedData object must 773 be identical, the receiving application processes (such as performing 774 access control) on the first securityLabel that it encounters in a 775 SignerInfo that it can verify, and then ensures that all other 776 securityLabels are identical to the first one encountered. 778 A receiving agent that processes security labels SHOULD have a local policy 779 about whether or not to show the inner content of an incoming messages that 780 has a security label with a security policy identifier that the processing 781 software does not recognize. If the receiving agent does not recognize the 782 securityLabel security-policy-identifier value, it SHOULD stop processing 783 the message and indicate an error. 785 3.2 Syntax of securityLabel 787 The securityLabel syntax is copied directly from [MTSABS] ASN.1 module. 788 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS 789 ::=".) Further, the securityLabel syntax is identical to that used in 790 [MSP4] and [ACP120]. 792 securityLabel ::= SET { 793 security-policy-identifier SecurityPolicyIdentifier OPTIONAL, 794 security-classification SecurityClassification OPTIONAL, 795 privacy-mark PrivacyMark OPTIONAL, 796 security-categories SecurityCategories OPTIONAL } 798 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 800 SecurityClassification ::= INTEGER { 801 unmarked (0), 802 unclassified (1), 803 restricted (2), 804 confidential (3), 805 secret (4), 806 top-secret (5) } (0..ub-integer-options) 808 ub-integer-options INTEGER ::= 256 810 PrivacyMark ::= PrintableString (SIZE (1..ub-privacy-mark-length)) 812 ub-privacy-mark-length INTEGER ::= 128 814 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 815 SecurityCategory 817 ub-security-categories INTEGER ::= 64 819 SecurityCategory ::= SEQUENCE { 820 type [0] OBJECT IDENTIFIER, 821 value [1] ANY -- defined by type} 823 -Note: The aforementioned SecurityCategory syntax produces identical 824 -hex encodings as the following SecurityCategory syntax that is 825 -documented in the X.411 specification: 826 - 827 -SecurityCategory ::= SEQUENCE { 828 - type [0] SECURITY-CATEGORY, 829 - value [1] ANY DEFINED BY type } 830 - 831 -SECURITY-CATEGORY MACRO ::= 832 -BEGIN 833 -TYPE NOTATION ::= type | empty 834 -VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 835 -END 837 3.3 Security Label Components 839 This section gives more detail on the the various components of the 840 securityLabel syntax. 842 3.3.1 Security Policy Identifier 844 A security policy is a set of criteria for the provision of security 845 services. The securityLabel security-policy-identifier is used to identify 846 the security policy in force to which the security label relates. It 847 indicates the semantics of the other security label components. Even though 848 the securityLabel security-policy-identifier is an optional field, all 849 security labels used with S/MIME messages MUST include the 850 security-policy-identifier. 852 3.3.2 Security Classification 854 This specification defines the use of the Security Classification field 855 exactly as is specified in the X.411 Recommendation, which states in part: 857 If present, a security-classification may have one of a hierarchical 858 list of values. The basic security-classification hierarchy is defined 859 in this Recommendation, but the use of these values is defined by the 860 security-policy in force. Additional values of security-classification, 861 and their position in the hierarchy, may also be defined by a 862 security-policy as a local matter or by bilateral agreement. The basic 863 security-classification hierarchy is, in ascending order: unmarked, 864 unclassified, restricted, confidential, secret, top-secret. 866 This means that the security policy in force (identified by the 867 securityLabel security-policy-identifier) defines the 868 SecurityClassification integer values and their meanings. 870 An organization can develop its own security policy that defines the 871 SecurityClassification INTEGER values and their meanings. However, the 872 general interpretation of the X.411 specification is that the values of 0 873 thru 5 are reserved for the "basic hierarchy" values of unmarked, 874 unclassified, restricted, confidential, secret, and top-secret. Note that 875 X.411 does not provide the rules for how these values are used to label 876 data and how access control is performed using these values. 878 There is no universal definition of the rules for using these "basic 879 hierarchy" values. Each organization (or group of organizations) will 880 define a security policy which documents how the "basic hierarchy" values 881 are used (if at all) and how access control is enforced (if at all) within 882 their domain. 884 Therefore, the security-classification value MUST be accompanied by a 885 security-policy-identifier value to define the rules for its use. For 886 example, a company's "secret" classification may convey a different meaning 887 than the US Government "secret" classification. In summary, a security 888 policy SHOULD NOT use integers 0 through 5 for other than their X.411 889 meanings, and SHOULD instead use other values in a hierarchical fashion. 891 Note that the set of valid security-classification values MUST be 892 hierarchical, but these values do not necessarily need to be in ascending 893 numerical order. Further, the values do not need to be contiguous. 895 For example, in the Defense Message System 1.0 security policy, the 896 security-classification value of 11 indicates Sensitive-But-Unclassified 897 and 5 indicates top-secret. The hierarchy of sensistivity ranks top-secret 898 as more sensitive than Sensitive-But-Unclassified even though the numerical 899 value of top-secret is less than Sensitive-But-Unclassified. 901 (Of course, if security-classification values are both hierarchical and in 902 ascending order, a casual reader of the security policy is more likely to 903 understand it.) 905 An example of a security policy that does not use any of the X.411 values 906 might be: 907 10 -- anyone 908 15 -- Morgan Corporation and its contractors 909 20 -- Morgan Corporation employees 910 25 -- Morgan Corporation board of directors 912 An example of a security policy that uses part of the X.411 hierarchy might 913 be: 914 0 -- unmarked 915 1 -- unclassified, can be read by everyone 916 2 -- restricted to Timberwolf Productions staff 917 6 -- can only be read to Timberwolf Productions executives 919 3.3.3 Privacy Mark 921 If present, the securityLabel privacy-mark is not used for access control. 922 The content of the securityLabel privacy-mark may be defined by the 923 security policy in force (identified by the securityLabel 924 security-policy-identifier) which may define a list of values to be used. 925 Alternately, the value may be determined by the originator of the 926 security-label. 928 3.3.4 Security Categories 930 If present, the securityLabel security-categories provide further 931 granularity for the sensitivity of the message. The security policy in 932 force (identified by the securityLabel security-policy-identifier) is used 933 to indicate the syntaxes that are allowed to be present in the 934 securityLabel security-categories. Alternately, the security-categories and 935 their values may be defined by bilateral agreement. 937 4. Mail List Management 939 Sending agents must create recipient-specific data structures for each 940 recipient of an encrypted message. This process can impair performance for 941 messages sent to a large number of recipients. Thus, Mail List Agents 942 (MLAs) that can take a single message and perform the recipient-specific 943 encryption for every recipient are often desired. 945 An MLA appears to the message originator as a normal message recipient, but 946 the MLA acts as a message expansion point for a Mail List (ML). The sender 947 of a message directs the message to the MLA, which then redistributes the 948 message to the members of the ML. This process offloads the per-recipient 949 processing from individual user agents and allows for more efficient 950 management of large MLs. MLs are true message recipients served by MLAs 951 that provide cryptographic and expansion services for the mailing list. 953 In addition to cryptographic handling of messages, secure mailing lists 954 also have to prevent mail loops. A mail loop is where one mailing list is a 955 member of a second mailing list, and the second mailing list is a member of 956 the first. A message will go from one list to the other in a 957 rapidly-cascading sucession of mail that will be distributed to all other 958 members of boths lists. 960 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the 961 outer signature of a triple wrapped message. The mlExpansionHistory 962 attribute is essentially a list of every MLA that has processed the 963 message. If an MLA sees its own unique entity identifier in the list, it 964 knows that a loop has been formed, and does not send the message to the 965 list again. 967 4.1 Mail List Expansion 969 Mail list expansion processing is noted in the value of the 970 mlExpansionHistory attribute, located in the authenticated attributes of 971 the MLA's SignerInfo block. The MLA creates or updates the authenticated 972 mlExpansionHistory attribute value each time the MLA expands and signs a 973 message for members of a mail list. 975 The MLA MUST add an MLData record containing the MLA's identification 976 information, date and time of expansion, and optional receipt policy to the 977 end of the mail list expansion history sequence. If the mlExpansionHistory 978 attribute is absent, then the MLA MUST add the attribute and the current 979 expansion becomes the first element of the sequence. If the 980 mlExpansionHistory attribute is present, then the MLA MUST add the current 981 expansion information to the end of the existing MLExpansionHistory 982 sequence. Only one mlExpansionHistory attribute can be included in the 983 authenticatedAttributes of a SignerInfo. 985 Note that if the mlExpansionHistory attribute is absent, then the recipient 986 is a first tier message recipient. 988 There can be multiple SignerInfos within a SignedData object, and each 989 SignerInfo may include authenticatedAttributes. Therefore, a single 990 SignedData object may include multiple SignerInfos, each SignerInfo having 991 a mlExpansionHistory attribute. For example, an originator can send a 992 signed message with two SignerInfos, one containing a DSS signature, the 993 other containing an RSA signature. Not all of the SignerInfos need to 994 include mlExpansionHistory attributes, but in all of the SignerInfos that 995 do conatin mlExpansionHistory attributes, the mlExpansionHistory attributes 996 MUST be identical. 998 A recipient SHOULD only process an mlExpansionHistory attribute if the 999 recipient can verify the signature of the SignerInfo which covers the 1000 attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which 1001 the recipient cannot authenticate. 1003 When receiving a message that includes an outer SignedData object, a 1004 receiving agent that processes mlExpansionHistory attributes MUST process 1005 the mlExpansionHistory attribute, if present, in each SignerInfo in the 1006 SignedData object for which it verifies the signature. This may result in 1007 the receiving agent processing multiple mlExpansionHistory attributes 1008 included in a single SignedData object. Because all mlExpansionHistory 1009 attributes must be identical, the receiving application processes the first 1010 mlExpansionHistory attribute that it encounters in a SignerInfo that it can 1011 verify, and then ensures that all other mlExpansionHistory attributes are 1012 identical to the first one encountered. 1014 4.1.1 Detecting Mail List Expansion Loops 1016 Prior to expanding a message, the MLA examines the value of any existing 1017 mail list expansion history attribute to detect an expansion loop. An 1018 expansion loop exists when a message expanded by a specific MLA for a 1019 specific mail list is redelivered to the same MLA for the same mail list. 1021 Expansion loops are detected by examining the mailListIdentifier field of 1022 each MLData entry found in the mail list expansion history. If an MLA finds 1023 its own identification information, then the MLA must discontinue expansion 1024 processing and should provide warning of an expansion loop to a human mail 1025 list administrator. The mail list administrator is responsible for 1026 correcting the loop condition. 1028 4.2 Mail List Agent Processing 1030 MLA message processing depends on the structure of S/MIME layers found in 1031 the processed message. In all cases, the MLA ultimately signs the message 1032 and adds or updates an mlExpansionHistory attribute to document MLA 1033 processing. In all cases, the MLA may need to perform access control before 1034 distributing the message to mail list members if the message contains a 1035 SignedData block and an associated securityLabel attribute. If a 1036 securityLabel authenticated attribute is used for access control, then the 1037 signature of the signerInfo block including the securityLabel authenticated 1038 attribute MUST be verified before using the security label. The MLA should 1039 continue parsing the MIME-encapsulated message to determine if there is a 1040 security label associated with an encapsulated SignedData object. This may 1041 include decrypting an EnvelopedData object to determine if an encapsulated 1042 SignedData object includes a securityLabel attribute. 1044 Each MLA that processes the message creates its own mlExpansionHistory and 1045 adds it to the sequence of mlExpansionHistory attributes already in the 1046 message. An MLA MUST NOT modify the mlExpansionHistory created by a MLA 1047 that previously processed the message. Each MLA copies the sequence of 1048 mlExpansionHistory attributes created by the MLAs that previously processed 1049 the message into the newly constructed expanded message, and adds its own 1050 mlExpansionHistory as the last element of the sequence. 1052 The processing used depends on the type of the outermost layer of the 1053 message. There are three cases for the type of the outermost data: 1054 - EnvelopedData 1055 - SignedData 1056 - data 1058 4.2.1 Processing for EnvelopedData 1060 1. The MLA locates its own RecipientInfo and uses the information it 1061 contains to obtain the message key. 1063 2. The MLA removes the existing recipientInfos field and replaces it with a 1064 new recipientInfos value built from RecipientInfo structures created for 1065 each member of the mailing list. 1067 3. The MLA encapsulates the expanded encrypted message in a SignedData 1068 block, adding an mlExpansionHistory attribute as described in the "Mail 1069 List Expansion" section to document the expansion. 1071 4. The MLA signs the new message and delivers the updated message to mail 1072 list members to complete MLA processing. 1074 4.2.2 Processing for SignedData 1076 MLA processing of multi-layer messages depends on the type of data in each 1077 of the layers. Step 3 below specifies that different processing will take 1078 place depending on the type of PKCS #7 message that has been signed. That 1079 is, it needs to know the type of data at the next inner layer, which may or 1080 may not be the innermost layer. 1082 1. The MLA verifies the signature value found in the outermost SignedData 1083 layer associated with the signed data. MLA processing of the message 1084 terminates if the message signature is invalid. 1086 2. If the outermost SignedData layer includes an authenticated 1087 mlExpansionHistory attribute the MLA checks for an expansion loop as 1088 described in the "Detecting Mail List Expansion Loops" section. 1090 3. Determine the type of the data that has been signed. That is, look at 1091 the type of data on the layer just below the SignedData, which may or may 1092 not be the "innermost" layer. Based on the type of data, perform either 1093 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other 1094 types). 1096 3.1. If the signed data is EnvelopedData, the MLA performs expansion 1097 processing of the encrypted message as described previously. Note that 1098 this process invalidates the signature value in the outermost 1099 SignedData layer associated with the original encrypted message. 1100 Proceed to section 3.2 with the result of the expansion. 1102 3.2. If the signed data is SignedData, or is the result of expanding an 1103 EnvelopedData block in step 3.1: 1105 3.2.1. The MLA strips the existing outermost SignedData layer after 1106 remembering the value of the mlExpansionHistory attribute in that 1107 layer, if one was there. 1109 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 1110 encapsulates the expanded encrypted message in a new outermost 1111 SignedData layer. On the other hand, if the signed data is 1112 SignedData (from step 3.2), the MLA encapsulates the signed data in 1113 a new outermost SignedData layer. 1115 3.2.3. The MLA adds an mlExpansionHistory attribute. The SignedData 1116 layer created by the MLA replaces the original outermost SignedData 1117 layer. 1119 3.2.3.1. If the original outermost SignedData layer included an 1120 mlExpansionHistory attribute, the attribute's value is copied 1121 and updated with the current ML expansion information as 1122 described in the "Mail List Expansion" section. 1124 3.2.3.2. If the original outermost SignedData layer did not 1125 include an mlExpansionHistory attribute, a new attribute value 1126 is created with the current ML expansion information as 1127 described in the "Mail List Expansion" section. 1129 3.3. If the signed data is not EnvelopedData or SignedData: 1131 3.3.1. The MLA encapsulates the received signedData object in an 1132 SignedData object, and adds an mlExpansionHistory attribute to the 1133 outer SignedData object containing the current ML expansion 1134 information as described in the "Mail List Expansion" section. 1136 4. The MLA signs the new message and delivers the updated message to mail 1137 list members to complete MLA processing. 1139 A flow chart for the above steps would be: 1141 1. Has a valid signature? 1142 YES -> 2. 1143 NO -> STOP. 1144 2. Does outermost SignedData layer 1145 contain mlExpansionHistory? 1146 YES -> Check it, then -> 3. 1147 NO -> 3. 1148 3. Check type of data just below outermost 1149 SignedData. 1150 EnvelopedData -> 3.1. 1151 SignedData -> 3.2. 1152 all others -> 3.3. 1153 3.1. Expand the encrypted message, then -> 3.2. 1154 3.2. -> 3.2.1. 1155 3.2.1. Strip outermost SignedData layer, note value of 1156 mlExpansionHistory, then -> 3.2.2. 1157 3.2.2. Encapsulate in new signature, then -> 3.2.3. 1158 3.2.3. Add mlExpansionHistory. Was there an old mlExpansionHistory? 1159 YES -> copy the old mlExpansionHistory values, then -> 4. 1160 NO -> create new mlExpansionHistory value, then -> 4. 1161 3.3. Is the signed data EnvelopedData or SignedData? 1162 YES -> 4. 1163 NO -> Encapsulate in a SignedData layer and add a 1164 mlExpansionHistory attribute. 1165 4. Sign message, deliver it, STOP. 1167 4.2.3 Processing for data 1169 1. The MLA encapsulates the message in a SignedData layer, and adds an 1170 mlExpansionHistory attribute containing the current ML expansion 1171 information as described in the "Mail List Expansion" section. 1173 2. The MLA signs the new message and delivers the updated message to mail 1174 list members to complete MLA processing. 1176 4.3 Mail List Expansion History Syntax 1178 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If 1179 there are more than ub-ml-expansion-hsitory mailing lists in the sequence, 1180 the processing agent should return an error. 1182 MLExpansionHistory ::= SEQUENCE (SIZE (1..ub-ml-expansion-history)) 1183 OF MLData 1184 ub-ml-expansion-history INTEGER ::= 64 1186 MLData contains the expansion history describing each MLA that has 1187 processed a message. As an MLA distributes a message to members of an ML, 1188 the MLA records its unique identifier, date and time of expansion, and 1189 receipt policy in an MLData structure. 1191 MLData ::= SEQUENCE { 1192 mailListIdentifier EntityIdentifier, 1193 expansionTime GeneralizedTime, 1194 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 1196 EntityIdentifier ::= CHOICE { 1197 issuerAndSerialNumber IssuerAndSerialNumber, -- From PKCS #7 1198 subjectKeyIdentifier KeyIdentifier } 1200 KeyIdentifier ::= OCTET STRING 1202 The receipt policy of the ML can withdraw the originator's request for 1203 the return of a signed receipt. However, if the originator of the 1204 message has not requested a signed receipt, the MLA cannot request a 1205 signed receipt. 1207 When present, the mlReceiptPolicy specifies a receipt policy that 1208 supersedes the originator's request for signed receipts. The policy 1209 can be one of three possibilities: receipts MUST NOT be returned 1210 (none); receipts should be returned to an alternate list of 1211 recipients, instead of to the originator (insteadOf); or receipts 1212 should be returned to a list of recipients in addition to the 1213 originator (inAdditionTo). 1215 MLReceiptPolicy ::= CHOICE { 1216 none [0] NULL, 1217 insteadOf [1] SEQUENCE (SIZE (1..ub-insteadOf)) 1218 OF GeneralNames, 1219 inAdditionTo [2] SEQUENCE (SIZE (1..ub-inAdditionTo)) 1220 OF GeneralNames } 1221 ub-insteadOf INTEGER ::= 16 1222 ub-inAdditionTo INTEGER ::= 16 1224 5. Security Considerations 1226 This entire document discusses security. 1228 A. References 1230 [ACP120] 28 Oct 97 Final Draft Allied Communication Publication (ACP) 120 1231 Communication Security Protocol (CSP) Specification. 1233 [CMS] Cryptographic Message Syntax, Internet Draft draft-ietf-smime-cms-xx. 1235 [MSP4] Secure Data Network System (SDNS) Message Security Protocol (MSP) 1236 4.0, Specification SDN.701, Revision A, 1997-02-06. 1238 [MTSABS] 1988 International Telecommunication Union (ITU) Data 1239 Communication Networks Message Handling Systems: Message Transfer System: 1240 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, 1241 Recommendation X.411; MTSAbstractService {joint-iso-ccitt mhs-motis(6) 1242 mts(3) modules(0) mts-abstract-service(1)} 1244 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", Internet Draft 1245 draft-hoffman-pkcs-crypt-msg-xx. 1247 [SMIME2] "S/MIME Version 2 Message Specification", Internet Draft 1248 draft-dusse-smime-msg-xx, and "S/MIME Version 2 Certificate Handling", 1249 Internet Draft draft-dusse-smime-cert-xx. 1251 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft 1252 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling", 1253 Internet Draft draft-ietf-smime-cert-xx. 1255 B. Acknowledgements 1257 The first draft of this work was prepared by David Solo. John Pawling did a 1258 huge amount of very detailed revision work during the many phases of the 1259 document. 1261 Many other people have contributed hard work to this draft, including: 1262 Bengt Ackzell 1263 Blake Ramsdell 1264 Carlisle Adams 1265 Jim Schaad 1266 Phillip Griffin 1267 Russ Housley 1268 Scott Hollenbeck 1269 Steve Dusse 1271 C. Open Issues 1273 There is a desire for a single ASN.1 module that collects all the ASN.1 1274 from the whole document. 1276 There is apparently two ASN.1:1994 types (BMPString and UniversalString) in 1277 the draft, leading to invalid ASN.1. 1279 2.4: Includes hashing the authenticatedAttributes included in the 1280 SignerInfo containing the receipt signature value included in the 1281 SignedData/Receipt. Also state that a SignedData/Receipt is not allowed to 1282 include receiptRequest or MLExpansionHistory attributes. 1284 2.6: Examples are needed. 1286 3.2: An OID for the securityLabel attribute is needed. 1288 5: The security considerations section needs to be fleshed out, including 1289 discussions of what happens if receiving clients don't check things very 1290 well. 1292 D. Changes from Draft -00 to Draft -01 1294 Changed the file name of the draft from "draft-hoffman-smime-ess" to 1295 "draft-ietf-smime-ess". 1297 Made the following capitalization changes throughout: 1298 ContentHints -> contentHints 1299 ReceiptRequest -> receiptRequest 1300 SecurityLabel -> securityLabel 1302 1.1.1: removed last sentence of first paragraph. 1304 1.2: Added to the last paragraph: As defined in [PKCS7-1.5] and [CMS], each 1305 SignedData and EnvelopedData object MUST be encapsulated by a ContentInfo 1306 SEQUENCE. 1308 1.3.1: Changed "A signed receipt may be requested in any signed body part." 1309 to "...any SignedData object." 1311 1.3.2: Changed the beginning of the first sentence from "A security label 1312 in authenticated attributes may also be included in the outer SignedData 1313 block..." to "A security label may also be included in the authenticated 1314 attributes of the outer SignedData block...". 1316 1.3.3: Changed last sentence to "In all cases, the agent adds or updates an 1317 mlExpansionHistory attribute to document the agent's processing, and 1318 ultimately adds or replaces the outer signature on the message to be 1319 distributed." 1321 1.3.4: Changed "SignerInfo" to "SignedData" in the first sentence. 1323 1.3.4: Changed ContentIdentifier to contentIdentifier and 1324 EncapsulatedContentType to encapsulatedContentType to reference the 1325 to-be-defined OIDs. Also alphabatized the table and added: 1326 counterSignature either no 1327 contentType either no 1328 messageDigest either yes 1330 1.4: Added this as a new section. Also, throughout the draft, removed 1331 definitions of OIDs in this draft that are actually on the OIDs page at 1332 IMC. 1334 2.2: Added to the first paragraph: "Only one receiptRequest attribute can 1335 be included in the authenticatedAttributes of a SignerInfo." Also changed 1336 "signed message" to "SignerInfo" in the last sentence. 1338 2.2.1: This section is new and adds new functionality from the previous 1339 draft. It should be read carefully, and additional wordsmithing is 1340 encouraged. 1342 2.3: Made large additions to the first paragraph. In the first bullet, 1343 changed "outermost authenticatedAttributes block" to "outermost signedData 1344 block". Also changed the lead-in paragraph to the flow chart. Also fixed 1345 2.3.1 and 2.3.2 in the flow chart to match the text. 1347 2.4: Changed bullet 2.2 to have the values copied from the "SignerInfo's 1348 receiptRequest" instead of the "original message's receiptRequest". In 1349 bullet 2.3, changed "protectionValue" to "signatureValue". 1351 2.6: Bullet 4, changed "protectionValue" to "signatureValue". 1353 2.7: Changed the first sentence in bullet 1 to read "The encapsulated 1354 content type, signed content identifier, and encrypted digest value 1355 (signature value) derived from the message content are copied from the 1356 SignerInfo including the receiptRequest into a Receipt structure." Added 1357 the reference to the receipt creation section in bullet 3. 1359 2.8: Change the definition of signedContentIdentifier from OCTET STRING to 1360 ContentIdentifier. 1362 2.9: Replaced the last paragraph with better wording. 1364 2.10: Changed the defintion of ContentHints to include { ub-conDesc } 1366 3.1: Changed "signed message" to "signedData object" in the first 1367 paragraph. 1369 3.1.1: In the first paragraph, changed "SignedData" to "SignerInfo". In the 1370 third paragraph, changed "signed message" to "signedData object". Also 1371 added long paragraphs at the end of this section describing multiple 1372 SignerInfos and what to do with them; this is new material that should be 1373 carefully scrutinized. 1375 3.1.2: The section "Processing Security Labels" was also called 3.1.1 in 1376 the previous draft; renumbered it. Also, changed and added most of the text 1377 of the section. 1379 3.2: Added the second sentence of the first paragraph, which was moved from 1380 Appendix A. Also fixed the ub-xxx ASN.1 defintions to include INTEGER. 1382 4.1: Added to the end of the second paragraph: "Only one MLExpansionHistory 1383 attribute can be included in the authenticatedAttributes of a SignerInfo." 1384 Also added all the text starting with "There can be multiple....", which 1385 describes how to handle multiple SignerInfos and what to do with them. This 1386 is new material and should be checked carefully. 1388 4.2: In the first paragraph, changed "signedData block" to "signerInfo 1389 block" and added the last two sentences. Added definitions of 1390 EntityIdentifier and KeyIdentifier. 1392 4.2.1: Bullet 1, removed "record". Bullet 3.3.1, fixed the wording to be 1393 more accruate. 1395 4.2.3: Removed "digestedData". 1397 A: Updated the reference for [ACP120]. Moved the sentence from [MTSABS] to 1398 Section 3.2. 1400 B: Gave John Pawling more direct credit for all his hard work. 1402 E. Editor's Address 1404 Paul Hoffman 1405 Internet Mail Consortium 1406 127 Segre Place 1407 Santa Cruz, CA 95060 1408 (408) 426-9827 1409 phoffman@imc.org