idnits 2.17.1 draft-ietf-ediint-as1-11.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 48 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 325 has weird spacing: '...non-use of...' == Line 346 has weird spacing: '...ication is re...' == Line 1014 has weird spacing: '...quested proto...' == Line 1239 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: The second part of the "disposition-mode" is set to "MDN-sent-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) ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2298 (ref. '5') (Obsoleted by RFC 3798) ** 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-req07 - 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 (~~), 8 warnings (==), 4 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 Software 3 Expires: Mar / 2000 R. Drummond 4 Drummond Group 5 Chuck Shih 6 Gartner Group 7 September, 1999 9 MIME-based Secure EDI 11 draft-ietf-ediint-as1-11.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 September 1999 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 Security Considerations 3 78 1.0 Introduction 3 79 2.0 Overview 4 80 2.1 Purpose of a security guideline for MIME EDI 4 81 2.2 Definitions 4 82 2.2.1. Terms 4 83 2.2.2 The secure transmission loop 5 84 2.2.3 Definition of receipts 5 85 2.3 Assumptions 6 86 2.3.1 EDI process assumptions 6 87 2.3.2 Flexibility assumptions 7 88 3.0 Referenced RFCs and their contribution 8 89 3.1 RFC 821 SMTP [7] 8 90 3.2 RFC 822 Text Message Format [3] 8 91 3.3 RFC 1847 MIME Security Multiparts [6] 9 92 3.4 RFC 1892 Multipart/report [10] 9 93 3.5 RFC 1767 EDI Content [2] 9 94 3.6 RFC 2015 PGP/MIME [4] 9 95 3.7 RFC 2045, 2046, and 2049 MIME [1] 9 96 3.8 RFC 2298 Message Disposition Notification [5] 9 97 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9 98 4.0 Structure of an EDI MIME message - Applicability 10 99 4.1 Introduction 10 100 4.2 Structure of an EDI MIME message - PGP/MIME 10 101 4.2.1 No encryption, no signature 10 103 MIME-based Secure EDI September 1999 105 4.2.2 No encryption, signature 10 106 4.2.3 Encryption, no signature 10 107 4.2.4 Encryption, signature 10 108 4.3 Structure of an EDI MIME message - S/MIME 11 109 4.3.1 No encryption, no signature 11 110 4.3.2 No encryption, signature 11 111 4.3.3 Encryption, no signature 11 112 4.3.4 Encryption, signature 11 113 5.0 Receipts 11 114 5.1 Introduction 11 115 5.2 Requesting a signed receipt 14 116 5.2.1 Additional Signed Receipt Considerations 16 117 5.3 Message Disposition Notification Format 17 118 5.3.1 Message Disposition Notification Extensions 18 119 5.3.2 Disposition Mode, Type, and Modifier Use 19 120 5.4 Message Disposition Notification Processing 21 121 5.4.1 Large File Processing 21 122 5.4.2 Example 23 123 6.0 Public key certificate handling 25 124 6.1 Near term approach 25 125 6.2 Long term approach 25 126 7.0 Acknowledgments 25 127 8.0 References 26 128 9.0 Authors' Addresses 27 130 Security Considerations 132 This document discusses the mechanisms, requirements and 133 Technologies necessary to conduct secure EDI over Internet using 134 either PGP/MIME or S/MIME. It further discusses the 135 implementation of encryption, digital signature, integrity and 136 signed-receipt for MIME objects transported over SMTP, HTTP or 137 FTP. 139 1.0 Introduction 141 Previous work on Internet EDI focused on specifying MIME content 142 Types for EDI data ([2] RFC 1767). This Applicability Statement 143 expands on RFC 1767 to specify use of a comprehensive set of data 144 security features, specifically data privacy, data 145 integrity/authenticity, non-repudiation of origin and non- 146 repudiation of receipt. This draft recognizes contemporary RFCs 147 and Internet drafts and is attempting to "re-invent" as little as 148 possible. 150 With an enhancement in the area of "receipts", as described below 151 (3.1.8), secure Internet MIME based EDI can be accomplished by 152 using and complying with the following RFCs: 154 MIME-based Secure EDI September 1999 156 -RFC 821 SMTP 157 -RFC 822 Text Message Formats 158 -RFC 1767 EDI Content Type 159 -RFC 1847 Security Multiparts for MIME 160 -RFC 1892 Multipart/Report 161 -RFC 2015 MIME/PGP 162 -RFC 2045 to 2049 MIME RFCs 163 -RFC 2298 Message Disposition Notification 164 -RFC 2630, 2633 S/MIME v3 Specification 166 Our intent here is to define clearly and precisely how these are 167 Used together, and what is required by user agents to be 168 compliant with this Applicability Statement. 170 2.0 Overview 172 2.1 Purpose of a security guideline for MIME EDI 174 The purpose of these specifications is to ensure interoperability 175 between EDI user agents, invoking some or all of the commonly 176 expected security features. This standard is also NOT limited to 177 strict EDI use, but applies to any electronic commerce 178 application where business data needs to be exchanged over the 179 Internet in a secure manner. 181 2.2 Definitions 183 2.2.1. Terms 185 EDI Electronic Data Interchange 187 EC Electronic Commerce 189 Receipt The functional message that is sent from a 190 receiver to a sender to acknowledge 191 receipt of an EDI/EC interchange. 193 Signed Receipt Same as above, but with a digital 194 signature. 196 Message Disposition The Internet messaging format used to 197 Notification convey a receipt. This term is used 198 interchangeably with receipt. A signed 199 MDN is a signed receipt. 201 Non-repudiation of NRR is a "legal event" that occurs when 202 Receipt (NRR) the original sender of an EDI/EC 203 interchange has verified the signed 204 receipt coming back from the receiver. 205 NRR IS NOT a functional or a technical 206 message. 208 MIME-based Secure EDI September 1999 210 PGP/MIME Digital envelope security based on the 211 Pretty Good Privacy (PGP) standard 212 (Zimmerman), integrated with MIME Security 213 Multiparts [6]. 215 S/MIME A format and protocol for adding 216 Cryptographic signature and/or encryption 217 services to Internet MIME messages. 219 2.2.2 The secure transmission loop 221 The functional requirements document, [9] "Requirements for 222 Inter-operable Internet EDI" (can be found at www.ietf.org), 223 Provides extensive information on EDI security and the 224 user/business related processes surrounding the need for and use 225 of EDI security. In this document, it is assumed that the reader 226 is familiar with the requirements document. 228 This document's focus is on the formats and protocols for 229 Exchanging EDI content that has had security applied to it using 230 the Internet's messaging transport. 232 The "secure transmission loop" for EDI involves one organization 233 sending a signed and encrypted EDI interchange to another 234 organization, requesting a signed receipt, followed later by the 235 receiving organization sending this signed receipt back to the 236 sending organization. In other words, the following transpires: 238 -The organization sending EDI/EC data signs and encrypts the 239 data using either PGP/MIME or S/MIME. In addition, the message 240 will request a signed receipt to be returned to the sender of 241 the message. 243 -The receiving organization decrypts the message and verifies 244 the signature, resulting in verified integrity of the data and 245 authenticity of the sender. 247 -The receiving organization then returns a signed receipt to 248 the sending organization in the form of a message disposition 249 notification message. This signed receipt will contain the 250 hash of the signature from the received message, indicating to 251 the sender that the received message was verified and/or 252 decrypted properly. 254 The above describes functionality which if implemented, would 255 Satisfy all security requirements. This specification, however, 256 leaves full flexibility for users to decide the degree to which 257 they want to deploy those security features with their EDI 259 MIME-based Secure EDI September 1999 261 trading partners. 263 2.2.3 Definition of receipts 265 The term used for both the functional activity and message for 266 acknowledging receipt of an EDI/EC interchange is receipt, or 267 signed receipt. The first term is used if the acknowledgment is 268 for an interchange resulting in a receipt which is NOT signed. 269 The second term is used if the acknowledgment is for an 270 interchange resulting in a receipt which IS signed. 272 The "rule" is: 274 - If a receipt is requested, explicitly specifying that the 275 receipt be signed, then the receipt MUST be returned with a 276 signature. 278 - If a receipt is requested, explicitly specifying that the 279 receipt be signed, but the recipient cannot support the 280 requested protocol format or requested MIC algorithms, then a 281 receipt, either signed or unsigned SHOULD be returned. 283 - If a signature is not explicitly requested, or if the signed 284 receipt request parameter is not recognized by the UA, a 285 receipt may or may not be returned. This behavior is 286 consistent with the MDN RFC 2298. 288 A term often used in combination with receipts is "Non- 289 Repudiation of Receipt (NRR). NRR refers to a legal event which 290 occurs only when the original sender of an interchange has 291 verified the signed receipt coming back from recipient of the 292 message. Note that NRR is not possible without signatures. 294 2.3 Assumptions 296 2.3.1 EDI process assumptions 298 -Encrypted object is an EDI Interchange 300 This specification assumes that a typical EDI interchange is the 301 lowest level object that will be subject to security services. 303 In ANSI X12, this means anything between, and including segments 304 ISA and IEA. In EDIFACT, this means anything between, and 305 including, segments UNA/UNB and UNZ. In other words, the EDI 306 interchanges including envelope segments remain intact and 307 unreadable during secure transport. 309 -EDI envelope headers are encrypted 311 MIME-based Secure EDI September 1999 313 Congruent with the above statement, EDI envelope headers are NOT 314 visible in the MIME package. In order to optimize VAN-to- 315 Internet routing, work may need to be done in the future to 316 define ways to pull out some of the envelope information to make 317 them visible, however, this specification does not go into any 318 detail on that. 320 -X12.58 and UN/EDIFACT security considerations 322 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 323 defined internal provisions for security. X12.58 is the 324 security mechanism for ANSI X12 and AUTACK provides security for 325 EDIFACT. This specification DOES NOT dictate use or non-use of 326 these security standards. They are both fully compatible, 327 though possibly redundant, with this specification. 329 2.3.2 Flexibility assumptions 331 -Encrypted or un-encrypted data 333 This specification allows for EDI message exchange where the EDI 334 Data can either be un-protected or protected by means of 335 encryption. 337 -Signed or un-signed data 339 This specification allows for EDI message exchange with or 340 Without digital signature of the original EDI transmission. 342 -Use of receipt or not 344 This specification allows for EDI message transmission with or 345 Without a request for receipt notification. If a signed receipt 346 notification is requested however, a mic value is REQUIRED as 347 part of the returned receipt, unless an error condition occurs 348 in which a mic value cannot be returned. In error cases, an un- 349 signed receipt or MDN SHOULD be returned with the correct 350 "disposition modifier" error value. 352 -Formatting choices 354 This specification defines the use of two methods for formatting 355 EDI contents that have security applied to it: 357 -PGP/MIME 358 -S/MIME 360 This specification relies on the guidelines set forth in RFC 361 2015, as reflected in [4] "MIME Security with Pretty Good 362 Privacy" (PGP), and RFC 2633/ 2630 [8] "S/MIME Version 3 364 MIME-based Secure EDI September 1999 366 Message Specification; Cryptographic Message Syntax". Compliance 367 with this specification REQUIRES the use of PGP/MIME or S/MIME 368 as defined in this Applicability statement, and the [9] 369 "Requirements for Inter-operable Internet EDI" draft. 371 -Hash function, message digest choices 373 When a signature is used, it is RECOMMENDED that the SHA1 hash 374 algorithm be used for all outgoing messages, and that both MD5 375 and SHA1 be supported for incoming messages. 377 In summary, the following eight permutations are possible in any 378 given trading relationship: 380 (1) Sender sends un-encrypted data, does NOT request a receipt. 382 (2) Sender sends un-encrypted data, requests a signed or 383 unsigned receipt. The receiver sends back the signed or 384 unsigned receipt. 386 (3) Sender sends encrypted data, does NOT request a receipt. 388 (4) Sender sends encrypted data, requests a signed or unsigned 389 receipt. The receiver sends back the signed or un-signed 390 receipt. 392 (5) Sender sends signed data, does NOT request a signed or un- 393 signed receipt. 395 (6) Sender sends signed data, requests a signed or un-signed 396 receipt. Receiver sends back the signed or un-signed 397 receipt. 399 (7) Sender sends encrypted and signed data, does NOT request a 400 signed or un-signed receipt. 402 (8) Sender sends encrypted and signed data, requests a signed or 403 un-signed receipt. Receiver sends back the signed or un- 404 signed receipt. 406 NOTE: Users can choose any of the eight possibilities, but only 407 example (8), when a signed receipt is requested, offers the 408 whole suite of security features described in the "Secure 409 transmission loop" above. 411 3.0 Referenced RFCs and their contribution 413 3.1 RFC 821 SMTP [7] 415 This is the core mail transfer standard that all MTAs need to 416 Adhere to. 418 MIME-based Secure EDI September 1999 420 3.2 RFC 822 Text Message Format [3] 422 Defines message header fields and the parts making up a message. 424 3.3 RFC 1847 MIME Security Multiparts [6] 426 This document defines security multiparts for MIME: 427 multipart/encrypted and multipart/signed. 429 3.4 RFC 1892 Multipart/report [10] 431 This RFC defines the use of the multipart/report content type, 432 something that the MDN RFC 2298 builds upon. 434 3.5 RFC 1767 EDI Content [2] 436 This RFC defines the use of content type "application" for ANSI 437 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 438 Mutually defined EDI (application/EDI-Consent). 440 3.6 RFC 2015 PGP/MIME [4] 442 This RFC defines the use of content types "multipart/encrypted", 443 "multipart/signed", "application/pgp encrypted" and 444 "application/pgp-signature" for defining MIME PGP content. 446 3.7 RFC 2045, 2046, and 2049 MIME [1] 448 These are the basic MIME standards, upon which all MIME related 449 RFCs build, including this one. Key contributions include 450 definition of "content type", "sub-type" and "multipart", as well 451 as encoding guidelines, which establishes 7-bit US-ASCII as the 452 canonical character set to be used in Internet messaging. 454 3.8 RFC 2298 Message Disposition Notification [5] 456 This Internet RFC defines how a message disposition notification 457 (MDN) is requested, and the format and syntax of the MDN. The MDN 458 is the basis upon which receipts and signed receipts are defined 459 in this and the "Requirements" specification. 461 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 463 This specification describes how MIME shall carry CMS Objects. 465 4.0 Structure of an EDI MIME message - Applicability 467 4.1 Introduction 469 The structures below are described hierarchically in terms of 471 MIME-based Secure EDI September 1999 473 Which RFC's are applied to form the specific structure. For 474 details of how to code in compliance with all RFC's involved, 475 turn directly to the RFC's referenced. The "requirements 476 document" has several examples described in an Appendix for those 477 interested. 479 Also, these structures describe the initial transmission only. 480 Receipts, and requests for receipts are handled in section 5. 482 4.2 Structure of an EDI MIME message - PGP/MIME 484 4.2.1 No encryption, no signature 486 -RFC822/2045 487 -RFC1767 (application/EDIxxxx) 489 4.2.2 No encryption, signature 491 -RFC822/2045 492 -RFC1847 (multipart/signed) 493 -RFC1767 (application/EDIxxxx) 494 -RFC2015 (application/pgp-signature) 496 4.2.3 Encryption, no signature 498 -RFC822/2045 499 -RFC1847 (multipart/encrypted) 500 -RFC2015 (application/pgp-encrypted) 501 -"Version: 1" 502 -RFC2015 (application/octet-stream) 503 -RFC1767 (application/EDIxxxx) (encrypted) 505 4.2.4 Encryption, signature 507 -RFC822/2045 508 -RFC1847 (multipart/encrypted) 509 -RFC2015 (application/pgp-encrypted) 510 -"Version: 1" 511 -RFC2015 (application/octet-stream) 512 -RFC1847 (multipart/signed)(encrypted) 513 -RFC1767 (application/EDIxxxx)(encrypted) 514 -RFC2015 (application/pgp-signature)(encrypted) 516 4.3 Structure of an EDI MIME message - S/MIME 518 4.3.1 No encryption, no signature 520 -RFC822/2045 521 -RFC1767 (application/EDIxxxx) 523 MIME-based Secure EDI September 1999 525 4.3.2 No encryption, signature 527 -RFC822/2045 528 -RFC1847 (multipart/signed) 529 -RFC1767 (application/EDIxxxx) 530 -RFC2633 (application/pkcs7-signature) 532 4.3.3 Encryption, no signature 534 -RFC822/2045 535 -RFC2633 (application/pkcs7-mime) 536 -RFC1767 (application/EDIxxxx) (encrypted) 538 4.3.4 Encryption, signature 540 -RFC822/2045 541 -RFC2633 (application/pkcs7-mime) 542 -RFC1847 (multipart/signed) (encrypted) 543 -RFC1767 (application/EDIxxxx) (encrypted) 544 -RFC2633 (application/pkcs7-signature) (encrypted) 546 5.0 Receipts 548 5.1 Introduction 550 In order to support non-repudiation of receipt (NRR), a signed 551 receipt, based on digitally signing a message disposition 552 notification, is to be implemented by a receiving trading 553 partner's UA (User Agent). The message disposition notification, 554 specified by RFC 2298 is digitally signed by a receiving trading 555 partner as part of a multipart/signed MIME message. 557 The following support for signed receipts is REQUIRED: 559 1). The ability to create a multipart/report; where the report- 560 type = disposition-notification. 562 2). The ability to calculate a message integrity check (MIC) on 563 the received message. The calculated MIC value will be 564 returned to the sender of the message inside the signed 565 receipt. 567 4). The ability to create a multipart/signed content with the 568 message disposition notification as the first body part, and 569 the signature as the second body part. 571 5). The ability to return the signed receipt to the sending 572 trading partner. 574 The signed receipt is used to notify a sending trading partner 575 that requested the signed receipt that: 577 MIME-based Secure EDI September 1999 579 1). The receiving trading partner acknowledges receipt of the 580 sent EDI Interchange. 582 2). If the sent message was signed, then the receiving trading 583 partner has authenticated the sender of the EDI Interchange. 585 3). If the sent message was signed, then the receiving trading 586 partner has verified the integrity of the sent EDI 587 Interchange. 589 Regardless of whether the EDI Interchange was sent in S/MIME or 590 PGP/MIME format, the receiving trading partner's UA MUST provide 591 the following basic processing: 593 1). If the sent EDI Interchange is encrypted, then the encrypted 594 symmetric key and initialization vector (if applicable) is 595 decrypted using the receiver's private key. 597 2). The decrypted symmetric encryption key is then used to 598 decrypt the EDI Interchange. 600 3). The receiving trading partner authenticates signatures in a 601 message using the sender's public key. The authentication 602 algorithm performs the following: 604 a). The message integrity check (MIC or Message Digest), 605 is decrypted using the sender's public key. 607 b). A MIC on the signed contents (the MIME header and 608 encoded EDI object, as per RFC 1767) in the message 609 received is calculated using the same one-way hash 610 function that the sending trading partner used. 612 c). The MIC extracted from the message that was sent, and 613 the MIC calculated using the same one-way hash function 614 that the sending trading partner used is compared for 615 equality. 617 4). The receiving trading partner formats the MDN and sets the 618 calculated MIC into the "Received-content-MIC" extension 619 field. 621 5). The receiving trading partner creates a multipart/signed MIME 622 message according to RFC 1847. 624 6). The MDN is the first part of the multipart/signed message, 625 and the digital signature is created over this MDN, including 626 its MIME headers. 628 7). The second part of the multipart/signed message contains the 630 MIME-based Secure EDI September 1999 632 digital signature. The "protocol" option specified in the 633 second part of the multipart/signed is as follows: 635 S/MIME: protocol = "application/pkcs-7-signature" 637 PGP/MIME: protocol = "application/pgp-signature" 639 8). The signature information is formatted according to S/MIME or 640 PGP/MIME specifications. 642 The EDI Interchange and the RFC 1767 MIME EDI content header, can 643 actually be part of a multi-part MIME content-type. When the EDI 644 Interchange is part of a multi-part MIME content-type, the MIC 645 MUST be calculated across the entire multi-part content, 646 including the MIME headers. 648 The signed MDN, when received by the sender of the EDI 649 Interchange can be used by the sender: 651 1). As an acknowledgment that the EDI Interchange sent, was 652 delivered and acknowledged by the receiving trading 653 partner. The receiver does this by returning the original 654 message id of the sent message in the MDN portion of the 655 signed receipt. 657 2). As an acknowledgment that the integrity of the EDI 658 Interchange was verified by the receiving trading partner. 659 The receiver does this by returning the calculated MIC of 660 the received EDI Interchange (and 1767 MIME headers) in the 661 "Received-content-MIC" field of the signed MDN. 663 3). As an acknowledgment that the receiving trading partner has 664 authenticated the sender of the EDI Interchange. 666 4). As a non-repudiation of receipt when the signed MDN is 667 successfully verified by the sender with the receiving 668 trading partner's public key and the returned mic value 669 inside the MDN is the same as the digest of the original 670 message. 672 5.2 Requesting a signed receipt 674 Message Disposition Notifications are requested as per RFC 2298, 675 "An Extensible Message Format for Message Disposition 676 Notification". A request that the receiving user agent issue a 677 message disposition notification is made by placing the following 678 header into the message to be sent: 680 MDN-request-header = "Disposition-notification-to" ":" 681 mail-address 683 MIME-based Secure EDI September 1999 685 The mail-address field is specified as an RFC 822 user@domain 686 address, and is the return address for the message disposition 687 notification. 689 In addition to requesting a message disposition notification, a 690 message disposition notification that is digitally signed, or 691 what has been referred to as a signed receipt, can be requested 692 by placing the following in the message header following the 693 "Disposition-Notification-To" line. 695 Disposition-notification-options = 696 "Disposition-Notification-Options" ":" 697 disposition-notification-parameters 699 where 701 disposition-notification-parameters = 702 parameter *(";" parameter) 704 where 706 parameter = attribute "=" importance ", " 1#value" 708 where 710 importance = "required" | "optional" 712 So the Disposition-notification-options string could be: 714 signed-receipt-protocol=optional, ; 715 signed-receipt-micalg=optional, , ,...; 717 The currently supported values for are 718 "pkcs7-signature", for the S/MIME detached signature format, or 719 "pgp-signature", for the pgp signature format. 721 The currently supported values for MIC algorithm values are: 723 Algorithm Value 724 used 726 MD5 md5 727 SHA-1 sha1 729 (Historical note: some early implementations of EDIINT emitted 730 and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) 731 Receiving agents SHOULD be able to recover gracefully from a 732 micalg parameter value that they do not recognize. 734 MIME-based Secure EDI September 1999 736 An example of a formatted options line would be as follows: 738 Disposition-notification-options: 739 signed-receipt-protocol=optional, pkcs7-signature; 740 signed-receipt-micalg=optional, sha1, md5 742 The semantics of the "signed-receipt-protocol" parameter is as 743 follows: 745 1). The "signed-receipt-protocol" parameter is used to request a 746 signed receipt from the recipient trading partner. The 747 "signed-receipt-protocol" parameter also specifies the format 748 in which the signed receipt should be returned to the 749 requester. 751 The "signed-receipt-micalg" parameter is a list of MIC 752 Algorithms preferred by the requester for use in signing the 753 returned receipt. The list of MIC algorithms should be 754 honored by the recipient from left to right. 756 Both the "signed-receipt-protocol" and the "signed-receipt- 757 micalg" option parameters are REQUIRED when requesting a 758 signed receipt. 760 2). The "importance" attribute of "Optional" is defined in the 761 MDN RFC 2298 and has the following meaning: 763 Parameters with an importance of "Optional" permit a UA that 764 does not understand the particular options parameter to still 765 generate a MDN in response to a request for a MDN. A UA that 766 does not understand the "signed-receipt-protocol" parameter, 767 or the "signed-receipt-micalg" will obviously not return a 768 signed receipt. 770 The importance of "Optional" is used for the signed receipt 771 parameters because it is RECOMMENDED that an MDN be returned 772 to the requesting trading partner even if the recipient could 773 not sign it. 774 The returned MDN will contain information on the disposition 775 of the message as well as why the MDN could not be signed. 776 See the Disposition field in section 5.3 for more 777 information. 779 Within an EDI trading relationship, if a signed receipt is 780 expected and is not returned, then the validity of the 781 transaction is up to the trading partners to resolve. In 782 general, if a signed receipt is required in the trading 783 relationship and is not received, the transaction will likely 784 not be considered valid. 786 MIME-based Secure EDI September 1999 788 5.2.1 Additional Signed Receipt Considerations 790 The "rules" stated in Section 2.2.3 for signed receipts are as 791 follows: 793 1). When a receipt is requested, explicitly specifying that the 794 receipt be signed, then the receipt MUST be returned with a 795 signature. 797 2). When a receipt is requested, explicitly specifying that the 798 receipt be signed, but the recipient cannot support either 799 the requested protocol format, or requested MIC algorithms, 800 then either a signed or unsigned receipt SHOULD be returned. 802 3). When a signature is not explicitly requested, or if the 803 signed receipt request parameter is not recognized by the UA, 804 then no receipt, an unsigned receipt, or a signed receipt MAY 805 be returned by the recipient. 807 NOTE: For Internet EDI, it is RECOMMENDED that when a signature 808 is not explicitly requested, or if parameters are not recognized, 809 that the UA send back at a minimum, an unsigned receipt. If a 810 signed receipt however was always returned as a policy, whether 811 requested or not, then any false unsigned receipts can be 812 repudiated. 814 When a request for a signed receipt is made, but there is an 815 error in processing the contents of the message, a signed receipt 816 MUST still be returned. The request for a signed receipt SHALL 817 still be honored, though the transaction itself may not be valid. 818 The reason for why the contents could not be processed MUST be 819 set in the "disposition-field". 821 When a request for a signed receipt is made, the "Received- 822 content-MIC" MUST always be returned to the requester. The 823 "Received-content-MIC" MUST be calculated as follows: 825 - For any signed messages, the MIC to be returned is calculated 826 on the RFC1767 MIME header and content. Canonicalization as 827 specified in RFC 1848 MUST be performed before the MIC is 828 calculated, since the sender requesting the signed receipt was 829 also REQUIRED to canonicalize. 831 - For encrypted, unsigned messages, the MIC to be returned is 832 calculated on the decrypted RFC 1767 MIME header and content. 833 The content after decryption MUST be canonicalized before the 834 MIC is calculated. 836 - For unsigned, unencrypted messages, the MIC MUST be calculated 837 over the message contents prior to Content-Transfer-Encoding or 838 Content-Encoding, and without the MIME or any other RFC 822 840 MIME-based Secure EDI September 1999 842 headers, since these are sometimes altered or reordered by MTAs. 844 5.3 Message Disposition Notification Format 846 The format of a message disposition notification is specified in 847 RFC 2298 For use in Internet EDI, the following format will be 848 used: 850 - content-type - per RFC 1892 and the RFC 2298 specification 852 - reporting-ua-field - per RFC 2298 specification 854 - MDN-gateway-field - per RFC 2298 specification 856 - original-recipient-field - per RFC 2298 specification 858 - final-recipient-field - per RFC 2298 specification 860 - original-message-id-field - per RFC 2298 specification 862 - disposition-field - the following "disposition-mode" 863 values SHOULD be used for 864 Internet EDI: 866 "automatic-action" - The disposition described by the 867 disposition type was a result of an 868 automatic action, rather than an explicit 869 instruction by the user for this message. 871 "manual-action" - The disposition described by the 872 disposition type was a result of an 873 explicit instruction by the user rather 874 than some sort of automatically performed 875 action. 877 "MDN-sent-automatically" - The MDN was sent because the UA had 878 previously been configured to do 879 so. 881 "MDN-sent-manually" - The user explicitly gave permission for 882 this particular MDN to be sent. "MDN- 883 sent-manually" is meaningful with 884 "manual-action", but not with 885 "automatic-action". 887 - disposition-field - the following "disposition-type" values 888 SHOULD be used for Internet EDI: 890 "processed" - The message has been processed in some manner 891 (e.g., printed, faxed, forwarded, gatewayed) 893 MIME-based Secure EDI September 1999 895 without being displayed to the user. The user 896 may or may not see the message later. 898 "failed" - A failure occurred that prevented the proper 899 generation of an MDN. More information about the 900 cause of the failure may be contained in a 901 Failure field. The "failed" disposition type is 902 not to be used for the situation in which there 903 is some problem in processing the message other 904 than interpreting the request for an MDN. The 905 "processed" or other disposition type with 906 appropriate disposition modifiers is to be used 907 in such situations. 909 - disposition-field - the following "disposition-modifier" 910 values SHOULD be used for Internet EDI: 912 "error" - An error of some sort occurred that prevented 913 successful processing of the message. Further 914 information is contained in an Error field. 916 "warning" - The message was successfully processed but some 917 sort of exceptional condition occurred. Further 918 information is contained in a Warning field. 920 5.3.1 Message Disposition Notification Extensions 922 The following "extension field" will be added in order to support 923 signed receipts for RFC 1767 MIME content type and multipart MIME 924 content types that include the RFC 1767 MIME content type. The 925 extension field" defined below follows the "disposition-field" in 926 the MDN. 928 The "Received-content-MIC" extension field is set when the 929 integrity of the received message is verified. The MIC is the 930 base64 encoded quantity computed over the received message with a 931 hash function. For details of "what" the "Received-content-MIC" 932 should be calculated over, see Section 5.2.1. The algorithm used 933 to calculate the "Received-content-MIC" value MUST be the same as 934 the "micalg" value used by the sender in the multipart/signed 935 message. When no signature is received, or the mic-alg parameter 936 is not supported then it is RECOMMENDED that the SHA1 algorithm 937 be used to calculate the MIC on the received message or message 938 contents. 940 This field is set only when the contents of the message are 941 processed successfully. This field is used in conjunction with 942 the recipient's signature on the MDN in order for the sender to 943 verify "non-repudiation of receipt". 945 MIME-based Secure EDI September 1999 947 - extension field = "Received-content-MIC" ":" MIC 949 where: 951 = "," 953 = the result of one way hash function, base64 954 encoded. 956 < micalg> = the micalg value defined in RFC1847, an IANA 957 registered MIC algorithm ID token. 959 5.3.2 Disposition Mode, Type, and Modifier Use 961 Guidelines for use of the "disposition-mode", "disposition- 962 type", and "disposition-modifier" fields within Internet EDI are 963 discussed in this section. The "disposition-mode", "disposition- 964 type', and "disposition-modifier' fields are described in detail 965 in RFC 2298. The "disposition-mode', "disposition-type" and 966 "disposition-modifier" values SHOULD be used as follows: 968 5.3.2.1 Successful Processing 970 When the request for a receipt or signed receipt, and the 971 received message contents are successfully processed by the 972 receiving EDI UA, a receipt or MDN SHOULD be returned with the 973 "disposition-type" set to 'processed'. When the MDN is sent 974 automatically by the EDI UA, and there is no explicit way for a 975 user to control the sending of the MDN, then the first part of 976 the "disposition-mode" should be set to "automatic-action". When 977 the MDN is being sent under user configurable control, then the 978 first part of the "disposition-mode" should be set to "manual- 979 action". Since a request for a signed receipt should always be 980 honored, the user MUST not be allowed to configure the UA to not 981 send a signed receipt when the sender requests one. 983 The second part of the "disposition-mode" is set to "MDN-sent- 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 MIME-based Secure EDI September 1999 998 Disposition: automatic-action/MDN-sent-automatically; processed 1000 Note this specification does not restrict the use of the 1001 "disposition-mode" to just automatic actions. Manual actions are 1002 valid as long as it is kept in mind that a request for a signed 1003 receipt MUST be honored. 1005 5.3.2.2 Unprocessed Content 1007 The request for a signed receipt requires the use of two 1008 "disposition-notification-options", which specify the protocol 1009 format of the returned signed receipt, and the MIC algorithm 1010 used to calculate the mic over the message contents. The 1011 "disposition-field" values that should be used in the case where 1012 the message content is being rejected or ignored, for instance 1013 if the EDI UA determines that a signed receipt cannot be 1014 returned because it does not support the requested protocol 1015 format, so the EDI UA chooses not to process the message 1016 contents itself, should be specified in the MDN "disposition- 1017 field" as follows: 1019 Disposition: "disposition-mode"; 1020 failed/Failure: unsupported format 1022 The syntax of the "failed" "disposition-type" is general, 1023 Allowing the sending of any textual information along with the 1024 "failed" "disposition-type". For use in Internet EDI, the 1025 following "failed" values are defined: 1027 "Failure: unsupported format" 1028 "Failure: unsupported MIC-algorithms" 1030 5.3.2.3 Content Processing Errors 1032 When errors occur processing the received message content, the 1033 "disposition-field" should be set to the "processed" 1034 "disposition-type" value and the "error" "disposition-modifier" 1035 value. For use in Internet EDI, the following "error" 1036 "disposition-modifier" values are defined: 1038 "Error: decryption-failed" - the receiver could not decrypt the 1039 message contents. 1041 "Error: authentication-failed" - the receiver could not 1042 authenticate the sender. 1044 "Error: integrity-check-failed" - the receiver could not verify 1045 content integrity. 1047 MIME-based Secure EDI September 1999 1049 "Error: unexpected-processing-error" - a catch-all for any 1050 additional processing 1051 errors. 1053 An example of how the "disposition-field" would look when 1054 content processing errors are detected is as follows: 1056 Disposition: "disposition-mode"; 1057 processed/Error: decryption-failed 1059 5.3.2.4 Content Processing Warnings 1061 Situations arise in EDI where even if a trading partner cannot 1062 be authenticated correctly, the trading partners still agree 1063 to continue processing the EDI transactions. Transaction 1064 reconciliation is done between the trading partners at a later 1065 time. In the content processing warning situations as described 1066 above, the "disposition-field' SHOULD be set to the "processed" 1067 "disposition-type" value, and the "warning" "disposition- 1068 modifier" value. For use in Internet EDI, the following 1069 "warning" "disposition-modifier" values are defined: 1071 "Warning: authentication-failed, processing continued" 1073 An example of how the "disposition-field" would look when 1074 content processing warnings are detected is as follows: 1076 Disposition: "disposition-mode"; processed/Warning: 1077 authentication-failed, processing continued 1079 5.4 Message Disposition Notification Processing 1081 5.4.1 Large File Processing 1083 Large EDI Interchanges sent via SMTP can be automatically 1084 fragmented by some message transfer agents. A subtype of 1085 message, "partial", is defined in RFC 2045 [1] to allow large 1086 objects to be delivered as separate pieces of mail and to be 1087 automatically reassembled by the receiving user agent. Using 1088 message, "partial", can help alleviate fragmentation of large 1089 messages by different message transfer agents, but does not 1090 completely eliminate the problem. It is still possible that a 1091 piece of a partial message, upon re-assembly, may prove to 1092 contain a partial message as well. This is allowed by the 1093 Internet standards, and it is the responsibility of the user 1094 agent to re-assemble the fragmented pieces. 1096 It is RECOMMENDED that the size of the EDI Interchange sent via 1097 SMTP be configurable so that if fragmentation does occur, then 1099 MIME-based Secure EDI September 1999 1101 message, "partial" can be used to send the large EDI 1102 Interchange in smaller pieces. RFC 2045 [1] defines the use of 1103 Content-Type: message/partial. Support of the message/partial 1104 content type for use in Internet EDI is OPTIONAL. 1106 The receiving UA is required to re-assemble the original 1107 message before sending the message disposition notification to 1108 the original sender of the message. A message disposition 1109 notification is used to specify the disposition of the entire 1110 message that was sent, and should not be returned by a 1111 processing UA until the entire message is received, even if the 1112 received message requires re-assembling. 1114 In general, EDI content compresses well, since there is 1115 Repetitive data in most EDI Interchanges. Instead of 1116 implementing the message/partial, compression of the EDI 1117 Interchange can be done after the signature is applied to the 1118 EDI Interchange, and before encryption. When no signature is 1119 applied, then compression is applied before the encryption. 1120 Compression is an alternative solution to implementing Content- 1121 Type: message/partial when sending large EDI Interchanges on 1122 the Internet. 1124 Applying compression before encryption strengthens 1125 cryptographic security since repetitious strings are reduced. 1126 This sequence of signature, compression, then encryption, or 1127 compression then encryption, is consistent with the order in 1128 which PGP implementations handle compression. 1130 Note: Compression is done automatically when using PGP 1131 encryption. 1133 The MIME standards [1], do not define a way in which to convey 1134 that a message has been compressed. However, RFC 2045 [1] does 1135 allow the definition of additional MIME header fields to 1136 further describe the content of a message. 1138 RFC 2068 [11], the HTTP/1.1 specification does define a 1139 Content-Encoding field that is primarily used to convey 1140 compression information: 1142 Content-Encoding = "Content-Encoding" ":" content-coding 1144 where content-coding can take on the values of "gzip" or 1145 "compress". The gzip compression standard is further described 1146 in RFC 1952 [12], and compress is the standard UNIX file 1147 compression program. Both gzip and compress are registered with 1148 IANA. 1150 Trading partners can adopt the use of the Content-Encoding 1151 header if they need to compress their EDI data and convey the 1153 MIME-based Secure EDI September 1999 1155 compression type to their trading partners. 1157 5.4.2 Example 1159 The following is an example of a signed receipt returned by a 1160 UA after successfully processing a MIME EDI content type. The 1161 Sending trading partner has requested a return signed receipt. 1163 This example follows the S/MIME application/pkcs-7-signature 1164 format. 1166 NOTE: This example is provided as an illustration only, and is 1167 not considered part of the protocol specification. If an 1168 example conflicts with the protocol definitions specified above 1169 or in the other referenced RFCs, the example is wrong. 1171 To: 1172 Subject: 1173 From: 1174 Date: 1175 Mime-Version: 1.0 1176 Content-Type: multipart/signed; boundary="separator"; 1177 micalg=sha1; protocol="application/pkcs7-signature" 1179 --separator 1180 & Content-Type: multipart/report; report-type=disposition 1181 & notification; boundary="xxxxx" 1182 & 1183 & --xxxxx 1184 & Content-Type: text/plain 1185 & 1186 & The message sent to Recipient 1187 & has been received, the EDI Interchange was successfully 1188 & decrypted and its integrity was verified. In addition, the 1189 & sender of the message, Sender 1190 & was authenticated as the originator of the message. There is 1191 & no guarantee however that the EDI Interchange was 1192 & syntactically correct, or was received by the EDI 1193 & application. 1194 & 1195 & --xxxxx 1196 & Content-Type: message/disposition-notification 1197 & 1198 & Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2) 1199 & Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1200 & Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1201 & Original-Message-ID: <17759920005.12345@cyclonesoftware.com > 1202 & Disposition: automatic-action/MDN-sent-automatically; processed 1203 & Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1 1204 & 1206 MIME-based Secure EDI September 1999 1208 & --xxxxx 1209 & Content-Type: message/rfc822 1210 & 1211 & To: 1212 & Subject: 1213 & 1214 & [additional header fields go here] 1215 & 1216 & --xxxxx- 1218 --separator 1219 Content-Type: application/pkcs7-signature; name=smime.p7s; 1220 Content-Transfer-Encoding: base64 1221 Content-Disposition: attachment; filename=smime.p7s 1223 MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg 1224 ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA 1225 oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU= 1227 --separator-- 1229 Notes: 1231 -The lines preceded with "&" is what the signature is calculated 1232 over. 1234 (For details on how to prepare the multipart/signed with 1235 protocol = "application/pkcs7-signature" see the "S/MIME 1236 Message Specification, PKCS Security Services for MIME".) 1238 Note: As specified by RFC 1892 [10], returning the original or 1239 portions of the original message in the third body part of the 1240 multipart/report is not required. This is an optional body part. 1241 It is RECOMMENDED that the received headers from the original 1242 message be placed in the third body part, as they can be helpful 1243 in tracking problems. 1245 Also note that the textual first body part of the 1246 multipart/report can be used to include a more detailed 1247 explanation of the error conditions reported by the disposition 1248 headers. The first body part of the multipart/report when used in 1249 this way, allows a person to better diagnose a problem in detail. 1251 6.0 Public key certificate handling 1253 6.1 Near term approach 1255 In the near term, the exchange of public keys and certification 1256 of these keys must be handled as part of the process of 1257 establishing a trading partnership. The UA and/or EDI application 1259 MIME-based Secure EDI September 1999 1261 interface must maintain a database of public keys used for 1262 encryption or signatures, in addition to the mapping between EDI 1263 trading partner ID and RFC 822 [3] email address. The procedures 1264 for establishing a trading partnership and configuring the secure 1265 EDI messaging system might vary among trading partners and 1266 Software packages. 1268 For systems which make use of X.509 certificates, it is 1269 RECOMMENDED that trading partners self-certify each other if an 1270 agreed upon certification authority is not used. It is highly 1271 RECOMMENDED that when trading partners are using S/MIME, that 1272 they also exchange public key certificates using the 1273 recommendations specified in the S/MIME Version 3 Message 1274 Specification. The message formats and S/MIME conformance 1275 requirements for certificate exchange are specified in this 1276 document. 1278 This applicability statement does NOT require the use of a 1279 certification authority. The use of a certification authority 1280 is therefore OPTIONAL. 1282 6.2 Long term approach 1284 In the long term, additional Internet-EDI standards may be 1285 developed to simplify the process of establishing a trading 1286 partnership, including the third party authentication of trading 1287 partners, as well as attributes of the trading relationship. 1289 7.0 Acknowledgments 1291 Many thanks go out to the previous authors of the MIME-based 1292 Secure EDI IETF Draft: Mats Jansson. 1294 The authors would like to extend special thanks to Carl Hage, Jun 1295 Ding, Dale Moberg, and Karen Rosenthal for providing the team 1296 with valuable, and very thorough feedback. Without participants 1297 like those cited above, these efforts become hard to complete in 1298 a way useful to the users and implementers of the technology. 1300 In addition, the authors would like to thank Harald Alvestrand, 1301 Jim Galvin, and Roger Fajman for their guidance and input. 1303 8.0 References 1305 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail 1306 Extensions (MIME) 1307 Part One: Format of Internet Message Bodies", RFC 2045, 1308 December 02, 1996. 1310 MIME-based Secure EDI September 1999 1312 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1313 Extensions (MIME) 1314 Part Two: Media Types", RFC 2046, December 02, 1996. 1316 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1317 Extensions (MIME) 1318 Part Five: Conformance Criteria and Examples", RFC 2049 , 1319 December 02, 1996. 1321 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1322 March 2, 1995. 1324 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1325 Messages", STD 11, RFC 822, August 13, 1982. 1327 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", 1328 RFC 2015, Sept. 1996. 1330 [5] R. Fajman, "An Extensible Message Format for Message 1331 Disposition Notifications", RFC 2298, March 1998. 1333 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1334 Multiparts for MIME: Multipart/Signed and 1335 Multipart/Encrypted", RFC 1847, Oct. 3, 1995 1337 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 1338 821, August 1, 1982. 1340 [8] B. Ramsdell, "S/MIME Version 3 Message Specification; 1341 Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999. 1343 [9] T. Harding, R. Drummond, "Requirements for Inter-operable 1344 Internet EDI", Internet draft: draft-ietf-ediint-req07.txt 1345 September 1999. 1347 [10] G. Vaudreuil, "The Multipart/Report Content Type for the 1348 Reporting of Mail System Administrative Messages", RFC 1349 1892, January 15, 1996. 1351 [11] R. Fielding, J.Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 1352 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1353 1997. 1355 [12] L. Deutsch, "GZIP File Format Specification Version 4.3", 1356 RFC 1952, May 23, 1996. 1358 9.0 Authors' Addresses 1360 Terry Harding 1362 MIME-based Secure EDI September 1999 1364 tharding@cyclonesoftware.com 1365 Cyclone Software 1366 14505 N. Hayden Road. Suite 300 1367 Scottsdale, AZ, 85260 1369 Chuck Shih 1370 chuck.shih@gartner.com 1371 Gartner Group. 1372 251 River Oaks Parkway 1373 San Jose, CA 95134-1913 USA 1375 Rik Drummond 1376 drummond@onramp.com 1377 The Drummond Group 1378 5008 Bentwood Ct. 1379 Ft. Worth, TX 76132 USA