idnits 2.17.1 draft-ietf-smime-rfc2634-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1716. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1801 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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.) ** 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 66: '...nd ContentIdentifier MAY appear in any...' RFC 2119 keyword, line 68: '...lExpansionHistory MUST be carried in a...' RFC 2119 keyword, line 69: '...ibutes type, and MUST NOT be carried i...' RFC 2119 keyword, line 71: '...and signingCertificate MUST be carried...' RFC 2119 keyword, line 72: '...dAttributes, and MUST NOT be carried i...' (98 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 763 has weird spacing: '... | none inst...' == Line 765 has weird spacing: '... | none none...' == Line 766 has weird spacing: '... | none inst...' == Line 767 has weird spacing: '... | none inst...' == Line 1324 has weird spacing: '... | none inst...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7191 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? 'ESS' on line 99 looks like a reference -- Missing reference section? 'CMS' on line 646 looks like a reference -- Missing reference section? 'MSG' on line 97 looks like a reference -- Missing reference section? '0' on line 1639 looks like a reference -- Missing reference section? '1' on line 1640 looks like a reference -- Missing reference section? '2' on line 1641 looks like a reference -- Missing reference section? 'UNIVERSAL 12' on line 1411 looks like a reference -- Missing reference section? 'UTF8' on line 1412 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group J Schaad 2 Internet Draft Soaring Hawk Consulting 3 August 2004 4 Category: Standards Track 6 Enhanced Security Services for S/MIME 7 draft-ietf-smime-rfc2634-update-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes the structures and procedures necessary to 38 provide a number of additional security services for S/MIME. These 39 services are: 41 - signed receipts 42 - security labels 43 - secure mailing lists 44 - signing certificate validation 46 These services can be used by any CMS (Cryptographic Message Syntax) 47 based protocol. 49 ******************************************************************** 51 Schaad 1 52 RFC2634Update August 2004 54 This document currently only contains the sections of RFC 2634 that 55 are being updated. The two documents will be folded together at a 56 later date. 58 ******************************************************************** 60 1.3.4 Placement of Attributes 62 Certain attributes should be placed in the inner or outer SignedData 63 message; some attributes can be in either. Further, some attributes 64 must be signed, while signing is optional for others, and some 65 attributes must not be signed. ESS defines several types of 66 attributes. ContentHints and ContentIdentifier MAY appear in any 67 list of attributes. contentReference, equivalentLabel, 68 eSSSecurityLabel and mlExpansionHistory MUST be carried in a 69 SignedAttributes or AuthAttributes type, and MUST NOT be carried in a 70 UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. 71 msgSigDigest, receiptRequest and signingCertificate MUST be carried 72 in a SignedAttributes, and MUST NOT be carried in a AuthAttributes, 73 UnsignedAttributes, UnauthAttributes or UnprotectedAttributes type. 75 The following table summarizes the recommendation of this profile. In 76 the OID column, [ESS] indicates that the attribute is defined in this 77 document. 79 | |Inner or | 80 Attribute |OID |outer |Signed 81 ------------------|----------------------------- |----------|-------- 82 contentHints |id-aa-contentHint [ESS] |either |MAY 83 contentIdentifier |id-aa-contentIdentifier [ESS] |either |MAY 84 contentReference |id-aa-contentReference [ESS] |either |MUST 85 contentType |id-contentType [CMS] |either |MUST 86 counterSignature |id-countersignature [CMS] |either |MUST NOT 87 equivalentLabel |id-aa-equivalentLabels [ESS] |either |MUST 88 eSSSecurityLabel |id-aa-securityLabel [ESS] |either |MUST 89 messageDigest |id-messageDigest [CMS] |either |MUST 90 msgSigDigest |id-aa-msgSigDigest [ESS] |inner only|MUST 91 mlExpansionHistory|id-aa-mlExpandHistory [ESS] |outer only|MUST 92 receiptRequest |id-aa-receiptRequest [ESS] |inner only|MUST 93 signingCertificate|id-aa-signingCertificate [ESS]|either |MUST 94 signingTime |id-signingTime [CMS] |either |MUST 95 smimeCapabilities |sMIMECapabilities [MSG] |either |MUST 96 sMIMEEncryption- 97 KeyPreference |id-aa-encrypKeyPref [MSG] |either |MUST 98 mlaExpandHistory |id-aa-mlaExpandHistory [ESS] |outer only|MUST 99 receiptModify |id-aa-receiptModify [ESS] |either |MUST 101 CMS defines signedAttrs as a SET OF Attribute and defines 102 unsignedAttrs as a SET OF Attribute. ESS defines the contentHints, 103 contentIdentifier, eSSecurityLabel, msgSigDigest, mlExpansionHistory, 104 receiptRequest, contentReference, equivalentLabels and 106 Schaad 2 107 RFC2634Update August 2004 109 signingCertificate attribute types. A signerInfo MUST NOT include 110 multiple instances of any of the attribute types defined in ESS. 111 Later sections of ESS specify further restrictions that apply to the 112 receiptRequest, mlExpansionHistory and eSSecurityLabel attribute 113 types. 115 CMS defines the syntax for the signed and unsigned attributes as 116 "attrValues SET OF AttributeValue". For all of the attribute types 117 defined in ESS, if the attribute type is present in a signerInfo, 118 then it MUST only include a single instance of AttributeValue. In 119 other words, there MUST NOT be zero, or multiple, instances of 120 AttributeValue present in the attrValues SET OF AttributeValue. 122 If a counterSignature attribute is present, then it MUST be included 123 in the unsigned attributes. It MUST NOT be included in the signed 124 attributes. The only attributes that are allowed in a 125 counterSignature attribute are counterSignature, messageDigest, 126 signingTime, and signingCertificate. 128 Note that the inner and outer signatures are usually those of 129 different senders. Because of this, the same attribute in the two 130 signatures could lead to very different consequences. 132 ContentIdentifier is an attribute (OCTET STRING) used to carry a 133 unique identifier assigned to the message. 135 2. Signed Receipts 137 Returning a signed receipt provides to the originator proof of 138 delivery of a message, and allows the originator to demonstrate to a 139 third party that the recipient was able to verify the signature of 140 the original message. This receipt is bound to the original message 141 through the signature; consequently, this service may be requested 142 only if a message is signed. The receipt sender may optionally also 143 encrypt a receipt to provide confidentiality between the receipt 144 sender and the receipt recipient. 146 2.1 Signed Receipt Concepts 148 The originator of a message can request a signed receipt from the 149 message's recipients. The request is indicated by adding a 150 receiptRequest attribute to the signedAttrs field of the SignerInfo 151 object for which the receipt is requested. The receiving user agent 152 software SHOULD automatically create a signed receipt when requested 153 to do so, and return the receipt in accordance with mailing list 154 expansion options, local security policies, and configuration 155 options. 157 Because receipts involve the interaction of two parties, the 158 terminology can sometimes be confusing. In this section, the "sender" 159 is the agent that sent the original message that included a request 160 for a receipt. The "receiver" is the party that received that message 161 and generated the receipt. 163 Schaad 3 164 RFC2634Update August 2004 166 The steps in a typical transaction are: 168 1. Sender creates a signed message including a receipt request 169 attribute (Section 2.2). 171 2. Sender transmits the resulting message to the recipient or 172 recipients. 174 3. Recipient receives message and determines if there is a valid 175 signature and receipt request in the message (Section 2.3). 177 4. Recipient creates a signed receipt (Section 2.4). 179 5. Recipient transmits the resulting signed receipt message to the 180 sender (Section 2.5). 182 6. Sender receives the message and validates that it contains a 183 signed receipt for the original message (Section 2.6). This 184 validation relies on the sender having retained either a copy of 185 the original message or information extracted from the original 186 message. 188 The ASN.1 syntax for the receipt request is given in Section 2.7; the 189 ASN.1 syntax for the receipt is given in Section 2.9. 191 Note that a Recipient Agent SHOULD remember when it has sent a 192 receipt so that it can avoid re-sending a receipt each time it 193 processes the message. 195 A receipt request can indicate that receipts be sent to many places, 196 not just to the sender (in fact, the receipt request might indicate 197 that the receipts should not even go to the sender). In order to 198 verify a receipt, the recipient of the receipt needs to be the 199 originator or a recipient of the original message. Thus, the sender 200 SHOULD NOT request that receipts be sent to anyone who does not have 201 an exact copy of the message. 203 2.2 Receipt Request Creation 205 Multi-layer S/MIME messages can contain multiple SignedData layers. 206 However, only one layer can contain a receipt request. This will 207 generally be the innermost layer, but in some workflow applications 208 it can be a middle or outer layer. Receipt processing MUST NOT start 209 before all layers of CMS content are unwound so that only the 210 innermost receipt request is processed. Only one receiptRequest 211 attribute can be included in the signedAttrs of a SignerInfo. 213 A ReceiptRequest attribute MUST NOT be included in the attributes of 214 a SignerInfo in a SignedData object that encapsulates a content type 215 of Receipt (id-ct-receipt). In other words, the receiving agents 216 MUST NOT request a signed receipt for a signed receipt. 218 Schaad 4 219 RFC2634Update August 2004 221 A sender requests receipts by placing a receiptRequest attribute in 222 the signed attributes of a signerInfo as follows: 224 1. A receiptRequest data structure is created. 226 2. A signed content identifier for the message is created and 227 assigned to the signedContentIdentifier field. The 228 signedContentIdentifier is used to associate the signed receipt 229 with the message requesting the signed receipt. 231 3. The entities requested to return a signed receipt are noted in the 232 receiptsFrom field. 234 4. The message originator MUST populate the receiptsTo field with a 235 GeneralNames for each entity to whom the recipient should send the 236 signed receipt. If the message originator wants the recipient to 237 send the signed receipt to the originator, then the originator 238 MUST include a GeneralNames for itself in the receiptsTo field. 239 GeneralNames is a SEQUENCE OF GeneralName. receiptsTo is a 240 SEQUENCE OF GeneralNames in which each GeneralNames represents an 241 entity. There can be multiple GeneralName instances in each 242 GeneralNames. At a minimum, the message originator MUST populate 243 each entity's GeneralNames with the address to which the signed 244 receipt is suppose to be sent. Optionally, the message originator 245 MAY also populate each entity's GeneralNames with other 246 GeneralName instances (such as directoryName). 248 5. The completed receiptRequest attribute is placed in the 249 signedAttrs field of the SignerInfo object. 251 2.2.1 Multiple Receipt Requests 253 There can be multiple SignerInfos within a SignedData object, and 254 each SignerInfo can include signedAttrs. Therefore, a single 255 SignedData object can include multiple SignerInfos, each SignerInfo 256 having a receiptRequest attribute. For example, an originator can 257 send a signed message with two SignerInfos, one containing a DSS 258 signature, the other containing an RSA signature. 260 Each recipient SHOULD return only one signed receipt. 262 Not all of the SignerInfos within a SignedData object need to include 263 receipt requests, but in all of the SignerInfos that do contain 264 receipt requests, the receipt requests MUST be identical. 266 2.2.2 Information Needed to Validate Signed Receipts 268 The sending agent MUST retain one or both of the following items to 269 support the validation of signed receipts returned by the recipients. 271 - the original SignedData object requesting the signed receipt 273 Schaad 5 274 RFC2634Update August 2004 276 - the content identifier in the receipt request, the message 277 signature digest value and the content type and signature value 278 included in the original SignedData object. If signed receipts are 279 requested from multiple recipients, then retaining these values is 280 a performance enhancement because the sending agent can reuse the 281 saved values when verifying each returned signed receipt. 283 2.3 Receipt Request Processing 285 A receiptRequest is associated only with the SignerInfo object that 286 the receipt request is an authenticated attribute of. The behavior 287 for processing of a receiptRequest is modified by the presence of a 288 either a receiptPolicy or an mlaExpandHistory attribute either in the 289 same SignerData or in a outer SignerData object. 291 Before processing a receiptRequest signedAttribute, the receiving 292 agent MUST verify the following conditions: 294 1. The signature of the SignerInfo that covers the receiptRequest 295 attribute MUST validate. 297 2. All receiptRequests for SignerInfo objects in the current 298 SignedData object MUST be the same. (Since the attributes are DER 299 encoded, this check can be done by a binary compare of the 300 attributes.) 302 3. The encapsulated content of the message MUST NOT contain a 303 SignedData for which a receiptRequest exists. 305 4. The inner-most encapsulated content of the message MUST NOT be 306 id-ct-receipt. 308 A receipt MUST NOT be created of any of these conditions are not met. 310 If a receiptRequest attribute is absent from the signed attributes, 311 then a signed receipt has not been requested from any of the message 312 recipients and MUST NOT be created. If a receiptRequest attribute is 313 present in the signed attributes, then a signed receipt has been 314 requested from some or all of the message recipients. Note that in 315 some cases, a receiving agent might receive two almost-identical 316 messages, one with a receipt request and the other without one. In 317 this case, the receiving agent SHOULD send a signed receipt for the 318 message that requests a signed receipt. 320 If a receiptRequest attribute is present in the signed attributes, 321 the following process SHOULD be used to determine if a message 322 recipient has been requested to return a signed receipt. 324 1. If a receiptPolicy attribute is present in the SignedData block, 325 do one of the following two steps value of ReceiptPolicy: 327 Schaad 6 328 RFC2634Update August 2004 330 1.1. If the ReceiptPolicy value is none, then the receipt policy 331 supersedes the originator's request for a signed receipt and 332 a signed receipt MUST NOT be created. 334 1.2. If the ReceiptPolicy value is insteadOf or inAdditionTo, the 335 processing software SHOULD examine the receiptsFrom value 336 from the receiptRequest attribute to determine if a receipt 337 should be created and returned. If a receipt is created, the 338 insteadOf and inAdditionTo fields identify entities that 339 SHOULD be sent the receipt instead of or in addition to the 340 originator. 342 2. If the receiptsFrom value of the receiptRequest attribute 343 allOrFirstTier, do one of the following two steps based on the 344 value of allOrFirstTier. 346 2.1. If the value of allOrFirstTier is allReceipts, then a signed 347 receipt SHOULD be created. 349 2.2. If the value of allOrFirstTier is firstTierRecipients, do 350 one of the following two steps based on the presence of an 351 mlaExpandHistory attribute in an outer SignedData block: 353 2.2.1. If an mlaExpandHistory attribute is present, then this 354 recipient is not a first tier recipient and a signed 355 receipt MUST NOT be created. 357 2.2.2. If an mlaExpandHistory attribute is not present, then 358 a signed receipt SHOULD be created. 360 3. If the receiptsFrom value of the receiptRequest attribute is a 361 receiptList: 363 3.1. If receiptList contains one of the GeneralNames of the 364 recipient, then a signed receipt SHOULD be created. 366 3.2. If receiptList does not contain one of the GeneralNames of 367 the recipient, then a signed receipt MUST NOT be created. 369 A flow chart for the above steps to be executed for each signerInfo 370 for which the receiving agent verifies the signature would be: 372 0. Receipt Request attribute present? 373 YES -> 1. 374 NO -> STOP 375 1. Does an outer SignedData layer exist? 376 YES -> 1.1. 377 NO -> 4. 378 1.1. Make next SignedData layer out the current layer. 379 2. Current layer has a receiptPolicy attribute? 380 YES -> 2.1. 381 NO -> 3. 382 2.1. Modify receiptsTo based on ReceiptPolicy 384 Schaad 7 385 RFC2634Update August 2004 387 2.2. Go to 3. 388 3. Current layer has an mlaExpandHistory attribute? 389 YES -> 3.1 390 NO -> 1. 391 3.1. Is value of receiptsFrom allOrFirstTier? 392 YES -> Pick based on value of allOrFirstTier. 393 allReceipts -> 1. 394 firstTierReceipts -> 3.2. 395 NO -> 1. 396 3.2. Set receiptsFrom to none. 397 3.3. Go to 1. 398 4. Is receiptsFrom value a receiptList? 399 YES -> 4.1. 400 NO -> 4.2. 401 4.1. Does receipList contain the recipient? 402 YES -> 4.2. 403 NO -> STOP. 404 4.2. Create a receipt. 405 4.3. STOP. 407 2.4 Signed Receipt Creation 409 A signed receipt is a SignedData object encapsulating a Receipt 410 content (also called a "SignedData/Receipt"). Signed receipts are 411 created as follows: 413 1. The signature of the original SignedData signerInfo that includes 414 the receiptRequest signed attribute MUST be successfully verified 415 before creating the SignedData/Receipt. 417 1.1. The content of the original SignedData object is digested as 418 described in [CMS]. The resulting digest value is then 419 compared with the value of the messageDigest attribute 420 included in the signedAttrs of the original SignedData 421 signerInfo. If these digest values are different, then the 422 signature verification process fails and the 423 SignedData/Receipt MUST NOT be created. 425 1.2. The ASN.1 DER encoded signedAttrs (including messageDigest, 426 receiptRequest and, possibly, other signed attributes) in the 427 original SignedData signerInfo are digested as described in 428 [CMS]. The resulting digest value, called msgSigDigest, is 429 then used to verify the signature of the original SignedData 430 signerInfo. If the signature verification fails, then the 431 SignedData/Receipt MUST NOT be created. 433 2. A Receipt structure is created. 435 2.1. The value of the Receipt version field is set to 1. 437 2.2. The object identifier from the contentType attribute included 438 in the original SignedData SignerInfo that includes the 440 Schaad 8 441 RFC2634Update August 2004 443 receiptRequest attribute is copied into the Receipt 444 contentType. 446 2.3. The original SignedData signerInfo receiptRequest 447 signedContentIdentifier is copied into the Receipt 448 signedContentIdentifier. 450 2.4. The signature value from the original SignedData signerInfo 451 that includes the receiptRequest attribute is copied into the 452 Receipt originatorSignatureValue. 454 3. The Receipt structure is ASN.1 DER encoded to produce a data 455 stream, D1. 457 4. D1 is digested. The resulting digest value is included as the 458 messageDigest attribute in the signedAttrs of the SignerInfo which 459 will eventually contain the SignedData/Receipt signature value. 461 5. The digest value (msgSigDigest) calculated in Step 1 to verify the 462 signature of the original SignedData SignerInfo is included as the 463 msgSigDigest attribute in the signedAttrs of a SignerInfo which 464 will eventually contain the SignedData/Receipt signature value. 466 6. A contentType attribute including the id-ct-receipt object 467 identifier MUST be created and added to the signed attributes of 468 the signerInfo which will eventually contain the 469 SignedData/Receipt signature value. 471 7. A signingTime attribute indicating the time that the 472 SignedData/Receipt is signed SHOULD be created and added to the 473 signed attributes of the SignerInfo which will eventually contain 474 the SignedData/Receipt signature value. Other attributes (except 475 receiptRequest) can be added to the signedAttrs of the SignerInfo. 477 8. The signedAttrs (messageDigest, msgSigDigest, contentType, and 478 possibly others) of the SignerInfo are ASN.1 DER encoded and 479 digested as described in [CMS]. The resulting digest value is used 480 to calculate the signature value which is then included in the 481 SignedData/Receipt signerInfo. 483 9. The ASN.1 DER encoded Receipt content MUST be directly encoded 484 within the SignedData EncapContentInfo.eContent OCTET STRING 485 defined in [CMS]. The id-ct-receipt object identifier MUST be 486 included in the SignedData EncapContentInfo.eContentType. This 487 results in a single ASN.1 encoded object composed of a SignedData 488 including the Receipt content. The Data content type MUST NOT be 489 used. The Receipt content MUST NOT be encapsulated in a MIME 490 header or any other header prior to being encoded as part of the 491 SignedData object. 493 10. The SignedData/Receipt is then put in an application/pkcs7-mime 494 MIME wrapper with the smime-type parameter set to "signed- 495 receipt". This will allow for identification of signed receipts 497 Schaad 9 498 RFC2634Update August 2004 500 without having to crack the ASN.1 body. The smime-type parameter 501 would still be set as normal in any layer wrapped around this 502 message. 504 11. If the SignedData/Receipt is to be encrypted within an 505 EnvelopedData object, then an outer SignedData object MUST be 506 created that encapsulates the EnvelopedData object, and a 507 contentHints attribute with contentType set to the id-ct-receipt 508 object identifier MUST be included in the outer SignedData 509 SignerInfo signedAttrs. When a receiving agent processes the 510 outer SignedData object, the presence of the id-ct-receipt OID in 511 the contentHints contentType indicates that a SignedData/Receipt 512 is encrypted within the EnvelopedData object encapsulated by the 513 outer SignedData. 515 All sending agents that support the generation of ESS signed receipts 516 MUST provide the ability to send encrypted signed receipts (that is, 517 a SignedData/Receipt encapsulated within an EnvelopedData). The 518 sending agent MAY send an encrypted signed receipt in response to an 519 EnvelopedData-encapsulated SignedData requesting a signed receipt. It 520 is a matter of local policy regarding whether or not the signed 521 receipt should be encrypted. The ESS signed receipt includes the 522 message digest value calculated for the original SignedData object 523 that requested the signed receipt. If the original SignedData object 524 was sent encrypted within an EnvelopedData object and the ESS signed 525 receipt is sent unencrypted, then the message digest value calculated 526 for the original encrypted SignedData object is sent unencrypted. The 527 responder should consider this when deciding whether or not to 528 encrypt the ESS signed receipt. 530 2.4.1 MLExpansionHistory Attributes and Receipts 532 An MLExpansionHistory attribute MUST NOT be included in the 533 attributes of a SignerInfo in a SignedData object that encapsulates a 534 Receipt content. This is true because when a SignedData/Receipt is 535 sent to an MLA for distribution, then the MLA MUST always encapsulate 536 the received SignedData/Receipt in an outer SignedData in which the 537 MLA will include the MLExpansionHistory attribute. The MLA cannot 538 change the signedAttrs of the received SignedData/Receipt object, so 539 it can't add the MLExpansionHistory to the SignedData/Receipt. 541 2.5 Determining the Recipients of the Signed Receipt 543 If a signed receipt was created by the process described in the 544 sections above, then the software MUST use the following process to 545 determine to whom the signed receipt should be sent. 547 1. The receiptsTo field must be present in the receiptRequest 548 attribute. The software initiates the sequence of recipients with 549 the value(s) of receiptsTo. 551 2. If the receiptPolicy attribute is present in the outer SignedData 552 block and contains a value of insteadOf, then the software 554 Schaad 10 555 RFC2634Update August 2004 557 replaces the sequence of recipients with the value(s) of 558 insteadOf. 560 3. If the receiptPolicy attribute is present in the outer SignedData 561 block and contains a value of inAdditionTo, then the software adds 562 the value(s) of inAdditionTo to the sequence of recipients. 564 2.6. Signed Receipt Validation 566 A signed receipt is communicated as a single ASN.1 encoded object 567 composed of a SignedData object directly including a Receipt content. 568 It is identified by the presence of the id-ct-receipt object 569 identifier in the encapContentInfo eContentType value of the 570 SignedData object including the Receipt content. 572 Although recipients are not supposed to send more than one signed 573 receipt, receiving agents SHOULD be able to accept multiple signed 574 receipts from a recipient. 576 A SignedData/Receipt is validated as follows: 578 1. ASN.1 decode the SignedData object including the Receipt content. 580 2. Extract the contentType, signedContentIdentifier, and 581 originatorSignatureValue from the decoded Receipt structure to 582 identify the original SignedData signerInfo that requested the 583 SignedData/Receipt. 585 3. Acquire the message signature digest value calculated by the 586 sender to generate the signature value included in the original 587 SignedData signerInfo that requested the SignedData/Receipt. 589 1.1. If the sender-calculated message signature digest value has 590 been saved locally by the sender, it needs be located and 591 retrieved. 593 2.2. If it has not been saved, then it needs be re-calculated 594 based on the original SignedData content and signedAttrs as 595 described in [CMS]. 597 4. The message signature digest value calculated by the sender is 598 then compared with the value of the msgSigDigest signedAttribute 599 included in the SignedData/Receipt signerInfo. If these digest 600 values are identical, then that proves that the message signature 601 digest value calculated by the recipient based on the received 602 original SignedData object is the same as that calculated by the 603 sender. This proves that the recipient received exactly the same 604 original SignedData content and signedAttrs as sent by the sender 605 because that is the only way that the recipient could have 606 calculated the same message signature digest value as calculated 607 by the sender. If the digest values are different, then the 608 SignedData/Receipt signature verification process fails. 610 Schaad 11 611 RFC2634Update August 2004 613 7. Acquire the digest value calculated by the sender for the Receipt 614 content constructed by the sender (including the contentType, 615 signedContentIdentifier, and signature value that were included in 616 the original SignedData signerInfo that requested the 617 SignedData/Receipt). 619 5.1. If the sender-calculated Receipt content digest value has 620 been saved locally by the sender, it needs be located and 621 retrieved. 623 5.2. If it has not been saved, then it needs be re-calculated. As 624 described in section above, step 2, create a Receipt 625 structure including the contentType, signedContentIdentifier 626 and signature value that were included in the original 627 SignedData signerInfo that requested the signed receipt. The 628 Receipt structure is then ASN.1 DER encoded to produce a 629 data stream which is then digested to produce the Receipt 630 content digest value. 632 6. The Receipt content digest value calculated by the sender is then 633 compared with the value of the messageDigest signedAttribute 634 included in the SignedData/Receipt signerInfo. If these digest 635 values are identical, then that proves that the values included in 636 the Receipt content by the recipient are identical to those that 637 were included in the original SignedData signerInfo that requested 638 the SignedData/Receipt. This proves that the recipient received 639 the original SignedData signed by the sender, because that is the 640 only way that the recipient could have obtained the original 641 SignedData signerInfo signature value for inclusion in the Receipt 642 content. If the digest values are different, then the 643 SignedData/Receipt signature verification process fails. 645 7. The ASN.1 DER encoded signedAttrs of the SignedData/Receipt 646 signerInfo are digested as described in [CMS]. 648 8. The resulting digest value is then used to verify the signature 649 value included in the SignedData/Receipt signerInfo. If the 650 signature verification is successful, then that proves the 651 integrity of the SignedData/receipt signerInfo signedAttrs and 652 authenticates the identity of the signer of the SignedData/Receipt 653 signerInfo. Note that the signedAttrs include the recipient- 654 calculated Receipt content digest value (messageDigest attribute) 655 and recipient-calculated message signature digest value 656 (msgSigDigest attribute). Therefore, the aforementioned comparison 657 of the sender-generated and recipient-generated digest values 658 combined with the successful SignedData/Receipt signature 659 verification proves that the recipient received the exact original 660 SignedData content and signedAttrs (proven by msgSigDigest 661 attribute) that were signed by the sender of the original 662 SignedData object (proven by messageDigest attribute). If the 663 signature verification fails, then the SignedData/Receipt 664 signature verification process fails. 666 Schaad 12 667 RFC2634Update August 2004 669 The signature verification process for each signature algorithm that 670 is used in conjunction with the CMS protocol is specific to the 671 algorithm. These processes are described in documents specific to 672 the algorithms. 674 2.7 Receipt Request Syntax 676 A receiptRequest attribute value has ASN.1 type ReceiptRequest. Use 677 the receiptRequest attribute only within the signed attributes 678 associated with a signed message. 680 ReceiptRequest ::= SEQUENCE { 681 signedContentIdentifier ContentIdentifier, 682 receiptsFrom ReceiptsFrom, 683 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo)) OF GeneralNames } 685 ub-receiptsTo INTEGER ::= 16 687 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 688 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 690 ContentIdentifier ::= OCTET STRING 692 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 693 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 695 A signedContentIdentifier MUST be created by the message originator 696 when creating a receipt request. To ensure global uniqueness, the 697 minimal signedContentIdentifier SHOULD contain a concatenation of 698 user-specific identification information (such as a user name or 699 public keying material identification information), a GeneralizedTime 700 string, and a random number. 702 The receiptsFrom field is used by the originator to specify the 703 recipients requested to return a signed receipt. A CHOICE is provided 704 to allow specification of: 706 - receipts from all recipients are requested 707 - receipts from first tier (recipients that did not receive 708 themessage as members of a mailing list) recipients are requested 709 - receipts from a specific list of recipients are requested 711 ReceiptsFrom ::= CHOICE { 712 allOrFirstTier [0] AllOrFirstTier, 713 -- formerly "allOrNone [0]AllOrNone" 714 receiptList [1] SEQUENCE OF GeneralNames } 716 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 717 allReceipts (0), 718 firstTierRecipients (1) } 720 The receiptsTo field is used by the originator to identify the 721 user(s) to whom the identified recipient needs to send signed 723 Schaad 13 724 RFC2634Update August 2004 726 receipts. The message originator MUST populate the receiptsTo field 727 with a GeneralNames for each entity to whom the recipient is suppose 728 to send the signed receipt. If the message originator wants the 729 recipient to send the signed receipt to the originator, then the 730 originator MUST include a GeneralNames for itself in the receiptsTo 731 field. 733 2.8 Receipt Policy Syntax 735 Various entities can modify how receipt processing is done; this is 736 accomplished by adding a receiptPolicy attribute to a signature 737 layer. A receiptPolicy attribute has an ASN.1 type of ReceiptPolicy. 738 Use the receiptPolicy attribute only within the signed attributes 739 associated with a signed message. 741 ReceiptPolicy ::= CHOICE { 742 none [0] NULL, 743 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 744 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 746 id-aa-receiptPolicy OBJECT IDENTIFIER ::= {id-aa XX} 748 2.8.1 Receipt Policy Combining 750 There are circumstances where multiple receiptPolicy attributes need 751 to be combined together. (One example is during MLA processing where 752 multiple signature layers are removed.) This section gives the rules 753 for combining two attributes. Attribute A is the inner of the two 754 receiptPolicy attributes. The final result of combining two policies 755 together should be the same as if the two policies were processed in 756 sequence. 758 The following table describes the outcome of the union of 759 ReceiptPolicy A (the rows in the table) and ReceiptPolicy B (the 760 columns in the table). 762 | B's policy 763 A's policy | none insteadOf inAdditionTo 764 -------------------------------------------------- 765 none | none none none 766 insteadOf | none insteadOf(B) *1 767 inAdditionTo | none insteadOf(B) *2 769 *1 = insteadOf(insteadOf(A) + inAdditionTo(B)) 770 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) 772 2.8 Receipt Syntax 774 Receipts are represented using a new content type, Receipt. The 775 Receipt content type SHALL have ASN.1 type Receipt. Receipts MUST be 776 encapsulated within a SignedData message. 778 Schaad 14 779 RFC2634Update August 2004 781 Receipt ::= SEQUENCE { 782 version ESSVersion, 783 contentType ContentType, 784 signedContentIdentifier ContentIdentifier, 785 originatorSignatureValue OCTET STRING } 787 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 788 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 790 ESSVersion ::= INTEGER { v1(1) } 792 The version field defines the syntax version number, which is 1 for 793 this version of the standard. 795 2.9 Content Hints 797 Many applications find it useful to have information that describes 798 the innermost signed content of a multi-layer message available on 799 the outermost signature layer. The contentHints attribute provides 800 such information. 802 Content-hints attribute values have ASN.1 type contentHints. 804 ContentHints ::= SEQUENCE { 805 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 806 contentType ContentType } 808 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) 809 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 811 The contentDescription field is used to provide information that the 812 recipient can use to select protected messages for processing, such 813 as a message subject. If this field is set, then the attribute is 814 expected to appear on the SignedData object enclosing an 815 EnvelopedData object and not on the inner SignedData object. The 816 (SIZE (1..MAX)) construct constrains the sequence to have at least 817 one entry. MAX indicates the upper bound is unspecified. 818 Implementations are free to choose an upper bound that suits their 819 environment. 821 Messages that contain a SignedData object wrapped around an 822 EnvelopedData object, thus masking the inner content type of the 823 message, SHOULD include a contentHints attribute, except for the case 824 of the data content type. Specific message content types can either 825 force or preclude the inclusion of the contentHints attribute. For 826 example, when a SignedData/Receipt is encrypted within an 827 EnvelopedData object, an outer SignedData object MUST be created that 828 encapsulates the EnvelopedData object and a contentHints attribute 829 with contentType set to the id-ct-receipt object identifier MUST be 830 included in the outer SignedData SignerInfo signedAttrs. 832 2.10 Message Signature Digest Attribute 834 Schaad 15 835 RFC2634Update August 2004 837 The msgSigDigest attribute can only be used in the signed attributes 838 of a signed receipt. It contains the digest of the ASN.1 DER encoded 839 signedAttrs included in the original SignedData that requested the 840 signed receipt. Only one msgSigDigest attribute can appear in a 841 signed attributes set. It is defined as follows: 843 msgSigDigest ::= OCTET STRING 845 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 846 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 848 2.11 Signed Content Reference Attribute 850 The contentReference attribute is a link from one SignedData to 851 another. It is used to link a reply to the original message to which 852 it refers, or to incorporate by reference one SignedData into 853 another. The first SignedData MUST include a contentIdentifier signed 854 attribute, which SHOULD be constructed as specified in section 2.7. 855 The second SignedData links to the first by including a 856 ContentReference signed attribute containing the content type, 857 content identifier, and signature value from the first SignedData. 859 ContentReference ::= SEQUENCE { 860 contentType ContentType, 861 signedContentIdentifier ContentIdentifier, 862 originatorSignatureValue OCTET STRING } 864 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member- 865 body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 866 10 } 868 4. Mail List Management 870 Sending agents need to create recipient-specific data structures for 871 each recipient of an encrypted message. This process can impair 872 performance for messages sent to a large number of recipients. Thus, 873 Mail List Agents (MLAs) that can take a single message and perform 874 the recipient-specific encryption for every recipient are often 875 desired. 877 An MLA appears to the message originator as a normal message 878 recipient, but the MLA acts as a message expansion point for a Mail 879 List (ML). The sender of a message directs the message to the MLA, 880 which then redistributes the message to the members of the ML. This 881 process offloads the per-recipient processing from individual user 882 agents and allows for more efficient management of large MLs. MLs are 883 true message recipients served by MLAs that provide cryptographic and 884 expansion services for the mailing list. 886 In addition to cryptographic handling of messages, secure mailing 887 lists also have to prevent mail loops. A mail loop is where one 889 Schaad 16 890 RFC2634Update August 2004 892 mailing list is a member of a second mailing list, and the second 893 mailing list is a member of the first. A message will go from one 894 list to the other in a rapidly-cascading succession of mail that will 895 be distributed to all other members of both lists. 897 To prevent mail loops, MLAs use the mlaExpandHistory attribute of the 898 outer signature of a triple wrapped message. The mlaExpandHistory 899 attribute is essentially a list of every MLA that has processed the 900 message. If an MLA sees its own unique entity identifier in the list, 901 it knows that a loop has been formed, and does not send the message 902 to the list again. 904 4.1 Mail List Expansion 906 Mail list expansion processing is noted in the value of the 907 mlaExpandHistory attribute, located in the signed attributes of the 908 MLA's SignerInfo block. The MLA creates or updates the signed 909 mlaExpandHistory attribute value each time the MLA expands and signs 910 a message for members of a mail list. 912 The MLA MUST add an MLAData record containing the MLA's 913 identification information, date and time of expansion to the end of 914 the mail list expansion history sequence. If the mlaExpandHistory 915 attribute is absent, then the MLA MUST add the attribute and the 916 current expansion becomes the first element of the sequence. If the 917 mlaExpandHistory attribute is present, then the MLA MUST add the 918 current expansion information to the end of the existing 919 MLAExpandHistory sequence. Only one mlaExpandHistory attribute can be 920 included in the signedAttrs of a SignerInfo. 922 Note that if the mlaExpandHistory attribute is absent, then the 923 recipient is a first tier message recipient. 925 There can be multiple SignerInfos within a SignedData object, and 926 each SignerInfo can include signedAttrs. Therefore, a single 927 SignedData object can include multiple SignerInfos, each SignerInfo 928 having an mlaExpandHistory attribute. For example, an MLA can send a 929 signed message with two SignerInfos, one containing a DSS signature, 930 the other containing an RSA signature. 932 If an MLA creates a SignerInfo that includes an mlaExpandHistory 933 attribute, then all of the SignerInfos created by the MLA for that 934 SignedData object MUST include an mlaExpandHistory attribute, and the 935 value of each MUST be identical. Note that other agents might later 936 add SignerInfo attributes to the SignedData block, and those 937 additional SignerInfos might not include mlaExpandHistory attributes. 939 A recipient MUST verify the signature of the SignerInfo that covers 940 the mlaExpandHistory attribute before processing the 941 mlaExpandHistory, and MUST NOT process the mlaExpandHistory attribute 942 unless the signature over it has been verified. If a SignedData 943 object has more than one SignerInfo that has an mlaExpandHistory 944 attribute, the recipient MUST compare the mlaExpandHistory attributes 946 Schaad 17 947 RFC2634Update August 2004 949 in all the SignerInfos that it has verified, and MUST NOT process the 950 mlaExpandHistory attribute unless every verified mlaExpandHistory 951 attribute in the SignedData block is identical. If the 952 mlaExpandHistory attributes in the verified signerInfos are not all 953 identical, then the receiving agent MUST stop processing the message 954 and SHOULD notify the user or MLA administrator of this error 955 condition. In the mlaExpandHistory processing, SignerInfos that do 956 not have an mlaExpandHistory attribute are ignored. 958 4.1.1 Detecting Mail List Expansion Loops 960 Prior to expanding a message, the MLA examines the value of any 961 existing mlaExpandHistory attribute to detect an expansion loop. An 962 expansion loop exists when a message expanded by a specific MLA for a 963 specific mail list is redelivered to the same MLA for the same mail 964 list. 966 Expansion loops are detected by examining the mailListIdentifier 967 field of each MLAData entry found in the mlaExpandHistory. If an MLA 968 finds its own identification information, then the MLA must 969 discontinue expansion processing and should provide warning of an 970 expansion loop to a human mail list administrator. The mail list 971 administrator is responsible for correcting the loop condition. 973 4.2 Mail List Agent Processing 975 The first few paragraphs of this section provide a high-level 976 description of MLA processing. The rest of the section provides a 977 detailed description of MLA processing. 979 MLA message processing depends on the structure of the S/MIME layers 980 in the message sent to the MLA for expansion. In addition to sending 981 triple wrapped messages to an MLA, an entity can send other types of 982 messages to an MLA, such as: 984 - a single wrapped SignedData or EnvelopedData message 985 - a double wrapped message (such as signed and enveloped, 986 envelopedand signed, or signed and signed, and so on) 987 - a quadruple-wrapped message (such as if a well-formed triple 988 wrapped message was sent through a gateway that added an outer 989 SignedData layer) 991 In all cases, the MLA MUST parse all layers of the received message 992 to determine if there are any SignedData layers that include an 993 eSSSecurityLabel signedAttribute. This can include decrypting an 994 EnvelopedData layer to determine if an encapsulated SignedData layer 995 includes an eSSSecurityLabel attribute. The MLA MUST fully process 996 each eSSSecurityLabel attribute found in the various SignedData 997 layers, including performing access control checks, before 998 distributing the message to the ML members. The details of the access 999 control checks are beyond the scope of this document. The MLA MUST 1000 verify the signature of the signerInfo including the eSSSecurityLabel 1001 attribute before using it. 1003 Schaad 18 1004 RFC2634Update August 2004 1006 In all cases, the MLA MUST sign the message to be sent to the ML 1007 members in a new "outer" SignedData layer. The MLA MUST add or update 1008 an mlaExpandHistory attribute in the "outer" SignedData that it 1009 creates to document MLA processing. If there was an "outer" 1010 SignedData layer included in the original message received by the 1011 MLA, then the MLA-created "outer" SignedData layer MUST include each 1012 signed attribute present in the original "outer" SignedData layer, 1013 unless the MLA explicitly replaces an attribute (such as signingTime 1014 or mlaExpandHistory) with a new value. 1016 When an S/MIME message is received by the MLA, the MLA MUST first 1017 determine which received SignedData layer, if any, is the "outer" 1018 SignedData layer. To identify the received "outer" SignedData layer, 1019 the MLA MUST verify the signature and fully process the signedAttrs 1020 in each of the outer SignedData layers (working from the outside in) 1021 to determine if any of them either include an mlaExpandHistory 1022 attribute or encapsulate an EnvelopedData object. 1024 The MLA's search for the "outer" SignedData layer is completed when 1025 it finds one of the following: 1027 - the "outer" SignedData layer that includes an mlaExpandHistory 1028 attribute or encapsulates an EnvelopedData object 1029 - an EnvelopedData layer 1030 - the original content (that is, a layer that is neither 1031 EnvelopedData nor SignedData). 1033 If the MLA finds an "outer" SignedData layer, then the MLA MUST 1034 perform the following steps: 1036 1. Strip off all of the SignedData layers that encapsulated the 1037 "outer" SignedData layer 1039 2. Strip off the "outer" SignedData layer itself (after remembering 1040 the included signedAttrs) 1042 3. Expand the EnvelopedData (if present) 1044 4. Sign the message to be sent to the ML members in a new "outer" 1045 SignedData layer that includes the signedAttrs (unless explicitly 1046 replaced) from the original, received "outer" SignedData layer. 1048 If the MLA finds an "outer" SignedData layer that includes an 1049 mlaExpandHistory attribute AND the MLA subsequently finds an 1050 EnvelopedData layer buried deeper with the layers of the received 1051 message, then the MLA MUST strip off all of the SignedData layers 1052 down to the EnvelopedData layer (including stripping off the original 1053 "outer" SignedData layer) and MUST sign the expanded EnvelopedData in 1054 a new "outer" SignedData layer that includes the signedAttrs (unless 1055 explicitly replaced) from the original, received "outer" SignedData 1056 layer. 1058 Schaad 19 1059 RFC2634Update August 2004 1061 If the MLA does not find an "outer" SignedData layer and does not 1062 find an EnvelopedData layer, then the MLA MUST sign the original, 1063 received message in a new "outer" SignedData layer. If the MLA does 1064 not find an "outer" SignedData and does find an EnvelopedData layer 1065 then it MUST expand the EnvelopedData layer, if present, and sign it 1066 in a new "outer" SignedData layer. 1068 4.2.1 Examples of Rule Processing 1070 The following examples help explain the rules above: 1072 1) A message (S1(Original Content)) (where S = SignedData) is sent to 1073 the MLA in which the SignedData layer does not include an 1074 mlaExpandHistory attribute. The MLA verifies and fully processes 1075 the signedAttrs in S1. The MLA decides that there is not an 1076 original, received "outer" SignedData layer since it finds the 1077 original content, but never finds an EnvelopedData and never finds 1078 an mlaExpandHistory attribute. The MLA calculates a new SignedData 1079 layer, S2, resulting in the following message sent to the ML 1080 recipients: (S2(S1(Original Content))). The MLA includes an 1081 mlaExpandHistory attribute in S2. 1083 2) A message (S3(S2(S1(Original Content)))) is sent to the MLA in 1084 which none of the SignedData layers includes an mlaExpandHistory 1085 attribute. The MLA verifies and fully processes the signedAttrs in 1086 S3, S2 and S1. The MLA decides that there is not an original, 1087 received "outer" SignedData layer since it finds the original 1088 content, but never finds an EnvelopedData and never finds an 1089 mlaExpandHistory attribute. The MLA calculates a new SignedData 1090 layer, S4, resulting in the following message sent to the ML 1091 recipients: (S4(S3(S2(S1(Original Content))))). The MLA includes 1092 an mlaExpandHistory attribute in S4. 1094 3) A message (E1(S1(Original Content))) (where E = EnvelopedData) is 1095 sent to the MLA in which S1 does not include an MLAExpandHistory 1096 attribute. The MLA decides that there is not an original, received 1097 "outer" SignedData layer since it finds the E1 as the outer layer. 1098 The MLA expands the recipientInformation in E1. The MLA calculates 1099 a new SignedData layer, S2, resulting in the following message 1100 sent to the ML recipients: (S2(E1(S1(Original Content)))). The MLA 1101 includes an mlaExpandHistory attribute in S2. 1103 4) A message (S2(E1(S1(Original Content)))) is sent to the MLA in 1104 which S2 includes an mlaExpandHistory attribute. The MLA verifies 1105 the signature and fully processes the signedAttrs in S2. The MLA 1106 finds the mlaExpandHistory attribute in S2, so it decides that S2 1107 is the "outer" SignedData. The MLA remembers the signedAttrs 1108 included in S2 for later inclusion in the new outer SignedData 1109 that it applies to the message. The MLA strips off S2. The MLA 1110 then expands the recipientInformation in E1 (this invalidates the 1111 signature in S2 which is why it was stripped). The MLA calculates 1112 a new SignedData layer, S3, resulting in the following message 1113 sent to the ML recipients: (S3(E1(S1(Original Content)))). The MLA 1115 Schaad 20 1116 RFC2634Update August 2004 1118 includes in S3 the attributes from S2 (unless it specifically 1119 replaces an attribute value) including an updated mlaExpandHistory 1120 attribute. 1122 5) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in 1123 which none of the SignedData layers include an mlaExpandHistory 1124 attribute. The MLA verifies the signature and fully processes the 1125 signedAttrs in S3 and S2. When the MLA encounters E1, then it 1126 decides that S2 is the "outer" SignedData since S2 encapsulates 1127 E1. The MLA remembers the signedAttrs included in S2 for later 1128 inclusion in the new outer SignedData that it applies to the 1129 message. The MLA strips off S3 and S2. The MLA then expands the 1130 recipientInformation in E1 (this invalidates the signatures in S3 1131 and S2 which is why they were stripped). The MLA calculates a new 1132 SignedData layer, S4, resulting in the following message sent to 1133 the ML recipients: (S4(E1(S1(Original Content)))). The MLA 1134 includes in S4 the attributes from S2 (unless it specifically 1135 replaces an attribute value) and includes a new mlaExpandHistory 1136 attribute. 1138 6) A message (S3(S2(E1(S1(Original Content))))) is sent to the MLA in 1139 which S3 includes an mlaExpandHistory attribute. In this case, the 1140 MLA verifies the signature and fully processes the signedAttrs in 1141 S3. The MLA finds the mlaExpandHistory in S3, so it decides that 1142 S3 is the "outer" SignedData. The MLA remembers the signedAttrs 1143 included in S3 for later inclusion in the new outer SignedData 1144 that it applies to the message. The MLA keeps on parsing 1145 encapsulated layers because it must determine if there are any 1146 eSSSecurityLabel attributes contained within. The MLA verifies the 1147 signature and fully processes the signedAttrs in S2. When the MLA 1148 encounters E1, then it strips off S3 and S2. The MLA then expands 1149 the recipientInformation in E1 (this invalidates the signatures in 1150 S3 and S2 which is why they were stripped). The MLA calculates a 1151 new SignedData layer, S4, resulting in the following message sent 1152 to the ML recipients: (S4(E1(S1(Original Content)))). The MLA 1153 includes in S4 the attributes from S3 (unless it specifically 1154 replaces an attribute value) including an updated mlaExpandHistory 1155 attribute. 1157 4.2.3 Processing Choices 1159 The processing used depends on the type of the outermost layer of the 1160 message. There are three cases for the type of the outermost data: 1162 - EnvelopedData 1163 - SignedData 1164 - data 1166 4.2.3.1 Processing for EnvelopedData 1168 1. The MLA locates its own RecipientInfo and uses the information it 1169 contains to obtain the message key. 1171 Schaad 21 1172 RFC2634Update August 2004 1174 2. The MLA removes the existing recipientInfos field and replaces it 1175 with a new recipientInfos value built from RecipientInfo 1176 structures created for each member of the mailing list. The MLA 1177 also removes the existing originatorInfo field and replaces it 1178 with a new originatorInfo value built from information describing 1179 the MLA. 1181 3. The MLA encapsulates the expanded encrypted message in a 1182 SignedData block, adding an mlExpandHistory attribute as described 1183 in the "Mail List Expansion" section to document the expansion. 1185 4. The MLA signs the new message and delivers the updated message to 1186 mail list members to complete MLA processing. 1188 4.2.3.2 Processing for SignedData 1190 MLA processing of multi-layer messages depends on the type of data in 1191 each of the layers. Step 3 below specifies that different processing 1192 will take place depending on the type of CMS message that has been 1193 signed. That is, it needs to know the type of data at the next inner 1194 layer, which may or may not be the innermost layer. 1196 1. The MLA verifies the signature value found in the outermost 1197 SignedData layer associated with the signed data. MLA processing of 1198 the message terminates if the message signature is invalid. 1200 2. If the outermost SignedData layer includes a signed 1201 mlaExpandHistory attribute, the MLA checks for an expansion loop as 1202 described in the "Detecting Mail List Expansion Loops" section, 1203 then go to step 3. If the outermost SignedData layer does not 1204 include a signed mlaExpandHistory attribute, the MLA signs the 1205 whole message (including this outermost SignedData layer that 1206 doesn't have an mlaExpandHistory attribute), and delivers the 1207 updated message to mail list members to complete MLA processing. 1209 3. Determine the type of the data that has been signed. That is, look 1210 at the type of data on the layer just below the SignedData, which 1211 may or may not be the "innermost" layer. Based on the type of data, 1212 perform either step 3.1 (EnvelopedData), step 3.2 (SignedData), or 1213 step 3.3 (all other types). 1215 3.1. If the signed data is EnvelopedData, the MLA performs 1216 expansion processing of the encrypted message as described 1217 previously. Note that this process invalidates the signature 1218 value in the outermost SignedData layer associated with the 1219 original encrypted message. Proceed to section 3.2 with the 1220 result of the expansion. 1222 3.2. If the signed data is SignedData, or is the result of 1223 expanding an EnvelopedData block in step 3.1: 1225 Schaad 22 1226 RFC2634Update August 2004 1228 3.2.1. The MLA strips the existing outermost SignedData layer 1229 after remembering the value of the mlaExpandHistory and all 1230 other signed attributes in that layer, if present. 1232 3.2.2. If the signed data is EnvelopedData (from step 3.1), the 1233 MLA encapsulates the expanded encrypted message in a new 1234 outermost SignedData layer. On the other hand, if the signed 1235 data is SignedData (from step 3.2), the MLA encapsulates the 1236 signed data in a new outermost SignedData layer. 1238 3.2.3. The outermost SignedData layer created by the MLA 1239 replaces the original outermost SignedData layer. The MLA 1240 MUST create a signed attribute list for the new outermost 1241 SignedData layer which MUST include each signed attribute 1242 present in the original outermost SignedData layer, unless 1243 the MLA explicitly replaces one or more particular attributes 1244 with new value. A special case is the mlaExpandHistory 1245 attribute. The MLA MUST add an mlaExpandHistory signed 1246 attribute to the outer SignedData layer as follows: 1248 3.2.3.1. If the original outermost SignedData layer included 1249 an mlaExpandHistory attribute, the attribute's value is 1250 copied and updated with the current ML expansion 1251 information as described in the "Mail List Expansion" 1252 section. 1254 3.2.3.2. If the original outermost SignedData layer did not 1255 include an mlaExpandHistory attribute, a new attribute 1256 value is created with the current ML expansion 1257 information. 1259 3.3. If the signed data is not EnvelopedData or SignedData: 1261 3.3.1. The MLA encapsulates the received SignedData object in an 1262 outer SignedData object, and adds an mlaExpandHistory 1263 attribute to the outer SignedData object containing the 1264 current ML expansion information as described in the "Mail 1265 List Expansion" section. 1267 4. The MLA signs the new message and delivers the updated message to 1268 mail list members to complete MLA processing. 1270 A flow chart for the above steps would be: 1272 1. Has a valid signature? 1273 YES -> 2. 1274 NO -> STOP. 1275 2. Does outermost SignedData layer contain mlaExpandHistory? 1276 YES -> Check it, then -> 3. 1277 NO -> Sign message (including outermost SignedData that 1278 doesn't have mlaExpandHistory), deliver it, STOP. 1279 3. Check type of data just below outermost SignedData. 1281 Schaad 23 1282 RFC2634Update August 2004 1284 EnvelopedData -> 3.1. 1285 SignedData -> 3.2. 1286 all others -> 3.3. 1287 3.1. Expand the encrypted message, then -> 3.2. 1288 3.2. -> 3.2.1. 1289 3.2.1. Strip outermost SignedData layer, note value of 1290 mlaExpandHistory and other signed attributes, then -> 3.2.2. 1291 3.2.2. Encapsulate in new signature, then -> 3.2.3. 1292 3.2.3. Create new SignedData layer. 1293 Was there an old mlaExpandHistory? 1294 YES -> copy the old mlaExpandHistory values, then -> 4. 1295 NO -> create new mlaExpandHistory value, then -> 4. 1296 3.3. Encapsulate in a SignedData layer and add an mlaExpandHistory 1297 attribute, then -> 4. 1298 4. Sign message, deliver it, STOP. 1300 4.2.3.3 Processing for data 1302 1. The MLA encapsulates the message in a SignedData layer, and adds 1303 an mlaExpandHistory attribute containing the current ML expansion 1304 information as described in the "Mail List Expansion" section. 1306 2. The MLA signs the new message and delivers the updated message to 1307 mail list members to complete MLA processing. 1309 4.3 Mail List Agent Signed Receipt Policy Processing 1311 If a mailing list (B) is a member of another mailing list (A), list B 1312 often needs to propagate forward the mailing list receipt policy of 1313 A. As a general rule, a mailing list should be conservative in 1314 propagating forward the mailing list receipt policy because the 1315 ultimate recipient need only process the last item in the ML 1316 expansion history. The MLA builds the expansion history to meet this 1317 requirement. 1319 The following table describes the outcome of the union of mailing 1320 list A's policy (the rows in the table) and mailing list B's policy 1321 (the columns in the table). 1323 | B's policy 1324 A's policy | none insteadOf inAdditionTo missing 1325 --------------------------------------------------------------------- 1326 none | none none none none 1327 insteadOf | none insteadOf(B) *1 insteadOf(A) 1328 inAdditionTo | none insteadOf(B) *2 inAdditionTo(A) 1329 missing | none insteadOf(B) inAdditionTo(B) missing 1331 *1 = insteadOf(insteadOf(A) + inAdditionTo(B)) 1332 *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) 1334 4.4 Mail List Expansion History Syntax 1336 Schaad 24 1337 RFC2634Update August 2004 1339 An mlaExpandHistory attribute value has ASN.1 type MLAExpandHistory. 1340 If there are more than ub-ml-expansion-history mailing lists in the 1341 sequence, the receiving agent should provide notification of the 1342 error to a human mail list administrator. The mail list administrator 1343 is responsible for correcting the overflow condition. 1345 MLAExpandHistory ::= SEQUENCE 1346 SIZE (1..ub-ml-expansion-history) OF MLAData 1348 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1349 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) XX} 1351 ub-ml-expansion-history INTEGER ::= 64 1353 MLAData contains the expansion history describing each MLA that has 1354 processed a message. As an MLA distributes a message to members of an 1355 ML, the MLA records its unique identifier, date and time of 1356 expansion, and receipt policy in an MLAData structure. 1358 MLAData ::= SEQUENCE { 1359 mailListIdentifier EntityIdentifier, 1360 expansionTime GeneralizedTime } 1362 EntityIdentifier ::= CHOICE { 1363 issuerAndSerialNumber IssuerAndSerialNumber, 1364 subjectKeyIdentifier SubjectKeyIdentifier } 1366 The receipt policy of the ML can withdraw the originator's request 1367 for the return of a signed receipt. However, if the originator of the 1368 message has not requested a signed receipt, the MLA cannot request a 1369 signed receipt. In the event that a ML's signed receipt policy 1370 supersedes the originator's request for signed receipts, such that 1371 the originator will not receive any signed receipts, then the MLA MAY 1372 inform the originator of that fact. 1374 A. ASN.1 Module 1376 ExtendedSecurityServices2003 1377 { iso(1) member-body(2) us(840) rsadsi(113549) 1378 pkcs(1) pkcs-9(9) smime(16) modules(0) ess2003(XX) } 1380 DEFINITIONS IMPLICIT TAGS ::= 1381 BEGIN 1383 IMPORTS 1385 -- Cryptographic Message Syntax (CMS) 1386 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier 1387 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 1388 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 1390 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 1392 Schaad 25 1393 RFC2634Update August 2004 1395 -- 1988 Syntax 1396 PolicyInformation, CertificateSerialNumber, GeneralNames 1397 FROM PKIX1Implicit88 {iso(1) 1398 identified-organization(3) dod(6) internet(1) security(5) 1399 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 1401 -- Extended Security Services 1403 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 1404 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 1405 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 1406 -- have at least one entry. MAX indicates the upper bound is 1407 unspecified. 1408 -- Implementations are free to choose an upper bound that suits their 1409 -- environment. 1411 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 1412 -- The contents are formatted as described in [UTF8] 1414 -- Section 2.7 1416 ReceiptRequest ::= SEQUENCE { 1417 signedContentIdentifier ContentIdentifier, 1418 receiptsFrom ReceiptsFrom, 1419 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 1421 ub-receiptsTo INTEGER ::= 16 1423 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1424 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 1426 ContentIdentifier ::= OCTET STRING 1428 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1429 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 1431 ReceiptsFrom ::= CHOICE { 1432 allOrFirstTier [0] AllOrFirstTier, 1433 -- formerly "allOrNone [0]AllOrNone" 1434 receiptList [1] SEQUENCE OF GeneralNames } 1436 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 1437 allReceipts (0), 1438 firstTierRecipients (1) } 1440 -- Section 2.X 1442 id-aa-receiptPolicy ::= {id-at XX} 1444 ReceiptPolicy ::= CHOICE { 1445 none [0] NULL, 1446 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1447 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1449 Schaad 26 1450 RFC2634Update August 2004 1452 -- Section 2.8 1454 Receipt ::= SEQUENCE { 1455 version ESSVersion, 1456 contentType ContentType, 1457 signedContentIdentifier ContentIdentifier, 1458 originatorSignatureValue OCTET STRING } 1460 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1461 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 1463 ESSVersion ::= INTEGER { v1(1) } 1465 -- Section 2.9 1467 ContentHints ::= SEQUENCE { 1468 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 1469 contentType ContentType } 1471 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1472 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 1474 -- Section 2.10 1476 MsgSigDigest ::= OCTET STRING 1478 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1479 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 1481 -- Section 2.11 1483 ContentReference ::= SEQUENCE { 1484 contentType ContentType, 1485 signedContentIdentifier ContentIdentifier, 1486 originatorSignatureValue OCTET STRING } 1488 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1489 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 1491 -- Section 3.2 1493 ESSSecurityLabel ::= SET { 1494 security-policy-identifier SecurityPolicyIdentifier, 1495 security-classification SecurityClassification OPTIONAL, 1496 privacy-mark ESSPrivacyMark OPTIONAL, 1497 security-categories SecurityCategories OPTIONAL } 1499 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1500 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 1502 Schaad 27 1503 RFC2634Update August 2004 1505 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 1507 SecurityClassification ::= INTEGER { 1508 unmarked (0), 1509 unclassified (1), 1510 restricted (2), 1511 confidential (3), 1512 secret (4), 1513 top-secret (5) } (0..ub-integer-options) 1515 ub-integer-options INTEGER ::= 256 1517 ESSPrivacyMark ::= CHOICE { 1518 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 1519 utf8String UTF8String (SIZE (1..MAX)) 1520 } 1522 ub-privacy-mark-length INTEGER ::= 128 1524 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 1525 SecurityCategory 1527 ub-security-categories INTEGER ::= 64 1529 SecurityCategory ::= SEQUENCE { 1530 type [0] OBJECT IDENTIFIER, 1531 value [1] ANY DEFINED BY type -- defined by type 1532 } 1534 --Note: The aforementioned SecurityCategory syntax produces identical 1535 --hex encodings as the following SecurityCategory syntax that is 1536 --documented in the X.411 specification: 1537 -- 1538 --SecurityCategory ::= SEQUENCE { 1539 -- type [0] SECURITY-CATEGORY, 1540 -- value [1] ANY DEFINED BY type } 1541 -- 1542 --SECURITY-CATEGORY MACRO ::= 1543 --BEGIN 1544 --TYPE NOTATION ::= type | empty 1545 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 1546 --END 1548 -- Section 3.4 1550 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 1552 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1553 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 1555 -- Section 4.4 1557 id-aa-mlaExpandHistory OBJECT IDENTIFIER ::= {id-aa X } 1559 Schaad 28 1560 RFC2634Update August 2004 1562 MLAExpandHistory ::= SEQUENCE 1563 SIZE (1..ub-ml-expansion-history) of MLAData 1565 MLAData ::= SEQUENCE { 1566 mailListIdentifier EntryIdentifier, 1567 expansionTime GeneralizedTime 1568 } 1570 -- The use of id-aa-mlExpandHistory is obsoleted and replaced by 1571 -- id-aa-mlaExpandHistory and id-aa-receiptBehavior 1573 MLAExpandHistory ::= SEQUENCE 1574 SIZE (1..ub-ml-expansion-history) OF MLAData 1576 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1577 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) XX} 1579 ub-ml-expansion-history INTEGER ::= 64 1581 MLAData ::= SEQUENCE { 1582 mailListIdentifier EntityIdentifier, 1583 expansionTime GeneralizedTime } 1585 EntityIdentifier ::= CHOICE { 1586 issuerAndSerialNumber IssuerAndSerialNumber, 1587 subjectKeyIdentifier SubjectKeyIdentifier } 1589 MLReceiptPolicy ::= CHOICE { 1590 none [0] NULL, 1591 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1592 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1594 -- Section 5.4 1596 SigningCertificate ::= SEQUENCE { 1597 certs SEQUENCE OF ESSCertID, 1598 policies SEQUENCE OF PolicyInformation OPTIONAL 1599 } 1601 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 1602 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 1603 smime(16) id-aa(2) 12 } 1605 ESSCertID ::= SEQUENCE { 1606 certHash Hash, 1607 issuerSerial IssuerSerial OPTIONAL 1608 } 1610 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 1612 IssuerSerial ::= SEQUENCE { 1614 Schaad 29 1615 RFC2634Update August 2004 1617 issuer GeneralNames, 1618 serialNumber CertificateSerialNumber 1619 } 1620 -- 1621 -- The following items are included for historical reasons. 1622 -- See Appendix C of this document for processing. 1623 -- 1625 MLExpansionHistory ::= SEQUENCE 1626 SIZE (1..ub-ml-expansion-history) OF MLData 1628 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1629 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 1631 ub-ml-expansion-history INTEGER ::= 64 1633 MLData ::= SEQUENCE { 1634 mailListIdentifier EntityIdentifier, 1635 expansionTime GeneralizedTime, 1636 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 1638 MLReceiptPolicy ::= CHOICE { 1639 none [0] NULL, 1640 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 1641 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 1643 END -- of ExtendedSecurityServices 1645 C. Processing for Obsolete Mail List Expansion Signed Attribute 1647 One of the main changes between this document and it's predecessor is 1648 the decomposistion of the MLExpansionHistory attribute into the 1649 MLAExpandHistory and ReceiptPolicy attributes. The author does not 1650 currently know of any systems that generate the MLExpansionHistory 1651 attribute, however this section is provided for completeness. 1653 When an implementation finds the old MLExpansionHistory attribute the 1654 following is suggested as the correct handling: 1656 1. If there exists a MLAExpandHistory or ReceiptPolicy attribute, 1657 ignore the MLExpansionHistory attribute for processing, but place 1658 it into the new signature created. 1660 2. Decompose the MLExpansionHistory attribute into a MLAExpandHistory 1661 attribute and ReceiptPolicy attribute as necessary. Place the 1662 current MLExpansionHistory attribute in all new signatures 1663 created. 1665 D. Acknowledgments 1667 Schaad 30 1668 RFC2634Update August 2004 1670 The first draft of this work was prepared by David Solo. John Pawling 1671 did a huge amount of very detailed revision work during the many 1672 phases of the document. 1674 The first RFC version of this work was edited by Paul Hoffman who did 1675 remarkably well in keeping up with the arguments between John, myself 1676 and the others who contributed to this document. 1678 Many other people have contributed hard work to this memo, including: 1680 Andrew Farrell 1681 Bancroft Scott 1682 Bengt Ackzell 1683 Bill Flanigan 1684 Blake Ramsdell 1685 Carlisle Adams 1686 Darren Harter 1687 David Kemp 1688 Denis Pinkas 1689 Francois Rousseau 1690 Russ Housley 1691 Scott Hollenbeck 1692 Steve Dusse 1694 Author's Addresses 1696 Jim Schaad 1697 Soaring Hawk Consulting 1698 PO Box 675 1699 Gold Bar, 98251 1701 Email: jimsch@exmsft.com 1703 Copyright Statement 1705 Copyright (C) The Internet Society (year). This document is 1706 Subject to the rights, licenses and restrictions contained in BCP 78, 1707 and except as set forth therein, the authors retain all their 1708 rights." 1710 This document and the information contained herein are provided on 1711 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1712 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1713 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1714 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1715 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1716 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1718 Schaad 31