idnits 2.17.1 draft-ietf-smime-ess-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2496 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 152 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 85 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 113: '...identifier MUST be id-data. If the str...' RFC 2119 keyword, line 114: '...Data encapContentInfo eContent MUST be...' RFC 2119 keyword, line 140: '...contentType MUST be id-data. The Envel...' RFC 2119 keyword, line 171: '...agents MUST be able to interpret eithe...' RFC 2119 keyword, line 252: '...request MUST be in the inside signatur...' (152 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1818 has weird spacing: '... | none inst...' == Line 1820 has weird spacing: '... | none none...' == Line 1821 has weird spacing: '... | none inst...' == Line 1822 has weird spacing: '... | none inst...' == Line 1823 has weird spacing: '... | none inst...' ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [MUSTSHOULD], but that reference does not seem to mention RFC 2119 either. -- 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 (March 29, 1999) is 9122 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 2416 looks like a reference -- Missing reference section? 'MSG' on line 2410 looks like a reference -- Missing reference section? 'CERT' on line 2404 looks like a reference -- Missing reference section? 'SMIME2' on line 2427 looks like a reference -- Missing reference section? 'ASN1-1988' on line 2398 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 2413 looks like a reference -- Missing reference section? 'ESS' on line 332 looks like a reference -- Missing reference section? 'CMS' on line 2407 looks like a reference -- Missing reference section? '0' on line 2367 looks like a reference -- Missing reference section? '1' on line 2368 looks like a reference -- Missing reference section? 'MTSABS' on line 2419 looks like a reference -- Missing reference section? '2' on line 2369 looks like a reference -- Missing reference section? 'SMIME3' on line 2129 looks like a reference -- Missing reference section? 'UNIVERSAL 12' on line 2218 looks like a reference -- Missing reference section? 'UTF8' on line 2430 looks like a reference -- Missing reference section? 'ASN1-1994' on line 2401 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 18 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-12.txt Internet Mail Consortium 3 March 29, 1999 4 Expires in six months 6 Enhanced Security Services for S/MIME 8 Status of this memo 10 Internet-Drafts are working documents of the Internet Engineering Task 11 Force (IETF), its areas, and its working groups. Note that other 12 groups may also distribute working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet- Drafts as reference 17 material or to cite them other than as "work in progress." 19 To view the list Internet-Draft Shadow Directories, see 20 http://www.ietf.org/shadow.html. 22 This document is an Internet-Draft and is in full conformance with all 23 provisions of Section 10 of RFC2026. 25 1. Introduction 27 This document describes four optional security service extensions for 28 S/MIME. The services are: 29 - signed receipts 30 - security labels 31 - secure mailing lists 32 - signing certificates 33 The first three of these services provide functionality that is similar 34 to the Message Security Protocol [MSP4], but are useful in many other 35 environments, particularly business and finance. Signing certificates 36 are useful in any environment where certificates might be transmitted 37 with signed messages. 39 The services described here are extensions to S/MIME version 3 ([MSG] 40 and [CERT]), and some of them can also be added to S/MIME version 2 41 [SMIME2]. The extensions described here will not cause an S/MIME 42 version 3 recipient to be unable to read messages from an S/MIME 43 version 2 sender. However, some of the extensions will cause messages 44 created by an S/MIME version 3 sender to be unreadable by an S/MIME 45 version 2 recipient. 47 This document describes both the procedures and the attributes needed 48 for the four services. Note that some of the attributes described in 49 this document are quite useful in other contexts and should be 50 considered when extending S/MIME or other CMS applications. 52 The format of the messages are described in ASN.1:1988 [ASN1-1988]. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [MUSTSHOULD]. 58 This document is being discussed on the "ietf-smime" mailing list. To 59 subscribe, send a message to: 60 ietf-smime-request@imc.org 61 with the single word 62 subscribe 63 in the body of the message. There is a Web site for the mailing list at 64 . 66 1.1 Triple Wrapping 68 Some of the features of each service use the concept of a "triple 69 wrapped" message. A triple wrapped message is one that has been signed, 70 then encrypted, then signed again. The signers of the inner and outer 71 signatures may be different entities or the same entity. Note that the 72 S/MIME specification does not limit the number of nested 73 encapsulations, so there may be more than three wrappings. 75 1.1.1 Purpose of Triple Wrapping 77 Not all messages need to be triple wrapped. Triple wrapping is used 78 when a message must be signed, then encrypted, and then have signed 79 attributes bound to the encrypted body. Outer attributes may be added 80 or removed by the message originator or intermediate agents, and may be 81 signed by intermediate agents or the final recipient. 83 The inside signature is used for content integrity, non-repudiation 84 with proof of origin, and binding attributes (such as a security label) 85 to the original content. These attributes go from the originator to the 86 recipient, regardless of the number of intermediate entities such as 87 mail list agents that process the message. The signed attributes can be 88 used for access control to the inner body. Requests for signed receipts 89 by the originator are carried in the inside signature as well. 91 The encrypted body provides confidentiality, including confidentiality 92 of the attributes that are carried in the inside signature. 94 The outside signature provides authentication and integrity for 95 information that is processed hop-by-hop, where each hop is an 96 intermediate entity such as a mail list agent. The outer signature 97 binds attributes (such as a security label) to the encrypted body. 98 These attributes can be used for access control and routing decisions. 100 1.1.2 Steps for Triple Wrapping 102 The steps to create a triple wrapped message are: 104 1. Start with a message body, called the "original content". 106 2. Encapsulate the original content with the appropriate MIME 107 Content-type headers, such as "Content-type: text/plain". An exception 108 to this MIME encapsulation rule is that a signed receipt is not put in 109 MIME headers. 111 3. Sign the result of step 2 (the inner MIME headers and the original 112 content). The SignedData encapContentInfo eContentType object 113 identifier MUST be id-data. If the structure you create in step 4 is 114 multipart/signed, then the SignedData encapContentInfo eContent MUST be 115 absent. If the structure you create in step 4 is 116 application/pkcs7-mime, then the SignedData encapContentInfo eContent 117 MUST contain the result of step 2 above. The SignedData structure is 118 encapsulated by a ContentInfo SEQUENCE with a contentType of 119 id-signedData. 121 4. Add an appropriate MIME construct to the signed message from step 3 122 as defined in [MSG]. The resulting message is called the "inside 123 signature". 125 - If you are signing using multipart/signed, the MIME construct added 126 consists of a Content-type of multipart/signed with parameters, the 127 boundary, the result of step 2 above, the boundary, a Content-type 128 of application/pkcs7-signature, optional MIME headers (such as 129 Content-transfer-encoding and Content-disposition), and a body part 130 that is the result of step 3 above. 132 - If you are instead signing using application/pkcs7-mime, the MIME 133 construct added consists of a Content-type of application/pkcs7-mime 134 with parameters, optional MIME headers (such as 135 Content-transfer-encoding and Content-disposition), and the result 136 of step 3 above. 138 5. Encrypt the result of step 4 as a single block, turning it into an 139 application/pkcs7-mime object. The EnvelopedData encryptedContentInfo 140 contentType MUST be id-data. The EnvelopedData structure is 141 encapsulated by a ContentInfo SEQUENCE with a contentType of 142 id-envelopedData. This is called the "encrypted body". 144 6. Add the appropriate MIME headers: a Content-type of 145 application/pkcs7-mime with parameters, and optional MIME headers such 146 as Content-transfer-encoding and Content-disposition. 148 7. Using the same logic as in step 3 above, sign the result of step 6 149 (the MIME headers and the encrypted body) as a single block 151 8. Using the same logic as in step 4 above, add an appropriate MIME 152 construct to the signed message from step 7. The resulting message is 153 called the "outside signature", and is also the triple wrapped message. 155 1.2 Format of a Triple Wrapped Message 157 A triple wrapped message has many layers of encapsulation. The 158 structure differs based on the choice of format for the signed portions 159 of the message. Because of the way that MIME encapsulates data, the 160 layers do not appear in order, and the notion of "layers" becomes 161 vague. 163 There is no need to use the multipart/signed format in an inner 164 signature because it is known that the recipient is able to process 165 S/MIME messages (because they decrypted the middle wrapper). A sending 166 agent might choose to use the multipart/signed format in the outer 167 layer so that a non-S/MIME agent could see that the next inner layer is 168 encrypted; however, this is not of great value, since all it shows the 169 recipient is that the rest of the message is unreadable. Because many 170 sending agents always use multipart/signed structures, all receiving 171 agents MUST be able to interpret either multipart/signed or 172 application/pkcs7-mime signature structures. 174 The format of a triple wrapped message that uses multipart/signed for 175 both signatures is: 177 [step 8] Content-type: multipart/signed; 178 [step 8] protocol="application/pkcs7-signature"; 179 [step 8] boundary=outerboundary 180 [step 8] 181 [step 8] --outerboundary 182 [step 6] Content-type: application/pkcs7-mime; ) 183 [step 6] smime-type=enveloped-data ) 184 [step 6] ) 185 [step 4] Content-type: multipart/signed; | ) 186 [step 4] protocol="application/pkcs7-signature"; | ) 187 [step 4] boundary=innerboundary | ) 188 [step 4] | ) 189 [step 4] --innerboundary | ) 190 [step 2] Content-type: text/plain % | ) 191 [step 2] % | ) 192 [step 1] Original content % | ) 193 [step 4] | ) 194 [step 4] --innerboundary | ) 195 [step 4] Content-type: application/pkcs7-signature | ) 196 [step 4] | ) 197 [step 3] inner SignedData block (eContent is missing) | ) 198 [step 4] | ) 199 [step 4] --innerboundary-- | ) 200 [step 8] 201 [step 8] --outerboundary 202 [step 8] Content-type: application/pkcs7-signature 203 [step 8] 204 [step 7] outer SignedData block (eContent is missing) 205 [step 8] 206 [step 8] --outerboundary-- 208 % = These lines are what the inner signature is computed over. 209 | = These lines are what is encrypted in step 5. This encrypted result 210 is opaque and is a part of an EnvelopedData block. 211 ) = These lines are what the outer signature is computed over. 213 The format of a triple wrapped message that uses application/pkcs7-mime for 214 the both signatures is: 216 [step 8] Content-type: application/pkcs7-mime; 217 [step 8] smime-type=signed-data 218 [step 8] 219 [step 7] outer SignedData block (eContent is present) O 220 [step 6] Content-type: application/pkcs7-mime; ) O 221 [step 6] smime-type=enveloped-data; ) O 222 [step 6] ) O 223 [step 4] Content-type: application/pkcs7-mime; | ) O 224 [step 4] smime-type=signed-data | ) O 225 [step 4] | ) O 226 [step 3] inner SignedData block (eContent is present) I | ) O 227 [step 2] Content-type: text/plain I | ) O 228 [step 2] I | ) O 229 [step 1] Original content I | ) O 231 I = These lines are the inner SignedData block, which is opaque and 232 contains the ASN.1 encoded result of step 2 as well as control 233 information. 234 | = These lines are what is encrypted in step 5. This encrypted result 235 is opaque and is a part of an EnvelopedData block. 236 ) = These lines are what the outer signature is computed over. 237 O = These lines are the outer SignedData block, which is opaque and 238 contains the ASN.1 encoded result of step 6 as well as control 239 information. 241 1.3 Security Services and Triple Wrapping 243 The first three security services described in this document are used 244 with triple wrapped messages in different ways. This section briefly 245 describes the relationship of each service with triple wrapping; the 246 other sections of the document go into greater detail. 248 1.3.1 Signed Receipts and Triple Wrapping 250 A signed receipt may be requested in any SignedData object. However, if 251 a signed receipt is requested for a triple wrapped message, the receipt 252 request MUST be in the inside signature, not in the outside signature. 253 A secure mailing list agent may change the receipt policy in the 254 outside signature of a triple wrapped message when that message is 255 processed by the mailing list. 257 Note: the signed receipts and receipt requests described in this draft 258 differ from those described in the work done by the IETF Receipt 259 Notification Working Group. The output of that Working Group, when 260 finished, is not expected to work well with triple wrapped messages as 261 described in this document. 263 1.3.2 Security Labels and Triple Wrapping 265 A security label may be included in the signed attributes of any 266 SignedData object. A security label attribute may be included in either 267 the inner signature, outer signature, or both. 269 The inner security label is used for access control decisions related 270 to the plaintext original content. The inner signature provides 271 authentication and cryptographically protects the integrity of the 272 original signer's security label that is in the inside body. This 273 strategy facilitates the forwarding of messages because the original 274 signer's security label is included in the SignedData block which can 275 be forwarded to a third party that can verify the inner signature which 276 will cover the inner security label. The confidentiality security 277 service can be applied to the inner security label by encrypting the 278 entire inner SignedData block within an EnvelopedData block. 280 A security label may also be included in the signed attributes of the 281 outer SignedData block which will include the sensitivities of the 282 encrypted message. The outer security label is used for access control 283 and routing decisions related to the encrypted message. Note that a 284 security label attribute can only be used in a signedAttributes block. 285 An eSSSecurityLabel attribute MUST NOT be used in an EnvelopedData or 286 unsigned attributes. 288 1.3.3 Secure Mailing Lists and Triple Wrapping 290 Secure mail list message processing depends on the structure of S/MIME 291 layers present in the message sent to the mail list agent. The mail 292 list agent never changes the data that was hashed to form the inner 293 signature, if such a signature is present. If an outer signature is 294 present, then the agent will modify the data that was hashed to form 295 that outer signature. In all cases, the agent adds or updates an 296 mlExpansionHistory attribute to document the agent's processing, and 297 ultimately adds or replaces the outer signature on the message to be 298 distributed. 300 1.3.4 Placement of Attributes 302 Certain attributes should be placed in the inner or outer SignedData 303 message; some attributes can be in either. Further, some attributes 304 must be signed, while signing is optional for others, and some 305 attributes must not be signed. ESS defines several types of attributes. 306 ContentHints and ContentIdentifier MAY appear in any list of 307 attributes. contentReference, equivalentLabel, eSSSecurityLabel and 308 mlExpansionHistory MUST be carried in a SignedAttributes or 309 AuthAttributes type, and MUST NOT be carried in a UnsignedAttributes, 310 UnauthAttributes or UnprotectedAttributes type. msgSigDigest, 311 receiptRequest and signingCertificate MUST be carried in a 312 SignedAttributes, and MUST NOT be carried in a AuthAttributes, 313 UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. 315 The following table summarizes the recommendation of this profile. In 316 the OID column, [ESS] indicates that the attribute is defined in this 317 document. 319 | |Inner or | 320 Attribute |OID |outer |Signed 321 ------------------|----------------------------- |----------|-------- 322 contentHints |id-aa-contentHint [ESS] |either |MAY 323 contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY 324 contentReference |id-aa-contentReference [ESS] |either |MUST 325 contentType |id-contentType [CMS] |either |MUST 326 counterSignature |id-countersignature [CMS] |either |MUST NOT 327 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST 328 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST 329 messageDigest |id-messageDigest [CMS] |either |MUST 330 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST 331 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST 332 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST 333 signingCertificate|id-aa-signingCertificate [ESS]|either |MUST 334 signingTime |id-signingTime [CMS] |either |MUST 335 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST 336 sMIMEEncryption- 337 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST 339 CMS defines signedAttrs as a SET OF Attribute and defines unsignedAttrs 340 as a SET OF Attribute. ESS defines the contentHints, contentIdentifier, 341 eSSecurityLabel, msgSigDigest, mlExpansionHistory, receiptRequest, 342 contentReference, equivalentLabels and signingCertificate attribute 343 types. A signerInfo MUST NOT include multiple instances of any of the 344 attribute types defined in ESS. Later sections of ESS specify further 345 restrictions that apply to the receiptRequest, mlExpansionHistory and 346 eSSecurityLabel attribute types. 348 CMS defines the syntax for the signed and unsigned attributes as 349 "attrValues SET OF AttributeValue". For all of the attribute types 350 defined in ESS, if the attribute type is present in a signerInfo, then 351 it MUST only include a single instance of AttributeValue. In other 352 words, there MUST NOT be zero, or multiple, instances of AttributeValue 353 present in the attrValues SET OF AttributeValue. 355 If a counterSignature attribute is present, then it MUST be included in 356 the unsigned attributes. It MUST NOT be included in the signed 357 attributes. The only attributes that are allowed in a counterSignature 358 attribute are counterSignature, messageDigest, signingTime, and 359 signingCertificate. 361 Note that the inner and outer signatures are usually those of different 362 senders. Because of this, the same attribute in the two signatures 363 could lead to very different consequences. 365 ContentIdentifier is an attribute (OCTET STRING) used to carry a unique 366 identifier assigned to the message. 368 1.4 Required and Optional Attributes 370 Some security gateways sign messages that pass through them. If the 371 message is any type other than a signedData type, the gateway has only 372 one way to sign the message: by wrapping it with a signedData block and 373 MIME headers. If the message to be signed by the gateway is a 374 signedData message already, the gateway can sign the message by 375 inserting a signerInfo into the signedData block. 377 The main advantage of a gateway adding a signerInfo instead of wrapping 378 the message in a new signature is that the message doesn't grow as much 379 as if the gateway wrapped the message. The main disadvantage is that 380 the gateway must check for the presence of certain attributes in the 381 other signerInfos and either omit or copy those attributes. 383 If a gateway or other processor adds a signerInfo to an existing 384 signedData block, it MUST copy the mlExpansionHistory and 385 eSSSecurityLabel attributes from other signerInfos. This helps ensure 386 that the recipient will process those attributes in a signerInfo that 387 it can verify. 389 Note that someone may in the future define an attribute that must be 390 present in each signerInfo of a signedData block in order for the 391 signature to be processed. If that happens, a gateway that inserts 392 signerInfos and doesn't copy that attribute will cause every message 393 with that attribute to fail when processed by the recipient. For this 394 reason, it is safer to wrap messages with new signatures than to insert 395 signerInfos. 397 1.5 Object Identifiers 399 The object identifiers for many of the objects described in this draft 400 are found in [CMS], [MSG], and [CERT]. Other object identifiers used in 401 S/MIME can be found in the registry kept at 402 . When this draft moves to 403 standards track within the IETF, it is intended that the IANA will 404 maintain this registry. 406 2. Signed Receipts 408 Returning a signed receipt provides to the originator proof of delivery 409 of a message, and allows the originator to demonstrate to a third party 410 that the recipient was able to verify the signature of the original 411 message. This receipt is bound to the original message through the 412 signature; consequently, this service may be requested only if a 413 message is signed. The receipt sender may optionally also encrypt a 414 receipt to provide confidentiality between the receipt sender and the 415 receipt recipient. 417 2.1 Signed Receipt Concepts 419 The originator of a message may request a signed receipt from the 420 message's recipients. The request is indicated by adding a 421 receiptRequest attribute to the signedAttributes field of the 422 SignerInfo object for which the receipt is requested. The receiving 423 user agent software SHOULD automatically create a signed receipt when 424 requested to do so, and return the receipt in accordance with mailing 425 list expansion options, local security policies, and configuration 426 options. 428 Because receipts involve the interaction of two parties, the 429 terminology can sometimes be confusing. In this section, the "sender" 430 is the agent that sent the original message that included a request for 431 a receipt. The "receiver" is the party that received that message and 432 generated the receipt. 434 The steps in a typical transaction are: 436 1. Sender creates a signed message including a receipt request 437 attribute (Section 2.2). 439 2. Sender transmits the resulting message to the recipient or 440 recipients. 442 3. Recipient receives message and determines if there is a valid 443 signature and receipt request in the message (Section 2.3). 445 4. Recipient creates a signed receipt (Section 2.4). 447 5. Recipient transmits the resulting signed receipt message to the 448 sender (Section 2.5). 450 6. Sender receives the message and validates that it contains a signed 451 receipt for the original message (Section 2.6). This validation relies 452 on the sender having retained either a copy of the original message or 453 information extracted from the original message. 455 The ASN.1 syntax for the receipt request is given in Section 2.7; the 456 ASN.1 syntax for the receipt is given in Section 2.8. 458 Note that a sending agent SHOULD remember when it has sent a receipt so 459 that it can avoid re-sending a receipt each time it processes the 460 message. 462 A receipt request can indicate that receipts be sent to many places, 463 not just to the sender (in fact, the receipt request might indicate 464 that the receipts should not even go to the sender). In order to verify 465 a receipt, the recipient of the receipt must be the originator or a 466 recipient of the original message. Thus, the sender SHOULD NOT request 467 that receipts be sent to anyone who does not have an exact copy of the 468 message. 470 2.2 Receipt Request Creation 472 Multi-layer S/MIME messages may contain multiple SignedData layers. 473 However, receipts may be requested only for the innermost SignedData 474 layer in a multi-layer S/MIME message, such as a triple wrapped 475 message. Only one receiptRequest attribute can be included in the 476 signedAttributes of a SignerInfo. 478 A ReceiptRequest attribute MUST NOT be included in the attributes of a 479 SignerInfo in a SignedData object that encapsulates a Receipt content. 480 In other words, the receiving agent MUST NOT request a signed receipt 481 for a signed receipt. 483 A sender requests receipts by placing a receiptRequest attribute in the 484 signed attributes of a signerInfo as follows: 486 1. A receiptRequest data structure is created. 488 2. A signed content identifier for the message is created and assigned 489 to the signedContentIdentifier field. The signedContentIdentifier is 490 used to associate the signed receipt with the message requesting the 491 signed receipt. 493 3. The entities requested to return a signed receipt are noted in the 494 receiptsFrom field. 496 4. The message originator MUST populate the receiptsTo field with a 497 GeneralNames for each entity to whom the recipient should send the 498 signed receipt. If the message originator wants the recipient to send 499 the signed receipt to the originator, then the originator MUST include 500 a GeneralNames for itself in the receiptsTo field. GeneralNames is a 501 SEQUENCE OF GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in 502 which each GeneralNames represents an entity. There may be multiple 503 GeneralName instances in each GeneralNames. At a minimum, the message 504 originator MUST populate each entity's GeneralNames with the address to 505 which the signed receipt should be sent. Optionally, the message 506 originator MAY also populate each entity's GeneralNames with other 507 GeneralName instances (such as directoryName). 509 5. The completed receiptRequest attribute is placed in the 510 signedAttributes field of the SignerInfo object. 512 2.2.1 Multiple Receipt Requests 514 There can be multiple SignerInfos within a SignedData object, and each 515 SignerInfo may include signedAttributes. Therefore, a single SignedData 516 object may include multiple SignerInfos, each SignerInfo having a 517 receiptRequest attribute. For example, an originator can send a signed 518 message with two SignerInfos, one containing a DSS signature, the other 519 containing an RSA signature. 521 Each recipient SHOULD return only one signed receipt. 523 Not all of the SignerInfos need to include receipt requests, but in all 524 of the SignerInfos that do contain receipt requests, the receipt 525 requests MUST be identical. 527 2.2.2 Information Needed to Validate Signed Receipts 529 The sending agent MUST retain one or both of the following items to 530 support the validation of signed receipts returned by the recipients. 532 - the original signedData object requesting the signed receipt 534 - the message signature digest value used to generate the original 535 signedData signerInfo signature value and the digest value of the 536 Receipt content containing values included in the original 537 signedData object. If signed receipts are requested from multiple 538 recipients, then retaining these digest values is a performance 539 enhancement because the sending agent can reuse the saved values 540 when verifying each returned signed receipt. 542 2.3 Receipt Request Processing 544 A receiptRequest is associated only with the SignerInfo object to which 545 the receipt request attribute is directly attached. Receiving software 546 SHOULD examine the signedAttributes field of each of the SignerInfos 547 for which it verifies a signature in the innermost signedData object to 548 determine if a receipt is requested. This may result in the receiving 549 agent processing multiple receiptRequest attributes included in a 550 single SignedData object, such as requests made from different people 551 who signed the object in parallel. 553 Before processing a receiptRequest signedAttribute, the receiving agent 554 MUST verify the signature of the SignerInfo which covers the 555 receiptRequest attribute. A recipient MUST NOT process a receiptRequest 556 attribute that has not been verified. Because all receiptRequest 557 attributes in a SignedData object must be identical, the receiving 558 application fully processes (as described in the following paragraphs) 559 the first receiptRequest attribute that it encounters in a SignerInfo 560 that it verifies, and it then ensures that all other receiptRequest 561 attributes in signerInfos that it verifies are identical to the first 562 one encountered. If there are verified ReceiptRequest attributes which 563 are not the same, then the processing software MUST NOT return any 564 signed receipt. A signed receipt SHOULD be returned if any signerInfo 565 containing a receiptRequest attribute can be validated, even if other 566 signerInfos containing the same receiptRequest attribute cannot be 567 validated because they are signed using an algorithm not supported by 568 the receiving agent. 570 If a receiptRequest attribute is absent from the signed attributes, 571 then a signed receipt has not been requested from any of the message 572 recipients and MUST NOT be created. If a receiptRequest attribute is 573 present in the signed attributes, then a signed receipt has been 574 requested from some or all of the message recipients. Note that in some 575 cases, a receiving agent might receive two almost-identical messages, 576 one with a receipt request and the other without one. In this case, the 577 receiving agent SHOULD send a signed receipt for the message that 578 requests a signed receipt. 580 If a receiptRequest attribute is present in the signed attributes, the 581 following process SHOULD be used to determine if a message recipient 582 has been requested to return a signed receipt. 584 1. If an mlExpansionHistory attribute is present in the outermost 585 signedData block, do one of the following two steps, based on the 586 absence or presence of mlReceiptPolicy: 588 1.1. If an mlReceiptPolicy value is absent from the last MLData 589 element, a Mail List receipt policy has not been specified and the 590 processing software SHOULD examine the receiptRequest attribute 591 value to determine if a receipt should be created and returned. 593 1.2. If an mlReceiptPolicy value is present in the last MLData 594 element, do one of the following two steps, based on the value of 595 mlReceiptPolicy: 597 1.2.1. If the mlReceiptPolicy value is none, then the receipt 598 policy of the Mail List supersedes the originator's request for 599 a signed receipt and a signed receipt MUST NOT be created. 601 1.2.2. If the mlReceiptPolicy value is insteadOf or 602 inAdditionTo, the processing software SHOULD examine the 603 receiptsFrom value from the receiptRequest attribute to 604 determine if a receipt should be created and returned. If a 605 receipt is created, the insteadOf and inAdditionTo fields 606 identify entities that SHOULD be sent the receipt instead of or 607 in addition to the originator. 609 2. If the receiptsFrom value of the receiptRequest attribute is 610 allOrFirstTier, do one of the following two steps based on the value of 611 allOrFirstTier. 613 2.1. If the value of allOrFirstTier is allReceipts, then a signed 614 receipt SHOULD be created. 616 2.2. If the value of allOrFirstTier is firstTierRecipients, do one 617 of the following two steps based on the presence of an 618 mlExpansionHistory attribute in an outer signedData block: 620 2.2.1. If an mlExpansionHistory attribute is present, then this 621 recipient is not a first tier recipient and a signed receipt 622 MUST NOT be created. 624 2.2.2. If an mlExpansionHistory attribute is not present, then 625 a signed receipt SHOULD be created. 627 3. If the receiptsFrom value of the receiptRequest attribute is a 628 receiptList: 630 3.1. If receiptList contains one of the GeneralNames of the 631 recipient, then a signed receipt SHOULD be created. 633 3.2. If receiptList does not contain one of the GeneralNames of the 634 recipient, then a signed receipt MUST NOT be created. 636 A flow chart for the above steps to be executed for each signerInfo for 637 which the receiving agent verifies the signature would be: 639 0. Receipt Request attribute present? 640 YES -> 1. 641 NO -> STOP 642 1. Has mlExpansionHistory in outer signedData? 643 YES -> 1.1. 644 NO -> 2. 645 1.1. mlReceiptPolicy absent? 646 YES -> 2. 647 NO -> 1.2. 648 1.2. Pick based on value of mlReceiptPolicy. 649 none -> 1.2.1. 650 insteadOf or inAdditionTo -> 1.2.2. 651 1.2.1. STOP. 652 1.2.2. Examine receiptsFrom to determine if a receipt should be created, 653 create it if required, send it to recipients designated by 654 mlReceiptPolicy, then -> STOP. 655 2. Is value of receiptsFrom allOrFirstTier? 656 YES -> Pick based on value of allOrFirstTier. 657 allReceipts -> 2.1. 658 firstTierRecipients -> 2.2. 659 NO -> 3. 660 2.1. Create a receipt, then -> STOP. 661 2.2. Has mlExpansionHistory in the outer signedData block? 662 YES -> 2.2.1. 663 NO -> 2.2.2. 664 2.2.1. STOP. 665 2.2.2. Create a receipt, then -> STOP. 666 3. Is receiptsFrom value of receiptRequest a receiptList? 667 YES -> 3.1. 668 NO -> STOP. 669 3.1. Does receiptList contain the recipient? 670 YES -> Create a receipt, then -> STOP. 671 NO -> 3.2. 672 3.2. STOP. 674 2.4 Signed Receipt Creation 676 A signed receipt is a signedData object encapsulating a Receipt content 677 (also called a "signedData/Receipt"). Signed receipts are created as 678 follows: 680 1. The signature of the original signedData signerInfo that includes 681 the receiptRequest signed attribute MUST be successfully verified 682 before creating the signedData/Receipt. 684 1.1. The content of the original signedData object is digested as 685 described in [CMS]. The resulting digest value is then compared 686 with the value of the messageDigest attribute included in the 687 signedAttributes of the original signedData signerInfo. If these 688 digest values are different, then the signature verification 689 process fails and the signedData/Receipt MUST NOT be created. 691 1.2. The ASN.1 DER encoded signedAttributes (including 692 messageDigest, receiptRequest and, possibly, other signed 693 attributes) in the original signedData signerInfo are digested as 694 described in [CMS]. The resulting digest value, called 695 msgSigDigest, is then used to verify the signature of the original 696 signedData signerInfo. If the signature verification fails, then 697 the signedData/Receipt MUST NOT be created. 699 2. A Receipt structure is created. 701 2.1. The value of the Receipt version field is set to 1. 703 2.2. The object identifier from the contentType attribute included 704 in the original signedData signerInfo that includes the 705 receiptRequest attribute is copied into the Receipt contentType. 707 2.3. The original signedData signerInfo receiptRequest 708 signedContentIdentifier is copied into the Receipt 709 signedContentIdentifier. 711 2.4. The signature value from the original signedData signerInfo 712 that includes the receiptRequest attribute is copied into the 713 Receipt originatorSignatureValue. 715 3. The Receipt structure is ASN.1 DER encoded to produce a data stream, 716 D1. 718 4. D1 is digested. The resulting digest value is included as the 719 messageDigest attribute in the signedAttributes of the signerInfo which 720 will eventually contain the signedData/Receipt signature value. 722 5. The digest value (msgSigDigest) calculated in Step 1 to verify the 723 signature of the original signedData signerInfo is included as the 724 msgSigDigest attribute in the signedAttributes of the signerInfo which 725 will eventually contain the signedData/Receipt signature value. 727 6. A contentType attribute including the id-ct-receipt object 728 identifier MUST be created and added to the signed attributes of the 729 signerInfo which will eventually contain the signedData/Receipt 730 signature value. 732 7. A signingTime attribute indicating the time that the 733 signedData/Receipt is signed SHOULD be created and added to the signed 734 attributes of the signerInfo which will eventually contain the 735 signedData/Receipt signature value. Other attributes (except 736 receiptRequest) may be added to the signedAttributes of the signerInfo. 738 8. The signedAttributes (messageDigest, msgSigDigest, contentType and, 739 possibly, others) of the signerInfo are ASN.1 DER encoded and digested 740 as described in [CMS]. The resulting digest value is used to calculate 741 the signature value which is then included in the signedData/Receipt 742 signerInfo. 744 9. The ASN.1 DER encoded Receipt content MUST be directly encoded 745 within the signedData encapContentInfo eContent OCTET STRING defined in 746 [CMS]. The id-ct-receipt object identifier MUST be included in the 747 signedData encapContentInfo eContentType. This results in a single 748 ASN.1 encoded object composed of a signedData including the Receipt 749 content. The Data content type MUST NOT be used. The Receipt content 750 MUST NOT be encapsulated in a MIME header or any other header prior to 751 being encoded as part of the signedData object. 753 10. The signedData/Receipt is then put in an application/pkcs7-mime 754 MIME wrapper with the smime-type parameter set to "signed-receipt". 755 This will allow for identification of signed receipts without having to 756 crack the ASN.1 body. The smime-type parameter would still be set as 757 normal in any layer wrapped around this message. 759 11. If the signedData/Receipt is to be encrypted within an 760 envelopedData object, then an outer signedData object MUST be created 761 that encapsulates the envelopedData object, and a contentHints 762 attribute with contentType set to the id-ct-receipt object identifier 763 MUST be included in the outer signedData SignerInfo signedAttributes. 764 When a receiving agent processes the outer signedData object, the 765 presence of the id-ct-receipt OID in the contentHints contentType 766 indicates that a signedData/Receipt is encrypted within the 767 envelopedData object encapsulated by the outer signedData. 769 All sending agents that support the generation of ESS signed receipts 770 MUST provide the ability to send encrypted signed receipts (that is, a 771 signedData/Receipt encapsulated within an envelopedData). The sending 772 agent MAY send an encrypted signed receipt in response to an 773 envelopedData-encapsulated signedData requesting a signed receipt. It 774 is a matter of local policy regarding whether or not the signed receipt 775 should be encrypted. The ESS signed receipt includes the message 776 digest value calculated for the original signedData object that 777 requested the signed receipt. If the original signedData object was 778 sent encrypted within an envelopedData object and the ESS signed 779 receipt is sent unencrypted, then the message digest value calculated 780 for the original encrypted signedData object is sent unencrypted. The 781 responder should consider this when deciding whether or not to encrypt 782 the ESS signed receipt. 784 2.4.1 MLExpansionHistory Attributes and Receipts 786 An MLExpansionHistory attribute MUST NOT be included in the attributes 787 of a SignerInfo in a SignedData object that encapsulates a Receipt 788 content. This is true because when a SignedData/Receipt is sent to an 789 MLA for distribution, then the MLA must always encapsulate the received 790 SignedData/Receipt in an outer SignedData in which the MLA will include 791 the MLExpansionHistory attribute. The MLA cannot change the 792 signedAttributes of the received SignedData/Receipt object, so it can't 793 add the MLExpansionHistory to the SignedData/Receipt. 795 2.5 Determining the Recipients of the Signed Receipt 797 If a signed receipt was created by the process described in the 798 sections above, then the software MUST use the following process to 799 determine to whom the signed receipt should be sent. 801 1. The receiptsTo field must be present in the receiptRequest 802 attribute. The software initiates the sequence of recipients with the 803 value(s) of receiptsTo. 805 2. If the MlExpansionHistory attribute is present in the outer 806 SignedData block, and the last MLData contains an MLReceiptPolicy value 807 of insteadOf, then the software replaces the sequence of recipients 808 with the value(s) of insteadOf. 810 3. If the MlExpansionHistory attribute is present in the outer 811 SignedData block and the last MLData contains an MLReceiptPolicy value 812 of inAdditionTo, then the software adds the value(s) of inAdditionTo to 813 the sequence of recipients. 815 2.6. Signed Receipt Validation 817 A signed receipt is communicated as a single ASN.1 encoded object 818 composed of a signedData object directly including a Receipt content. 819 It is identified by the presence of the id-ct-receipt object identifier 820 in the encapContentInfo eContentType value of the signedData object 821 including the Receipt content. 823 Although recipients are not supposed to send more than one signed 824 receipt, receiving agents SHOULD be able to accept multiple signed 825 receipts from a recipient. 827 A signedData/Receipt is validated as follows: 829 1. ASN.1 decode the signedData object including the Receipt content. 831 2. Extract the contentType, signedContentIdentifier, and 832 originatorSignatureValue from the decoded Receipt structure to identify 833 the original signedData signerInfo that requested the 834 signedData/Receipt. 836 3. Acquire the message signature digest value calculated by the sender 837 to generate the signature value included in the original signedData 838 signerInfo that requested the signedData/Receipt. 840 3.1. If the sender-calculated message signature digest value has 841 been saved locally by the sender, it must be located and retrieved. 843 3.2. If it has not been saved, then it must be re-calculated based 844 on the original signedData content and signedAttributes as 845 described in [CMS]. 847 4. The message signature digest value calculated by the sender is then 848 compared with the value of the msgSigDigest signedAttribute included in 849 the signedData/Receipt signerInfo. If these digest values are 850 identical, then that proves that the message signature digest value 851 calculated by the recipient based on the received original signedData 852 object is the same as that calculated by the sender. This proves that 853 the recipient received exactly the same original signedData content and 854 signedAttributes as sent by the sender because that is the only way 855 that the recipient could have calculated the same message signature 856 digest value as calculated by the sender. If the digest values are 857 different, then the signedData/Receipt signature verification process 858 fails. 860 5. Acquire the digest value calculated by the sender for the Receipt 861 content constructed by the sender (including the contentType, 862 signedContentIdentifier, and signature value that were included in the 863 original signedData signerInfo that requested the signedData/Receipt). 865 5.1. If the sender-calculated Receipt content digest value has been 866 saved locally by the sender, it must be located and retrieved. 868 5.2. If it has not been saved, then it must be re-calculated. As 869 described in section 2.4 above, step 2, create a Receipt structure 870 including the contentType, signedContentIdentifier and signature 871 value that were included in the original signedData signerInfo that 872 requested the signed receipt. The Receipt structure is then ASN.1 873 DER encoded to produce a data stream which is then digested to 874 produce the Receipt content digest value. 876 6. The Receipt content digest value calculated by the sender is then 877 compared with the value of the messageDigest signedAttribute included 878 in the signedData/Receipt signerInfo. If these digest values are 879 identical, then that proves that the values included in the Receipt 880 content by the recipient are identical to those that were included in 881 the original signedData signerInfo that requested the 882 signedData/Receipt. This proves that the recipient received the 883 original signedData signed by the sender, because that is the only way 884 that the recipient could have obtained the original signedData 885 signerInfo signature value for inclusion in the Receipt content. If the 886 digest values are different, then the signedData/Receipt signature 887 verification process fails. 889 7. The ASN.1 DER encoded signedAttributes of the signedData/Receipt 890 signerInfo are digested as described in [CMS]. 892 8. The resulting digest value is then used to verify the signature 893 value included in the signedData/Receipt signerInfo. If the signature 894 verification is successful, then that proves the integrity of the 895 signedData/receipt signerInfo signedAttributes and authenticates the 896 identity of the signer of the signedData/Receipt signerInfo. Note that 897 the signedAttributes include the recipient-calculated Receipt content 898 digest value (messageDigest attribute) and recipient-calculated message 899 signature digest value (msgSigDigest attribute). Therefore, the 900 aforementioned comparison of the sender-generated and 901 recipient-generated digest values combined with the successful 902 signedData/Receipt signature verification proves that the recipient 903 received the exact original signedData content and signedAttributes 904 (proven by msgSigDigest attribute) that were signed by the sender of 905 the original signedData object (proven by messageDigest attribute). If 906 the signature verification fails, then the signedData/Receipt signature 907 verification process fails. 909 The signature verification process for each signature algorithm that is 910 used in conjunction with the CMS protocol is specific to the algorithm. 911 These processes are described in documents specific to the algorithms. 913 2.7 Receipt Request Syntax 915 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use the 916 receiptRequest attribute only within the signed attributes associated 917 with a signed message. 919 ReceiptRequest ::= SEQUENCE { 920 signedContentIdentifier ContentIdentifier, 921 receiptsFrom ReceiptsFrom, 922 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } 924 ub-receiptsTo INTEGER ::= 16 926 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 927 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 929 ContentIdentifier ::= OCTET STRING 931 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 932 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 934 A signedContentIdentifier MUST be created by the message originator 935 when creating a receipt request. To ensure global uniqueness, the 936 minimal signedContentIdentifier SHOULD contain a concatenation of 937 user-specific identification information (such as a user name or public 938 keying material identification information), a GeneralizedTime string, 939 and a random number. 941 The receiptsFrom field is used by the originator to specify the 942 recipients requested to return a signed receipt. A CHOICE is provided 943 to allow specification of: 944 - receipts from all recipients are requested 945 - receipts from first tier (recipients that did not receive the 946 message as members of a mailing list) recipients are requested 947 - receipts from a specific list of recipients are requested 949 ReceiptsFrom ::= CHOICE { 950 allOrFirstTier [0] AllOrFirstTier, 951 -- formerly "allOrNone [0]AllOrNone" 952 receiptList [1] SEQUENCE OF GeneralNames } 954 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 955 allReceipts (0), 956 firstTierRecipients (1) } 958 The receiptsTo field is used by the originator to identify the user(s) 959 to whom the identified recipient should send signed receipts. The 960 message originator MUST populate the receiptsTo field with a 961 GeneralNames for each entity to whom the recipient should send the 962 signed receipt. If the message originator wants the recipient to send 963 the signed receipt to the originator, then the originator MUST include 964 a GeneralNames for itself in the receiptsTo field. 966 2.8 Receipt Syntax 968 Receipts are represented using a new content type, Receipt. The Receipt 969 content type shall have ASN.1 type Receipt. Receipts must be 970 encapsulated within a SignedData message. 972 Receipt ::= SEQUENCE { 973 version ESSVersion, 974 contentType ContentType, 975 signedContentIdentifier ContentIdentifier, 976 originatorSignatureValue OCTET STRING } 978 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 979 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 981 ESSVersion ::= INTEGER { v1(1) } 983 The version field defines the syntax version number, which is 1 for 984 this version of the standard. 986 2.9 Content Hints 988 Many applications find it useful to have information that describes the 989 innermost signed content of a multi-layer message available on the 990 outermost signature layer. The contentHints attribute provides such 991 information. 993 Content-hints attribute values have ASN.1 type contentHints. 995 ContentHints ::= SEQUENCE { 996 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 997 contentType ContentType } 999 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1000 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 1002 The contentDescription field may be used to provide information that 1003 the recipient may use to select protected messages for processing, such 1004 as a message subject. If this field is set, then the attribute is 1005 expected to appear on the signedData object enclosing an envelopedData 1006 object and not on the inner signedData object. The (SIZE (1..MAX)) 1007 construct constrains the sequence to have at least one entry. MAX 1008 indicates the upper bound is unspecified. Implementations are free to 1009 choose an upper bound that suits their environment. 1011 Messages which contain a signedData object wrapped around an 1012 envelopedData object, thus masking the inner content type of the 1013 message, SHOULD include a contentHints attribute, except for the case 1014 of the data content type. Specific message content types may either 1015 force or preclude the inclusion of the contentHints attribute. For 1016 example, when a signedData/Receipt is encrypted within an envelopedData 1017 object, an outer signedData object MUST be created that encapsulates 1018 the envelopedData object and a contentHints attribute with contentType 1019 set to the id-ct-receipt object identifier MUST be included in the 1020 outer signedData SignerInfo signedAttributes. 1022 2.10 Message Signature Digest Attribute 1024 The msgSigDigest attribute can only be used in the signed attributes of 1025 a signed receipt. It contains the digest of the ASN.1 DER encoded 1026 signedAttributes included in the original signedData that requested the 1027 signed receipt. Only one msgSigDigest attribute can appear in a signed 1028 attributes set. It is defined as follows: 1030 msgSigDigest ::= OCTET STRING 1032 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1033 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 1035 2.11 Signed Content Reference Attribute 1037 The contentReference attribute is a link from one SignedData to 1038 another. It may be used to link a reply to the original message to 1039 which it refers, or to incorporate by reference one SignedData into 1040 another. The first SignedData MUST include a contentIdentifier signed 1041 attribute, which SHOULD be constructed as specified in section 2.7. The 1042 second SignedData links to the first by including a ContentReference 1043 signed attribute containing the content type, content identifier, and 1044 signature value from the first SignedData. 1046 ContentReference ::= SEQUENCE { 1047 contentType ContentType, 1048 signedContentIdentifier ContentIdentifier, 1049 originatorSignatureValue OCTET STRING } 1051 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1052 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 1054 3. Security Labels 1056 This section describes the syntax to be used for security labels that 1057 can optionally be associated with S/MIME encapsulated data. A security 1058 label is a set of security information regarding the sensitivity of the 1059 content that is protected by S/MIME encapsulation. 1061 "Authorization" is the act of granting rights and/or privileges to 1062 users permitting them access to an object. "Access control" is a means 1063 of enforcing these authorizations. The sensitivity information in a 1064 security label can be compared with a user's authorizations to 1065 determine if the user is allowed to access the content that is 1066 protected by S/MIME encapsulation. 1068 Security labels may be used for other purposes such as a source of 1069 routing information. The labels often describe ranked levels ("secret", 1070 "confidential", "restricted", and so on) or are role-based, describing 1071 which kind of people can see the information ("patient's health-care 1072 team", "medical billing agents", "unrestricted", and so on). 1074 3.1 Security Label Processing Rules 1076 A sending agent may include a security label attribute in the signed 1077 attributes of a signedData object. A receiving agent examines the 1078 security label on a received message and determines whether or not the 1079 recipient is allowed to see the contents of the message. 1081 3.1.1 Adding Security Labels 1083 A sending agent that is using security labels MUST put the security 1084 label attribute in the signedAttributes field of a SignerInfo block. 1085 The security label attribute MUST NOT be included in the unsigned 1086 attributes. Integrity and authentication security services MUST be 1087 applied to the security label, therefore it MUST be included as a 1088 signed attribute, if used. This causes the security label attribute to 1089 be part of the data that is hashed to form the SignerInfo signature 1090 value. A SignerInfo block MUST NOT have more than one security label 1091 signed attribute. 1093 When there are multiple SignedData blocks applied to a message, a 1094 security label attribute may be included in either the inner signature, 1095 outer signature, or both. A security label signed attribute may be 1096 included in a signedAttributes field within the inner SignedData block. 1097 The inner security label will include the sensitivities of the original 1098 content and will be used for access control decisions related to the 1099 plaintext encapsulated content. The inner signature provides 1100 authentication of the inner security label and cryptographically 1101 protects the original signer's inner security label of the original 1102 content. 1104 When the originator signs the plaintext content and signed attributes, 1105 the inner security label is bound to the plaintext content. An 1106 intermediate entity cannot change the inner security label without 1107 invalidating the inner signature. The confidentiality security service 1108 can be applied to the inner security label by encrypting the entire 1109 inner signedData object within an EnvelopedData block. 1111 A security label signed attribute may also be included in a 1112 signedAttributes field within the outer SignedData block. The outer 1113 security label will include the sensitivities of the encrypted message 1114 and will be used for access control decisions related to the encrypted 1115 message and for routing decisions. The outer signature provides 1116 authentication of the outer security label (as well as for the 1117 encapsulated content which may include nested S/MIME messages). 1119 There can be multiple SignerInfos within a SignedData object, and each 1120 SignerInfo may include signedAttributes. Therefore, a single SignedData 1121 object may include multiple eSSSecurityLabels, each SignerInfo having 1122 an eSSSecurityLabel attribute. For example, an originator can send a 1123 signed message with two SignerInfos, one containing a DSS signature, 1124 the other containing an RSA signature. If any of the SignerInfos 1125 included in a SignedData object include an eSSSecurityLabel attribute, 1126 then all of the SignerInfos in that SignedData object MUST include an 1127 eSSSecurityLabel attribute and the value of each MUST be identical. 1129 3.1.2 Processing Security Labels 1131 Before processing an eSSSecurityLabel signedAttribute, the receiving 1132 agent MUST verify the signature of the SignerInfo which covers the 1133 eSSSecurityLabel attribute. A recipient MUST NOT process an 1134 eSSSecurityLabel attribute that has not been verified. 1136 A receiving agent MUST process the eSSSecurityLabel attribute, if 1137 present, in each SignerInfo in the SignedData object for which it 1138 verifies the signature. This may result in the receiving agent 1139 processing multiple eSSSecurityLabels included in a single SignedData 1140 object. Because all eSSSecurityLabels in a SignedData object must be 1141 identical, the receiving agent processes (such as performing access 1142 control) on the first eSSSecurityLabel that it encounters in a 1143 SignerInfo that it verifies, and then ensures that all other 1144 eSSSecurityLabels in signerInfos that it verifies are identical to the 1145 first one encountered. If the eSSSecurityLabels in the signerInfos that 1146 it verifies are not all identical, then the receiving agent MUST warn 1147 the user of this condition. 1149 Receiving agents SHOULD have a local policy regarding whether or not to 1150 show the inner content of a signedData object that includes an 1151 eSSSecurityLabel security-policy-identifier that the processing 1152 software does not recognize. If the receiving agent does not recognize 1153 the eSSSecurityLabel security-policy-identifier value, then it SHOULD 1154 stop processing the message and indicate an error. 1156 3.2 Syntax of eSSSecurityLabel 1158 The eSSSecurityLabel syntax is derived directly from [MTSABS] ASN.1 1159 module. (The MTSAbstractService module begins with "DEFINITIONS 1160 IMPLICIT TAGS ::=".) Further, the eSSSecurityLabel syntax is compatible 1161 with that used in [MSP4]. 1163 ESSSecurityLabel ::= SET { 1164 security-policy-identifier SecurityPolicyIdentifier, 1165 security-classification SecurityClassification OPTIONAL, 1166 privacy-mark ESSPrivacyMark OPTIONAL, 1167 security-categories SecurityCategories OPTIONAL } 1169 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1170 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 1172 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 1174 SecurityClassification ::= INTEGER { 1175 unmarked (0), 1176 unclassified (1), 1177 restricted (2), 1178 confidential (3), 1179 secret (4), 1180 top-secret (5) } (0..ub-integer-options) 1182 ub-integer-options INTEGER ::= 256 1184 ESSPrivacyMark ::= CHOICE { 1185 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 1186 utf8String UTF8String (SIZE (1..MAX)) 1187 } 1189 ub-privacy-mark-length INTEGER ::= 128 1191 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1192 SecurityCategory 1194 ub-security-categories INTEGER ::= 64 1196 SecurityCategory ::= SEQUENCE { 1197 type [0] OBJECT IDENTIFIER, 1198 value [1] ANY DEFINED BY type -- defined by type 1199 } 1201 --Note: The aforementioned SecurityCategory syntax produces identical 1202 --hex encodings as the following SecurityCategory syntax that is 1203 --documented in the X.411 specification: 1204 -- 1205 --SecurityCategory ::= SEQUENCE { 1206 -- type [0] SECURITY-CATEGORY, 1207 -- value [1] ANY DEFINED BY type } 1208 -- 1209 --SECURITY-CATEGORY MACRO ::= 1210 --BEGIN 1211 --TYPE NOTATION ::= type | empty 1212 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1213 --END 1215 3.3 Security Label Components 1217 This section gives more detail on the the various components of the 1218 eSSSecurityLabel syntax. 1220 3.3.1 Security Policy Identifier 1222 A security policy is a set of criteria for the provision of security 1223 services. The eSSSecurityLabel security-policy-identifier is used to 1224 identify the security policy in force to which the security label 1225 relates. It indicates the semantics of the other security label 1226 components. 1228 3.3.2 Security Classification 1230 This specification defines the use of the Security Classification field 1231 exactly as is specified in the X.411 Recommendation, which states in 1232 part: 1234 If present, a security-classification may have one of a 1235 hierarchical list of values. The basic security-classification 1236 hierarchy is defined in this Recommendation, but the use of these 1237 values is defined by the security-policy in force. Additional 1238 values of security-classification, and their position in the 1239 hierarchy, may also be defined by a security-policy as a local 1240 matter or by bilateral agreement. The basic security-classification 1241 hierarchy is, in ascending order: unmarked, unclassified, 1242 restricted, confidential, secret, top-secret. 1244 This means that the security policy in force (identified by the 1245 eSSSecurityLabel security-policy-identifier) defines the 1246 SecurityClassification integer values and their meanings. 1248 An organization can develop its own security policy that defines the 1249 SecurityClassification INTEGER values and their meanings. However, the 1250 general interpretation of the X.411 specification is that the values of 1251 0 through 5 are reserved for the "basic hierarchy" values of unmarked, 1252 unclassified, restricted, confidential, secret, and top-secret. Note 1253 that X.411 does not provide the rules for how these values are used to 1254 label data and how access control is performed using these values. 1256 There is no universal definition of the rules for using these "basic 1257 hierarchy" values. Each organization (or group of organizations) will 1258 define a security policy which documents how the "basic hierarchy" 1259 values are used (if at all) and how access control is enforced (if at 1260 all) within their domain. 1262 Therefore, the security-classification value MUST be accompanied by a 1263 security-policy-identifier value to define the rules for its use. For 1264 example, a company's "secret" classification may convey a different 1265 meaning than the US Government "secret" classification. In summary, a 1266 security policy SHOULD NOT use integers 0 through 5 for other than 1267 their X.411 meanings, and SHOULD instead use other values in a 1268 hierarchical fashion. 1270 Note that the set of valid security-classification values MUST be 1271 hierarchical, but these values do not necessarily need to be in 1272 ascending numerical order. Further, the values do not need to be 1273 contiguous. 1275 For example, in the Defense Message System 1.0 security policy, the 1276 security-classification value of 11 indicates 1277 Sensitive-But-Unclassified and 5 indicates top-secret. The hierarchy of 1278 sensitivity ranks top-secret as more sensitive than 1279 Sensitive-But-Unclassified even though the numerical value of 1280 top-secret is less than Sensitive-But-Unclassified. 1282 (Of course, if security-classification values are both hierarchical and 1283 in ascending order, a casual reader of the security policy is more 1284 likely to understand it.) 1286 An example of a security policy that does not use any of the X.411 1287 values might be: 1288 10 -- anyone 1289 15 -- Morgan Corporation and its contractors 1290 20 -- Morgan Corporation employees 1291 25 -- Morgan Corporation board of directors 1293 An example of a security policy that uses part of the X.411 hierarchy 1294 might be: 1295 0 -- unmarked 1296 1 -- unclassified, can be read by everyone 1297 2 -- restricted to Timberwolf Productions staff 1298 6 -- can only be read to Timberwolf Productions executives 1300 3.3.3 Privacy Mark 1302 If present, the eSSSecurityLabel privacy-mark is not used for access 1303 control. The content of the eSSSecurityLabel privacy-mark may be 1304 defined by the security policy in force (identified by the 1305 eSSSecurityLabel security-policy-identifier) which may define a list of 1306 values to be used. Alternately, the value may be determined by the 1307 originator of the security-label. 1309 3.3.4 Security Categories 1311 If present, the eSSSecurityLabel security-categories provide further 1312 granularity for the sensitivity of the message. The security policy in 1313 force (identified by the eSSSecurityLabel security-policy-identifier) 1314 is used to indicate the syntaxes that are allowed to be present in the 1315 eSSSecurityLabel security-categories. Alternately, the 1316 security-categories and their values may be defined by bilateral 1317 agreement. 1319 3.4 Equivalent Security Labels 1321 Because organizations are allowed to define their own security 1322 policies, many different security policies will exist. Some 1323 organizations may wish to create equivalencies between their security 1324 policies with the security policies of other organizations. For 1325 example, the Acme Company and the Widget Corporation may reach a 1326 bilateral agreement that the "Acme private" security-classification 1327 value is equivalent to the "Widget sensitive" security-classification 1328 value. 1330 Receiving agents MUST NOT process an equivalentLabels attribute in a 1331 message if the agent does not trust the signer of that attribute to 1332 translate the original eSSSecurityLabel values to the security policy 1333 included in the equivalentLabels attribute. Receiving agents have the 1334 option to process equivalentLabels attributes but do not have to. It is 1335 acceptable for a receiving agent to only process eSSSecurityLabels. All 1336 receiving agents SHOULD recognize equivalentLabels attributes even if 1337 they do not process them. 1339 3.4.1 Creating Equivalent Labels 1341 The EquivalentLabels signed attribute is defined as: 1343 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 1345 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1346 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 1348 As stated earlier, the ESSSecurityLabel contains the sensitivity values 1349 selected by the original signer of the signedData. If an 1350 ESSSecurityLabel is present in a signerInfo, all signerInfos in the 1351 signedData MUST contain an ESSSecurityLabel and they MUST all be 1352 identical. In addition to an ESSSecurityLabel, a signerInfo MAY also 1353 include an equivalentLabels signed attribute. If present, the 1354 equivalentLabels attribute MUST include one or more security labels 1355 that are believed by the signer to be semantically equivalent to the 1356 ESSSecurityLabel attribute included in the same signerInfo. 1358 All security-policy object identifiers MUST be unique in the set of 1359 ESSSecurityLabel and EquivalentLabels security labels. Before using an 1360 EquivalentLabels attribute, a receiving agent MUST ensure that all 1361 security-policy OIDs are unique in the security label or labels 1362 included in the EquivalentLabels. Once the receiving agent selects the 1363 security label (within the EquivalentLabels) to be used for processing, 1364 then the security-policy OID of the selected EquivalentLabels security 1365 label MUST be compared with the ESSSecurityLabel security-policy OID to 1366 ensure that they are unique. 1368 In the case that an ESSSecurityLabel attribute is not included in a 1369 signerInfo, then an EquivalentLabels attribute may still be included. 1370 For example, in the Acme security policy, the absence of an 1371 ESSSecurityLabel could be defined to equate to a security label 1372 composed of the Acme security-policy OID and the "unmarked" 1373 security-classification. 1375 Note that equivalentLabels MUST NOT be used to convey security labels 1376 that are semantically different from the ESSSecurityLabel included in 1377 the signerInfos in the signedData. If an entity needs to apply a 1378 security label that is semantically different from the 1379 ESSSecurityLabel, then it MUST include the sematically different 1380 security label in an outer signedData object that encapsulates the 1381 signedData object that includes the ESSSecurityLabel. 1383 If present, the equivalentLabels attribute MUST be a signed attribute; 1384 it MUST NOT be an unsigned attribute. [CMS] defines signedAttributes as 1385 a SET OF Attribute. A signerInfo MUST NOT include multiple instances of 1386 the equivalentLabels attribute. CMS defines the ASN.1 syntax for the 1387 signed attributes to include attrValues SET OF AttributeValue. A 1388 equivalentLabels attribute MUST only include a single instance of 1389 AttributeValue. There MUST NOT be zero or multiple instances of 1390 AttributeValue present in the attrValues SET OF AttributeValue. 1392 3.4.2 Processing Equivalent Labels 1394 A receiving agent SHOULD process the ESSSecurityLabel before processing 1395 any EquivalentLabels. If the policy in the ESSSecurityLabel is 1396 understood by the receiving agent, it MUST process that label and MUST 1397 ignore all EquivalentLabels. 1399 When processing an EquivalentLabels attribute, the receiving agent MUST 1400 validate the signature on the EquivalentLabels attribute. A receiving 1401 agent MUST NOT act on an equivalentLabels attribute for which the 1402 signature could not be validated, and MUST NOT act on an 1403 equivalentLabels attribute unless that attribute is signed by an entity 1404 trusted to translate the original eSSSecurityLabel values to the 1405 security policy included in the equivalentLabels attribute. Determining 1406 who is allowed to specify equivalence mappings is a local policy. If a 1407 message has more than one EquivalentLabels attribute, the receiving 1408 agent SHOULD process the first one that it reads and validates that 1409 contains the security policy of interest to the receiving agent. 1411 4. Mail List Management 1413 Sending agents must create recipient-specific data structures for each 1414 recipient of an encrypted message. This process can impair performance 1415 for messages sent to a large number of recipients. Thus, Mail List 1416 Agents (MLAs) that can take a single message and perform the 1417 recipient-specific encryption for every recipient are often desired. 1419 An MLA appears to the message originator as a normal message recipient, 1420 but the MLA acts as a message expansion point for a Mail List (ML). The 1421 sender of a message directs the message to the MLA, which then 1422 redistributes the message to the members of the ML. This process 1423 offloads the per-recipient processing from individual user agents and 1424 allows for more efficient management of large MLs. MLs are true message 1425 recipients served by MLAs that provide cryptographic and expansion 1426 services for the mailing list. 1428 In addition to cryptographic handling of messages, secure mailing lists 1429 also have to prevent mail loops. A mail loop is where one mailing list 1430 is a member of a second mailing list, and the second mailing list is a 1431 member of the first. A message will go from one list to the other in a 1432 rapidly-cascading succession of mail that will be distributed to all 1433 other members of both lists. 1435 To prevent mail loops, MLAs use the mlExpansionHistory attribute of the 1436 outer signature of a triple wrapped message. The mlExpansionHistory 1437 attribute is essentially a list of every MLA that has processed the 1438 message. If an MLA sees its own unique entity identifier in the list, 1439 it knows that a loop has been formed, and does not send the message to 1440 the list again. 1442 4.1 Mail List Expansion 1444 Mail list expansion processing is noted in the value of the 1445 mlExpansionHistory attribute, located in the signed attributes of the 1446 MLA's SignerInfo block. The MLA creates or updates the signed 1447 mlExpansionHistory attribute value each time the MLA expands and signs 1448 a message for members of a mail list. 1450 The MLA MUST add an MLData record containing the MLA's identification 1451 information, date and time of expansion, and optional receipt policy to 1452 the end of the mail list expansion history sequence. If the 1453 mlExpansionHistory attribute is absent, then the MLA MUST add the 1454 attribute and the current expansion becomes the first element of the 1455 sequence. If the mlExpansionHistory attribute is present, then the MLA 1456 MUST add the current expansion information to the end of the existing 1457 MLExpansionHistory sequence. Only one mlExpansionHistory attribute can 1458 be included in the signedAttributes of a SignerInfo. 1460 Note that if the mlExpansionHistory attribute is absent, then the 1461 recipient is a first tier message recipient. 1463 There can be multiple SignerInfos within a SignedData object, and each 1464 SignerInfo may include signedAttributes. Therefore, a single SignedData 1465 object may include multiple SignerInfos, each SignerInfo having a 1466 mlExpansionHistory attribute. For example, an MLA can send a signed 1467 message with two SignerInfos, one containing a DSS signature, the other 1468 containing an RSA signature. 1470 If an MLA creates a SignerInfo that includes an mlExpansionHistory 1471 attribute, then all of the SignerInfos created by the MLA for that 1472 SignedData object MUST include an mlExpansionHistory attribute, and the 1473 value of each MUST be identical. Note that other agents might later add 1474 SignerInfo attributes to the SignedData block, and those additional 1475 SignerInfos might not include mlExpansionHistory attributes. 1477 A recipient MUST verify the signature of the SignerInfo which covers 1478 the mlExpansionHistory attribute before processing the 1479 mlExpansionHistory, and MUST NOT process the mlExpansionHistory 1480 attribute unless the signature over it has been verified. If a 1481 SignedData object has more than one SignerInfo that has an 1482 mlExpansionHistory attribute, the recipient MUST compare the 1483 mlExpansionHistory attributes in all the SignerInfos that it has 1484 verified, and MUST NOT process the mlExpansionHistory attribute unless 1485 every verified mlExpansionHistory attribute in the SignedData block is 1486 identical. If the mlExpansionHistory attributes in the verified 1487 signerInfos are not all identical, then the receiving agent MUST stop 1488 processing the message and SHOULD notify the user or MLA administrator 1489 of this error condition. In the mlExpansionHistory processing, 1490 SignerInfos that do not have an mlExpansionHistory attribute are 1491 ignored. 1493 4.1.1 Detecting Mail List Expansion Loops 1495 Prior to expanding a message, the MLA examines the value of any 1496 existing mail list expansion history attribute to detect an expansion 1497 loop. An expansion loop exists when a message expanded by a specific 1498 MLA for a specific mail list is redelivered to the same MLA for the 1499 same mail list. 1501 Expansion loops are detected by examining the mailListIdentifier field 1502 of each MLData entry found in the mail list expansion history. If an 1503 MLA finds its own identification information, then the MLA must 1504 discontinue expansion processing and should provide warning of an 1505 expansion loop to a human mail list administrator. The mail list 1506 administrator is responsible for correcting the loop condition. 1508 4.2 Mail List Agent Processing 1510 The first few paragraphs of this section provide a high-level description 1511 of MLA processing. The rest of the section provides a detailed description 1512 of MLA processing. 1514 MLA message processing depends on the structure of the S/MIME layers in the 1515 message sent to the MLA for expansion. In addition to sending triple 1516 wrapped messages to an MLA, an entity can send other types of messages to 1517 an MLA, such as: 1518 - a single wrapped signedData or envelopedData message 1519 - a double wrapped message (such as signed and enveloped, enveloped and 1520 signed, or signed and signed, and so on) 1521 - a quadruple-wrapped message (such as if a well-formed triple wrapped 1522 message was sent through a gateway that added an outer SignedData layer) 1524 In all cases, the MLA MUST parse all layers of the received message to 1525 determine if there are any signedData layers that include an 1526 eSSSecurityLabel signedAttribute. This may include decrypting an 1527 EnvelopedData layer to determine if an encapsulated SignedData layer 1528 includes an eSSSecurityLabel attribute. The MLA MUST fully process each 1529 eSSSecurityLabel attribute found in the various signedData layers, 1530 including performing access control checks, before distributing the message 1531 to the ML members. The details of the access control checks are beyond the 1532 scope of this document. The MLA MUST verify the signature of the signerInfo 1533 including the eSSSecurityLabel attribute before using it. 1535 In all cases, the MLA MUST sign the message to be sent to the ML members in 1536 a new "outer" signedData layer. The MLA MUST add or update an 1537 mlExpansionHistory attribute in the "outer" signedData that it creates to 1538 document MLA processing. If there was an "outer" signedData layer included 1539 in the original message received by the MLA, then the MLA-created "outer" 1540 signedData layer MUST include each signed attribute present in the 1541 original "outer" signedData layer, unless the MLA explicitly replaces an 1542 attribute (such as signingTime or mlExpansionHistory) with a new value. 1544 When an S/MIME message is received by the MLA, the MLA MUST first determine 1545 which received signedData layer, if any, is the "outer" signedData layer. 1546 To identify the received "outer" signedData layer, the MLA MUST verify the 1547 signature and fully process the signedAttributes in each of the 1548 outer signedData layers (working from the outside in) to determine if any 1549 of them either include an mlExpansionHistory attribute or encapsulate an 1550 envelopedData object. 1552 The MLA's search for the "outer" signedData layer is completed when it 1553 finds one of the following: 1554 - the "outer" signedData layer that includes an mlExpansionHistory 1555 attribute or encapsulates an envelopedData object 1556 - an envelopedData layer 1557 - the original content (that is, a layer that is neither envelopedData nor 1558 signedData). 1560 If the MLA finds an "outer" signedData layer, then the MLA MUST perform 1561 the following steps: 1563 1. Strip off all of the signedData layers that encapsulated the "outer" 1564 signedData layer 1566 2. Strip off the "outer" signedData layer itself (after remembering the 1567 included signedAttributes) 1569 3. Expand the envelopedData (if present) 1571 4. Sign the message to be sent to the ML members in a new "outer" 1572 signedData layer that includes the signedAttributes (unless explicitly 1573 replaced) from the original, received "outer" signedData layer. 1575 If the MLA finds an "outer" signedData layer that includes an 1576 mlExpansionHistory attribute AND the MLA subsequently finds an 1577 envelopedData layer buried deeper with the layers of the received message, 1578 then the MLA MUST strip off all of the signedData layers down to the 1579 envelopedData layer (including stripping off the original "outer" 1580 signedData layer) and MUST sign the expanded envelopedData in a new "outer" 1581 signedData layer that includes the signedAttributes (unless explicitly 1582 replaced) from the original, received "outer" signedData layer. 1584 If the MLA does not find an "outer" signedData layer AND does not find an 1585 envelopedData layer, then the MLA MUST sign the original, received message 1586 in a new "outer" signedData layer. If the MLA does not find an "outer" 1587 signedData AND does find an envelopedData layer then it MUST expand the 1588 envelopedData layer, if present, and sign it in a new "outer" signedData 1589 layer. 1591 4.2.1 Examples of Rule Processing 1593 The following examples help explain the rules above: 1595 1) A message (S1(Original Content)) (where S = SignedData) is sent to the 1596 MLA in which the signedData layer does not include an MLExpansionHistory 1597 attribute. The MLA verifies and fully processes the signedAttributes in S1. 1598 The MLA decides that there is not an original, received "outer" signedData 1599 layer since it finds the original content, but never finds an envelopedData 1600 and never finds an mlExpansionHistory attribute. The MLA calculates a new 1601 signedData layer, S2, resulting in the following message sent to the ML 1602 recipients: (S2(S1(Original Content))). The MLA includes an 1603 mlExpansionHistory attribute in S2. 1605 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in which 1606 none of the signedData layers includes an MLExpansionHistory attribute. The 1607 MLA verifies and fully processes the signedAttributes in S3, S2 and S1. The 1608 MLA decides that there is not an original, received "outer" signedData 1609 layer since it finds the original content, but never finds an envelopedData 1610 and never finds an mlExpansionHistory attribute. The MLA calculates a new 1611 signedData layer, S4, resulting in the following message sent to the ML 1612 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes an 1613 mlExpansionHistory attribute in S4. 1615 3) A message (E1(S1(Original Content))) (where E = envelopedData) is sent 1616 to the MLA in which S1 does not include an MLExpansionHistory attribute. 1617 The MLA decides that there is not an original, received "outer" signedData 1618 layer since it finds the E1 as the outer layer. The MLA expands the 1619 recipientInformation in E1. The MLA calculates a new signedData layer, S2, 1620 resulting in the following message sent to the ML recipients: 1621 (S2(E1(S1(Original Content)))). The MLA includes an mlExpansionHistory 1622 attribute in S2. 1624 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in which S2 1625 includes an MLExpansionHistory attribute. The MLA verifies the signature 1626 and fully processes the signedAttributes in S2. The MLA finds the 1627 mlExpansionHistory attribute in S2, so it decides that S2 is the "outer" 1628 signedData. The MLA remembers the signedAttributes included in S2 for later 1629 inclusion in the new outer signedData that it applies to the message. The 1630 MLA strips off S2. The MLA then expands the recipientInformation in E1 1631 (this invalidates the signature in S2 which is why it was stripped). The 1632 MLA calculates a new signedData layer, S3, resulting in the following 1633 message sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA 1634 includes in S3 the attributes from S2 (unless it specifically replaces an 1635 attribute value) including an updated mlExpansionHistory attribute. 1637 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 1638 none of the signedData layers include an MLExpansionHistory attribute. The 1639 MLA verifies the signature and fully processes the signedAttributes in S3 1640 and S2. When the MLA encounters E1, then it decides that S2 is the "outer" 1641 signedData since S2 encapsulates E1. The MLA remembers the signedAttributes 1642 included in S2 for later inclusion in the new outer signedData that it 1643 applies to the message. The MLA strips off S3 and S2. The MLA then expands 1644 the recipientInformation in E1 (this invalidates the signatures in S3 and 1645 S2 which is why they were stripped). The MLA calculates a new signedData 1646 layer, S4, resulting in the following message sent to the ML recipients: 1647 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from 1648 S2 (unless it specifically replaces an attribute value) and includes a new 1649 mlExpansionHistory attribute. 1651 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in which 1652 S3 includes an MLExpansionHistory attribute. In this case, the MLA verifies 1653 the signature and fully processes the signedAttributes in S3. The MLA finds 1654 the mlExpansionHistory in S3, so it decides that S3 is the "outer" 1655 signedData. The MLA remembers the signedAttributes included in S3 for later 1656 inclusion in the new outer signedData that it applies to the message. The 1657 MLA keeps on parsing encapsulated layers because it must determine if there 1658 are any eSSSecurityLabel attributes contained within. The MLA verifies the 1659 signature and fully processes the signedAttributes in S2. When the MLA 1660 encounters E1, then it strips off S3 and S2. The MLA then expands the 1661 recipientInformation in E1 (this invalidates the signatures in S3 and S2 1662 which is why they were stripped). The MLA calculates a new signedData 1663 layer, S4, resulting in the following message sent to the ML recipients: 1664 (S4(E1(S1(Original Content)))). The MLA includes in S4 the attributes from 1665 S3 (unless it specifically replaces an attribute value) including an 1666 updated mlExpansionHistory attribute. 1668 4.2.3 Processing Choices 1670 The processing used depends on the type of the outermost layer of the 1671 message. There are three cases for the type of the outermost data: 1672 - EnvelopedData 1673 - SignedData 1674 - data 1676 4.2.3.1 Processing for EnvelopedData 1678 1. The MLA locates its own RecipientInfo and uses the information it 1679 contains to obtain the message key. 1681 2. The MLA removes the existing recipientInfos field and replaces it with a 1682 new recipientInfos value built from RecipientInfo structures created for 1683 each member of the mailing list. The MLA also removes the existing 1684 originatorInfo field and replaces it with a new originatorInfo value built 1685 from information describing the MLA. 1687 3. The MLA encapsulates the expanded encrypted message in a SignedData 1688 block, adding an mlExpansionHistory attribute as described in the "Mail 1689 List Expansion" section to document the expansion. 1691 4. The MLA signs the new message and delivers the updated message to mail 1692 list members to complete MLA processing. 1694 4.2.3.2 Processing for SignedData 1696 MLA processing of multi-layer messages depends on the type of data in each 1697 of the layers. Step 3 below specifies that different processing will take 1698 place depending on the type of CMS message that has been signed. That is, 1699 it needs to know the type of data at the next inner layer, which may or may 1700 not be the innermost layer. 1702 1. The MLA verifies the signature value found in the outermost SignedData 1703 layer associated with the signed data. MLA processing of the message 1704 terminates if the message signature is invalid. 1706 2. If the outermost SignedData layer includes a signed mlExpansionHistory 1707 attribute, the MLA checks for an expansion loop as described in the 1708 "Detecting Mail List Expansion Loops" section, then go to step 3. If the 1709 outermost SignedData layer does not include a signed mlExpansionHistory 1710 attribute, the MLA signs the whole message (including this outermost 1711 SignedData layer that doesn't have an mlExpansionHistory attribute), and 1712 delivers the updated message to mail list members to complete MLA 1713 processing. 1715 3. Determine the type of the data that has been signed. That is, look at 1716 the type of data on the layer just below the SignedData, which may or may 1717 not be the "innermost" layer. Based on the type of data, perform either 1718 step 3.1 (EnvelopedData), step 3.2 (SignedData), or step 3.3 (all other 1719 types). 1721 3.1. If the signed data is EnvelopedData, the MLA performs expansion 1722 processing of the encrypted message as described previously. Note that 1723 this process invalidates the signature value in the outermost 1724 SignedData layer associated with the original encrypted message. 1725 Proceed to section 3.2 with the result of the expansion. 1727 3.2. If the signed data is SignedData, or is the result of expanding an 1728 EnvelopedData block in step 3.1: 1730 3.2.1. The MLA strips the existing outermost SignedData layer after 1731 remembering the value of the mlExpansionHistory and all other 1732 signed attributes in that layer, if present. 1734 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 1735 encapsulates the expanded encrypted message in a new outermost 1736 SignedData layer. On the other hand, if the signed data is 1737 SignedData (from step 3.2), the MLA encapsulates the signed data in 1738 a new outermost SignedData layer. 1740 3.2.3. The outermost signedData layer created by the MLA replaces 1741 the original outermost signedData layer. The MLA MUST create an 1742 signed attribute list for the new outermost signedData layer which 1743 MUST include each signed attribute present in the original 1744 outermost signedData layer, unless the MLA explicitly replaces one 1745 or more particular attributes with new value. A special case is the 1746 mlExpansionHistory attribute. The MLA MUST add an 1747 mlExpansionHistory signed attribute to the outer signedData layer 1748 as follows: 1750 3.2.3.1. If the original outermost SignedData layer included an 1751 mlExpansionHistory attribute, the attribute's value is copied 1752 and updated with the current ML expansion information as 1753 described in the "Mail List Expansion" section. 1755 3.2.3.2. If the original outermost SignedData layer did not 1756 include an mlExpansionHistory attribute, a new attribute value 1757 is created with the current ML expansion information as 1758 described in the "Mail List Expansion" section. 1760 3.3. If the signed data is not EnvelopedData or SignedData: 1762 3.3.1. The MLA encapsulates the received signedData object in an 1763 outer SignedData object, and adds an mlExpansionHistory attribute 1764 to the outer SignedData object containing the current ML expansion 1765 information as described in the "Mail List Expansion" section. 1767 4. The MLA signs the new message and delivers the updated message to mail 1768 list members to complete MLA processing. 1770 A flow chart for the above steps would be: 1772 1. Has a valid signature? 1773 YES -> 2. 1774 NO -> STOP. 1775 2. Does outermost SignedData layer contain mlExpansionHistory? 1776 YES -> Check it, then -> 3. 1777 NO -> Sign message (including outermost SignedData that 1778 doesn't have mlExpansionHistory), deliver it, STOP. 1779 3. Check type of data just below outermost SignedData. 1780 EnvelopedData -> 3.1. 1781 SignedData -> 3.2. 1782 all others -> 3.3. 1783 3.1. Expand the encrypted message, then -> 3.2. 1784 3.2. -> 3.2.1. 1785 3.2.1. Strip outermost SignedData layer, note value of mlExpansionHistory 1786 and other signed attributes, then -> 3.2.2. 1787 3.2.2. Encapsulate in new signature, then -> 3.2.3. 1788 3.2.3. Create new signedData layer. Was there an old mlExpansionHistory? 1789 YES -> copy the old mlExpansionHistory values, then -> 4. 1790 NO -> create new mlExpansionHistory value, then -> 4. 1791 3.3. Encapsulate in a SignedData layer and add an mlExpansionHistory 1792 attribute, then -> 4. 1793 4. Sign message, deliver it, STOP. 1795 4.2.3.3 Processing for data 1797 1. The MLA encapsulates the message in a SignedData layer, and adds an 1798 mlExpansionHistory attribute containing the current ML expansion 1799 information as described in the "Mail List Expansion" section. 1801 2. The MLA signs the new message and delivers the updated message to mail 1802 list members to complete MLA processing. 1804 4.3 Mail List Agent Signed Receipt Policy Processing 1806 If a mailing list (B) is a member of another mailing list (A), list B often 1807 needs to propagate forward the mailing list receipt policy of A. As a 1808 general rule, a mailing list should be conservative in propagating forward 1809 the mailing list receipt policy because the ultimate recipient need only 1810 process the last item in the ML expansion history. The MLA builds the 1811 expansion history to meet this requirement. 1813 The following table describes the outcome of the union of mailing list A's 1814 policy (the rows in the table) and mailing list B's policy (the columns in 1815 the table). 1817 | B's policy 1818 A's policy | none insteadOf inAdditionTo missing 1819 ------------------------------------------------------------------------- 1820 none | none none none none 1821 insteadOf | none insteadOf(B) *1 insteadOf(A) 1822 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) 1823 missing | none insteadOf(B) inAdditionTo(B) missing 1825 *1 = insteadOf(insteadOf(A) + inAdditionTo(B)) 1826 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) 1828 4.4 Mail List Expansion History Syntax 1830 An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If 1831 there are more than ub-ml-expansion-history mailing lists in the sequence, 1832 the receiving agent should provide notification of the error to a human 1833 mail list administrator. The mail list administrator is responsible for 1834 correcting the overflow condition. 1836 MLExpansionHistory ::= SEQUENCE 1837 SIZE (1..ub-ml-expansion-history) OF MLData 1839 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1840 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 1842 ub-ml-expansion-history INTEGER ::= 64 1844 MLData contains the expansion history describing each MLA that has 1845 processed a message. As an MLA distributes a message to members of an ML, 1846 the MLA records its unique identifier, date and time of expansion, and 1847 receipt policy in an MLData structure. 1849 MLData ::= SEQUENCE { 1850 mailListIdentifier EntityIdentifier, 1851 expansionTime GeneralizedTime, 1852 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 1854 EntityIdentifier ::= CHOICE { 1855 issuerAndSerialNumber IssuerAndSerialNumber, 1856 subjectKeyIdentifier SubjectKeyIdentifier } 1858 The receipt policy of the ML can withdraw the originator's request for the 1859 return of a signed receipt. However, if the originator of the message has 1860 not requested a signed receipt, the MLA cannot request a signed receipt. In 1861 the event that a ML's signed receipt policy supersedes the originator's 1862 request for signed receipts, such that the originator will not receive any 1863 signed receipts, then the MLA MAY inform the originator of that fact. 1865 When present, the mlReceiptPolicy specifies a receipt policy that 1866 supersedes the originator's request for signed receipts. The policy can be 1867 one of three possibilities: receipts MUST NOT be returned (none); receipts 1868 should be returned to an alternate list of recipients, instead of to the 1869 originator (insteadOf); or receipts should be returned to a list of 1870 recipients in addition to the originator (inAdditionTo). 1872 MLReceiptPolicy ::= CHOICE { 1873 none [0] NULL, 1874 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1875 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1877 5. Signing Certificate Attribute 1879 Concerns have been raised over the fact that the certificate which the 1880 signer of a CMS SignedData object desired to be bound into the verification 1881 process of the SignedData object is not cryptographically bound into the 1882 signature itself. This section addresses this issue by creating a new 1883 attribute to be placed in the signed attributes section of a SignerInfo 1884 object. 1886 This section also presents a description of a set of possible attacks 1887 dealing with the substitution of one certificate to verify the signature 1888 for the desired certificate. A set of ways for preventing or addressing 1889 these attacks is presented to deal with the simplest of the attacks. 1891 Authorization information can be used as part of a signature 1892 verification process. This information can be carried in either 1893 attribute certificates and other public key certificates. The signer 1894 needs to have the ability to restrict the set of certificates used in 1895 the signature verification process, and information needs to be encoded 1896 so that is covered by the signature on the SignedData object. The 1897 methods in this section allow for the set of authorization certificates 1898 to be listed as part of the signing certificate attribute. 1900 Explicit certificate policies can also be used as part of a signature 1901 verification process. If a signer desires to state an explicit certificate 1902 policy that should be used when validating the signature, that policy needs 1903 to be cryptographically bound into the signing process. The methods 1904 described in this section allows for a set of certificate policy statements 1905 to be listed as part of the signing certificate attribute. 1907 5.1. Attack Descriptions 1909 At least three different attacks can be launched against a possible 1910 signature verification process by replacing the certificate or certficates 1911 used in the signature verification process. 1913 5.1.1 Substitution Attack Description 1915 The first attack deals with simple substitution of one certificate for 1916 another certificate. In this attack, the issuer and serial number in the 1917 SignerInfo is modified to refer to a new certificate. This new certificate 1918 is used during the signature verification process. 1920 The first version of this attack is a simple denial of service attack where 1921 an invalid certificate is substituted for the valid certificate. This 1922 renders the message unverifiable, as the public key in the certificate no 1923 longer matches the private key used to sign the message. 1925 The second version is a substitution of one valid certificate for the 1926 original valid certificate where the public keys in the certificates match. 1927 This allows the signature to be validated under potentially different 1928 certificate constraints than the originator of the message intended. 1930 5.1.2 Reissue of Certificate Description 1932 The second attack deals with a certificate authority (CA) re-issuing the 1933 signing certificate (or potentially one of its certificates). This attack 1934 may start becoming more frequent as Certificate Authorities reissue their 1935 own root certificates, or as certificate authorities change policies in the 1936 certificate while reissuing their root certificates. This problem also 1937 occurs when cross certificates (with potentially different restrictions) 1938 are used in the process of verifying a signature. 1940 5.1.3 Rogue Duplicate CA Description 1942 The third attack deals with a rogue entity setting up a certificate 1943 authority that attempts to duplicate the structure of an existing CA. 1944 Specifically, the rogue entity issues a new certificate with the same 1945 public keys as the signer used, but signed by the rogue entity's private 1946 key. 1948 5.2 Attack Responses 1950 This document does not attempt to solve all of the above attacks; however, 1951 a brief description of responses to each of the attacks is given in this 1952 section. 1954 5.2.1 Substitution Attack Response 1956 The denial of service attack cannot be prevented. After the certificate 1957 identifier has been modified in transit, no verification of the signature 1958 is possible. There is also no way to automatically identify the attack 1959 because it is indistinguishable from a message corruption. 1961 The substitution of a valid certificate can be responded to in two 1962 different manners. The first is to make a blanket statement that the use of 1963 the same public key in two different certificates is bad practice and has 1964 to be avoided. In practice, there is no practical way to prevent users from 1965 getting new certificates with the same public keys, and it should be 1966 assumed that they will do this. Section 5.4 provides a new attribute that 1967 can be included in the SignerInfo signed attributes. This binds the correct 1968 certificate identifier into the signature. This will convert the attack 1969 from a potentially successful one to simply a denial of service attack. 1971 5.2.2 Reissue of Certificate Response 1973 A CA should never reissue a certificate with different attributes. 1974 Certificate Authorities that do so are following poor practices and cannot 1975 be relied on. Using the hash of the certificate as the reference to the 1976 certificate prevents this attack for end-entity certificates. 1978 Preventing the attack based on reissuing of CA certificates would require a 1979 substantial change to the usage of the signingCertificate attribute 1980 presented in section 5.4. It would require that ESSCertIDs would need to be 1981 included in the attribute to represent the issuer certificates in the 1982 signer's certification path. This presents problems when the relying party 1983 is using a cross-certificate as part of its authentication process, and 1984 this certificate does not appear on the list of certificates. The problems 1985 outside of a closed PKI make the addition of this information prone to 1986 error, possibly causing the rejection of valid chains. 1988 5.2.3 Rogue Duplicate CA Response 1990 The best method of preventing this attack is to avoid trusting the rogue 1991 CA. The use of the hash to identify certificates prevents the use of 1992 end-entity certificates from the rogue authority. However the only true way 1993 to prevent this attack is to never trust the rogue CA. 1995 5.3 Related Signature Verification Context 1997 Some applications require that additional information be used as part of 1998 the signature validation process. In particular, authorization 1999 information from attribute certificates and other public key 2000 certificates or policy identifiers provide additional information about 2001 the abilities and intent of the signer. The signing certificate 2002 attribute described in Section 5.4 provides the ability to bind this 2003 context information as part of the signature. 2005 5.3.1 Authorization Information 2007 Some applications require that authorization information found in 2008 attribute certificates and/or other public key certificates be 2009 validated. This validation requires that the application be able to find 2010 the correct certificates to perform the verification process; however 2011 there is no list of the certificates to used in a SignerInfo object. The 2012 sender has the ability to include a set of attribute certificates and 2013 public key certificates in a SignedData object. The receiver has the 2014 ability to retrieve attribute certificates and public key certificates 2015 from a directory service. There are some circumstances where the signer 2016 may wish to limit the set of certificates that may be used in verifying 2017 a signature. It is useful to be able to list the set of certificates the 2018 signer wants the recipient to use in validating the signature. 2020 5.3.2 Policy Information 2022 A related aspect of the certificate binding is the issue of multiple 2023 certification paths. In some instances, the semantics of a certificate in 2024 its use with a message may depend on the Certificate Authorities and 2025 policies that apply. To address this issue, the signer may also wish to 2026 bind that context under the signature. While this could be done by either 2027 signing the complete certification path or a policy ID, only a binding for 2028 the policy ID is described here. 2030 5.4 Signing Certificate Attribute Definition 2032 The signing certificate attribute is designed to prevent the simple 2033 substitution and re-issue attacks, and to allow for a restricted set of 2034 authorization certificates to be used in verifying a signature. 2036 The definition of SigningCertificate is 2038 SigningCertificate ::= SEQUENCE { 2039 certs SEQUENCE OF ESSCertID, 2040 policies SEQUENCE OF PolicyInformation OPTIONAL 2041 } 2043 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 2044 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2045 smime(16) id-aa(2) 12 } 2047 The first certificate identified in the sequence of certificate identifiers 2048 MUST be the certificate used to verify the signature. The encoding of the 2049 ESSCertID for this certificate SHOULD include the issuerSerial field. If 2050 other constraints ensure that issuerAndSerialNumber will be present in the 2051 SignerInfo, the issuerSerial field MAY be omitted. The certificate 2052 identified is used during the signature verification process. If the hash 2053 of the certificate does not match the certificate used to verify the 2054 signature, the signature MUST be considered invalid. 2056 If more than one certificate is present in the sequence of ESSCertIDs, 2057 the certificates after the first one limit the set of authorization 2058 certificates that are used during signature validation. Authorization 2059 certificates can be either attribute certificates or normal 2060 certificates. The issuerSerial field (in the ESSCertID structure) SHOULD 2061 be present for these certificates, unless the client who is validating 2062 the signature is expected to have easy access to all the certificates 2063 requred for validation. If only the signing certificate is present in 2064 the sequence, there are no restrictions on the set of authorization 2065 certificates used in validating the signature. 2067 The sequence of policy information terms identifies those certificate 2068 policies that the signer asserts apply to the certificate, and under which 2069 the certificate should be relied upon. This value suggests a policy value 2070 to be used in the relying party's certification path validation. 2072 If present, the SigningCertificate attribute MUST be a signed attribute; it 2073 MUST NOT be an unsigned attribute. CMS defines SignedAttributes as a SET OF 2074 Attribute. A SignerInfo MUST NOT include multiple instances of the 2075 SigningCertificate attribute. CMS defines the ASN.1 syntax for the signed 2076 attributes to include attrValues SET OF AttributeValue. A 2077 SigningCertificate attribute MUST include only a single instance of 2078 AttributeValue. There MUST NOT be zero or multiple instances of 2079 AttributeValue present in the attrValues SET OF AttributeValue. 2081 5.4.1 Certificate Identification 2083 The best way to identify certificates is an often-discussed issue. [CERT] 2084 has imposed a restriction for SignedData objects that the issuer DN must be 2085 present in all signing certificates. The issuer/serial number pair is 2086 therefore sufficient to identify the correct signing certificate. This 2087 information is already present, as part of the SignerInfo object, and 2088 duplication of this information would be unfortunate. A hash of the entire 2089 certificate serves the same function (allowing the receiver to verify that 2090 the same certificate is being used as when the message was signed), is 2091 smaller, and permits a detection of the simple substitution attacks. 2093 Attribute certificates and additional public key certificates containing 2094 authorization information do not have an issuer/serial number pair 2095 represented anywhere in a SignerInfo object. When an attribute 2096 certificate or an additional public key certificate is not included in 2097 the SignedData object, it becomes much more difficult to get the correct 2098 set of certificates based only on a hash of the certificate. For this 2099 reason, these certificates SHOULD be identified by the IssuerSerial 2100 object. 2102 This document defines a certificate identifier as: 2104 ESSCertID ::= SEQUENCE { 2105 certHash Hash, 2106 issuerSerial IssuerSerial OPTIONAL 2107 } 2109 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 2111 IssuerSerial ::= SEQUENCE { 2112 issuer GeneralNames, 2113 serialNumber CertificateSerialNumber 2114 } 2116 When creating an ESSCertID, the certHash is computed over the entire DER 2117 encoded certificate including the signature. The issuerSerial would 2118 normally be present unless the value can be inferred from other 2119 information. 2121 When encoding IssuerSerial, serialNumber is the serial number that uniquely 2122 identifies the certificate. For non-attribute certificates, the issuer MUST 2123 contain only the issuer name from the certificate encoded in the 2124 directoryName choice of GeneralNames. For attribute certificates, the 2125 issuer MUST contain the issuer name field from the attribute certificate. 2127 6. Security Considerations 2129 All security considerations from [CMS] and [SMIME3] apply to applications 2130 that use procedures described in this document. 2132 As stated in Section 2.3, a recipient of a receipt request must not send 2133 back a reply if it cannot validate the signature. Similarly, if there 2134 conflicting receipt requests in a message, the recipient must not send back 2135 receipts, since an attacker may have inserted the conflicting request. 2136 Sending a signed receipt to an unvalidated sender can expose information 2137 about the recipient that it may not want to expose to unknown senders. 2139 Senders of receipts should consider encrypting the receipts to prevent a 2140 passive attacker from gleaning information in the receipts. 2142 Senders must not rely on recipients' processing software to correctly 2143 process security labels. That is, the sender cannot assume that adding a 2144 security label to a message will prevent recipients from viewing messages 2145 the sender doesn't want them to view. It is expected that there will be 2146 many S/MIME clients that will not understand security labels but will still 2147 display a labelled message to a recipient. 2149 A receiving agent that processes security labels must handle the content of 2150 the messages carefully. If the agent decides not to show the message to the 2151 intended recipient after processing the security label, the agent must take 2152 care that the recipient does not accidentally see the content at a later 2153 time. For example, if an error response sent to the originator contains the 2154 content that was hidden from the recipient, and that error response bounces 2155 back to the sender due to addressing errors, the original recipient can 2156 possibly see the content since it is unlikely that the bounce message will 2157 have the proper security labels. 2159 A man-in-the-middle attack can cause a recipient to send receipts to an 2160 attacker if that attacker has a signature that can be validated by the 2161 recipient. The attack consists of intercepting the original message and 2162 adding a mLData attribute that says that a receipt should be sent to the 2163 attacker in addition to whoever else was going to get the receipt. 2165 Mailing lists that encrypt their content may be targets for 2166 denial-of-service attacks if they do not use the mailing list management 2167 described in Section 4. Using simple RFC822 header spoofing, it is quite 2168 easy to subscribe one encrypted mailing list to another, thereby setting up 2169 an infinite loop. 2171 Mailing List Agents need to be aware that they can be used as oracles for 2172 the the adaptive chosen ciphertext attack described in [CMS]. MLAs should 2173 notify an administrator if a large number of undecryptable messages are 2174 received. 2176 When verifying a signature using certificates that come with a [CMS] 2177 message, the recipient should only verify using certificates previously 2178 known to be valid, or certificates that have come from a signed 2179 SigningCertificate attribute. Otherwise, the attacks described in Section 5 2180 can cause the receiver to possibly think a signature is valid when it is 2181 not. 2183 A. ASN.1 Module 2185 ExtendedSecurityServices 2186 { iso(1) member-body(2) us(840) rsadsi(113549) 2187 pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) } 2189 DEFINITIONS IMPLICIT TAGS ::= 2190 BEGIN 2192 IMPORTS 2194 -- Cryptographic Message Syntax (CMS) 2195 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier 2196 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 2197 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 2199 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 2200 -- 1988 Syntax 2201 PolicyInformation FROM PKIX1Implicit88 {iso(1) 2202 identified-organization(3) dod(6) internet(1) security(5) 2203 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)} 2205 -- X.509 2206 GeneralNames, CertificateSerialNumber FROM CertificateExtensions 2207 {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; 2209 -- Extended Security Services 2211 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 2212 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 2213 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 2214 -- have at least one entry. MAX indicates the upper bound is unspecified. 2215 -- Implementations are free to choose an upper bound that suits their 2216 -- environment. 2218 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 2219 -- The contents are formatted as described in [UTF8] 2221 -- Section 2.7 2223 ReceiptRequest ::= SEQUENCE { 2224 signedContentIdentifier ContentIdentifier, 2225 receiptsFrom ReceiptsFrom, 2226 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 2228 ub-receiptsTo INTEGER ::= 16 2230 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2231 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 2233 ContentIdentifier ::= OCTET STRING 2235 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2236 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 2238 ReceiptsFrom ::= CHOICE { 2239 allOrFirstTier [0] AllOrFirstTier, 2240 -- formerly "allOrNone [0]AllOrNone" 2241 receiptList [1] SEQUENCE OF GeneralNames } 2243 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 2244 allReceipts (0), 2245 firstTierRecipients (1) } 2247 -- Section 2.8 2249 Receipt ::= SEQUENCE { 2250 version ESSVersion, 2251 contentType ContentType, 2252 signedContentIdentifier ContentIdentifier, 2253 originatorSignatureValue OCTET STRING } 2255 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2256 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 2258 ESSVersion ::= INTEGER { v1(1) } 2260 -- Section 2.9 2262 ContentHints ::= SEQUENCE { 2263 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 2264 contentType ContentType } 2266 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 2267 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 2269 -- Section 2.10 2271 MsgSigDigest ::= OCTET STRING 2273 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2274 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 2276 -- Section 2.11 2278 ContentReference ::= SEQUENCE { 2279 contentType ContentType, 2280 signedContentIdentifier ContentIdentifier, 2281 originatorSignatureValue OCTET STRING } 2283 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2284 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 2286 -- Section 3.2 2288 ESSSecurityLabel ::= SET { 2289 security-policy-identifier SecurityPolicyIdentifier, 2290 security-classification SecurityClassification OPTIONAL, 2291 privacy-mark ESSPrivacyMark OPTIONAL, 2292 security-categories SecurityCategories OPTIONAL } 2294 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2295 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 2297 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 2299 SecurityClassification ::= INTEGER { 2300 unmarked (0), 2301 unclassified (1), 2302 restricted (2), 2303 confidential (3), 2304 secret (4), 2305 top-secret (5) } (0..ub-integer-options) 2307 ub-integer-options INTEGER ::= 256 2309 ESSPrivacyMark ::= CHOICE { 2310 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 2311 utf8String UTF8String (SIZE (1..MAX)) 2312 } 2314 ub-privacy-mark-length INTEGER ::= 128 2316 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 2317 SecurityCategory 2319 ub-security-categories INTEGER ::= 64 2321 SecurityCategory ::= SEQUENCE { 2322 type [0] OBJECT IDENTIFIER, 2323 value [1] ANY DEFINED BY type -- defined by type 2324 } 2326 --Note: The aforementioned SecurityCategory syntax produces identical 2327 --hex encodings as the following SecurityCategory syntax that is 2328 --documented in the X.411 specification: 2329 -- 2330 --SecurityCategory ::= SEQUENCE { 2331 -- type [0] SECURITY-CATEGORY, 2332 -- value [1] ANY DEFINED BY type } 2333 -- 2334 --SECURITY-CATEGORY MACRO ::= 2335 --BEGIN 2336 --TYPE NOTATION ::= type | empty 2337 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 2338 --END 2340 -- Section 3.4 2342 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 2344 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2345 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 2347 -- Section 4.4 2349 MLExpansionHistory ::= SEQUENCE 2350 SIZE (1..ub-ml-expansion-history) OF MLData 2352 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2353 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 2355 ub-ml-expansion-history INTEGER ::= 64 2357 MLData ::= SEQUENCE { 2358 mailListIdentifier EntityIdentifier, 2359 expansionTime GeneralizedTime, 2360 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 2362 EntityIdentifier ::= CHOICE { 2363 issuerAndSerialNumber IssuerAndSerialNumber, 2364 subjectKeyIdentifier SubjectKeyIdentifier } 2366 MLReceiptPolicy ::= CHOICE { 2367 none [0] NULL, 2368 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 2369 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 2371 -- Section 5.4 2373 SigningCertificate ::= SEQUENCE { 2374 certs SEQUENCE OF ESSCertID, 2375 policies SEQUENCE OF PolicyInformation OPTIONAL 2376 } 2378 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 2379 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 2380 smime(16) id-aa(2) 12 } 2382 ESSCertID ::= SEQUENCE { 2383 certHash Hash, 2384 issuerSerial IssuerSerial OPTIONAL 2385 } 2387 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 2389 IssuerSerial ::= SEQUENCE { 2390 issuer GeneralNames, 2391 serialNumber CertificateSerialNumber 2392 } 2394 END -- of ExtendedSecurityServices 2396 B. References 2398 [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax 2399 Notation One (ASN.1)" 2401 [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax 2402 Notation One (ASN.1)" 2404 [CERT] "S/MIME Version 3 Certificate Handling", Internet Draft 2405 draft-ietf-smime-cert-xx. 2407 [CMS] "Cryptographic Message Syntax", Internet Draft 2408 draft-ietf-smime-cms-xx. 2410 [MSG] "S/MIME Version 3 Message Specification", Internet Draft 2411 draft-ietf-smime-msg-xx. 2413 [MUSTSHOULD] "Key Words for Use in RFCs to Indicate Requirement Levels", 2414 RFC 2119. 2416 [MSP4] "Secure Data Network System (SDNS) Message Security Protocol (MSP) 2417 4.0", Specification SDN.701, Revision A, 1997-02-06. 2419 [MTSABS] "1988 International Telecommunication Union (ITU) Data 2420 Communication Networks Message Handling Systems: Message Transfer System: 2421 Abstract Service Definition and Procedures, Volume VIII, Fascicle VIII.7, 2422 Recommendation X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6) 2423 mts(3) modules(0) mts-abstract-service(1)} 2425 [PKCS7-1.5] "PKCS #7: Cryptographic Message Syntax", RFC 2315. 2427 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 2428 "S/MIME Version 2 Certificate Handling", RFC 2312. 2430 [UTF8] "UTF-8, a transformation format of ISO 10646", RFC 2279. 2432 C. Acknowledgments 2434 The first draft of this work was prepared by David Solo. John Pawling did a 2435 huge amount of very detailed revision work during the many phases of the 2436 document. 2438 Many other people have contributed hard work to this draft, including: 2439 Andrew Farrell 2440 Bancroft Scott 2441 Bengt Ackzell 2442 Bill Flanigan 2443 Blake Ramsdell 2444 Carlisle Adams 2445 Darren Harter 2446 David Kemp 2447 Denis Pinkas 2448 Francois Rousseau 2449 Jim Schaad 2450 Russ Housley 2451 Scott Hollenbeck 2452 Steve Dusse 2454 D. Changes from draft-ietf-smime-ess-11 to draft-ietf-smime-ess-12 2455 [[Should be removed when becoming an RFC]] 2457 General: Corrected "an signed" to "a signed". 2459 1, 1.3: Corrected "three services" to "four services". 2461 2.6: Corrected spelling of "recipients". 2463 5: Made changes to make it clear that the section covered certs 2464 that were used for authorization. 2466 5.2.2: Corrected "attach" to "attack". 2468 5.4: Third paragraph, replaced the third sentence to make it 2469 clearer. 2471 C: Added Francois Rousseau. 2473 E. Editor's Address 2475 Paul Hoffman 2476 Internet Mail Consortium 2477 127 Segre Place 2478 Santa Cruz, CA 95060 2479 phoffman@imc.org