idnits 2.17.1 draft-ietf-ediint-as1-15.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 27) being 61 lines == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 334 has weird spacing: '...ication is re...' == Line 996 has weird spacing: '...quested proto...' == Line 1182 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.) -- The document date (January 2002) is 8136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** 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) ** Obsolete normative reference: RFC 1892 (ref. '9') (Obsoleted by RFC 3462) Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 3 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: June 2002 R. Drummond 4 Drummond Group 5 Chuck Shih 6 Gartner Group 7 January 2002 9 MIME-based Secure Peer-to-Peer EDI over the Internet 11 draft-ietf-ediint-as1-15.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 January 2002 53 Feedback Instructions: 55 If you want to provide feedback on this draft, follow these 56 guidelines: 58 -Send feedback via e-mail to the ietf-ediint list for discussion, 59 with "AS#1" in the Subject field. To enter or follow the 60 discussion, you need to subscribe to ietf-ediint@imc.org. 62 -Be specific as to what section you are referring to, preferably 63 quoting the portion that needs modification, after which you 64 state your comments. 66 -If you are recommending some text to be replaced with your 67 suggested text, again, quote the section to be replaced, and be 68 clear on the section in question. 70 Table of Contents 72 1.0 Introduction .................................................3 73 2.0 Overview .....................................................4 74 2.1 Purpose of a security guideline for MIME EDI ................4 75 2.2 Definitions ..................................................4 76 2.2.1. Terms .....................................................4 77 2.2.2 The secure transmission loop ...............................5 78 2.2.3 Definition of receipts .....................................5 79 2.3 Assumptions .................................................6 80 2.3.1 EDI process assumptions ....................................6 81 2.3.2 Flexibility assumptions ....................................7 82 3.0 Referenced RFCs and their contribution .......................8 83 3.1 RFC 821 SMTP [7] .............................................8 84 3.2 RFC 822 Text Message Format [3] ..............................8 85 3.3 RFC 1847 MIME Security Multiparts [6] ........................8 86 3.4 RFC 1892 Multipart/report [9] ................................9 87 3.5 RFC 1767 EDI Content [2] .....................................9 88 3.6 RFC 2015, 3156, 2440 PGP/MIME [4] ............................9 89 3.7 RFC 2045, 2046, and 2049 MIME [1] ............................9 90 3.8 RFC 2298 Message Disposition Notification [5] ................9 91 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9 92 4.0 Structure of an EDI MIME message - Applicability .............9 93 4.1 Introduction .................................................9 94 4.2 Structure of an EDI MIME message - PGP/MIME .................10 95 4.2.1 No encryption, no signature ...............................10 96 4.2.2 No encryption, signature ..................................10 97 4.2.3 Encryption, no signature ..................................10 98 4.2.4 Encryption, signature .....................................10 99 4.3 Structure of an EDI MIME message - S/MIME ...................10 100 4.3.1 No encryption, no signature ...............................10 101 4.3.2 No encryption, signature ..................................10 102 4.3.3 Encryption, no signature ..................................11 103 4.3.4 Encryption, signature .....................................11 105 MIME-based Secure EDI January 2002 107 5.0 Receipts ....................................................11 108 5.1 Introduction ..............................................11 109 5.2 Requesting a signed receipt .................................13 110 5.2.1 Additional Signed Receipt Considerations ..................16 111 5.3 Message Disposition Notification Format .....................17 112 5.3.1 Message Disposition Notification Extensions ...............18 113 5.3.2 Disposition Mode, Type, and Modifier Use ..................19 114 5.4 Message Disposition Notification Processing .................21 115 5.4.1 Large File Processing ....................................21 116 5.4.2 Example ...................................................22 117 6.0 Public key certificate handling .............................24 118 6.1 Near term approach ..........................................24 119 6.2 Long term approach ..........................................24 120 7.0 Security Considerations .....................................25 121 8.0 Acknowledgments .............................................26 122 9.0 References ..................................................26 123 10.0 Authors' Addresses .........................................27 124 Appendix IANA Registration Form .................................27 126 1.0 Introduction 128 Previous work on Internet EDI focused on specifying MIME content 129 types for EDI data ([2] RFC 1767). This document expands on RFC 130 1767 to specify use of a comprehensive set of data security 131 features, specifically data privacy, data integrity/authenticity, 132 non-repudiation of origin and non-repudiation of receipt. This 133 document also recognizes contemporary RFCs and Internet drafts and 134 is attempting to "re-invent" as little as possible. 136 With an enhancement in the area of "receipts", as described below 137 (5.2), secure Internet MIME based EDI can be accomplished by 138 using and complying with the following RFCs: 140 -RFC 821 SMTP 141 -RFC 822 Text Message Formats 142 -RFC 1767 EDI Content Type 143 -RFC 1847 Security Multiparts for MIME 144 -RFC 1892 Multipart/Report 145 -RFC 2015, 3156, 2440 MIME/PGP 147 -RFC 2045 to 2049 MIME RFCs 148 -RFC 2298 Message Disposition Notification 149 -RFC 2630, 2633 S/MIME v3 Specification 151 Our intent here is to define clearly and precisely how these are 152 used together, and what is required by user agents to be 153 compliant with this document. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 156 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in 158 RFC 2119. 160 MIME-based Secure EDI January 2002 162 2.0 Overview 164 2.1 Purpose of a security guideline for MIME EDI 166 The purpose of these specifications is to ensure interoperability 167 between EDI user agents, invoking some or all of the commonly 168 expected security features. This document is also NOT limited to 169 strict EDI use, but applies to any electronic commerce 170 application where business data needs to be exchanged over the 171 Internet in a secure manner. 173 2.2 Definitions 175 2.2.1. Terms 177 EDI Electronic Data Interchange 179 EC Electronic Commerce 181 Receipt The functional message that is sent from a 182 receiver to a sender to acknowledge 183 receipt of an EDI/EC interchange. 185 Signed Receipt Same as above, but with a digital 186 signature. 188 Message Disposition The Internet messaging format used to 189 Notification convey a receipt. This term is used 190 interchangeably with receipt. A signed 191 MDN is a signed receipt. 193 Non-repudiation of NRR is a "legal event" that occurs when 194 Receipt (NRR) the original sender of an EDI/EC 195 interchange has verified the signed 196 receipt coming back from the receiver. 197 NRR IS NOT a functional or a technical 198 message. 200 PGP/MIME Digital envelope security based on the 201 Pretty Good Privacy (PGP) standard 202 (Zimmerman), integrated with MIME Security 203 Multiparts [6]. 205 S/MIME A format and protocol for adding 206 Cryptographic signature and/or encryption 207 services to Internet MIME messages. 209 MIME-based Secure EDI January 2002 211 2.2.2 The secure transmission loop 213 This document's focus is on the formats and protocols for 214 exchanging EDI content that has had security applied to it using 215 the Internet's messaging environment. 217 The "secure transmission loop" for EDI involves one organization 218 sending a signed and encrypted EDI interchange to another 219 organization, requesting a signed receipt, followed later by the 220 receiving organization sending this signed receipt back to the 221 sending organization. In other words, the following transpires: 223 -The organization sending EDI/EC data signs and encrypts the 224 data using either PGP/MIME or S/MIME. In addition, the message 225 will request a signed receipt to be returned to the sender of 226 the message. 228 -The receiving organization decrypts the message and verifies 229 the signature, resulting in verified integrity of the data and 230 authenticity of the sender. 232 -The receiving organization then returns a signed receipt to 233 the sending organization in the form of a message disposition 234 notification message. This signed receipt will contain the 235 hash of the signature from the received message, indicating to 236 the sender that the received message was verified and/or 237 decrypted properly. 239 The above describes functionality which if implemented, would 240 satisfy all security requirements. This specification, however, 241 leaves full flexibility for users to decide the degree to which 242 they want to deploy those security features with their EDI trading 243 partners. 245 2.2.3 Definition of receipts 247 The term used for both the functional activity and message for 248 acknowledging receipt of an EDI/EC interchange is receipt, or 249 signed receipt. The first term is used if the acknowledgment is 250 for an interchange resulting in a receipt which is NOT signed. 251 The second term is used if the acknowledgment is for an 252 interchange resulting in a receipt which IS signed. The method 253 used to request a receipt or a signed receipt is defined in 254 RFC 2298, "An Extensible Message Format for Message Disposition 255 Notifications". 257 MIME-based Secure EDI January 2002 259 The "rule" is: 261 - If a receipt is requested, explicitly specifying that the 262 receipt be signed, then the receipt MUST be returned with a 263 signature. 265 - If a receipt is requested, explicitly specifying that the 266 receipt be signed, but the recipient cannot support the 267 requested protocol format or requested MIC algorithms, then a 268 receipt, either signed or unsigned SHOULD be returned. 270 - If a signature is not explicitly requested, or if the signed 271 receipt request parameter is not recognized by the UA, a 272 receipt may or may not be returned. This behavior is 273 consistent with the MDN RFC 2298. 275 A term often used in combination with receipts is "Non- 276 Repudiation of Receipt (NRR). NRR refers to a legal event which 277 occurs only when the original sender of an interchange has 278 verified the signed receipt coming back from recipient of the 279 message. Note that NRR is not possible without signatures. 281 2.3 Assumptions 283 2.3.1 EDI process assumptions 285 -Encrypted object is an EDI Interchange 287 This specification assumes that a typical EDI interchange is the 288 lowest level object that will be subject to security services. 290 In ANSI X12, this means anything between, and including segments 291 ISA and IEA. In EDIFACT, this means anything between, and 292 including, segments UNA/UNB and UNZ. In other words, the EDI 293 interchanges including envelope segments remain intact and 294 unreadable during secure transport. 296 -EDI envelope headers are encrypted 298 Congruent with the above statement, EDI envelope headers are NOT 299 visible in the MIME package. In order to optimize VAN-to- 300 Internet routing, work may need to be done in the future to 301 define ways to pull out some of the envelope information to make 302 them visible, however, this specification does not go into any 303 detail on that. 305 -X12.58 and UN/EDIFACT security considerations 307 The most common EDI standards bodies, ANSI X12 and EDIFACT, have 308 defined internal provisions for security. X12.58 is the 310 MIME-based Secure EDI January 2002 312 security mechanism for ANSI X12 and AUTACK provides security for 313 EDIFACT. This specification DOES NOT dictate use or non-use of 314 these security standards. They are both fully compatible, 315 though possibly redundant, with this specification. 317 2.3.2 Flexibility assumptions 319 -Encrypted or un-encrypted data 321 This specification allows for EDI message exchange where the EDI 322 data can either be un-protected or protected by means of 323 encryption. 325 -Signed or unsigned data 327 This specification allows for EDI message exchange with or 328 without digital signature of the original EDI transmission. 330 -Use of receipt or not 332 This specification allows for EDI message transmission with or 333 without a request for receipt notification. If a signed receipt 334 notification is requested however, a mic value is REQUIRED as 335 part of the returned receipt, unless an error condition occurs 336 in which a mic value cannot be returned. In error cases, an un- 337 signed receipt or MDN SHOULD be returned with the correct 338 "disposition modifier" error value. 340 -Formatting choices 342 This specification defines the use of two methods for formatting 343 EDI contents that have security applied to it: 345 -PGP/MIME 346 -S/MIME 348 This specification relies on the guidelines set forth in RFC 349 2015/3156/2440, as reflected in [4] "MIME Security with Pretty 350 Good Privacy" (PGP); OpenPGP Message Format, and RFC 2633/2630 351 [8] "S/MIME Version 3 Message Specification; Cryptographic 352 Message Syntax". PGP/MIME or S/MIME as defined in this 353 Applicability statement. 355 -Hash function, message digest choices 357 When a signature is used, it is RECOMMENDED that the SHA1 hash 358 algorithm be used for all outgoing messages, and that both MD5 359 and SHA1 be supported for incoming messages. 361 MIME-based Secure EDI January 2002 363 In summary, the following eight permutations are possible in any 364 given trading relationship: 366 (1) Sender sends un-encrypted data, does NOT request a receipt. 368 (2) Sender sends un-encrypted data, requests a signed or 369 unsigned receipt. The receiver sends back the signed or 370 unsigned receipt. 372 (3) Sender sends encrypted data, does NOT request a receipt. 374 (4) Sender sends encrypted data, requests a signed or unsigned 375 receipt. The receiver sends back the signed or unsigned 376 receipt. 378 (5) Sender sends signed data, does NOT request a signed or 379 unsigned receipt. 381 (6) Sender sends signed data, requests a signed or unsigned 382 receipt. Receiver sends back the signed or unsigned receipt. 384 (7) Sender sends encrypted and signed data, does NOT request a 385 signed or unsigned receipt. 387 (8) Sender sends encrypted and signed data, requests a signed or 388 unsigned receipt. Receiver sends back the signed or un- 389 signed receipt. 391 NOTE: Users can choose any of the eight possibilities, but only 392 example (8), when a signed receipt is requested, offers the 393 whole suite of security features described in the "Secure 394 transmission loop" above. 396 3.0 Referenced RFCs and their contribution 398 3.1 RFC 821 SMTP [7] 400 This is the core mail transfer standard that all MTAs need to 401 adhere to. 403 3.2 RFC 822 Text Message Format [3] 405 Defines message header fields and the parts making up a message. 407 3.3 RFC 1847 MIME Security Multiparts [6] 409 This document defines security multiparts for MIME: 410 multipart/encrypted and multipart/signed. 412 MIME-based Secure EDI January 2002 414 3.4 RFC 1892 Multipart/report [9] 416 This RFC defines the use of the multipart/report content type, 417 something that the MDN RFC 2298 builds upon. 419 3.5 RFC 1767 EDI Content [2] 421 This RFC defines the use of content type "application" for ANSI 422 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and 423 mutually defined EDI (application/EDI-Consent). 425 3.6 RFC 2015, 3156, 2440 PGP/MIME [4] 427 These RFCs define the use of content types "multipart/encrypted", 428 "multipart/signed", "application/pgp encrypted" and 429 "application/pgp-signature" for defining MIME PGP content. 431 3.7 RFC 2045, 2046, and 2049 MIME [1] 433 These are the basic MIME standards, upon which all MIME related 434 RFCs build, including this one. Key contributions include 435 definition of "content type", "sub-type" and "multipart", as well 436 as encoding guidelines, which establishes 7-bit US-ASCII as the 437 canonical character set to be used in Internet messaging. 439 3.8 RFC 2298 Message Disposition Notification [5] 441 This Internet RFC defines how a message disposition notification 442 (MDN) is requested, and the format and syntax of the MDN. The MDN 443 is the basis upon which receipts and signed receipts are defined 444 in this and the "Requirements" specification. 446 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 448 This specification describes how MIME shall carry CMS Objects. 450 4.0 Structure of an EDI MIME message - Applicability 452 4.1 Introduction 454 The structures below are described hierarchically in terms of 455 which RFC's are applied to form the specific structure. For 456 details of how to code in compliance with all RFC's involved, 457 turn directly to the RFC's referenced. The "requirements 458 document" has several examples described in an Appendix for those 459 interested. 461 Also, these structures describe the initial transmission only. 462 Receipts, and requests for receipts are handled in section 5. 464 MIME-based Secure EDI January 2002 466 4.2 Structure of an EDI MIME message - PGP/MIME 468 4.2.1 No encryption, no signature 470 -RFC822/2045 471 -RFC1767 (application/EDIxxxx) 473 4.2.2 No encryption, signature 475 -RFC822/2045 476 -RFC1847 (multipart/signed) 477 -RFC1767 (application/EDIxxxx) 478 -RFC2015/2440/3156 (application/pgp-signature) 480 4.2.3 Encryption, no signature 482 -RFC822/2045 483 -RFC1847 (multipart/encrypted) 484 -RFC2015/2440/3156 (application/pgp-encrypted) 485 -"Version: 1" 486 -RFC2015/2440/3156 (application/octet-stream) 487 -RFC1767 (application/EDIxxxx) (encrypted) 489 4.2.4 Encryption, signature 491 -RFC822/2045 492 -RFC1847 (multipart/encrypted) 493 -RFC2015/2440/3156 (application/pgp-encrypted) 494 -"Version: 1" 495 -RFC2015/2440/3156 (application/octet-stream) 496 -RFC1847 (multipart/signed)(encrypted) 497 -RFC1767 (application/EDIxxxx)(encrypted) 498 -RFC2015/2440/3156 (application/pgp-signature)(encrypted) 500 4.3 Structure of an EDI MIME message - S/MIME 502 4.3.1 No encryption, no signature 504 -RFC822/2045 505 -RFC1767 (application/EDIxxxx) 507 4.3.2 No encryption, signature 509 -RFC822/2045 510 -RFC1847 (multipart/signed) 511 -RFC1767 (application/EDIxxxx) 512 -RFC2633 (application/pkcs7-signature) 514 MIME-based Secure EDI January 2002 516 4.3.3 Encryption, no signature 518 -RFC822/2045 519 -RFC2633 (application/pkcs7-mime) 520 -RFC1767 (application/EDIxxxx) (encrypted) 522 4.3.4 Encryption, signature 524 -RFC822/2045 525 -RFC2633 (application/pkcs7-mime) 526 -RFC1847 (multipart/signed) (encrypted) 527 -RFC1767 (application/EDIxxxx) (encrypted) 528 -RFC2633 (application/pkcs7-signature) (encrypted) 530 5.0 Receipts 532 5.1 Introduction 534 In order to support non-repudiation of receipt (NRR), a signed 535 receipt, based on digitally signing a message disposition 536 notification, is to be implemented by a receiving trading 537 partner's UA (User Agent). The message disposition notification, 538 specified by RFC 2298 is digitally signed by a receiving trading 539 partner as part of a multipart/signed MIME message. 541 The following support for signed receipts is REQUIRED: 543 1). The ability to create a multipart/report; where the report- 544 type = disposition-notification. 546 2). The ability to calculate a message integrity check (MIC) on 547 the received message. The calculated MIC value will be 548 returned to the sender of the message inside the signed 549 receipt. 551 4). The ability to create a multipart/signed content with the 552 message disposition notification as the first body part, and 553 the signature as the second body part. 555 5). The ability to return the signed receipt to the sending 556 trading partner. 558 The signed receipt is used to notify a sending trading partner 559 that requested the signed receipt that: 561 1). The receiving trading partner acknowledges receipt of the 562 sent EDI Interchange. 564 2). If the sent message was signed, then the receiving trading 565 partner has authenticated the sender of the EDI Interchange. 567 MIME-based Secure EDI January 2002 569 3). If the sent message was signed, then the receiving trading 570 partner has verified the integrity of the sent EDI 571 Interchange. 573 Regardless of whether the EDI Interchange was sent in S/MIME or 574 PGP/MIME format, the receiving trading partner's UA MUST provide 575 the following basic processing: 577 1). If the sent EDI Interchange is encrypted, then the encrypted 578 symmetric key and initialization vector (if applicable) is 579 decrypted using the receiver's private key. 581 2). The decrypted symmetric encryption key is then used to 582 decrypt the EDI Interchange. 584 3). The receiving trading partner authenticates signatures in a 585 message using the sender's public key. The authentication 586 algorithm performs the following: 588 a). The message integrity check (MIC or Message Digest), 589 is decrypted using the sender's public key. 591 b). A MIC on the signed contents (the MIME header and 592 encoded EDI object, as per RFC 1767) in the message 593 received is calculated using the same one-way hash 594 function that the sending trading partner used. 596 c). The MIC extracted from the message that was sent, and 597 the MIC calculated using the same one-way hash function 598 that the sending trading partner used is compared for 599 equality. 601 4). The receiving trading partner formats the MDN and sets the 602 calculated MIC into the "Received-content-MIC" extension 603 field. 605 5). The receiving trading partner creates a multipart/signed MIME 606 message according to RFC 1847. 608 6). The MDN is the first part of the multipart/signed message, 609 and the digital signature is created over this MDN, including 610 its MIME headers. 612 7). The second part of the multipart/signed message contains the 613 digital signature. The "protocol" option specified in the 614 second part of the multipart/signed is as follows: 616 S/MIME: protocol = "application/pkcs-7-signature" 618 PGP/MIME: protocol = "application/pgp-signature" 620 MIME-based Secure EDI January 2002 622 8). The signature information is formatted according to S/MIME or 623 PGP/MIME specifications. 625 The EDI Interchange and the RFC 1767 MIME EDI content header, can 626 actually be part of a multi-part MIME content-type. When the EDI 627 Interchange is part of a multi-part MIME content-type, the MIC 628 MUST be calculated across the entire multi-part content, 629 including the MIME headers. 631 The signed MDN, when received by the sender of the EDI 632 Interchange can be used by the sender: 634 1). As an acknowledgment that the EDI Interchange sent, was 635 delivered and acknowledged by the receiving trading 636 partner. The receiver does this by returning the original 637 message id of the sent message in the MDN portion of the 638 signed receipt. 640 2). As an acknowledgment that the integrity of the EDI 641 Interchange was verified by the receiving trading partner. 642 The receiver does this by returning the calculated MIC of 643 the received EDI Interchange (and 1767 MIME headers) in the 644 "Received-content-MIC" field of the signed MDN. 646 3). As an acknowledgment that the receiving trading partner has 647 authenticated the sender of the EDI Interchange. 649 4). As a non-repudiation of receipt when the signed MDN is 650 successfully verified by the sender with the receiving 651 trading partner's public key and the returned mic value 652 inside the MDN is the same as the digest of the original 653 message. 655 5.2 Requesting a signed receipt 657 Message Disposition Notifications are requested as per RFC 2298, 659 "An Extensible Message Format for Message Disposition 660 Notification". A request that the receiving user agent issue a 661 message disposition notification is made by placing the following 662 header into the message to be sent: 664 MDN-request-header = "Disposition-notification-to" ":" 665 mail-address 667 The mail-address field is specified as an RFC 822 user@domain 668 address, and is the return address for the message disposition 669 notification. 671 MIME-based Secure EDI January 2002 673 In addition to requesting a message disposition notification, a 674 message disposition notification that is digitally signed, or 675 what has been referred to as a signed receipt, can be requested 676 by placing the following in the message header following the 677 "Disposition-Notification-To" line. 679 Disposition-notification-options = 680 "Disposition-Notification-Options" ":" 681 disposition-notification-parameters 683 where 685 disposition-notification-parameters = 686 parameter *(";" parameter) 688 where 690 parameter = attribute "=" importance ", " 1#value" 692 where 694 importance = "required" | "optional" 696 So the Disposition-notification-options string could be: 698 signed-receipt-protocol=optional, ; 699 signed-receipt-micalg=optional, , ,...; 701 The currently supported values for are 702 "pkcs7-signature", for the S/MIME detached signature format, or 703 "pgp-signature", for the pgp signature format. 705 The currently supported values for MIC algorithm values are: 707 Algorithm Value 708 used 710 MD5 md5 711 SHA-1 sha1 713 (Historical note: some early implementations of EDIINT emitted 714 and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) 715 Receiving agents SHOULD be able to recover gracefully from a 716 micalg parameter value that they do not recognize. 718 An example of a formatted options line would be as follows: 720 Disposition-notification-options: 721 signed-receipt-protocol=optional, pkcs7-signature; 722 signed-receipt-micalg=optional, sha1, md5 724 MIME-based Secure EDI January 2002 726 The semantics of the "signed-receipt-protocol" parameter is as 727 follows: 729 1). The "signed-receipt-protocol" parameter is used to request a 730 signed receipt from the recipient trading partner. The 731 "signed-receipt-protocol" parameter also specifies the format 732 in which the signed receipt should be returned to the 733 requester. 735 The "signed-receipt-micalg" parameter is a list of MIC 736 algorithms preferred by the requester for use in signing the 737 returned receipt. The list of MIC algorithms should be 738 honored by the recipient from left to right. 740 Both the "signed-receipt-protocol" and the "signed-receipt- 741 micalg" option parameters are REQUIRED when requesting a 742 signed receipt. 744 2). The "importance" attribute of "Optional" is defined in the 745 MDN RFC 2298 and has the following meaning: 747 Parameters with an importance of "Optional" permit a UA that 748 does not understand the particular options parameter to still 749 generate a MDN in response to a request for a MDN. A UA that 750 does not understand the "signed-receipt-protocol" parameter, 751 or the "signed-receipt-micalg" will obviously not return a 752 signed receipt. 754 The importance of "Optional" is used for the signed receipt 755 parameters because it is RECOMMENDED that an MDN be returned 756 to the requesting trading partner even if the recipient could 757 not sign it. 759 The returned MDN will contain information on the disposition 760 of the message as well as why the MDN could not be signed. 761 See the Disposition field in section 5.3 for more information. 763 Within an EDI trading relationship, if a signed receipt is 764 expected and is not returned, then the validity of the 765 transaction is up to the trading partners to resolve. In 766 general, if a signed receipt is required in the trading 767 relationship and is not received, the transaction will likely 768 not be considered valid. 770 MIME-based Secure EDI January 2002 772 5.2.1 Additional Signed Receipt Considerations 774 The "rules" stated in Section 2.2.3 for signed receipts are as 775 follows: 777 1). When a receipt is requested, explicitly specifying that the 778 receipt be signed, then the receipt MUST be returned with a 779 signature. 781 2). When a receipt is requested, explicitly specifying that the 782 receipt be signed, but the recipient cannot support either 783 the requested protocol format, or requested MIC algorithms, 784 then either a signed or unsigned receipt SHOULD be returned. 786 3). When a signature is not explicitly requested, or if the 787 signed receipt request parameter is not recognized by the UA, 788 then no receipt, an unsigned receipt, or a signed receipt MAY 789 be returned by the recipient. 791 NOTE: For Internet EDI, it is RECOMMENDED that when a signature 792 is not explicitly requested, or if parameters are not recognized, 793 that the UA send back at a minimum, an unsigned receipt. If a 794 signed receipt however was always returned as a policy, whether 795 requested or not, then any false unsigned receipts can be 796 repudiated. 798 When a request for a signed receipt is made, but there is an 799 error in processing the contents of the message, a signed receipt 800 MUST still be returned. The request for a signed receipt SHALL 801 still be honored, though the transaction itself may not be valid. 802 The reason for why the contents could not be processed MUST be 803 set in the "disposition-field". 805 When a request for a signed receipt is made, the "Received- 806 content-MIC" MUST always be returned to the requester. The 807 "Received-content-MIC" MUST be calculated as follows: 809 - For any signed messages, the MIC to be returned is calculated 810 on the RFC1767 MIME header and content. Canonicalization as 811 specified in RFC 1848 MUST be performed before the MIC is 812 calculated, since the sender requesting the signed receipt was 813 also REQUIRED to canonicalize. 815 - For encrypted, unsigned messages, the MIC to be returned is 816 calculated on the decrypted RFC 1767 MIME header and content. 817 The content after decryption MUST be canonicalized before the 818 MIC is calculated. 820 MIME-based Secure EDI January 2002 822 - For unsigned, unencrypted messages, the MIC MUST be calculated 823 over the message contents prior to Content-Transfer-Encoding 824 and without the MIME or any other RFC 822 headers, since 825 these are sometimes altered or reordered by MTAs. 827 5.3 Message Disposition Notification Format 829 The format of a message disposition notification is specified in 830 RFC 2298 For use in Internet EDI, the following format will be 831 used: 833 - content-type - per RFC 1892 and the RFC 2298 specification 835 - reporting-ua-field - per RFC 2298 specification 837 - MDN-gateway-field - per RFC 2298 specification 839 - original-recipient-field - per RFC 2298 specification 841 - final-recipient-field - per RFC 2298 specification 843 - original-message-id-field - per RFC 2298 specification 845 - disposition-field - the following "disposition-mode" 846 values SHOULD be used for 847 Internet EDI: 849 "automatic-action" - The disposition described by the 850 disposition type was a result of an 851 automatic action, rather than an explicit 852 instruction by the user for this message. 854 "manual-action" - The disposition described by the 855 disposition type was a result of an 856 explicit instruction by the user rather 857 than some sort of automatically performed 858 action. 860 "MDN-sent-automatically" - The MDN was sent because the UA had 861 previously been configured to do 862 so. 864 "MDN-sent-manually" - The user explicitly gave permission for 865 this particular MDN to be sent. "MDN- 866 sent-manually" is meaningful with 867 "manual-action", but not with 868 "automatic-action". 870 MIME-based Secure EDI January 2002 872 - disposition-field - the following "disposition-type" values 873 SHOULD be used for Internet EDI: 875 "processed" - The message has been processed in some manner 876 (e.g., printed, faxed, forwarded, gatewayed) 877 without being displayed to the user. The user 878 may or may not see the message later. 880 "failed" - A failure occurred that prevented the proper 881 generation of an MDN. More information about the 882 cause of the failure may be contained in a 883 Failure field. The "failed" disposition type is 884 not to be used for the situation in which there 885 is some problem in processing the message other 886 than interpreting the request for an MDN. The 887 "processed" or other disposition type with 888 appropriate disposition modifiers is to be used 889 in such situations. 891 - disposition-field - the following "disposition-modifier" 892 values SHOULD be used for Internet EDI: 894 "error" - An error of some sort occurred that prevented 895 successful processing of the message. Further 896 information is contained in an Error field. 898 "warning" - The message was successfully processed but some 899 sort of exceptional condition occurred. Further 900 information is contained in a Warning field. 902 5.3.1 Message Disposition Notification Extensions 904 The following "extension field" will be added in order to support 905 signed receipts for RFC 1767 MIME content type and multipart MIME 906 content types that include the RFC 1767 MIME content type. The 907 extension field" defined below follows the "disposition-field" in 908 the MDN. 910 The "Received-content-MIC" extension field is set when the 911 integrity of the received message is verified. The MIC is the 912 base64 encoded quantity computed over the received message with a 913 hash function. For details of "what" the "Received-content-MIC" 914 should be calculated over, see Section 5.2.1. The algorithm used 915 to calculate the "Received-content-MIC" value MUST be the same as 916 the "micalg" value used by the sender in the multipart/signed 917 message. When no signature is received, or the mic-alg parameter 918 is not supported then it is RECOMMENDED that the SHA1 algorithm 919 be used to calculate the MIC on the received message or message 920 contents. 922 MIME-based Secure EDI January 2002 924 This field is set only when the contents of the message are 925 processed successfully. This field is used in conjunction with 926 the recipient's signature on the MDN in order for the sender to 927 verify "non-repudiation of receipt". 929 - extension field = "Received-content-MIC" ":" MIC 931 where: 933 = "," 935 = the result of one way hash function, base64 936 encoded. 938 < micalg> = the micalg value defined in RFC1847, an IANA 939 registered MIC algorithm ID token. 941 5.3.2 Disposition Mode, Type, and Modifier Use 943 Guidelines for use of the "disposition-mode", "disposition- 944 type", and "disposition-modifier" fields within Internet EDI are 945 discussed in this section. The "disposition-mode", "disposition- 946 type', and "disposition-modifier' fields are described in detail 947 in RFC 2298. The "disposition-mode', "disposition-type" and 948 "disposition-modifier" values SHOULD be used as follows: 950 5.3.2.1 Successful Processing 952 When the request for a receipt or signed receipt, and the 953 received message contents are successfully processed by the 954 receiving EDI UA, a receipt or MDN SHOULD be returned with the 955 "disposition-type" set to 'processed'. When the MDN is sent 956 automatically by the EDI UA, and there is no explicit way for a 957 user to control the sending of the MDN, then the first part of 958 the "disposition-mode" should be set to "automatic-action". When 959 the MDN is being sent under user configurable control, then the 960 first part of the "disposition-mode" should be set to "manual- 961 action". Since a request for a signed receipt should always be 962 honored, the user MUST not be allowed to configure the UA to not 963 send a signed receipt when the sender requests one. 965 The second part of the "disposition-mode" is set to "MDN-sent- 966 manually" if the user gave explicit permission for the MDN to be 967 sent. Again, the user MUST not be allowed to explicitly refuse 968 to send a signed receipt when the sender requests one. The 969 second part of the "disposition-mode" is set to "MDN-sent- 970 automatically" whenever the EDI UA sends the MDN automatically, 971 regardless of whether the sending was under a user's, 972 administrator's, or under software control. 974 MIME-based Secure EDI January 2002 976 Since EDI content is generally handled automatically by the EDI 977 UA, a request for a receipt or signed receipt will generally 978 return the following in the "disposition-field": 980 Disposition: automatic-action/MDN-sent-automatically; processed 982 Note this specification does not restrict the use of the 983 "disposition-mode" to just automatic actions. Manual actions are 984 valid as long as it is kept in mind that a request for a signed 985 receipt MUST be honored. 987 5.3.2.2 Unprocessed Content 989 The request for a signed receipt requires the use of two 990 "disposition-notification-options", which specify the protocol 991 format of the returned signed receipt, and the MIC algorithm 992 used to calculate the mic over the message contents. The 993 "disposition-field" values that should be used in the case where 994 the message content is being rejected or ignored, for instance 995 if the EDI UA determines that a signed receipt cannot be 996 returned because it does not support the requested protocol 997 format, so the EDI UA chooses not to process the message 998 contents itself, should be specified in the MDN "disposition- 999 field" as follows: 1001 Disposition: "disposition-mode"; 1002 failed/Failure: unsupported format 1004 The syntax of the "failed" "disposition-type" is general, 1005 Allowing the sending of any textual information along with the 1006 "failed" "disposition-type". For use in Internet EDI, the 1007 following "failed" values are defined: 1009 "Failure: unsupported format" 1010 "Failure: unsupported MIC-algorithms" 1012 5.3.2.3 Content Processing Errors 1014 When errors occur processing the received message content, the 1015 "disposition-field" should be set to the "processed" 1016 "disposition-type" value and the "error" "disposition-modifier" 1017 value. For use in Internet EDI, the following "error" 1018 "disposition-modifier" values are defined: 1020 "Error: decryption-failed" - the receiver could not decrypt the 1021 message contents. 1023 "Error: authentication-failed" - the receiver could not 1024 authenticate the sender. 1026 MIME-based Secure EDI January 2002 1028 "Error: integrity-check-failed" - the receiver could not verify 1029 content integrity. 1031 "Error: unexpected-processing-error" - a catch-all for any 1032 additional processing 1033 errors. 1035 An example of how the "disposition-field" would look when 1036 content processing errors are detected is as follows: 1038 Disposition: "disposition-mode"; 1039 processed/Error: decryption-failed 1041 5.3.2.4 Content Processing Warnings 1043 Situations arise in EDI where even if a trading partner cannot 1044 be authenticated correctly, the trading partners still agree 1045 to continue processing the EDI transactions. Transaction 1046 reconciliation is done between the trading partners at a later 1047 time. In the content processing warning situations as described 1048 above, the "disposition-field' SHOULD be set to the "processed" 1049 "disposition-type" value, and the "warning" "disposition- 1050 modifier" value. For use in Internet EDI, the following 1051 "warning" "disposition-modifier" values are defined: 1053 "Warning: authentication-failed, processing continued" 1055 An example of how the "disposition-field" would look when 1056 content processing warnings are detected is as follows: 1058 Disposition: "disposition-mode"; processed/Warning: 1059 authentication-failed, processing continued 1061 5.4 Message Disposition Notification Processing 1063 5.4.1 Large File Processing 1065 Large EDI Interchanges sent via SMTP can be automatically 1066 fragmented by some message transfer agents. A subtype of 1067 message/partial, is defined in RFC 2045 [1] to allow large 1068 objects to be delivered as separate pieces of mail and to be 1069 automatically reassembled by the receiving user agent. Using 1070 message/partial, can help alleviate fragmentation of large 1071 messages by different message transfer agents, but does not 1072 completely eliminate the problem. It is still possible that a 1073 piece of a partial message, upon re-assembly, may prove to 1074 contain a partial message as well. This is allowed by the 1075 Internet standards, and it is the responsibility of the user 1076 agent to re-assemble the fragmented pieces. 1078 MIME-based Secure EDI January 2002 1080 It is RECOMMENDED that the size of the EDI Interchange sent via 1081 SMTP be configurable so that if fragmentation is needed, then 1082 message/partial can be used to send the large EDI Interchange in 1083 smaller pieces. RFC 2045 [1] defines the use of Content-Type: 1084 message/partial. 1086 Note: Support of the message/partial content type for use in 1087 Internet EDI is OPTIONAL and in the absence of knowledge that 1088 the recipient supports partial it SHOULD NOT be used. 1090 The receiving UA is required to re-assemble the original 1091 message before sending the message disposition notification to 1092 the original sender of the message. A message disposition 1093 notification is used to specify the disposition of the entire 1094 message that was sent, and should not be returned by a 1095 processing UA until the entire message is received, even if the 1096 received message requires re-assembling. 1098 5.4.2 Example 1100 The following is an example of a signed receipt returned by a 1101 UA after successfully processing a MIME EDI content type. The 1102 sending trading partner has requested a return signed receipt. 1104 This example follows the S/MIME application/pkcs-7-signature 1105 format. 1107 NOTE: This example is provided as an illustration only, and is 1108 not considered part of the protocol specification. If an 1109 example conflicts with the protocol definitions specified above 1110 or in the other referenced RFCs, the example is wrong. 1112 To: 1113 Subject: 1114 From: 1115 Date: 1116 Mime-Version: 1.0 1117 Content-Type: multipart/signed; boundary="separator"; 1118 micalg=sha1; protocol="application/pkcs7-signature" 1120 --separator 1121 & Content-Type: multipart/report; report-type=disposition 1122 & notification; boundary="xxxxx" 1123 & 1124 & --xxxxx 1125 & Content-Type: text/plain 1126 & 1128 MIME-based Secure EDI January 2002 1130 & The message sent to Recipient 1131 & has been received, the EDI Interchange was successfully 1132 & decrypted and its integrity was verified. In addition, the 1133 & sender of the message, Sender 1134 & was authenticated as the originator of the message. There is 1135 & no guarantee however that the EDI Interchange was 1136 & syntactically correct, or was received by the EDI 1137 & application. 1138 & 1139 & --xxxxx 1140 & Content-Type: message/disposition-notification 1141 & 1142 & Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2) 1143 & Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1144 & Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com 1145 & Original-Message-ID: <17759920005.12345@cyclonesoftware.com > 1146 & Disposition: automatic-action/MDN-sent-automatically; processed 1147 & Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1 1148 & 1149 & --xxxxx 1150 & Content-Type: message/rfc822 1151 & 1152 & To: 1153 & Subject: 1154 & 1155 & [additional header fields go here] 1156 & 1157 & --xxxxx- 1159 --separator 1160 Content-Type: application/pkcs7-signature; name=smime.p7s; 1161 Content-Transfer-Encoding: base64 1162 Content-Disposition: attachment; filename=smime.p7s 1164 MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg 1165 ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA 1166 oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU= 1168 --separator-- 1170 Notes: 1172 -The lines preceded with "&" is what the signature is calculated 1173 over. 1175 (For details on how to prepare the multipart/signed with 1176 protocol = "application/pkcs7-signature" see the "S/MIME 1177 Message Specification, PKCS Security Services for MIME".) 1179 MIME-based Secure EDI January 2002 1181 Note: As specified by RFC 1892 [9], returning the original or 1182 portions of the original message in the third body part of the 1183 multipart/report is not required. This is an optional body part. 1184 It is RECOMMENDED that the received headers from the original 1185 message be placed in the third body part, as they can be helpful 1186 in tracking problems. 1188 Also note that the textual first body part of the 1189 multipart/report can be used to include a more detailed 1190 explanation of the error conditions reported by the disposition 1191 headers. The first body part of the multipart/report when used in 1192 this way, allows a person to better diagnose a problem in detail. 1194 6.0 Public key certificate handling 1196 6.1 Near term approach 1198 In the near term, the exchange of public keys and certification 1199 of these keys must be handled as part of the process of 1200 establishing a trading partnership. The UA and/or EDI application 1201 interface must maintain a database of public keys used for 1202 encryption or signatures, in addition to the mapping between EDI 1203 trading partner ID and RFC 822 [3] email address. The procedures 1204 for establishing a trading partnership and configuring the secure 1205 EDI messaging system might vary among trading partners and 1206 software packages. 1208 For systems which make use of X.509 certificates, it is 1209 RECOMMENDED that trading partners self-certify each other if an 1210 agreed upon certification authority is not used. It is highly 1211 RECOMMENDED that when trading partners are using S/MIME, that 1212 they also exchange public key certificates using the 1213 recommendations specified in the S/MIME Version 3 Message 1214 Specification. The message formats and S/MIME conformance 1215 requirements for certificate exchange are specified in this 1216 document. 1218 This applicability statement does NOT require the use of a 1219 certification authority. The use of a certification authority 1220 is therefore OPTIONAL. 1222 6.2 Long term approach 1224 In the long term, additional Internet-EDI standards may be 1225 developed to simplify the process of establishing a trading 1226 partnership, including the third party authentication of trading 1227 partners, as well as attributes of the trading relationship. 1229 MIME-based Secure EDI January 2002 1231 7.0 Security Considerations 1233 This entire document is concerned with secure transport of 1234 business to business data, and considers both privacy and 1235 authentication issues. 1237 Extracted from S/MIME Version 2 Message Specification: 1238 40-bit encryption is considered weak by most cryptographers. Using 1239 weak cryptography offers little actual security over sending 1240 plaintext. However, other features of S/MIME, such as the 1241 specification of tripleDES and the ability to announce stronger 1242 cryptographic capabilities to parties with whom you communicate, 1243 allow senders to create messages that use strong encryption. Using 1244 weak cryptography is never recommended unless the only alternative 1245 is no cryptography. When feasible, sending and receiving agents 1246 should inform senders and recipients the relative cryptographic 1247 strength of messages. 1249 Extracted from S/MIME Version 2 Certificate Handling: 1250 When processing certificates, there are many situations where the 1251 processing might fail. Because the processing may be done by a 1252 user agent, a security gateway, or other program, there is no 1253 single way to handle such failures. Just because the methods to 1254 handle the failures has not been listed, however, the reader 1255 should not assume that they are not important. The opposite is 1256 true: if a certificate is not provably valid and associated with 1257 the message, the processing software should take immediate and 1258 noticeable steps to inform the end user about it. 1260 Some of the many places where signature and certificate checking 1261 might fail include: 1263 - no certificate chain leads to a trusted CA 1264 - no ability to check the CRL for a certificate 1265 - an invalid CRL was received 1266 - the CRL being checked is expired 1267 - the certificate is expired 1268 - the certificate has been revoked 1270 There are certainly other instances where a certificate may be 1271 invalid, and it is the responsibility of the processing software 1272 to check them all thoroughly, and to decide what to do if the 1273 check fails. 1275 8.0 Acknowledgments 1277 Many thanks go out to the previous authors of the MIME-based 1278 Secure EDI IETF Draft: Mats Jansson. 1280 MIME-based Secure EDI January 2002 1282 The authors would like to extend special thanks to Carl Hage, Jun 1283 Ding, Dale Moberg, and Karen Rosenthal for providing the team 1284 with valuable, and very thorough feedback. Without participants 1285 like those cited above, these efforts become hard to complete in 1286 a way useful to the users and implementers of the technology. 1288 In addition, the authors would like to thank Harald Alvestrand, 1289 Jim Galvin, and Roger Fajman for their guidance and input. 1291 9.0 References 1293 [1] N. Borenstein, N.Freed, "Multipurpose Internet Mail 1294 Extensions (MIME) 1295 Part One: Format of Internet Message Bodies", RFC 2045, 1296 December 02, 1996. 1298 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1299 Extensions (MIME) 1300 Part Two: Media Types", RFC 2046, December 02, 1996. 1302 N. Borenstein, N.Freed, "Multipurpose Internet Mail 1303 Extensions (MIME) 1304 Part Five: Conformance Criteria and Examples", RFC 2049 , 1305 December 02, 1996. 1307 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, 1308 March 2, 1995. 1310 [3] D. Crocker, "Standard for the Format of ARPA Internet Text 1311 Messages", STD 11, RFC 822, August 13, 1982. 1313 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", 1314 RFC 2015, Sept. 1996. 1316 J. Callas, L.Donnerhacke, H. Finney, R.Thayer 1317 "OpenPGP Message Format", RFC 2440, Nov. 1998. 1319 M. Elkins, D. Del Torto, R. Levien, T. Roessler 1320 "MIME Security with OpenPGP", RFC 3156, August 2001. 1322 [5] R. Fajman, "An Extensible Message Format for Message 1323 Disposition Notifications", RFC 2298, March 1998. 1325 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security 1327 Multiparts for MIME: Multipart/Signed and 1328 Multipart/Encrypted", RFC 1847, Oct. 3, 1995 1330 MIME-based Secure EDI January 2002 1332 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 1333 821, August 1, 1982. 1335 [8] B. Ramsdell, "S/MIME Version 3 Message Specification; 1336 Cryptographic Message Syntax", RFC 2633 RFC 2630, June 1999. 1338 [9] G. Vaudreuil, "The Multipart/Report Content Type for the 1339 Reporting of Mail System Administrative Messages", RFC 1340 1892, January 15, 1996. 1342 10.0 Authors' Addresses 1344 tharding@cyclonecommerce.com 1345 Cyclone Commerce 1346 17767 North Perimeter Drive 1347 Scottsdale, Arizona 85255, USA 1349 Chuck Shih 1350 chuck.shih@gartner.com 1351 Gartner Group. 1352 251 River Oaks Parkway 1353 San Jose, CA 95134-1913 USA 1355 Rik Drummond 1356 rik@drummondgroup.com 1357 Drummond Group 1358 P.O. Box 101567 1359 Ft. Worth, TX 76105 USA 1361 Apendix IANA Registration Form 1363 A.1 IANA registration of the signed-receipt-protocol disposition 1364 notification option 1366 Parameter-name: signed-receipt-protocol 1367 Syntax: See section 5.2 of this document 1368 Specification: See section 5.2 of this document 1370 A.2 IANA registration of the signed-receipt-micalg disposition 1371 notification option 1373 Parameter-name: signed-receipt-micalg 1374 Syntax: See section 5.2 of this document 1375 Specification: See section 5.2 of this document 1377 A.3 IANA registration of the Received-content-MIC MDN extension 1378 field name 1380 Extension field name: Received-content-MIC 1381 Syntax: See section 5.3.1 of this document 1382 Specificaion: See section 5.3.1 of this document