idnits 2.17.1 draft-ietf-smime-ess-07.txt: -(454): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(459): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(898): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(961): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1115): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1745): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1909): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-26) 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. == There are 22 instances of lines with non-ascii characters in the document. == 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 2058 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 386 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 82 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 100: '...entInfo eContent MUST be absent. If th...' RFC 2119 keyword, line 102: '...entInfo eContent MUST contain the resu...' RFC 2119 keyword, line 125: '...contentType MUST be id-data. The Envel...' RFC 2119 keyword, line 154: '...receiving agents MUST be able to inter...' RFC 2119 keyword, line 235: '...request MUST be in the inside signatur...' (126 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1730 has weird spacing: '... | none inst...' == Line 1732 has weird spacing: '... | none none...' == Line 1733 has weird spacing: '... | none inst...' == Line 1734 has weird spacing: '... | none inst...' == Line 1735 has weird spacing: '... | none inst...' -- 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 (August 5, 1998) is 9396 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? 'MSP4' on line 1980 looks like a reference -- Missing reference section? 'SMIME3' on line 1994 looks like a reference -- Missing reference section? 'SMIME2' on line 1991 looks like a reference -- Missing reference section? 'ASN1-1988' on line 1971 looks like a reference -- Missing reference section? 'ESS' on line 302 looks like a reference -- Missing reference section? 'CMS' on line 1977 looks like a reference -- Missing reference section? 'MSG' on line 306 looks like a reference -- Missing reference section? '0' on line 1963 looks like a reference -- Missing reference section? '1' on line 1964 looks like a reference -- Missing reference section? 'MTSABS' on line 1983 looks like a reference -- Missing reference section? '2' on line 1965 looks like a reference -- Missing reference section? 'UNIVERSAL 12' on line 1819 looks like a reference -- Missing reference section? 'UTF8' on line 1998 looks like a reference -- Missing reference section? 'ASN1-1994' on line 1974 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 16 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-07.txt Internet Mail Consortium 3 August 5, 1998 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), ftp.ietf.org (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 [MSP4], 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 3 [SMIME3], 37 and some of them can also be added to S/MIME version 2 [SMIME2]. The 38 extensions described here will not cause an S/MIME version 3 recipient to 39 be unable to read messages from an S/MIME version 2 sender. However, some 40 of the extensions will cause messages created by an S/MIME version 3 sender 41 to be unreadable by an S/MIME version 2 recipient. 43 The format of the messages are described in ASN.1:1988 [ASN1-1988]. 45 This draft is being discussed on the 'ietf-smime' mailing list. To 46 subscribe, send a message to: 47 ietf-smime-request@imc.org 48 with the single word 49 subscribe 50 in the body of the message. There is a Web site for the mailing list at 51 . 53 1.1 Triple Wrapping 55 Some of the features of each service use the concept of a "triple wrapped" 56 message. A triple wrapped message is one that has been signed, then 57 encrypted, then signed again. The signers of the inner and outer signatures 58 may be different entities or the same entity. Note that the S/MIME 59 specification does not limit the number of nested encapsulations, so there 60 may be more than three wrappings. 62 1.1.1 Purpose of Triple Wrapping 64 Not all messages need to be triple wrapped. Triple wrapping is used when a 65 message must be signed, then encrypted, and then have signed attributes 66 bound to the encrypted body. Outer attributes may be added or removed by 67 the message originator or intermediate agents, and may be signed by 68 intermediate agents or the final recipient. 70 The inside signature is used for content integrity, non-repudiation with 71 proof of origin, and binding attributes (such as a security label) to the 72 original content. These attributes go from the originator to the recipient, 73 regardless of the number of intermediate entities such as mail list agents 74 that process the message. The signed attributes can be used for access 75 control to the inner body. Requests for signed receipts by the originator 76 are carried in the inside signature as well. 78 The encrypted body provides confidentiality, including confidentiality of 79 the attributes that are carried in the inside signature. 81 The outside signature provides authentication and integrity for information 82 that is processed hop-by-hop, where each hop is an intermediate entity such 83 as a mail list agent. The outer signature binds attributes (such as a 84 security label) to the encrypted body. These attributes can be used for 85 access control and routing decisions. 87 1.1.2 Steps for Triple Wrapping 89 The steps to create a triple wrapped message are: 91 1. Start with a message body, called the "original content". 93 2. Encapsulate the original content with the appropriate MIME Content-type 94 headers, such as "Content-type: text/plain". An exception to this MIME 95 encapsulation rule is that a signed receipt is not put in MIME headers. 97 3. Sign the result of step 2 (the inner MIME headers and the original 98 content). The SignedData encapContentInfo eContentType object identifier 99 MUST be id-data. If the structure you create in step 4 is multipart/signed, 100 then the SignedData encapContentInfo eContent MUST be absent. If the 101 structure you create in step 4 is application/pkcs7-mime, then the 102 SignedData encapContentInfo eContent MUST contain the result of step 2 103 above. The SignedData structure is encapsulated by a ContentInfo SEQUENCE 104 with a contentType of id-signedData. 106 4. Add an appropriate MIME construct to the signed message from step 3 as 107 defined in [SMIME3]. The resulting message is called the "inside 108 signature". 110 - If you are signing using multipart/signed, the MIME construct added 111 consists of a Content-type of multipart/signed with parameters, the 112 boundary, the result of step 2 above, the boundary, a Content-type of 113 application/pkcs7-signature, optional MIME headers (such as 114 Content-transfer-encoding and Content-disposition), and a body part that 115 is the result of step 3 above. 117 - If you are instead signing using application/pkcs7-mime, the MIME 118 construct added consists of a Content-type of application/pkcs7-mime 119 with parameters, optional MIME headers (such as 120 Content-transfer-encoding and Content-disposition), and the result of 121 step 3 above. 123 5. Encrypt the result of step 4 as a single block, turning it into an 124 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo 125 contentType MUST be id-data. The EnvelopedData structure is encapsulated by 126 a ContentInfo SEQUENCE with a contentType of id-envelopedData. This is 127 called the "encrypted body". 129 6. Add the appropriate MIME headers: a Content-type of 130 application/pkcs7-mime with parameters, and optional MIME headers such as 131 Content-transfer-encoding and Content-disposition. 133 7. Using the same logic as in step 3 above, sign the result of step 6 (the 134 MIME headers and the encrypted body) as a single block 136 8. Using the same logic as in step 4 above, add an appropriate MIME 137 construct to the signed message from step 7. The resulting message is 138 called the "outside signature", and is also the triple wrapped message. 140 1.2 Format of a Triple Wrapped Message 142 A triple wrapped message has many layers of encapsulation. The structure 143 differs based on the choice of format for the signed portions of the 144 message. Because of the way that MIME encapsulates data, the layers do not 145 appear in order, and the notion of "layers" becomes vague. 147 There is no need to use the multipart/signed format in an inner signature 148 because it is known that the recipient is able to process S/MIME messages 149 (because they decrypted the middle wrapper). A sending agent might choose 150 to use the multipart/signed format in the outer layer so that a non-S/MIME 151 agent could see that the next inner layer is encrypted; however, this is 152 not of great value, since all it shows the recipient is that the rest of 153 the message is unreadable. Because many sending agents always use 154 multipart/signed structures, all receiving agents MUST be able to interpret 155 either multipart/signed or application/pkcs7-mime signature structures. 157 The format of a triple wrapped message that uses multipart/signed for both 158 signatures is: 160 [step 8] Content-type: multipart/signed; 161 [step 8] protocol="application/pkcs7-signature"; 162 [step 8] boundary=outerboundary 163 [step 8] 164 [step 8] --outerboundary 165 [step 6] Content-type: application/pkcs7-mime; ) 166 [step 6] smime-type=enveloped-data ) 167 [step 6] ) 168 [step 4] Content-type: multipart/signed; | ) 169 [step 4] protocol="application/pkcs7-signature"; | ) 170 [step 4] boundary=innerboundary | ) 171 [step 4] | ) 172 [step 4] --innerboundary | ) 173 [step 2] Content-type: text/plain % | ) 174 [step 2] % | ) 175 [step 1] Original content % | ) 176 [step 4] | ) 177 [step 4] --innerboundary | ) 178 [step 4] Content-type: application/pkcs7-signature | ) 179 [step 4] | ) 180 [step 3] inner SignedData block (eContent is missing) | ) 181 [step 4] | ) 182 [step 4] --innerboundary-- | ) 183 [step 8] 184 [step 8] --outerboundary 185 [step 8] Content-type: application/pkcs7-signature 186 [step 8] 187 [step 7] outer SignedData block (eContent is missing) 188 [step 8] 189 [step 8] --outerboundary-- 191 % = These lines are what the inner signature is computed over. 192 | = These lines are what is encrypted in step 5. This encrypted result 193 is opaque and is a part of an EnvelopedData block. 194 ) = These lines are what the outer signature is computed over. 196 The format of a triple wrapped message that uses application/pkcs7-mime for 197 the both signatures is: 199 [step 8] Content-type: application/pkcs7-mime; 200 [step 8] smime-type=signed-data 201 [step 8] 202 [step 7] outer SignedData block (eContent is present) O 203 [step 6] Content-type: application/pkcs7-mime; ) O 204 [step 6] smime-type=enveloped-data; ) O 205 [step 6] ) O 206 [step 4] Content-type: application/pkcs7-mime; | ) O 207 [step 4] smime-type=signed-data | ) O 208 [step 4] | ) O 209 [step 3] inner SignedData block (eContent is present) I | ) O 210 [step 2] Content-type: text/plain I | ) O 211 [step 2] I | ) O 212 [step 1] Original content I | ) O 214 I = These lines are the inner SignedData block, which is opaque and 215 contains the ASN.1 encoded result of step 2 as well as control 216 information. 217 | = These lines are what is encrypted in step 5. This encrypted result 218 is opaque and is a part of an EnvelopedData block. 219 ) = These lines are what the outer signature is computed over. 220 O = These lines are the outer SignedData block, which is opaque and 221 contains the ASN.1 encoded result of step 6 as well as control 222 information. 224 1.3 Security Services and Triple Wrapping 226 The three security services described in this document are used with triple 227 wrapped messages in different ways. This section briefly describes the 228 relationship of each service with triple wrapping; the other sections of 229 the document go into greater detail. 231 1.3.1 Signed Receipts and Triple Wrapping 233 A signed receipt may be requested in any SignedData object. However, if a 234 signed receipt is requested for a triple wrapped message, the receipt 235 request MUST be in the inside signature, not in the outside signature. A 236 secure mailing list agent may change the receipt policy in the outside 237 signature of a triple wrapped message when that message is processed by the 238 mailing list. 240 Note: the signed receipts and receipt requests described in this draft 241 differ from those described in the work done by the IETF Receipt 242 Notification Working Group. The output of that Working Group, when 243 finished, is not expected to work well with triple wrapped messages as 244 described in this document. 246 1.3.2 Security Labels and Triple Wrapping 248 A security label may be included in the signed attributes of any SignedData 249 object. A security label attribute may be included in either the inner 250 signature, outer signature, or both. 252 The inner security label is used for access control decisions related to 253 the plaintext original content. The inner signature provides authentication 254 and cryptographically protects the original signer's security label that is 255 on the inside body. This strategy facilitates the forwarding of messages 256 because the original signer's security label is included in the SignedData 257 block which can be forwarded to a third party that can verify the inner 258 signature which will cover the inner security label. The confidentiality 259 security service can be applied to the inner security label by encrypting 260 the entire inner SignedData block within an EnvelopedData block. 262 A security label may also be included in the signed attributes of the outer 263 SignedData block which will include the sensitivities of the encrypted 264 message. The outer security label is used for access control and routing 265 decisions related to the encrypted message. Note that a security label 266 attribute can only be used in an signedAttributes block. An 267 eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or unsigned 268 attributes. 270 1.3.3 Secure Mailing Lists and Triple Wrapping 272 Secure mail list message processing depends on the structure of S/MIME 273 layers present in the message sent to the mail list agent. The agent never 274 changes the data that was hashed to form the inner signature, if such a 275 signature is present. If an outer signature is present, then the agent will 276 modify the data that was hashed to form that outer signature. In all cases, 277 the agent adds or updates an mlExpansionHistory attribute to document the 278 agent's processing, and ultimately adds or replaces the outer signature on 279 the message to be distributed. 281 1.3.4 Placement of Attributes 283 Certain attributes should be placed in the inner or outer SignedData 284 message; some attributes can be in either. Further, some attributes must be 285 signed, while signing is optional for others, and some attributes must not 286 be signed. The following table summarizes the recommendation of this 287 profile. 289 | |Inner or | 290 Attribute |OID |outer |Signed 291 ------------------|-----------------------------|----------|-------- 292 contentHints |id-aa-contentHint [ESS] |either |MAY 293 contentIdentifier |id-aa-contentIdentifier [ESS]|either |MAY 294 contentReference |id-aa-contentReference [ESS] |either |MUST 295 contentType |id-contentType [CMS] |either |MUST 296 counterSignature |id-countersignature [CMS] |either |MUST NOT 297 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST 298 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST 299 messageDigest |id-messageDigest [CMS] |either |MUST 300 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST 301 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST 302 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST 303 signingTime |id-signingTime [CMS] |either |MUST 304 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST 305 sMIMEEncryption- 306 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST 308 CMS defines signedAttrs as a SET OF Attributes and defines 309 unsignedAttributes as a SET OF Attributes. ESS defines the contentHints, 310 contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, 311 receiptRequest, contentReference and equivalentLabels attribute types. A 312 signerInfo MUST NOT include multiple instances of any of the attribute 313 types defined in ESS. Later sections of ESS specify further restrictions 314 that apply to the receiptRequest, mlExpansionHistory and eSSecurityLabel 315 attribute types. 317 CMS defines the syntax for the signed and unsigned attributes as 318 "attrValues SET OF AttributeValue". For all of the attribute types defined 319 in ESS, if the attribute type is present in a signerInfo, then it MUST only 320 include a single instance of AttributeValue. In other words, there MUST NOT 321 be zero or multiple instances of AttributeValue present in the attrValues 322 SET OF AttributeValue. 324 If a counterSignature attribute is present, then it MUST be included in the 325 unsigned attributes. It MUST NOT be included in the signed attributes. The 326 only attributes that are allowed in a counterSignature attribute are 327 counterSignature, messageDigest, signingTime, and signingCertificate. 329 Note that the inner and outer signatures are usually for different senders. 330 The same attribute in the two signatures could lead to very different 331 consequences. 333 The macValue attribute is only used in authenticatedData, never in 334 signedData. 336 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique 337 identifier assigned to the message. 339 1.4 Required and Optional Attributes 341 Some security gateways sign messages that pass through them. If the message 342 is any type other than a signedData type, the gateway has only one way to 343 sign the message: by wrapping it with a signedData block and MIME headers. 344 If the message to be signed by the gateway is a signedData message already, 345 the gateway can sign the message by inserting a signerInfo into the 346 signedData block. 348 The main advantage of a gateway adding a signerInfo instead of wrapping the 349 message in a new signature is that the message doesn't grow as much as if 350 the gateway wrapped the message. The main disadvantage is that the gateway 351 must check for the presence of certain attributes in the other signerInfos 352 and duplicate those attributes. 354 If a gateway or other processor adds a signerInfo to an existing signedData 355 block, it MUST copy the mlExpansionHistory and eSSSecurityLabel attributes 356 from other signerInfos. This helps ensure that the recipient will process 357 those attributes in a signerInfo that it can verify. 359 Note that someone may in the future define an attribute that must be 360 present in each signerInfo of a signedData block in order for the signature 361 to be processed. If that happens, a gateway that inserts signerInfos and 362 doesn't copy that attribute will cause every message with that attribute to 363 fail when processed by the recipient. For this reason, it is safer to wrap 364 messages with new signatures than to insert signerInfos. 366 1.5 Object Identifiers 368 The object identifiers for many of the objects described in this draft are 369 found in [CMS} and [SMIME3]. Other object identifiers used in S/MIME can be 370 found in the registry kept at . 371 When this draft moves to standards track within the IETF, it is intended 372 that the IANA will maintain this registry. 374 2. Signed Receipts 376 Returning a signed receipt provides to the originator proof of delivery of 377 a message, and allows the originator to demonstrate to a third party that 378 the recipient was able to verify the signature of the original message. 379 This receipt is bound to the original message through the signature; 380 consequently, this service may be requested only if a message is signed. 381 The receipt sender may optionally also encrypt a receipt to provide 382 confidentiality between the receipt sender and the receipt recipient. 384 2.1 Signed Receipt Concepts 386 The originator of a message may request a signed receipt from the message's 387 recipients. The request is indicated by adding a receiptRequest attribute 388 to the signedAttributes field of the SignerInfo object for which the 389 receipt is requested. The receiving user agent software SHOULD 390 automatically create a signed receipt when requested to do so, and return 391 the receipt in accordance with mailing list expansion options, local 392 security policies, and configuration options. 394 Because receipts involve the interaction of two parties, the terminology 395 can sometimes be confusing. In this section, the "sender" is the agent that 396 sent the original message that included a request for a receipt. The 397 "receiver" is the party that received that message and generated the 398 receipt. 400 The steps in a typical transaction are: 402 1. Sender creates a signed message including a receipt request attribute 403 (Section 2.2). 405 2. Sender transmits the resulting message to the recipient or recipients. 407 3. Recipient receives message and determines if there is a valid signature 408 and receipt request in the message (Section 2.3). 410 4. Recipient creates a signed receipt (Section 2.4). 412 5. Recipient transmits the resulting signed receipt message to the sender 413 (Section 2.5). 415 6. Sender receives the message and validates that it contains a signed 416 receipt for the original message (Section 2.6). This validation relies on 417 the sender having retained either a copy of the original message or 418 information extracted from the original message. 420 The ASN.1 syntax for the receipt request is given in Section 2.7; the ASN.1 421 syntax for the receipt is given in Section 2.8. 423 Note that an agent SHOULD remember when it has sent a receipt so that it 424 can avoid re-sending a receipt each time it processes the message. 426 2.2 Receipt Request Creation 428 Multi-layer S/MIME messages may contain multiple SignedData layers. 429 However, receipts may be requested only for the innermost SignedData layer 430 in a multi-layer S/MIME message, such as a triple wrapped message. Only one 431 receiptRequest attribute can be included in the signedAttributes of a 432 SignerInfo. 434 A ReceiptRequest attribute MUST NOT be included in the attributes of a 435 SignerInfo in a SignedData object that encapsulates a Receipt content. In 436 other words, the user agent MUST NOT request a signed receipt for a signed 437 receipt. 439 A sender requests receipts by placing a receiptRequest attribute in the 440 signed attributes of a signerInfo as follows: 442 1. A receiptRequest data structure is created. 444 2. A signed content identifier for the message is created and assigned to 445 the signedContentIdentifier field. The signedContentIdentifier is used to 446 associate the signed receipt with the message requesting the signed 447 receipt. 449 3. The entities requested to return a signed receipt are noted in the 450 receiptsFrom field. 452 4. The message originator MUST populate the receiptsTo field with a 453 GeneralNames for each entity to whom the recipient should send the signed 454 receipt.�If the message originator wants the recipient to send the signed 455 receipt to the originator, then the originator MUST include a GeneralNames 456 for itself in the receiptsTo field.�GeneralNames is a SEQUENCE OF 457 GeneralName.�receiptsTo is a SEQUENCE OF GeneralNames in which each 458 GeneralNames represents an entity.�There may be multiple GeneralName 459 instances in each GeneralNames.�At a minimum, the message originator MUST 460 populate each entity's GeneralNames with the address to which the signed 461 receipt should be sent.�Optionally, the message originator MAY also 462 populate each entity's GeneralNames with other GeneralName instances (such 463 as directoryName). 465 5. The completed receiptRequest attribute is placed in the signedAttributes 466 field of the SignerInfo object. 468 2.2.1 Multiple Receipt Requests 470 There can be multiple SignerInfos within a SignedData object, and each 471 SignerInfo may include signedAttributes. Therefore, a single SignedData 472 object may include multiple SignerInfos, each SignerInfo having a 473 receiptRequest attribute. For example, an originator can send a signed 474 message with two SignerInfos, one containing a DSS signature, the other 475 containing an RSA signature. 477 Each recipient SHOULD return only one signed receipt. 479 Not all of the SignerInfos need to include receipt requests, but in all of 480 the SignerInfos that do contain receipt requests, the receipt requests MUST 481 be identical. 483 2.2.2 Information Needed to Validate Signed Receipts 485 The sending agent MUST retain one or both of the following items to support 486 the validation of signed receipts returned by the recipients. 488 - the original signedData object requesting the signed receipt 490 - the message signature digest value used to generate the original 491 signedData signerInfo signature value and the digest value of the 492 Receipt content containing values included in the original signedData 493 object. If signed receipts are requested from multiple recipients, then 494 retaining these digest values is a performance enhancement because the 495 sending agent can reuse the saved values when verifying each returned 496 signed receipt. 498 2.3 Receipt Request Processing 500 A receiptRequest is associated only with the SignerInfo object in which the 501 receipt request attribute is directly attached. Processing software SHOULD 502 examine the signedAttributes field of each of the SignerInfos for which it 503 verifies a signature in the innermost signedData object to determine if a 504 receipt is requested. This may result in the receiving agent processing 505 multiple receiptRequest attributes included in a single SignedData object. 507 Before processing a receiptRequest signedAttribute, the receiving agent 508 MUST verify the signature of the SignerInfo which covers the receiptRequest 509 attribute. A recipient MUST NOT process a receiptRequest attribute that has 510 not been verified. Because all receiptRequest attributes in a SignedData 511 object must be identical, the receiving application fully processes (as 512 described in the following paragraphs) the first receiptRequest attribute 513 that it encounters in a SignerInfo that it verifies, and it then ensures 514 that all other receiptRequest attributes in signerInfos that it verifies 515 are identical to the first one encountered. If there are verified 516 ReceiptRequest attributes which conflict, then the processing software MUST 517 NOT return any signed receipt. A signed receipt SHOULD be returned if any 518 signerInfo containing a receiptRequest attribute can be validated, even if 519 other signerInfos containing the same receiptRequest attribute cannot be 520 validated because they are signed using an algorithm not supported by the 521 receiving agent. 523 If a receiptRequest attribute is absent from the signed attributes, then a 524 signed receipt has not been requested from any of the message recipients 525 and MUST NOT be created. If a receiptRequest attribute is present in the 526 signed attributes, then a signed receipt has been requested from some or 527 all of the message recipients. Note that in some cases, a receiving agent 528 might receive two almost-identical messages, one with a receipt request and 529 the other without one. In this case, the receiving agent SHOULD send a 530 signed receipt for the message that requests a signed receipt. 532 If a receiptRequest attribute is present in the signed attributes, the 533 following process SHOULD be used to determine if a message recipient has 534 been requested to return a signed receipt. 536 1. If an mlExpansionHistory attribute is present in the outermost 537 signedData block, do one of the following two steps, based on the absence 538 or presence of mlReceiptPolicy: 540 1.1. If an mlReceiptPolicy value is absent from the last MLData 541 element, a Mail List receipt policy has not been specified and the 542 processing software SHOULD examine the receiptRequest attribute value 543 to determine if a receipt should be created and returned. 545 1.2. If an mlReceiptPolicy value is present in the last MLData element, 546 do one of the following two steps, based on the value of 547 mlReceiptPolicy: 549 1.2.1. If the mlReceiptPolicy value is none, then the receipt 550 policy of the Mail List supersedes the originator's request for a 551 signed receipt and a signed receipt MUST NOT be created. 553 1.2.2. If the mlReceiptPolicy value is insteadOf or inAdditionTo, 554 the processing software SHOULD examine the receiptsFrom value from 555 the receiptRequest attribute to determine if a receipt should be 556 created and returned. If a receipt is created, the insteadOf and 557 inAdditionTo fields identify entities that SHOULD be sent the 558 receipt instead of or in addition to the originator. 560 2. If the receiptsFrom value of the receiptRequest attribute is 561 allOrFirstTier, do one of the following two steps based on the value of 562 allOrFirstTier. 564 2.1. If the value of allOrFirstTier is allReceipts, then a signed 565 receipt SHOULD be created. 567 2.2. If the value of allOrFirstTier is firstTierRecipients, do one of 568 the following two steps based on the presence of an mlExpansionHistory 569 attribute in an outer signedData block: 571 2.2.1. If an mlExpansionHistory attribute is present, then this 572 recipient is not a first tier recipient and a signed receipt MUST 573 NOT be created. 575 2.2.2. If an mlExpansionHistory attribute is not present, then a 576 signed receipt SHOULD be created. 578 3. If the receiptsFrom value of the receiptRequest attribute is a 579 receiptList: 581 3.1. If receiptList contains one of the GeneralNames of the recipient, 582 then a signed receipt should be created. 584 3.2. If receiptList does not contain one of the GeneralNames of the 585 recipient, then a signed receipt MUST NOT be created. 587 A flow chart for the above steps to be executed for each signerInfo for 588 which the receiving agent verifies the signature would be: 590 0. Receipt Request attribute present? 591 YES -> 1. 592 NO -> STOP 593 1. Has mlExpansionHistory in outer signedData? 594 YES -> 1.1. 595 NO -> 2. 596 1.1. mlReceiptPolicy absent? 597 YES -> 2. 598 NO -> 1.2. 599 1.2. Pick based on value of mlReceiptPolicy. 600 none -> 1.2.1. 601 insteadOf or inAdditionTo -> 1.2.2. 602 1.2.1. STOP. 603 1.2.2. Examine receiptsFrom to determine if a receipt should be created, 604 create it if required, send it to recipients designated by 605 mlReceiptPolicy, then -> STOP. 606 2. Is value of receiptsFrom allOrFirstTier? 607 YES -> Pick based on value of allOrFirstTier. 608 allReceipts -> 2.1. 609 firstTierRecipients -> 2.2. 610 NO -> 3. 611 2.1. Create a receipt, then -> STOP. 612 2.2. Has mlExpansionHistory in the outer signedData block? 613 YES -> 2.2.1. 614 NO -> 2.2.2. 615 2.2.1. STOP. 616 2.2.2. Create a receipt, then -> STOP. 617 3. Is receiptsFrom value of receiptRequest a receiptList? 618 YES -> 3.1. 619 NO -> STOP. 620 3.1. Does receiptList contain the recipient? 621 YES -> Create a receipt, then -> STOP. 622 NO -> 3.2. 623 3.2. STOP. 625 2.4 Signed Receipt Creation 627 A signed receipt is a signedData object encapsulating a Receipt content 628 (also called a "signedData/Receipt"). Signed receipts are created as 629 follows: 631 1. The signature of the original signedData signerInfo that includes the 632 receiptRequest signed attribute MUST be successfully verified before 633 creating the signedData/Receipt. 635 1.1. The content of the original signedData object is digested as 636 described in [CMS]. The resulting digest value is then compared with 637 the value of the messageDigest attribute included in the 638 signedAttributes of the original signedData signerInfo. If these digest 639 values are different, then the signature verification process fails and 640 the signedData/Receipt MUST NOT be created. 642 1.2. The ASN.1 DER encoded signedAttributes (including messageDigest, 643 receiptRequest and, possibly, other signed attributes) in the original 644 signedData signerInfo are digested as described in [CMS]. The resulting 645 digest value, called msgSigDigest, is then used to verify the signature 646 of the original signedData signerInfo. If the signature verification 647 fails, then the signedData/Receipt MUST NOT be created. 649 2. A Receipt structure is created. 651 2.1. The value of the Receipt version field is set to 1. 653 2.2. The object identifier from the contentType attribute included in 654 the original signedData signerInfo that includes the receiptRequest 655 attribute is copied into the Receipt contentType. 657 2.3. The original signedData signerInfo receiptRequest 658 signedContentIdentifier is copied into the Receipt 659 signedContentIdentifier. 661 2.4. The signature value from the original signedData signerInfo that 662 includes the receiptRequest attribute is copied into the Receipt 663 originatorSignatureValue. 665 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, D1. 667 4. D1 is digested. The resulting digest value is included as the 668 messageDigest attribute in the signedAttributes of the signerInfo which 669 will eventually contain the signedData/Receipt signature value. 671 5. The digest value (msgSigDigest) calculated in Step 1 to verify the 672 signature of the original signedData signerInfo is included as the 673 msgSigDigest attribute in the signedAttributes of the signerInfo which will 674 eventually contain the signedData/Receipt signature value. 676 6. A contentType attribute including the id-ct-receipt object identifier 677 MUST be created and added to the signed attributes of the signerInfo which 678 will eventually contain the signedData/Receipt signature value. 680 7. A signingTime attribute indicating the time that the signedData/Receipt 681 is signed SHOULD be created and added to the signed attributes of the 682 signerInfo which will eventually contain the signedData/Receipt signature 683 value. Other attributes (except receiptRequest) may be added to the 684 signedAttributes of the signerInfo. 686 8. The signedAttributes (messageDigest, msgSigDigest, contentType and, 687 possibly, others) of the signerInfo are ASN.1 DER encoded and digested as 688 described in CMS, Section 5.3. The resulting digest value is used to 689 calculate the signature value which is then included in the 690 signedData/Receipt signerInfo. 692 9. The ASN.1 DER encoded Receipt content MUST be directly encoded within 693 the signedData encapContentInfo eContent OCTET STRING defined in [CMS]. The 694 id-ct-receipt object identifier MUST be included in the signedData 695 encapContentInfo eContentType. This results in a single ASN.1 encoded 696 object composed of a signedData including the Receipt content. The Data 697 content type MUST NOT be used. The Receipt content MUST NOT be encapsulated 698 in a MIME header or any other header prior to being encoded as part of the 699 signedData object. 701 10. The signedData/Receipt is then put in an application/pkcs7-mime MIME 702 wrapper with the smime-type parameter set to "signed-receipt". This will 703 allow for identification of signed receipts without having to crack the 704 ASN.1 body. The smime-type parameter would still be set as normal in any 705 layer wrapped around this message. 707 11. If the signedData/Receipt is to be encrypted within an envelopedData 708 object, then an outer signedData object MUST be created that encapsulates 709 the envelopedData object, and a contentHints attribute with contentType set 710 to the id-ct-receipt object identifier MUST be included in the outer 711 signedData SignerInfo signedAttributes. When a receiving agent processes 712 the outer signedData object, the presence of the id-ct-receipt OID in the 713 contentHints contentType indicates that a signedData/Receipt is encrypted 714 within the envelopedData object encapsulated by the outer signedData. 716 All agents that support the generation of ESS signed receipts MUST provide 717 the ability to send encrypted signed receipts (that is, a 718 signedData/Receipt encapsulated within an envelopedData). The agent MAY 719 send an encrypted signed receipt in response to an 720 envelopedData-encapsulated signedData requesting a signed receipt. It is a 721 matter of local policy regarding whether or not the signed receipt should 722 be encrypted. The ESS signed receipt includes the message digest value 723 calculated for the original signedData object that requested the signed 724 receipt. If the original signedData object was sent encrypted within an 725 envelopedData object and the ESS signed receipt is sent unencrypted, then 726 the message digest value calculated for the original encrypted signedData 727 object is sent unencrypted. The responder should consider this when 728 deciding whether or not to encrypt the ESS signed receipt. 730 2.4.1 MLExpansionHistory Attributes and Receipts 732 An MLExpansionHistory attribute MUST NOT be included in the attributes of a 733 SignerInfo in a SignedData object that encapsulates a Receipt content. This 734 is true because when a SignedData/Receipt is sent to an MLA for 735 distribution, then the MLA must always encapsulate the received 736 SignedData/Receipt in an outer SignedData in which the MLA will include the 737 MLExpansionHistory attribute. The MLA cannot change the signedAttributes of 738 the received SignedData/Receipt object, so it can't add the 739 MLExpansionHistory to the SignedData/Receipt. 741 2.5 Determining the Recipients of the Signed Receipt 743 If a signed receipt was created by the process described in the sections 744 above, then the software MUST use the following process to determine to 745 whom the signed receipt should be sent. 747 1. The receiptsTo field must be present in the receiptRequest attribute. 748 The software initiates the sequence of recipients with the value(s) of 749 receiptsTo. 751 2. If the MlExpansionHistory attribute is present in the outer SignedData 752 block, and the last MLData contains an MLReceiptPolicy value of insteadOf, 753 then the software replaces the sequence of recipients with the value(s) of 754 insteadOf. 756 3. If the MlExpansionHistory attribute is present in the outer SignedData 757 block and the last MLData contains an MLReceiptPolicy value of 758 inAdditionTo, then the software adds the value(s) of inAdditionTo to the 759 sequence of recipients. 761 2.6. Signed Receipt Validation 763 A signed receipt is communicated as a single ASN.1 encoded object composed 764 of a signedData object directly including a Receipt content. It is 765 identified by the presence of the id-ct-receipt object identifier in the 766 encapContentInfo eContentType value of the signedData object including the 767 Receipt content. 769 A signedData/Receipt is validated as follows: 771 1. ASN.1 decode the signedData object including the Receipt content. 773 2. Extract the contentType, signedContentIdentifier, and 774 originatorSignatureValue from the decoded Receipt structure to identify the 775 original signedData signerInfo that requested the signedData/Receipt. 777 3. Acquire the message signature digest value calculated by the sender to 778 generate the signature value included in the original signedData signerInfo 779 that requested the signedData/Receipt. 781 3.1. If the sender-calculated message signature digest value has been 782 saved locally by the sender, it must be located and retrieved. 784 3.2. If it has not been saved, then it must be re-calculated based on 785 the original signedData content and signedAttributes as described in 786 [CMS]. 788 4. The message signature digest value calculated by the sender is then 789 compared with the value of the msgSigDigest signedAttribute included in the 790 signedData/Receipt signerInfo. If these digest values are identical, then 791 that proves that the message signature digest value calculated by the 792 recipient based on the received original signedData object is the same as 793 that calculated by the sender. This proves that the recipient received 794 exactly the same original signedData content and signedAttributes as sent 795 by the sender because that is the only way that the recipient could have 796 calculated the same message signature digest value as calculated by the 797 sender. If the digest values are different, then the signedData/Receipt 798 signature verification process fails. 800 5. Acquire the digest value calculated by the sender for the Receipt 801 content constructed by the sender (including the contentType, 802 signedContentIdentifier, and signature value that were included in the 803 original signedData signerInfo that requested the signedData/Receipt). 805 5.1. If the sender-calculated Receipt content digest value has been 806 saved locally by the sender, it must be located and retrieved. 808 5.2. If it has not been saved, then it must be re-calculated. As 809 described in section 2.4 above, step 2, create a Receipt structure 810 including the contentType, signedContentIdentifier and signature value 811 that were included in the original signedData signerInfo that requested 812 the signed receipt. The Receipt structure is then ASN.1 DER encoded to 813 produce a data stream which is then digested to produce the Receipt 814 content digest value. 816 6. The Receipt content digest value calculated by the sender is then 817 compared with the value of the messageDigest signedAttribute included in 818 the signedData/Receipt signerInfo. If these digest values are identical, 819 then that proves that the values included in the Receipt content by the 820 recipient are identical to those that were included in the original 821 signedData signerInfo that requested the signedData/Receipt. This proves 822 that the recipient received the original signedData signed by the sender, 823 because that is the only way that the recipient could have obtained the 824 original signedData signerInfo signature value for inclusion in the Receipt 825 content. If the digest values are different, then the signedData/Receipt 826 signature verification process fails. 828 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt 829 signerInfo are digested as described in [CMS]. 831 8. The resulting digest value is then used to verify the signature value 832 included in the signedData/Receipt signerInfo. If the signature 833 verification is successful, then that proves the integrity of the 834 signedData/receipt signerInfo signedAttributes and authenticates the 835 identity of the signer of the signedData/Receipt signerInfo. Note that the 836 signedAttributes include the recipient-calculated Receipt content digest 837 value (messageDigest attribute) and recipient-calculated message signature 838 digest value (msgSigDigest attribute). Therefore, the aforementioned 839 comparison of the sender-generated and recipient-generated digest values 840 combined with the successful signedData/Receipt signature verification 841 proves that the recipient received the exact original signedData content 842 and signedAttributes (proven by msgSigDigest attribute) that were signed by 843 the sender of the original signedData object (proven by messageDigest 844 attribute). If the signature verification fails, then the 845 signedData/Receipt signature verification process fails. 847 The signature verification process for each signature algorithm that is 848 used in conjunction with the CMS protocol is specific to the algorithm. 849 These processes are described in documents specific to the algorithms. 851 2.7 Receipt Request Syntax 853 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the 854 receiptRequest attribute only within the signed attributes associated with 855 a signed message. 857 ReceiptRequest ::= SEQUENCE { 858 signedContentIdentifier ContentIdentifier, 859 receiptsFrom ReceiptsFrom, 860 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } 862 ub-receiptsTo INTEGER ::= 16 864 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 865 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 867 ContentIdentifier ::= OCTET STRING 869 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 870 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 872 A signedContentIdentifier MUST be created by the message originator when 873 creating a receipt request. To ensure global uniqueness, the minimal 874 signedContentIdentifier SHOULD contain a concatenation of user-specific 875 identification information (such as a user name or public keying material 876 identification information), a GeneralizedTime string, and a random number. 878 The receiptsFrom field is used by the originator to specify the recipients 879 requested to return a signed receipt. A CHOICE is provided to allow 880 specification of: 881 - receipts from all recipients are requested 882 - receipts from first tier (recipients that did not receive the 883 message as members of a mailing list) recipients are requested 884 - receipts from a specific list of recipients are requested 886 ReceiptsFrom ::= CHOICE { 887 allOrFirstTier [0] AllOrFirstTier, 888 -- formerly "allOrNone [0]AllOrNone" 889 receiptList [1] SEQUENCE OF GeneralNames } 891 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 892 allReceipts (0), 893 firstTierRecipients (1) } 895 The receiptsTo field is used by the originator to identify the user(s) to 896 whom the identified recipient should send signed receipts. The message 897 originator MUST populate the receiptsTo field with a GeneralNames for each 898 entity to whom the recipient should send the signed receipt.�If the message 899 originator wants the recipient to send the signed receipt to the 900 originator, then the originator MUST include a GeneralNames for itself in 901 the receiptsTo field. 903 2.8 Receipt Syntax 905 Receipts are represented using a new content type, Receipt. The Receipt 906 content type shall have ASN.1 type Receipt. Receipts must be encapsulated 907 within a SignedData message. 909 Receipt ::= SEQUENCE { 910 version Version, -- Version is imported from [CMS] 911 contentType ContentType, 912 signedContentIdentifier ContentIdentifier, 913 originatorSignatureValue OCTET STRING } 915 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 916 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 918 The version field defines the syntax version number, which is 1 for this 919 version of the standard. 921 2.9 Content Hints 923 Many applications find it useful to have information that describes the 924 innermost signed content of a multi-layer message available on the 925 outermost signature layer. The contentHints attribute provides such 926 information. 928 Content-hints attribute values have ASN.1 type contentHints. 930 ContentHints ::= SEQUENCE { 931 � contentDescription UTF8String SIZE (1..MAX) OPTIONAL, 932 � contentType ContentType } 934 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 935 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 937 The contentDescription field may be used to provide information that the 938 recipient may use to select protected messages for processing, such as a 939 message subject. If this field is set, then the attribute is expected to 940 appear on the signedData object enclosing an envelopedData object and not 941 on the inner signedData object. The SIZE (1..MAX) construct constrains the 942 sequence to have at least one entry. MAX indicates the upper bound is 943 unspecified. Implementations are free to choose an upper bound that suits 944 their environment. 946 Messages which contain a signedData object wrapped around an envelopedData 947 object, thus masking the inner content type of the message, SHOULD include 948 a contentHints attribute, except for the case of the data content type. 949 Specific message content types may either force or preclude the inclusion 950 of the contentHints attribute. For example, when a signedData/Receipt is 951 encrypted within an envelopedData object, an outer signedData object MUST 952 be created that encapsulates the envelopedData object and a contentHints 953 attribute with contentType set to the id-ct-receipt object identifier MUST 954 be included in the outer signedData SignerInfo signedAttributes. 956 2.10� Message Signature Digest Attribute 958 The msgSigDigest attribute can only be used in the signed attributes of a 959 signed receipt.�It contains the digest of the ASN.1 DER encoded 960 signedAttributes included in the original signedData that requested the 961 signed receipt.�Only one msgSigDigest attribute can appear in an signed 962 attributes set. It is defined as follows: 964 msgSigDigest ::= OCTET STRING 966 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 967 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 969 2.11 Signed Content Reference Attribute 971 The contentReference attribute is a link from one SignedData to another. It 972 may be used to link a reply to the original message to which it refers, or 973 to incorporate by reference one SignedData into another. The first 974 SignedData MUST include a contentIdentifier signed attribute, which SHOULD 975 be constructed as specified in section 2.7. The second SignedData links to 976 the first by including a ContentReference signed attribute containing the 977 content type, content identifier, and signature value from the first 978 SignedData. 980 ContentReference ::= SEQUENCE { 981 contentType ContentType, 982 signedContentIdentifier ContentIdentifier, 983 originatorSignatureValue OCTET STRING } 985 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 986 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 988 3. Security Labels 990 This section describes the syntax to be used for security labels that can 991 optionally be associated with S/MIME encapsulated data. A security label is 992 a set of security information regarding the sensitivity of the content that 993 is protected by S/MIME encapsulation. 995 "Authorization" is the act of granting rights and/or privileges to users 996 permitting them access to an object. "Access control" is a means of 997 enforcing these authorizations. The sensitivity information in a security 998 label can be compared with a user's authorizations to determine if the user 999 is allowed to access the content that is protected by S/MIME encapsulation. 1001 Security labels may be used for other purposes such as a source of routing 1002 information. The labels are often priority based ("secret", "confidential", 1003 "restricted", and so on) or role-based, describing which kind of people can 1004 see the information ("patient's health-care team", "medical billing 1005 agents", "unrestricted", and so on). 1007 3.1 Security Label Processing Rules 1009 A sending agent may include a security label attribute in the signed 1010 attributes of a signedData object. A receiving agent examines the security 1011 label on a received message and determines whether or not the recipient is 1012 allowed to see the contents of the message. 1014 3.1.1 Adding Security Labels 1016 A sending agent that is using security labels MUST put the security label 1017 attribute in the signedAttributes field of a SignerInfo block. The security 1018 label attribute MUST NOT be included in the unsigned attributes. Integrity 1019 and authentication security services MUST be applied to the security label, 1020 therefore it MUST be included as an signed attribute, if used. This causes 1021 the security label attribute to be part of the data that is hashed to form 1022 the SignerInfo signature value. A SignerInfo block MUST NOT have more than 1023 one security label signed attribute. 1025 When there are multiple SignedData blocks applied to a message, a security 1026 label attribute may be included in either the inner signature, outer 1027 signature, or both. A security label signed attribute may be included in a 1028 signedAttributes field within the inner SignedData block. The inner 1029 security label will include the sensitivities of the original content and 1030 will be used for access control decisions related to the plaintext 1031 encapsulated content. The inner signature provides authentication of the 1032 inner security label and cryptographically protects the original signer's 1033 inner security label of the original content. 1035 When the originator signs the plaintext content and signed attributes, the 1036 inner security label is bound to the plaintext content. An intermediate 1037 entity cannot change the inner security label without invalidating the 1038 inner signature. The confidentiality security service can be applied to the 1039 inner security label by encrypting the entire inner signedData object 1040 within an EnvelopedData block. 1042 A security label signed attribute may also be included in a 1043 signedAttributes field within the outer SignedData block. The outer 1044 security label will include the sensitivities of the encrypted message and 1045 will be used for access control decisions related to the encrypted message 1046 and for routing decisions. The outer signature provides authentication of 1047 the outer security label (as well as for the encapsulated content which may 1048 include nested S/MIME messages). 1050 There can be multiple SignerInfos within a SignedData object, and each 1051 SignerInfo may include signedAttributes. Therefore, a single SignedData 1052 object may include multiple eSSSecurityLabels, each SignerInfo having an 1053 eSSSecurityLabel attribute. For example, an originator can send a signed 1054 message with two SignerInfos, one containing a DSS signature, the other 1055 containing an RSA signature. If any of the SignerInfos included in a 1056 SignedData object include an eSSSecurityLabel attribute, then all of the 1057 SignerInfos in that SignedData object MUST include an eSSSecurityLabel 1058 attribute and the value of each MUST be identical. 1060 3.1.2 Processing Security Labels 1062 Before processing an eSSSecurityLabel signedAttribute, the receiving agent 1063 MUST verify the signature of the SignerInfo which covers the 1064 eSSSecurityLabel attribute. A recipient MUST NOT process an 1065 eSSSecurityLabel attribute that has not been verified. 1067 A receiving agent MUST process the eSSSecurityLabel attribute, if present, 1068 in each SignerInfo in the SignedData object for which it verifies the 1069 signature. This may result in the receiving agent processing multiple 1070 eSSSecurityLabels included in a single SignedData object. Because all 1071 eSSSecurityLabels in a SignedData object must be identical, the receiving 1072 agent processes (such as performing access control) on the first 1073 eSSSecurityLabel that it encounters in a SignerInfo that it verifies, and 1074 then ensures that all other eSSSecurityLabels in signerInfos that it 1075 verifies are identical to the first one encountered. If the 1076 eSSSecurityLabels in the signerInfos that it verifies are not all 1077 identical, then the receiving agent MUST warn the user of this condition. 1079 Receiving agents SHOULD have a local policy regarding whether or not to 1080 show the inner content of a signedData object that includes an 1081 eSSSecurityLabel security-policy-identifier that the processing software 1082 does not recognize. If the receiving agent does not recognize the 1083 eSSSecurityLabel security-policy-identifier value, then it SHOULD stop 1084 processing the message and indicate an error. 1086 3.2 Syntax of eSSSecurityLabel 1088 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 module. 1089 (The MTSAbstractService module begins with "DEFINITIONS IMPLICIT TAGS 1090 ::=".) Further, the eSSSecurityLabel syntax is compatible with that used in 1091 [MSP4]. 1093 ESSSecurityLabel ::= SET { 1094 security-policy-identifier SecurityPolicyIdentifier, 1095 security-classification SecurityClassification OPTIONAL, 1096 privacy-mark ESSPrivacyMark OPTIONAL, 1097 security-categories SecurityCategories OPTIONAL } 1099 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1100 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 1102 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 1104 SecurityClassification ::= INTEGER { 1105 unmarked (0), 1106 unclassified (1), 1107 restricted (2), 1108 confidential (3), 1109 secret (4), 1110 top-secret (5) } (0..ub-integer-options) 1112 ub-integer-options INTEGER ::= 256 1114 ESSPrivacyMark ::= CHOICE { 1115 ��� pString����� PrintableString SIZE (1..ub-privacy-mark-length), 1116 ��� utf8String�� UTF8String SIZE (1..MAX) 1117 } 1119 ub-privacy-mark-length INTEGER ::= 128 1121 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1122 SecurityCategory 1124 ub-security-categories INTEGER ::= 64 1126 SecurityCategory ::= SEQUENCE { 1127 type [0] OBJECT IDENTIFIER, 1128 value [1] ANY DEFINED BY type -- defined by type 1129 } 1131 --Note: The aforementioned SecurityCategory syntax produces identical 1132 --hex encodings as the following SecurityCategory syntax that is 1133 --documented in the X.411 specification: 1134 -- 1135 --SecurityCategory ::= SEQUENCE { 1136 -- type [0] SECURITY-CATEGORY, 1137 -- value [1] ANY DEFINED BY type } 1138 -- 1139 --SECURITY-CATEGORY MACRO ::= 1140 --BEGIN 1141 --TYPE NOTATION ::= type | empty 1142 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1143 --END 1145 3.3 Security Label Components 1147 This section gives more detail on the the various components of the 1148 eSSSecurityLabel syntax. 1150 3.3.1 Security Policy Identifier 1152 A security policy is a set of criteria for the provision of security 1153 services. The eSSSecurityLabel security-policy-identifier is used to 1154 identify the security policy in force to which the security label relates. 1155 It indicates the semantics of the other security label components. 1157 3.3.2 Security Classification 1159 This specification defines the use of the Security Classification field 1160 exactly as is specified in the X.411 Recommendation, which states in part: 1162 If present, a security-classification may have one of a hierarchical 1163 list of values. The basic security-classification hierarchy is defined 1164 in this Recommendation, but the use of these values is defined by the 1165 security-policy in force. Additional values of security-classification, 1166 and their position in the hierarchy, may also be defined by a 1167 security-policy as a local matter or by bilateral agreement. The basic 1168 security-classification hierarchy is, in ascending order: unmarked, 1169 unclassified, restricted, confidential, secret, top-secret. 1171 This means that the security policy in force (identified by the 1172 eSSSecurityLabel security-policy-identifier) defines the 1173 SecurityClassification integer values and their meanings. 1175 An organization can develop its own security policy that defines the 1176 SecurityClassification INTEGER values and their meanings. However, the 1177 general interpretation of the X.411 specification is that the values of 0 1178 through 5 are reserved for the "basic hierarchy" values of unmarked, 1179 unclassified, restricted, confidential, secret, and top-secret. Note that 1180 X.411 does not provide the rules for how these values are used to label 1181 data and how access control is performed using these values. 1183 There is no universal definition of the rules for using these "basic 1184 hierarchy" values. Each organization (or group of organizations) will 1185 define a security policy which documents how the "basic hierarchy" values 1186 are used (if at all) and how access control is enforced (if at all) within 1187 their domain. 1189 Therefore, the security-classification value MUST be accompanied by a 1190 security-policy-identifier value to define the rules for its use. For 1191 example, a company's "secret" classification may convey a different meaning 1192 than the US Government "secret" classification. In summary, a security 1193 policy SHOULD NOT use integers 0 through 5 for other than their X.411 1194 meanings, and SHOULD instead use other values in a hierarchical fashion. 1196 Note that the set of valid security-classification values MUST be 1197 hierarchical, but these values do not necessarily need to be in ascending 1198 numerical order. Further, the values do not need to be contiguous. 1200 For example, in the Defense Message System 1.0 security policy, the 1201 security-classification value of 11 indicates Sensitive-But-Unclassified 1202 and 5 indicates top-secret. The hierarchy of sensitivity ranks top-secret 1203 as more sensitive than Sensitive-But-Unclassified even though the numerical 1204 value of top-secret is less than Sensitive-But-Unclassified. 1206 (Of course, if security-classification values are both hierarchical and in 1207 ascending order, a casual reader of the security policy is more likely to 1208 understand it.) 1210 An example of a security policy that does not use any of the X.411 values 1211 might be: 1212 10 -- anyone 1213 15 -- Morgan Corporation and its contractors 1214 20 -- Morgan Corporation employees 1215 25 -- Morgan Corporation board of directors 1217 An example of a security policy that uses part of the X.411 hierarchy might 1218 be: 1219 0 -- unmarked 1220 1 -- unclassified, can be read by everyone 1221 2 -- restricted to Timberwolf Productions staff 1222 6 -- can only be read to Timberwolf Productions executives 1224 3.3.3 Privacy Mark 1226 If present, the eSSSecurityLabel privacy-mark is not used for access 1227 control. The content of the eSSSecurityLabel privacy-mark may be defined by 1228 the security policy in force (identified by the eSSSecurityLabel 1229 security-policy-identifier) which may define a list of values to be used. 1230 Alternately, the value may be determined by the originator of the 1231 security-label. 1233 3.3.4 Security Categories 1235 If present, the eSSSecurityLabel security-categories provide further 1236 granularity for the sensitivity of the message. The security policy in 1237 force (identified by the eSSSecurityLabel security-policy-identifier) is 1238 used to indicate the syntaxes that are allowed to be present in the 1239 eSSSecurityLabel security-categories. Alternately, the security-categories 1240 and their values may be defined by bilateral agreement. 1242 3.4 Equivalent Security Labels 1244 Because organizations are allowed to define their own security policies, 1245 many different security policies will exist. Some organizations may wish to 1246 create equivalencies between their security policies with the security 1247 policies of other organizations. For example, the Acme Company and the 1248 Widget Corporation may reach a bilateral agreement that the "Acme private" 1249 security-classification value is equivalent to the "Widget sensitive" 1250 security-classification value. 1252 Receiving agents MUST NOT process an equivalentLabels attribute in a 1253 message if the agent does not trust the signer of that attribute to 1254 translate the original eSSSecurityLabel values to the security policy 1255 included in the equivalentLabels attribute. Receiving agents have the 1256 option to process equivalentLabels attributes but do not have to. It is 1257 acceptable for a receiving agent to only process eSSSecurityLabels. All 1258 receiving agents SHOULD recognize equivalentLabels attributes even if they 1259 do not process them. 1261 3.4.1 Creating Equivalent Labels 1263 The EquivalentLabels signed attribute is defined as: 1265 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 1267 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1268 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 1270 As stated earlier, the ESSSecurityLabel contains the sensitivity values 1271 selected by the original signer of the signedData. If an ESSSecurityLabel 1272 is present in a signerInfo, all signerInfos in the signedData MUST contain 1273 an ESSSecurityLabel and they MUST all be identical. In addition to an 1274 ESSSecurityLabel, a signerInfo MAY also include an equivalentLabels signed 1275 attribute. If present, the equivalentLabels attribute MUST include one or 1276 more security labels that are believed by the signer to be semantically 1277 equivalent to the ESSSecurityLabel attribute included in the same 1278 signerInfo. 1280 All security-policy object identifiers MUST be unique in the set of 1281 ESSSecurityLabel and EquivalentLabels security labels. Before using an 1282 EquivalentLabels attribute, an agent MUST ensure that all security-policy 1283 OIDs are unique in the security label or labels included in the 1284 EquivalentLabels. Once the agent selects the security label (within the 1285 EquivalentLabels) to be used for processing, then the security-policy OID 1286 of the selected EquivalentLabels security label MUST be compared with the 1287 ESSSecurityLabel security-policy OID to ensure that they are unique. 1289 In the case that an ESSSecurityLabel attribute is not included in a 1290 signerInfo, then an EquivalentLabels attribute may still be included. For 1291 example, in the Acme security policy, the absence of an ESSSecurityLabel 1292 could be defined to equate to a security label composed of the Acme 1293 security-policy OID and the "unmarked" security-classification. 1295 Note that equivalentLabels MUST NOT be used to convey security labels that 1296 are semantically different from the ESSSecurityLabel included in the 1297 signerInfos in the signedData. If an entity needs to apply a security label 1298 that is semantically different from the ESSSecurityLabel, then it MUST 1299 include the sematically different security label in an outer signedData 1300 object that encapsulates the signedData object that includes the 1301 ESSSecurityLabel. 1303 If present, the equivalentLabels attribute MUST be an signed attribute; it 1304 MUST NOT be an unsigned attribute. CMS defines signedAttributes as a SET OF 1305 Attribute. A signerInfo MUST NOT include multiple instances of the 1306 equivalentLabels attribute. CMS defines the ASN.1 syntax for the signed 1307 attributes to include attrValues SET OF AttributeValue. A equivalentLabels 1308 attribute MUST only include a single instance of AttributeValue. There MUST 1309 NOT be zero or multiple instances of AttributeValue present in the 1310 attrValues SET OF AttributeValue. 1312 3.4.2 Processing Equivalent Labels 1314 A receiving agent SHOULD process the ESSSecurityLabel before processing any 1315 EquivalentLabels. If the policy in the ESSSecurityLabel is understood by 1316 the receiving agent, it MUST process that label and MUST ignore all 1317 EquivalentLabels. 1319 When processing an EquivalentLabels attribute, the receiving agent MUST 1320 validate the signature on the EquivalentLabels attribute. A receiving agent 1321 MUST NOT act on an equivalentLabels attribute for which the signature could 1322 not be validated, and MUST NOT act on an equivalentLabels attribute unless 1323 that attribute is signed by an entity trusted to to translate the original 1324 eSSSecurityLabel values to to the security policy included in the 1325 equivalentLabels attribute. Determining who is allowed to specify 1326 equivalence mappings is a local policy. If a message has more than one 1327 EquivalentLabels attribute, the receiving agent SHOULD process the first 1328 one that it reads and validates that contains the security policy of 1329 interest to the receiving agent. 1331 4. Mail List Management 1333 Sending agents must create recipient-specific data structures for each 1334 recipient of an encrypted message. This process can impair performance for 1335 messages sent to a large number of recipients. Thus, Mail List Agents 1336 (MLAs) that can take a single message and perform the recipient-specific 1337 encryption for every recipient are often desired. 1339 An MLA appears to the message originator as a normal message recipient, but 1340 the MLA acts as a message expansion point for a Mail List (ML). The sender 1341 of a message directs the message to the MLA, which then redistributes the 1342 message to the members of the ML. This process offloads the per-recipient 1343 processing from individual user agents and allows for more efficient 1344 management of large MLs. MLs are true message recipients served by MLAs 1345 that provide cryptographic and expansion services for the mailing list. 1347 In addition to cryptographic handling of messages, secure mailing lists 1348 also have to prevent mail loops. A mail loop is where one mailing list is a 1349 member of a second mailing list, and the second mailing list is a member of 1350 the first. A message will go from one list to the other in a 1351 rapidly-cascading succession of mail that will be distributed to all other 1352 members of both lists. 1354 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the 1355 outer signature of a triple wrapped message. The mlExpansionHistory 1356 attribute is essentially a list of every MLA that has processed the 1357 message. If an MLA sees its own unique entity identifier in the list, it 1358 knows that a loop has been formed, and does not send the message to the 1359 list again. 1361 4.1 Mail List Expansion 1363 Mail list expansion processing is noted in the value of the 1364 mlExpansionHistory attribute, located in the signed attributes of the MLA's 1365 SignerInfo block. The MLA creates or updates the signed mlExpansionHistory 1366 attribute value each time the MLA expands and signs a message for members 1367 of a mail list. 1369 The MLA MUST add an MLData record containing the MLA's identification 1370 information, date and time of expansion, and optional receipt policy to the 1371 end of the mail list expansion history sequence. If the mlExpansionHistory 1372 attribute is absent, then the MLA MUST add the attribute and the current 1373 expansion becomes the first element of the sequence. If the 1374 mlExpansionHistory attribute is present, then the MLA MUST add the current 1375 expansion information to the end of the existing MLExpansionHistory 1376 sequence. Only one mlExpansionHistory attribute can be included in the 1377 signedAttributes of a SignerInfo. 1379 Note that if the mlExpansionHistory attribute is absent, then the recipient 1380 is a first tier message recipient. 1382 There can be multiple SignerInfos within a SignedData object, and each 1383 SignerInfo may include signedAttributes. Therefore, a single SignedData 1384 object may include multiple SignerInfos, each SignerInfo having a 1385 mlExpansionHistory attribute. For example, an MLA can send a signed message 1386 with two SignerInfos, one containing a DSS signature, the other containing 1387 an RSA signature. 1389 If an MLA creates a SignerInfo that includes an mlExpansionHistory 1390 attribute, then all of the SignerInfos created by the MLA for that 1391 SignedData object MUST include an mlExpansionHistory attribute, and the 1392 value of each MUST be identical. Note that other agents might later add 1393 SignerInfo attributes to the SignedData block, and those additional 1394 SignerInfos might not include mlExpansionHistory attributes. 1396 A recipient MUST verify the signature of the SignerInfo which covers the 1397 mlExpansionHistory attribute before processing the mlExpansionHistory, and 1398 MUST NOT process the mlExpansionHistory attribute unless the signature over 1399 it has been verified. If a SignedData object has more than one SignerInfo 1400 that has an mlExpansionHistory attribute, the recipient MUST compare the 1401 mlExpansionHistory attributes in all the SignerInfos that it has verified, 1402 and MUST NOT process the mlExpansionHistory attribute unless every verified 1403 mlExpansionHistory attribute in the SignedData block is identical. If the 1404 mlExpansionHistory attributes in the verified signerInfos are not all 1405 identical, then the receiving agent MUST stop processing the message and 1406 SHOULD notify the user or MLA administrator of this error condition. In the 1407 mlExpansionHistory processing, SignerInfos that do not have an 1408 mlExpansionHistory attribute are ignored. 1410 4.1.1 Detecting Mail List Expansion Loops 1412 Prior to expanding a message, the MLA examines the value of any existing 1413 mail list expansion history attribute to detect an expansion loop. An 1414 expansion loop exists when a message expanded by a specific MLA for a 1415 specific mail list is redelivered to the same MLA for the same mail list. 1417 Expansion loops are detected by examining the mailListIdentifier field of 1418 each MLData entry found in the mail list expansion history. If an MLA finds 1419 its own identification information, then the MLA must discontinue expansion 1420 processing and should provide warning of an expansion loop to a human mail 1421 list administrator. The mail list administrator is responsible for 1422 correcting the loop condition. 1424 4.2 Mail List Agent Processing 1426 The first few paragraphs of this section provide a high-level description 1427 of MLA processing. The rest of the section provides a detailed description 1428 of MLA processing. 1430 MLA message processing depends on the structure of the S/MIME layers in the 1431 message sent to the MLA for expansion. In addition to sending triple 1432 wrapped messages to an MLA, an entity can send other types of messages to 1433 an MLA, such as: 1434 - a single wrapped signedData or envelopedData message 1435 - a double wrapped message (such as signed and enveloped, enveloped and 1436 signed, or signed and signed, and so on) 1437 - a quadruple-wrapped message (such as if a well-formed triple wrapped 1438 message was sent through a gateway that added an outer SignedData layer) 1440 In all cases, the MLA MUST parse all layers of the received message to 1441 determine if there are any signedData layers that include an 1442 eSSSecurityLabel signedAttribute. This may include decrypting an 1443 EnvelopedData layer to determine if an encapsulated SignedData layer 1444 includes an eSSSecurityLabel attribute. The MLA MUST fully process each 1445 eSSSecurityLabel attribute found in the various signedData layers, 1446 including performing access control checks, before distributing the message 1447 to the ML members. The details of the access control checks are beyond the 1448 scope of this document. The MLA MUST verify the signature of the signerInfo 1449 including the eSSSecurityLabel attribute before using it. 1451 In all cases, the MLA MUST sign the message to be sent to the ML members in 1452 a new "outer" signedData layer. The MLA MUST add or update an 1453 mlExpansionHistory attribute in the "outer" signedData that it creates to 1454 document MLA processing. If there was an "outer" signedData layer included 1455 in the original message received by the MLA, then the MLA-created "outer" 1456 signedData layer MUST include each signed attribute present in the 1457 original "outer" signedData layer, unless the MLA explicitly replaces an 1458 attribute (such as signingTime or mlExpansionHistory) with a new value. 1460 When an S/MIME message is received by the MLA, the MLA MUST first determine 1461 which received signedData layer, if any, is the "outer" signedData layer. 1462 To identify the received "outer" signedData layer, the MLA MUST verify the 1463 signature and fully process the signedAttributes in each of the 1464 outer signedData layers (working from the outside in) to determine if any 1465 of them either include an mlExpansionHistory attribute or encapsulate an 1466 envelopedData object. 1468 The MLA's search for the "outer" signedData layer is completed when it 1469 finds one of the following: 1470 - the "outer" signedData layer that includes an mlExpansionHistory 1471 attribute or encapsulates an envelopedData object 1472 - an envelopedData layer 1473 - the original content (that is, a layer that is neither envelopedData nor 1474 signedData). 1476 If the MLA finds an "outer" signedData layer, then the MLA MUST perform 1477 the following steps: 1479 1. Strip off all of the signedData layers that encapsulated the "outer" 1480 signedData layer 1482 2. Strip off the "outer" signedData layer itself (after remembering the 1483 included signedAttributes) 1485 3. Expand the envelopedData (if present) 1487 4. Sign the message to be sent to the ML members in a new "outer" 1488 signedData layer that includes the signedAttributes (unless explicitly 1489 replaced) from the original, received "outer" signedData layer. 1491 If the MLA finds an "outer" signedData layer that includes an 1492 mlExpansionHistory attribute AND the MLA subsequently finds an 1493 envelopedData layer buried deeper with the layers of the received message, 1494 then the MLA MUST strip off all of the signedData layers down to the 1495 envelopedData layer (including stripping off the original "outer" 1496 signedData layer) and MUST sign the expanded envelopedData in a new "outer" 1497 signedData layer that includes the signedAttributes (unless explicitly 1498 replaced) from the original, received "outer" signedData layer. 1500 If the MLA does not find an "outer" signedData layer AND does not find an 1501 envelopedData layer, then the MLA MUST sign the original, received message 1502 in a new "outer" signedData layer. If the MLA does not find an "outer" 1503 signedData AND does find an envelopedData layer then it MUST expand the 1504 envelopedData layer, if present, and sign it in a new "outer" signedData 1505 layer. 1507 4.2.1 Examples of Rule Processing 1509 The following examples help explain the rules above: 1511 1) A message (S1(Original Content)) (where S = SignedData) is sent to the 1512 MLA in which the signedData layer does not include an MLExpansionHistory 1513 attribute. The MLA verifies and fully processes the signedAttributes in S1. 1514 The MLA decides that there is not an original, received "outer" signedData 1515 layer since it finds the original content, but never finds an envelopedData 1516 and never finds an mlExpansionHistory attribute. The MLA calculates a new 1517 signedData layer, S2, resulting in the following message sent to the ML 1518 recipients: (S2(S1(Original Content))). The MLA includes an 1519 mlExpansionHistory attribute in S2. 1521 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which 1522 none of the signedData layers includes an MLExpansionHistory attribute. The 1523 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The 1524 MLA decides that there is not an original, received "outer" signedData 1525 layer since it finds the original content, but never finds an envelopedData 1526 and never finds an mlExpansionHistory attribute. The MLA calculates a new 1527 signedData layer, S4, resulting in the following message sent to the ML 1528 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an 1529 mlExpansionHistory attribute in S4. 1531 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent 1532 to the MLA in which S1 does not include an MLExpansionHistory attribute. 1533 The MLA decides that there is not an original, received "outer" signedData 1534 layer since it finds the E1 as the outer layer. The MLA expands the 1535 recipientInformation in E1. The MLA calculates a new signedData layer, S2, 1536 resulting in the following message sent to the ML recipients: 1537 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory 1538 attribute in S2. 1540 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 1541 includes an MLExpansionHistory attribute. The MLA verifies the signature 1542 and fully processes the signedAttributes in S2. The MLA finds the 1543 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" 1544 signedData. The MLA remembers the signedAttributes included in S2 for later 1545 inclusion in the new outer signedData that it applies to the message. The 1546 MLA strips off S2. The MLA then expands the recipientInformation in E1 1547 (this invalidates the signature in S2 which is why it was stripped). The 1548 MLA calculates a new signedData layer, S3, resulting in the following 1549 message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA 1550 includes in S3 the attributes from S2 (unless it specifically replaces an 1551 attribute value) including an updated mlExpansionHistory attribute. 1553 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 1554 none of the signedData layers include an MLExpansionHistory attribute. The 1555 MLA verifies the signature and fully processes the signedAttributes in S3 1556 and S2. When the MLA encounters E1, then it decides that S2 is the "outer" 1557 signedData since S2 encapsulates E1. The MLA remembers the signedAttributes 1558 included in S2 for later inclusion in the new outer signedData that it 1559 applies to the message. The MLA strips off S3 and S2. The MLA then expands 1560 the recipientInformation in E1 (this invalidates the signatures in S3 and 1561 S2 which is why they were stripped). The MLA calculates a new signedData 1562 layer, S4, resulting in the following message sent to the ML recipients: 1563 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from 1564 S2 (unless it specifically replaces an attribute value) and includes a new 1565 mlExpansionHistory attribute. 1567 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 1568 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies 1569 the signature and fully processes the signedAttributes in S3. The MLA finds 1570 the mlExpansionHistory in S3, so it decides that S3 is the "outer" 1571 signedData. The MLA remembers the signedAttributes included in S3 for later 1572 inclusion in the new outer signedData that it applies to the message. The 1573 MLA keeps on parsing encapsulated layers because it must determine if there 1574 are any eSSSecurityLabel attributes contained within. The MLA verifies the 1575 signature and fully processes the signedAttributes in S2. When the MLA 1576 encounters E1, then it strips off S3 and S2. The MLA then expands the 1577 recipientInformation in E1 (this invalidates the signatures in S3 and S2 1578 which is why they were stripped). The MLA calculates a new signedData 1579 layer, S4, resulting in the following message sent to the ML recipients: 1580 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from 1581 S3 (unless it specifically replaces an attribute value) including an 1582 updated mlExpansionHistory attribute. 1584 4.2.3 Processing Choices 1586 The processing used depends on the type of the outermost layer of the 1587 message. There are three cases for the type of the outermost data: 1588 - EnvelopedData 1589 - SignedData 1590 - data 1592 4.2.3.1 Processing for EnvelopedData 1594 1. The MLA locates its own RecipientInfo and uses the information it 1595 contains to obtain the message key. 1597 2. The MLA removes the existing recipientInfos field and replaces it with a 1598 new recipientInfos value built from RecipientInfo structures created for 1599 each member of the mailing list. The MLA also removes the existing 1600 originatorInfo field and replaces it with a new originatorInfo value built 1601 from information describing the MLA. 1603 3. The MLA encapsulates the expanded encrypted message in a SignedData 1604 block, adding an mlExpansionHistory attribute as described in the "Mail 1605 List Expansion" section to document the expansion. 1607 4. The MLA signs the new message and delivers the updated message to mail 1608 list members to complete MLA processing. 1610 4.2.3.2 Processing for SignedData 1612 MLA processing of multi-layer messages depends on the type of data in each 1613 of the layers. Step 3 below specifies that different processing will take 1614 place depending on the type of CMS message that has been signed. That is, 1615 it needs to know the type of data at the next inner layer, which may or may 1616 not be the innermost layer. 1618 1. The MLA verifies the signature value found in the outermost SignedData 1619 layer associated with the signed data. MLA processing of the message 1620 terminates if the message signature is invalid. 1622 2. If the outermost SignedData layer includes an signed mlExpansionHistory 1623 attribute the MLA checks for an expansion loop as described in the 1624 "Detecting Mail List Expansion Loops" section. 1626 3. Determine the type of the data that has been signed. That is, look at 1627 the type of data on the layer just below the SignedData, which may or may 1628 not be the "innermost" layer. Based on the type of data, perform either 1629 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other 1630 types). 1632 3.1. If the signed data is EnvelopedData, the MLA performs expansion 1633 processing of the encrypted message as described previously. Note that 1634 this process invalidates the signature value in the outermost 1635 SignedData layer associated with the original encrypted message. 1636 Proceed to section 3.2 with the result of the expansion. 1638 3.2. If the signed data is SignedData, or is the result of expanding an 1639 EnvelopedData block in step 3.1: 1641 3.2.1. The MLA strips the existing outermost SignedData layer after 1642 remembering the value of the mlExpansionHistory and all other 1643 signed attributes in that layer, if present. 1645 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 1646 encapsulates the expanded encrypted message in a new outermost 1647 SignedData layer. On the other hand, if the signed data is 1648 SignedData (from step 3.2), the MLA encapsulates the signed data in 1649 a new outermost SignedData layer. 1651 3.2.3. The outermost signedData layer created by the MLA replaces 1652 the original outermost signedData layer.�The MLA MUST create an 1653 signed attribute list for the new outermost signedData layer which 1654 MUST include each signed attribute present in the original 1655 outermost signedData layer, unless the MLA explicitly replaces one 1656 or more particular attributes with new value.�A special case is the 1657 mlExpansionHistory attribute.�The MLA MUST add an 1658 mlExpansionHistory signed attribute to the outer signedData layer 1659 as follows: 1661 3.2.3.1. If the original outermost SignedData layer included an 1662 mlExpansionHistory attribute, the attribute's value is copied 1663 and updated with the current ML expansion information as 1664 described in the "Mail List Expansion" section. 1666 3.2.3.2. If the original outermost SignedData layer did not 1667 include an mlExpansionHistory attribute, a new attribute value 1668 is created with the current ML expansion information as 1669 described in the "Mail List Expansion" section. 1671 3.3. If the signed data is not EnvelopedData or SignedData: 1673 3.3.1. The MLA encapsulates the received signedData object in an 1674 outer SignedData object, and adds an mlExpansionHistory attribute 1675 to the outer SignedData object containing the current ML expansion 1676 information as described in the "Mail List Expansion" section. 1678 4. The MLA signs the new message and delivers the updated message to mail 1679 list members to complete MLA processing. 1681 A flow chart for the above steps would be: 1683 1. Has a valid signature? 1684 YES -> 2. 1685 NO -> STOP. 1686 2. Does outermost SignedData layer 1687 contain mlExpansionHistory? 1688 YES -> Check it, then -> 3. 1689 NO -> 3. 1690 3. Check type of data just below outermost 1691 SignedData. 1692 EnvelopedData -> 3.1. 1693 SignedData -> 3.2. 1694 all others -> 3.3. 1695 3.1. Expand the encrypted message, then -> 3.2. 1696 3.2. -> 3.2.1. 1697 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 1698 and other signed attributes, then -> 3.2.2. 1699 3.2.2. Encapsulate in new signature, then -> 3.2.3. 1700 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? 1701 YES -> copy the old mlExpansionHistory values, then -> 4. 1702 NO -> create new mlExpansionHistory value, then -> 4. 1703 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory 1704 attribute, then -> 4. 1705 4. Sign message, deliver it, STOP. 1707 4.2.3.3 Processing for data 1709 1. The MLA encapsulates the message in a SignedData layer, and adds an 1710 mlExpansionHistory attribute containing the current ML expansion 1711 information as described in the "Mail List Expansion" section. 1713 2. The MLA signs the new message and delivers the updated message to mail 1714 list members to complete MLA processing. 1716 4.3 Mail List Agent Signed Receipt Policy Processing 1718 If a mailing list (B) is a member of another mailing list (A), list B often 1719 needs to propagate forward the mailing list receipt policy of A. As a 1720 general rule, a mailing list should be conservative in propagating forward 1721 the mailing list receipt policy because the ultimate recipient need only 1722 process the last item in the ML expansion history. The MLA builds the 1723 expansion history to meet this requirement. 1725 The following table describes the outcome of the union of mailing list A's 1726 policy (the rows in the table) and mailing list B's policy (the columns in 1727 the table). 1729 | B's policy 1730 A's policy | none insteadOf inAdditionTo missing 1731 ------------------------------------------------------------------------- 1732 none | none none none none 1733 insteadOf | none insteadOf(B) *1 insteadOf(A) 1734 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) 1735 missing | none insteadOf(B) inAdditionTo(B) missing 1737 *1 = insteadOf(insteadOf(A) + inAdditionTo(B)) 1738 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) 1740 4.4 Mail List Expansion History Syntax 1742 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If 1743 there are more than ub-ml-expansion-history mailing lists in the sequence, 1744 the processing agent should provide notification of the error to a human 1745 mail list administrator.�The mail list administrator is responsible for 1746 correcting the overflow condition. 1748 MLExpansionHistory ::= SEQUENCE 1749 SIZE (1..ub-ml-expansion-history) OF MLData 1751 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1752 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 1754 ub-ml-expansion-history INTEGER ::= 64 1756 MLData contains the expansion history describing each MLA that has 1757 processed a message. As an MLA distributes a message to members of an ML, 1758 the MLA records its unique identifier, date and time of expansion, and 1759 receipt policy in an MLData structure. 1761 MLData ::= SEQUENCE { 1762 mailListIdentifier EntityIdentifier, 1763 -- EntityIdentifier is imported from [CMS] 1764 expansionTime GeneralizedTime, 1765 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 1767 The receipt policy of the ML can withdraw the originator's request for the 1768 return of a signed receipt. However, if the originator of the message has 1769 not requested a signed receipt, the MLA cannot request a signed receipt. In 1770 the event that a ML's signed receipt policy supersedes the originator's 1771 request for signed receipts, such that the originator will not receive any 1772 signed receipts, then the MLA MAY inform the originator of that fact. 1774 When present, the mlReceiptPolicy specifies a receipt policy that 1775 supersedes the originator's request for signed receipts. The policy can be 1776 one of three possibilities: receipts MUST NOT be returned (none); receipts 1777 should be returned to an alternate list of recipients, instead of to the 1778 originator (insteadOf); or receipts should be returned to a list of 1779 recipients in addition to the originator (inAdditionTo). 1781 MLReceiptPolicy ::= CHOICE { 1782 none [0] NULL, 1783 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1784 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1786 5. Security Considerations 1788 This entire document discusses security. 1790 A. ASN.1 Module 1792 ExtendedSecurityServices 1793 { iso(1) member-body(2) us(840) rsadsi(113549) 1794 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 1796 DEFINITIONS IMPLICIT TAGS ::= 1797 BEGIN 1799 IMPORTS 1801 -- Cryptographic Message Syntax (CMS) 1802 ContentType, EntityIdentifier, SubjectKeyIdentifier, Version 1803 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 1804 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } 1806 -- X.509 1807 GeneralNames FROM CertificateExtensions 1808 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; 1810 -- Extended Security Services 1812 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 1813 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 1814 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 1815 -- have at least one entry. MAX indicates the upper bound is unspecified. 1816 -- Implementations are free to choose an upper bound that suits their 1817 -- environment. 1819 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1820 -- The contents are formatted as described in [UTF8] 1822 -- Section 2.7 1824 ReceiptRequest ::= SEQUENCE { 1825 signedContentIdentifier ContentIdentifier, 1826 receiptsFrom ReceiptsFrom, 1827 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 1829 ub-receiptsTo INTEGER ::= 16 1831 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1832 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 1834 ContentIdentifier ::= OCTET STRING 1836 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1837 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 1839 ReceiptsFrom ::= CHOICE { 1840 allOrFirstTier [0] AllOrFirstTier, 1841 -- formerly "allOrNone [0]AllOrNone" 1842 receiptList [1] SEQUENCE OF GeneralNames } 1844 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 1845 allReceipts (0), 1846 firstTierRecipients (1) } 1848 -- Section 2.8 1850 Receipt ::= SEQUENCE { 1851 version Version, -- Version is imported from [CMS] 1852 contentType ContentType, 1853 signedContentIdentifier ContentIdentifier, 1854 originatorSignatureValue OCTET STRING } 1856 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1857 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 1859 -- Section 2.9 1861 ContentHints ::= SEQUENCE { 1862 � contentDescription UTF8String SIZE (1..MAX) OPTIONAL, 1863 � contentType ContentType } 1865 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1866 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 1868 -- Section 2.10 1870 MsgSigDigest ::= OCTET STRING 1872 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1873 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 1875 -- Section 2.11 1877 ContentReference ::= SEQUENCE { 1878 contentType ContentType, 1879 signedContentIdentifier ContentIdentifier, 1880 originatorSignatureValue OCTET STRING } 1882 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1883 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 1885 -- Section 3.2 1887 ESSSecurityLabel ::= SET { 1888 security-policy-identifier SecurityPolicyIdentifier, 1889 security-classification SecurityClassification OPTIONAL, 1890 privacy-mark ESSPrivacyMark OPTIONAL, 1891 security-categories SecurityCategories OPTIONAL } 1893 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1894 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 1896 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 1898 SecurityClassification ::= INTEGER { 1899 unmarked (0), 1900 unclassified (1), 1901 restricted (2), 1902 confidential (3), 1903 secret (4), 1904 top-secret (5) } (0..ub-integer-options) 1906 ub-integer-options INTEGER ::= 256 1908 ESSPrivacyMark ::= CHOICE { 1909 ��� pString����� PrintableString SIZE (1..ub-privacy-mark-length), 1910 ��� utf8String�� UTF8String SIZE (1..MAX) 1911 } 1913 ub-privacy-mark-length INTEGER ::= 128 1915 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1916 SecurityCategory 1918 ub-security-categories INTEGER ::= 64 1920 SecurityCategory ::= SEQUENCE { 1921 type [0] OBJECT IDENTIFIER, 1922 value [1] ANY DEFINED BY type -- defined by type 1923 } 1925 --Note: The aforementioned SecurityCategory syntax produces identical 1926 --hex encodings as the following SecurityCategory syntax that is 1927 --documented in the X.411 specification: 1928 -- 1929 --SecurityCategory ::= SEQUENCE { 1930 -- type [0] SECURITY-CATEGORY, 1931 -- value [1] ANY DEFINED BY type } 1932 -- 1933 --SECURITY-CATEGORY MACRO ::= 1934 --BEGIN 1935 --TYPE NOTATION ::= type | empty 1936 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1937 --END 1939 -- Section 3.4 1941 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 1943 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1944 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 1946 -- Section 4.4 1948 MLExpansionHistory ::= SEQUENCE 1949 SIZE (1..ub-ml-expansion-history) OF MLData 1951 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1952 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 1954 ub-ml-expansion-history INTEGER ::= 64 1956 MLData ::= SEQUENCE { 1957 mailListIdentifier EntityIdentifier, 1958 -- EntityIdentifier is imported from [CMS] 1959 expansionTime GeneralizedTime, 1960 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 1962 MLReceiptPolicy ::= CHOICE { 1963 none [0] NULL, 1964 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1965 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1967 END -- of ExtendedSecurityServices 1969 B. References 1971 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax 1972 Notation One (ASN.1)" 1974 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax 1975 Notation One (ASN.1)" 1977 [CMS] "Cryptographic Message Syntax", Internet Draft 1978 draft-ietf-smime-cms-xx. 1980 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) 1981 4.0", Specification SDN.701, Revision A, 1997-02-06. 1983 [MTSABS] "1988 International Telecommunication Union (ITU) Data 1984 Communication Networks Message Handling Systems: Message Transfer System: 1985 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, 1986 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) 1987 mts(3) modules(0) mts-abstract-service(1)} 1989 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315. 1991 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 1992 "S/MIME Version 2 Certificate Handling", RFC 2312. 1994 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft 1995 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate Handling", 1996 Internet Draft draft-ietf-smime-cert-xx. 1998 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 2000 C. Acknowledgments 2002 The first draft of this work was prepared by David Solo. John Pawling did a 2003 huge amount of very detailed revision work during the many phases of the 2004 document. 2006 Many other people have contributed hard work to this draft, including: 2007 Bancroft Scott 2008 Bengt Ackzell 2009 Blake Ramsdell 2010 Carlisle Adams 2011 David Kemp 2012 Jim Schaad 2013 Russ Housley 2014 Scott Hollenbeck 2015 Steve Dusse 2017 D. Open Issues 2019 None. 2021 E. Changes from draft-ietf-smime-ess-06 to draft-ietf-smime-ess-07 2023 1.3.4: Reworded second and fifth paragraphs a bit. Also added 2024 OID for sMIMEEncryptionKeyPreference. 2026 3.4: Clarified intention in second paragraph. Also slightly updated wording 2027 in fifth paragraph. 2029 3.4.2: Clarified intention in second paragraph. 2031 F: Changed my area code 2033 F. Editor's Address 2035 Paul Hoffman 2036 Internet Mail Consortium 2037 127 Segre Place 2038 Santa Cruz, CA 95060 2039 (831) 426-9827 2040 phoffman@imc.org