idnits 2.17.1 draft-ietf-ediint-as1-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1035 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 85 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 328: '...ceipt that is signed, MUST result in a...' RFC 2119 keyword, line 329: '...est for receipt without signature MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 361 has weird spacing: '...This is the b...' == Line 724 has weird spacing: '...ion key is th...' == Line 733 has weird spacing: '..., using the s...' == Line 852 has weird spacing: '...nternet stand...' == Line 865 has weird spacing: '...ired to re-as...' -- 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 1521 (ref. '1') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (ref. '3') (Obsoleted by RFC 2822) == Outdated reference: A later version (-07) exists of draft-ietf-receipt-mdn-01 ** Obsolete normative reference: RFC 821 (ref. '7') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1892 (ref. '10') (Obsoleted by RFC 3462) Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Mats Jansson, LiNK 2 draft-ietf-ediint-as1-01.txt Chuck Shih, Actra 3 Nancy Turaj, Mitre Corp. 4 Rik Drummond, Drummond Group 6 19 October, 1996 8 MIME-based Secure EDI 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet Drafts 20 as reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Abstract 31 This document describes how to securely exchange EDI documents 32 using MIME and public key cryptography. 34 Feedback Instructions: 36 If you want to provide feedback on this draft, follow these guidelines: 38 -Send feedback via e-mail to mjansson@agathon.com, with "AS#1" in the 39 Subject field. 41 -Be specific as to what section you are referring to, preferrably 42 quoting the portion that needs modification, after which you state your 43 comments. 45 -If you are recommending some text to be replaced with your suggested 46 text, again, quote the section to be replaced, and be clear on the 47 section in question. 49 -If you are questioning fundamental methods, make it clear to us and we 50 will bring the issue to the ediint list for discussion. To follow the 51 discussion, you need to subscribe at ietf-ediint@imc.org. 53 Table of Contents 55 1. Introduction 57 2. Overview 58 2.1 Purpose of a security guideline for MIME EDI 59 2.2 Definitions 60 2.2.1 Terms 61 2.2.2 The secure transmission loop 62 2.2.3 Definition of receipts 63 2.3 Assumptions 64 2.3.1 EDI process assumptions 65 2.3.2 Flexibility assumptions 67 3. Structure of an EDI MIME message 68 3.1 Referenced RFC's and their contribution 69 3.1.1 RFC 821 SMTP [7] 70 3.1.2 RFC 822 Text Message Format [3] 71 3.1.3 RFC 1521 MIME [1] 72 3.1.4 RFC 1847 MIME Security Multiparts [6] 73 3.1.5 RFC 1892 Multipart/report [9] 74 3.1.6 RFC 1767 EDI Content [2] 75 3.1.7 RFC 2015 PGP/MIME [4] 76 3.1.8 Internet draft (fajman): Message Disposition Notification [5] 77 3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8] 78 3.2 Vocabulary 79 3.3 Structure of an EDI MIME message - No encryption/No signature 80 3.4 Structure of an EDI MIME message - Encryption/No signature 81 3.4.1 S/MIME 82 3.4.2 PGP/MIME 83 3.5 Structure of an EDI MIME message - No encryption/Signature 84 3.5.1 S/MIME 85 3.5.2 PGP/MIME 86 3.6 Structure of an EDI MIME message - Encryption/Signature 87 3.6.1 S/MIME 88 3.6.2 PGP/MIME 90 4. Receipts 91 4.1 Introduction 92 4.2 Requesting a signed receipt 93 4.3 Message Disposition Notification Format 94 4.4 Message Disposition Notification Processing 95 4.4.1 Large File Processing 96 4.4.2 Example 98 5. Public key certificate handling 99 5.1 Near term approach 100 5.2 Long term approach 102 6. Authors' Addresses 104 7. References 106 1. Introduction 108 Previous work on internet EDI focussed on specifying MIME content 109 types for EDI data ([2] RFC 1767). This Applicability Statement 110 expands on RFC 1767 to specify use of a comprehensive set of data 111 security features, specifically data privacy, data 112 integrity/authenticity, non-repudiation of origin and non-repudiation 113 of receipt. This draft recognizes contemporary RFCs and internet 114 drafts and is attempting to "re-invent" as little as possible. 116 With an enhancements in the area of "receipts", as described below 117 (3.1.8), secure internet MIME based EDI can be accomplished by using 118 and complying with the following RFC's and drafts: 120 -RFC 821 SMTP 121 -RFC 822 Text Message Formats 122 -RFC 1521 MIME 123 -RFC 1767 EDI Content Type 124 -RFC 1847 Security Multiparts for MIME 125 -RFC 1892 Multipart/Report 126 -Internet draft: Message Disposition Notification (fajman) 127 -RFC 2015 MIME/PGP (elkins) 128 -S/MIME Specification (RSA) 130 Our intent here is to define clearly and precisely how these 131 are pieced together and what is required by user agents to be 132 compliant with this Applicability Statement. 134 2. Overview 136 2.1 Purpose of a security guideline for MIME EDI 138 The purpose of these specifications is to ensure interoperability 139 between EDI user agents, invoking some or all of the commonly 140 expected security features. This standard is also NOT limited to 141 strict EDI use, but applies to any electronic commerce application 142 where business data needs to be exchanged over the internet in a 143 secure manner. 145 2.2 Definitions 147 2.2.1. Terms 149 EDI Electronic Data Interchange 151 EC Electronic Commerce 153 Receipt The functional message that is sent from a 154 receiver to a sender to acknowledge receipt 155 of an EDI/EC interchange 157 Signed Receipt Same as above, but with a digital signature 159 Message Disposition The way by which a receipt or a signed 160 Notification (MDN) receipt is accomplished within Internet 161 Messaging. 163 Non-repudiation of NRR is a "legal event" that occurs when the 164 Receipt (NRR) original sender of an EDI/EC interchange has 165 verified the signed receipt coming back from the 166 receiver. NRR IS NOT a functional or a 167 technical message. 169 PGP/MIME Digital envelope security based on the Pretty 170 Good Privacy (PGP) standard (Zimmerman), 171 integrated with MIME Security Multiparts [6]. 173 S/MIME A protocol for adding cryptographic 174 signature and/or encryption services to Internet 175 MIME messages. 177 2.2.2 The secure transmission loop 179 The functional requirements document, [9] "Requirements for Inter- 180 operable Internet EDI" (can be found at www.ietf.org),provides 181 extensive information on EDI security and the user/business related 182 processes surrounding the need for and use of EDI security. In 183 this document, it is assumed that the reader is familiar with the 184 requirements document. 186 This document's focus is on the formats and protocols for 187 exchanging EDI content that has had security applied to it using 188 the Internet's messaging transport. 190 The "secure transmission loop" for EDI involves one organization 191 sending a signed and encrypted EDI interchange to another 192 organization, requesting a "signed receipt", followed later by the 193 receiving organization sending this "signed receipt" back to the 194 sending organization. In other words, the following transpires: 196 -The organization sending EDI/EC data encrypts the data and 197 provides a digital signature, using either PGP/MIME or S/MIME. 198 In addition, they request a "signed receipt". 200 -The receiving organization decrypts the message and verifies the 201 signature, resulting in verified integrity of the data and 202 authenticity of the sender. 204 -The receiving organization then sends a "signed receipt" in the 205 form of a signature over the hash from the previous step. 207 The above describes functionality which if implemented, would 208 satisfy all security requirements. This specification, however, 209 leaves full flexibility for users to decide the degree to which they 210 want to deploy those features with their EDI trading partners. 212 2.2.3 Definition of receipts 214 The term used for the both the functional activity and message for 215 acknowledging receipt of an EDI/EC interchange is "receipt", or 216 "signed receipt". The first term is used if the acknowledgment is 217 for an interchange that was not signed, thereby resulting in a 218 receipt which is also not signed. The second term is used if the 219 acknowledgment is for an interchange which was signed, resulting in 220 a receipt which is also signed. The rule is: If a receipt is 221 requested, it will be signed only if the original interchange was 222 signed. A term often used in combination with receipts is "Non- 223 repudiation of Receipt (NRR). NRR refers to a legal event which 224 occurs only when the original sender of an interchange has verified 225 the sender and content of a "signed receipt". Note that NRR is not 226 possible without signatures. 228 2.3 Assumptions 230 2.3.1 EDI process assumptions 232 -Encrypted object is an EDI Interchange 234 This specification assumes that a typical EDI interchange is the 235 lowest level object that will be subject to security features. 236 In ANSI X12, this means anything between, and including 237 segments ISA and IEA. In EDIFACT, this means anything between, 238 and including, segments UNA/UNB and UNZ. In other words, the 239 EDI interchanges including envelope segments remain intact and 240 unreadable during secure transport. 242 -EDI envelope headers are encrypted 244 Congruent with the above statement, EDI envelope headers are NOT 245 visible in the MIME package. In order to optimize VAN-to- 246 Internet routing, work may need to be done in the future to 247 define ways to pull out some of the envelope information to make 248 them visible, however, this specification does not go into any 249 detail on that. 251 -X12.58 and UN/EDIFACT security considerations 253 The most common EDI standards, ANSI X12 and EDIFACT, have 254 defined internal provisions for security. X12.58 is the 255 security mechanism for ANSI X12 and AUTACK provides security for 256 EDIFACT. This specification DOES NOT dictate use or non-use of 257 these security standards. They are both fully compatible, 258 though possibly redundant, with this specification. 260 2.3.2 Flexibility assumptions 262 -Encrypted or un-encrypted data 264 This specification allows for EDI message exchange where the EDI 265 data is either un-protected or protected by means of encryption. 267 -Signed or un-signed data 269 This specification allows for EDI message exchange with or 270 without digital signature of the original EDI transmission. 272 -Use of receipt or not (signature required for "Signed Receipt") 274 This specification allows for EDI message transmission with or 275 without a request for receipt notification. If receipt 276 notification is requested, however, a signature is required as 277 part of both the original EDI transmission and the returned 278 receipt. 280 -Formatting choices 282 This specification defines use of two methods for formatting EDI 283 contents that have security applied to it: 285 -PGP/MIME 286 -S/MIME 288 This specification relies on the guidelines set forth in the 289 internet draft on PGP/MIME, as reflected in [4] MIME Security 290 with Pretty Good Privacy (PGP), and [8] S/MIME Specification 291 from RSA Security, Inc. Compliance with this specification 292 dictates that AT LEAST one of these methods is supported. 294 -Hash function, message digest choices 296 When signature is used, unless specified otherwise by the chosen 297 method (PGP/MIME or S/MIME), the MD5 checksum hash function is 298 recommended. 300 In summary, the following eight permutations are possible, in 301 any given trading relationship: 303 (1) Sender sends un-encrypted data, does NOT request a receipt. 305 (2) Sender sends unencrypted data, requests a receipt. Receiver 306 sends back a receipt. 308 (3) Sender sends encrypted data, does NOT request a receipt. 310 (4) Sender sends encrypted data, requests a receipt. Receiver 311 sends back a receipt. 313 (5) Sender sends signed data, does NOT request a signed receipt. 315 (6) Sender sends signed data, requests a signed receipt. 316 Receiver sends back a signed receipt. 318 (7) Sender sends encrypted and signed data, does NOT request a 319 signed receipt. 321 (8) Sender sends encrypted and signed data, requests a signed 322 receipt. Receiver sends back a signed receipt. 324 NOTE: Users can choose any of the eight possibilities, but only 325 example (8) offers the whole suite of security features described 326 in the "Secure transmission loop" above. 328 NOTE: A request for receipt that is signed, MUST result in a 329 signed receipt. A request for receipt without signature MUST 330 result in an un-signed receipt. 332 3. Structure of an EDI MIME message 334 The following sub chapters describe the structure of EDI MIME 335 messages, making use of security features in different ways. 336 Please note that if a signed receipt is to be returned, the 337 original EDI transmission also had to have been signed. 339 The structures shown below represent the use of specifications 340 outlined in the following RFCs and Internet-drafts, and before 341 moving into the sructures themselves, there is a brief review of 342 what each document contributes. 344 NOTE: The examples below are just that - examples. Do not code 345 according to them. Refer to the RFC's that specify the correct 346 grammar in each case. 348 3.1 Referenced RFC's and their contribution 350 3.1.1 RFC 821 SMTP [7] 352 This is the core mail transfer standard that all MTA's need to adhere 353 to. 355 3.1.2 RFC 822 Text Message Format [3] 357 Defines message header fields and the parts making up a message. 359 3.1.3 RFC 1521 MIME [1] 361 This is the basic MIME standard, upon which all MIME related RFCs 362 build, including this one. Key contributions include definition of 363 "content type" and sub-type "multipart", in addition to encoding 364 guidelines, which establish 7-bit US-ASCII as the lowest common 365 denominator used. 367 3.1.4 RFC 1847 MIME Security Multiparts [6] 369 This document defines security multiparts for MIME: 370 multipart/encrypted and multipart/signed. 372 3.1.5 RFC 1892 Multipart/report [10] 374 This RFC defines the use of Multipart/report content type, 375 something that the MDN draft (fajman) relies on for the receipt 376 functionality. 378 3.1.6 RFC 1767 EDI Content [2] 380 This RFC defines the use of content type "application" for ANSI 381 X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and mutually 382 defined EDI (application/EDI-Consent). 384 3.1.7 RFC 2015 PGP/MIME [4] 386 This RFC defines the use of content types 387 "multipart/encrypted", "multipart/signed", "application/pgp 388 encrypted" and "application/pgp-signature" for defining MIME PGP 389 content. 391 3.1.8 Internet draft (fajman): Message Disposition Notification [5] 393 This Internet draft defines how a "signed receipt" is requested, 394 and the structure of the signed receipt, also called message 395 disposition notification. 397 NOTE: This is the only specification we were not able to take 398 "as is". Extension field-names beginning with "X-" will not be defined 399 as a standard field. MDN field names not beginning with "X-" need to 400 be registered with the Internet Assigned Numbers Authority (IANA) 401 and described in an RFC. The X-Received-MIC field described in this 402 document will be registered with IANA. 404 3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8] 406 This specification describes how MIME shall carry PKCS7 407 envelope information. 409 3.2 Vocabulary 411 The email address of the receiving 412 organization's EDI processing system. 414 The email address of the sending organi- 415 zation's EDI processing system. 417 Transmission date 419 "EDI-FACT" or "EDI-X12" or "EDI-consent" 421 "Quoted-printable" or "Base64" 423 ANSI X12 or EDIFACT EDI Interchange, or 424 mutually agreed electronic commerce file 426 "us-ascii" or "iso-8859-1" (note that if 427 iso-8859-1 is used, in most cases 428 encoding will be required "Quoted 429 printable" or "Base 64" 431 "md5" or "sha1" 433 NOTE: The examples below are just that - examples. They are provided 434 for illustration purposes only. Refer to the RFCs or drafts under 435 "7. References" for the actual grammar and protocol definitions 437 3.3 Structure of an EDI MIME message - No encryption/No signature 439 To: 440 Subject: 441 From: 442 Date: 443 Mime-Version: 1.0 444 Content-Type: Application/ 445 Content-Transfer-Encoding: 447 449 3.4 Structure of an EDI MIME message - Encryption/No signature 451 3.4.1 S/MIME 453 To: 454 Subject: 455 From: 456 Date: 457 Version: 1.5 458 Content-Type: application/x-pkcs7-mime 459 Content-Transfer-Encoding: base64 461 ContentType = EnvelopedData 463 &MIME-Version: 1.0 464 &Content-Type: Application/; 465 &Content-Transfer-Encoding: 466 & 467 & 469 Notes: 471 -The text preceeded by "&" indicates that it is really encrypted, 472 but presented as text for clarity 474 3.4.2 PGP/MIME 476 To: 477 Subject: 478 From: 479 Date: 480 Mime-Version: 1.0 481 Content-Type: multipart/encrypted; boundary="separator"; 482 protocol="application/pgp-encrypted" 484 --separator 485 Content-Type: application/pgp-encrypted 487 Version: 1 489 --separator 490 Content-Type: application/octet-stream 492 -----BEGIN PGP MESSAGE----- 493 Version 2.6.2 495 &Content-Type: Application/; 496 &Content-Transfer-Encoding: 497 & 498 & 499 -----END PGP MESSAGE----- 501 --separator-- 503 Notes: 505 -The text preceeded by "&" indicates that it is really encrypted, 506 but presented as text for clarity 508 3.5 Structure of an EDI MIME message - No encryption/Signature 510 3.5.1 S/MIME 512 To: 513 Subject: 514 From: 515 Date: 516 Version: 1.5 517 Content-Type: application/x-pkcs7-mime 518 Content-Transfer-Encoding: base64 520 ContentType = SignedData 522 MIME-Version: 1.0 523 Content-Type: multipart/signed; boundary="separator"; 524 micalg=rsa-; protocol="application/x-pkcs7-signature" 526 --separator 527 &Content-Type: Application/ 528 &Content-Transfer-Encoding: 529 & 530 & 532 --separator 533 Content-Type: application/x-pkcs7-signature 534 Content-Transfer-Encoding: base64 536 538 --separator-- 540 Notes: 542 -The lines preceeded with "&" is what the signature is calculated 543 over. 545 3.5.2 PGP/MIME 547 To: 548 Subject: 549 From: 550 Date: 551 Mime-Version: 1.0 552 Content-Type: multipart/signed; boundary="separator"; 553 micalg=pgp-; protocol="application/pgp-signature" 555 --separator 556 &Content-Type: Application/ 557 &Content-Transfer-Encoding: 558 & 559 & 561 --separator 562 Content-Type: application/pgp-signature 564 -----BEGIN PGP MESSAGE----- 565 Version 2.6.2 567 fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytdhfFFQere 568 /876JHJHGIUIUgsdIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF 569 frtFFKFG+GFff= 570 =ndaj 571 -----END PGP MESSAGE----- 573 --separator-- 575 Notes: 577 -The lines preceeded with "&" is what the signature is calculated 578 over. 580 3.6 Structure of an EDI MIME message - Encryption/Signature 582 3.6.1 S/MIME 584 The sequence here is that the EDI data is first signed as a 585 multipart/signature body. Then the data plus the signature 586 are encrypted to form the final multipart/encrypted body. In other words, the multipart/signed body part is nested within the multipart/encrypted body part. 588 To: 589 Subject: 590 From: 591 Date: 593 Version: 1.5 594 Content-Type: application/x-pkcs7-mime 595 Content-Transfer-Encoding: base64 597 ContentType = SignedAndEnvelopedData 599 *MIME-Version: 1.0 600 *Content-Type: multipart/encrypted; boundary="separator"; 601 *protocol="application/x-pkcs7-mime" 602 * 603 *--separator 605 * Content-Type: multipart/signed; boundary="signed separator"; 606 * micalg=rsa-; protocol="application/x-pkcs7-signature" 607 * 608 * --signed separator 609 * &Content-Type: Application/ 610 * &Content-Transfer-Encoding: 611 * & 612 * & 613 * 614 * --signed separator 615 * Content-Type: application/x-pkcs7-signature 616 * Content-Transfer-Encoding: base64 617 * 618 * 619 * 620 * --signed separator-- 622 --separator-- 624 Notes: 626 - The lines preceded with "&" is what the signature is calculated 627 over. 629 - The text preceeded by "*" indicates that it is really encrypted, 630 but presented as text for clarity 632 3.6.2 PGP/MIME 634 The sequence here is that the EDI data is first signed as a 635 multipart/signature body, and then the data plus the signature 636 is encrypted to form the final multipart/encrypted body. Here 637 goes: 639 To: 640 Subject: 641 From: 642 Date: 643 Mime-Version: 1.0 644 Content-Type: multipart/encrypted; boundary="separator"; 645 protocol="application/pgp-encrypted" 647 --separator 648 Content-Type: application/pgp-encrypted 650 Version: 1 652 --separator 653 Content-Type: application/octet-stream 655 -----BEGIN PGP MESSAGE----- 656 Version 2.6.2 658 * Content-Type: multipart/signed; boundary="signed separator"; 659 * micalg=pgp-; protocol="application/pgp-signature" 660 * 661 * --signed separator 662 * &Content-Type: Application/ 663 * &Content-Transfer-Encoding: 664 * & 665 * & 666 * 667 * --signed separator 668 * Content-Type: application/pgp-signature 669 * 670 * -----BEGIN PGP MESSAGE----- 671 * Version 2.6.2 672 * 673 * fgfjhHjhJhgljhgJGHGJHGJHJHJhghjhJHJuytIYTiutTYT34553//YRytd 674 * /GIUIUgsIUYgYTRdgggguytUTIUlbXssfdsfdREWrewREWREEWE88POF/DF 675 * frtFFKFG+GFff= 676 * =ndaj 677 * -----END PGP MESSAGE----- 678 * 679 * --signed separator-- 680 -----END PGP MESSAGE----- 682 --separator-- 684 Notes: 686 - The lines preceded with "&" is what the signature is calculated 687 over. 689 - The text preceeded by "*" indicates that it is really encrypted, 690 but presented as text for clarity 692 -Elkins draft allows another way to handle the above in a combined 693 fashion, However, for the purpose of EDI we require the above 694 method, which is based on [4] RFC 1847. 696 4. Receipts 698 4.1 Introduction 700 In order to provide a non-repudiation of receipt (NRR) or signed 701 receipt, a message disposition notification as specified by draft- 702 ietf-receipt-mdn-01 is to be implemented by a receiving trading 703 partner's UA (User Agent). The MDN is used to notify a sending 704 trading partner that sent a signed, or signed and encrypted EDI 705 Interchange that: 707 1). The receiving trading partner acknowledges receipt of 708 the sent EDI Interchange. 710 2). The receiving trading partner has authenticated the sender of 711 the EDI Interchange. 713 3). The receiving trading partner has verified the integrity of the 714 received EDI Interchange. 716 Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME 717 format, the receiving trading partner's UA must provide the following 718 basic processing: 720 1). If the sent EDI Interchange is encrypted, then the encrypted 721 symmetric key and initialization vector (if applicable) is 722 decrypted using the receiver's private key. 724 2). The decrypted symmetric encryption key is then used to decrypt 725 the EDI Interchange. 727 3). The sender's public key is then used to decrypt the received 728 message integrity check (MIC or Message Digest) calculated by 729 the sender using a one-way hash function, and digitally signed 730 by the sender. The decryption of the MIC authenticates the 731 sender of the EDI Interchange to the receiving trading partner. 733 4). The receiving trading partner, using the same one-way hash 734 function that the sending trading partner used, then calculates 735 a MIC value on the received EDI Interchange and the RFC 1767 736 MIME content header information. 738 5). The receiving trading partner compares the received MIC from 739 the sending trading partner with the MIC that the receiving 740 trading partner independently calculated. If the two MIC 741 values are equal, then the receiving trading partner knows that 742 the EDI Interchange that was received was not altered in 743 transit from the sending trading partner. The receiving trading 744 partner has verified the integrity of the sent EDI Interchange. 746 6). The receiving trading partner then digitally signs the MIC that 747 was calculated on the received EDI Interchange and the RFC 1767 748 MIME content header information. 750 7). The receiving trading partner formats the MDN and returns the 751 digitally signed MIC back to the sending trading partner in the 752 MDN. 754 The EDI Interchange and the RFC 1767 MIME EDI content header, can 755 actually be part of a multi-part MIME content-type. When the EDI 756 Interchange is part of a multi-part MIME content-type, the MIC is 757 calculated across the entire multi-part content, including the MIME 758 headers. The multi-part MIME content that contains the EDI Interchange 759 is then enveloped in either PKCS #7 or PGP format. The signed MIC 760 returned in the MDN is then a signed receipt for the entire multi-part 761 MIME content 763 The MDN when received by the sender of the EDI Interchange can then be 764 used by the sender: 766 1). As an acknowledgment that the EDI Interchange sent, was 767 delivered and acknowledged by the receiving trading partner. 769 2). As an acknowledgment that the integrity of the EDI Interchange 770 was verified by the receiving trading partner. 772 3). As an acknowledgment that the receiving trading partner has 773 authenticated the sender of the EDI Interchange. 775 4). As a non-repudiation of receipt, since the returned MIC signed 776 by the receiving trading partner could only be signed by the 777 receiving trading partner. 779 4.2 Requesting a signed receipt 781 Message Disposition Notifications are requested as per the draft-ietf- 782 receipt-mdn-01.txt. A request that the receiving user agent issue a 783 message disposition notification is made by placing the following header 784 into the message to be sent: 786 mdn-request-header = "Disposition-notification-to" ":" address 788 The address field is specified as an RFC 822 user@domain address, and is 789 the return address for the message disposition notification. 791 4.3 Message Disposition Notification Format 793 The format of a message disposition notification is as specified in draft- 794 ietf-receipt-mdn-01.txt. For use in EDI over the Internet the following 795 format will be used: 797 - content-type - per RFC1892 and the ietf-receipt-mdn specification 799 - reporting-ua-field - per ietf-receipt-mdn specification 801 - mdn-gateway-field - per ietf-receipt-mdn specification 803 - original-recipient-field - per ietf-receipt-mdn specification 805 - final-recipient-field - per ietf-receipt-mdn specification 807 - original-message-id-field - per ietf-receipt-mdn specification 809 - disposition-field - for EDI use: 811 * autoprocessed - when the received content(s) are 812 successfully processed 814 * decryption_failed - when the receiver could not decrypt the 815 contents 817 * authentication_failed - when the receiver could not 818 authenticate the sender 820 * integrity_check_failed - when the receiver could not verify 821 content integrity 823 - extension field - the following extension field will be added in 824 order to support signed-receipts for RFC 1767 specified content 825 types and multi-part specified content types which includes RFC 826 1767 content types. The extension field is sent only when the 827 received contents are successfully processed. 829 - extension field = "X-" "Received-MIC" ":" MIC 831 MIC or message integrity check, is defined as the result of a one-way 832 hash function applied to the received EDI Interchange and RFC 1767 MIME 833 content type information, or the multi-part MIME content containing 834 RFC 1767 MIME EDI content information. The MIC is also referred to as a 835 MD5 or message digest. The MIC that is returned in this message 836 disposition notification extension field is signed with the receiving 837 trading partner's private key. 839 4.4 Message Disposition Notification Processing 841 4.4.1 Large File Processing 843 Large EDI Interchanges sent via SMTP can be automatically 844 fragmented by some message transfer agents. A subtype of message, 845 "partial", is defined in RFC 1521 to allow large objects to be 846 delivered as separate pieces of mail and to be automatically 847 reassembled by the receiving user agent. Using message, "partial", 848 can help alleviate fragmentation of large messages by different 849 message transfer agents, but does not completely eliminate the 850 problem. It is still possible that a piece of a partial message, 851 upon re-assembly, may prove themselves to contain a partial 852 message. This is allowed by the Internet standards, and it is 853 the responsibility of the user agent to reassemble the fragmented 854 pieces. 856 It is recommended that the size of the EDI Interchange sent via 857 SMTP be configurable so that if fragmentation does occur, then 858 message, "partial" can be used to send the large EDI Interchange 859 in smaller pieces. RFC 1521 defines the use of Content-Type: 860 message/partial. 862 It is also recommended that very large EDI files not be sent via 863 SMTP and a file transfer protocol be used instead. 865 The receiving UA is required to re-assemble the original message 866 before sending the message disposition notification to the 867 original sender of the message. A message disposition notification 868 is used to specify the disposition of the entire message that was 869 sent, and should not be returned by a processing UA until the 870 entire message is received, even if the received message requires 871 re-assembling. 873 4.4.2 Example 875 The following is an example of an MDN returned by a UA after 876 processing a MIME EDI content type that was signed and encrypted: 878 NOTE: This example is provided as an illustration only, and is 879 not considered part of the protocol specification. If an example 880 conflicts with the protocol definitions specified above or in the 881 other referenced RFCs, the example is wrong. 883 Date: Thur, 19 Sep 1996 00:16:55 (EDT) -0400 884 From: Edi Recipient 885 Message-ID: <17759920005.12345@edicorp.com> 886 Subject: Signed Receipt 887 To: Edi Sender 888 MIME-Version 1.0 889 Content-Type: multipart/report; report-type=disposition-notification; 890 boundary = "xxxxx" 892 --xxxxx 894 The message sent to Edi Recipient has 895 been received, the EDI Interchange was succesfully decrypted and 896 its integrity was verified. In addition, the sender of the message, 897 Edi Sender was authenticated as the 898 originator of the message. There is no guarantee however that the 899 EDI Interchange was syntactically correct, or was received by the 900 EDI application. 902 --xxxxx 903 content-type: message/disposition-notification 905 Reporting-UA: good-edi-internet-ua.edicorp.com (ediua 1.0) 906 Original-Recipient: rfc822; Edi_Recipient@edicorp.com 907 Final-Recipient: rfc822; Edi_Recipient@edicorp.com 908 Original-Message-ID: <17759920005.12345@edicorp.com> 909 Disposition: autoprocessed 910 X-Received-MIC: Q2hlY2sgSW50XwdyaXRIQ�� 912 --xxxxx 913 content-type: message/rfc822 915 --xxxxx-- 917 As specified by RFC 1892. Returning the original message is not 918 necessary. This is an optional body part. 920 5. Public key certificate handling 922 5.1 Near term approach 924 In the near term, and compliant with this Applicability Statement, 925 self certification according to guidelines described in the functional 926 requirements document, "Requirements for Inter-operable Internet EDI" 927 [9] (can be found at www.ietf.org). 929 5.2 Long term approach 931 Long term, certifying authorities such as Verisign may be used in 932 compliance with X.509 guidelines, however, this Applicability 933 Statement does NOT require use of a certifying authority (CA). 935 6. Authors' Addresses 937 Mats Jansson 938 mjansson@agathon.com 939 LiNK 940 2317 Broadway, Suite 330 941 Redwood City, CA 94063 USA 943 Chuck Shih 944 chucks@actracorp.com 945 Actra Corp. 946 610 East Caribbean Drive 947 Sunnyvale, CA XXXXX USA 949 Nancy Turaj 950 nturaj@mail04.mitre.org 951 MITRE Corporation 952 Mailstop: W657 953 1820 Dolley Madison Blvd. 954 McLean, VA 22102-3481 USA 956 Rik Drummond 957 drummond@onramp.com 958 The Drummond Group 959 5008 Bentwood Ct. 960 Ft. Worth, TX 76132 USA 962 7. References 964 [1] N. Borenstein, N.Freed, "MIME (Multipurpose Internet Mail Extensions) 965 Part One: Mechanisms for Specifying and Describing the Format of 966 Internet Message Bodies", RFC 1521, September 23, 1993. 968 [2] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767, March 2, 969 1995. 971 [3] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", 972 STD 11, RFC 822, August 13, 1982. 974 [4] M. Elkins, "MIME Security With Pretty Good Privacy (PGP)", RFC 2015, 975 Sept. 1996. 977 [5] R. Fajman, "An Extensible Message Format for Message Disposition 978 Notifications", draft-ietf-receipt-mdn-01.txt, May 13, 1996. 980 [6] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for 981 MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, 1995 983 [7] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821, August 984 1, 1982. 986 [8] RSA Laboratories, "S/MIME Message Specification; PKCS Security 987 Services for MIME", Version of February 23, 1996. 989 [9] C. Shih, "Requirements for Inter-operable Internet EDI", July 1996. 991 [10] G. Vaudreuil, "The Multipart/Report Content Type for the Reporting of 992 Mail System Administrative Messages", RFC 1892, January 15, 1996.