idnits 2.17.1 draft-ietf-ediint-as1-00.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-16) 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. == 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 164 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 7 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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) -- Missing reference section? '7' on line 69 looks like a reference -- Missing reference section? '3' on line 70 looks like a reference -- Missing reference section? '1' on line 71 looks like a reference -- Missing reference section? '6' on line 72 looks like a reference -- Missing reference section? '9' on line 73 looks like a reference -- Missing reference section? '2' on line 108 looks like a reference -- Missing reference section? '4' on line 75 looks like a reference -- Missing reference section? '5' on line 76 looks like a reference -- Missing reference section? '8' on line 77 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 11 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-00.txt Chuck Shih, Actra 3 Expire in six months 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 3.5 Structure of an EDI MIME message - No encryption/Signature 83 3.5.1 S/MIME 84 3.5.2 PGP/MIME 85 3.6 Structure of an EDI MIME message - Encryption/Signature 86 3.6.1 S/MIME 87 3.6.2 PGP/MIME 89 4. Receipts 90 4.2 Requesting a signed receipt 91 4.3 Message Disposition Notification Format 92 4.4 Message Disposition Notification Processing 93 4.4.1 Segmented Messages 94 4.4.2 Multiple Mime Body Parts 95 4.4.3 Example 97 5. Public key certificate handling 98 5.1 Near term approach 99 5.2 Long term approach 101 6. Authors' Addresses 103 7. References 105 1. Introduction 107 Previous work on internet EDI focussed on specifying MIME content 108 types for EDI data ([2] RFC 1767). This Applicability Statement 109 expands on RFC 1767 to specify use of a comprehensive set of data 110 security features, specifically data privacy, data 111 integrity/authenticity, non-repudiation of origin and non-repudiation 112 of receipt. This draft recognizes contemporary RFCs and internet 113 drafts and is attempting to "re-invent" as little as possible. 115 With an enhancements in the area of "receipts", as described below 116 (3.1.8), secure internet MIME based EDI can be accomplished by using 117 and complying with the following RFC's and drafts: 119 -RFC 821 SMTP 120 -RFC 822 Text Message Formats 121 -RFC 1521 MIME 122 -RFC 1767 EDI Content Type 123 -RFC 1847 Security Multiparts for MIME 124 -RFC 1892 Multipart/Report 125 -Internet draft: Message Disposition Notification (fajman) 126 -RFC 2015 MIME/PGP (elkins) 127 -S/MIME Specification (RSA) 129 Our intent here is to define clearly and precisely how these 130 are pieced together and what is required by user agents to be 131 compliant with this Applicability Statement. 133 2. Overview 135 2.1 Purpose of a security guideline for MIME EDI 137 The purpose of these specifications is to ensure interoperability 138 between EDI user agents, invoking some or all of the commonly 139 expected security features. This standard is also NOT limited to 140 strict EDI use, but applies to any electronic commerce application 141 where business data needs to be exchanged over the internet in a 142 secure manner. 144 2.2 Definitions 146 2.2.1. Terms 148 EDI Electronic Data Interchange 150 EC Electronic Commerce 152 Receipt The functional message that is sent from a 153 receiver to a sender to acknowledge receipt 154 of an EDI/EC interchange 156 Signed Receipt Same as above, but with a digital signature