idnits 2.17.1 draft-ietf-ediint-as1-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: ---------------------------------------------------------------------------- ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 53 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 322 has weird spacing: '...non-use of...' == Line 343 has weird spacing: '...ication is re...' == Line 1012 has weird spacing: '...quested proto...' == Line 1200 has weird spacing: '...ions of the o...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the request for a receipt or signed receipt, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the "disposition-type" set to 'processed'. When the MDN is sent automatically by the EDI UA, and there is no explicit way for a user to control the sending of the MDN, then the first part of the "disposition-mode" should be set to "automatic-action". When the MDN is being sent under user configurable control, then the first part of the "disposition-mode" should be set to "manual-action". Since a request for a signed receipt should always be honored, the user MUST not be allowed to configure the UA to not send a signed receipt when the sender requests one. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, administrator's, or under software control. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1362, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1366, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2630 (ref. '8') (Obsoleted by RFC 3369, RFC 3370) -- No information found for draft-ietf-ediint-req09 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 1892 (ref. '10') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 2068 (ref. '11') (Obsoleted by RFC 2616) ** Downref: Normative reference to an Informational RFC: RFC 1952 (ref. '12') Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 EDIINT Working Group T. Harding 2 Internet draft Cyclone Commerce 3 Expires: Aug / 2001 R. Drummond 4 Drummond Group 5 Chuck Shih 6 Gartner Group 7 February, 2001 9 MIME-based Secure EDI 11 draft-ietf-ediint-as1-12.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Any questions, comments, and reports of defects or ambiguities in 36 this specification may be sent to the mailing list for the EDIINT 37 working group of the IETF, using the address 38 . Requests to subscribe to the mailing list 39 should be addressed to . 41 Copyright Notice 43 Copyright (c) The Internet Society (1998). All rights reserved. 45 Abstract 47 This document describes how to securely exchange EDI and other 48 business related documents using MIME and public key 49 cryptography. 51 MIME-based Secure EDI February, 2001 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 54 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 55 "OPTIONAL" in this document are to be interpreted as described in 56 RFC 2119. 58 Feedback Instructions: 60 If you want to provide feedback on this draft, follow these 61 guidelines: 63 -Send feedback via e-mail to the ietf-ediint list for discussion, 64 with "AS#1" in the Subject field. To enter or follow the 65 discussion, you need to subscribe to ietf-ediint@imc.org. 67 -Be specific as to what section you are referring to, preferably 68 quoting the portion that needs modification, after which you 69 state your comments. 71 -If you are recommending some text to be replaced with your 72 suggested text, again, quote the section to be replaced, and be 73 clear on the section in question. 75 Table of Contents 77 1.0 Introduction 3 78 2.0 Overview 4 79 2.1 Purpose of a security guideline for MIME EDI 4 80 2.2 Definitions 4 81 2.2.1. Terms 4 82 2.2.2 The secure transmission loop 5 83 2.2.3 Definition of receipts 5 84 2.3 Assumptions 6 85 2.3.1 EDI process assumptions 6 86 2.3.2 Flexibility assumptions 7 87 3.0 Referenced RFCs and their contribution 8 88 3.1 RFC 821 SMTP [7] 8 89 3.2 RFC 822 Text Message Format [3] 8 90 3.3 RFC 1847 MIME Security Multiparts [6] 8 91 3.4 RFC 1892 Multipart/report [10] 9 92 3.5 RFC 1767 EDI Content [2] 9 93 3.6 RFC 2015, 2440 PGP/MIME [4] 9 94 3.7 RFC 2045, 2046, and 2049 MIME [1] 9 95 3.8 RFC 2298 Message Disposition Notification [5] 9 96 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9 97 4.0 Structure of an EDI MIME message - Applicability 9 98 4.1 Introduction 9 99 4.2 Structure of an EDI MIME message - PGP/MIME 10 100 4.2.1 No encryption, no signature 10 102 MIME-based Secure EDI February, 2001 104 4.2.2 No encryption, signature 10 105 4.2.3 Encryption, no signature 10 106 4.2.4 Encryption, signature 10 107 4.3 Structure of an EDI MIME message - S/MIME 10 108 4.3.1 No encryption, no signature 10 109 4.3.2 No encryption, signature 10 110 4.3.3 Encryption, no signature 10 111 4.3.4 Encryption, signature 11 112 5.0 Receipts 11 113 5.1 Introduction 11 114 5.2 Requesting a signed receipt 13 115 5.2.1 Additional Signed Receipt Considerations 15 116 5.3 Message Disposition Notification Format 16 117 5.3.1 Message Disposition Notification Extensions 18 118 5.3.2 Disposition Mode, Type, and Modifier Use 19 119 5.3.2.1 Successful Processing 19 120 5.3.2.2 Unprocessed Content 20 121 5.3.2.3 Content Processing Errors 20 122 5.3.2.4 Content Processing Warnings 21 123 5.4 Message Disposition Notification Processing 21 124 5.4.1 Large File Processing 21 125 5.4.2 Example 22 126 6.0 Public key certificate handling 24 127 6.1 Near term approach 24 128 6.2 Long term approach 24 129 7.0 Security Considerations 24 130 8.0 Acknowledgments 25 131 9.0 References 26 132 10.0 Authors' Addresses 27 134 1.0 Introduction 136 Previous work on Internet EDI focused on specifying MIME content 137 types for EDI data ([2] RFC 1767). This document expands on RFC 138 1767 to specify use of a comprehensive set of data security 139 features, specifically data privacy, data integrity/authenticity, 140 non-repudiation of origin and non-repudiation of receipt. This 141 document also recognizes contemporary RFCs and Internet drafts and 142 is attempting to "re-invent" as little as possible. 144 With an enhancement in the area of "receipts", as described below 145 (5.2), secure Internet MIME based EDI can be accomplished by 146 using and complying with the following RFCs: 148 -RFC 821 SMTP 149 -RFC 822 Text Message Formats 150 -RFC 1767 EDI Content Type 151 -RFC 1847 Security Multiparts for MIME 152 -RFC 1892 Multipart/Report 153 -RFC 2015, 2440 MIME/PGP 155 MIME-based Secure EDI February, 2001 157 -RFC 2045 to 2049 MIME RFCs 158 -RFC 2298 Message Disposition Notification 159 -RFC 2630, 2633 S/MIME v3 Specification 161 Our intent here is to define clearly and precisely how these are 162 used together, and what is required by user agents to be 163 compliant with this document. 165 2.0 Overview 167 2.1 Purpose of a security guideline for MIME EDI 169 The purpose of these specifications is to ensure interoperability 170 between EDI user agents, invoking some or all of the commonly 171 expected security features. This document is also NOT limited to 172 strict EDI use, but applies to any electronic commerce 173 application where business data needs to be exchanged over the 174 Internet in a secure manner. 176 2.2 Definitions 178 2.2.1. Terms 180 EDI Electronic Data Interchange 182 EC Electronic Commerce 184 Receipt The functional message that is sent from a 185 receiver to a sender to acknowledge 186 receipt of an EDI/EC interchange. 188 Signed Receipt Same as above, but with a digital 189 signature. 191 Message Disposition The Internet messaging format used to 192 Notification convey a receipt. This term is used 193 interchangeably with receipt. A signed 194 MDN is a signed receipt. 196 Non-repudiation of NRR is a "legal event" that occurs when 197 Receipt (NRR) the original sender of an EDI/EC 198 interchange has verified the signed 199 receipt coming back from the receiver. 200 NRR IS NOT a functional or a technical 201 message. 203 PGP/MIME Digital envelope security based on the 204 Pretty Good Privacy (PGP) standard 205 (Zimmerman), integrated with MIME Security 206 Multiparts [6]. 208 MIME-based Secure EDI February, 2001 210 S/MIME A format and protocol for adding 211 Cryptographic signature and/or encryption 212 services to Internet MIME messages. 214 2.2.2 The secure transmission loop 216 The functional requirements document,[9] "Requirements for 217 Inter-operable Internet EDI", a reference to a RFC-to-be (can be 218 found at www.ietf.org), provides extensive information on EDI 219 security and the user/business related processes surrounding the 220 need for and use of EDI security. In this document, it is assumed 221 that the reader is familiar with the requirements document. 223 This document's focus is on the formats and protocols for 224 exchanging EDI content that has had security applied to it using 225 the Internet's messaging environment. 227 The "secure transmission loop" for EDI involves one organization 228 sending a signed and encrypted EDI interchange to another 229 organization, requesting a signed receipt, followed later by the 230 receiving organization sending this signed receipt back to the 231 sending organization. In other words, the following transpires: 233 -The organization sending EDI/EC data signs and encrypts the 234 data using either PGP/MIME or S/MIME. In addition, the message 235 will request a signed receipt to be returned to the sender of 236 the message. 238 -The receiving organization decrypts the message and verifies 239 the signature, resulting in verified integrity of the data and 240 authenticity of the sender. 242 -The receiving organization then returns a signed receipt to 243 the sending organization in the form of a message disposition 244 notification message. This signed receipt will contain the 245 hash of the signature from the received message, indicating to 246 the sender that the received message was verified and/or 247 decrypted properly. 249 The above describes functionality which if implemented, would 250 satisfy all security requirements. This specification, however, 251 leaves full flexibility for users to decide the degree to which 252 they want to deploy those security features with their EDI trading 253 partners. 255 2.2.3 Definition of receipts 257 MIME-based Secure EDI February, 2001 259 The term used for both the functional activity and message for 260 acknowledging receipt of an EDI/EC interchange is receipt, or 261 signed receipt. The first term is used if the acknowledgment is 262 for an interchange resulting in a receipt which is NOT signed. 263 The second term is used if the acknowledgment is for an 264 interchange resulting in a receipt which IS signed. The method 265 used to request a receipt or a signed receipt is defined in 266 RFC 2298, "An Extensible Message Format for Message Disposition 267 Notifications". 269 The "rule" is: 271 - If a receipt is requested, explicitly specifying that the 272 receipt be signed, then the receipt MUST be returned with a 273 signature. 275 - If a receipt is requested, explicitly specifying that the 276 receipt be signed, but the recipient cannot support the 277 requested protocol format or requested MIC algorithms, then a 278 receipt, either signed or unsigned SHOULD be returned. 280 - If a signature is not explicitly requested, or if the signed 281 receipt request parameter is not recognized by the UA, a 282 receipt may or may not be returned. This behavior is 283 consistent with the MDN RFC 2298. 285 A term often used in combination with receipts is "Non- 286 Repudiation of Receipt (NRR). NRR refers to a legal event which 287 occurs only when the original sender of an interchange has 288 verified the signed receipt coming back from recipient of the 289 message. Note that NRR is not possible without signatures. 291 2.3 Assumptions 293 2.3.1 EDI process assumptions 295 -Encrypted object is an EDI Interchange 297 This specification assumes that a typical EDI interchange is the 298 lowest level object that will be subject to security services. 300 In ANSI X12, this means anything between, and including segments 301 ISA and IEA. In EDIFACT, this means anything between, and 302 including, segments UNA/UNB and UNZ. In other words, the EDI 303 interchanges including envelope segments remain intact and 304 unreadable during secure transport. 306 -EDI envelope headers are encrypted 308 MIME-based Secure EDI February, 2001 310 Congruent with the above statement, EDI envelope headers are NOT 311 visible in the MIME package. In order to optimize VAN-to- 312 Internet routing, work may need to be done in the future to 313 define ways to pull out some of the envelope information to make 314 them visible, however, this specification does not go into any 315 detail on that. 317 -X12.58 and UN/EDIFACT security considerations 319 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 320 defined internal provisions for security. X12.58 is the 321 security mechanism for ANSI X12 and AUTACK provides security for 322 EDIFACT. This specification DOES NOT dictate use or non-use of 323 these security standards. They are both fully compatible, 324 though possibly redundant, with this specification. 326 2.3.2 Flexibility assumptions 328 -Encrypted or un-encrypted data 330 This specification allows for EDI message exchange where the EDI 331 data can either be un-protected or protected by means of 332 encryption. 334 -Signed or un-signed data 336 This specification allows for EDI message exchange with or 337 without digital signature of the original EDI transmission. 339 -Use of receipt or not 341 This specification allows for EDI message transmission with or 342 without a request for receipt notification. If a signed receipt 343 notification is requested however, a mic value is REQUIRED as 344 part of the returned receipt, unless an error condition occurs 345 in which a mic value cannot be returned. In error cases, an un- 346 signed receipt or MDN SHOULD be returned with the correct 347 "disposition modifier" error value. 349 -Formatting choices 351 This specification defines the use of two methods for formatting 352 EDI contents that have security applied to it: 354 -PGP/MIME 355 -S/MIME 357 This specification relies on the guidelines set forth in RFC 358 2015/2440, as reflected in [4] "MIME Security with Pretty Good 360 MIME-based Secure EDI February, 2001 362 Privacy" (PGP); OpenPGP Message Format, and RFC 2633/2630 363 [8] "S/MIME Version 3 Message Specification; Cryptographic 364 Message Syntax". PGP/MIME or S/MIME as defined in this 365 Applicability statement, and the [9]"Requirements for 366 Inter-operable Internet EDI" draft is REQUIRED to be compliant 367 with the document. 369 -Hash function, message digest choices 371 When a signature is used, it is RECOMMENDED that the SHA1 hash 372 algorithm be used for all outgoing messages, and that both MD5 373 and SHA1 be supported for incoming messages. 375 In summary, the following eight permutations are possible in any 376 given trading relationship: 378 (1) Sender sends un-encrypted data, does NOT request a receipt. 380 (2) Sender sends un-encrypted data, requests a signed or 381 unsigned receipt. The receiver sends back the signed or 382 unsigned receipt. 384 (3) Sender sends encrypted data, does NOT request a receipt. 386 (4) Sender sends encrypted data, requests a signed or unsigned 387 receipt. The receiver sends back the signed or un-signed 388 receipt. 390 (5) Sender sends signed data, does NOT request a signed or un- 391 signed receipt. 393 (6) Sender sends signed data, requests a signed or un-signed 394 receipt. Receiver sends back the signed or un-signed 395 receipt. 397 (7) Sender sends encrypted and signed data, does NOT request a 398 signed or un-signed receipt. 400 (8) Sender sends encrypted and signed data, requests a signed or 401 un-signed receipt. Receiver sends back the signed or un- 402 signed receipt. 404 NOTE: Users can choose any of the eight possibilities, but only 405 example (8), when a signed receipt is requested, offers the 406 whole suite of security features described in the "Secure 407 transmission loop" above. 409 3.0 Referenced RFCs and their contribution 411 3.1 RFC 821 SMTP [7] 413 MIME-based Secure EDI February, 2001 415 This is the core mail transfer standard that all MTAs need to 416 adhere to. 418 3.2 RFC 822 Text Message Format [3] 420 Defines message header fields and the parts making up a message. 422 3.3 RFC 1847 MIME Security Multiparts [6] 424 This document defines security multiparts for MIME: 425 multipart/encrypted and multipart/signed. 427 3.4 RFC 1892 Multipart/report [10] 429 This RFC defines the use of the multipart/report content type, 430 something that the MDN RFC 2298 builds upon. 432 3.5 RFC 1767 EDI Content [2] 434 This RFC defines the use of content type "application" for ANSI 435 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 436 mutually defined EDI (application/EDI-Consent). 438 3.6 RFC 2015, 2440 PGP/MIME [4] 440 This RFC defines the use of content types "multipart/encrypted", 441 "multipart/signed", "application/pgp encrypted" and 442 "application/pgp-signature" for defining MIME PGP content. 444 3.7 RFC 2045, 2046, and 2049 MIME [1] 446 These are the basic MIME standards, upon which all MIME related 447 RFCs build, including this one. Key contributions include 448 definition of "content type", "sub-type" and "multipart", as well 449 as encoding guidelines, which establishes 7-bit US-ASCII as the 450 canonical character set to be used in Internet messaging. 452 3.8 RFC 2298 Message Disposition Notification [5] 454 This Internet RFC defines how a message disposition notification 455 (MDN) is requested, and the format and syntax of the MDN. The MDN 456 is the basis upon which receipts and signed receipts are defined 457 in this and the "Requirements" specification. 459 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 461 This specification describes how MIME shall carry CMS Objects. 463 4.0 Structure of an EDI MIME message - Applicability 465 MIME-based Secure EDI February, 2001 467 4.1 Introduction 469 The structures below are described hierarchically in terms of 470 which RFC's are applied to form the specific structure. For 471 details of how to code in compliance with all RFC's involved, 472 turn directly to the RFC's referenced. The "requirements 473 document" has several examples described in an Appendix for those 474 interested. 476 Also, these structures describe the initial transmission only. 477 Receipts, and requests for receipts are handled in section 5. 479 4.2 Structure of an EDI MIME message - PGP/MIME 481 4.2.1 No encryption, no signature 483 -RFC822/2045 484 -RFC1767 (application/EDIxxxx) 486 4.2.2 No encryption, signature 488 -RFC822/2045 489 -RFC1847 (multipart/signed) 490 -RFC1767 (application/EDIxxxx) 491 -RFC2015/2440 (application/pgp-signature) 493 4.2.3 Encryption, no signature 495 -RFC822/2045 496 -RFC1847 (multipart/encrypted) 497 -RFC2015/2440 (application/pgp-encrypted) 498 -"Version: 1" 499 -RFC2015/2440 (application/octet-stream) 500 -RFC1767 (application/EDIxxxx) (encrypted) 502 4.2.4 Encryption, signature 504 -RFC822/2045 505 -RFC1847 (multipart/encrypted) 506 -RFC2015/2440 (application/pgp-encrypted) 507 -"Version: 1" 508 -RFC2015/2440 (application/octet-stream) 509 -RFC1847 (multipart/signed)(encrypted) 510 -RFC1767 (application/EDIxxxx)(encrypted) 511 -RFC2015/2440 (application/pgp-signature)(encrypted) 513 4.3 Structure of an EDI MIME message - S/MIME 515 4.3.1 No encryption, no signature 517 MIME-based Secure EDI February, 2001 519 -RFC822/2045 520 -RFC1767 (application/EDIxxxx) 522 4.3.2 No encryption, signature 524 -RFC822/2045 525 -RFC1847 (multipart/signed) 526 -RFC1767 (application/EDIxxxx) 527 -RFC2633 (application/pkcs7-signature) 529 4.3.3 Encryption, no signature 531 -RFC822/2045 532 -RFC2633 (application/pkcs7-mime) 533 -RFC1767 (application/EDIxxxx) (encrypted) 535 4.3.4 Encryption, signature 537 -RFC822/2045 538 -RFC2633 (application/pkcs7-mime) 539 -RFC1847 (multipart/signed) (encrypted) 540 -RFC1767 (application/EDIxxxx) (encrypted) 541 -RFC2633 (application/pkcs7-signature) (encrypted) 543 5.0 Receipts 545 5.1 Introduction 547 In order to support non-repudiation of receipt (NRR), a signed 548 receipt, based on digitally signing a message disposition 549 notification, is to be implemented by a receiving trading 550 partner's UA (User Agent). The message disposition notification, 551 specified by RFC 2298 is digitally signed by a receiving trading 552 partner as part of a multipart/signed MIME message. 554 The following support for signed receipts is REQUIRED: 556 1). The ability to create a multipart/report; where the report- 557 type = disposition-notification. 559 2). The ability to calculate a message integrity check (MIC) on 560 the received message. The calculated MIC value will be 561 returned to the sender of the message inside the signed 562 receipt. 564 4). The ability to create a multipart/signed content with the 565 message disposition notification as the first body part, and 566 the signature as the second body part. 568 MIME-based Secure EDI February, 2001 570 5). The ability to return the signed receipt to the sending 571 trading partner. 573 The signed receipt is used to notify a sending trading partner 574 that requested the signed receipt that: 576 1). The receiving trading partner acknowledges receipt of the 577 sent EDI Interchange. 579 2). If the sent message was signed, then the receiving trading 580 partner has authenticated the sender of the EDI Interchange. 582 3). If the sent message was signed, then the receiving trading 583 partner has verified the integrity of the sent EDI 584 Interchange. 586 Regardless of whether the EDI Interchange was sent in S/MIME or 587 PGP/MIME format, the receiving trading partner's UA MUST provide 588 the following basic processing: 590 1). If the sent EDI Interchange is encrypted, then the encrypted 591 symmetric key and initialization vector (if applicable) is 592 decrypted using the receiver's private key. 594 2). The decrypted symmetric encryption key is then used to 595 decrypt the EDI Interchange. 597 3). The receiving trading partner authenticates signatures in a 598 message using the sender's public key. The authentication 599 algorithm performs the following: 601 a). The message integrity check (MIC or Message Digest), 602 is decrypted using the sender's public key. 604 b). A MIC on the signed contents (the MIME header and 605 encoded EDI object, as per RFC 1767) in the message 606 received is calculated using the same one-way hash 607 function that the sending trading partner used. 609 c). The MIC extracted from the message that was sent, and 610 the MIC calculated using the same one-way hash function 611 that the sending trading partner used is compared for 612 equality. 614 4). The receiving trading partner formats the MDN and sets the 615 calculated MIC into the "Received-content-MIC" extension 616 field. 618 5). The receiving trading partner creates a multipart/signed MIME 619 message according to RFC 1847. 621 MIME-based Secure EDI February, 2001 623 6). The MDN is the first part of the multipart/signed message, 624 and the digital signature is created over this MDN, including 625 its MIME headers. 627 7). The second part of the multipart/signed message contains the 628 digital signature. The "protocol" option specified in the 629 second part of the multipart/signed is as follows: 631 S/MIME: protocol = "application/pkcs-7-signature" 633 PGP/MIME: protocol = "application/pgp-signature" 635 8). The signature information is formatted according to S/MIME or 636 PGP/MIME specifications. 638 The EDI Interchange and the RFC 1767 MIME EDI content header, can 639 actually be part of a multi-part MIME content-type. When the EDI 640 Interchange is part of a multi-part MIME content-type, the MIC 641 MUST be calculated across the entire multi-part content, 642 including the MIME headers. 644 The signed MDN, when received by the sender of the EDI 645 Interchange can be used by the sender: 647 1). As an acknowledgment that the EDI Interchange sent, was 648 delivered and acknowledged by the receiving trading 649 partner. The receiver does this by returning the original 650 message id of the sent message in the MDN portion of the 651 signed receipt. 653 2). As an acknowledgment that the integrity of the EDI 654 Interchange was verified by the receiving trading partner. 655 The receiver does this by returning the calculated MIC of 656 the received EDI Interchange (and 1767 MIME headers) in the 657 "Received-content-MIC" field of the signed MDN. 659 3). As an acknowledgment that the receiving trading partner has 660 authenticated the sender of the EDI Interchange. 662 4). As a non-repudiation of receipt when the signed MDN is 663 successfully verified by the sender with the receiving 664 trading partner's public key and the returned mic value 665 inside the MDN is the same as the digest of the original 666 message. 668 5.2 Requesting a signed receipt 670 Message Disposition Notifications are requested as per RFC 2298, 672 MIME-based Secure EDI February, 2001 674 "An Extensible Message Format for Message Disposition 675 Notification". A request that the receiving user agent issue a 676 message disposition notification is made by placing the following 677 header into the message to be sent: 679 MDN-request-header = "Disposition-notification-to" ":" 680 mail-address 682 The mail-address field is specified as an RFC 822 user@domain 683 address, and is the return address for the message disposition 684 notification. 686 In addition to requesting a message disposition notification, a 687 message disposition notification that is digitally signed, or 688 what has been referred to as a signed receipt, can be requested 689 by placing the following in the message header following the 690 "Disposition-Notification-To" line. 692 Disposition-notification-options = 693 "Disposition-Notification-Options" ":" 694 disposition-notification-parameters 696 where 698 disposition-notification-parameters = 699 parameter *(";" parameter) 701 where 703 parameter = attribute "=" importance ", " 1#value" 705 where 707 importance = "required" | "optional" 709 So the Disposition-notification-options string could be: 711 signed-receipt-protocol=optional, ; 712 signed-receipt-micalg=optional, , ,...; 714 The currently supported values for are 715 "pkcs7-signature", for the S/MIME detached signature format, or 716 "pgp-signature", for the pgp signature format. 718 The currently supported values for MIC algorithm values are: 720 Algorithm Value 721 used 723 MIME-based Secure EDI February, 2001 725 MD5 md5 726 SHA-1 sha1 728 (Historical note: some early implementations of EDIINT emitted 729 and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) 730 Receiving agents SHOULD be able to recover gracefully from a 731 micalg parameter value that they do not recognize. 733 An example of a formatted options line would be as follows: 735 Disposition-notification-options: 736 signed-receipt-protocol=optional, pkcs7-signature; 737 signed-receipt-micalg=optional, sha1, md5 739 The semantics of the "signed-receipt-protocol" parameter is as 740 follows: 742 1). The "signed-receipt-protocol" parameter is used to request a 743 signed receipt from the recipient trading partner. The 744 "signed-receipt-protocol" parameter also specifies the format 745 in which the signed receipt should be returned to the 746 requester. 748 The "signed-receipt-micalg" parameter is a list of MIC 749 algorithms preferred by the requester for use in signing the 750 returned receipt. The list of MIC algorithms should be 751 honored by the recipient from left to right. 753 Both the "signed-receipt-protocol" and the "signed-receipt- 754 micalg" option parameters are REQUIRED when requesting a 755 signed receipt. 757 2). The "importance" attribute of "Optional" is defined in the 758 MDN RFC 2298 and has the following meaning: 760 Parameters with an importance of "Optional" permit a UA that 761 does not understand the particular options parameter to still 762 generate a MDN in response to a request for a MDN. A UA that 763 does not understand the "signed-receipt-protocol" parameter, 764 or the "signed-receipt-micalg" will obviously not return a 765 signed receipt. 767 The importance of "Optional" is used for the signed receipt 768 parameters because it is RECOMMENDED that an MDN be returned 769 to the requesting trading partner even if the recipient could 770 not sign it. 772 The returned MDN will contain information on the disposition 773 of the message as well as why the MDN could not be signed. 774 See the Disposition field in section 5.3 for more information. 776 MIME-based Secure EDI February, 2001 778 Within an EDI trading relationship, if a signed receipt is 779 expected and is not returned, then the validity of the 780 transaction is up to the trading partners to resolve. In 781 general, if a signed receipt is required in the trading 782 relationship and is not received, the transaction will likely 783 not be considered valid. 785 5.2.1 Additional Signed Receipt Considerations 787 The "rules" stated in Section 2.2.3 for signed receipts are as 788 follows: 790 1). When a receipt is requested, explicitly specifying that the 791 receipt be signed, then the receipt MUST be returned with a 792 signature. 794 2). When a receipt is requested, explicitly specifying that the 795 receipt be signed, but the recipient cannot support either 796 the requested protocol format, or requested MIC algorithms, 797 then either a signed or unsigned receipt SHOULD be returned. 799 3). When a signature is not explicitly requested, or if the 800 signed receipt request parameter is not recognized by the UA, 801 then no receipt, an unsigned receipt, or a signed receipt MAY 802 be returned by the recipient. 804 NOTE: For Internet EDI, it is RECOMMENDED that when a signature 805 is not explicitly requested, or if parameters are not recognized, 806 that the UA send back at a minimum, an unsigned receipt. If a 807 signed receipt however was always returned as a policy, whether 808 requested or not, then any false unsigned receipts can be 809 repudiated. 811 When a request for a signed receipt is made, but there is an 812 error in processing the contents of the message, a signed receipt 813 MUST still be returned. The request for a signed receipt SHALL 814 still be honored, though the transaction itself may not be valid. 815 The reason for why the contents could not be processed MUST be 816 set in the "disposition-field". 818 When a request for a signed receipt is made, the "Received- 819 content-MIC" MUST always be returned to the requester. The 820 "Received-content-MIC" MUST be calculated as follows: 822 - For any signed messages, the MIC to be returned is calculated 823 on the RFC1767 MIME header and content. Canonicalization as 824 specified in RFC 1848 MUST be performed before the MIC is 825 calculated, since the sender requesting the signed receipt was 826 also REQUIRED to canonicalize. 828 MIME-based Secure EDI February, 2001 830 - For encrypted, unsigned messages, the MIC to be returned is 831 calculated on the decrypted RFC 1767 MIME header and content. 832 The content after decryption MUST be canonicalized before the 833 MIC is calculated. 835 - For unsigned, unencrypted messages, the MIC MUST be calculated 836 over the message contents prior to Content-Transfer-Encoding or 837 Content-Encoding, and without the MIME or any other RFC 822 838 headers, since these are sometimes altered or reordered by MTAs. 840 5.3 Message Disposition Notification Format 842 The format of a message disposition notification is specified in 843 RFC 2298 For use in Internet EDI, the following format will be 844 used: 846 - content-type - per RFC 1892 and the RFC 2298 specification 848 - reporting-ua-field - per RFC 2298 specification 850 - MDN-gateway-field - per RFC 2298 specification 852 - original-recipient-field - per RFC 2298 specification 854 - final-recipient-field - per RFC 2298 specification 856 - original-message-id-field - per RFC 2298 specification 858 - disposition-field - the following "disposition-mode" 859 values SHOULD be used for 860 Internet EDI: 862 "automatic-action" - The disposition described by the 863 disposition type was a result of an 864 automatic action, rather than an explicit 865 instruction by the user for this message. 867 "manual-action" - The disposition described by the 868 disposition type was a result of an 869 explicit instruction by the user rather 870 than some sort of automatically performed 871 action. 873 "MDN-sent-automatically" - The MDN was sent because the UA had 874 previously been configured to do 875 so. 877 "MDN-sent-manually" - The user explicitly gave permission for 879 MIME-based Secure EDI February, 2001 881 this particular MDN to be sent. "MDN- 882 sent-manually" is meaningful with 883 "manual-action", but not with 884 "automatic-action". 886 - disposition-field - the following "disposition-type" values 887 SHOULD be used for Internet EDI: 889 "processed" - The message has been processed in some manner 890 (e.g., printed, faxed, forwarded, gatewayed) 891 without being displayed to the user. The user 892 may or may not see the message later. 894 "failed" - A failure occurred that prevented the proper 895 generation of an MDN. More information about the 896 cause of the failure may be contained in a 897 Failure field. The "failed" disposition type is 898 not to be used for the situation in which there 899 is some problem in processing the message other 900 than interpreting the request for an MDN. The 901 "processed" or other disposition type with 902 appropriate disposition modifiers is to be used 903 in such situations. 905 - disposition-field - the following "disposition-modifier" 906 values SHOULD be used for Internet EDI: 908 "error" - An error of some sort occurred that prevented 909 successful processing of the message. Further 910 information is contained in an Error field. 912 "warning" - The message was successfully processed but some 913 sort of exceptional condition occurred. Further 914 information is contained in a Warning field. 916 5.3.1 Message Disposition Notification Extensions 918 The following "extension field" will be added in order to support 919 signed receipts for RFC 1767 MIME content type and multipart MIME 920 content types that include the RFC 1767 MIME content type. The 921 extension field" defined below follows the "disposition-field" in 922 the MDN. 924 The "Received-content-MIC" extension field is set when the 925 integrity of the received message is verified. The MIC is the 926 base64 encoded quantity computed over the received message with a 927 hash function. For details of "what" the "Received-content-MIC" 928 should be calculated over, see Section 5.2.1. The algorithm used 929 to calculate the "Received-content-MIC" value MUST be the same as 931 MIME-based Secure EDI February, 2001 933 the "micalg" value used by the sender in the multipart/signed 934 message. When no signature is received, or the mic-alg parameter 935 is not supported then it is RECOMMENDED that the SHA1 algorithm 936 be used to calculate the MIC on the received message or message 937 contents. 939 This field is set only when the contents of the message are 940 processed successfully. This field is used in conjunction with 941 the recipient's signature on the MDN in order for the sender to 942 verify "non-repudiation of receipt". 944 - extension field = "Received-content-MIC" ":" MIC 946 where: 948 = "," 950 = the result of one way hash function, base64 951 encoded. 953 < micalg> = the micalg value defined in RFC1847, an IANA 954 registered MIC algorithm ID token. 956 5.3.2 Disposition Mode, Type, and Modifier Use 958 Guidelines for use of the "disposition-mode", "disposition- 959 type", and "disposition-modifier" fields within Internet EDI are 960 discussed in this section. The "disposition-mode", "disposition- 961 type', and "disposition-modifier' fields are described in detail 962 in RFC 2298. The "disposition-mode', "disposition-type" and 963 "disposition-modifier" values SHOULD be used as follows: 965 5.3.2.1 Successful Processing 967 When the request for a receipt or signed receipt, and the 968 received message contents are successfully processed by the 969 receiving EDI UA, a receipt or MDN SHOULD be returned with the 970 "disposition-type" set to 'processed'. When the MDN is sent 971 automatically by the EDI UA, and there is no explicit way for a 972 user to control the sending of the MDN, then the first part of 973 the "disposition-mode" should be set to "automatic-action". When 974 the MDN is being sent under user configurable control, then the 975 first part of the "disposition-mode" should be set to "manual- 976 action". Since a request for a signed receipt should always be 977 honored, the user MUST not be allowed to configure the UA to not 978 send a signed receipt when the sender requests one. 980 The second part of the "disposition-mode" is set to "MDN-sent- 982 MIME-based Secure EDI February, 2001 984 manually" if the user gave explicit permission for the MDN to be 985 sent. Again, the user MUST not be allowed to explicitly refuse 986 to send a signed receipt when the sender requests one. The 987 second part of the "disposition-mode" is set to "MDN-sent- 988 automatically" whenever the EDI UA sends the MDN automatically, 989 regardless of whether the sending was under a user's, 990 administrator's, or under software control. 992 Since EDI content is generally handled automatically by the EDI 993 UA, a request for a receipt or signed receipt will generally 994 return the following in the "disposition-field": 996 Disposition: automatic-action/MDN-sent-automatically; processed 998 Note this specification does not restrict the use of the 999 "disposition-mode" to just automatic actions. Manual actions are 1000 valid as long as it is kept in mind that a request for a signed 1001 receipt MUST be honored. 1003 5.3.2.2 Unprocessed Content 1005 The request for a signed receipt requires the use of two 1006 "disposition-notification-options", which specify the protocol 1007 format of the returned signed receipt, and the MIC algorithm 1008 used to calculate the mic over the message contents. The 1009 "disposition-field" values that should be used in the case where 1010 the message content is being rejected or ignored, for instance 1011 if the EDI UA determines that a signed receipt cannot be 1012 returned because it does not support the requested protocol 1013 format, so the EDI UA chooses not to process the message 1014 contents itself, should be specified in the MDN "disposition- 1015 field" as follows: 1017 Disposition: "disposition-mode"; 1018 failed/Failure: unsupported format 1020 The syntax of the "failed" "disposition-type" is general, 1021 Allowing the sending of any textual information along with the 1022 "failed" "disposition-type". For use in Internet EDI, the 1023 following "failed" values are defined: 1025 "Failure: unsupported format" 1026 "Failure: unsupported MIC-algorithms" 1028 5.3.2.3 Content Processing Errors 1030 When errors occur processing the received message content, the 1031 "disposition-field" should be set to the "processed" 1033 MIME-based Secure EDI February, 2001 1035 "disposition-type" value and the "error" "disposition-modifier" 1036 value. For use in Internet EDI, the following "error" 1037 "disposition-modifier" values are defined: 1039 "Error: decryption-failed" - the receiver could not decrypt the 1040 message contents. 1042 "Error: authentication-failed" - the receiver could not 1043 authenticate the sender. 1045 "Error: integrity-check-failed" - the receiver could not verify 1046 content integrity. 1048 "Error: unexpected-processing-error" - a catch-all for any 1049 additional processing 1050 errors. 1052 An example of how the "disposition-field" would look when 1053 content processing errors are detected is as follows: 1055 Disposition: "disposition-mode"; 1056 processed/Error: decryption-failed 1058 5.3.2.4 Content Processing Warnings 1060 Situations arise in EDI where even if a trading partner cannot 1061 be authenticated correctly, the trading partners still agree 1062 to continue processing the EDI transactions. Transaction 1063 reconciliation is done between the trading partners at a later 1064 time. In the content processing warning situations as described 1065 above, the "disposition-field' SHOULD be set to the "processed" 1066 "disposition-type" value, and the "warning" "disposition- 1067 modifier" value. For use in Internet EDI, the following 1068 "warning" "disposition-modifier" values are defined: 1070 "Warning: authentication-failed, processing continued" 1072 An example of how the "disposition-field" would look when 1073 content processing warnings are detected is as follows: 1075 Disposition: "disposition-mode"; processed/Warning: 1076 authentication-failed, processing continued 1078 5.4 Message Disposition Notification Processing 1080 5.4.1 Large File Processing 1082 Large EDI Interchanges sent via SMTP can be automatically 1084 MIME-based Secure EDI February, 2001 1086 fragmented by some message transfer agents. A subtype of 1087 message/partial, is defined in RFC 2045 [1] to allow large 1088 objects to be delivered as separate pieces of mail and to be 1089 automatically reassembled by the receiving user agent. Using 1090 message/partial, can help alleviate fragmentation of large 1091 messages by different message transfer agents, but does not 1092 completely eliminate the problem. It is still possible that a 1093 piece of a partial message, upon re-assembly, may prove to 1094 contain a partial message as well. This is allowed by the 1095 Internet standards, and it is the responsibility of the user 1096 agent to re-assemble the fragmented pieces. 1098 It is RECOMMENDED that the size of the EDI Interchange sent via 1099 SMTP be configurable so that if fragmentation is needed, then 1100 message/partial can be used to send the large EDI Interchange in 1101 smaller pieces. RFC 2045 [1] defines the use of Content-Type: 1102 message/partial. 1104 Note: Support of the message/partial content type for use in 1105 Internet EDI is OPTIONAL and in the absence of knowledge that 1106 the recipient supports partial it SHOULD NOT be used. 1108 The receiving UA is required to re-assemble the original 1109 message before sending the message disposition notification to 1110 the original sender of the message. A message disposition 1111 notification is used to specify the disposition of the entire 1112 message that was sent, and should not be returned by a 1113 processing UA until the entire message is received, even if the 1114 received message requires re-assembling. 1116 5.4.2 Example 1118 The following is an example of a signed receipt returned by a 1119 UA after successfully processing a MIME EDI content type. The 1120 sending trading partner has requested a return signed receipt. 1122 This example follows the S/MIME application/pkcs-7-signature 1123 format. 1125 NOTE: This example is provided as an illustration only, and is 1126 not considered part of the protocol specification. If an 1127 example conflicts with the protocol definitions specified above 1128 or in the other referenced RFCs, the example is wrong. 1130 To: 1131 Subject: 1132 From: 1133 Date: 1134 Mime-Version: 1.0 1136 MIME-based Secure EDI February, 2001 1138 Content-Type: multipart/signed; boundary="separator"; 1139 micalg=sha1; protocol="application/pkcs7-signature" 1141 --separator 1142 & Content-Type: multipart/report; report-type=disposition 1143 & notification; boundary="xxxxx" 1144 & 1145 & --xxxxx 1146 & Content-Type: text/plain 1147 & 1148 & The message sent to Recipient 1149 & has been received, the EDI Interchange was successfully 1150 & decrypted and its integrity was verified. In addition, the 1151 & sender of the message, Sender 1152 & was authenticated as the originator of the message. There is 1153 & no guarantee however that the EDI Interchange was 1154 & syntactically correct, or was received by the EDI 1155 & application. 1156 & 1157 & --xxxxx 1158 & Content-Type: message/disposition-notification 1159 & 1160 & Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2) 1161 & Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1162 & Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1163 & Original-Message-ID: <17759920005.12345@cyclonesoftware.com > 1164 & Disposition: automatic-action/MDN-sent-automatically; processed 1165 & Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1 1166 & 1167 & --xxxxx 1168 & Content-Type: message/rfc822 1169 & 1170 & To: 1171 & Subject: 1172 & 1173 & [additional header fields go here] 1174 & 1175 & --xxxxx- 1177 --separator 1178 Content-Type: application/pkcs7-signature; name=smime.p7s; 1179 Content-Transfer-Encoding: base64 1180 Content-Disposition: attachment; filename=smime.p7s 1182 MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg 1183 ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA 1184 oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU= 1186 --separator-- 1188 MIME-based Secure EDI February, 2001 1190 Notes: 1192 -The lines preceded with "&" is what the signature is calculated 1193 over. 1195 (For details on how to prepare the multipart/signed with 1196 protocol = "application/pkcs7-signature" see the "S/MIME 1197 Message Specification, PKCS Security Services for MIME".) 1199 Note: As specified by RFC 1892 [10], returning the original or 1200 portions of the original message in the third body part of the 1201 multipart/report is not required. This is an optional body part. 1202 It is RECOMMENDED that the received headers from the original 1203 message be placed in the third body part, as they can be helpful 1204 in tracking problems. 1206 Also note that the textual first body part of the 1207 multipart/report can be used to include a more detailed 1208 explanation of the error conditions reported by the disposition 1209 headers. The first body part of the multipart/report when used in 1210 this way, allows a person to better diagnose a problem in detail. 1212 6.0 Public key certificate handling 1214 6.1 Near term approach 1216 In the near term, the exchange of public keys and certification 1217 of these keys must be handled as part of the process of 1218 establishing a trading partnership. The UA and/or EDI application 1219 interface must maintain a database of public keys used for 1220 encryption or signatures, in addition to the mapping between EDI 1221 trading partner ID and RFC 822 [3] email address. The procedures 1222 for establishing a trading partnership and configuring the secure 1223 EDI messaging system might vary among trading partners and 1224 software packages. 1226 For systems which make use of X.509 certificates, it is 1227 RECOMMENDED that trading partners self-certify each other if an 1228 agreed upon certification authority is not used. It is highly 1229 RECOMMENDED that when trading partners are using S/MIME, that 1230 they also exchange public key certificates using the 1231 recommendations specified in the S/MIME Version 3 Message 1232 Specification. The message formats and S/MIME conformance 1233 requirements for certificate exchange are specified in this 1234 document. 1236 This applicability statement does NOT require the use of a 1237 certification authority. The use of a certification authority 1238 is therefore OPTIONAL. 1240 MIME-based Secure EDI February, 2001 1242 6.2 Long term approach 1244 In the long term, additional Internet-EDI standards may be 1245 developed to simplify the process of establishing a trading 1246 partnership, including the third party authentication of trading 1247 partners, as well as attributes of the trading relationship. 1249 7.0 Security Considerations 1251 This entire document is concerned with secure transport of 1252 business to business data, and considers both privacy and 1253 authentication issues. 1255 Extracted from S/MIME Version 2 Message Specification: 1256 40-bit encryption is considered weak by most cryptographers. Using 1257 weak cryptography offers little actual security over sending 1258 plaintext. However, other features of S/MIME, such as the 1259 specification of tripleDES and the ability to announce stronger 1260 cryptographic capabilities to parties with whom you communicate, 1261 allow senders to create messages that use strong encryption. Using 1262 weak cryptography is never recommended unless the only alternative 1263 is no cryptography. When feasible, sending and receiving agents 1264 should inform senders and recipients the relative cryptographic 1265 strength of messages. 1267 Extracted from S/MIME Version 2 Certificate Handling: 1268 When processing certificates, there are many situations where the 1269 processing might fail. Because the processing may be done by a 1270 user agent, a security gateway, or other program, there is no 1271 single way to handle such failures. Just because the methods to 1272 handle the failures has not been listed, however, the reader 1273 should not assume that they are not important. The opposite is 1274 true: if a certificate is not provably valid and associated with 1275 the message, the processing software should take immediate and 1276 noticable steps to inform the end user about it. 1278 Some of the many places where signature and certificate checking 1279 might fail include: 1281 - no certificate chain leads to a trusted CA 1282 - no ability to check the CRL for a certificate 1283 - an invalid CRL was received 1284 - the CRL being checked is expired 1285 - the certificate is expired 1286 - the certificate has been revoked 1288 There are certainly other instances where a certificate may be 1289 invalid, and it is the responsibility of the processing software 1291 MIME-based Secure EDI February, 2001 1293 to check them all thoroughly, and to decide what to do if the 1294 check fails. 1296 8.0 Acknowledgments 1298 Many thanks go out to the previous authors of the MIME-based 1299 Secure EDI IETF Draft: Mats Jansson. 1301 The authors would like to extend special thanks to Carl Hage, Jun 1302 Ding, Dale Moberg, and Karen Rosenthal for providing the team 1303 with valuable, and very thorough feedback. Without participants 1304 like those cited above, these efforts become hard to complete in 1305 a way useful to the users and implementers of the technology. 1307 In addition, the authors would like to thank Harald Alvestrand, 1308 Jim Galvin, and Roger Fajman for their guidance and input. 1310 9.0 References 1312 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail 1313 Extensions (MIME) 1314 Part One: Format of Internet Message Bodies", RFC 2045, 1315 December 02, 1996. 1317 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1318 Extensions (MIME) 1319 Part Two: Media Types", RFC 2046, December 02, 1996. 1321 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1322 Extensions (MIME) 1323 Part Five: Conformance Criteria and Examples", RFC 2049 , 1324 December 02, 1996. 1326 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1327 March 2, 1995. 1329 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1330 Messages", STD 11, RFC 822, August 13, 1982. 1332 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", 1333 RFC 2015, Sept. 1996. 1335 J. Callas, L.Donnerhacke, H. Finney, R.Thayer 1336 "OpenPGP Message Format", RFC 2440, Nov. 1998. 1338 [5] R. Fajman, "An Extensible Message Format for Message 1339 Disposition Notifications", RFC 2298, March 1998. 1341 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1343 MIME-based Secure EDI February, 2001 1345 Multiparts for MIME: Multipart/Signed and 1346 Multipart/Encrypted", RFC 1847, Oct. 3, 1995 1348 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 1349 821, August 1, 1982. 1351 [8] B. Ramsdell, "S/MIME Version 3 Message Specification; 1352 Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999. 1354 [9] T. Harding, R. Drummond, "Requirements for Inter-operable 1355 Internet EDI", Internet draft: draft-ietf-ediint-req09.txt 1356 September 1999. 1358 [10] G. Vaudreuil, "The Multipart/Report Content Type for the 1359 Reporting of Mail System Administrative Messages", RFC 1360 1892, January 15, 1996. 1362 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 1363 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1364 1997. 1366 [12] L. Deutsch, "GZIP File Format Specification Version 4.3", 1367 RFC 1952, May 23, 1996. 1369 10.0 Authors' Addresses 1371 tharding@cyclonecommerce.com 1372 Cyclone Commerce 1373 17767 North Perimeter Drive 1374 Scottsdale, Arizona 85255, USA 1376 Chuck Shih 1377 chuck.shih@gartner.com 1378 Gartner Group. 1379 251 River Oaks Parkway 1380 San Jose, CA 95134-1913 USA 1382 Rik Drummond 1383 drummond@onramp.com 1384 The Drummond Group 1385 5008 Bentwood Ct. 1386 Ft. Worth, TX 76132 USA