From owner-ietf-ediint Wed Feb 14 10:51:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA16427 for ietf-ediint-bks; Wed, 14 Feb 1996 08:38:12 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id IAA16422 for ; Wed, 14 Feb 1996 08:38:10 -0800 (PST) Received: from [199.184.212.164] (stockyard01.onramp.net [199.184.212.164]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id KAA13138 for ; Wed, 14 Feb 1996 10:45:31 -0600 (CST) Message-Id: Mime-Version: 1.0 Date: Wed, 14 Feb 1996 10:51:38 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Welcome to to the workgroup Sender: owner-ietf-ediint@imc.org Precedence: bulk Welcome! Before we get to work on the EDI over Internet Transport interpretability issues lets take care of some administrative details first. - The deliverable is: Define the use of security and associated processes for exchanging EDI transactions in MIME in a manner which supports core, functional, transport services requirements. - The first milestone is in about six weeks. We must produce an outline for the requirements document. When we complete the effort we hope your companies will start implementing and testing the procedures and standards we will recommend in the paper. Please, start generating interest within you companies _now_ in anticipation of that final effort. If you need help, I will be glad to make phone calls in coordination with you to the appropriate people in your organization. - I estimate this effort will take one hour per day from each participant to achieve the initial milestone. The effort level for the subsequent milestones is currently unknown. - Commerce Net involvement: We will be cooperating and coordinating this effort with a similar Commerce Net effort. One of the important differences of IETF standard efforts is that before something really becomes an RFC it must demonstrate production capability. To that end, when we get done with our effort, Commerce Net will take over to help facilitate the inter-operability testing of "EDI over Internet" using the standards we recommend. - We need volunteers for the editor(s) of the paper. Do we have any? Please contact me if you are interested. - Please get other key people involved in this effort. OK. That is enough administrative detail. Let get to work. Lets start this process by identifying the issues and requirements necessary to "Define the use of security and associated processes for exchanging EDI transactions using MIME". I suggest that we each take some time and _brainstorm_ EDI/Internet issues near and dear to our hearts in a format that will facilitate distribution and discussion. The format: REQUIREMENT - TITLE - Description or ISSUE- TITLE - Description The difference may not always be clear, but lets not worry about that on the first pass and just _brainstorm_ those items and issues we must address to achieve the goal. I will offer the first one -- and the most obvious -- privacy. REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. Feel free to modify these if you feel they need clarification. Let spend through Friday generating the first set of these. Verbosity is not a requirement at this stage -- clarity is. So lets keep them as short as is appropriate. In closing, 1) we need an editor(s), 2) make sure you have the time to do this, 3) get other key people in your company involved -add'em to the listserv-- and 4) start discussing with appropriate individuals the inter-operability testing activities need anticipated at the end of our process. Thanks..Rik Rik Drummond 817 294 7339 From owner-ietf-ediint Wed Feb 14 13:44:18 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA17143 for ietf-ediint-bks; Wed, 14 Feb 1996 11:30:49 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id LAA17138 for ; Wed, 14 Feb 1996 11:30:48 -0800 (PST) Received: from [199.184.212.199] (stockyard36.onramp.net [199.184.212.199]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id NAA19464 for ; Wed, 14 Feb 1996 13:38:11 -0600 (CST) Message-Id: Mime-Version: 1.0 Date: Wed, 14 Feb 1996 13:44:18 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Who is going to ietf in march? Sender: owner-ietf-ediint@imc.org Precedence: bulk Will any of you be going to the IETF meeting in LA on 4-8 March? We plan to have a Birds of a Feather meeting there to gain futher visibilty. Later...rik From owner-ietf-ediint Wed Feb 14 15:07:54 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id MAA17483 for ietf-ediint-bks; Wed, 14 Feb 1996 12:54:25 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id MAA17478 for ; Wed, 14 Feb 1996 12:54:23 -0800 (PST) Received: from [199.184.212.223] (stockyard40.onramp.net [199.184.212.203]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id PAA06552 for ; Wed, 14 Feb 1996 15:01:46 -0600 (CST) Message-Id: Mime-Version: 1.0 Date: Wed, 14 Feb 1996 15:07:54 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: RE: Welcome to to the workgroup Sender: owner-ietf-ediint@imc.org Precedence: bulk >>I will offer the first one -- and the most obvious -- privacy. >> >>REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI >>transaction within MIME including the ISA segment using an existing >>encryption standard or combination of standards such as PGP, DES, MOSS or >>S/MIME. > >Before we get too involved in the technical details, would someone please >clarify the "exportability" of these various encryption methods to >non greencard holders. > Ken, I suggest you submit an Issue statement which addresses your concern such as: ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. An we will work the issue after we get done _brainstorming_ in a few days. Good Point!...Later...Rik > >------------------------------------- >Ken Steel >The University of Melbourne >Department of Computer Science >ksteel@cs.mu.oz.au From owner-ietf-ediint Wed Feb 14 23:03:47 1996 X-Sender: boblyons@hiway1.exit109.com Mime-Version: 1.0 Date: Wed, 14 Feb 1996 23:03:47 -0500 To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Non-repudiation of receipt Sender: owner-ietf-ediint@imc.org Precedence: bulk REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. Note that a trusted third party, such as an EDI VAN, can provide non-repudiation of receipt without the use of digital signatures. However, most, if not all, Internet Service Providers do not offer this service. MOSS, PEM, PGP and S/MIME meet most of the security requirements of users doing EDI over the Internet; however, they do not provide non-repudiation of receipt. The IETF-EDIINT group should try to pursuade any IETF groups working on e-mail security and e-mail receipts to develop a standard for non-repudiation of receipt. We should also align ourselves with any other groups that need this feature for their Internet e-mail applications. A possible interim solution is to use the 997. The receiver of an EDI message would place the digital signature of this EDI message into a 997, and return the 997 to the sender of the original EDI message. The problem with this solution is that e-mail users, EDIFACT users and proprietary EDI users will not want to use an ANSI X12 transaction set for non-repudiation of receipt. This will result in multiple solutions for non-repudiation of receipt (i.e., one for e-mail, one for X12-based EDI, one for EDIFACT-based EDI, etc.). Another possible interim solution is to use the EDIFACT AUTACK message, which was designed to provide non-repudiation of receipt. This is how Premenos's Templar product provides non-repudiation of receipt. However, this solution has the same problem as the 997-based solution. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Thu Feb 15 14:18:33 1996 From: ksteel@cs.mu.oz.au Date: Thu, 15 Feb 96 14:18:33 PST Subject: RE: Non-repudiation of receipt To: ietf-ediint@imc.org Mime-Version: 1.0 Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Wed, 14 Feb 1996 23:03:47 -0500 >From: boblyons@unidex.com (Robert C. Lyons) >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. Might I strongly recommend the Non-repudiation receipt is not tied in any way to an EDI method. Whatever is done should be equally applicable to X12, EDIFACT, Open-edi and any other flavour that comes along. If we follow the model: Application Layer EDI Layer Communication Layer. and contain the solutions we are working up only to the communications layer, we will have achieved something. Using solutions such as 997 means we are all wasting our time on this - it is not a universal solution - just another contribution to the non-standard mess called edi. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Thu Feb 15 10:30:28 1996 Date: Thu, 15 Feb 96 10:30:28 MET From: NAD+FR+EDI ENGINEERING:"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'" To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Apparently-To: ietf-ediint@imc.org Subject: RE: Secrecy and authentication Sender: owner-ietf-ediint@imc.org Precedence: bulk ISSUE - Dont duplicate what is already provided within the EDI standards. Both X12 and EDIFACT have security solutions of their own. We should understand these solutions, and decide if any meet the requirements we need for EDI over the Internet. Where there are no instant solutions we should provide solutions which do not clash with the existing EDI standards. To set the ball rolling, X12.58, X12 Security Structures defines security at two levels, where security covers authentification and encrytion. The levels are at the functional group and transaction set levels. If both levels were applied you would see a sequence of segments as... ISA-Interchange Header GS-Functional group Header S1S-Security Header Level 1 ST-Transaction Set Header S2S-Security Header Level 2 ...transaction set segments S2E-Security Trailer Level 2 SE-Transaction Set Trailer ...other transaction sets (either secured or unsecured) S1E-Security Trailer Level 1 GE-Functional Group Trailer ...other functional groups (either secured or unsecured) IEA-Interchange trailer. Either level 1 or level 2 security can be used or both together. Note that the security does not kick in until after the GS so ALL addressing information is visible. The security offered is: o Authentification of content via the use of MAC codes. o Confidentiality of content through encryption. Regards, Graham From owner-ietf-ediint Thu Feb 15 11:25:07 1996 From: gami@edieng.enet.dec.com Date: Thu, 15 Feb 96 11:25:07 MET To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Cc: gami@edieng.enet.dec.com Apparently-To: ietf-ediint@imc.org Subject: Multiple/Batched Transaction Sets Sender: owner-ietf-ediint@imc.org Precedence: bulk This is not an ISSUE or REQUIREMENT. I need clarification on one point that might affect any security schemes chose. RFC1767 is a little unclear on the use of Multiple/Batched Transaction Sets (Interchanges) within a single message. Is this allowed ?, if so, how ?, using single/multiple bodyparts ? Raj Gami From owner-ietf-ediint Thu Feb 15 11:36:38 1996 From: gami@edieng.enet.dec.com Date: Thu, 15 Feb 96 11:36:38 MET To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Cc: gami@edieng.enet.dec.com Apparently-To: ietf-ediint@imc.org Subject: tunnels Sender: owner-ietf-ediint@imc.org Precedence: bulk ISSUE - encrypted tunnels We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Raj Gami From owner-ietf-ediint Thu Feb 15 07:47:37 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 07:47:37 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Re: Non-repudiation of receipt Sender: owner-ietf-ediint@imc.org Precedence: bulk Great statement Bob. We will have to discuss the extended comments later after we get the all statements collected. Any body else have any other ideas/issues for EDI over Internet? ......later....rik >From: boblyons@unidex.com (Robert C. Lyons >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. > >Note that a trusted third party, such as an EDI VAN, can provide >non-repudiation of receipt without the use of digital signatures. However, >most, if not all, Internet Service Providers do not offer this service. > >MOSS, PEM, PGP and S/MIME meet most of the security requirements of users >doing EDI over the Internet; however, they do not provide non-repudiation of >receipt. > >The IETF-EDIINT group should try to pursuade any IETF groups working on >e-mail security and e-mail receipts to develop a standard for >non-repudiation of receipt. We should also align ourselves with any other >groups that need this feature for their Internet e-mail applications. > >A possible interim solution is to use the 997. The receiver of an EDI >message would place the digital signature of this EDI message into a 997, >and return the 997 to the sender of the original EDI message. The problem >with this solution is that e-mail users, EDIFACT users and proprietary EDI >users will not want to use an ANSI X12 transaction set for non-repudiation >of receipt. This will result in multiple solutions for non-repudiation of >receipt (i.e., one for e-mail, one for X12-based EDI, one for EDIFACT-based >EDI, etc.). > >Another possible interim solution is to use the EDIFACT AUTACK message, >which was designed to provide non-repudiation of receipt. This is how >Premenos's Templar product provides non-repudiation of receipt. However, >this solution has the same problem as the 997-based solution. > > >Bob Lyons >EDI & Internet Consultant >Unidex, Inc. >1-908-975-9877 >boblyons@unidex.com >EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Thu Feb 15 07:52:17 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 07:52:17 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: RE: Non-repudiation of receipt Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk I suggest the following way to express your fine comment: ISSUE - NON-REPUDIATION REQUIREMENTS - Recommend the Non-repudiation receipt is not tied in any way to an EDI method. Whatever is done should be equally applicable to X12, EDIFACT, Open-edi and any other flavour that comes along. Rik ------------------forwarded message --------------------------- >FROM: ksteel@cs.mu.oz.au >>Date: Wed, 14 Feb 1996 23:03:47 -0500 >>From: boblyons@unidex.com (Robert C. Lyons) > >>REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >>obtains undeniable proof that the recipient received the message and the >>message was not altered in transit. Non-repudiation of receipt is >>implemented via an acknowledgment; the recipient of an EDI message returns >>this acknowledgment to the sender of the EDI message. This acknowledgment >>contains the digital signature of the EDI message; also, the acknowledgment >>is digitally signed by the receiver of the EDI message. > >Might I strongly recommend the Non-repudiation receipt is not tied in any >way to an EDI method. Whatever is done should be equally applicable to >X12, EDIFACT, Open-edi and any other flavour that comes along. > >If we follow the model: > > Application Layer > > EDI Layer > > Communication Layer. > >and contain the solutions we are working up only to the communications layer, >we will have achieved something. Using solutions such as 997 means we are >all wasting our time on this - it is not a universal solution - just another >contribution to the non-standard mess called edi. > >------------------------------------- >Ken Steel >The University of Melbourne >Department of Computer Science >ksteel@cs.mu.oz.au From owner-ietf-ediint Thu Feb 15 08:02:37 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 08:02:37 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: tunnels Sender: owner-ietf-ediint@imc.org Precedence: bulk Excellent! I reformated slightly....rik ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. --- begin forwarded text From: gami@edieng.enet.dec.com Date: Thu, 15 Feb 96 11:36:38 MET To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Cc: gami@edieng.enet.dec.com Apparently-To: ietf-ediint@imc.org Subject: tunnels Sender: owner-ietf-ediint@imc.org Precedence: bulk ISSUE - encrypted tunnels We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Raj Gami --- end forwarded text From owner-ietf-ediint Thu Feb 15 08:00:51 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 08:00:51 -0600 To: "NAD+FR+EDI ENGINEERING:\"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'\"" From: drummond@onramp.net (Rik Drummond) Subject: RE: Secrecy and authentication Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Good Comment! Any one else. Lets get the thoughts down. By the way since we are only transporting the transactions (EDIFACT messages) our interest should stop at the transaction level (entire X12 envelop) and not the Group level. Would you agree or not? ISSUE - TRANPORT ONLY - since we are only transporting the transactions (EDIFACT messages) our interest should stop at the transaction level (entire X12 envelop) and not the Group level. Rik p.s. this is why an X12C person will be on this list soon.... --------------------------------------------------------------------- From owner-ietf-ediint Thu Feb 15 08:01:51 1996 From: "NAD+FR+EDI ENGINEERING:\"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'\"" >ISSUE - Dont duplicate what is already provided within the EDI standards. > >Both X12 and EDIFACT have security solutions of their own. We should >understand >these solutions, and decide if any meet the requirements we need for EDI over >the Internet. Where there are no instant solutions we should provide solutions >which do not clash with the existing EDI standards. > >To set the ball rolling, X12.58, X12 Security Structures defines security >at two >levels, where security covers authentification and encrytion. The levels >are at >the functional group and transaction set levels. If both levels were >applied you >would see a sequence of segments as... > > ISA-Interchange Header > GS-Functional group Header > S1S-Security Header Level 1 > ST-Transaction Set Header > S2S-Security Header Level 2 > ...transaction set segments > S2E-Security Trailer Level 2 > SE-Transaction Set Trailer > ...other transaction sets (either secured or unsecured) > S1E-Security Trailer Level 1 > GE-Functional Group Trailer > ...other functional groups (either secured or unsecured) > IEA-Interchange trailer. > >Either level 1 or level 2 security can be used or both together. Note that the >security does not kick in until after the GS so ALL addressing information is >visible. > > The security offered is: > o Authentification of content via the use of MAC codes. > o Confidentiality of content through encryption. > >Regards, > >Graham From owner-ietf-ediint Thu Feb 15 08:20:39 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 08:20:39 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #1 Sender: owner-ietf-ediint@imc.org Precedence: bulk Here is what we have so far. Lets keep duing this for a few more days, but lets approach it from a different view point also. If I am attempting "interoperate" with other vendors over Internet, what are my technical concerns? Why has EDI over Internet not takent off? What is holding it back? Is it technical, lack of understanding or lack of interest? later...Rik p.s. Keep up the good work. Soon as our X12C rep. get on the list we will discuss and explore the X12C work and see which problems it solves for EDI on Internet Transport. REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. ISSUE - Dont duplicate what is already provided within the EDI standards. ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. From owner-ietf-ediint Thu Feb 15 14:35:39 1996 Date: Thu, 15 Feb 1996 14:35:39 +0000 From: jamster@attmail.com (Jim Amster) Phone: +1 908 576 6462 Subject: RE: Non-repudiation of receipt Importance: High Default-Options: /RECEIPT To: ietf-ediint@imc.org X-MAPI-Message-ID: 00000000407F12B6D5E2CE119EA7444553540000C4012600 Mime-Version: 1.0 Sender: owner-ietf-ediint@imc.org Precedence: bulk I agree that we need to have a generic method that goes beyond EDI. The effort to define a non-repudiable receipt would seem to be an activity that might be co-worked with the IETF Notary group. That group recently published the following RFCs. RFC 1894 An Extensible Message Format for Delivery Status Notifications RFC 1891 SMTP Service Extension for Delivery Status Notifications There had been some discussion in that group of generating a work item on receipts. I am not sure if that item is still under development, has been suspended or what. It would seem that non-repudiation could be added to that work item. Jim Amster AT&T jamster@mail.att.net ---------- From owner-ietf-ediint Thu Feb 15 02:47:00 1996 From: Rik Drummond Sent: Thursday, February 15, 1996 2:47 AM To: internet!imc.org!ietf-ediint Subject: Re: Non-repudiation of receipt Great statement Bob. We will have to discuss the extended comments later after we get the all statements collected. Any body else have any other ideas/issues for EDI over Internet? ......later....rik >From: boblyons@unidex.com (Robert C. Lyons >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. > >Note that a trusted third party, such as an EDI VAN, can provide >non-repudiation of receipt without the use of digital signatures. However, >most, if not all, Internet Service Providers do not offer this service. > >MOSS, PEM, PGP and S/MIME meet most of the security requirements of users >doing EDI over the Internet; however, they do not provide non-repudiation of >receipt. > >The IETF-EDIINT group should try to pursuade any IETF groups working on >e-mail security and e-mail receipts to develop a standard for >non-repudiation of receipt. We should also align ourselves with any other >groups that need this feature for their Internet e-mail applications. > >A possible interim solution is to use the 997. The receiver of an EDI >message would place the digital signature of this EDI message into a 997, >and return the 997 to the sender of the original EDI message. The problem >with this solution is that e-mail users, EDIFACT users and proprietary EDI >users will not want to use an ANSI X12 transaction set for non-repudiation >of receipt. This will result in multiple solutions for non-repudiation of >receipt (i.e., one for e-mail, one for X12-based EDI, one for EDIFACT-based >EDI, etc.). > >Another possible interim solution is to use the EDIFACT AUTACK message, >which was designed to provide non-repudiation of receipt. This is how >Premenos's Templar product provides non-repudiation of receipt. However, >this solution has the same problem as the 997-based solution. > > >Bob Lyons >EDI & Internet Consultant >Unidex, Inc. >1-908-975-9877 >boblyons@unidex.com >EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Thu Feb 15 07:22:36 1996 Date: Thu, 15 Feb 96 07:22:36 PST From: klaus@thor.premenos.com (Klaus-Dieter Naujok) Reply-To: klaus@premenos.com (Klaus-Dieter Naujok) To: ietf-ediint@imc.org Subject: Re: Two more Possible Statements Sender: owner-ietf-ediint@imc.org Precedence: bulk On Wed, 14 Feb 1996 21:40:29 -0600 Rik wrote: >Klaus...I am sure you have a couple with respect to non-repudiation of >receipt. How about sending us a couple. Rik, a quick reply to let you know I am not ignoring your request, I will forward my 2 cents soon, but first, I must finsh hosting a UN/ECE EDIFACT Steering Group Meeting :-) ------------------------------------------------------------------ Klaus-Dieter Naujok | Premenos, Concord, CA, USA, 94520 | "TCP/IP - Living the OSI Voice: +1-510-688-2791 | dream today" - Stef Fax: +1-510-602-2133 | Web: http://www.premenos.com/klaus/ | From owner-ietf-ediint Thu Feb 15 09:45:56 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 09:45:56 -0600 To: Trevor Richards From: drummond@onramp.net (Rik Drummond) Subject: RE: Secrecy and authentication Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk No, I did not of made myself clear -- sorry. We will not do anything to the "EDI Package"/ EDI envelop/ message. We just transported the entire thing. We can not touch or do anything to the EDI Package -- just transport it. I am glad you are aboard and have significant X12 experience. We need that view in this.....later...Rik >Rik > >If I understand this issue correctly, it is suggesting that we only consider >transporting transaction sets (X12:ST segment through SE, EDIFACT:UNH >segment through UNT) only via the Internet, or at least provide the option >to do so. The mandatory interchange control segments (X12:ISA,GS,GE,IEA, >EDIFACT:UNB,UNZ) contain both counters to ensure data integrity and >information about the interchange control segment standard version >(X12:X12.5, EDIFACT:ISO 9735) used to construct the interchange control >segments, and the standard version used to construct the transaction >sets/messages. Our interest must start at the interchange level, as this is >an integral part of the tranmission of transaction sets/messages. The group >level is (i) mandatory for X12 interchanges as it contains the standard >version used to construct the transaction sets, and (ii) optional for >EDIFACT messages as the standard version/release information is carried in >the UNB segment. > >I would suggest that the issue be restated as:- > >ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that >can be transported via the Internet. The definition of an interchange for >MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the >relevant standards, and should be defined between trading partners who >choose to use the Application/EDI-Consent MIME type. Can multiple >interchanges be transported in a single MIME envelope, or can only a single >interchange be contained in a single MIME envelope ? > >By the way, I have represented both my previous company and Trinary Systems >on the X12C subcommittee intermittently over the past five years. > >At 08:00 AM 2/15/96 -0600, you wrote: >>Good Comment! Any one else. Lets get the thoughts down. By the way since >>we are only transporting the transactions (EDIFACT messages) our interest >>should stop at the transaction level (entire X12 envelop) and not the Group >>level. Would you agree or not? >> >>ISSUE - TRANPORT ONLY - since we are only transporting the transactions >>(EDIFACT messages) our interest should stop at the transaction level >>(entire X12 envelop) and not the Group level. >> >> >> >>Rik >> >>p.s. this is why an X12C person will be on this list soon.... >>--------------------------------------------------------------------- >> >>FROM: "NAD+FR+EDI ENGINEERING:\"PSE:DEC+GRAHAM >>HELLIAR:830-3173++REO2-F/D2'\"" >> >>>ISSUE - Dont duplicate what is already provided within the EDI standards. >>> >>>Both X12 and EDIFACT have security solutions of their own. We should >>>understand >>>these solutions, and decide if any meet the requirements we need for EDI over >>>the Internet. Where there are no instant solutions we should provide >>>solutions >>>which do not clash with the existing EDI standards. >>> >>>To set the ball rolling, X12.58, X12 Security Structures defines security >>>at two >>>levels, where security covers authentification and encrytion. The levels >>>are at >>>the functional group and transaction set levels. If both levels were >>>applied you >>>would see a sequence of segments as... >>> >>> ISA-Interchange Header >>> GS-Functional group Header >>> S1S-Security Header Level 1 >>> ST-Transaction Set Header >>> S2S-Security Header Level 2 >>> ...transaction set segments >>> S2E-Security Trailer Level 2 >>> SE-Transaction Set Trailer >>> ...other transaction sets (either secured or unsecured) >>> S1E-Security Trailer Level 1 >>> GE-Functional Group Trailer >>> ...other functional groups (either secured or unsecured) >>> IEA-Interchange trailer. >>> >>>Either level 1 or level 2 security can be used or both together. Note >>>that the >>>security does not kick in until after the GS so ALL addressing information is >>>visible. >>> >>> The security offered is: >>> o Authentification of content via the use of MAC codes. >>> o Confidentiality of content through encryption. >>> >>>Regards, >>> >>>Graham >> >> >> >> > > Trevor Richards phone : (512)345-3981 > Trinary Systems fax : (512)345-8705 > Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Thu Feb 15 09:49:44 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 09:49:44 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #2 Sender: owner-ietf-ediint@imc.org Precedence: bulk ** New**ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. ISSUE - Dont duplicate what is already provided within the EDI standards. ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. --- end forwarded text From owner-ietf-ediint Thu Feb 15 09:55:14 1996 Mime-Version: 1.0 Date: Thu, 15 Feb 1996 09:55:14 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: RE: Statement Summary #1 Sender: owner-ietf-ediint@imc.org Precedence: bulk Non-repudiation of origin and integrity are not include because no one brought them up yet. Feel free to make a couple of statements to that end. I appreciate the comments. So I can't spell X.435? I will do better next time. Please submitt the two statements and we will add them to the list. Later...rik --- begin forwarded text Subject: RE: Statement Summary #1 From: clueder@mail06.mitre.org (Christopher J. Kit Lueder) To: drummond@onramp.net (Rik Drummond) Date: Thu, 15 Feb 96 10:07:32 -0500 Hi Rik, Change "X.434" to "X.435". Is there a reason that integrity and non-repudiation of origin are not included? I know that confidentality (encryption) also can provide integrity, but you may want to have integrity without confidentiality (e.g., so that the X12 headers are visible for relay by EDI VANs). Kit. >Here is what we have so far. Lets keep duing this for a few more days, >but lets approach it from a different view point also. > >If I am attempting "interoperate" with other vendors over Internet, what >are my technical concerns? Why has EDI over Internet not takent off? What >is holding it back? Is it technical, lack of understanding or lack of >interest? > >later...Rik > >p.s. Keep up the good work. Soon as our X12C rep. get on the list we will >discuss and explore the X12C work and see which problems it solves for EDI >on Internet Transport. > > > > >REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI >transaction within MIME including the ISA segment using an existing >encryption standard or combination of standards such as PGP, DES, MOSS or >S/MIME. > >ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the >existing encryption standands for use in EDI over Internet. > >ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work >across the world and not be limited by the export (or legal) restrictions >of any nation. > >ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / >MIME / Internet package should implement compatible functionality (or be >easily translatable between) with X.434. > >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. > >ISSUE - Dont duplicate what is already provided within the EDI standards. > >ISSUE - encrypted tunnels - We should take into account any current/future >work that is going on to standardize encrypted tunnels. They may provide a >useful mechanism for providing security at the communications layer. > > > > --- end forwarded text From owner-ietf-ediint Thu Feb 15 09:50:31 1996 From: mgreely@prisminfo.com Date: Thu, 15 Feb 96 09:50:31 cdt Encoding: 20 Text To: ietf-ediint@imc.org Subject: EDI over the internet slow start Sender: owner-ietf-ediint@imc.org Precedence: bulk Requirement: improve use of internet for EDI messaging. Issue: slow start of EDI over the Internet I believe there are three items that have kept EDI off the internet. 1. VANs and end users don't have the ability to bridge e-mail to there translator, easily today. TCPIP for mainframes is not cheep. 2. The timeliness of data movement. 30 sec to over 4 hours to lost data with no tracking capability,for the same communication to move from Chicago to Houston. 3. The trusted comfort zone of the MIS edi staff and the VAN against the e-mail staff with free movement over the Internet. Marvin Greely Prism Information Inc. From owner-ietf-ediint Thu Feb 15 10:34:34 1996 From: mgreely@prisminfo.com Date: Thu, 15 Feb 96 10:34:34 cdt Encoding: 97 Text To: ietf-ediint@imc.org Subject: Re[2]: Statement Summary #1 Sender: owner-ietf-ediint@imc.org Precedence: bulk I also believe that the ISA header is critical for the document routing by standard means today. I can not route EDI files without it. The catch 22 could be that it also lets you know who is sending what to where. If it stays unencrypted who is to say that the ISA was not changed. ______________________________ Reply Separator _________________________________ Subject: RE: Statement Summary #1 Author: drummond@onramp.net (Rik Drummond) at INTERNET Date: 2/15/96 9:50 AM Non-repudiation of origin and integrity are not include because no one brought them up yet. Feel free to make a couple of statements to that end. I appreciate the comments. So I can't spell X.435? I will do better next time. Please submitt the two statements and we will add them to the list. Later...rik --- begin forwarded text Subject: RE: Statement Summary #1 From: clueder@mail06.mitre.org (Christopher J. Kit Lueder) To: drummond@onramp.net (Rik Drummond) Date: Thu, 15 Feb 96 10:07:32 -0500 Hi Rik, Change "X.434" to "X.435". Is there a reason that integrity and non-repudiation of origin are not included? I know that confidentality (encryption) also can provide integrity, but you may want to have integrity without confidentiality (e.g., so that the X12 headers are visible for relay by EDI VANs). Kit. >Here is what we have so far. Lets keep duing this for a few more days, >but lets approach it from a different view point also. > >If I am attempting "interoperate" with other vendors over Internet, what >are my technical concerns? Why has EDI over Internet not takent off? What >is holding it back? Is it technical, lack of understanding or lack of >interest? > >later...Rik > >p.s. Keep up the good work. Soon as our X12C rep. get on the list we will >discuss and explore the X12C work and see which problems it solves for EDI >on Internet Transport. > > > > >REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI >transaction within MIME including the ISA segment using an existing >encryption standard or combination of standards such as PGP, DES, MOSS or >S/MIME. > >ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the >existing encryption standands for use in EDI over Internet. > >ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work >across the world and not be limited by the export (or legal) restrictions >of any nation. > >ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / >MIME / Internet package should implement compatible functionality (or be >easily translatable between) with X.434. > >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. > >ISSUE - Dont duplicate what is already provided within the EDI standards. > >ISSUE - encrypted tunnels - We should take into account any current/future >work that is going on to standardize encrypted tunnels. They may provide a >useful mechanism for providing security at the communications layer. > > > > --- end forwarded text From owner-ietf-ediint Thu Feb 15 13:41:22 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id NAA25732 for ietf-ediint-bks; Thu, 15 Feb 1996 13:41:22 -0800 (PST) Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by imc.imc.org (8.7.3/8.7.1) with SMTP id NAA25727 for ; Thu, 15 Feb 1996 13:41:09 -0800 (PST) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id an10756; 15 Feb 96 17:34 GMT Received: from mirror.demon.co.uk ([158.152.45.217]) by relay-3.mail.demon.net id aa27568; 15 Feb 96 17:30 GMT Received: by mirror.demon.co.uk (Linux Smail3.1.28.1 #5) id m0tn7Pf-00036xC; Thu, 15 Feb 96 17:24 GMT Message-Id: From: Jonathan Allen Subject: Re: Re[2]: Statement Summary #1 To: mgreely@prisminfo.com Date: Thu, 15 Feb 1996 17:24:11 +0100 (GMT) Cc: ietf-ediint@imc.org In-Reply-To: <9601158244.AA824409289@mail.prisminfo.com> from "mgreely@prisminfo.com" at Feb 15, 96 10:34:34 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ietf-ediint@imc.org Precedence: bulk mgreely@prisminfo.com said: > > I also believe that the ISA header is critical for the document routing by > standard means today. I can not route EDI files without it. The catch 22 could > be that it also lets you know who is sending what to where. If it stays > unencrypted who is to say that the ISA was not changed. This misses the whole point of this work item. We are looking specifically at EDI over the Internet. Thus the Internet address determines who the package (be it a single transaction, a group, a bale) is going to. If it goes _to_ a VAN, then the VAN undoes whatever encoding/packaging we recommend and then carries on as normal with the plain-text ISA/UNB that it finds as the first thing in the message stream. If _from_ a VAN, then the VAN already knows from the ISA/UNB segment who the thing is going to, and they simply look up the appropriate Internet address, package the stuff and send it over the net by SMTP or whatever. Jonathan ------------------------------------------------------------------------------ Jonathan Allen | jonathan@mirror.demon.co.uk | Voice: 01271-79023 Barum Computer Consultants | jeremiah@cix.compulink.co.uk | Fax: 01271-24183 ------------------------------------------------------------------------------ From owner-ietf-ediint Thu Feb 15 19:11:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id TAA27051 for ietf-ediint-bks; Thu, 15 Feb 1996 19:11:38 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id TAA27046 for ; Thu, 15 Feb 1996 19:11:36 -0800 (PST) Received: from [199.184.212.135] (turnpike36.onramp.net [199.184.212.135]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id VAA04355 for ; Thu, 15 Feb 1996 21:19:01 -0600 (CST) X-Sender: drummond@onramp.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Feb 1996 21:25:13 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: RE: Non-repudiation of receipt Sender: owner-ietf-ediint@imc.org Precedence: bulk Thanks Jim. Do you work with either of the other ietf groups you noted? .. later...Rik >I agree that we need to have a generic method that goes beyond EDI. The >effort to define a non-repudiable receipt would seem to be an activity >that might be co-worked with the IETF Notary group. That group recently >published the following RFCs. > >RFC 1894 An Extensible Message Format for Delivery Status Notifications >RFC 1891 SMTP Service Extension for Delivery Status Notifications > >There had been some discussion in that group of generating a work item on >receipts. I am not sure if that item is still under development, has been >suspended or what. It would seem that non-repudiation could be added to >that work item. > >Jim Amster >AT&T >jamster@mail.att.net >---------- >From: Rik Drummond >Sent: Thursday, February 15, 1996 2:47 AM >To: internet!imc.org!ietf-ediint >Subject: Re: Non-repudiation of receipt > >Great statement Bob. We will have to discuss the extended comments later >after we get the all statements collected. Any body else have any other >ideas/issues for EDI over Internet? ......later....rik > > >>From: boblyons@unidex.com (Robert C. Lyons > >>REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >>obtains undeniable proof that the recipient received the message and the >>message was not altered in transit. Non-repudiation of receipt is >>implemented via an acknowledgment; the recipient of an EDI message returns >>this acknowledgment to the sender of the EDI message. This acknowledgment >>contains the digital signature of the EDI message; also, the acknowledgment >>is digitally signed by the receiver of the EDI message. >> >>Note that a trusted third party, such as an EDI VAN, can provide >>non-repudiation of receipt without the use of digital signatures. However, >>most, if not all, Internet Service Providers do not offer this service. >> >>MOSS, PEM, PGP and S/MIME meet most of the security requirements of users >>doing EDI over the Internet; however, they do not provide non-repudiation of >>receipt. >> >>The IETF-EDIINT group should try to pursuade any IETF groups working on >>e-mail security and e-mail receipts to develop a standard for >>non-repudiation of receipt. We should also align ourselves with any other >>groups that need this feature for their Internet e-mail applications. >> >>A possible interim solution is to use the 997. The receiver of an EDI >>message would place the digital signature of this EDI message into a 997, >>and return the 997 to the sender of the original EDI message. The problem >>with this solution is that e-mail users, EDIFACT users and proprietary EDI >>users will not want to use an ANSI X12 transaction set for non-repudiation >>of receipt. This will result in multiple solutions for non-repudiation of >>receipt (i.e., one for e-mail, one for X12-based EDI, one for EDIFACT-based >>EDI, etc.). >> >>Another possible interim solution is to use the EDIFACT AUTACK message, >>which was designed to provide non-repudiation of receipt. This is how >>Premenos's Templar product provides non-repudiation of receipt. However, >>this solution has the same problem as the 997-based solution. >> >> >>Bob Lyons >>EDI & Internet Consultant >>Unidex, Inc. >>1-908-975-9877 >>boblyons@unidex.com >>EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Thu Feb 15 22:48:18 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id WAA27800 for ietf-ediint-bks; Thu, 15 Feb 1996 22:48:18 -0800 (PST) Received: from ns1.indirect.com (ns1.indirect.com [165.247.1.3]) by imc.imc.org (8.7.3/8.7.1) with SMTP id WAA27795 for ; Thu, 15 Feb 1996 22:48:14 -0800 (PST) Received: from dave_d.indirect.com (s161.phxslip4.indirect.com [165.247.24.161]) by ns1.indirect.com (8.6.12/8.6.6) with SMTP id XAA26680; Thu, 15 Feb 1996 23:55:55 -0700 Message-Id: <2.2.32.19960216065550.00719894@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Feb 1996 23:55:50 -0700 To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org From: Dave Darnell Subject: RE: Non-repudiation of receipt Sender: owner-ietf-ediint@imc.org Precedence: bulk I believe non-repudiation is extremely important and should be approached from the lower communication protocol layers of SMTP. 997 leaves too much to custom implementations of EDI. NRR should be guaranteed, not by the application layer of our protocols, but by the network and/or transport layers. i.e. my NRR will differ from some other person's NRR if it depends on my particular 997 implementation. Re. current X12.58 standards: why limit our thinking to current standards?? We are doing this to set a standard, not to adhere to X12.58...... Let's do what make's sense and not what conventional thinking tells us in current standards. Let's set standards for today's technology and not worry about our "legacy" standards or current vested interests. Also I think that if we worry about VAN routings of EDI transactions that require unencrypted ISA's we will limit our options. If a network does not recognize SMTP headers then they are not worth worrying about because they are not, by definition, part of the Internet or subject to IETF RFC's. What are we doing here? IETF RFC's or something else? Is this not a forum for Internet EDI standard setting? X12.58 is, IMHO, highly overrated and is another example of a standard that is looking for a practical application. Standards should support what is pratical to do in today's and tomorrow's technologies and not be formulated prior to this. Regards, Dave Darnell At 09:25 PM 2/15/96 -0600, Rik Drummond wrote: >Thanks Jim. > > Do you work with either of the other ietf groups you noted? .. later...Rik > > > >>I agree that we need to have a generic method that goes beyond EDI. The >>effort to define a non-repudiable receipt would seem to be an activity >>that might be co-worked with the IETF Notary group. That group recently >>published the following RFCs. >> >>RFC 1894 An Extensible Message Format for Delivery Status Notifications >>RFC 1891 SMTP Service Extension for Delivery Status Notifications >> >>There had been some discussion in that group of generating a work item on >>receipts. I am not sure if that item is still under development, has been >>suspended or what. It would seem that non-repudiation could be added to >>that work item. >> >>Jim Amster >>AT&T >>jamster@mail.att.net >>---------- >>From: Rik Drummond >>Sent: Thursday, February 15, 1996 2:47 AM >>To: internet!imc.org!ietf-ediint >>Subject: Re: Non-repudiation of receipt >> >>Great statement Bob. We will have to discuss the extended comments later >>after we get the all statements collected. Any body else have any other >>ideas/issues for EDI over Internet? ......later....rik >> >> >>>From: boblyons@unidex.com (Robert C. Lyons >> >>>REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >>>obtains undeniable proof that the recipient received the message and the >>>message was not altered in transit. Non-repudiation of receipt is >>>implemented via an acknowledgment; the recipient of an EDI message returns >>>this acknowledgment to the sender of the EDI message. This acknowledgment >>>contains the digital signature of the EDI message; also, the acknowledgment >>>is digitally signed by the receiver of the EDI message. >>> >>>Note that a trusted third party, such as an EDI VAN, can provide >>>non-repudiation of receipt without the use of digital signatures. However, >>>most, if not all, Internet Service Providers do not offer this service. >>> >>>MOSS, PEM, PGP and S/MIME meet most of the security requirements of users >>>doing EDI over the Internet; however, they do not provide non-repudiation of >>>receipt. >>> >>>The IETF-EDIINT group should try to pursuade any IETF groups working on >>>e-mail security and e-mail receipts to develop a standard for >>>non-repudiation of receipt. We should also align ourselves with any other >>>groups that need this feature for their Internet e-mail applications. >>> >>>A possible interim solution is to use the 997. The receiver of an EDI >>>message would place the digital signature of this EDI message into a 997, >>>and return the 997 to the sender of the original EDI message. The problem >>>with this solution is that e-mail users, EDIFACT users and proprietary EDI >>>users will not want to use an ANSI X12 transaction set for non-repudiation >>>of receipt. This will result in multiple solutions for non-repudiation of >>>receipt (i.e., one for e-mail, one for X12-based EDI, one for EDIFACT-based >>>EDI, etc.). >>> >>>Another possible interim solution is to use the EDIFACT AUTACK message, >>>which was designed to provide non-repudiation of receipt. This is how >>>Premenos's Templar product provides non-repudiation of receipt. However, >>>this solution has the same problem as the 997-based solution. >>> >>> >>>Bob Lyons >>>EDI & Internet Consultant >>>Unidex, Inc. >>>1-908-975-9877 >>>boblyons@unidex.com >>>EDI Help Desk: http://www.wwa.com/unidex/edi/ > > > > ====================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8479 | mailto://dave_d@systrends.com ====================== From owner-ietf-ediint Thu Feb 15 23:26:17 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id XAA27938 for ietf-ediint-bks; Thu, 15 Feb 1996 23:26:17 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id XAA27933 for ; Thu, 15 Feb 1996 23:26:15 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16756 Fri, 16 Feb 1996 18:33:40 +1100 (from ksteel@cs.mu.oz.au) Date: Fri, 16 Feb 96 17:30:55 PST Subject: RE: Non-repudiation of receipt To: ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Thu, 15 Feb 1996 23:55:50 -0700 >From: Dave Darnell >Standards should support what is pratical to do in today's and tomorrow's >technologies and not be formulated prior to this. > >Regards, >Dave Darnell Here! Here! Well said. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 06:18:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id GAA01119 for ietf-ediint-bks; Fri, 16 Feb 1996 06:18:38 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id GAA01114 for ; Fri, 16 Feb 1996 06:18:36 -0800 (PST) Received: from ppp26-rb.exit109.com (ppp26-rb.exit109.com [205.164.176.153]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id JAA07637 for ; Fri, 16 Feb 1996 09:25:38 -0500 Date: Fri, 16 Feb 1996 09:25:38 -0500 Message-Id: <199602161425.JAA07637@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Re: tunnels Sender: owner-ietf-ediint@imc.org Precedence: bulk At 11:36 AM 2/15/96 MET, gami@edieng.enet.dec.com wrote: > >ISSUE - encrypted tunnels > >We should take into account any current/future work that is going on >to standardize encrypted tunnels. They may provide a useful mechanism for >providing security at the communications layer. > >Raj Gami Raj, Are you talking about encryption at the packet level (e.g., routers that perform encryption) or at the session layer (e.g., Secure Sockets Layer)? I assume the former; however, either can provide secure tunnels. RSADSI has proposed S/WAN (Secure/Wide Area Network) as a standard for encryption at the packet layer. Encrypted tunnels over the Internet might be very useful for interactive EDI applications. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 06:18:46 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id GAA01134 for ietf-ediint-bks; Fri, 16 Feb 1996 06:18:46 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id GAA01129 for ; Fri, 16 Feb 1996 06:18:44 -0800 (PST) Received: from ppp26-rb.exit109.com (ppp26-rb.exit109.com [205.164.176.153]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id JAA07651 for ; Fri, 16 Feb 1996 09:25:46 -0500 Date: Fri, 16 Feb 1996 09:25:46 -0500 Message-Id: <199602161425.JAA07651@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. How will they implement this requirement? By waiting for the recipient to return a 997 for message N before sending message N+1? Also, some users have their translator validate the sequencing of the interchange control numbers (by trading partner) in order to detect missing, duplicate or out-of-sequence interchanges. Will they have to turn off this validation feature when doing EDI over the Internet? If so, then how will they detect missing, duplicate and out-of-sequence interchanges? REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. FYI. I believe that Premenos's Templar product can detect duplicate messages. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 06:19:08 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id GAA01147 for ietf-ediint-bks; Fri, 16 Feb 1996 06:19:08 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id GAA01142 for ; Fri, 16 Feb 1996 06:19:05 -0800 (PST) Received: from ppp26-rb.exit109.com (ppp26-rb.exit109.com [205.164.176.153]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id JAA07657 for ; Fri, 16 Feb 1996 09:25:49 -0500 Date: Fri, 16 Feb 1996 09:25:49 -0500 Message-Id: <199602161425.JAA07657@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: A brief comparison of email encryption protocols Sender: owner-ietf-ediint@imc.org Precedence: bulk I thought that this might be of interest to the group. It was posted to the pem-dev mailing list. Bob Lyons >Reply-To: pem-dev-request@neptune.tis.com >Date: Wed, 14 Feb 1996 12:49:44 -0800 (PST) >From: Raph Levien >Subject: A brief comparison of email encryption protocols >To: cypherpunks@toad.com, coderpunks@toad.com, resolving-security@imc.org, > pgp-mime@purpletape.cs.uchicago.edu, pem-dev@neptune.tis.com >Sender: pem-dev-request@neptune.tis.com >Precedence: bulk > > This message briefly reviews and compares the four major email >encryption protocols under discussion: MOSS, PGP, PGP/MIME, and >S/MIME. Each is capable of adequate security, but also suffers from >the lack of good implementation, in the context of transparent email >encryption. > > I will try to address issues of underlying cryptographic soundness, >ease of integration with email, implementation issues, support for >multimedia and Web datatypes, and backwards compatibility. > > An additional grave concern is key management. Contrary to some >beliefs, key management is not a solved problem. All of the proposals >contain some mechanism for key management, but none of them have been >demonstrated to be scalable to an Internet-wide email system. My >belief is that the problems with key management do not stem from the >classic Web of trust/certification hierarchy split, but the >nonexistence of a distributed database (with nice interfaces) for >holding keys. The encryption protocols also stand in the way of such a >database, with key formats that are either overly complex, inadequate, >or both. > > In case it is not clear by now, this review will be quite >subjective, in many cases representing my own beliefs rather than >objective fact. I'll try to point that out where I can. Also, I do not >claim to have a thorough understanding of PEM and PKCS. Much of my >knowledge comes from implementing premail, a tool that acts as "glue" >between mailers and encryption packages. It supports PGP, MOSS (using >the TIS/MOSS 7.1 implementation), and a draft of PGP/MIME, in addition >to a wide range of anonymous remailer services. While usable, premail >has many limitations, and certainly does not represent the "holy >grail" of transparent email/crypto integration. Thus, my participation >in the Internet Mail Consortium Secuirty Workshop >(http://www.imc.org/security-workshop.html). > > I apologize for the wide distribution, and ask that followups be >trimmed. > > >PGP >--- > > PGP (Pretty Good Privacy) is, of course, the de facto standard for >email encryption on the Internet. > PGP's underlying cryptography is quite sound - RSA (up to 2048 bits >with the most recent implementation), IDEA with a 128 bit key, and >MD5. PGP is entirely in accordance with the recent recommendations on >minimum keylength (http://www.bsa.org/bsa/cryptologists.html), and in >fact does not include a mode of operation in violation of those >recommendations. This makes PGP (and, by extension, PGP/MIME) unique >among the encryption protocols. > PGP is packaged in a single application (i.e. a single binary) >which performs encryption, decryption, signing, verification, and key >management. It does not depend on the existence of great deal of >infrastructure. These factors have, in my opinion, been decisive in >PGP's popularity. > > However, PGP is still not suitable for fully transparent email >encryption. The reasons are complex, and I will only touch on them >here. > > The main missing feature is the lack of MIME integration. Thus, PGP >is not suitable for multimedia types other than US-ASCII text. PGP >does contain some support for 8-bit charsets, but at cross-purposes >with MIME. Signature checking of non-US-ASCII data is simply not >reliable. To give an idea of this problem, the most recent >international version (2.6.3i) tries several different character set >conversions when verifying signatures, to see if any of them will >work. > However, since a large fraction of email _is_ US-ASCII text, this >feature alone probably does not explain the lack of deployment. PGP >contains a number of implementation flaws (including silly things like >not locking files, so that concurrent invocations fail). In addition, >key management has some problems. Mostly, key management is hard to >learn, time consuming, and requires a great deal of manual >intervention. The "Web of trust" is supposed to fix this, by providing >transitive trust of key authenticity. However, in practice the Web of >trust has not delivered. In my experience (with many dozen >correspondents), I have only had one or two keys transitively trusted. > > A standard PGP-signed message consists of a "-----BEGIN PGP SIGNED >MESSAGE-----" line, the signed text (subject to some canonicalization >rules), a "----BEGIN PGP SIGNATURE-----" line, a version line, the PGP >signature itself, and an "-----END PGP SIGNATURE-----" line. All this >is in the message body. The headers indicate that the message is a >standard 7-bit, us-ascii, text/plain message. Thus, mailers have to >parse the message contents to identify the message as PGP signed, or >to extract the signed parts. This is at cross-purposes with MIME. >Mailer implementors are reluctant to include such ad-hoc extensions. >Existing extensibility mechanisms, based on MIME, cannot be used. > PGP encrypted messages are similar - the identification as an >encrypted message can only be made by parsing the message body. > > One technical problem with PGP is its inability to support >single-pass processing, because the data format includes a size >field. > > >PGP/MIME >-------- > > PGP/MIME is an effort to integrate MIME and PGP. There is a >workable draft based on the MIME security multiparts, but the PGP/MIME >mailing list is divided. Some particpants are happy with the existing >draft, while others feel that other points in the design space >(for the most part, labelling existing PGP message formats with >appropriate MIME types) would be better. > The design space is large and complex, with many constraints on >efficiency, simplicity, backwards compatibility, and functionality. It >is not clear that a consensus will develop at all. > There are two implementations of the PGP/MIME draft: premail, and >the PGPMIME reference implementation by Michael Elkins. > For more information about the PGP/MIME draft, see >http://www.c2.org/~raph/pgpmime.html . > > >PGP 3.0 >------- > > Many people are hoping that PGP 3.0 will somehow come along and >solve all their problems. PGP 3.0 is only an evolutionary improvement >over the existing implementations (MIT PGP 2.6.2 and PGP 2.6.3i). For >the most part, it will support only the existing message formats. >There may be support for decoding draft PGP/MIME signed messages, but >this is still being negotiated. > The main advance in PGP 3.0 is a cleaned up implemenation. The PGP >2.6.2 code is disgusting, and should not be integrated directly into >any mailer application. The 3.0 code will be modular and based on >published interfaces. Furthermore, the 3.0 development team plans to >release the code as both a stand-alone application and as a library. > It is difficult to predict when the public release will happen. >Based on what I've seen, fall of 1996 seems the most likely. > > >MOSS >---- > > MOSS (MIME Object Security Services) is an attempt at an email >encryption protocol in accordance with MIME. It is currently an >Internet RFC. There is a reference implementation (TIS/MOSS 7.1). > MOSS is mostly cryptographically sound. However, the choice of >symmetric encryption algorithm (and key size) is left unspecified. >Thus, it cannot be said that MOSS is in accordance with the >recommendations for minimum keysize. In fact, the only public >implementation, TIS/MOSS 7.1, uses 56-bit DES, which is in direct >violation of these standards. > The TIS/MOSS implementation has a number of other problems. It is >big and complex, probably due to its TIS/PEM ancestry. For more >information about TIS/MOSS, see >http://www.tis.com/docs/Products/tismoss.html . > > MOSS supports two modes of key management: X.509, and completely >manual key management. In this way, it is a dramatic advance over PEM, >which only supported X.509, but life for implementors remains hard. >One feature which I believe is sorely lacking is a cryptographic hash >of the public key as the basic unit of manual key management. Thus, >people either have to trust the mechanism by which the key was >delivered, or examine the base-64 representation of the entire key. I >consider this to be a serious usability problem. > For an example of how hashes of keys have been done right, see >Netscape 2.0's handling of untrusted certificates. > > >S/MIME >------ > > S/MIME is an attempt to graft MIME support onto underlying PEM >standards. See http://www.rsa.com/rsa/S-MIME/ for more info. > > I feel compelled to deal harshly with RSA's S/MIME FAQ >(http://www.rsa.com/rsa/S-MIME/smimeqa.htm). It suggests that MOSS has >interoperability problems because of multiple implementations, while >S/MIME presumably doesn't. I take strong exception to this statement. >There is no technical basis for it. I consider the possibility of >admitting multiple implementations as a _requirement_ for an Internet >email standard. However, because S/MIME is documented, it hopefully >will be possible to create independent implementations, in spite of >what RSA says. > > The only symmetric encryption algorithm mandated by S/MIME is >40-bit RC2. Thus, S/MIME is in violation of the key size >recommendations. Further, RC2 has not been confirmed to be publicly >known. If RC2 is not known, then an independent implementation of >S/MIME is impossible. Fortunately, source code for an alleged >implementation of RC2 has recently been posted to the Internet, >resolving this problem, if it is authentic. If not, then my >reservations remain. > > S/MIME also recommends 56-bit DES CBC and (either 112 or 168 bit) >DES EDE3-CBC. This is good; any S/MIME implementation in accordance >with the recommendations will conform to the keysize recommendations >as well. > > S/MIME remains firmly grounded in the X.509 certification >hierarchy, although the FAQ claims that the guidelines for hierarchies >are "more flexible" than in PEM. > > One cryptographic weakness of S/MIME is that eavesdroppers can >distinguish between encrypted and signed-and-encrypted messages. This >violates the principle of disclosing a minimum amount of information. >PGP, PGP/MIME, and MOSS do not have this problem. > > Probably the most controversial aspect of S/MIME is its signature >format. An S/MIME signed message is a MIME multipart in which the >first part is the data to be signed, and the second part is a complete >PKCS #7 (section 10) signed message. This protects quite well against >munging by mail transport, but has two problems. First, the size of >the message is doubled. Second, the fact that the two singed messages >are identical is not enforced (if it were, mailer munging would cause >too many signatures to fail). Thus, Eve can send Alice and Bob a >message (M1, (M2, Signature(M2))). Alice, not having an S/MIME >implementation, would see only M1. Bob, having an S/MIME >implementation, would see only M2, for which the signature would >check. Alice, being suspicious, might call Bob up on the telephone and >ask whether the signature was really valid. Bob would of course say >yes. Unless they compared notes on the contents, they would not notice >the discrepancy. To my mind, this counts as protocol failure, and thus >it is not possible to claim that S/MIME conforms to best cryptographic >practice. > I would expect that doubling the message body will create >performance problems in a Web environment. For example, if the first >message is used for display, then it becomes necessary to compare the >two messages. If, instead, the second message is used, then the first >message will be responsible for significant added latency. > > >Integration with mailers >------------------------ > > Integration with mailers is quite difficult. In general, the mailer >implementor will need to add specific features to support >cryptography. Because of the restrictiveness of ITAR regulations, such >an approach may not be practical for US developers, at least while >supporting strong cryptography. > Perhaps the biggest feature required in the mailer is integration >of key management and the "address book". If this feature is not >implemented in the mailer, then two address books are required - one >to select email addresses, and another to map email addresses to keys. >This approach is used by premail, and is the source of many usability >problems. It would be nice if a database existed which could map email >addresses to public keys without manual intervention, but none of the >proposals on the table are capable of it. Such a database would >certainly improve usability, as well as making it considerably easier >to > > Another feature that is required for fully transparent integration >is caching of decrypted session keys. If not implemented, then the >user interface delays in navigating a mail folder become unacceptable. >To my knowledge, no implementation supports this feature. > One dimension in the design space is whether the cryptographic >engine is tightly integrated with the mailer (i.e. shares an address >space), or is a separate process that communicates with the mailer. >Both approaches have been implemented. Both approaches are subject to >numerous pitfalls, which have unfortunately not been entirely avoided. > These issues have more to do with implementation than with the >encryption protocol, but I thought I'd mention them here, so that they >are not actively thwarted. > > >Conclusion >---------- > > All of the proposals described here can be used for secure email. >None of them will be widely deployed in this capacity unless they are >implemented well. I have concerns that both MOSS and S/MIME are >susceptible to political pressure which will restrict key sizes >insecurely in practice. I would like to see consensus develop around >one of the proposals, so that energies used for implementation can be >more focussed and effective. It is my hope that this conference will >move in that direction. > >Raph Levien > > From owner-ietf-ediint Fri Feb 16 06:52:11 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id GAA01276 for ietf-ediint-bks; Fri, 16 Feb 1996 06:52:11 -0800 (PST) Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id GAA01267 for ; Fri, 16 Feb 1996 06:50:15 -0800 (PST) From: gami@edieng.enet.dec.com Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id PAA12697 for ; Fri, 16 Feb 1996 15:57:00 +0100 Received: from edieng.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id PAA27087 for ; Fri, 16 Feb 1996 15:52:27 +0100 Message-Id: <199602161452.PAA27087@vbormc.vbo.dec.com> Received: from edieng.enet; by vbormc.enet; Fri, 16 Feb 96 15:54:54 MET Date: Fri, 16 Feb 96 15:54:54 MET To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Cc: gami@edieng.enet.dec.com Apparently-To: ietf-ediint@imc.org Subject: Re: tunnels Sender: owner-ietf-ediint@imc.org Precedence: bulk Bob, Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. Raj From owner-ietf-ediint Fri Feb 16 07:03:44 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id HAA01327 for ietf-ediint-bks; Fri, 16 Feb 1996 07:03:44 -0800 (PST) Received: from franklin-fddi.cris.com (franklin-fddi.cris.com [199.3.126.7]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id HAA01322 for ; Fri, 16 Feb 1996 07:03:40 -0800 (PST) Received: from fs1.cris.com by franklin-fddi.cris.com [1-800-745-CRIS (voice)] Received: from cnc087034.concentric.net by fs1.cris.com (8.7.1) id KAA18325; Fri, 16 Feb 1996 10:10:37 -0500 (EST) Message-Id: <2.2.16.19960216150658.0a67d22c@pop3.concentric.net> X-Sender: trevr@pop3.concentric.net X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 09:06:58 -0600 To: ietf-ediint@imc.org From: Trevor Richards Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. When I last heard the topic of sequencing interchange control numbers discussed at an X12C working group, it became apparent that many different techniques are used to allocate interchange control numbers, not just an incremental number for each transmission to each trading partner. I believe that the only stipulation in X12.5 is that he interchange control number sent to each trading partner should be unique. If the communications layer is to validate interchange control numbers, the only validation should be to check for duplicates. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. That is why most translation software allows the level of validation applied to interchange control numbers to be set by trading partner. Incidentally, X.25 and interconnected VANs can lead to interchange N+1 arriving before interchange N in todays' communications infrastructure. At 09:25 AM 2/16/96 -0500, you wrote: >ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee >message sequence integrity. In other words, message N+1 may be delivered >before message N. Some EDI VANs provide message sequence integrity. There >are probably some EDI applications that require message sequence integrity. >How will they implement this requirement? By waiting for the recipient to >return a 997 for message N before sending message N+1? > >Also, some users have their translator validate the sequencing of the >interchange control numbers (by trading partner) in order to detect missing, >duplicate or out-of-sequence interchanges. Will they have to turn off this >validation feature when doing EDI over the Internet? If so, then how will >they detect missing, duplicate and out-of-sequence interchanges? > >REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - >EDI users need an automated means to detect missing, duplicate or >out-of-sequence messages, where the sequencing problem is caused by the >communications layer (e.g., the Internet e-mail software) or the security >layer. Sequence problems caused by the business application or the EDI >translator are not within the scope of this requirement. > >This feature is normally provided by the EDI translator that verifies that >the interchange control numbers (ICNs) are received in the correct sequence. > >If this feature was provided by a layer below the EDI translator (e.g., the >security layer or the communications layer), then it could be used by e-mail >users, proprietary EDI applications that don't use an EDI translator, and >EDI applications where one of the trading partner's has a translator that >does not validate ICN sequencing. > >FYI. I believe that Premenos's Templar product can detect duplicate messages. > > >Bob Lyons Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Fri Feb 16 07:16:58 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id HAA01402 for ietf-ediint-bks; Fri, 16 Feb 1996 07:16:58 -0800 (PST) Received: from lotus.com (lotus.com [192.233.136.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id HAA01397 for ; Fri, 16 Feb 1996 07:16:55 -0800 (PST) Received: from internet1.lotus.com (crd2.lotus.com) by lotus.com (4.1/SMI-4.10801.1994) id AA07092; Fri, 16 Feb 96 10:28:29 EST Received: by internet1.lotus.com (5.x/SMI-SVR4) id AA08966; Fri, 16 Feb 1996 10:16:59 -0500 Message-Id: <9602161516.AA08966@internet1.lotus.com> Received: by Lotus (Lotus Notes Mail Gateway for SMTP V.03 Beta) id 98340634FDCFF03C852562D20054A7D0; Fri, 16 Feb 96 10:16:59 EST To: ietf-ediint From: Keith Boucher/CAM/Lotus Date: 16 Feb 96 10:32:17 EST Subject: what about funds transfer Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-ediint@imc.org Precedence: bulk Is the topic of funds transfer over the net included in our discussion or just traditional EDI? Regards, Keith Keith Boucher Lotus Development keith_boucher@crd.lotus.com From owner-ietf-ediint Fri Feb 16 07:44:49 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id HAA01540 for ietf-ediint-bks; Fri, 16 Feb 1996 07:44:49 -0800 (PST) Received: from ng.netgate.net (ng.netgate.net [204.145.147.10]) by imc.imc.org (8.7.3/8.7.1) with SMTP id HAA01535 for ; Fri, 16 Feb 1996 07:44:47 -0800 (PST) Received: from [205.214.160.40] (d23.netgate.net [205.214.160.55]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id HAA14958; Fri, 16 Feb 1996 07:58:44 -0800 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <2.2.32.19960216065550.00719894@mail.indirect.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Feb 1996 07:45:31 -0800 To: Dave Darnell From: Dave Crocker Subject: RE: Non-repudiation of receipt Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 10:55 PM 2/15/96, Dave Darnell wrote: >I believe non-repudiation is extremely important and should be approached >from the lower communication protocol layers of SMTP. 997 leaves too much People often use the acronym of SMTP to refer to all of Internet-native mail. Othertimes, they really mean specifically the Internet mail transfer protocol. If you were pointing and just and only SMTP, I'd like to suggest a different view. If you meant 'internet native mail' then I agree. To clarify. Like any good network architecture, Internet mail is mulit-layered. Namely: Mime - content RFC822 - addressing/headers SMTP - transfer It is possible to have a transport other than smtp and still have end-to-end 'native' Internet mail, since the email DATA is pure over the whole distance. This is done and works well. SMTP is, in fact, equivalent to a link-layer, hop-by-hope protocol. One coule similarly view RFC822 (i.e., the addressing framework) as equivalent to IP, itself, which IS end-to-end, as is Mime. As such, I suggest that the critical mechanism for non-rep needs to be in the content/addressing area, rather than transfer. This is, in effect, what the new delivery service notification provices. The relevant SMTP extensions are in support of that mechanism, rather than actually being the mechanism itself. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Fri Feb 16 08:25:28 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA01789 for ietf-ediint-bks; Fri, 16 Feb 1996 08:25:28 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id IAA01784 for ; Fri, 16 Feb 1996 08:25:25 -0800 (PST) Received: from ppp26-rb.exit109.com (ppp26-rb.exit109.com [205.164.176.153]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id LAA13382 for ; Fri, 16 Feb 1996 11:32:24 -0500 Date: Fri, 16 Feb 1996 11:32:24 -0500 Message-Id: <199602161632.LAA13382@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >Let's make sure that we don't impose controls at the communications layer >which are not in place in the underlying EDI standards. Why? If the EDI standards met all of our security needs for doing EDI over the Internet, then there would be very little need for this work group. If we don't have message sequence integrity, then how will EDI users protect themselves from replay attacks and the deletion of messages while in transit? To secure your EDI messages as they traverse the Internet, it's not enough to encrypt and apply digital signatures. >...If the communications layer is to validate >interchange control numbers, the only validation should be to check for >duplicates. I was not suggesting that the communications layer validate the ICNs. In fact, such an implementation would not meet the requirements that I specified in my last message. I pointed out that a mechanism is needed that will work for X12 users, EDIFACT users, proprietary EDI users and e-mail users. E-mail messages and many proprietary EDI messages do not contain message sequence numbers (and they certainly don't contain X12's ICN data element). > >Message sequence integrity is a trading partner dependent >issue. I agree with this. I didn't say that message sequence integrity would be a mandatory feature that all users had to use. I would think that most users would want protection against replay attacks, accidental duplicates and message loss. However, some users may not need protection against out of sequence messages. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 08:44:51 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA01878 for ietf-ediint-bks; Fri, 16 Feb 1996 08:44:51 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id IAA01873 for ; Fri, 16 Feb 1996 08:44:48 -0800 (PST) Received: from [199.184.212.135] (turnpike36.onramp.net [199.184.212.135]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id KAA13189; Fri, 16 Feb 1996 10:52:04 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 10:58:17 -0600 To: boblyons@unidex.com (Robert C. Lyons) From: drummond@onramp.net (Rik Drummond) Subject: Re: Message Sequence Integrity Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Thanks Bob for putting them in ISSUE/ REQUIREMENT form. Good comments! We will enter these into the List and discuss them is much more detail later....Thanks...Rik >ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee >message sequence integrity. In other words, message N+1 may be delivered >before message N. Some EDI VANs provide message sequence integrity. There >are probably some EDI applications that require message sequence integrity. >How will they implement this requirement? By waiting for the recipient to >return a 997 for message N before sending message N+1? > >Also, some users have their translator validate the sequencing of the >interchange control numbers (by trading partner) in order to detect missing, >duplicate or out-of-sequence interchanges. Will they have to turn off this >validation feature when doing EDI over the Internet? If so, then how will >they detect missing, duplicate and out-of-sequence interchanges? > >REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - >EDI users need an automated means to detect missing, duplicate or >out-of-sequence messages, where the sequencing problem is caused by the >communications layer (e.g., the Internet e-mail software) or the security >layer. Sequence problems caused by the business application or the EDI >translator are not within the scope of this requirement. > >This feature is normally provided by the EDI translator that verifies that >the interchange control numbers (ICNs) are received in the correct sequence. > >If this feature was provided by a layer below the EDI translator (e.g., the >security layer or the communications layer), then it could be used by e-mail >users, proprietary EDI applications that don't use an EDI translator, and >EDI applications where one of the trading partner's has a translator that >does not validate ICN sequencing. > >FYI. I believe that Premenos's Templar product can detect duplicate messages. > > >Bob Lyons >EDI & Internet Consultant >Unidex, Inc. >1-908-975-9877 >boblyons@unidex.com >EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 08:51:19 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA01911 for ietf-ediint-bks; Fri, 16 Feb 1996 08:51:19 -0800 (PST) Received: from ns2.indirect.com (ns2.indirect.com [165.247.1.17]) by imc.imc.org (8.7.3/8.7.1) with SMTP id IAA01906 for ; Fri, 16 Feb 1996 08:51:17 -0800 (PST) Received: from dave_d.indirect.com (s81.phxslip4.indirect.com [165.247.24.81]) by ns2.indirect.com (8.6.12/8.6.6) with SMTP id JAA13244; Fri, 16 Feb 1996 09:57:41 -0700 Message-Id: <2.2.32.19960216165827.0072da80@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 09:58:27 -0700 To: Dave Crocker From: Dave Darnell Subject: RE: Non-repudiation of receipt Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 07:45 AM 2/16/96 -0800, Dave Crocker wrote: > People often use the acronym of SMTP to refer to all of >Internet-native mail. Othertimes, they really mean specifically the >Internet mail transfer protocol. If you were pointing and just and only >SMTP, I'd like to suggest a different view. If you meant 'internet native >mail' then I agree. > > To clarify. Like any good network architecture, Internet mail is >mulit-layered. Namely: > > Mime - content > RFC822 - addressing/headers > SMTP - transfer > >It is possible to have a transport other than smtp and still have >end-to-end 'native' Internet mail, since the email DATA is pure over the >whole distance. This is done and works well. SMTP is, in fact, equivalent >to a link-layer, hop-by-hope protocol. One coule similarly view RFC822 >(i.e., the addressing framework) as equivalent to IP, itself, which IS >end-to-end, as is Mime. As such, I suggest that the critical mechanism for >non-rep needs to be in the content/addressing area, rather than transfer. >This is, in effect, what the new delivery service notification provices. >The relevant SMTP extensions are in support of that mechanism, rather than >actually being the mechanism itself. > > Good comments, DaveC! How would you implement NRR in the content/addressing area such that we would not have to rely on a Trading Partner implementation as we do with 997's? Can you expand on your ideas here? Regards, DaveD ====================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8479 | mailto://dave_d@systrends.com ====================== From owner-ietf-ediint Fri Feb 16 08:59:56 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA01956 for ietf-ediint-bks; Fri, 16 Feb 1996 08:59:56 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id IAA01949 for ; Fri, 16 Feb 1996 08:59:45 -0800 (PST) Received: from [199.184.212.135] (stockyard64.onramp.net [199.184.212.227]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA16191 for ; Fri, 16 Feb 1996 11:07:13 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 11:13:26 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #4 Sender: owner-ietf-ediint@imc.org Precedence: bulk **NEW**REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the net included in our discussion or just traditional EDI? **NEW**ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. **changed**ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. **new**ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. **new**REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. ACTION ITEM - we can use from the current Templar pilot to add to our document, i.e. can we leverage any of their efforts? ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. ISSUE - Dont duplicate what is already provided within the EDI standards. **new**ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. From owner-ietf-ediint Fri Feb 16 09:22:16 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id JAA02105 for ietf-ediint-bks; Fri, 16 Feb 1996 09:22:16 -0800 (PST) Received: from ng.netgate.net (ng.netgate.net [204.145.147.10]) by imc.imc.org (8.7.3/8.7.1) with SMTP id JAA02100 for ; Fri, 16 Feb 1996 09:22:14 -0800 (PST) Received: from [205.214.160.40] (d15.netgate.net [205.214.160.47]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id JAA16525; Fri, 16 Feb 1996 09:35:55 -0800 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: <2.2.32.19960216165827.0072da80@mail.indirect.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 09:18:50 -0800 To: Dave Darnell From: Dave Crocker Subject: RE: Non-repudiation of receipt Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 8:58 AM 2/16/96, Dave Darnell wrote: >Good comments, DaveC! How would you implement NRR in the content/addressing >area such that we would not have to rely on a Trading Partner implementation >as we do with 997's? Can you expand on your ideas here? darn. you would have to follow up with a reasonable query like this, wouldn't you? The reality is that I don't know enough about the detailed requirements for accomplishing automated NRR. At base, I'd guess that it would be a variant of the delivery service notice, but with lots of interesting add-ons for the security functions. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Fri Feb 16 09:29:55 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id JAA02151 for ietf-ediint-bks; Fri, 16 Feb 1996 09:29:55 -0800 (PST) Received: from lotus.com (lotus.com [192.233.136.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id JAA02144 for ; Fri, 16 Feb 1996 09:29:44 -0800 (PST) Received: from internet1.lotus.com (crd2.lotus.com) by lotus.com (4.1/SMI-4.10801.1994) id AA13096; Fri, 16 Feb 96 12:41:57 EST Received: by internet1.lotus.com (5.x/SMI-SVR4) id AA12181; Fri, 16 Feb 1996 12:30:28 -0500 Message-Id: <9602161730.AA12181@internet1.lotus.com> Received: by Lotus (Lotus Notes Mail Gateway for SMTP V.03 Beta) id 49558CCAB88C4387852562D20059F66D; Fri, 16 Feb 96 12:30:27 EST To: ietf-ediint From: Keith Boucher/CAM/Lotus Date: 16 Feb 96 12:46:49 EST Subject: File size and compression X-Importance: High Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-ediint@imc.org Precedence: bulk Miscellaneous items that come to mind from a non-technical standpoint (and mind!). Regards, Keith ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI Internet messages we may send? Will file size impact transportablitity, ability to send/receive, depandability etc. ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? From owner-ietf-ediint Fri Feb 16 10:17:01 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id KAA00341 for ietf-ediint-bks; Fri, 16 Feb 1996 10:17:01 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id KAA00336 for ; Fri, 16 Feb 1996 10:16:58 -0800 (PST) Received: from ppp5-rb.exit109.com (ppp5-rb.exit109.com [205.164.176.132]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id NAA18068 for ; Fri, 16 Feb 1996 13:24:02 -0500 Date: Fri, 16 Feb 1996 13:24:02 -0500 Message-Id: <199602161824.NAA18068@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Segmentation Sender: owner-ietf-ediint@imc.org Precedence: bulk Another file size issue: ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 11:05:44 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA00562 for ietf-ediint-bks; Fri, 16 Feb 1996 11:05:44 -0800 (PST) Received: from gatekeeper.premenos.com (crimson.premenos.com [150.105.250.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA00555 for ; Fri, 16 Feb 1996 11:05:43 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id LAA11845 for ; Fri, 16 Feb 1996 11:11:31 -0800 Received: from orville.premenos.com(150.105.100.82) by mail.premenos.com via smap (V1.3mjr) id sma011841; Fri Feb 16 11:10:56 1996 Received: by orville.premenos.com. (5.x/SMI-SVR4) id AA03958; Fri, 16 Feb 1996 11:12:51 -0800 Date: Fri, 16 Feb 1996 11:12:51 -0800 From: chuck@orville.premenos.com (Chuck Shih) Message-Id: <9602161912.AA03958@orville.orville.premenos.com.> To: ietf-ediint@imc.org Subject: Additional Issues X-Sun-Charset: US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk Some additional issues that I have not seen posted are as follows: ISSUE: Key Management - Use of public-key cryptography for key management. Very much like the Standard Encryption Scheme issue, we must recommend the algorithms and existing standards that EDI over the Internet will use for key management. ISSUE: Authentication - Use of digital signatures for authenticating EDI inter- changes. Again we must recommend the digital signature algorithms, hash functions and key lengths to be used for EDI over the Internet. ISSUE: Non-repudiation of origin - Use of digital signatures for non-repudiation of origin. Recommend the digital signature algorithms, hash functions, and key lengths to be used for EDI over the Internet. ISSUE: Non-repudiation of receipt - I agree with much of the discussion that has already taken place but would add these additional topics. Will the specifications that we come up with address only the non-repudiation of receipt of the e-mail message, or of each of the contents that are contained in a mime-message of which EDI could be one of many. Do we allow in our specification, security services to be applied to groups of documents in an interchange, or to individual documents within the interchange. Some businesses may want to send out an EDI Interchange consisting of many types of documents, only some of which need security applied to them. In this type of scenario the non-repudiation of receipt needs to be at a much more granular level then at an e-mail or even interchange level. ISSUE: I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? From owner-ietf-ediint Fri Feb 16 11:10:35 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA00599 for ietf-ediint-bks; Fri, 16 Feb 1996 11:10:35 -0800 (PST) Received: from gatekeeper.premenos.com (crimson.premenos.com [150.105.250.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA00594 for ; Fri, 16 Feb 1996 11:10:34 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id LAA11897 for ; Fri, 16 Feb 1996 11:16:32 -0800 Received: from orville.premenos.com(150.105.100.82) by mail.premenos.com via smap (V1.3mjr) id sma011889; Fri Feb 16 11:16:29 1996 Received: by orville.premenos.com. (5.x/SMI-SVR4) id AA04233; Fri, 16 Feb 1996 11:18:20 -0800 Date: Fri, 16 Feb 1996 11:18:20 -0800 From: chuck@orville.premenos.com (Chuck Shih) Message-Id: <9602161918.AA04233@orville.orville.premenos.com.> To: ietf-ediint@imc.org Subject: Re: Segmentation X-Sun-Charset: US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk ----- Begin Included Message ----- >From owner-ietf-ediint@imc.imc.org Fri Feb 16 11:03 PST 1996 Date: Fri, 16 Feb 1996 13:24:02 -0500 X-Sender: boblyons@hiway1.exit109.com Mime-Version: 1.0 To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Segmentation Another file size issue: ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ ----- End Included Message ----- Yes I think this is an important issue, which brings up the transport issue. All of the discussion on transport of EDI over the Internet has centered on the e-mail system. For very large EDI files, think of a 30 Meg 811, sending this file through the e-mail system can become quite cumbersome. Other ways of sending large files on the Internet - such as FTP and via SSL should also be considered. From owner-ietf-ediint Fri Feb 16 11:13:15 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA00619 for ietf-ediint-bks; Fri, 16 Feb 1996 11:13:15 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA00614 for ; Fri, 16 Feb 1996 11:13:13 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02786 Sat, 17 Feb 1996 06:20:43 +1100 (from ksteel@cs.mu.oz.au) Date: Sat, 17 Feb 96 05:16:57 PST Subject: RE: Segmentation To: ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Fri, 16 Feb 1996 13:24:02 -0500 >From: boblyons@unidex.com (Robert C. Lyons) >ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the >sender's system breaks up a large EDI interchange into a series of small >messages and the recipient's system recombines the small messages? >Apparently, some Internet e-mail systems have a maximum message size limit >of 50KB. PGP provides segmentation. So does Premenos's Templar product. I would like to suggest this is also a side-issue. These email restrictions are usually a result of the editing/user interface, software. They are not normally a restriction with the sendmail program which would be used by edi. ------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 11:19:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA00662 for ietf-ediint-bks; Fri, 16 Feb 1996 11:19:38 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA00657 for ; Fri, 16 Feb 1996 11:19:36 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02920 Sat, 17 Feb 1996 06:27:09 +1100 (from ksteel@cs.mu.oz.au) Date: Sat, 17 Feb 96 05:20:53 PST Subject: RE: Additional Issues To: ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Fri, 16 Feb 1996 11:12:51 -0800 >From: chuck@orville.premenos.com (Chuck Shih) >ISSUE: I think the thread of this has been touched upon on Interchange sequence > numbers, but what additional management constructs do we need to come > up with when doing EDI over the Internet. For instance, today if two > EDI Interchanges are sent through a VAN with control numbers, and one > of them does not arrive at the receiver, the receiver can call the > VAN and attempt to trace it. What mechanisms would the receiver use > in this scenario when sending EDI over the Internet? The essence of EDI is automated transactions - no human intervention. Why not just incorporate a rule into your application implementation: If acknowledgement is not received in x hours, resend. If a duplicate is received, it will be detected by the sequence number. This is much simpler and cheaper than trying to trace what happened by phoning up networks. If it's encrypted no outsiders can use it if it goes astray. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 11:29:08 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA00722 for ietf-ediint-bks; Fri, 16 Feb 1996 11:29:08 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA00717 for ; Fri, 16 Feb 1996 11:29:05 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03002 Sat, 17 Feb 1996 06:36:38 +1100 (from ksteel@cs.mu.oz.au) Date: Sat, 17 Feb 96 05:31:38 PST Subject: Re: Segmentation To: ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Fri, 16 Feb 1996 11:18:20 -0800 >From: chuck@orville.premenos.com (Chuck Shih) > For very large EDI files, think of a 30 Meg 811, sending >this file through the e-mail system can become quite cumbersome. Other ways >of sending large files on the Internet - such as FTP and via SSL should also >be considered. If the encryption is applied to the file being transported, it is independent of whether it is moved by email or ftp. That's why it is important to control the security at the communications level and not further up or further down in the stack. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 13:14:42 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id NAA01175 for ietf-ediint-bks; Fri, 16 Feb 1996 13:14:42 -0800 (PST) Received: from uuneo.neosoft.com (root@uuneo.neosoft.com [206.109.1.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id NAA01170 for ; Fri, 16 Feb 1996 13:14:39 -0800 (PST) From: mgreely@prisminfo.com Received: from mail.prisminfo.com ([206.109.132.20]) by uuneo.neosoft.com (8.7.3/8.7.3) with SMTP id PAA07729; Fri, 16 Feb 1996 15:22:06 -0600 (CST) Received: from ccMail by mail.prisminfo.com (SMTPLINK V2.11 PreRelease 4) id AA824512852; Fri, 16 Feb 96 15:20:23 cdt Date: Fri, 16 Feb 96 15:20:23 cdt Encoding: 32 Text Message-Id: <9601168245.AA824512852@mail.prisminfo.com> To: ietf-ediint@imc.org, ksteel@cs.mu.oz.au Subject: Re[2]: Segmentation Sender: owner-ietf-ediint@imc.org Precedence: bulk If we start with a 30 Meg file before encryption how big is it going to be once it is encrypted? EDI makes the file as small as possible by eliminating all extra spacing. What file size are we talking about now? ______________________________ Reply Separator _________________________________ Subject: Re: Segmentation Author: ksteel@cs.mu.oz.au at INTERNET Date: 2/17/96 5:31 AM >Date: Fri, 16 Feb 1996 11:18:20 -0800 >From: chuck@orville.premenos.com (Chuck Shih) > For very large EDI files, think of a 30 Meg 811, sending >this file through the e-mail system can become quite cumbersome. Other ways >of sending large files on the Internet - such as FTP and via SSL should also >be considered. If the encryption is applied to the file being transported, it is independent of whether it is moved by email or ftp. That's why it is important to control the security at the communications level and not further up or further down in the stack. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 14:01:26 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01379 for ietf-ediint-bks; Fri, 16 Feb 1996 14:01:26 -0800 (PST) Received: from keeper.albany.net (root@keeper.albany.net [206.72.192.14]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id OAA01374 for ; Fri, 16 Feb 1996 14:01:24 -0800 (PST) Received: from tdarling (pm2ip18-albny.albany.net [206.72.192.149]) by keeper.albany.net (8.7.1/8.7.1) with SMTP id RAA08037 for ; Fri, 16 Feb 1996 17:10:05 -0500 (EST) Message-Id: <2.2.32.19960216220527.006c68bc@mail.albany.net> X-Sender: tdarling@mail.albany.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 17:05:27 -0500 To: ietf-ediint@imc.org From: Tom Darling Subject: Authentication+integrity=non-repudiation of origin Sender: owner-ietf-ediint@imc.org Precedence: bulk REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be assured that the purported original signatory of the message is the entity that actually sent (?) the message. REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured that the message arrived in its "pure" and original state, i.e., was not modified by having data added, deleted, or changed along the way. ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + Integrity = NRO ==================================== I'm sure we all know and care about these, but I noticed they hadn't made it on to the table. ==================================== Re: Non-Repudiation of Receipt I suspect some of the discussion around the NRR can be clarified if we distinguish two alternative types of business needs for NRR. The first, and I suspect far more common, need is to know that the trading partner has received the message (alive and intact). At that point I can expect the TP to be under some obligation to fulfill its responsibilities in our relationship (e.g., send me an order, etc.). Because the functional acknowledgment is generated later in the receiver's processing (after they've had a chance to check that the message makes sense to them), it satisfies this need much better than a notification that the message arrived in a mailbox. [For example, I would be loathe to enter into a TPA in which I incured obligations because mail was put in my box, whether I had been able to read it or not, etc., etc. (Especially after my ISP went down for 3 hours this afternoon)] With traditional FAs, if my translator doesn't get back the acknowledegment within some agreed upon period I will either re-submit or contact the TP through another medium. In other words, this type of solution needs no further attention from the group(?) -- it is not related to the transport of the message, but the solution is at the EDI Application layer. Aside -- Assuming the TPs are using both authentication and message integrity checks, there is no reason I can think of to include the MIC in the reply, since the check of the hash by the receiver has been successful. (Am I confused on this?) The second type of NRR is the "delivered to the mailbox" kind of NRR that seems to have been the focus of discussion. To be honest, I couldn't think of a good business reason for delivery NRR until I had a discussion with another member of the Government Subcommittee at X12 last week. His business need is essentially legal, and he needs to use the NRR like a "process server" -- i.e., for sending people mail that they would not willingly respond to. A process server will testify to delivery of the message, and the recipient is bound by the contents of the message, even if he or she tears up the envelope and throws it on the ground in front of the (human) server. I'd be interested in other business needs for mailbox delivery NRR in trad-EDI that cannot be met by the functional acknowledgment. Re: Dave D.'s comment "what is pratical to do today" -- I think this may apply to mailbox NRR. If it is practical today without extensive revamping then fine, I'm all for including it. Based on discussion I've seen so far, it looks like it isn't -- so we shouldn't, but I'm wrong a fair amount of the time :) Re: Ken Steel's request that an NRR solution be applicable to a broader range of messages, I agree in theory, but not necessarily in practice. Ceteris paribus, given two solutions I prefer the one with broader applicability -- but not if it takes us into additional (technological or procedural) complexity or too far beyond the formal mandate of this group. ************************************************************************* * Thomas A. Darling, PhD | * * NYS Forum for Information | http://www.albany.net/~tdarling * * Resource Management, and | * * Center for Policy Research | mailto://tdarling@albany.net * * University at Albany | * * (518) 443-5004 (office) | (518) 443-5006 (fax) * *-----------------------------------------------------------------------* * The structured complex of human relations... is not a passive product * * of situational constraints. It conforms to a logic and rationality of * * its own. For it corresponds to a collection of relations of power * * distributed in various games, within whose framework relatively * * autonomous actors pursue their divergent interests and negotiate the * * conditions of their participation in the group. * * -- _Actors and Systems_, Crozier & Friedberg (1980: 79) * ************************************************************************* From owner-ietf-ediint Fri Feb 16 14:05:57 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01420 for ietf-ediint-bks; Fri, 16 Feb 1996 14:05:57 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id OAA01415 for ; Fri, 16 Feb 1996 14:05:55 -0800 (PST) Received: from [199.184.212.200] (stockyard37.onramp.net [199.184.212.200]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id QAA16437; Fri, 16 Feb 1996 16:13:19 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 16:19:32 -0600 To: Tom Darling From: drummond@onramp.net (Rik Drummond) Subject: Re: Authentication+integrity=non-repudiation or origin Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Yes is appropriate to bring them up. It is better to have them twice in the list than to overlook them..Thanks...Later..Rik >REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be assured >that the purported original signatory of the message is the entity that >actually sent (?) the message. > >REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured that >the message arrived in its "pure" and original state, i.e., was not modified >by having data added, deleted, or changed along the way. > >ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + >Integrity = NRO > >==================================== > > I'm sure we all know and care about these, but I noticed they hadn't made >it on to the table. > >==================================== > >Re: Non-Repudiation of Receipt > > I suspect some of the discussion around the NRR can be clarified if we >distinguish two alternative types of business needs for NRR. > > The first, and I suspect far more common, need is to know that the trading >partner has received the message (alive and intact). At that point I can >expect the TP to be under some obligation to fulfill its responsibilities in >our relationship (e.g., send me an order, etc.). Because the functional >acknowledgment is generated later in the receiver's processing (after >they've had a chance to check that the message makes sense to them), it >satisfies this need much better than a notification that the message arrived >in a mailbox. [For example, I would be loathe to enter into a TPA in which >I incured obligations because mail was put in my box, whether I had been >able to read it or not, etc., etc. (Especially after my ISP went down for 3 >hours this afternoon)] > > With traditional FAs, if my translator doesn't get back the >acknowledegment within some agreed upon period I will either re-submit or >contact the TP through another medium. In other words, this type of >solution needs no further attention from the group(?) -- it is not related >to the transport of the message, but the solution is at the EDI Application >layer. > > Aside -- Assuming the TPs are using both authentication and message >integrity checks, there is no reason I can think of to include the MIC in >the reply, since the check of the hash by the receiver has been successful. >(Am I confused on this?) > > The second type of NRR is the "delivered to the mailbox" kind of NRR that >seems to have been the focus of discussion. To be honest, I couldn't think >of a good business reason for delivery NRR until I had a discussion with >another member of the Government Subcommittee at X12 last week. His >business need is essentially legal, and he needs to use the NRR like a >"process server" -- i.e., for sending people mail that they would not >willingly respond to. A process server will testify to delivery of the >message, and the recipient is bound by the contents of the message, even if >he or she tears up the envelope and throws it on the ground in front of the >(human) server. > > I'd be interested in other business needs for mailbox delivery NRR in >trad-EDI that cannot be met by the functional acknowledgment. > > Re: Dave D.'s comment "what is pratical to do today" -- I think this may >apply to mailbox NRR. If it is practical today without extensive revamping >then fine, I'm all for including it. Based on discussion I've seen so far, >it looks like it isn't -- so we shouldn't, but I'm wrong a fair amount of >the time :) > > Re: Ken Steel's request that an NRR solution be applicable to a broader >range of messages, I agree in theory, but not necessarily in practice. >Ceteris paribus, given two solutions I prefer the one with broader >applicability -- but not if it takes us into additional (technological or >procedural) complexity or too far beyond the formal mandate of this group. > >************************************************************************* >* Thomas A. Darling, PhD | * >* NYS Forum for Information | http://www.albany.net/~tdarling * >* Resource Management, and | * >* Center for Policy Research | mailto://tdarling@albany.net * >* University at Albany | * >* (518) 443-5004 (office) | (518) 443-5006 (fax) * >*-----------------------------------------------------------------------* >* The structured complex of human relations... is not a passive product * >* of situational constraints. It conforms to a logic and rationality of * >* its own. For it corresponds to a collection of relations of power * >* distributed in various games, within whose framework relatively * >* autonomous actors pursue their divergent interests and negotiate the * >* conditions of their participation in the group. * >* -- _Actors and Systems_, Crozier & Friedberg (1980: 79) * >************************************************************************* From owner-ietf-ediint Fri Feb 16 14:08:22 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01439 for ietf-ediint-bks; Fri, 16 Feb 1996 14:08:22 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id OAA01434 for ; Fri, 16 Feb 1996 14:08:18 -0800 (PST) Received: from ppp18-rb.exit109.com (ppp18-rb.exit109.com [205.164.176.145]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id RAA28922 for ; Fri, 16 Feb 1996 17:15:20 -0500 Date: Fri, 16 Feb 1996 17:15:20 -0500 Message-Id: <199602162215.RAA28922@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Re: Segmentation Sender: owner-ietf-ediint@imc.org Precedence: bulk At 03:20 PM 2/16/96 cdt, mgreely@prisminfo.com wrote: > If we start with a 30 Meg file before encryption how big is it going > to be once it is encrypted? > EDI makes the file as small as possible by eliminating all extra > spacing. What file size are we talking about now? It will be roughly the same size. However, the encrypted file will be binary. To send binary via Internet e-mail, it must be encoded into printable characters. The base64 encoding method used in MIME, increases the size of the file by 33%. If you send the encrypted file via FTP (using binary transfer mode), then there is no need to encode the binary into printable characters. If you want to also compress the file, you should compress it before it is encrypted. Bob Lyons EDI & Internet Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Fri Feb 16 14:11:47 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01467 for ietf-ediint-bks; Fri, 16 Feb 1996 14:11:47 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id OAA01462 for ; Fri, 16 Feb 1996 14:11:45 -0800 (PST) Received: from [199.184.212.200] (stockyard37.onramp.net [199.184.212.200]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id QAA17257; Fri, 16 Feb 1996 16:17:56 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 16:24:10 -0600 To: Keith Boucher/CAM/Lotus From: drummond@onramp.net (Rik Drummond) Subject: Re: File size and compression Cc: ietf-ediint Sender: owner-ietf-ediint@imc.org Precedence: bulk Excellent points! I have added them to the list. The first one could be a real gotcha for large 841 type transactions...Later...Rik >Miscellaneous items that come to mind from a non-technical standpoint (and >mind!). Regards, Keith > > >ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI Internet >messages we may send? Will file size impact transportablitity, ability to >send/receive, depandability etc. > >ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? From owner-ietf-ediint Fri Feb 16 14:12:18 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01485 for ietf-ediint-bks; Fri, 16 Feb 1996 14:12:18 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id OAA01480 for ; Fri, 16 Feb 1996 14:12:16 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05352 Sat, 17 Feb 1996 09:19:35 +1100 (from ksteel@cs.mu.oz.au) Date: Sat, 17 Feb 96 09:21:03 PST Subject: RE: Re[2]: Segmentation To: mgreely@prisminfo.com, ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk >From: mgreely@prisminfo.com >Date: Fri, 16 Feb 96 15:20:23 cdt > If we start with a 30 Meg file before encryption how big is it going > to be once it is encrypted? > EDI makes the file as small as possible by eliminating all extra > spacing. What file size are we talking about now? 1. A 30Mb file for EDI is extremely rare. 2. The EDI syntaxes (trad-edi) may well reduce size by eliminating spaces but adds an overhead of 100 to 900% through the "fixed" segments and the use of dispersed semantics. 3. What's your point anyhow? ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Fri Feb 16 14:24:35 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01553 for ietf-ediint-bks; Fri, 16 Feb 1996 14:24:35 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id OAA01548 for ; Fri, 16 Feb 1996 14:24:33 -0800 (PST) Received: from [199.184.212.200] (stockyard28.onramp.net [199.184.212.191]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id QAA19999 for ; Fri, 16 Feb 1996 16:31:59 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 16:38:12 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #5 Sender: owner-ietf-ediint@imc.org Precedence: bulk These are great statements and issues you'all (I am from Texas) have expressed. Have we bounded the proplem yet? Do we need to keep brainstorming a few of more days? YOUR ACTION REQUIRED: If you think it is time to _quit_ brainstorming, broadcast the comment to the group. If you think we need to continue a few more days ( not more than a week) your silence will indicate that. After the brainstorming is done, we will need to go back and clean the statement up, combine and seperate some and then vote on the order of importance. Others statements will come up as we get discussions going on each, but that is to be expected. Have a Nice weekend. This have been a very productive session! Regards, Rik p.s. Chuch Shih of Premenos has stepped up to be one of the co-editors. Would Sterling, or someone else like to be one of the others? **new**ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI Internet messages we may send? Will file size impact transportablitity, ability to send/receive, depandability etc. **new**ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? **new** REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be assured that the purported original signatory of the message is the entity that actually sent (?) the message. **new**REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured that the message arrived in its "pure" and original state, i.e., was not modified by having data added, deleted, or changed along the way. **new**ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + Integrity = NRO **new**ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. **new**ISSUE: Key Management - Use of public-key cryptography for key management. Very much like the Standard Encryption Scheme issue, we must recommend the algorithms and existing standards that EDI over the Internet will use for key management. **new**ISSUE: Authentication - Use of digital signatures for authenticating EDI inter- changes. Again we must recommend the digital signature algorithms, hash functions and key lengths to be used for EDI over the Internet. **new**ISSUE: Non-repudiation of origin - Use of digital signatures for non-repudiation of origin. Recommend the digital signature algorithms, hash functions, and key lengths to be used for EDI over the Internet. **new**ISSUE: Non-repudiation of receipt - I agree with much of the discussion that has already taken place but would add these additional topics. Will the specifications that we come up with address only the non-repudiation of receipt of the e-mail message, or of each of the contents that are contained in a mime-message of which EDI could be one of many. Do we allow in our specification, security services to be applied to groups of documents in an interchange, or to individual documents within the interchange. Some businesses may want to send out an EDI Interchange consisting of many types of documents, only some of which need security applied to them. In this type of scenario the non-repudiation of receipt needs to be at a much more granular level then at an e-mail or even interchange level. **new**ISSUE: I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the net included in our discussion or just traditional EDI? ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. ACTION ITEM - we can use from the current Templar pilot to add to our document, i.e. can we leverage any of their efforts? ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. ISSUE - Dont duplicate what is already provided within the EDI standards. **new**ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. --- end forwarded text From owner-ietf-ediint Fri Feb 16 14:39:24 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01631 for ietf-ediint-bks; Fri, 16 Feb 1996 14:39:24 -0800 (PST) Received: from ns2.indirect.com (ns2.indirect.com [165.247.1.17]) by imc.imc.org (8.7.3/8.7.1) with SMTP id OAA01626 for ; Fri, 16 Feb 1996 14:39:20 -0800 (PST) Received: from dave_d (s123.phxslip4.indirect.com [165.247.24.123]) by ns2.indirect.com (8.6.12/8.6.6) with SMTP id PAA28037; Fri, 16 Feb 1996 15:45:53 -0700 Message-Id: <2.2.32.19960216223956.00b68ca0@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 15:39:56 -0700 To: ksteel@cs.mu.oz.au, mgreely@prisminfo.com, ietf-ediint@imc.org From: Dave Darnell Subject: RE: Re[2]: Segmentation Sender: owner-ietf-ediint@imc.org Precedence: bulk Good Point from Ken. My experience with X12 EDI is that the X12 translation is always at least twice as large as the original file. This varies quite a bit based on which fields get mapped and which dont, but as a rule of thumb, you have to plan on at least twice as many bytes when going from proprietary (or even an industry std like HCFA 1500 or UB92) to EDI. Regards, Dave_D At 09:21 AM 2/17/96 PST, ksteel@cs.mu.oz.au wrote: > >>From: mgreely@prisminfo.com >>Date: Fri, 16 Feb 96 15:20:23 cdt > >> If we start with a 30 Meg file before encryption how big is it going >> to be once it is encrypted? >> EDI makes the file as small as possible by eliminating all extra >> spacing. What file size are we talking about now? > >1. A 30Mb file for EDI is extremely rare. >2. The EDI syntaxes (trad-edi) may well reduce size by eliminating > spaces but adds an overhead of 100 to 900% through the > "fixed" segments and the use of dispersed semantics. >3. What's your point anyhow? > >------------------------------------- >Ken Steel >The University of Melbourne >Department of Computer Science >ksteel@cs.mu.oz.au > > > ====================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8479 | mailto://dave_d@systrends.com ====================== From owner-ietf-ediint Fri Feb 16 14:41:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id OAA01659 for ietf-ediint-bks; Fri, 16 Feb 1996 14:41:38 -0800 (PST) Received: from ns2.indirect.com (ns2.indirect.com [165.247.1.17]) by imc.imc.org (8.7.3/8.7.1) with SMTP id OAA01654 for ; Fri, 16 Feb 1996 14:41:36 -0800 (PST) Received: from dave_d (s123.phxslip4.indirect.com [165.247.24.123]) by ns2.indirect.com (8.6.12/8.6.6) with SMTP id PAA28142; Fri, 16 Feb 1996 15:48:39 -0700 Message-Id: <2.2.32.19960216224241.00c217cc@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 15:42:41 -0700 To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org From: Dave Darnell Subject: Re: Statement Summary #5 Sender: owner-ietf-ediint@imc.org Precedence: bulk RIck, Have you heard from TSI? I am in contact with them and have requested their participation. I have received a voice mail from a VP (Dave Ray) but have not spoken personally with him. Regards, Dave At 04:38 PM 2/16/96 -0600, Rik Drummond wrote: >These are great statements and issues you'all (I am from Texas) have expressed. > >Have we bounded the proplem yet? Do we need to keep brainstorming a few of >more days? > >YOUR ACTION REQUIRED: If you think it is time to _quit_ brainstorming, >broadcast the comment to the group. If you think we need to continue a few >more days ( not more than a week) your silence will indicate that. > >After the brainstorming is done, we will need to go back and clean the >statement up, combine and seperate some and then vote on the order of >importance. > >Others statements will come up as we get discussions going on each, but >that is to be expected. > >Have a Nice weekend. This have been a very productive session! > > >Regards, Rik > >p.s. Chuch Shih of Premenos has stepped up to be one of the co-editors. >Would Sterling, or someone else like to be one of the others? > > > > > >**new**ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI >Internet >messages we may send? Will file size impact transportablitity, ability to >send/receive, depandability etc. > >**new**ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? > > >**new** REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can >be assured >that the purported original signatory of the message is the entity that >actually sent (?) the message. > >**new**REQUIREMENT - INTEGRITY - The receiver of an EDI message can be >assured that >the message arrived in its "pure" and original state, i.e., was not modified >by having data added, deleted, or changed along the way. > >**new**ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + >Integrity = NRO > > >**new**ISSUE - SEGEMENTATION - Is there a requirement for segmentation, >where the >sender's system breaks up a large EDI interchange into a series of small >messages and the recipient's system recombines the small messages? >Apparently, some Internet e-mail systems have a maximum message size limit >of 50KB. PGP provides segmentation. So does Premenos's Templar product. > >**new**ISSUE: Key Management - Use of public-key cryptography for key >management. > Very much like the Standard Encryption Scheme issue, we must recommend > the algorithms and existing standards that EDI over the Internet will > use for key management. > >**new**ISSUE: Authentication - Use of digital signatures for authenticating >EDI inter- > changes. Again we must recommend the digital signature algorithms, hash > functions and key lengths to be used for EDI over the Internet. > >**new**ISSUE: Non-repudiation of origin - Use of digital signatures for >non-repudiation > of origin. Recommend the digital signature algorithms, hash functions, > and key lengths to be used for EDI over the Internet. > >**new**ISSUE: Non-repudiation of receipt - I agree with much of the >discussion that > has already taken place but would add these additional topics. Will > the specifications that we come up with address only the non-repudiation > of receipt of the e-mail message, or of each of the contents that are > contained in a mime-message of which EDI could be one of many. Do we > allow in our specification, security services to be applied to > groups of documents in an interchange, or to individual documents within > the interchange. Some businesses may want to send out an EDI Interchange > consisting of many types of documents, only some of which need security > applied to them. In this type of scenario the non-repudiation of > receipt needs to be at a much more granular level then at an e-mail > or even interchange level. > >**new**ISSUE: I think the thread of this has been touched upon on >Interchange sequence > numbers, but what additional management constructs do we need to come > up with when doing EDI over the Internet. For instance, today if two > EDI Interchanges are sent through a VAN with control numbers, and one > of them does not arrive at the receiver, the receiver can call the > VAN and attempt to trace it. What mechanisms would the receiver use > in this scenario when sending EDI over the Internet? > > >REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the >net included in our discussion or just traditional EDI? > > >ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose >controls at the communications layer which are not in place in the >underlying EDI standards. Message sequence integrity is a trading partner >dependent issue. If the issuer of the interchange control numbers uses any >other scheme than >sequential numbers by trading partner, checking for this at the >communications layer could cause more problems than it solves. > > >ISSUE - encrypted tunnels - We should take into account any >current/future >work that is going on to standardize encrypted tunnels. They may provide a >useful mechanism for providing security at the communications layer. Yes, >I am talking about encryption at the packet level. I guess that this really >depends on the outcome of the standardization work for tunnels. We would >need to adopt these standards to ensure that tunnels themselves >interwork. > > >ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee >message sequence integrity. In other words, message N+1 may be delivered >before message N. Some EDI VANs provide message sequence integrity. There >are probably some EDI applications that require message sequence integrity. > > >REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE >MESSAGES - >EDI users need an automated means to detect missing, duplicate or >out-of-sequence messages, where the sequencing problem is caused by the >communications layer (e.g., the Internet e-mail software) or the security >layer. Sequence problems caused by the business application or the EDI >translator are not within the scope of this requirement. This feature is >normally provided by the EDI translator that verifies that the interchange >control numbers (ICNs) are received in the correct sequence. If this >feature was provided by a layer below the EDI translator (e.g., the >security layer or the communications layer), then it could be used by >e-mail users, proprietary EDI applications that don't use an EDI >translator, and EDI applications where one of the trading partner's has a >translator that does not validate ICN sequencing. > > >ACTION ITEM - we can use from the current Templar pilot to add to our >document, i.e. can we leverage any of their efforts? > >ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that >can be transported via the Internet. The definition of an interchange for >MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the >relevant standards, and should be defined between trading partners who >choose to use the Application/EDI-Consent MIME type. Can multiple >interchanges be transported in a single MIME envelope, or can only a single >interchange be contained in a single MIME envelope ? > >REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI >transaction within MIME including the ISA segment using an existing >encryption standard or combination of standards such as PGP, DES, MOSS or >S/MIME. > >ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the >existing encryption standands for use in EDI over Internet. > >ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work >across the world and not be limited by the export (or legal) restrictions >of any nation. > >ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / >MIME / Internet package should implement compatible functionality (or be >easily translatable between) with X.434. > >REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. > >ISSUE - Dont duplicate what is already provided within the EDI standards. > >**new**ISSUE - encrypted tunnels - We should take into account any >current/future >work that is going on to standardize encrypted tunnels. They may provide a >useful mechanism for providing security at the communications layer. Yes, >I am talking about encryption at the packet level. I guess that this really >depends on the outcome of the standardization work for tunnels. We would >need to adopt these standards to ensure that tunnels themselves >interwork. > >--- end forwarded text > > > > > ====================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8479 | mailto://dave_d@systrends.com ====================== From owner-ietf-ediint Fri Feb 16 17:06:10 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id RAA02281 for ietf-ediint-bks; Fri, 16 Feb 1996 17:06:10 -0800 (PST) Received: from tide10.microsoft.com (firewall-user@tide10.microsoft.com [131.107.3.20]) by imc.imc.org (8.7.3/8.7.1) with SMTP id RAA02276 for ; Fri, 16 Feb 1996 17:06:08 -0800 (PST) Received: by tide10.microsoft.com; id RAA00810; Fri, 16 Feb 1996 17:35:33 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma000720; Fri, 16 Feb 96 17:34:55 -0800 Received: from xnet1 (xnet1.microsoft.com [157.54.17.204]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id RAA19219 for ; Fri, 16 Feb 1996 17:16:40 -0800 (PST) X-Received: from xmtp6 by xnet1 with receive; Fri, 16 Feb 1996 17:13:00 -0800 X-Received: from RED-01-IMC by xmtp6 with recvsmtp; Fri, 16 Feb 1996 17:12:55 -0800 Received: by red-01-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.17.736) id <01BAFC92.03FD8100@red-01-imc.itg.microsoft.com>; Fri, 16 Feb 1996 17:12:56 -0800 Message-ID: From: Lori Blackburn To: "ietf-ediint@imc.org" , "'chuck@orville.premenos.com'" Subject: RE: Additional Issues Date: Fri, 16 Feb 1996 17:12:54 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.17.736 Encoding: 72 TEXT X-MsXMTID: xmtp6960217011255RECVSMTP[01.52.00]000000c0-34523 Sender: owner-ietf-ediint@imc.org Precedence: bulk Additional, Additional issue related to Key Management... Who will be the keepers of the Public and Private keys? I once heard a rumor the Post Office wanted to get into that business....? >---------- >From: chuck@orville.premenos.com[SMTP:chuck@orville.premenos.com] >Sent: Friday, February 16, 1996 11:12 AM >To: ietf-ediint@imc.org >Subject: Additional Issues > >Some additional issues that I have not seen posted are as follows: > >ISSUE: Key Management - Use of public-key cryptography for key >management. > Very much like the Standard Encryption Scheme issue, we must >recommend > the algorithms and existing standards that EDI over the Internet >will > use for key management. > >ISSUE: Authentication - Use of digital signatures for authenticating >EDI inter- > changes. Again we must recommend the digital signature >algorithms, hash > functions and key lengths to be used for EDI over the Internet. > >ISSUE: Non-repudiation of origin - Use of digital signatures for >non-repudiation > of origin. Recommend the digital signature algorithms, hash >functions, > and key lengths to be used for EDI over the Internet. > >ISSUE: Non-repudiation of receipt - I agree with much of the discussion >that > has already taken place but would add these additional topics. >Will > the specifications that we come up with address only the >non-repudiation > of receipt of the e-mail message, or of each of the contents >that are > contained in a mime-message of which EDI could be one of many. >Do we > allow in our specification, security services to be applied to > groups of documents in an interchange, or to individual >documents within > the interchange. Some businesses may want to send out an EDI >Interchange > consisting of many types of documents, only some of which need >security > applied to them. In this type of scenario the non-repudiation of > receipt needs to be at a much more granular level then at an >e-mail > or even interchange level. > >ISSUE: I think the thread of this has been touched upon on Interchange >sequence > numbers, but what additional management constructs do we need to >come > up with when doing EDI over the Internet. For instance, today if >two > EDI Interchanges are sent through a VAN with control numbers, >and one > of them does not arrive at the receiver, the receiver can call >the > VAN and attempt to trace it. What mechanisms would the receiver >use > in this scenario when sending EDI over the Internet? > > > > > From owner-ietf-ediint Sat Feb 17 01:15:48 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id BAA04064 for ietf-ediint-bks; Sat, 17 Feb 1996 01:15:48 -0800 (PST) Received: from franklin-fddi.cris.com (franklin-fddi.cris.com [199.3.126.7]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id BAA04055 for ; Sat, 17 Feb 1996 01:15:46 -0800 (PST) Received: from fs1.cris.com by franklin-fddi.cris.com [1-800-745-CRIS (voice)] Received: from cnc087036.concentric.net by fs1.cris.com (8.7.1) id QAA13575; Fri, 16 Feb 1996 16:14:41 -0500 (EST) Message-Id: <2.2.16.19960216211101.0eb735a0@pop3.concentric.net> X-Sender: trevr@pop3.concentric.net X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 15:11:01 -0600 To: ietf-ediint@imc.org From: Trevor Richards Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk At 11:32 AM 2/16/96 -0500, Bob Lyons wrote: >At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >>Let's make sure that we don't impose controls at the communications layer >>which are not in place in the underlying EDI standards. > >Why? If the EDI standards met all of our security needs for doing EDI over >the Internet, then there would be very little need for this work group. I agree wholeheartedly that the current EDI standards leave a lot to be desired! >If we don't have message sequence integrity, then how will EDI users protect >themselves from replay attacks and the deletion of messages while in >transit? To secure your EDI messages as they traverse the Internet, it's not >enough to encrypt and apply digital signatures. Do you envisage the responsibility for ensuring delivery being with the sender, the receiver or both ? Receiving an acknowledgement of receipt from the receiver for each transmission would satisfy the senders' requirement to ensure delivery. The only way the receiver could check for either duplicate transmissions of any EDI format (standard or mutually agreed) or missing transmissions would be if we provided the option to include a "transmission control number" (which is sequentially assigned by recipient) outside of the EDI data being transmitted (as part of the MIME header ?). Is this an issue that we should raise ? Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Sat Feb 17 01:15:30 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id BAA04051 for ietf-ediint-bks; Sat, 17 Feb 1996 01:15:30 -0800 (PST) Received: from franklin-fddi.cris.com (franklin-fddi.cris.com [199.3.126.7]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id BAA04046 for ; Sat, 17 Feb 1996 01:15:28 -0800 (PST) Received: from fs1.cris.com by franklin-fddi.cris.com [1-800-745-CRIS (voice)] Received: from cnc087042.concentric.net by fs1.cris.com (8.7.1) id NAA09396; Fri, 16 Feb 1996 13:11:46 -0500 (EST) Message-Id: <2.2.16.19960216180810.218f602e@pop3.concentric.net> X-Sender: trevr@pop3.concentric.net X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 12:08:10 -0600 To: ietf-ediint@imc.org From: Trevor Richards Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk At 11:32 AM 2/16/96 -0500, Bob Lyons wrote: >At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >>Let's make sure that we don't impose controls at the communications layer >>which are not in place in the underlying EDI standards. > >Why? If the EDI standards met all of our security needs for doing EDI over >the Internet, then there would be very little need for this work group. I agree wholeheartedly that the current EDI standards leave a lot to be desired! >If we don't have message sequence integrity, then how will EDI users protect >themselves from replay attacks and the deletion of messages while in >transit? To secure your EDI messages as they traverse the Internet, it's not >enough to encrypt and apply digital signatures. Do you envisage the responsibility for ensuring delivery being with the sender, the receiver or both ? Receiving an acknowledgement of receipt from the receiver for each transmission would satisfy the senders' requirement to ensure delivery. The only way the receiver could check for either duplicate transmissions of any EDI format (standard or mutually agreed) or missing transmissions would be if we provided the option to include a "transmission control number" (which is sequentially assigned by recipient) outside of the EDI data being transmitted (as part of the MIME header ?). Is this an issue that we should raise ? Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Sat Feb 17 01:15:48 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id BAA04065 for ietf-ediint-bks; Sat, 17 Feb 1996 01:15:48 -0800 (PST) Received: from franklin-fddi.cris.com (franklin-fddi.cris.com [199.3.126.7]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id BAA04054 for ; Sat, 17 Feb 1996 01:15:45 -0800 (PST) Received: from fs1.cris.com by franklin-fddi.cris.com [1-800-745-CRIS (voice)] Received: from cnc087036.concentric.net by fs1.cris.com (8.7.1) id RAA15001; Fri, 16 Feb 1996 17:11:00 -0500 (EST) Message-Id: <2.2.16.19960216220720.68b7b4f6@mail.concentric.net> X-Sender: trevr@mail.concentric.net X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Feb 1996 16:07:20 -0600 To: ietf-ediint@imc.org From: Trevor Richards Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk At 11:32 AM 2/16/96 -0500, Bob Lyons wrote: >At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >>Let's make sure that we don't impose controls at the communications layer >>which are not in place in the underlying EDI standards. > >Why? If the EDI standards met all of our security needs for doing EDI over >the Internet, then there would be very little need for this work group. I agree wholeheartedly that the current EDI standards leave a lot to be desired! >If we don't have message sequence integrity, then how will EDI users protect >themselves from replay attacks and the deletion of messages while in >transit? To secure your EDI messages as they traverse the Internet, it's not >enough to encrypt and apply digital signatures. Do you envisage the responsibility for ensuring delivery being with the sender, the receiver or both ? Receiving an acknowledgement of receipt from the receiver for each transmission would satisfy the senders' requirement to ensure delivery. The only way the receiver could check for either duplicate transmissions of any EDI format (standard or mutually agreed) or missing transmissions would be if we provided the option to include a "transmission control number" (which is sequentially assigned by recipient) outside of the EDI data being transmitted (as part of the MIME header ?). Is this an issue that we should raise ? Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Sat Feb 17 01:57:30 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id BAA04212 for ietf-ediint-bks; Sat, 17 Feb 1996 01:57:30 -0800 (PST) Received: from tide10.microsoft.com (firewall-user@[131.107.3.20]) by imc.imc.org (8.7.3/8.7.1) with SMTP id BAA04207 for ; Sat, 17 Feb 1996 01:57:29 -0800 (PST) Received: by tide10.microsoft.com; id CAA14115; Sat, 17 Feb 1996 02:27:04 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma014085; Sat, 17 Feb 96 02:26:52 -0800 Received: from xnet1 (xnet1.microsoft.com [157.54.17.204]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id CAA13148 for ; Sat, 17 Feb 1996 02:08:32 -0800 (PST) X-Received: from xmtp6 by xnet1 with receive; Sat, 17 Feb 1996 02:04:48 -0800 X-Received: from RED-04-IMC by xmtp6 with recvsmtp; Sat, 17 Feb 1996 02:04:43 -0800 Received: by red-04-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.17.736) id <01BAFCDC.4D6B9210@red-04-imc.itg.microsoft.com>; Sat, 17 Feb 1996 02:04:42 -0800 Message-ID: From: Scott Whelan To: "'ietf-ediint@imc.org'" Date: Fri, 16 Feb 1996 17:26:51 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.17.736 Encoding: 0 TEXT X-MsXMTID: xmtp6960217100443RECVSMTP[01.52.00]000000c0-37045 Sender: owner-ietf-ediint@imc.org Precedence: bulk From owner-ietf-ediint Sat Feb 17 09:41:16 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id JAA07795 for ietf-ediint-bks; Sat, 17 Feb 1996 09:41:16 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id JAA07790 for ; Sat, 17 Feb 1996 09:41:14 -0800 (PST) Received: from [199.184.212.144] (turnpike45.onramp.net [199.184.212.144]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA29417; Sat, 17 Feb 1996 11:48:47 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 17 Feb 1996 11:55:04 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Re: Message Sequence Integrity Cc: trevr@cris.com Sender: owner-ietf-ediint@imc.org Precedence: bulk --- begin forwarded text Errors-To: trevr@cris.com X-Sender: trevr@mail.concentric.net Mime-Version: 1.0 Date: Fri, 16 Feb 1996 16:16:11 -0600 To: Rik Drummond From: Trevor Richards Subject: Re: Message Sequence Integrity Rik I've been trying, unsuccessfully, to send the following message to the mailing list since noon today. Unfortunately, I seem to be in "email hell", where messages are being recived through my provider and outgoing messages are being transmitted .... but some messages don't seem to be making it to the other end ! Can you send this to the list, if you receive it ? At 11:32 AM 2/16/96 -0500, Bob Lyons wrote: >At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >>Let's make sure that we don't impose controls at the communications layer >>which are not in place in the underlying EDI standards. > >Why? If the EDI standards met all of our security needs for doing EDI over >the Internet, then there would be very little need for this work group. I agree wholeheartedly that the current EDI standards leave a lot to be desired! >If we don't have message sequence integrity, then how will EDI users protect >themselves from replay attacks and the deletion of messages while in >transit? To secure your EDI messages as they traverse the Internet, it's not >enough to encrypt and apply digital signatures. Do you envisage the responsibility for ensuring delivery being with the sender, the receiver or both ? Receiving an acknowledgement of receipt from the receiver for each transmission would satisfy the senders' requirement to ensure delivery. The only way the receiver could check for either duplicate transmissions of any EDI format (standard or mutually agreed) or missing transmissions would be if we provided the option to include a "transmission control number" (which is sequentially assigned by recipient) outside of the EDI data being transmitted (as part of the MIME header ?). Is this an issue that we should raise ? Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com --- end forwarded text From owner-ietf-ediint Sat Feb 17 11:36:20 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA08233 for ietf-ediint-bks; Sat, 17 Feb 1996 11:36:20 -0800 (PST) Received: from hiway1.exit109.com (hiway1.exit109.com [205.164.176.32]) by imc.imc.org (8.7.3/8.7.1) with SMTP id LAA08228 for ; Sat, 17 Feb 1996 11:36:17 -0800 (PST) Received: from ppp3-rb.exit109.com (ppp3-rb.exit109.com [205.164.176.130]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id OAA20991; Sat, 17 Feb 1996 14:43:23 -0500 Date: Sat, 17 Feb 1996 14:43:23 -0500 Message-Id: <199602171943.OAA20991@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Re: Message Sequence Integrity Cc: trevr@cris.com Sender: owner-ietf-ediint@imc.org Precedence: bulk Trevor, I received four copies of your posting. (Three from you, and the 4th via Rik.) Did you do this intentionally in order to illustrate the need for detecting duplicate messages? :-) Bob Lyons At 11:55 AM 2/17/96 -0600, Rik Drummond wrote: > >--- begin forwarded text > >Errors-To: trevr@cris.com >X-Sender: trevr@mail.concentric.net >Mime-Version: 1.0 >Date: Fri, 16 Feb 1996 16:16:11 -0600 >To: Rik Drummond >From: Trevor Richards >Subject: Re: Message Sequence Integrity > >Rik > >I've been trying, unsuccessfully, to send the following message to the >mailing list since noon today. Unfortunately, I seem to be in "email hell", >where messages are being recived through my provider and outgoing messages >are being transmitted .... but some messages don't seem to be making it to >the other end ! >Can you send this to the list, if you receive it ? > >At 11:32 AM 2/16/96 -0500, Bob Lyons wrote: >>At 09:06 AM 2/16/96 -0600, Trevor Richards wrote: >>>Let's make sure that we don't impose controls at the communications layer >>>which are not in place in the underlying EDI standards. >> >>Why? If the EDI standards met all of our security needs for doing EDI over >>the Internet, then there would be very little need for this work group. > >I agree wholeheartedly that the current EDI standards leave a lot to be desired! > >>If we don't have message sequence integrity, then how will EDI users protect >>themselves from replay attacks and the deletion of messages while in >>transit? To secure your EDI messages as they traverse the Internet, it's not >>enough to encrypt and apply digital signatures. > >Do you envisage the responsibility for ensuring delivery being with the >sender, the receiver or both ? Receiving an acknowledgement of receipt from >the receiver for each transmission would satisfy the senders' requirement to >ensure delivery. The only way the receiver could check for either duplicate >transmissions of any EDI format (standard or mutually agreed) or missing >transmissions would be if we provided the option to include a "transmission >control number" (which is sequentially assigned by recipient) outside of the >EDI data being transmitted (as part of the MIME header ?). Is this an issue >that we should raise ? > > Trevor Richards phone : (512)345-3981 > Trinary Systems fax : (512)345-8705 > Austin, TX e-mail : richards@trinary.com > >--- end forwarded text > > > > From owner-ietf-ediint Sun Feb 18 11:13:41 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id LAA14470 for ietf-ediint-bks; Sun, 18 Feb 1996 11:13:41 -0800 (PST) Received: from franklin-fddi.cris.com (franklin-fddi.cris.com [199.3.126.7]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id LAA14465 for ; Sun, 18 Feb 1996 11:13:38 -0800 (PST) Received: from fs1.cris.com by franklin-fddi.cris.com [1-800-745-CRIS (voice)] Received: from jake-4o.ip.realtime.net by fs1.cris.com (8.7.1) id OAA28709; Sun, 18 Feb 1996 14:20:46 -0500 (EST) Message-Id: <2.2.16.19960218191655.2497a9e8@mail.concentric.net> X-Sender: trevr@mail.concentric.net X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 Feb 1996 13:16:55 -0600 To: ietf-ediint@imc.org From: Trevor Richards Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk Bob It certainly emphasizes the need to consider the timing factor of delivery of EDI data via email. As you can see from the times on the messages, I was trying for several hours to post the message to the list server ... but to no avail. One further aspect that I think we should consider is terminology. The term message seems to be applied in the IETF-EDIINT discussions to both (i) the whole "package" of EDI data which is being transmitted via email or ftp; and (ii) to the transaction sets (messages) which fall inside the ANSI ASC X12 and UN/EDIFACT control segments (or their proprietary equivalents). Do you think we should find another term for the package of EDI data being transmitted to eliminate any confusion with the term message defined in the UN/EDIFACT standard? At 02:43 PM 2/17/96 -0500, you wrote: >Trevor, > >I received four copies of your posting. (Three from you, and the 4th via Rik.) > >Did you do this intentionally in order to illustrate the need for detecting >duplicate messages? :-) > >Bob Lyons >At 11:55 AM 2/17/96 -0600, Rik Drummond wrote: >> >>--- begin forwarded text >> >>Errors-To: trevr@cris.com >>X-Sender: trevr@mail.concentric.net >>Mime-Version: 1.0 >>Date: Fri, 16 Feb 1996 16:16:11 -0600 >>To: Rik Drummond >>From: Trevor Richards >>Subject: Re: Message Sequence Integrity >> >>Rik >> >>I've been trying, unsuccessfully, to send the following message to the >>mailing list since noon today. Unfortunately, I seem to be in "email hell", >>where messages are being recived through my provider and outgoing messages >>are being transmitted .... but some messages don't seem to be making it to >>the other end ! >>Can you send this to the list, if you receive it ? >> Trevor Richards phone : (512)345-3981 Trinary Systems fax : (512)345-8705 Austin, TX e-mail : richards@trinary.com From owner-ietf-ediint Sun Feb 18 18:13:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id SAA16012 for ietf-ediint-bks; Sun, 18 Feb 1996 18:13:38 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.imc.org (8.7.3/8.7.1) with SMTP id SAA16007 for ; Sun, 18 Feb 1996 18:13:36 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA06187; Sun, 18 Feb 1996 21:18:39 -0500 Date: Sun, 18 Feb 1996 21:18:39 -0500 Message-Id: <9602190218.AA06187@RezoNet.NET> X-Sender: epmck@ns.rezonet.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: "E. Peter McKinney, CA" Subject: RE: Additional Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk Yes, in fact USPS has an ongoing project in this regard. Cheers Peter At 05:12 PM 2/16/96 -0800, you wrote: >Additional, Additional issue related to Key Management... Who will be >the keepers of the Public and Private keys? I once heard a rumor the >Post Office wanted to get into that business....? > >>---------- >>From: chuck@orville.premenos.com[SMTP:chuck@orville.premenos.com] >>Sent: Friday, February 16, 1996 11:12 AM >>To: ietf-ediint@imc.org >>Subject: Additional Issues >> >>Some additional issues that I have not seen posted are as follows: >> >>ISSUE: Key Management - Use of public-key cryptography for key >>management. >> Very much like the Standard Encryption Scheme issue, we must >>recommend >> the algorithms and existing standards that EDI over the Internet >>will >> use for key management. >> >>ISSUE: Authentication - Use of digital signatures for authenticating >>EDI inter- >> changes. Again we must recommend the digital signature >>algorithms, hash >> functions and key lengths to be used for EDI over the Internet. >> >>ISSUE: Non-repudiation of origin - Use of digital signatures for >>non-repudiation >> of origin. Recommend the digital signature algorithms, hash >>functions, >> and key lengths to be used for EDI over the Internet. >> >>ISSUE: Non-repudiation of receipt - I agree with much of the discussion >>that >> has already taken place but would add these additional topics. >>Will >> the specifications that we come up with address only the >>non-repudiation >> of receipt of the e-mail message, or of each of the contents >>that are >> contained in a mime-message of which EDI could be one of many. >>Do we >> allow in our specification, security services to be applied to >> groups of documents in an interchange, or to individual >>documents within >> the interchange. Some businesses may want to send out an EDI >>Interchange >> consisting of many types of documents, only some of which need >>security >> applied to them. In this type of scenario the non-repudiation of >> receipt needs to be at a much more granular level then at an >>e-mail >> or even interchange level. >> >>ISSUE: I think the thread of this has been touched upon on Interchange >>sequence >> numbers, but what additional management constructs do we need to >>come >> up with when doing EDI over the Internet. For instance, today if >>two >> EDI Interchanges are sent through a VAN with control numbers, >>and one >> of them does not arrive at the receiver, the receiver can call >>the >> VAN and attempt to trace it. What mechanisms would the receiver >>use >> in this scenario when sending EDI over the Internet? >> >> >> >> >> > > ================================================= E. Peter McKinney,CA | McKinney, Paul & Assoc. Inc. | An Information Systems / EDI - EC Consultantcy | Montreal, Canada {epmck @ interlink.net] | Tel : +1-514-852-4497 Fax : +1-514-329-0494 | ================================================= From owner-ietf-ediint Mon Feb 19 01:47:05 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id BAA17440 for ietf-ediint-bks; Mon, 19 Feb 1996 01:47:05 -0800 (PST) Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id BAA17433 for ; Mon, 19 Feb 1996 01:46:57 -0800 (PST) Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id KAA23782 for ; Mon, 19 Feb 1996 10:54:40 +0100 Received: from edieng.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id KAA07176 for ; Mon, 19 Feb 1996 10:52:19 +0100 Message-Id: <199602190952.KAA07176@vbormc.vbo.dec.com> Received: from edieng.enet; by vbormc.enet; Mon, 19 Feb 96 10:52:20 MET Date: Mon, 19 Feb 96 10:52:20 MET From: NAD+FR+EDI ENGINEERING:"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'" To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Apparently-To: ietf-ediint@imc.org Subject: General Observations Sender: owner-ietf-ediint@imc.org Precedence: bulk Folks, I took a few days of and wading through the 40 odd mails left me confused. In particular, the Interchange Control Number (ICN) debate. In particular, the ICN's location is standards specific, and not just in EDIFACT and X12, so the EDI-CONSENT type needs to know about it as well. The value is within the Interchange content, so if encryption is applied 'above' the edi interchange level then how can you get at it. As a number of mails have pointed out there are no rules as to how the ICN is populated, and I have come across 19 different ways they have been implemented, whilst some are just duplication across standards, I'm sure this is just the tip of the iceberg. I think ICN checking, whilst a valid user requirement is best left to the 'value added' of the VAN's and the features of the various EDI Translators. It does not stop people doing 'EDI over the Internet' any more than it stops them doing EDI over X.400. One thing that did occur to me is that is we are not able to look within the interchange for information, can we propergate it outside so VAN's can interpret some of the information. X.435 tool this approach for a lot of the EDI Interchange level information. Regards, Graham From owner-ietf-ediint Mon Feb 19 02:05:33 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id CAA18913 for ietf-ediint-bks; Mon, 19 Feb 1996 02:05:33 -0800 (PST) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by imc.imc.org (8.7.3/8.7.1) with SMTP id CAA18908 for ; Mon, 19 Feb 1996 02:05:26 -0800 (PST) From: ksteel@cs.mu.oz.au Received: from kds.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01724 Mon, 19 Feb 1996 21:13:07 +1100 (from ksteel@cs.mu.oz.au) Date: Mon, 19 Feb 96 21:14:20 PST Subject: RE: General Observations To: ietf-ediint@imc.org X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Mon, 19 Feb 96 10:52:20 MET >From: NAD+FR+EDI ENGINEERING:"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'" >In particular, the Interchange Control Number (ICN) debate. In particular, the >ICN's location is standards specific, and not just in EDIFACT and X12, so the >EDI-CONSENT type needs to know about it as well. The value is within the >Interchange content, so if encryption is applied 'above' the edi interchange >level then how can you get at it. > >As a number of mails have pointed out there are no rules as to how the ICN is >populated, and I have come across 19 different ways they have been implemented, >whilst some are just duplication across standards, I'm sure this is just the tip >of the iceberg. > >I think ICN checking, whilst a valid user requirement is best left to the 'value >added' of the VAN's and the features of the various EDI Translators. It does not >stop people doing 'EDI over the Internet' any more than it stops them doing EDI >over X.400. Folks, I have to agree with Graham. I think this project is so far off the rails now, it is useless proceeding any further. Please unsubscribe me. ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Mon Feb 19 10:51:38 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id KAA21014 for ietf-ediint-bks; Mon, 19 Feb 1996 10:51:38 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id KAA21009 for ; Mon, 19 Feb 1996 10:51:34 -0800 (PST) Received: from [199.184.212.226] (stockyard63.onramp.net [199.184.212.226]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id MAA22227 for ; Mon, 19 Feb 1996 12:59:12 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Feb 1996 13:05:14 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Are you getting the messages Sender: owner-ietf-ediint@imc.org Precedence: bulk Some people are having proplems getting messages. If you think you are please contact me. -- 817 294 7339. Also, some responses to messages are not showing ietf-ediint@imc.org. Please make sure when you are responding to a message which should go to the whole list that the address "ietf-ediint@imc.org" is on the message. I have been forwarding them on when this happens. I am sure I am missing some...later... Rik Drummond From owner-ietf-ediint Mon Feb 19 12:35:27 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id MAA21511 for ietf-ediint-bks; Mon, 19 Feb 1996 12:35:27 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id MAA21506 for ; Mon, 19 Feb 1996 12:35:25 -0800 (PST) Received: from [199.184.212.226] (stockyard42.onramp.net [199.184.212.205]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id OAA13363; Mon, 19 Feb 1996 14:43:01 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 19 Feb 1996 14:49:02 +0100 To: ksteel@cs.mu.oz.au From: drummond@onramp.net (Rik Drummond) Subject: RE: General Observations Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Let quit discussing the ICN checking short term and finish brainstorming. We will then make a list of issues/requirments and then vote on whether we keep'em to work on or not work on them because they are outside of the project objective. If you have any more issues / needs/ issues please get them in by Wed. PM. We will then close out the brainstorming part and clean up the items and then prioritize and order them so that we may start doing the outline of the paper and investigating possible directions and recommendations. Later...Rik >>Date: Mon, 19 Feb 96 10:52:20 MET >>From: NAD+FR+EDI ENGINEERING:"PSE:DEC+GRAHAM HELLIAR:830-3173++REO2-F/D2'" > > >>In particular, the Interchange Control Number (ICN) debate. In >>particular, the >>ICN's location is standards specific, and not just in EDIFACT and X12, so the >>EDI-CONSENT type needs to know about it as well. The value is within the >>Interchange content, so if encryption is applied 'above' the edi interchange >>level then how can you get at it. >> >>As a number of mails have pointed out there are no rules as to how the ICN is >>populated, and I have come across 19 different ways they have been >>implemented, >>whilst some are just duplication across standards, I'm sure this is just >>the tip >>of the iceberg. >> >>I think ICN checking, whilst a valid user requirement is best left to the >>'value >>added' of the VAN's and the features of the various EDI Translators. It >>does not >>stop people doing 'EDI over the Internet' any more than it stops them >>doing EDI >>over X.400. > >Folks, > >I have to agree with Graham. > >I think this project is so far off the rails now, it is useless >proceeding any further. > >Please unsubscribe me. > >------------------------------------- >Ken Steel >The University of Melbourne >Department of Computer Science >ksteel@cs.mu.oz.au From owner-ietf-ediint Mon Feb 19 13:07:02 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id NAA21640 for ietf-ediint-bks; Mon, 19 Feb 1996 13:07:02 -0800 (PST) Received: from uuneo.neosoft.com (root@uuneo.neosoft.com [206.109.1.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id NAA21634 for ; Mon, 19 Feb 1996 13:06:56 -0800 (PST) From: mgreely@prisminfo.com Received: from mail.prisminfo.com ([206.109.132.20]) by uuneo.neosoft.com (8.7.3/8.7.3) with SMTP id PAA09386; Mon, 19 Feb 1996 15:14:34 -0600 (CST) Received: from ccMail by mail.prisminfo.com (SMTPLINK V2.11 PreRelease 4) id AA824771637; Mon, 19 Feb 96 15:12:40 cdt Date: Mon, 19 Feb 96 15:12:40 cdt Encoding: 42 Text Message-Id: <9601198247.AA824771637@mail.prisminfo.com> To: ietf-ediint@imc.org, ksteel@cs.mu.oz.au Subject: Re[4]: Segmentation Sender: owner-ietf-ediint@imc.org Precedence: bulk EDI transactions over 30mg are not rare at all. The steel, oil, banking and office products have 30 mg files all time between POs and invoices. The point being Vans charge users by the KC. If the internet solution is only one part of a users requirement, one part of the trading partner relationship uses a Van to receive while the other has direct internet capability. The customer/trading partner using the Van will become even more economically burdened by the file size. That company will not want to use the internet because of the cost involved. This just may be a decision that the company makes but it will also keep activity off the internet. ______________________________ Reply Separator _________________________________ Subject: RE: Re[2]: Segmentation Author: ksteel@cs.mu.oz.au at INTERNET Date: 2/17/96 9:21 AM >From: mgreely@prisminfo.com >Date: Fri, 16 Feb 96 15:20:23 cdt > If we start with a 30 Meg file before encryption how big is it going > to be once it is encrypted? > EDI makes the file as small as possible by eliminating all extra > spacing. What file size are we talking about now? 1. A 30Mb file for EDI is extremely rare. 2. The EDI syntaxes (trad-edi) may well reduce size by eliminating spaces but adds an overhead of 100 to 900% through the "fixed" segments and the use of dispersed semantics. 3. What's your point anyhow? ------------------------------------- Ken Steel The University of Melbourne Department of Computer Science ksteel@cs.mu.oz.au From owner-ietf-ediint Tue Feb 20 09:26:09 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id JAA27688 for ietf-ediint-bks; Tue, 20 Feb 1996 09:26:09 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id JAA27683 for ; Tue, 20 Feb 1996 09:26:07 -0800 (PST) Received: from [199.184.212.198] (stockyard35.onramp.net [199.184.212.198]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA11095 for ; Tue, 20 Feb 1996 11:33:51 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 20 Feb 1996 11:39:55 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: The next step Sender: owner-ietf-ediint@imc.org Precedence: bulk It looks like we are almost complete on identifing the initial list of issues and requirments. I have not seen anything new in a couple of days. The next step is to refine each of those on the list - "Statement Summary #5" - and make them more readable and concise. My plan is (and please make adjustments/suggestions) to ask people to break in to small work groups to work on cleaning up each statement or series of statements for futher review by the whole group. I plan on assign (for lack of a better way) certain people the responsibility for specific statments and let people communicate directly with them (not the entire group) to reduce traffic and allow multiple efforts to run at the same time. After they have completed the work the whole group would review and approve the statements. If you wish wish to be responsible for one or more of the statements, those in "Statement Summary #5" or do NOT wish to be responsible for any of the statements please let me know soonest. Later....Rik From owner-ietf-ediint Tue Feb 20 10:37:00 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id KAA27964 for ietf-ediint-bks; Tue, 20 Feb 1996 10:37:00 -0800 (PST) Received: from gatekeeper.premenos.com (crimson.premenos.com [150.105.250.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id KAA27959 for ; Tue, 20 Feb 1996 10:36:58 -0800 (PST) Received: from localhost (smap@localhost) by gatekeeper.premenos.com (8.6.5/8.6.5) id KAA20887; Tue, 20 Feb 1996 10:43:16 -0800 Received: from orville.premenos.com(150.105.100.82) by mail.premenos.com via smap (V1.3mjr) id sma020879; Tue Feb 20 10:42:26 1996 Received: by orville.premenos.com. (5.x/SMI-SVR4) id AA04219; Tue, 20 Feb 1996 10:44:14 -0800 Date: Tue, 20 Feb 1996 10:44:14 -0800 From: chuck@orville.premenos.com (Chuck Shih) Message-Id: <9602201844.AA04219@orville.orville.premenos.com.> To: drummond@onramp.net Subject: Re: Statement Summary #4 Cc: ietf-ediint@imc.org X-Sun-Charset: US-ASCII Sender: owner-ietf-ediint@imc.org Precedence: bulk ----- Begin Included Message ----- >From owner-ietf-ediint@imc.imc.org Fri Feb 16 09:48 PST 1996 Mime-Version: 1.0 Date: Fri, 16 Feb 1996 11:13:26 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #4 ACTION ITEM - we can use from the current Templar pilot to add to our document, i.e. can we leverage any of their efforts? Rik, Templar is out of pilot and the software has been generally available since May of 1995. I think we can definitely leverage what has been learned with our experiences with Templar. ----- End Included Message ----- Rik, From owner-ietf-ediint Tue Feb 20 13:31:26 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id NAA28734 for ietf-ediint-bks; Tue, 20 Feb 1996 13:31:26 -0800 (PST) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id NAA28728 for ; Tue, 20 Feb 1996 13:31:21 -0800 (PST) Received: from tgate1 (tgate1.mitre.org [128.29.154.210]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id QAA28832; Tue, 20 Feb 1996 16:39:04 -0500 Received: from mail06.mitre.org (128.29.250.7) by tgate1.mitre.org (EMWAC SMTPRS 0.60) with SMTP id ; Tue, 20 Feb 1996 16:39:03 -0500 Received: by mail06.mitre.org; (5.65 EXP 2/15/95/1.1.8.2/22Jun94-0628PM) id AA09719; Tue, 20 Feb 1996 16:38:58 -0500 Subject: RE: The next step From: clueder@mail06.mitre.org (Christopher J. Kit Lueder) To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org Message-Id: <960220163854.12988@mail06.mitre.org.0> Date: Tue, 20 Feb 96 16:38:57 -0500 X-Mailer: MAILworks 1.7-A-1 Sender: owner-ietf-ediint@imc.org Precedence: bulk OK, I finally got around to writing up the Integrity and Non-repudiation requirements. Integrity (without confidentiality) is important in cases where the VAN needs the ISA/GS information to be visible for routing purposes, or in countries like France where encryption of the data contents is illegal (in general). The need for integrity is to be assured that the data arrived without changes. Similarly, the non-repudiation of origin service is important to be assured of who sent the data; this is important for RFPs, proposals, or large purchase orders, where you want to be sure you know who the transaction came from before you process it. Kit Lueder. MITRE. REQUIREMENT - TRANSACTION INTEGRITY - Assurance of integrity of the entire EDI transaction is required. This involves producing a hash code of the transaction, which is transmitted in a secure way (either by encrypting the hash code using the sender's private key, or encrypting it using the recipient's public key). The EDI transaction may be carried along as one MIME attachment and the encrypted hash code could be conveyed as a second MIME attachment. Encryption of the hash code within MIME could use an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. REQUIREMENT - NON-REPUDIATION OF ORIGIN OF A TRANSACTION - Assurance of identity of the originator of the EDI transaction is required, with non-repudiation of origin service. This involves producing a hash code of the transaction, which is transmitted with a digital signature of the sender; the hash code is encrypted using the sender's private key. The EDI transaction may be carried along as one MIME attachment and the signature could be conveyed as a second MIME attachment. The signature within MIME could use an existing encryption standard or combination of standards such as PGP, MOSS or S/MIME. (Secret key encryption algorithms (e.g., DES) do not support non-repudiation services.) >It looks like we are almost complete on identifing the initial list of >issues and requirments. I have not seen anything new in a couple of days. >The next step is to refine each of those on the list - "Statement Summary >#5" - and make them more readable and concise. My plan is (and please make >adjustments/suggestions) to ask people to break in to small work groups to >work on cleaning up each statement or series of statements for futher >review by the whole group. > >I plan on assign (for lack of a better way) certain people the >responsibility for specific statments and let people communicate directly >with them (not the entire group) to reduce traffic and allow multiple >efforts to run at the same time. After they have completed the work the >whole group would review and approve the statements. > >If you wish wish to be responsible for one or more of the statements, those >in "Statement Summary #5" or do NOT wish to be responsible for any of the >statements please let me know soonest. > >Later....Rik > > > > From owner-ietf-ediint Thu Feb 22 08:52:37 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id IAA11530 for ietf-ediint-bks; Thu, 22 Feb 1996 08:52:37 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id IAA11522 for ; Thu, 22 Feb 1996 08:52:28 -0800 (PST) Received: from [199.184.212.105] (turnpike06.onramp.net [199.184.212.105]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA01441 for ; Thu, 22 Feb 1996 11:00:11 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Feb 1996 11:06:45 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Statement Summary #6 Sender: owner-ietf-ediint@imc.org Precedence: bulk **new**ISSUE: We should use the X.435 NRR, NRO, integrity, secrecy and such as the basis for part of our functionality requirements. **new**REQUIREMENT : Delivery notification. **new**ISSUE : Currently, you can get from a VAN separate sets of messages denoting message delivery, in advance of a 997. Given that ISPs do not have the management software to provide similar support, it might be advisable for IETF-EDI to be aware of and perhaps integrate the notification work now going on Title : An Extensible Message Format for Delivery Status Notifications Author(s) : K. Moore, G. Vaudreuil Filename : draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 **new**REQUIREMENT : WWW - HTML Integration with EDI **new**ISSUE : As electronic commerce expands across the Internet, there could be ways to ease that expansion through support of smoother integration paths between the WWW's HTML pages and EDI messages. This has been bounced around in the EDI-L list and could assist the fulfilment process that site's need to execute. **new**REQUIREMENT : EDI via secure FTP **new**ISSUE : As Wal-Mart does in the direct dial world, there will be companies who wish to have their trading partners access a server for requesting EDI messages or sending EDI messages. Are there issues IETF-EDI needs to address in this area ? ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI Internet messages we may send? Will file size impact transportablitity, ability to send/receive, depandability etc. ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be assured that the purported original signatory of the message is the entity that actually sent (?) the message. REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured that the message arrived in its "pure" and original state, i.e., was not modified by having data added, deleted, or changed along the way. ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + Integrity = NRO ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. ISSUE: Key Management - Use of public-key cryptography for key management. Very much like the Standard Encryption Scheme issue, we must recommend the algorithms and existing standards that EDI over the Internet will use for key management. ISSUE: Authentication - Use of digital signatures for authenticating EDI inter- changes. Again we must recommend the digital signature algorithms, hash functions and key lengths to be used for EDI over the Internet. ISSUE: Non-repudiation of origin - Use of digital signatures for non-repudiation of origin. Recommend the digital signature algorithms, hash functions, and key lengths to be used for EDI over the Internet. ISSUE: Non-repudiation of receipt - I agree with much of the discussion that has already taken place but would add these additional topics. Will the specifications that we come up with address only the non-repudiation of receipt of the e-mail message, or of each of the contents that are contained in a mime-message of which EDI could be one of many. Do we allow in our specification, security services to be applied to groups of documents in an interchange, or to individual documents within the interchange. Some businesses may want to send out an EDI Interchange consisting of many types of documents, only some of which need security applied to them. In this type of scenario the non-repudiation of receipt needs to be at a much more granular level then at an e-mail or even interchange level. ISSUE: I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the net included in our discussion or just traditional EDI? ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. ACTION ITEM - we can use from the current Templar pilot to add to our document, i.e. can we leverage any of their efforts? ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standands for use in EDI over Internet. ISSUE - WORLDWIDE ENCRYPTION - The choosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. ISSUE - Dont duplicate what is already provided within the EDI standards. **new**ISSUE - encrypted tunnels - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves interwork. From owner-ietf-ediint Thu Feb 22 18:31:35 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.3/8.7.1) id SAA14026 for ietf-ediint-bks; Thu, 22 Feb 1996 18:31:35 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.3/8.7.1) with ESMTP id SAA14021 for ; Thu, 22 Feb 1996 18:31:33 -0800 (PST) Received: from [199.184.212.159] (turnpike60.onramp.net [199.184.212.159]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id UAA29833 for ; Thu, 22 Feb 1996 20:39:22 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 Feb 1996 20:45:53 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk Below are the statements you submitted in logical groups. They are yet unedited. Next we will edit them and make them more concise and then we will vote to see which are the most important... Thanks for all your effort Later...Rik --- General Comments Section--- 01 ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the existing encryption standards for use in EDI over Internet. 02 ISSUE - WORLDWIDE ENCRYPTION - The chosen encryption scheme(s) must work across the world and not be limited by the export (or legal) restrictions of any nation. 03 ISSUE - DON'T DUPLICATE EXISTNG FUNCITONALITY -Don't duplicate what is already provided within the EDI standards. 04 ACTION ITEM - See what we can use from the current Templar pilot to add to our document, i.e. can we leverage any of their efforts? ----Message Security Section --- 05 ISSUE: Authentication - Use of digital signatures for authenticating EDI inter- changes. Again we must recommend the digital signature algorithms, hash functions and key lengths to be used for EDI over the Internet. 06 REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be assured that the purported original signatory of the message is the entity that actually sent (?) the message. 07 ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. 08 REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured that the message arrived in its "pure" and original state, i.e., was not modified by having data added, deleted, or changed along the way. 09 REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME including the ISA segment using an existing encryption standard or combination of standards such as PGP, DES, MOSS or S/MIME. 10 ISSUE: Non-repudiation of origin - Use of digital signatures for non-repudiation of origin. Recommend the digital signature algorithms, hash functions, and key lengths to be used for EDI over the Internet. 11 ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + Integrity = NRO 12 ISSUE: Key Management - Use of public-key cryptography for key management. Very much like the Standard Encryption Scheme issue, we must recommend the algorithms and existing standards that EDI over the Internet will use for key management. 13 REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains the digital signature of the EDI message; also, the acknowledgment is digitally signed by the receiver of the EDI message. 14 ISSUE: Non-repudiation of receipt - I agree with much of the discussion that has already taken place but would add these additional topics. Will the specifications that we come up with address only the non-repudiation of receipt of the e-mail message, or of each of the contents that are contained in a mime-message of which EDI could be one of many. Do we allow in our specification, security services to be applied to groups of documents in an interchange, or to individual documents within the interchange. Some businesses may want to send out an EDI Interchange consisting of many types of documents, only some of which need security applied to them. In this type of scenario the non-repudiation of receipt needs to be at a much more granular level then at an e-mail or even interchange level. ----Non Message Security Section---- 15REQUIREMENT : Delivery notification. 16 REQUIREMENT : WWW - HTML Integration with EDI 17 ISSUE : Currently, you can get from a VAN separate sets of messages denoting message delivery, in advance of a 997. Given that ISPs do not have the management software to provide similar support, it might be advisable for IETF-EDI to be aware of and perhaps integrate the notification work now going on Title : An Extensible Message Format for Delivery Status Notifications Author(s) : K. Moore, G. Vaudreuil Filename : draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 18 REQUIREMENT : EDI via secure FTP 19 ISSUE : As electronic commerce expands across the Internet, there could be ways to ease that expansion through support of smoother integration paths between the WWW's HTML pages and EDI messages. This has been bounced around in the EDI-L list and could assist the fulfillment process that site's need to execute. 20 ISSUE : As Wal-Mart does in the direct dial world, there will be companies who wish to have their trading partners access a server for requesting EDI messages or sending EDI messages. Are there issues IETF-EDI needs to address in this area ? 21 REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the net included in our discussion or just traditional EDI? 22 ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI Internet messages we may send? Will file size impact transportability, ability to send/receive, dependability etc. 23 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES - EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. 24 ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? 25 ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. 26 ISSUE: I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? 27 ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. 28 ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. 29 ISSUE - ENCRYPTED TUNNELS - We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves inter network. ----Other Section--- 30 ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? From owner-ietf-ediint Sat Feb 24 15:48:19 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id PAA28517 for ietf-ediint-bks; Sat, 24 Feb 1996 15:48:19 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.imc.org (8.7.3/8.7.1) with SMTP id PAA28512 for ; Sat, 24 Feb 1996 15:48:16 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA03850 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Sat, 24 Feb 1996 15:56:20 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA07881; Sat, 24 Feb 96 15:48:52 PST Date: Sat, 24 Feb 96 15:48:52 PST From: carl@chage.com (Carl Hage) Message-Id: <9602242348.AA07881@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk Hello everyone. Some snafu occurred the two times I subscribed before with the mail system. Unfortunately my timeout for retry was several days. Ironic, that the only known time my incoming mail has had a problem was signing up for this list. Arggh! After spending an hour and a half writing a reply, I accidently quit my email instead of sending it, deleting my work. Now I'm rewriting it all. :-( I read the archive of email and will comment in bulk below, listed by issue. One question I have concerns the scope of this effort. It seems to me the main issue is with how to integrate internet messaging with EDI application systems. Here "EDI" means X12 and EDIFACT (the MIME-EDI defined types), but could apply to other future formats with similar characteristics. I think there are two kinds of information that is needed. One is a definition of the specifications specific to EDI messaging, and another is indicating which other RFCs, etc. apply to the process. Is it OK to mix new specifications and requirements with some tutorial and references in a single RFC? I think it is useful to condsider two types of EDI message, a TP-TP message, and a broadcast (TP-many), e.g. RFQ, CRL, etc. The former would use RFC822 messaging, and possibly a GET/POST from HTTP. (I would not recommend using FTP.) The latter would use news (RFC1036), email list (RFC822), FTP, or HTTP. (What about WAIS, gopher?) Question: What kinds of status and functional acknowledgement might be useful regarding VAN EDI operations, e.g. mapping, translating, re-encrypting, etc.? Would an EDI level functional acknowledgement or status of some sort be appropriate? (new here) REQUIREMENT : Single message for receipt and functional ack It should be possible to use a single reply message which supplies confirmation of delivery, non-repudiation of receipt, and a functional acknowledgement of delivery to the EDI application. This is mainly an efficiecy issue. The spec should define the appropriate method of packaging a mailer receipt with the EDI application 997, TA1 or equivalent receipt. This way, a single receipt will suffice for a single EDI message transmission. Question: could/should a receipt be bundled with another message? (new here) ISSUE : Use of RFC822 Subject: and Message-Id: headers For convienience in managing message transfers across mailers, some standards for using the Subject and Message-Id could make message tracking easier. For example, if the Message-Id and Subject included the ISA13 Interchange Control Number, then finding a message within a mailer would be easier. This would not be mandatory, but if senders do make use of the Subject:, it would be useful to format the header the same way. Another use for the Subject and Message-ID is tracking receipt of a problem when the message passes through proprietary mail gateways. >01 ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the >existing encryption standards for use in EDI over Internet. We should probably select a minimum baseline support for encryption, but should make the encryption extensible so TPs could use other schemes by agreement. For example, the US Air Force might use EDI with a Defense procurement center and might need to use the MSP encruption scheme since that is mandated by law, and hardware encruption is available on a $69 PCMCIA card. MSP is not unlike S/MIME, but uses SKIPJACK and DSS instead of RSA and MD5, with an analogous ASN syntax. See The MIME wrapping structure should be designed so that it is easy for a pair of TPs to incorporate a particular encryption/signature package into the processing system, by agreement. >02 ISSUE - WORLDWIDE ENCRYPTION - The chosen encryption scheme(s) must work >across the world and not be limited by the export (or legal) restrictions >of any nation. Is this possible? >03 ISSUE - DON'T DUPLICATE EXISTNG FUNCITONALITY -Don't duplicate what is >already provided within the EDI standards. What does this mean. Presumably issues like message sequencing are already defined by the EDI protocol itself. >----Message Security Section --- > >05 ISSUE: Authentication - Use of digital signatures for authenticating EDI >inter- changes. Again we must recommend the digital signature algorithms, >hash functions and key lengths to be used for EDI over the Internet. The standard doesn't need to address key length. It doesn't really affect the software or protocol. No matter what one says for a key length, it will be controversial. >06 REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be >assured that the purported original signatory of the message is the entity >that actually sent (?) the message. All digital signatures provide both authentication, non-repudiation of origin, and integrity. >07 ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI >/ MIME / Internet package should implement compatible functionality (or be >easily translatable between) with X.434. > >08 REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured >that the message arrived in its "pure" and original state, i.e., was not >modified by having data added, deleted, or changed along the way. > >09 REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI >transaction within MIME including the ISA segment using an existing >encryption standard or combination of standards such as PGP, DES, MOSS or >S/MIME. > >10 ISSUE: Non-repudiation of origin - Use of digital signatures for >non-repudiation of origin. Recommend the digital signature algorithms, >hash functions, and key lengths to be used for EDI over the Internet. > >11 ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + >Integrity = NRO Not a requirement, this is a statement that the requirements above mean the same thing. >12 ISSUE: Key Management - Use of public-key cryptography for key >management. Very much like the Standard Encryption Scheme issue, we must >recommend the algorithms and existing standards that EDI over the Internet >will use for key management. There are basically two ways that might be used to address key management, using a certificate signed by a CA (suitable for anonymous introductions), or else using keys or self signed certifcates authenticated by the TPs themselves as part of an TP interchange agreement. In the latter case, the keys and/or certificates would be exchanged via email, finger, HTTP, etc. and authenticated by a separate phone call or as part of the TP agreement. To give a digital signature full legal status, a paper based TP agreement can include the certificate/key with a statement that a TP intends to use digital signatures produced using the key in leiu of a handwritten symbol. >13 REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message >obtains undeniable proof that the recipient received the message and the >message was not altered in transit. Non-repudiation of receipt is >implemented via an acknowledgment; the recipient of an EDI message returns >this acknowledgment to the sender of the EDI message. This acknowledgment >contains the digital signature of the EDI message; also, the acknowledgment >is digitally signed by the receiver of the EDI message. A Message Delivery Notice, e.g. from RFC1894, digitally signed, provides non repudiation, but only if either the original message is included, the original signature is included (e.g. RFC1848 MIC-Info:), or a one way hash "fingerprint" (e.g. MD5) is included. For some encryption/signature algorithms, extracting the signature might be difficult, since binary data may need to be parsed, and the encryption software might not have an option to extract the signature from the encoded data. Thus using a separate one way hash might be more convientient and independent of the encryption algorithm. There is a new header in the new HTTP draft and in a separate draft for mime, "Content-MD5:" used for integrity checking: There are a couple on minor problems with the latter, but if the MD5 was included in a message header, then that could simplify the integrity checks, auditing, and would also suffice for non-repudiation. An RFC1894 notice could include only the message headers with an MD5 and the message contents could be omitted. >14 ISSUE: Non-repudiation of receipt - I agree with much of the discussion >that has already taken place but would add these additional topics. Will >the specifications that we come up with address only the non-repudiation >of receipt of the e-mail message, or of each of the contents that are >contained in a mime-message of which EDI could be one of many. Do we allow >in our specification, security services to be applied to groups of >documents in an interchange, or to individual documents within the >interchange. Some businesses may want to send out an EDI Interchange >consisting of many types of documents, only some of which need security >applied to them. In this type of scenario the non-repudiation of receipt >needs to be at a much more granular level then at an e-mail or even >interchange level. This subject deals with the ordering of the MIME wrappers which combine messages, sign and encrypt, and issue receipts. A receipt at the email or SSL transmission level would provide NRR, but would greatly complicate the logging and auditing process. For convienience, I would suggest that the signature and corresponding receipt apply to a single interchange, which would be kept together within an EDI system log. I think it could be worthwhile to bundle a receipt for NRR and delivery assurance with another interchange. For example, if TPA sends a PO, then TPB might send back a message with a receipt containing the Content-MD5, a 997 functional ack, and a PO ack. TPA would then reply with a receipt for the PO ack interchange. >----Non Message Security Section---- > >15REQUIREMENT : Delivery notification. This is the same as 17. See below for comments., or above for NRR, which also provides Delivery notification. >16 REQUIREMENT : WWW - HTML Integration with EDI The integration with WWW is a pretty wide open opportunity, perhaps constituting many new standards. However, some basic integration standards with existing EDI messaging might be suitable for the scope of this work. For example, RFQs could be posted on a HTTP server. SSL servers could be used to post an X12/EDIFACT interchange and download a reply. This is likely a manual process, though, so Ken S. wouldn't call it EDI. ;) I still think general purpose SMTP exchanges are better than the more specialized HHTP for fully automated transactions. In my opinion, linking human-machine interaction on the WWW with EDI is beyond the scope of this initial effort at standardizing the process of internet based messaging for traditional EDI. It's useful, but we don't need to delay an RFC till this topic is addressed. >17 ISSUE : Currently, you can get from a VAN separate sets of messages >denoting message delivery, in advance of a 997. Given that ISPs do not have >the management software to provide similar support, it might be advisable >for IETF-EDI to be aware of and perhaps integrate the notification work now >going on Title : An Extensible Message Format for Delivery Status >Notifications Author(s) : K. Moore, G. Vaudreuil Filename : >draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 This is now . There are also some related RFCs: The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages Enhanced Mail System Status Codes An Extensible Message Format for Message Disposition Notifications See above for a couple of issues related to RFC1894. >18 REQUIREMENT : EDI via secure FTP FTP would be useful to post RFQs, CRLs, etc. with 1-many or many-many distribution. Howver, those people who use FTP for TP-TP EDI messaging would be better off switching to SMTP for a variety of reasons. >19 ISSUE : As electronic commerce expands across the Internet, there could >be ways to ease that expansion through support of smoother integration >paths between the WWW's HTML pages and EDI messages. This has been bounced >around in the EDI-L list and could assist the fulfillment process that >site's need to execute. See above comments under WWW. >20 ISSUE : As Wal-Mart does in the direct dial world, there will be >companies who wish to have their trading partners access a server for >requesting EDI messages or sending EDI messages. Are there issues IETF-EDI >needs to address in this area ? Corporations using (offering) direct dial messaging could use standard Internet protocols, and in turn standard software. The IETF standards supporting security, integrity, reliability, and interoperability would also address these needs in private or direct dial networks. >21 REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the net >included in our discussion or just traditional EDI? For the funds transfers which behave like EDI messaging (TP-TP exchange), then it seems like the security, integrity, reliability, NRO/NRR, etc. for EDI could apply to payment messages. Some payment protocols don't have the simple EDI-like TP-TP messaging architecture, since there are 3 or 4 parties involved (customer, merchant, bank, payment-gateway) sometimes with complex interaction. Note the new MasterCard/VISA grand unified theory, called "Secure Electronic Transaction" (SET) has just come out, . SET and the defunct STTS introduce "dual signatures", which is a way to bundle signatures of two private messages, one to the merchant and one to the bank, into a combined bundled signature. It might be worth considering this architecture for the Internet-EDI spec. >22 ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI >Internet messages we may send? Will file size impact transportability, >ability to send/receive, dependability etc. This is already solved by RFC1521, Content-Type : Message/Partial. We simply need to specify that this standard will be used when messages are too large. Also, it may be useful to suggest that a ", Part nn/mm" suffix be appended to the Subject: line when splitting a message. An intermediate mailer could split a message according to RFC1521, and another could glue it back together. TPs might impose limits to prevent attacks by filling up the disk space. >23 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE >MESSAGES - EDI users need an automated means to detect missing, duplicate >or out-of-sequence messages, where the sequencing problem is caused by the >communications layer (e.g., the Internet e-mail software) or the security >layer. Sequence problems caused by the business application or the EDI >translator are not within the scope of this requirement. This feature is >normally provided by the EDI translator that verifies that the interchange >control numbers (ICNs) are received in the correct sequence. If this >feature was provided by a layer below the EDI translator (e.g., the >security layer or the communications layer), then it could be used by >e-mail users, proprietary EDI applications that don't use an EDI >translator, and EDI applications where one of the trading partner's has a >translator that does not validate ICN sequencing. This is the same as 27 below. >24 ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? There are a couple of ways to add it. One is to extend the MIME Content-Type: to include a compression method, e.g. EDI-X12-gzip. The HTTP draft spec adds some headers that would be useful for MIME in general, one of which is Content-Encoding: "gzip" | "compress" | token SSL include a compression_method but doesn't define the constants. >25 ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where >the sender's system breaks up a large EDI interchange into a series of >small messages and the recipient's system recombines the small messages? >Apparently, some Internet e-mail systems have a maximum message size limit >of 50KB. PGP provides segmentation. So does Premenos's Templar product. This the same as MESSAGE FILE SIZE above. >26 ISSUE: I think the thread of this has been touched upon on Interchange >sequence numbers, but what additional management constructs do we need to >come up with when doing EDI over the Internet. For instance, today if two >EDI Interchanges are sent through a VAN with control numbers, and one of >them does not arrive at the receiver, the receiver can call the VAN and >attempt to trace it. What mechanisms would the receiver use in this >scenario when sending EDI over the Internet? One thing that would simplify the tracking of messages through mailers, ateways, and networks, is to use some standards for the Message-Id: and Subject: headings, where the ICN can be included. This may also simplify some logging and auditing issues. >27 ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee >message sequence integrity. In other words, message N+1 may be delivered >before message N. Some EDI VANs provide message sequence integrity. There >are probably some EDI applications that require message sequence integrity. The sequence should be enforced by the receiving EDI system, not the mailer. (It's built into X12 and EDIFACT.) However, the message sequence number can be useful for tracking messages through mailers. >28 ISSUE - MESSAGE SEQUENCING -Let's make sure that we don't impose >controls at the communications layer which are not in place in the >underlying EDI standards. Message sequence integrity is a trading partner >dependent issue. If the issuer of the interchange control numbers uses any >other scheme than sequential numbers by trading partner, checking for this >at the communications layer could cause more problems than it solves. See above. In case a message is split and recombined (Content-Type: message/partial), then the recombining mailer of course sequences the parts to reconstruct. Other than this, sequencing is controlled by the EDI application, or front end. >29 ISSUE - ENCRYPTED TUNNELS - We should take into account any >current/future work that is going on to standardize encrypted tunnels. They >may provide a useful mechanism for providing security at the communications >layer. Yes, I am talking about encryption at the packet level. I guess that >this really depends on the outcome of the standardization work for tunnels. >We would need to adopt these standards to ensure that tunnels themselves >inter network. If secure TCP/IP channels are available, then message encryption is not needed, however, signatures might be important for nonrepudiation. SSL provides exchange of signatures upon termination that provide nonrepudiation, but using the communications layer security complicates the logging and auditing process. BTW, it is possible to simply use SSL to exchange EDI interchange messages directly without any wrapping. A TP would connect a socket to the other TP's EDI port and simply send bytes starting with the ISA, etc. This would only work if at least one TP has a dedicated internet connection, and the other has a SLIP/PPP connection. SSL could also be used to communicate with a VAN. An SSL interchange would probably have a different signature value than would apply to a RFC822-MIME message, so converting SSL through a gateway or VAN would be problematic. On the other hand SSL can be pretty darn simple, since there is a direct secure link between the EDI translators at each TP without any intervening software. The IETF-EDI group could register a port number for SSL X12/EDIFACT messaging. ----Other Section--- > >30 ISSUE - TRANSPORT ONLY - a single interchange is the smallest entity >that can be transported via the Internet. The definition of an interchange >for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by >the relevant standards, and should be defined between trading partners who >choose to use the Application/EDI-Consent MIME type. Can multiple >interchanges be transported in a single MIME envelope, or can only a single >interchange be contained in a single MIME envelope ? Probably the main issue here is with non-repudiation and signatures, and the corresponding logging and auditing process. If messages are bundled, then there is no longer a correspondence between interchanges, signatures, and receipts, depending on the MIME wrapping order. There also might be a lack of correspondence between Message-ID and ICN, complicating the message tracking. MIME does allow combinations of messages with the multipart/mixed and multipart/digest. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Mon Feb 26 06:36:27 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id GAA10287 for ietf-ediint-bks; Mon, 26 Feb 1996 06:36:27 -0800 (PST) Received: from mwunix.mitre.org (mwunix.mitre.org [128.29.154.1]) by imc.imc.org (8.7.3/8.7.1) with SMTP id GAA10282 for ; Mon, 26 Feb 1996 06:36:21 -0800 (PST) Received: from tgate1 (tgate1.mitre.org [128.29.154.210]) by mwunix.mitre.org (8.6.10/8.6.4) with SMTP id JAA14452; Mon, 26 Feb 1996 09:44:22 -0500 Received: from mail06.mitre.org (128.29.250.7) by tgate1.mitre.org (EMWAC SMTPRS 0.60) with SMTP id ; Mon, 26 Feb 1996 09:44:08 -0500 Received: by mail06.mitre.org; (5.65 EXP 2/15/95/1.1.8.2/22Jun94-0628PM) id AA32703; Mon, 26 Feb 1996 09:44:17 -0500 Subject: Re: ** Statement Summary #7 - Final From: clueder@mail06.mitre.org (Christopher J. Kit Lueder) To: carl@chage.com (Carl Hage), ietf-ediint@imc.org Message-Id: <960226094413.16238@mail06.mitre.org.0> Date: Mon, 26 Feb 96 09:44:16 -0500 X-Mailer: MAILworks 1.7-A-1 Sender: owner-ietf-ediint@imc.org Precedence: bulk Hi Carl, > The list has the following statement: >>06 REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be >>assured that the purported original signatory of the message is the entity >>that actually sent (?) the message. > and Carl comments: >All digital signatures provide both authentication, non-repudiation >of origin, and integrity. I think you are oversimplifying this, or assuming that public keys are used. You can provide integrity and authentication of origin without providing non-repudiation of origin, by using DES (Data Encryption Standard) Secret key to encrypt the token. That does not constitute a signature. Why would you do that? Because DES is simple to implement, free, fast algorithm, keys are trivial to generate, and you don't need a supporting infrastructure (just exchange a secret key with each trading partner). And it has never been broken, which is more than can be said for the private key approaches (the Internet was used to factor a large public key into its two prime numbers in just seven months, or less--I forget). From owner-ietf-ediint Mon Feb 26 10:35:51 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id KAA11432 for ietf-ediint-bks; Mon, 26 Feb 1996 10:35:51 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.imc.org (8.7.3/8.7.1) with SMTP id KAA11427 for ; Mon, 26 Feb 1996 10:35:49 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA00182 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Mon, 26 Feb 1996 10:43:54 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA01488; Mon, 26 Feb 96 10:07:50 PST Date: Mon, 26 Feb 96 10:07:50 PST From: carl@chage.com (Carl Hage) Message-Id: <9602261807.AA01488@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk >From clueder@mail06.mitre.org Mon Feb 26 09:14:36 1996 >> and Carl comments: >>All digital signatures provide both authentication, non-repudiation >>of origin, and integrity. > >I think you are oversimplifying this, or assuming that public keys are used. Sorry, I'm assuming public keys are used. All the digital signature algorithms that I know of use public keys. >You can provide integrity and authentication of origin without providing >non-repudiation of origin, by using DES (Data Encryption Standard) Secret key >to encrypt the token. DES only provides privacy. There is no integrity check, since DES decryption alone doesn't protect against errors. It doesn't authenticate the origin, since someone within your company could send a forged message to itself. > That does not constitute a signature. Why would you do >that? Because DES is simple to implement, free, fast algorithm, keys are >trivial to generate, and you don't need a supporting infrastructure (just >exchange a secret key with each trading partner). And it has never been >broken, But secret keys are easily stolen. With a hardware encryption card, the private keys are buried in a chip and can't be extracted, even by people who posess the card. > which is more than can be said for the private key approaches (the >Internet was used to factor a large public key into its two prime numbers in >just seven months, or less--I forget). Actually, that was a small key (much smaller than the keys normally used). The export laws greatly reduce the length of the keys so that the NSA can break them. Of course such a key can be broken, since that's the purpose of the length limit. To get around the export restrictions, the key used to sign can be longer than the key used to encrypt for privacy. One important feature of public keys, is that the certificate process can be used to authenticate an arbitrary signature. This will be critical in Electronic Commerce, where retail stores do business on the net. Actually, MOSS (from tis.com) is free for email-only use. At the Email/WWW Internet expo in San Jose last week, the US Post Office was there and said they will be issuing X.509 certificates starting (or announcing?) in April. That should make certificates easy to get. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Tue Feb 27 21:07:11 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id VAA02479 for ietf-ediint-bks; Tue, 27 Feb 1996 21:07:11 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.imc.org (8.7.4/8.7.1) with SMTP id VAA02474 for ; Tue, 27 Feb 1996 21:07:01 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA09974; Wed, 28 Feb 1996 00:12:14 -0500 Message-Id: <2.2.32.19960228051146.007043f0@pop3.interlink.net> X-Sender: epmck@pop3.interlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Feb 1996 00:11:46 -0500 To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org From: "E. Peter McKinney, CA" Subject: Re: ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk Rik, My comments were not general in nature. I submitted the comments and the Statement Summary # 7 got them out of sequence. In order to discuss them properly, they need to be re-ordered. Thanks Peter At 07:45 AM 2/26/96 +0100, you wrote: >Thank you for your comments. I know some need to be combined and other edited. The list is currently those that people submitted --uneditied...We should have thes cleaned up in 10 days or so....later....rik > > > >>At 08:45 PM 2/22/96 -0600, you wrote: >>>Below are the statements you submitted in logical groups. They are yet >>>unedited. Next we will edit them and make them more concise and then we >>>will vote to see which are the most important... >>> >>>Thanks for all your effort >>> >>>Later...Rik >>> >>Rik, >> >>You got some out of sequence. >> >>15 and 17 go together >> >>16 & 19 go together >> >>18 and 20 go together >> >>Thanks >> >>Peter > > > > From owner-ietf-ediint Wed Feb 28 04:46:46 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id EAA05767 for ietf-ediint-bks; Wed, 28 Feb 1996 04:46:46 -0800 (PST) Received: from ns2.indirect.com (root@ns2.indirect.com [165.247.1.17]) by imc.imc.org (8.7.4/8.7.1) with SMTP id EAA05762 for ; Wed, 28 Feb 1996 04:46:45 -0800 (PST) Received: from dave_d.indirect.com (s95.phxslip4.indirect.com [165.247.24.95]) by ns2.indirect.com (8.6.12/8.6.6) with SMTP id FAA19928; Wed, 28 Feb 1996 05:55:01 -0700 Message-Id: <2.2.32.19960228125547.006e9fc0@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Feb 1996 05:55:47 -0700 To: carl@chage.com (Carl Hage), ietf-ediint@imc.org From: Dave Darnell Subject: Re: ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk At 10:07 AM 2/26/96 PST, Carl Hage wrote: >One important feature of public keys, is that the certificate process >can be used to authenticate an arbitrary signature. This will be critical >in Electronic Commerce, where retail stores do business on the net. > > I agree with Carl. Public key cryptosystems are the way to go if we want EDI to become ubiquitous and easy to implement as other technologies (fax, telephone,etc) Of course the underlying technologies are difficult to understand and explain, but this could be hidden by easy to use software (e.g. a picture of a trash can on a Mac screen or recycle bin on WIn95 is easy to understand - how a disk drive works and responds to operating system commands is another matter). Going to DES would be a great step backward - we want to minimize the amount of contact necessary with potential trading partners - not increase it. With a public key infrastructure we simply have to "grab" the public key of our potential trading partner off a key server. If an entity like the US Post Office or Verisign has "countersigned" the public key as the authentic public key of the indicated trading partner, then we have a high level of assurance we will be sending encrypted transactions that can only be decrypted by who we want them to be. We must keep in mind that Internet EDI will be successful only if easy to use and implement security schemes are available. I would like to see this group come up with recommendations that are especially applicable to the small and medium enterprises (SME's) who do not have large staffs specializing in EDI or DP or IT . >At the Email/WWW Internet expo in San Jose last week, the US Post Office >was there and said they will be issuing X.509 certificates starting >(or announcing?) in April. That should make certificates easy to get. This sounds good if they can implement an easy to use system on the WWW. I believe Verisign has done this. Any word on exactly how we register our public keys with the US Post Office? We don't have to go down to our local office and take a number, do we :-) ??? Regards, Dave ====================================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8032 | mailto://dave_d@systrends.com ====================================== From owner-ietf-ediint Wed Feb 28 08:32:49 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id IAA06751 for ietf-ediint-bks; Wed, 28 Feb 1996 08:32:49 -0800 (PST) Received: from relay-2.mail.demon.net (disperse.demon.co.uk [158.152.1.77]) by imc.imc.org (8.7.4/8.7.1) with SMTP id IAA06746 for ; Wed, 28 Feb 1996 08:32:46 -0800 (PST) Received: from post.demon.co.uk ([158.152.1.72]) by relay-2.mail.demon.net id aa17564; 28 Feb 96 14:16 GMT Received: from mirror.demon.co.uk ([158.152.45.217]) by relay-3.mail.demon.net id aa09294; 28 Feb 96 14:13 GMT Received: by mirror.demon.co.uk (Linux Smail3.1.28.1 #5) id m0trmdQ-00036xC; Wed, 28 Feb 96 14:13 GMT Message-Id: From: Jonathan Allen Subject: Re: ** Statement Summary #7 - Final To: Dave Darnell Date: Wed, 28 Feb 1996 14:13:39 +0100 (GMT) Cc: carl@chage.com, ietf-ediint@imc.org In-Reply-To: <2.2.32.19960228125547.006e9fc0@mail.indirect.com> from "Dave Darnell" at Feb 28, 96 05:55:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ietf-ediint@imc.org Precedence: bulk Dave Darnell said: > > Public key cryptosystems are the way to go if we want EDI to become > ubiquitous and easy to implement as other technologies (fax, telephone,etc) With the sole exception that the current flavours of PKCS are proprietory (at least in the commercial arena), I would endorse that too. Dave's comment about the levels of contact between trading partners, and the difficulties of key management should not be underestimated. Sticking with PKCS, now that there will be at least two players in the Certification Authority field, has to be better than looking at DES or any 'secret key' mechanism. Jonathan ------------------------------------------------------------------------------ Jonathan Allen | jonathan@mirror.demon.co.uk | Voice: 01271-79023 Barum Computer Consultants | jeremiah@cix.compulink.co.uk | Fax: 01271-24183 ------------------------------------------------------------------------------ From owner-ietf-ediint Wed Feb 28 09:34:52 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id JAA06998 for ietf-ediint-bks; Wed, 28 Feb 1996 09:34:52 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.4/8.7.1) with ESMTP id JAA06992 for ; Wed, 28 Feb 1996 09:34:48 -0800 (PST) Received: from [199.184.212.136] (turnpike37.onramp.net [199.184.212.136]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA02701 for ; Wed, 28 Feb 1996 11:42:53 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Feb 1996 11:49:19 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: From: Harald.T.Alvestrand ** Statement Summary #7 - Final Sender: owner-ietf-ediint@imc.org Precedence: bulk These are comments from the IETF Area Director under which our workgroup= would operate. His comments are worth reading... My activity on the list is light currently because I am spending time= working the IEFT issues and finding editors to first edit the statements= and second help edit the final paper. Soon as we have commitments we will= move out discussing the statements in detail. Later....Rik --- begin forwarded text =46rom: Harald.T.Alvestrand@uninett.no To: drummond@onramp.net (Rik Drummond) cc: John C Klensin Subject: Re: EDIINT ** Statement Summary #7 - Final MIME-Version: 1.0 Date: Fri, 23 Feb 1996 23:25:43 +0100 Sender: hta@dale.uninett.no Here's my quick and unedited comments to your quick and unedited issues list. Hope you can make use of it! > --- General Comments Section--- > 01 ISSUE - STANDARD ENCRYPTION SCHEME - We must recommend a subset of the > existing encryption standards for use in EDI over Internet. Agreed. MOSS is my recommendation. (NOTE - this may change over time; things are happening quickly. I believe security multiparts is stable, but MOSS might not be.) >=20 > 02 ISSUE - WORLDWIDE ENCRYPTION - The chosen encryption scheme(s) must wor= k > across the world and not be limited by the export (or legal) restrictions > of any nation. This is a "can't do". France has outlawed all encryption unless specifically authorized by the French ministry of security. (It is operated in the "we won't do anything to catch you, but if we need to get you for something, we have you on file" mode, I think) >=20 > 03 ISSUE - DON'T DUPLICATE EXISTNG FUNCITONALITY -Don't duplicate what is > already provided within the EDI standards. Agreed. >=20 > 04 ACTION ITEM - See what we can use from the current Templar pilot to ad= d > to our document, i.e. can we leverage any of their efforts? Details? References? >=20 >=20 > ----Message Security Section --- >=20 > 05 ISSUE: Authentication - Use of digital signatures for authenticating ED= I > inter- changes. Again we must recommend the digital signature algorithms, > hash functions and key lengths to be used for EDI over the Internet. =46ine. I suggest again sticking with MOSS for the basic standard. >=20 > 06 REQUIREMENT - AUTHENTICATION - The receiver of an EDI message can be > assured that the purported original signatory of the message is the entity > that actually sent (?) the message. This means a certificate distribution mechanism, I think. >=20 > 07 ISSUE - COMPATIBILITY WITH X.435 - The functionality chosen for the EDI > / MIME / Internet package should implement compatible functionality (or be > easily translatable between) with X.434. Note that security is VERY hard to gateway. Apart from that - I agree. >=20 > 08 REQUIREMENT - INTEGRITY - The receiver of an EDI message can be assured > that the message arrived in its "pure" and original state, i.e., was not > modified by having data added, deleted, or changed along the way. Already done if you do signatures on the data. >=20 > 09 REQUIREMENT - TRANSACTION PRIVACY - Encryption of the entire EDI > transaction within MIME including the ISA segment using an existing > encryption standard or combination of standards such as PGP, DES, MOSS or > S/MIME. Should be "no problem". Just pick the right standard (MOSS is my opinion) >=20 > 10 ISSUE: Non-repudiation of origin - Use of digital signatures for > non-repudiation of origin. Recommend the digital signature algorithms, > hash functions, and key lengths to be used for EDI over the Internet. As above. You need a certificate hierarchy. >=20 > 11 ISSUE (REQUIREMENT?) - NON-REPUDIATION OF ORIGIN - Authentication + > Integrity =3D NRO I think so. The ABA has a document on these things, I believe. I don't know if it's worth reading. >=20 > 12 ISSUE: Key Management - Use of public-key cryptography for key > management. Very much like the Standard Encryption Scheme issue, we must > recommend the algorithms and existing standards that EDI over the Interne= t > will use for key management. Agreed. I hope we have at least ONE key distribution/authentication mechanism standardized "soon". >=20 > 13 REQUIREMENT - NON-REPUDIATION OF RECEIPT - The sender of an EDI message > obtains undeniable proof that the recipient received the message and the > message was not altered in transit. Non-repudiation of receipt is > implemented via an acknowledgment; the recipient of an EDI message returns > this acknowledgment to the sender of the EDI message. This acknowledgment > contains the digital signature of the EDI message; also, the acknowledgmen= t > is digitally signed by the receiver of the EDI message. Receipt is an issue being worked on in the RECEIPT WG. But it doesn't address your issues. EDI-formatted receipts, digitally signed using MOSS, might be an answer. >=20 > 14 ISSUE: Non-repudiation of receipt - I agree with much of the discussion > that has already taken place but would add these additional topics. Will > the specifications that we come up with address only the non-repudiation > of receipt of the e-mail message, or of each of the contents that are > contained in a mime-message of which EDI could be one of many. Do we allo= w > in our specification, security services to be applied to groups of > documents in an interchange, or to individual documents within the > interchange. Some businesses may want to send out an EDI Interchange > consisting of many types of documents, only some of which need security > applied to them. In this type of scenario the non-repudiation of receipt > needs to be at a much more granular level then at an e-mail or even > interchange level. This gets so far away from the mail model that it's an argument for going with EDI-format receipts. >=20 >=20 > ----Non Message Security Section---- >=20 > 15REQUIREMENT : Delivery notification. Covered by the NOTARY standard, if we agree on the term "delivery". >=20 > 16 REQUIREMENT : WWW - HTML Integration with EDI Ouch! >=20 > 17 ISSUE : Currently, you can get from a VAN separate sets of messages > denoting message delivery, in advance of a 997. Given that ISPs do not hav= e > the management software to provide similar support, it might be advisable > for IETF-EDI to be aware of and perhaps integrate the notification work no= w > going on Title : An Extensible Message Format for Delivery Status > Notifications Author(s) : K. Moore, G. Vaudreuil Filename : > draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 This is now an RFC (one of a set of four). RFC 1891-1894. >=20 > 18 REQUIREMENT : EDI via secure FTP Not My Problem, I hope. >=20 > 19 ISSUE : As electronic commerce expands across the Internet, there coul= d > be ways to ease that expansion through support of smoother integration > paths between the WWW's HTML pages and EDI messages. This has been bounced > around in the EDI-L list and could assist the fulfillment process that > site's need to execute. Not something I'd spend much time on before the basic transport is OK. >=20 > 20 ISSUE : As Wal-Mart does in the direct dial world, there will be > companies who wish to have their trading partners access a server for > requesting EDI messages or sending EDI messages. Are there issues IETF-EDI > needs to address in this area ? > 21 REQUIEMENT - FUNDS TRANSER - Is the topic of funds transfer over the ne= t > included in our discussion or just traditional EDI? >=20 > 22 ISSUE - MESSAGE FILE SIZE - Are there any limits to the size of EDI > Internet messages we may send? Will file size impact transportability, > ability to send/receive, dependability etc. I regularly send and receive megabyte messages. If your disk is large enough and your line fast enough, I don't believe the Internet protocols will give you any problem. >=20 > 23 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE > MESSAGES - EDI users need an automated means to detect missing, duplicate > or out-of-sequence messages, where the sequencing problem is caused by the > communications layer (e.g., the Internet e-mail software) or the security > layer. Sequence problems caused by the business application or the EDI > translator are not within the scope of this requirement. This feature is > normally provided by the EDI translator that verifies that the interchange > control numbers (ICNs) are received in the correct sequence. If this > feature was provided by a layer below the EDI translator (e.g., the > security layer or the communications layer), then it could be used by > e-mail users, proprietary EDI applications that don't use an EDI > translator, and EDI applications where one of the trading partner's has a > translator that does not validate ICN sequencing. Are you arguing for putting a sequence number into the MIME headers? If so, that should be relatively easy. >=20 > 24 ISSUE - MESSAGE FILE COMPRESSION - What is the standard? Will we use it? I hope there will be a standard soon (months), based on L. Peter Deutsch' DEFLATE specifications. At the moment, there isn't one. >=20 > 25 ISSUE - SEGEMENTATION - Is there a requirement for segmentation, where > the sender's system breaks up a large EDI interchange into a series of > small messages and the recipient's system recombines the small messages? > Apparently, some Internet e-mail systems have a maximum message size limit > of 50KB. PGP provides segmentation. So does Premenos's Templar product. Also specified in the MIME standard. Look for message/partial in the spec. >=20 > 26 ISSUE: I think the thread of this has been touched upon on Interchange > sequence numbers, but what additional management constructs do we need to > come up with when doing EDI over the Internet. For instance, today if two > EDI Interchanges are sent through a VAN with control numbers, and one of > them does not arrive at the receiver, the receiver can call the VAN and > attempt to trace it. What mechanisms would the receiver use in this > scenario when sending EDI over the Internet? I can't help you define this :-) >=20 > 27 ISSUE - MESSAGE SEQUENCE INTEGRITY - Internet e-mail does not guarantee > message sequence integrity. In other words, message N+1 may be delivered > before message N. Some EDI VANs provide message sequence integrity. There > are probably some EDI applications that require message sequence integrity= From owner-ietf-ediint Thu Feb 29 04:25:28 1996 Received: (from majordomo@localhost) by imc.imc.org (8.7.4/8.7.1) id EAA04739 for ietf-ediint-bks; Thu, 29 Feb 1996 04:25:28 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.imc.org (8.7.4/8.7.1) with ESMTP id EAA04734 for ; Thu, 29 Feb 1996 04:25:26 -0800 (PST) Received: from [199.184.212.178] (stockyard15.onramp.net [199.184.212.178]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id GAA29952 for ; Thu, 29 Feb 1996 06:33:46 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Feb 1996 06:40:14 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** EDIWorld Column Sender: owner-ietf-ediint@imc.org Precedence: bulk My April EDIWorld Column will discuss this effort. It should get more= attention. The column will not appear until after the first milestone is= due -- the outline of the paper. Chuck...I put your name in column as the= editor. Others had not committed at that time. I am working the issues on taking this effort from a BOF (birds of a= feather) to a Workgroup. The ietf area director is interested... Later...Rik From owner-ietf-ediint Mon Mar 4 19:46:53 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id TAA00753 for ietf-ediint-bks; Mon, 4 Mar 1996 19:46:53 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.org (8.7.4/8.7.1) with SMTP id TAA00748 for ; Mon, 4 Mar 1996 19:46:51 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA08683; Mon, 4 Mar 1996 22:52:24 -0500 Message-Id: <2.2.32.19960305035121.006e5d6c@pop3.interlink.net> X-Sender: epmck@pop3.interlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 1996 22:51:21 -0500 To: drummond@onramp.net (Rik Drummond) From: "E. Peter McKinney, CA" Subject: Re: ** Statement Summary #7 - Final Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Rik, You said that you did not see what my editorial comment meant, so I have re-arranged the paragraphs for you to be more clear. Cheers Peter >----Non Message Security Section---- > >15REQUIREMENT : Delivery notification. >17 ISSUE : Currently, you can get from a VAN separate sets of messages >denoting message delivery, in advance of a 997. Given that ISPs do not have >the management software to provide similar support, it might be advisable >for IETF-EDI to be aware of and perhaps integrate the notification work now >going on Title : An Extensible Message Format for Delivery Status >Notifications Author(s) : K. Moore, G. Vaudreuil Filename : >draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 > > >16 REQUIREMENT : WWW - HTML Integration with EDI >19 ISSUE : As electronic commerce expands across the Internet, there could >be ways to ease that expansion through support of smoother integration >paths between the WWW's HTML pages and EDI messages. This has been bounced >around in the EDI-L list and could assist the fulfillment process that >site's need to execute. > > >18 REQUIREMENT : EDI via secure FTP > >20 ISSUE : As Wal-Mart does in the direct dial world, there will be >companies who wish to have their trading partners access a server for >requesting EDI messages or sending EDI messages. Are there issues IETF-EDI >needs to address in this area ? ============================= E. Peter McKinney, CA McKInney, Paul & Assoc. Inc. An Information Systems and EDI/EC Consultancy Montreal, Canada [Tel: 514-852-4497 Fax: 514-329-0494] From owner-ietf-ediint Tue Mar 5 11:25:52 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id LAA01202 for ietf-ediint-bks; Tue, 5 Mar 1996 11:25:52 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.org (8.7.4/8.7.1) with SMTP id LAA01197 for ; Tue, 5 Mar 1996 11:25:48 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA08586 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Tue, 5 Mar 1996 11:34:31 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA04948; Tue, 5 Mar 96 09:43:49 PST Newsgroups: lists.ietf-ediint Path: carl From: carl@chage.com (Carl Hage) Subject: Re: ** Statement Summary #7 - Final Message-Id: <+-0h#vl+@chage.com> Date: Tue, 05 Mar 96 17:43:42 GMT Organization: C. Hage Associates, Sunnyvale, CA References: <2.2.32.19960305035121.006e5d6c@pop3.interlink.net> Apparently-To: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk epmck@ns.RezoNet.NET ("E. Peter McKinney, CA") writes: : > : >18 REQUIREMENT : EDI via secure FTP : > : >20 ISSUE : As Wal-Mart does in the direct dial world, there will be : >companies who wish to have their trading partners access a server for : >requesting EDI messages or sending EDI messages. Are there issues IETF-EDI : >needs to address in this area ? What do you mean by this? What kind of messages are exchanged this way? What is meant by "access a server"? If the purpose is to bypass a VAN/ISP with direct dial or telnet access, then SMTP/POP3 protocols can be used to retrieve and post messages (with PPP for direct dial). However, I really don't see a reason to do this. It seems better to use a standard mailer interface for messaging (either direct or forwarded) rather than having multiple protocols which are used for one TP-TP message transfer. Perhaps Wal-Mart (or a VAN) keeps a log of messages in an FTP directory. Then a standard format definition for these logs might be appropriate. Perhaps a list of RFQs are placed in a file system directory. Then a standard way of posting them would be useful. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Tue Mar 5 15:20:35 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id PAA02158 for ietf-ediint-bks; Tue, 5 Mar 1996 15:20:35 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id PAA02153 for ; Tue, 5 Mar 1996 15:20:26 -0800 (PST) Received: from [199.184.212.108] (turnpike09.onramp.net [199.184.212.108]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id RAA15730 for ; Tue, 5 Mar 1996 17:29:00 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Mar 1996 17:35:44 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: * Status or EDI over Internet WG - EDIINT Sender: owner-ietf-ediint@imc.org Precedence: bulk We developed the list of EDI over Internet issues via brainstorming through late Feb. These issues are now being edited and combined by two of the group's members: Mats Jansson and Chuck Shih. As soon as they get done we will re-distribute the list, prioritize the list items as a group and then discuss and resolve the higher priority items. Also we must put together an outline of the paper. It is due by the end of March, 1996. My first thoughts on the paper outline are: 1 Background of EDI over Internet - Why - Who is involved - CommerceNet involvement - Other 2 Identified issues (prioritized) - Issue 1 - Issue 2 - Issue 3 - etc. 3 Issues solved with existing standards -- recommend standard and process - Issue 7 - Recommendation - Issue 12 - Recommendation - etc. 4 Issues which need something new or are not being address elsewhere - Issue 1 - Recommendation - Issue 2 - Recommendation - etc. 5 Issues which we will not address because of low priority or other reasons - List them and discuss why if necessary 6 Summary, closing,.... I hope the edits will be done by the end of the week. If you have additional thoughts, please let me know. Later, Rik Drummond - Chairperson EDIINT From owner-ietf-ediint Sat Mar 9 04:59:30 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id EAA28532 for ietf-ediint-bks; Sat, 9 Mar 1996 04:59:30 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id EAA28527 for ; Sat, 9 Mar 1996 04:59:27 -0800 (PST) Received: from [199.184.212.178] (stockyard15.onramp.net [199.184.212.178]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id HAA05679 for ; Sat, 9 Mar 1996 07:08:13 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 9 Mar 1996 07:15:07 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** ACTION Statement Edits #1-14 Sender: owner-ietf-ediint@imc.org Precedence: bulk This is the first section of the issues for EDI over Internet. If we did not get you comments in the first round, please forgive us. Submit them in this round. I would like thank our editors Chuck Shih and Mats Jansson for their effort on organized the responses. ACTION: Let us spend until next Friday (six days) doing two things: 1) adding additional comments or solution recommendations to these in the same form as below The form of response should look like "23 Comments: From Sally Jones blaw, blaw......." 2) vote on which items to address first. We have so many issues identified that we will have to attack them in some order. The voting response should be as the example below shows: Priority 1: xx issue Which means the most important statement is "xx Issue". Let vote for the top ten in this round. Your response should look like: To: ietf-ediint@imc.org From: Sally Jones Subject: ** EDIINT Vote Priority 5: 22 Issue Priority 2: 01 Issue Priority 4: 15 Issue Priority 1: 07 Issue Priority 3: 02 Issue o o Priority 10: 13 Issue Soon as these are prioritized we will finalize the outline and start working on each individual "Priority issue" with much discussion. Thank you for your patience.....Rik ***************************************************************************** 01 ISSUE: EDI OBJECT BOUNDARIES - The specifications by this work group apply to the EDI interchange level, and not the group or document level. Any security services, packaging, transport services, non-repudiation services, etc. is assumed to be applied to an EDI interchange. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Multiple interchanges can however be sent at one time. 01 Comments: From Rik Drummond Since we are only transporting the transactions (EDIFACT messages) our interest should stop at the transaction level (entire X12 envelope) and not the Group level. 01 Comments: From Trevor Richards If I understand the issue correctly, it is suggesting that we only consider transporting transaction sets (X12:ST segment through SE, EDIFACT:UNH segment through UNT) only via the Internet, or at least provide the option to do so. The mandatory control segments (X12:ISA, GS, GE, IEA, EDIFACT:UNB, UNZ) contain both counters to ensure data integrity and information about the interchange control segment standard version (X12:X12.5, EDIFACT: ISO 9735) used to construct the transaction sets/messages. Our interest must start at the interchange level, as this is an integral part of the transmission of transaction sets/messages. The group level is (i) mandatory for X12 interchanges as it contains the standard version used to construct the transaction sets, and (ii) optional for EDIFACT messages as the standard version/release information is carried in the UNB segment. 01 Comments: Chuck Shih The assumption is that the EDI interchange, which includes the enveloping segments is the basic unit of packaging, transport, security services, etc. ******************************************************************************** 02 ISSUE: STANDARD ENCRYPTION SCHEME - In order to provide confidentiality for EDI interchanges on the Internet, a standard encryption algorithm(s) and key length(s) must be specified. 02 Comments: From Harald T. Alvestrand Agreed. MOSS is my recommendation. (NOTE - this may change over time; things are happening quickly. I believe security multiparts is stable, but MOSS might not be.) 02 Comments: From Chuck Shih Giving too many options in a standard will almost guarantee interoperability problems when implemented. This is one problem with the MOSS specification. I feel that for any encryption algorithm or other security algorithms that need specification, that we limit the options, or pick an existing standard that limit the options. 02 Comments: From Rik Drummond We should be thinking about defining a *standards profile* which covers the whole area of EDI over the Internet. A standards profile takes existing standards, and standards-options and reduces them to one or a very few so that implementation issues are reduced to one or a few options. This insures better general interoper- ability, less interoperability testing (less options to test), and less coding personpower. Since we must show interoperability in this effort soon after the RFC is released, we must focus on the *profile* idea for a quick RFC and interoperability establishment. ******************************************************************************** 03 ISSUE: WORLDWIDE ENCRYPTION - The chosen encryption algorithm(s) must work across the world and not be limited by export or legal restrictions. 03 Comments: From Harald T. Alvestrand This is a "can't do". France has outlawed all encryption unless specifically authorized by the French ministry of security. (It is operated in the "we won't do anything to catch you, but if we need to get you for something, we have you on file" mode, I think) 03 Comments: From Chuck Shih From an export and licensing point of view there will always be legal restrictions on exporting security related products, more specifically with key lengths. This still does not invalidate the standardization work in the sense that the standards that are specified, if implemented outside the U.S. should still be able to interoperate with a standard implementation done within the U.S. ******************************************************************************** 04 ISSUE: TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME is to include the EDI enveloping segments as well as the EDI documents, i.e., the ISA/IEA or UNA/UNB/UNZ are also encrypted. Use an existing encryp- tion standard or combination of standards such as PGP, DES, MOSS, or S/MIME. 04 Comments: From M. Greely I also believe that the ISA is critical for the document routing by standard means today. I can not route EDI files without it. The catch 22 could be that it also lets you know who is sending what to where. If it stays unencrypted who is to say that the ISA was not changed. 04 Comments: From HARALD T. ALVESTRAND Should be "no problem". Just pick the right standard (MOSS is in my opinion) 04 Comments: From Rik Drummond The sequence of events to accomplish the re-enveloping of an EDI transaction into a MIME envelope is: Step 1) Translator translates the internal format to EDI format (X12, EDIFACT, etc.), Step 2) copies of pertinent control information from "step 1" format are made and the entire EDI formatted transaction is encrypted and placed in a MIME envelope, step 3) the data copied from the EDI transaction (Step 1 output) is appropriately placed in the proper MIME or SMTP message. In step 3 sometimes one-to-one translations may be necessary such as is the case for the DUNS number address being translated into the appropriate Internet Address. If we have to leave the control EDI segments out of the encryption - which implies disassembling encrypting and reassembling the EDI transaction - then we should not even attempt to handle this option. We should push back on the translator vendors to do this. We should not .. ******************************************************************************* 05 ISSUE: DON'T DUPLICATE EXISTNG FUNCITONALITY - Don't duplicate what is al- ready provided within the EDI standards. X12.58 and X12 Security Structures define security at two levels, authentication and encryption at the functional group and transaction set levels. UN-EDIFACT defines the AUTACK, USA, USC, and USR segments which provide authentication, and non-repudiation of origin/ receipt at the message, package, group, and interchange levels. 05 Comments: From Harald T. Alvestrand Agreed. 05 Comments: From Graham Helliar We should understand these solutions, and decide if any meet the requirements we need for EDI over the Internet. Where there are no instant solutions we should provide solutions which do not clash with existing EDI standards. ..... ******************************************************************************** 06 ISSUE: LEVERAGE TEMPLAR WORK - See what we can use from the current Templar produt to add to our document, i.e. can we leverage any of their efforts specifically as regards to architecture, design, implementation, and references? 06 Comments: From Rik Drummond We should also see what SupplyTech, DEC, HP, Sterling, Harbinger etc. have found from their efforts. 06 Comments: From Chuck Shih Templar has defined a *profile* for doing EDI over the Internet. The group shoould take the Templar profile, as well as profiles used by others, as a basis for discussion and consensus. ******************************************************************************** 07 ISSUE: CONTENT INTEGRITY - Protect the contents of an EDI message so that the receiver is guaranteed that the message arrived in its originally sent state. Provide a method to detect any modifications - additions, deletions, or changes to the original EDI message. 07 Comments: From HARALD T. ALVESTRAND Already done if you do signatures on the data 07 Comments: From Kit Lueder .... you may want to have integrity without confidentiality (e.g. so that the X12 headers are visible for relay by EDI VANS). 07 Comments: From CHUCK SHIH Content Integrity can be achieved by the sender including with the EDI Interchange an integrity control value. This value can be computed by using an appropriate cryptographic algorithm (MD5, SHA) to 'fingerprint' the EDI Interchange. Since the control value or 'fingerprint' itself is unprotected, additional measures such as digitally signing the control value is usually done. Thus content integrity is typically obtained as a result of message origin authentication or non-repudiation of origin. ******************************************************************************** 08 ISSUE: AUTHENTICATION - Guarantee or authenticate by use of digital signatures the identity of the sender of an EDI Interchange. Specify the algorithms, hash functions, and key lengths to be used in order to provide this functionality. 08 Comments: From CHUCK SHIH EDI Interchange authentication can be achieved by including with the EDI Interchange an authentication value. The authentication value would be dependent on the message contents and a sender's private key. Use of asymmetric or public-key algorithms solves the problem of the sender and receiver having to know or exchange private keys, so it is typically the case that EDI Interchange authentication is obtained as a result of non-repudiation of origin. Non-repudiation of origin can be achieved by use of a digital signature. 08 Comments: From This means a certificate distribution mechanism, I think. 08 Comments: From HARALD T. ALVESTRAND I suggest again sticking with MOSS for the basic standard. ******************************************************************************** 09 ISSUE: COMPATIBILITY WITH X.435 - The functionality chosen for the EDI / MIME / Internet package should implement compatible functionality (or be easily translatable between) with X.434. 09 Comments: From HARALD T. ALVESTRAND Note that security is VERY hard to gateway. Apart from that - I agree. 09 Comments: From Klaus Naujok The X.435 NRR, NRO, integrity, secrecy and such should be used as the basis for part of our functionality requirements. 09 Comments: From Rik Drummond I agree with Klaus ******************************************************************************** 10 ISSUE: NON-REPUDIATION OF ORIGIN - Non-repudiation of origin protects the receiver of the EDI interchange from the sender's denial of having sent the interchange. By using the non-repudiation of origin feature on an EDI inter- change, interchange authentication and content integrity are also achieved. (See issues on integrity and authentication). A key-management infrastructure or key certificate mechanism needs to be specified as well as digital signature algorithms, hash functions, and key lengths. 10 Comments: From HARALD T. ALVESTRAND As above (with authentication) you need a certificate hierarchy. ******************************************************************************** 11 ISSUE: KEY MANAGEMENT - The assumption is that public-key cryptography will be used for non-repudiation of origin/receipt, authentication, and integrity. Use of public-key cryptography requires the use of the trading partner's public-key. Standardization of the mechanism of public-key distribution and authentication among trading partners needs to be specified. 11 Comments: From HARALD T. ALVESTRAND Agreed. I hope we have at least ONE key distribution/authentication mechanism standardized "soon". 11 Comments: From Lori Blackburn Additional issue related to Key Management... Who will be the keepers of the Public and Private keys? I once heard a rumor the Post Office wanted to get into that business...? 11 Comments: From Chuck Shih The strength of any security program is pretty much dependent on your private key. So each trading partner must keep their private keys private. The Post Office and companies like Verisign are considering becoming public key certifying authorities, i.e. they will sign and vouch for public keys. ******************************************************************************** 12 ISSUE: NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains a digital signature applied to the original EDI message; also, the acknowledgment itself is digitally signed. Receipt acknowledgment is applied at the EDI Interchange level, and can consist of multiple receipts if multiple EDI Interchanges have been packaged together. 12 Comments: From HARALD T. ALVESTRAND Receipt is an issue being worked on in the RECEIPT WG. But it doesn't address your issues. EDI-formatted receipts, digitally signed using MOSS, might be an answer. 12 Comments: From Ken Steel Might I strongly recommend the non-repudiation of receipt is not tied in any way to an EDI method. Whatever is done should be equally applicable to X.12, EDIFACT, Open-edi and any other flavour that comes along. .... Using solutions such as 997 means we are all wasting our time on this - it is not a universal solution - just another contribution to the non-standard mess called edi. 12 Comments: From Bob Lyons Note that a trusted third party, such as an EDI VAN, can provide non-repudiation of receipt without the use of digital signatures. However, most, if not all, Internet Service Providers do not offer this service. MOSS, PEM, PGP and S/MIME meet most of the security requirements of users doing EDI over the Internet; however, they do not provide non-repudiation of receipt. The IETF-EDIINT group should try to persuade any IETF groups working on e-mail security and e-mail receipts to develop a standard for non- repudiation of receipt. We should also align ourselves with any other groups that need this feature for their Internet e-mail applications. A possible interim solution is to use the 997. The receiver of an EDI message would place the digital signature of this EDI message into a 997, and return the 997 to the sender of the original EDI message. The problem with this solution is that e-mail users, EDIFACT users and proprietary EDI users will not want to use an ANSI X12 transaction set for non-repudiation of receipt. This will result in multiple solutions for non-repudiation of receipt (i.e. one for e-mail, one for X12-based EDI, one for EDIFACT-based EDI, etc.) Another possible interim solution is to use the EDIFACT AUTACK message, which was designed to provide non-repudiation of receipt. This is how Premenos's Templar product provides non-repudiation of receipt. However, this solution has the same problem as the 997-based solution. 12 Comments: From Jim Amster I agree that we need to have a generic method that goes beyond EDI. The effort to define a non-repudiable receipt would seem to be an activity that might be co-worked with the IETF Notary group. That group recently published the following RFCs: RFC 1894 An Extensible Message Format for Delivery Status Notifications RFC 1891 SMTP Service Extension for Delivery Status Notifications There had been some discussion in that group of generating a work item on receipts. I am not sure if that item is still under development, has been suspended or what. It would seem that non-repudiation could be added to that work item. 12 Comments: From Thomas A. Darling I suspect some of the discussion around the NRR can be clarified if we distinguish two alternative types of business needs for NRR. The first, and I suspect far more common, need is to know that the trading partner has received the message (alive and intact). At that point I can expect the TP to be under some obligation to fulfill its responsibilities in our relationship (e.g. send me an order, etc.) Because the functional acknowledgment is generated later in the receiver's processing (after they've had a chance to check that the message makes sense to them), it satisfies this need much better than a notification that the message arrived in a mailbox. [For example, I would be loathe to enter into a TPA in which I incurred obligations because mail was put in my box, whether I had been able to read it or not, etc., etc. (Especially after my ISP went down for 3 hours this afternoon)] With traditional FAs, if my translator doesn't get back the acknowledgement within some agreed upon period I will either re-submit or contact the TP through another medium. In other words, this type of solution needs no furthur attention from the group(?) - it is not related to the transport of the message, but the solution is at the EDI Application layer. Aside - Assuming the TPs are using both authentication and message inte- grity checks, there is no reason I can think of to include the MIC in the reply, since the check of the hash by the receiver has been successful. (Am I confused on this?) ........ 12 Comments: Chuck Shih I mostly agree with T. Darling's analysis of the NRR. The mailbox NRR is being addressed by some of the e-mail working groups in the IETF, and we should make use of any mechanism they come up with. The NRR for EDI is at a higher level than the mailbox NRR. The NRR of the EDI Interchange satisfies the requirement of the sender that not only has the EDI inter- change been delivered to a mailbox, but the receiver has authenticated the EDI interchange (knows it truly is from the TP), and the integrity of the EDI interchange is intact - nobody changed the original purchase order from 50 widgets to 5000 widgets for instance. The receiver can then honor the EDI interchange on its end, and by sending back the NRR the sender knows that the receiver has acknowledged getting the interchange (and not just a mail message) and the interchange was not tampered with in transit. If the EDI NRR contains the MIC of the original interchange, then the sender can verify that what the receiver acknowledged was what the sender actually sent, and this can be archived or logged. By relying only on the subsequent 997, the level of security is not as strong, since the 997 does not directly correlate to a received interchange except by use of the control number. By sending the MIC back with the NRR, the sender can absolutely derive the original message that was sent from the information in the NRR. An additional comment on use of the AUTACK versus 997 for NRR. There is a difference between using AUTACK and 997 for NRR, in that the AUTACK was architected specifically for NRR by EDIFACT and contains the formats for the security objects while the 997 was never architected to do this by X12. I am not even sure how some of the security information could be sent back in the 997. (See Bob Lyons comment.) ******************************************************************************** 13 ISSUE: SPECIFY CRYPTOGRAPHIC SYNTAX AND PROTOCOL FOR EDI INTERCHANGES OVER THE INTERNET - Describe the syntax and protocol for applying digital signatures and/or encryption services when EDI Interchanges are to be sent over the Internet. Internet e-mail standards are addressing syntax and protocol for adding digital signature and/ or encryption services to any data enveloped by an Internet MIME message. Standards such as S/MIME, MOSS, and PGP are extant. Standards for non-repudiation of receipt also exist and are embodied in the AUTACK message described by ISO 9735-6. Use of, and extension of these existing standards should be specified. From owner-ietf-ediint Sat Mar 9 04:59:42 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id EAA28541 for ietf-ediint-bks; Sat, 9 Mar 1996 04:59:42 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id EAA28536 for ; Sat, 9 Mar 1996 04:59:41 -0800 (PST) Received: from [199.184.212.178] (stockyard15.onramp.net [199.184.212.178]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id HAA05721 for ; Sat, 9 Mar 1996 07:08:29 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 9 Mar 1996 07:15:22 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** ACTION Statement Edits #15-28 Sender: owner-ietf-ediint@imc.org Precedence: bulk **************************************************************************** 15 REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION (Original #15 and #17) The specification must describe what type of notifications and acknowledgments a sender should receive, taking into consideration Non- repudiation of receipt, 997's, 993's, AUTACK's, and existing pre-997 VAN- provided delivery status. 15 COMMENT: From Unknown Currently, you can get from a VAN separate sets of messages denoting message delivery, in advance of a 997. Given that ISPs do not have the management software to provide similar support, it might be advisable for IETF-EDI to be aware of and perhaps integrate the notification work now going on Title : An Extensible Message Format for Delivery Status Notifications Author(s) : K. Moore, G. Vaudreuil Filename : draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 15 COMMENT: From Carl Hage This is now . There are also some related RFCs: -The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages -Enhanced Mail System Status Codes -An Extensible Message Format for Message Disposition Notifications 15 COMMENT: From Harald Alvestrand This is now an RFC (one of a set of four). RFC 1891-1894. 15 COMMENT: From Mats Jansson I think the fact that internet EDI is point-to-point, as compared to the store-and-forward nature of VAN traffic, obliterates the need for any inter- im status. My experience is that non-repudiation of receipt acknowledgments are received within 45-90 seconds - why would I need anything in-between? Also, it brings up the question of the need for a 997. Given the installed base of translators out there, I think we need to assume that 997's will be used, if not as a means of acknowledging receipt, as a way to confirm that a transmission was translated in compliance. **************************************************************************** 16 REQUIREMENT : WWW - HTML Integration with EDI (original #16 and #19) The specification would describe interface requirements to http and html, and recommendations on providing "pull" documents on http servers. (recommendation: do NOT include in scope) 16 COMMENT: From Unknown As electronic commerce expands across the Internet, there could be ways to ease that expansion through support of smoother integration paths between the WWW's HTML pages and EDI messages. This has been bounced around in the EDI-L list and could assist the fulfillment process that site's need to execute. 16 COMMENT: From Harald Alvestrand Ouch! 16 COMMENT: From Carl Hage The integration with WWW is a pretty wide open opportunity, perhaps constituting many new standards. However, some basic integration standards with existing EDI messaging might be suitable for the scope of this work. For example, RFQs could be posted on a HTTP server. SSL servers could be used to post an X12/EDIFACT interchange and download a reply. This is likely a manual process, though, so Ken S. wouldn't call it EDI. ;) I still think general purpose SMTP exchanges are better than the more specialized HHTP for fully automated transactions. In my opinion, linking human-machine interaction on the WWW with EDI is beyond the scope of this initial effort at standardizing the process of internet based messaging for traditional EDI. It's useful, but we don't need to delay an RFC till this topic is addressed. 16 COMMENT: From Mats Jansson WWW and http document transport seems very much geared towards human-to- computer type electronic commerce, not computer-to-computer, such as EDI. Therefore, I don't think we need to address requirements in this doc. 16 COMMENT: From Harald Alvestrand Not something I'd spend much time on before the basic transport is OK. 16 COMMENT: From Mats Jansson If we assume that web pages can display information from a variety of sources, why do we need to specify any requirements for information coming from EDI transactions (or translated EDI transactions). It's just data. **************************************************************************** 17 REQUIREMENT: FTP and SERVER ACCESS (original #18 and #20) FTP is a very likely transport for internet EDI. Specification would define how FTP is used as an alternative to SMTP/MIME, covering all areas already defined for SMTP/MIME, including security. (recommendation: do NOT include in scope right now) 17 COMMENT: From Mats Jansson Existing Internet EDI tools make use of sendmail as the message transport. It is conceivable (and probably used somewhere already) that ftp could be used just as successfully. Tools utilizing ftp should provide the same security features as tools utilizing e-mail (is this enough?). One other choice would be to scope ftp out at this time, just to get moving. 17 COMMENT: From Carl Hage FTP would be useful to post RFQs, CRLs, etc. with 1-many or many-many distribution. However, those people who use FTP for TP-TP EDI messaging would be better off switching to SMTP for a variety of reasons. 17 COMMENT: From Harald Alvestrand Not My Problem, I hope. 17 COMMENT: From Unknown As Wal-Mart does in the direct dial world, there will be companies who wish to have their trading partners access a server for requesting EDI messages or sending EDI messages. Are there issues IETF-EDI needs to address in this area ? 17 COMMENT: From Carl Hage Corporations using (offering) direct dial messaging could use standard Internet protocols, and in turn standard software. The IETF standards supporting security, integrity, reliability, and interoperability would also address these needs in private or direct dial networks. 17 COMMENT: From Mats Jansson If the real reason hub companies require this is to avoid transmission costs, then internet EDI may change this presumption. If required, however, it seems ftp would be the transport of choice. Until we get comments from some large retailer, it's just anyones guess, I suppose. In the near term we can use the requirement under #18 **************************************************************************** 18 REQUIEMENT - FUNDS TRANSFER (original #21) Specifications should address any differences needed in applying internet EDI to EFT. 18 COMMENT: From Carl Hage For the funds transfers which behave like EDI messaging (TP-TP exchange), then it seems like the security, integrity, reliability, NRO/NRR, etc. for EDI could apply to payment messages. Some payment protocols don't have the simple EDI-like TP-TP messaging architecture, since there are 3 or 4 parties involved (customer, merchant, bank, payment-gateway) sometimes with complex interaction. Note the new MasterCard/VISA grand unified theory, called "Secure Electronic Transaction" (SET) has just come out, . SET and the defunct STTS introduce "dual signatures", which is a way to bundle signatures of two private messages, one to the merchant and one to the bank, into a combined bundled signature. It might be worth considering this architecture for the Internet-EDI spec. 18 COMMENT: From Mats Jansson I believe it's already being done by Bank of America and Lawrence livermore Labs (more info anyone?). I don't see a reason to exclude EFT. **************************************************************************** 19 ISSUE - MESSAGE FILE SIZE and SEGMENTATION (original #22 and #25) Specification should define any considerations related to message file size and its implications on transmission time, reliability, etc. (recommendation: point to existing RFC's?) 19 COMMENT: From Unknown Are there any limits to the size of EDI Internet messages we may send? Will file size impact transportability, ability to send/receive, dependability etc. 19 COMMENT: From Unknown Is there a requirement for segmentation, where the sender's system breaks up a large EDI interchange into a series of small messages and the recipient's system recombines the small messages? Apparently, some Internet e-mail systems have a maximum message size limit of 50KB. PGP provides segmentation. So does Premenos's Templar product. 19 COMMENT: From Harald Alvestrand I regularly send and receive megabyte messages. If your disk is large enough and your line fast enough, I don't believe the Internet protocols will give you any problem. 19 COMMENT: From Carl Hage This is already solved by RFC1521, Content-Type : Message/Partial. We simply need to specify that this standard will be used when messages are too large. Also, it may be useful to suggest that a ", Part nn/mm" suffix be appended to the Subject: line when splitting a message. An intermediate mailer could split a message according to RFC1521, and another could glue it back together. TPs might impose limits to prevent attacks by filling up the disk space. 19 COMMENT: From Mats Jansson >From what I understand, the larger the message, the more packets are being routed, and the greater the chance that one of these packets get delayed, causing the transmission to take a little longer. Also, internet EDI enables transaction driven exchange as opposed to large batches of multiple transactions, making each transmission smaller in the internet EDI scanario (except with product catalogs, CAD drawings and such) 19 COMMENT: From Harald Alvestrand Also specified in the MIME standard. Look for message/partial in the spec. **************************************************************************** 20 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES (original #23, #26 and #27) Specification should define how message tracking should be handled, and especially its relationship to other tracking mechansims in translators, applications. In addition, weigh the benefit of tracing versus simply re-transmitting in case of problems. Also, address the frequent sequence problems with internet routing. 20 COMMENT: From Unknown EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. 20 COMMENT: From Unknown I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? 20 COMMENT: From Carl Hage One thing that would simplify the tracking of messages through mailers, ateways, and networks, is to use some standards for the Message-Id: and Subject: headings, where the ICN can be included. This may also simplify some logging and auditing issues. 20 COMMENT: From Harald Alvestrand I can't help you define this :-) 20 COMMENT: From Mats Jansson Although my experience has been very good (eg no lost messages) so far, I believe a mind shift is in order. If a transmission does not arrive within specified time, to generate an acknowledgment back to the sender, don't spend any energy tracing, just re-transmit. It's important to note, though, that this puts the burden of identifying duplicates on translators and/or applications. Is this OK? 20 COMMENT: From Unknown Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. 20 COMMENT: From Harald Alvestrand Are you arguing for putting a sequence number into the MIME headers? If so, that should be relatively easy. 20 COMMENT: From Mats Jansson This is a common problem. Frequently, a message (A) sent before message (B) is received in reversed order, due to internet routing paths. I suppose we could say that the internet EDI gateway tool should have the capability to buffer incoming messages and re-order them according to some sequence ID. 20 COMMENT: From Carl Hage The sequence should be enforced by the receiving EDI system, not the mailer. (It's built into X12 and EDIFACT.) However, the message sequence number can be useful for tracking messages through mailers. 20 COMMENT: From Unknown Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. **************************************************************************** 21 ISSUE - MESSAGE FILE COMPRESSION (original #24) Specification should define how file compression should be handled and provide guidelines for applications where typically needed. 21 COMMENT: From Carl Hage There are a couple of ways to add it. One is to extend the MIME Content-Type: to include a compression method, e.g. EDI-X12-gzip. The HTTP draft spec adds some headers that would be useful for MIME in general, one of which is: Content-Encoding: "gzip" | "compress" | token SSL include a compression_method but doesn't define the constants. 21 COMMENT: From Harald Alvestrand I hope there will be a standard soon (months), based on L. Peter Deutsch' DEFLATE specifications. At the moment, there isn't one. **************************************************************************** 22 ISSUE - ENCRYPTED TUNNELS (original #29) Specification needs to define how, if at all, thinhs change if trading partners use "encrypted tunnels". 22 COMMENT: From Unknown We should take into account any current/future work that is going on to standardize encrypted tunnels. They may provide a useful mechanism for providing security at the communications layer. Yes, I am talking about encryption at the packet level. I guess that this really depends on the outcome of the standardization work for tunnels. We would need to adopt these standards to ensure that tunnels themselves inter network. 22 COMMENT: From Carl Hage If secure TCP/IP channels are available, then message encryption is not needed, however, signatures might be important for nonrepudiation. SSL provides exchange of signatures upon termination that provide nonrepudiation, but using the communications layer security complicates the logging and auditing process. BTW, it is possible to simply use SSL to exchange EDI interchange messages directly without any wrapping. A TP would connect a socket to the other TP's EDI port and simply send bytes starting with the ISA, etc. This would only work if at least one TP has a dedicated internet connection, and the other has a SLIP/PPP connection. SSL could also be used to communicate with a VAN. An SSL interchange would probably have a different signature value than would apply to a RFC822-MIME message, so converting SSL through a gateway or VAN would be problematic. On the other hand SSL can be pretty darn simple, since there is a direct secure link between the EDI translators at each TP without any intervening software. The IETF-EDI group could register a port number for SSL X12/EDIFACT messaging. **************************************************************************** 23 ISSUE - TRANSPORT ONLY (original #30) Specification needs to define any limitations on number of interchanges within a single MIME envelope, or message. 23 COMMENT: From Unknown A single interchange is the smallest entity that can be transported via the Internet. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Can multiple interchanges be transported in a single MIME envelope, or can only a single interchange be contained in a single MIME envelope ? 23 COMMENT: From Carl Hage Probably the main issue here is with non-repudiation and signatures, and the corresponding logging and auditing process. If messages are bundled, then there is no longer a correspondence between interchanges, signatures, and receipts, depending on the MIME wrapping order. There also might be a lack of correspondence between Message-ID and ICN, complicating the message tracking. MIME does allow combinations of messages with the multipart/mixed and multipart/digest. **************************************************************************** From owner-ietf-ediint Sun Mar 10 03:04:58 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id DAA04905 for ietf-ediint-bks; Sun, 10 Mar 1996 03:04:58 -0800 (PST) Received: from ns1.indirect.com (root@ns1.indirect.com [165.247.1.3]) by imc.org (8.7.4/8.7.1) with SMTP id DAA04900 for ; Sun, 10 Mar 1996 03:04:55 -0800 (PST) Received: from dave_d.indirect.com (s82.phxslip4.indirect.com [165.247.24.82]) by ns1.indirect.com (8.6.12/8.6.6) with SMTP id EAA26180 for ; Sun, 10 Mar 1996 04:04:50 -0700 Message-Id: <2.2.32.19960310110533.006d69e0@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Mar 1996 04:05:33 -0700 To: ietf-ediint@imc.org From: Dave Darnell Subject: GEIS Sender: owner-ietf-ediint@imc.org Precedence: bulk Since it is important that we know what the EDI VAN guys are doing with the Internet, I snipped the following off of GEIS' Web pages. Does anybody have more info on the operational spec of their "mutual authentication model", e.g. are they using DES encryption? Kerberos authentication? etc. ----------------------------------------------------------- This is from: http://www.geis.com/geis/press/pr020696.html Contact: GE Information Services John Berry (301) 340-4244 NEW GENERATION OF SECURE INTERNET COMMERCE UNVEILED BY GE INFORMATION SERVICES "GE InterBusinessSM" Allows Internet Access to Business-to-Business Electronic Commerce Solutions Rockville, MD, February 6, 1996 -- GE Information Services today announced the launch of "GE InterBusinessSM," a new electronic commerce offering that provides powerful security protection of business transactions over the Internet. GE InterBusinessSM combines encrypted dynamic session key, mutual authentication, and advanced firewall technology. It is based on standard Internet protocols and establishes a highly secure "pipeline" through which a user can conduct electronic data interchange, electronic messaging, and electronic file transfers, the three key elements of electronic commerce and GE Information Services. "Our goal is to deliver our Business Productivity Solutions suite of services to global customers and their trading communities," says Haskell Mayo, Vice President of Marketing for GE Information Services. "The Internet will play a critical new role in broadening this effort." Next-Generation Security GE InterBusiness uses secret key cryptology in a mutual authentication (double challenge) environment to permit secure transmission of highly sensitive data over the Internet. According to Anne Biehl, Manager of Market Development for GE Information Services, GE InterBusiness provides a dynamic session key that encrypts the session itself to secure all information passed from sender to receiver. "We recognize our customers' need to combine secure business applications with the Internet's global reach," says Ms. Biehl. "Our solution offers both the ease and breadth of access of the Internet with verification and authentication for private transactions." How It Works GE InterBusiness is based on a mutual-authentication model. The firewall server requests a user's ID, like that lifted off an ATM card's magnetic strip. This encrypted ID code constitutes a "secret key" that is generated by the software provided by GE Information Services. Once the server matches this code with that of an approved user, the server then requests a password known only to the user, also following the ATM analogy. The effectiveness of this kind of procedure, which occurs in seconds, establishes a secure pipeline before any data is transferred. GE InterBusiness is unique in its provision of a dynamic encrypted session, in which each key is used for one session only. The session key is never seen on the Internet, so there is no way for hackers to break the encryption. In addition, GE Information Services administers all of its customers' keys. Open Environment Departing from previous attempts in the industry to secure commerce on the information superhighway, GE InterBusiness uses the standard networking and connectivity of the Internet to interface with the diverse technology systems used by GE's broad customer base of more than 40,000 companies. Based on standard Internet protocols (e.g., TCP/IP, SMTP, and FTP), GE InterBusinessSM runs on all browsers, interacts with standard Internet applications, and can reside on any Internet-compatible desktop. With the advent of GE InterBusiness, businesses of all sizes can improve supplier management, strengthen logistics management, and expand their trading communities because they can use any SMTP-, FTP-, or TCP/IP-based application. "Successful Businesses recognize the strategic importance of networked information and electronic commerce. Yet because of concerns over security, relatively few have leveraged the Internet's open technology and powerful reach to gain a competitive advantage in their global marketplace.," says Hellene Runtagh, President & CEO of GE Information Services. "GE InterBusiness is pioneering a secure solution." Business Productivity Solutions GE Information Services' Business Productivity Solutions streamline business processes by using electronic commerce services to integrate suppliers, manufacturers, distributors, and customers. Benefits include reduced costs, decreased cycle times, improved quality, and increased customer satisfaction. GE InterBusiness provides an important means of secure access to these services. GE Information Services first established a presence on the Internet in 1993 with the introduction of its Internet mail gateway. In the fourth quarter of 1994, GE Information Services and four other GE businesses joined CommerceNet, a consortium of technology-oriented companies, the charter of which is to facilitate use of the Internet for business-to-business transactions. GE Information Services is a leading provider of Business Productivity Solutions, combining electronic commerce services, inter-business process consulting, GE best practices, and trading community management. GE Information Services supports a trading community of more than 40,000 companies, helping them improve their purchasing/supplier productivity, logistics productivity, and marketing and sales productivity. GE Information Services is one of the 12 key businesses of the General Electric Company, USA, and is headquartered in Rockville, MD, USA. ====================================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8032 | mailto://dave_d@systrends.com ====================================== From owner-ietf-ediint Sun Mar 10 04:41:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id EAA05215 for ietf-ediint-bks; Sun, 10 Mar 1996 04:41:54 -0800 (PST) Received: from Fox.nstn.ca (fox.nstn.ca [137.186.128.12]) by imc.org (8.7.4/8.7.1) with ESMTP id EAA05210 for ; Sun, 10 Mar 1996 04:41:51 -0800 (PST) Received: from [204.191.144.66] (ts3-06.ott.InfoRamp.Net [204.191.144.66]) by Fox.nstn.ca (8.7.3/8.7.3) with SMTP id IAA22072 for ; Sun, 10 Mar 1996 08:41:41 -0400 (AST) Date: Sun, 10 Mar 96 07:40:58 -0400 From: "jenkins" Message-Id: <41887.jenkins@fox.nstn.ca> X-Minuet-Version: Minuet1.0_Beta_14.1 Reply-To: X-POPMail-Charset: English To: ietf-ediint@imc.org Subject: EDINT VOTE Sender: owner-ietf-ediint@imc.org Precedence: bulk cc : drummond@onramp.net Subject: EDINT Vote >From Gordon Jenkins priority 1 2 issue priority 2 16 issue priority 3 18 issue priority 4 7 issue priority 5 4 issue -------------------------------------------------------------------------- JENKINS @ ASSOCIATES INC jenkins@fox.nstn.ca -------------------------------------------------------------------------- GORDON JENKINS x CONSULTING IN ELECTRONIC COMMERCE AND INTERNET " helping you move from paper to electronic to compete" http://infop.com/karoma: Electronic Commerce Answer Page http://ARRAYdev.com: Journal of Internet Banking and Commerce: Editor fax 613 723 8938 tel 613 723 1581 cel 613 794 6735 ----------------------- OTTAWA ON CANADA ----------------------------- --VAA16267.826421336/Fox.nstn.ca-- ------ Forwarded message ends here ------ -------------------------------------------------------------------------- JENKINS @ ASSOCIATES INC jenkins@fox.nstn.ca -------------------------------------------------------------------------- GORDON JENKINS x CONSULTING IN ELECTRONIC COMMERCE AND INTERNET " helping you move from paper to electronic to compete" http://infop.com/karoma: Electronic Commerce Answer Page http://ARRAYdev.com: Journal of Internet Banking and Commerce: Editor fax 613 723 8938 tel 613 723 1581 cel 613 794 6735 ----------------------- OTTAWA ON CANADA ----------------------------- From owner-ietf-ediint Sun Mar 10 05:12:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id FAA05331 for ietf-ediint-bks; Sun, 10 Mar 1996 05:12:32 -0800 (PST) Received: from ns1.indirect.com (root@ns1.indirect.com [165.247.1.3]) by imc.org (8.7.4/8.7.1) with SMTP id FAA05326 for ; Sun, 10 Mar 1996 05:12:29 -0800 (PST) Received: from dave_d.indirect.com (s82.phxslip4.indirect.com [165.247.24.82]) by ns1.indirect.com (8.6.12/8.6.6) with SMTP id GAA26563 for ; Sun, 10 Mar 1996 06:12:33 -0700 Message-Id: <2.2.32.19960310131310.00688818@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Mar 1996 06:13:10 -0700 To: ietf-ediint@imc.org From: Dave Darnell Subject: EDIINT VOTE Sender: owner-ietf-ediint@imc.org Precedence: bulk FROM DAVE DARNELL: priority 1 2 issue priority 2 12 issue priority 3 15 issue priority 4 18 issue priority 5 4 issue priority 6 9 issue priority 7 17 issue priority 8 20 issue priority 9 22 issue priority 10 19 issue Regards, Dave ====================================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8032 | mailto://dave_d@systrends.com ====================================== From owner-ietf-ediint Mon Mar 11 10:03:05 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id KAA14189 for ietf-ediint-bks; Mon, 11 Mar 1996 10:03:05 -0800 (PST) Received: from ns1.digital.fr (ns1.digital.fr [193.56.15.3]) by imc.org (8.7.4/8.7.1) with ESMTP id KAA14184 for ; Mon, 11 Mar 1996 10:03:00 -0800 (PST) Received: from vbormc.vbo.dec.com (vbormc.vbo.dec.com [16.36.208.94]) by ns1.digital.fr (8.7/8.7) with ESMTP id TAA12386 for ; Mon, 11 Mar 1996 19:03:19 +0100 Received: from edieng.enet (daemon@localhost) by vbormc.vbo.dec.com (8.7.3/8.7) with SMTP id SAA04254 for ; Mon, 11 Mar 1996 18:56:16 +0100 Message-Id: <199603111756.SAA04254@vbormc.vbo.dec.com> Received: from edieng.enet; by vbormc.enet; Mon, 11 Mar 96 18:56:32 MET Date: Mon, 11 Mar 96 18:56:32 MET From: "Mark Thompson, EDI, REO2 F/D-2, dtn: 830-6363 11-Mar-1996 1757" To: "ietf-ediint@imc.org"@vbormc.vbo.dec.com Cc: me@edieng.enet.dec.com Apparently-To: ietf-ediint@imc.org Subject: Re: Message Sequence Integrity Sender: owner-ietf-ediint@imc.org Precedence: bulk Hi, Re: >At 7:06 AM 2/16/96, Trevor Richards wrote: >>Incidentally, X.25 and interconnected VANs can lead to interchange N+1 >>arriving before interchange N in todays' communications infrastructure. > > Interesting. > > X.25 is a connection protocol that is defined to deliver packets in >order, over the same path (unlike IP.) < I would doubt, very much, that this is due to X.25 per se, rather that it is an artifact of the store-and-forward system used by the VAN and its retry algorithm. Mark From owner-ietf-ediint Mon Mar 11 13:28:13 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id NAA15129 for ietf-ediint-bks; Mon, 11 Mar 1996 13:28:13 -0800 (PST) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.org (8.7.4/8.7.1) with SMTP id NAA15124 for ; Mon, 11 Mar 1996 13:27:56 -0800 (PST) Received: from chage.com by hustle.rahul.net with UUCP id AA22249 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Mon, 11 Mar 1996 13:27:50 -0800 Received: by slick.chage.com (4.1/SMI-4.1) id AA06316; Mon, 11 Mar 96 11:48:53 PST Newsgroups: lists.ietf-ediint Path: carl From: carl@chage.com (Carl Hage) Subject: Re: "transport" services for reliability and security Message-Id: <1a=j#vj-@chage.com> Date: Mon, 11 Mar 96 19:48:48 GMT Organization: C. Hage Associates, Sunnyvale, CA References: Apparently-To: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk dcrocker@brandenburg.com (Dave Crocker) writes: : =46olks, [Those #$@! MIME mailreaders are out of control, corrupting messages that don't need to be corrupted with automatic quoted printable. Can you turn that darn thing off?] : ... I've started : proposing that we enhance the Internet Mail architecture to include a layer : for [security and reliability]... Hence, email becomes: : : UA-UTA-MTA-MTA-UTA-UA. : : The purpose of the UTA architectural model is to perform reliability (and : sequencing) functions usually attributed to transport-like services, as : well as apply any security services that are required. The RFCs related to email and EDI could support separate UA-UTA or integrated approach, provided the wrapping of services are layered appropriately. One could imagine a generic UTA that could deliver decrypted/authenticated "Content-Type: message" to a plain mailreader, or deliver selected MIME types (EDI or other) to a processing application. Most all the functions of Internet EDI messaging could be handled by a generic UTA. Corporate email gateways could perform the UTA function for delivery to individual PCs within a corporate LAN. There are a few tricky points, however. These aren't really addressed by the current RFC1894, or draft-ietf-receipt-mdn-00.txt. One issue is that it may be desirable to reduce the number of messages that need to be processed, decoded, authenticated, etc., by combining a MDN (Message Delivery Notification) with a response. For example, a common EDI sequence might be: Message 1: To:S From:B (signed and encrypted) { EDI-X12(840 RFQ) } Message 2: To:B From:S (signed and encrypted) { MDN(Message 1) - Disposition + Message 1 headers with Content-MD5 EDI-X12(843 RFQ Response) } Message 3: To:S From:B (signed and encrypted) { MDN(Message 2) - Disposition + Message 1 headers with Content-MD5 EDI-X12(850 PO) } Message 4: To:B From:S (signed and encrypted) { MDN(Message 3) - Disposition + Message 3 headers with Content-MD5 EDI-X12(855 PO Ack) } Message 5: To:S From:B (signed and encrypted) { MDN(Message 4) - Disposition + Message 4 headers with Content-MD5 } This sequence of 5 messages might typically take a minute or so of elapsed time, assuming the EDI UAs or comm links are not overloaded. The process of encrypting, signing, decrypting, and authentication is fairly CPU intensive, so combining a UA response with an MDN cuts the processing load almost in half. For small EDI messages, data transfer might also be cut nearly in half. Another issue is that the request for delivery notification needs to be refined. RFC1894 has no specification, other than the nonstandard but widely used "Return-Receipt-To:" header. There is no way to control the type of MDN to be returned. Someone debugging might want a "traceroute" style MDN, where each mail gateway replies with an MDN. There should be a way to control when MDNs are sent, probably with a timeout. For example, if a gateway cannot deliver within a specified time, a notification should be sent. There needs to be a distinction between delivery to a mailbox/folder and display of a message. A MDN request with timeout specifications, might, for example, request that an MDN be sent indicating delivery to a mailbox if not displayed within 10 minutes. MTAs which incur delays in delivery could issue MDNs with the timeout defaulting to the mailbox delivery timeout. If the message is displayed/processed by the UA within 10 minutes, then there might be another timeout of 15 minutes to wait for a reply, which would be bundled with an MDN. "Vacation" type programs could trigger an MDN and specify the estimated time of final delivery to the UA display. If an EDI processing system is down, or shut off during non business hours, then the MDN should indicate when the EDI message will be processed. All of the above processing could be performed by a UTA running in the background on a user's PC or LAN mail server. To Dave, et al: How would a UTA fit into mailer architecture in comparison say to an IMAP server? Would there be some extension to IMAP to perform UTA functions? Would there be some sort of DLL, RPC, or stdin/stdout interface between a TUA and UA? If the UTA performed security services, how would you keep "Trojan Horse" UAs from spoofing the UTA to sign or decrypt unauthorized data? -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Tue Mar 12 04:24:50 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id EAA21212 for ietf-ediint-bks; Tue, 12 Mar 1996 04:24:50 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id EAA21207 for ; Tue, 12 Mar 1996 04:24:48 -0800 (PST) Received: from [199.184.212.193] (stockyard30.onramp.net [199.184.212.193]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id GAA09698 for ; Tue, 12 Mar 1996 06:24:49 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 06:31:51 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** Action: Don't forget to Vote! Sender: owner-ietf-ediint@imc.org Precedence: bulk --- Forwarded message ----- To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** ACTION Statement Edits #1-14 Cc: Bcc: X-Attachments: This is the first section of the issues for EDI over Internet. If we did not get you comments in the first round, please forgive us. Submit them in this round. I would like thank our editors Chuck Shih and Mats Jansson for their effort on organized the responses. ACTION: Let us spend until next Friday (six days) doing two things: 1) adding additional comments or solution recommendations to these in the same form as below The form of response should look like "23 Comments: From Sally Jones blaw, blaw......." 2) vote on which items to address first. We have so many issues identified that we will have to attack them in some order. The voting response should be as the example below shows: Priority 1: xx issue Which means the most important statement is "xx Issue". Let vote for the top ten in this round. Your response should look like: To: ietf-ediint@imc.org From: Sally Jones Subject: ** EDIINT Vote Priority 5: 22 Issue Priority 2: 01 Issue Priority 4: 15 Issue Priority 1: 07 Issue Priority 3: 02 Issue o o Priority 10: 13 Issue Soon as these are prioritized we will finalize the outline and start working on each individual "Priority issue" with much discussion. Thank you for your patience.....Rik From owner-ietf-ediint Tue Mar 12 04:27:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id EAA21235 for ietf-ediint-bks; Tue, 12 Mar 1996 04:27:18 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id EAA21230 for ; Tue, 12 Mar 1996 04:27:17 -0800 (PST) Received: from [199.184.212.193] (stockyard30.onramp.net [199.184.212.193]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id GAA09691; Tue, 12 Mar 1996 06:24:42 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 1996 06:31:45 +0100 To: Graham Helliar From: drummond@onramp.net (Rik Drummond) Subject: Re: ** EDIINT COmments Cc: ietf-ediint@imc.org, raj@edieng.enet.dec.com Sender: owner-ietf-ediint@imc.org Precedence: bulk Thanks for your comments Graham. My comments follow in the text. > >23 Comments: From Graham Helliar > >We still have no clear idea of how many EDI Interchanges go within a single= MIME=20 >message. X.435 stipulates a single EDI Interchange, so if you want to map= =20 >between MIME and X.435 you need to address this. 23 Comments: From Rik Drummond=20 Even though X.435 only allows one interchange per message, it seems a short= sighted restriction because of the *Request for Quote* type messages which= go to may addresses. To this end if we wish to have what ever we do be 1)= translatable to/from X.435 (we have not agreed on this yet) and 2) we wish= to support multiple MIME/RFC822 addresses per Interchange in our MIME= message we must know the impact this have on the translation between X.435= and MIME/EDI? What transactions does it possibly impact? The big question:= How will it affect the EDI translator? The problem may be with the= translator sending out one interchange from its point of view and receiving= multiple responses. (I assume we would not have the translator create many= messages and then stick them in a single MIME message.) I don't know the= impact. Does any body? > >04 Comments: From Graham Helliar > >>> From Rik Drummond >>> step 3) the data is copied from the EDI transaction (Step 1 output) is >>> appropriately places in the proper MIME or SMTP message > >I would be grateful for any pointers to where the 'appropriate places' are= =20 >defined. 04 Comments: From Rik Drummond Graham, I was presenting the logic used in the X.435 envelope creation. The= movement of some ISA data fields up to the X.435 envelope. I don't have the= standards in front of me, so I can't quote which data items. In the case of= MIME the only ones I can think of are the source/destination addresses= after being translated to RFC822 addresses. Should there be others, if we= encrypt the entire Interchange? Maybe we should move (copy) the entire ISA= segment into a special field in the MIME envelope so that it may be read= when the interchange is encrypted -- just a thought -- don't know if it has= any use. From owner-ietf-ediint Tue Mar 12 09:31:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id JAA22372 for ietf-ediint-bks; Tue, 12 Mar 1996 09:31:01 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id JAA22367 for ; Tue, 12 Mar 1996 09:30:59 -0800 (PST) Received: from [199.184.212.176] (stockyard13.onramp.net [199.184.212.176]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA28680; Tue, 12 Mar 1996 11:28:47 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 11:35:55 +0100 To: Dave Crocker From: drummond@onramp.net (Rik Drummond) Subject: Re: "transport" services for reliability and security Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk I see you are doing your usual creative thinking.... What does the proposal do to the issues we have on the table for EDIINT? It seems it may solve (or facilitate) many of them. Could you identify those EDIINT items the proposal would not solve. I am interested. Please let me know....Later...Rik >Folks, > > I believe the message sequence integrity thread raises a larger set >of issues pertaining to reliability and security. > > Internet mail is very much like IP in that it has no reliability or >sequencing guarantees. Those two functions are performed by TCP, if you >need them. (E.g., if you use UDP you don't geter either.) I've started >proposing that we enhance the Internet Mail architecture to include a layer >for this purpose. I'm calling it the User Transport Agent (UTA). It >resides only at the end points and is not part of the mail relay (MTA) >infrastructure. Hence, email becomes: > > UA-UTA-MTA-MTA-UTA-UA. > >The purpose of the UTA architectural model is to perform reliability (and >sequencing) functions usually attributed to transport-like services, as >well as apply any security services that are required. > > I should note that "replay attack" is usually prevented by the >style of security features that are applied, rather than simple >transport-like duplicate detection. That is, it's part of the message >hashing function. > >d/ > >-------------------- >Dave Crocker +1 408 246 8253 >Brandenburg Consulting fax: +1 408 249 6205 >675 Spruce Dr. dcrocker@brandenburg.com >Sunnyvale CA 94086 USA http://www.brandenburg.com > >Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Tue Mar 12 09:50:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id JAA22444 for ietf-ediint-bks; Tue, 12 Mar 1996 09:50:16 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id JAA22439 for ; Tue, 12 Mar 1996 09:50:14 -0800 (PST) Received: from [205.214.160.50] (d22.netgate.net [205.214.160.54]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id JAA08533; Tue, 12 Mar 1996 09:59:23 -0800 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Mar 1996 09:38:55 -0800 To: drummond@onramp.net (Rik Drummond) From: Dave Crocker Subject: Re: "transport" services for reliability and security Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 2:35 AM 3/12/96, Rik Drummond wrote: >I see you are doing your usual creative thinking.... well, I always say, if you can't be helpful, be creative. (and I wasn't even educated as an attorney or accountant...) >What does the proposal do to the issues we have on the table for EDIINT? Might help in the thinking about required services and their delivery. It certainly has helped me to think more cleanly about the relevant set of enhancements. >It seems it may solve (or facilitate) many of them. Could you identify >those EDIINT items the proposal would not solve. It won't help in choosing any actual details. If the group wants to specify a single, default, security technology, this framework is irrelevant. If the group wants to specify actual performance and reliability details or requirements, this framework is irrelevant. The framewould should help to decide on TYPES of services that are missing and required and might help people see how to slip those services into an existing world. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Tue Mar 12 11:14:25 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id LAA22800 for ietf-ediint-bks; Tue, 12 Mar 1996 11:14:25 -0800 (PST) Received: from ns2.eds.com (ns2.eds.com [199.228.142.78]) by imc.org (8.7.4/8.7.1) with SMTP id LAA22795 for ; Tue, 12 Mar 1996 11:14:18 -0800 (PST) Received: by ns2.eds.com (hello) id OAA04712; Tue, 12 Mar 1996 14:14:10 -0500 Received: by nnsp.eds.com (hello) id OAA15367; Tue, 12 Mar 1996 14:13:40 -0500 Message-Id: <9603121909.AA08617@sccan01.mcs.eds.com> Received: from MCS with "Lotus Notes Mail Gateway for SMTP" id BC9ACE2965890561862562EB006746EC; Tue, 12 Mar 96 19:09:49 To: Rik Drummond Cc: ietf-ediint From: Paul Moo Date: 12 Mar 96 13:08:42 EDT Subject: Re: X.435 Structure Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-ietf-ediint@imc.org Precedence: bulk Rik et. al., I've noted a thread questioning the limitation of one EDI interchange to one X.435 message. I thought some background information on how this restriction came to be might prove helpful. Two issues acted to restrict designing the X.435 content type to contain multiple EDI body parts. The first deals with the lack of a mechanism for external reference between X.435 body parts. We knew that we wanted to permit multiple body parts in X.435 to allow BLOBs to accompany interchanges. With multiple interchanges in an X.435 message this would have presented the problem of which BLOB goes with which interchange. Not an insoluble problem, but we were on an ISO fast track to get the work out. The second issue dealt with mapping interchange header segment data to the X.435 header. Again, with multiple interchanges which interchanges' header (ISA or UNB) would be mapped for the X.435 header. The issues related to broadcast also where raised in the discussion. Theoretically, a single message, e.g. RFQ, might need delivery to several trading partners; why not use X.400 broadcast? The answer lies in the formation rules and controls for EDI interchanges. Each partner has unique IDs and probably control numbers in the ISA and GS (UNB, UNG) segments that must be properly generated. A single interchange cannot be broadcast using X.400 because each trading partner's copy requires individualization of IDs and control numbers. Food for thought! Good luck with extending the MIME specification; I'll go back into monitoring mode now! Regards, Paul Moo pmoo@mcs.eds.com From owner-ietf-ediint Tue Mar 12 11:58:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id LAA22963 for ietf-ediint-bks; Tue, 12 Mar 1996 11:58:09 -0800 (PST) Received: from mail1.best.com (mail1.best.com [206.86.8.14]) by imc.org (8.7.4/8.7.1) with SMTP id LAA22958 for ; Tue, 12 Mar 1996 11:58:08 -0800 (PST) Received: from agraves.vip.best.com (agraves.vip.best.com [205.149.165.153]) by mail1.best.com (8.6.12/8.6.5) with SMTP id LAA05368 for ; Tue, 12 Mar 1996 11:58:09 -0800 Date: Tue, 12 Mar 1996 11:58:09 -0800 Message-Id: <199603121958.LAA05368@mail1.best.com> X-Sender: mjansson@best.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: Mats Jansson Subject: ** EDIINT Vote Sender: owner-ietf-ediint@imc.org Precedence: bulk > >My vote: > >Priority Issue >--------------------- > >1 02 >2 01 >3 23 >4 20 >5 4 > 7 > 8 > 10 > 12 >6 15 >7 19 >--------------------- > >Mats jansson >LiNK >415-780-9039 > > From owner-ietf-ediint Tue Mar 12 14:43:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id OAA23726 for ietf-ediint-bks; Tue, 12 Mar 1996 14:43:47 -0800 (PST) Received: from ns.stercomm.com ([199.3.19.2]) by imc.org (8.7.4/8.7.1) with SMTP id OAA23721 for ; Tue, 12 Mar 1996 14:43:29 -0800 (PST) Received: from smtplink.stercomm.com by ns.stercomm.com id AA00777; Tue, 12 Mar 1996 17:42:28 -0500 Received: from ccMail by smtplink.stercomm.com (IMA Internet Exchange 1.04b) id 146008f0; Tue, 12 Mar 96 17:54:07 -0500 Mime-Version: 1.0 Date: Tue, 12 Mar 1996 17:46:46 -0500 Message-Id: <146008f0@smtplink.stercomm.com> From: David_Evangelisti@stercomm.com Subject: ** EDIINT Vote To: ietf-ediint@imc.org Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-ediint@imc.org Precedence: bulk Here's my vote: Priority 1: 02 Issue Priority 2: 07 Issue Priority 3: 08 Issue Priority 4: 12 Issue Priority 5: 04 Issue Priority 6: 15 Issue Priority 7: 22 Issue Priority 8: 23 Issue Priority 9: 11 Issue Priority 10: 03 Issue Regards, Dave Evangelisti Sterling Commerce From owner-ietf-ediint Tue Mar 12 17:43:40 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id RAA24430 for ietf-ediint-bks; Tue, 12 Mar 1996 17:43:40 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.org (8.7.4/8.7.1) with SMTP id RAA24425 for ; Tue, 12 Mar 1996 17:43:38 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA08905; Tue, 12 Mar 1996 19:47:35 -0500 Message-Id: <2.2.32.19960313004555.006f41e4@pop3.interlink.net> X-Sender: epmck@pop3.interlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 19:45:55 -0500 To: ietf-ediint@imc.org From: "E. Peter McKinney, CA" Subject: Re: ** Action: Don't forget to Vote! Cc: drummond@onramp.net (Rik Drummond) Sender: owner-ietf-ediint@imc.org Precedence: bulk I have sent my vote separately. But I feel the need to comment on some of the issues raised. At the risk of being out of order, the next editorial process , I would believe, want to take note these and others comments. Issues 3 and 6 appear to be Not Applicable to this process. I-3 : for the reasons already noted I-6 : this is covered by the other coments. Templar simply represents AN implementation of the various standards we wisah to resolve to a manageable level of inter-operability Issue 5 covers off Issue 4, thereby essentially eliminating it. Bob Lyons would have more to say on the subject of EDIFACT security. Issues 2, 7, and 8 would appear to be better handled by the resolving security group at IMC, now undergoing work on a number of issues. Dave Crocker can keep us posted on this, I hope. Issue 9 : I do not understand how X.435 can be an issue in the Internet world. Please fill me in on what I am missing. Issue 18 : This would appear to be an issue for IETF-PAY. Dave Crocker, any thoughts on that ? Issue 14 : was not included in the 1- 14 message file that I received. So I cannot comment on that. What is the issue ? Best regards, Peter ============================= E. Peter McKinney, CA McKinney, Paul & Assoc. Inc. An Information Systems and EDI/EC Consultancy Montreal, Canada [Tel: 514-852-4497 Fax: 514-329-0494] From owner-ietf-ediint Tue Mar 12 17:43:37 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id RAA24424 for ietf-ediint-bks; Tue, 12 Mar 1996 17:43:37 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.org (8.7.4/8.7.1) with SMTP id RAA24418 for ; Tue, 12 Mar 1996 17:43:34 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA16189; Tue, 12 Mar 1996 19:27:16 -0500 Message-Id: <2.2.32.19960313002520.006ec834@pop3.interlink.net> X-Sender: epmck@pop3.interlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 19:25:20 -0500 To: ietf-ediint@imc.org From: "E. Peter McKinney, CA" Subject: ** EDIINT Vote Sender: owner-ietf-ediint@imc.org Precedence: bulk > Here's my vote: > > Priority 1: 10 Issue > Priority 2: 11 Issue > Priority 3: 12 Issue > Priority 4: 20 Issue > Priority 5: 13 Issue > Priority 6: 15 Issue > Priority 7: 17 Issue > Priority 8: 19 Issue > Priority 9: 01 Issue > Priority 10: 9 Issue Best regards, Peter ============================= E. Peter McKinney, CA McKinney, Paul & Assoc. Inc. An Information Systems and EDI/EC Consultancy Montreal, Canada [Tel: 514-852-4497 Fax: 514-329-0494] From owner-ietf-ediint Tue Mar 12 20:19:40 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id UAA24990 for ietf-ediint-bks; Tue, 12 Mar 1996 20:19:40 -0800 (PST) Received: from hiway1.exit109.com (root@hiway1.exit109.com [205.164.176.32]) by imc.org (8.7.4/8.7.1) with SMTP id UAA24985 for ; Tue, 12 Mar 1996 20:19:33 -0800 (PST) Received: from ppp15-rb.exit109.com (ppp14-rb.exit109.com [205.164.176.141]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id XAA15267 for ; Tue, 12 Mar 1996 23:19:21 -0500 Date: Tue, 12 Mar 1996 23:19:21 -0500 Message-Id: <199603130419.XAA15267@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: ** EDIINT Vote Sender: owner-ietf-ediint@imc.org Precedence: bulk Here's my vote: Priority 1: 12 Issue Priority 2: 02 Issue Priority 3: 15 Issue Priority 4: 03 Issue Priority 5: 11 Issue Priority 6: 20 Issue Priority 7: 19 Issue Priority 8: 21 Issue I don't have a 9th and 10th priority, since I think the remaining issues are out of scope or unimportant. Bob Lyons Electronic Commerce Consultant Unidex, Inc. 1-908-975-9877 boblyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Wed Mar 13 06:16:33 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id GAA28754 for ietf-ediint-bks; Wed, 13 Mar 1996 06:16:33 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id GAA28749 for ; Wed, 13 Mar 1996 06:16:30 -0800 (PST) Received: from [199.184.212.223] (stockyard60.onramp.net [199.184.212.223]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id IAA09084; Wed, 13 Mar 1996 08:16:33 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Mar 1996 08:24:04 -0600 To: Paul Moo From: drummond@onramp.net (Rik Drummond) Subject: Re: X.435 Structure Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk Thanks Paul. We appreciate the comments. Later...rik >Rik et. al., > >I've noted a thread questioning the limitation of one EDI interchange to one >X.435 message. I thought some background information on how this restriction >came to be might prove helpful. > >Two issues acted to restrict designing the X.435 content type to contain >multiple EDI body parts. The first deals with the lack of a mechanism for >external reference between X.435 body parts. We knew that we wanted to permit >multiple body parts in X.435 to allow BLOBs to accompany interchanges. With >multiple interchanges in an X.435 message this would have presented the >problem >of which BLOB goes with which interchange. Not an insoluble problem, but we >were on an ISO fast track to get the work out. > >The second issue dealt with mapping interchange header segment data to the >X.435 header. Again, with multiple interchanges which interchanges' header >(ISA or UNB) would be mapped for the X.435 header. The issues related to >broadcast also where raised in the discussion. Theoretically, a single >message, e.g. RFQ, might need delivery to several trading partners; why >not use >X.400 broadcast? The answer lies in the formation rules and controls for EDI >interchanges. Each partner has unique IDs and probably control numbers in the >ISA and GS (UNB, UNG) segments that must be properly generated. A single >interchange cannot be broadcast using X.400 because each trading partner's >copy >requires individualization of IDs and control numbers. > >Food for thought! Good luck with extending the MIME specification; I'll go >back into monitoring mode now! > > >Regards, > >Paul Moo >pmoo@mcs.eds.com From owner-ietf-ediint Wed Mar 13 07:22:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA28989 for ietf-ediint-bks; Wed, 13 Mar 1996 07:22:09 -0800 (PST) Received: from sunshine.gsa.gov (sunshine.gsa.gov [159.142.1.100]) by imc.org (8.7.4/8.7.1) with SMTP id HAA28984 for ; Wed, 13 Mar 1996 07:22:00 -0800 (PST) From: Joanne.Ghahremani@gsa.gov Received: from ccgate1.gsa.gov by sunshine.gsa.gov (5.0/SMI-SVR4) id AA27226; Wed, 13 Mar 1996 10:10:32 +0500 Received: from cc:Mail by ccgate1.gsa.gov id AA826740263; Wed, 13 Mar 96 09:32:06 est Date: Wed, 13 Mar 96 09:32:06 est Message-Id: <9602138267.AA826740263@ccgate1.gsa.gov> To: helliar@edieng.enet.dec.com, drummond@onramp.net (Rik Drummond) Cc: ietf-ediint@imc.org, raj@edieng.enet.dec.com Subject: Re[2]: ** EDIINT COmments Sender: owner-ietf-ediint@imc.org Precedence: bulk I would like to respond to what I think is the area of concern: (1) the EDI name(taken out of the ISA) is mapped to the alias name in the directory or file of trading partner names to a mail address which is placed in the X.435 envelope. Therefore, it is not wise to specify the use of the entire ISA, since existing systems cannot support it. (2) Requests for quote go out to multiple addresses, which are handled by a distribution list in mail terms, rather than multiple EDI interchanges. Thus, one 840 RFQ can be issued to the distribution list or to "public" with a pointer to the list by the mail agent which both X.435 and SMTP should be able to handle.(it's just like sending an IPM to multiple recipients - each message is copied X times and sent one by one to the next recipient. X messages are not created and sent in one envelope.) The responses are 843s and are received as EDI interchanges back to be requesting procurement office. The federal government is actively using this scenario. Joanne Ghahremani ______________________________ Reply Separator _________________________________ Subject: Re: ** EDIINT COmments Author: drummond@onramp.net (Rik Drummond) at INTERNET Date: 3/12/96 7:36 AM Thanks for your comments Graham. My comments follow in the text. > >23 Comments: From Graham Helliar > >We still have no clear idea of how many EDI Interchanges go within a single= MIME=20 >message. X.435 stipulates a single EDI Interchange, so if you want to map= =20 >between MIME and X.435 you need to address this. 23 Comments: From Rik Drummond=20 Even though X.435 only allows one interchange per message, it seems a short= sighted restriction because of the *Request for Quote* type messages which= go to may addresses. To this end if we wish to have what ever we do be 1)= translatable to/from X.435 (we have not agreed on this yet) and 2) we wish= to support multiple MIME/RFC822 addresses per Interchange in our MIME= message we must know the impact this have on the translation between X.435= and MIME/EDI? What transactions does it possibly impact? The big question:= How will it affect the EDI translator? The problem may be with the= translator sending out one interchange from its point of view and receiving= multiple responses. (I assume we would not have the translator create many= messages and then stick them in a single MIME message.) I don't know the= impact. Does any body? > >04 Comments: From Graham Helliar > >>> From Rik Drummond >>> step 3) the data is copied from the EDI transaction (Step 1 output) is >>> appropriately places in the proper MIME or SMTP message > >I would be grateful for any pointers to where the 'appropriate places' are= =20 >defined. 04 Comments: From Rik Drummond Graham, I was presenting the logic used in the X.435 envelope creation. The= movement of some ISA data fields up to the X.435 envelope. I don't have the= standards in front of me, so I can't quote which data items. In the case of= MIME the only ones I can think of are the source/destination addresses= after being translated to RFC822 addresses. Should there be others, if we= encrypt the entire Interchange? Maybe we should move (copy) the entire ISA= segment into a special field in the MIME envelope so that it may be read= when the interchange is encrypted -- just a thought -- don't know if it has= any use. From owner-ietf-ediint Wed Mar 13 08:10:07 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA29181 for ietf-ediint-bks; Wed, 13 Mar 1996 08:10:07 -0800 (PST) Received: from cdshub.cdc.com (mailhub1.cdc.com [129.179.161.9]) by imc.org (8.7.4/8.7.1) with SMTP id IAA29176 for ; Wed, 13 Mar 1996 08:10:02 -0800 (PST) Received: from pigeon2.cpg.cdc.com by cdshub.cdc.com; Wed, 13 Mar 96 10:09:40 -0600 Message-ID: Date: 13 Mar 1996 10:10:12 -0600 From: "Dennis Borton" Subject: Re: ** Action- Don't forget To: ietf-ediint@imc.org X-Mailer: Mail*Link SMTP-QM 3.0.2 Sender: owner-ietf-ediint@imc.org Precedence: bulk Reply to: RE>>** Action: Don't forget to Vote! Peter, Issue 9: One perspective. Messaging solution providers and VANs have a requirement to be able to convert messages between X.400 and SMTP. Decisions made here will obviously impact their ability to effectively manage the conversion of the message. Of particular concern is the body of the message. The body of the message is generally not looked at or manipulated in the conversion process. When viewed in conjunction with the security requirements that will be defined, I believe we do need to consider the impact on X.435 as we go through this process. Dennis -------------------------------------- Date: 3/12/96 7:52 PM From: E. Peter McKinney, CA I have sent my vote separately. But I feel the need to comment on some of the issues raised. At the risk of being out of order, the next editorial process , I would believe, want to take note these and others comments. snip --------- Issue 9 : I do not understand how X.435 can be an issue in the Internet world. Please fill me in on what I am missing. snip ---------- Best regards, Peter ============================= E. Peter McKinney, CA McKinney, Paul & Assoc. Inc. An Information Systems and EDI/EC Consultancy Montreal, Canada [Tel: 514-852-4497 Fax: 514-329-0494] ------------------ RFC822 Header Follows ------------------ Received: by pigeon.cpg.cdc.com with SMTP;12 Mar 1996 19:50:43 -0600 Received: from imc.imc.org by cdshub.cdc.com; Tue, 12 Mar 96 19:50:40 -0600 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id RAA24430 for ietf-ediint-bks; Tue, 12 Mar 1996 17:43:40 -0800 (PST) Received: from RezoNet.NET (ns.RezoNet.NET [198.168.54.8]) by imc.org (8.7.4/8.7.1) with SMTP id RAA24425 for ; Tue, 12 Mar 1996 17:43:38 -0800 (PST) Received: from G536.InterLink.NET by RezoNet.NET (AIX 3.2/UCB 5.64/4.03) id AA08905; Tue, 12 Mar 1996 19:47:35 -0500 Message-Id: <2.2.32.19960313004555.006f41e4@pop3.interlink.net> X-Sender: epmck@pop3.interlink.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 1996 19:45:55 -0500 To: ietf-ediint@imc.org From: "E. Peter McKinney, CA" Subject: Re: ** Action: Don't forget to Vote! Cc: drummond@onramp.net (Rik Drummond) Sender: owner-ietf-ediint@imc.org Precedence: bulk From owner-ietf-ediint Wed Mar 13 08:43:36 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA29303 for ietf-ediint-bks; Wed, 13 Mar 1996 08:43:36 -0800 (PST) Received: from cdshub.cdc.com (mailhub1.cdc.com [129.179.161.9]) by imc.org (8.7.4/8.7.1) with SMTP id IAA29298 for ; Wed, 13 Mar 1996 08:43:15 -0800 (PST) Received: from pigeon2.cpg.cdc.com by cdshub.cdc.com; Wed, 13 Mar 96 10:42:32 -0600 Message-ID: Date: 13 Mar 1996 10:43:59 -0600 From: "Dennis Borton" Subject: **EDIINT Vote** To: "RFC 1767" X-Mailer: Mail*Link SMTP-QM 3.0.2 Sender: owner-ietf-ediint@imc.org Precedence: bulk Subject: Time: 10:35 AM OFFICE MEMO **EDIINT Vote** Date: 3/13/96 Here's my vote: Priority 1: 02 Issue Priority 2: 08 Issue Priority 3: 07 Issue Priority 4: 09 Issue Priority 5: 03 Issue Priority 6: 04 Issue Priority 7: 10 Issue Priority 8: 13 Issue Priority 9: 15 Issue Priority 10: 19 Issue Regards, Dennis Borton Control Data Systems, Inc. From owner-ietf-ediint Wed Mar 13 12:27:53 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id MAA00531 for ietf-ediint-bks; Wed, 13 Mar 1996 12:27:53 -0800 (PST) Received: from relay2.geis.com (relay2.geis.com [192.77.188.3]) by imc.org (8.7.4/8.7.1) with ESMTP id MAA00524 for ; Wed, 13 Mar 1996 12:27:50 -0800 (PST) From: milr@geis.geis.com Received: by relay2.geis.com (1.37.109.16/15.6) id AA164350245; Wed, 13 Mar 1996 20:50:45 GMT Message-Id: <199603132050.AA164350245@relay2.geis.com> Received: by (geis.)relay2.geis.com ( 2rem/1.40 ) ; Wed, 13 Mar 96 20:50:44 UTC 0000 ( from geis ; Wed, 13 Mar 96 20:49:46 UTC 0000) Date: Wed, 13 Mar 96 20:18:00 UTC 0000 To: ietf-ediint@imc.org X-Geis-Qk-From: MILR X-Geis-Qk-Id: 0264919 X-Geis-Gateway-Id: 216031 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Subject: EDIINT Sender: owner-ietf-ediint@imc.org Precedence: bulk 00 Comments: From Bob Miller This is my first exposure to the issues. As I reviewed the issues, I became concerned that the high level model which defines the environment needs clarification. No reference is made to a high level model, though proper resolution of some of these issues is dependent upon the definition of such a model. As an example, I cite the numerous issues related to security. Do we need a smorgasborg of security features at this layer, AND a (like) smorgasborg of security features at the EDI Application layer? To answer these questions, we should be able to call upon a model that defines where each security service SHOULD be performed. I believe that some of the security services defined in X12.58 (which I helped define) are there not because they are needed there, but rather as a hedge in the event they are not provided at a lower protocol layer. I believe that some of the services provided in X12.58 are required at an application layer outside the bounds of the communication layers. I believe that some of the services suggested for the MIME layer are not needed at that layer, but rather are appropriate only at a higher (application) layer. One aspect of communications should not be ignored, namely that more than one communications protocol may be involved in the transport of data from sender to recipient. That is, communications is effected via one or more 'point-to-point' data transfers, and may pass through 'gateways' to reach its destination. 01 Comments: Bob Miller IMHO, a MIME message should contain one 'unit-of-work'. Now if I just knew what a unit of work was ... I suspect that a unit-of-work means different things to different 'workers'. It might be nice to know from the meta-data what 'kind' of work unit is enclosed. Some possible units-of-work include: - A 'collection' of EDI data (A 'file' in some worlds) - An X12 MAILBAG - An X12 Interchange - An EDIFACT Interchange - An X12 Functional Group - An X12 Transaction Set - etc. 02 Comment: Bob Miller It's hard to live with 'more than one' of anything! ( But in the interest of technilogical change, I find myself having to live with 'more than one'. Note for example that many references to 'standards' include that trailing 's'! ) Start with one if you must, but design for more than one. 03 Comments: Bob Miller Unresolvable, but sensitivity to this issue is appreciated. 04 Comments: Bob Miller In the communication layers (and I view MIME as residing in these layers) it seems appropriate to me to apply security to the entire text body. If it is desirable to keep some information in the clear, copy that to the header before encryption. I assume the sender would want a voice in the copy decision. 05 Comments: Bob Miller (See also my '00 Comments') I believe that some security services may be meaningful only at the EDI application layer, that others may be meaningful only within the communication layers, and that some services may be meaningful at either/both layers (where both implies two requests for the same type of service) In the absence of a well-defined reference model, I cannot swear by my above beliefs, but am pretty darn sure that at least some of the security services provided in X12.58 need to independently be provided within the communication layer. 09 Comments: Bob Miller (See also my '00 Comments') There are a smorgasborg of communications protocols, and there is no hope of 'compatibility' among them in the sense I think this issue was meant to surface. Let the 'gateways' cope with the incompatibilities, and drop this issue. 11: Comments: Bob Miller IMHO, Key Management is a Management Application problem, not a communications problem. It must be addressed, but not at the communciations layer. The X12 815 Trransaction Set provides a Key Management tool, but Key Management is not an EDI Applications problem either. 15: Comments: Bob Miller IMHO, this should not be addressed at the communciations layer. 17: Comments: Bob Miller Let FTP do what FTP does. Leave it to another protocol to specify what to do with files transferred via FTP. 20: Comments: Bob Miller A real requirement, and not just for EDI users. To the extent that the problem is introduced by the communciations layer, it is a communciations problem, and should be addressed in that layer. 21: Comments: Bob Miller Data compression within the communication layers is a communciations issue, and should not be visible outside those layers. There is often a need to convey both data and meta-data in the same transmission. For character data, the character encoding scheme is one attribute which may need to be conveyed as meta-data. As it happens this particular attribute may be of interest to both the communciations layer and the application layer. Consideration should be given to an extensible ability to convey meta-data of interest to the application layer with the same transmission as the data. The location and syntax for conveyance of meta-data should be defined, but the list of attributes that may be conveyed should be open-ended. ZZ: Comments: Bob Miller The above comments represent my professional advice on these issues, and may or may not represent the views of my employer, GEIS, and likewise may or may not represent the views of the ANSI X12 Committee, on which I serve as Vice Chair, X12C Communciations and Controls. From owner-ietf-ediint Wed Mar 13 22:49:32 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id WAA02931 for ietf-ediint-bks; Wed, 13 Mar 1996 22:49:32 -0800 (PST) Received: from relay-4.mail.demon.net (relay-4.mail.demon.net [158.152.1.108]) by imc.org (8.7.4/8.7.1) with SMTP id WAA02926 for ; Wed, 13 Mar 1996 22:49:28 -0800 (PST) Received: from post.demon.co.uk ([158.152.1.72]) by relay-4.mail.demon.net id au20452; 13 Mar 96 17:54 GMT Received: from mirror.demon.co.uk ([158.152.45.217]) by relay-3.mail.demon.net id aa01319; 13 Mar 96 17:50 GMT Received: by mirror.demon.co.uk (Linux Smail3.1.28.1 #5) id m0twueA-000372C; Wed, 13 Mar 96 17:47 GMT Message-Id: From: Jonathan Allen Subject: ** EDIINT Vote To: ietf-ediint@imc.org Date: Wed, 13 Mar 1996 17:47:38 +0100 (GMT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ietf-ediint@imc.org Precedence: bulk Priority 1: 16 issue Priority 2: 05 issue Priority 3: 03 issue Priority 4: 04 issue Priority 5: 08 issue Priority 6: 07 issue Priority 6: 10 issue Priority 8: 12 issue Priority 9: 11 issue Priority 10: 20 issue ------------------------------------------------------------------------------ Jonathan Allen | jonathan@mirror.demon.co.uk | Voice: 01271-79023 Barum Computer Consultants | jeremiah@cix.compulink.co.uk | Fax: 01271-24183 ------------------------------------------------------------------------------ From owner-ietf-ediint Thu Mar 14 07:04:36 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA06399 for ietf-ediint-bks; Thu, 14 Mar 1996 07:04:36 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id HAA06394 for ; Thu, 14 Mar 1996 07:04:33 -0800 (PST) Received: from [199.184.212.142] (stockyard19.onramp.net [199.184.212.182]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id JAA28866 for ; Thu, 14 Mar 1996 09:04:37 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Mar 1996 09:12:11 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Re: EDIINT Sender: owner-ietf-ediint@imc.org Precedence: bulk Bob, we are working our way though the issues. They are being priorities= currently (the vote). After the vote is the time for the model to be= defined. Your point is valid ...we just have not gotten there yet. We need a tutorial on what X12.58 offers and where the possible over laps= are. Most of us are not going to purchase the X12 specifications for this= endeavor. Is there an online description of what X12.58 does, covers, and= its intended uses that you can share to facilitate the resolution of you co= ncerns? Please, let me know...Later...Rik >00 Comments: From Bob Miller >This is my first exposure to the issues. As I reviewed the issues, >I became concerned that the high level model which defines the >environment needs clarification. No reference is made to a high >level model, though proper resolution of some of these issues is >dependent upon the definition of such a model. > >As an example, I cite the numerous issues related to security. Do >we need a smorgasborg of security features at this layer, AND a >(like) smorgasborg of security features at the EDI Application layer? > >To answer these questions, we should be able to call upon a model that >defines where each security service SHOULD be performed. I believe >that some of the security services defined in X12.58 (which I helped >define) are there not because they are needed there, but rather as a >hedge in the event they are not provided at a lower protocol layer. >I believe that some of the services provided in X12.58 are required at=20 >an application layer outside the bounds of the communication layers.=20 >I believe that some of the services suggested for the MIME layer are=20 >not needed at that layer, but rather are appropriate only at a higher >(application) layer. > >One aspect of communications should not be ignored, namely that more >than one communications protocol may be involved in the transport of >data from sender to recipient. That is, communications is effected >via one or more 'point-to-point' data transfers, and may pass through >'gateways' to reach its destination. > >01 Comments: Bob Miller > >IMHO, a MIME message should contain one 'unit-of-work'. Now if I just >knew what a unit of work was ... > >I suspect that a unit-of-work means different things to different=20 >'workers'. It might be nice to know from the meta-data what 'kind' of >work unit is enclosed. Some possible units-of-work include: > - A 'collection' of EDI data (A 'file' in some worlds) > - An X12 MAILBAG=20 > - An X12 Interchange > - An EDIFACT Interchange > - An X12 Functional Group > - An X12 Transaction Set=20 > - etc. > >02 Comment: Bob Miller=20 > >It's hard to live with 'more than one' of anything! ( But in the >interest of technilogical change, I find myself having to live with=20 >'more than one'. Note for example that many references to 'standards' >include that trailing 's'! ) > >Start with one if you must, but design for more than one. > >03 Comments: Bob Miller > >Unresolvable, but sensitivity to this issue is appreciated. > >04 Comments: Bob Miller > >In the communication layers (and I view MIME as residing in these layers) >it seems appropriate to me to apply security to the entire text body. If >it is desirable to keep some information in the clear, copy that to the >header before encryption. I assume the sender would want a voice in the >copy decision. > >05 Comments: Bob Miller > >(See also my '00 Comments') > >I believe that some security services may be meaningful only at the=20 >EDI application layer, that others may be meaningful only within the >communication layers, and that some services may be meaningful at >either/both layers (where both implies two requests for the same >type of service) =20 > >In the absence of a well-defined reference model, I cannot swear by >my above beliefs, but am pretty darn sure that at least some of the >security services provided in X12.58 need to independently be provided >within the communication layer. > >09 Comments: Bob Miller > >(See also my '00 Comments') >There are a smorgasborg of communications protocols, and there is no hope >of 'compatibility' among them in the sense I think this issue was meant to >surface. Let the 'gateways' cope with the incompatibilities, and drop this >issue. > >11: Comments: Bob Miller > >IMHO, Key Management is a Management Application problem, not a communicati= ons >problem. It must be addressed, but not at the communciations layer. The >X12 815 Trransaction Set provides a Key Management tool, but Key Management= is >not an EDI Applications problem either. > >15: Comments: Bob Miller > >IMHO, this should not be addressed at the communciations layer. > >17: Comments: Bob Miller > >Let FTP do what FTP does. Leave it to another protocol to specify what to >do with files transferred via FTP. =20 > >20: Comments: Bob Miller > >A real requirement, and not just for EDI users. To the extent that the pro= blem >is introduced by the communciations layer, it is a communciations problem, = and >should be addressed in that layer. =20 > >21: Comments: Bob Miller > >Data compression within the communication layers is a communciations issue,= and >should not be visible outside those layers. > >There is often a need to convey both data and meta-data in the same transmi= ssion. >For character data, the character encoding scheme is one attribute which= may need >to be conveyed as meta-data. As it happens this particular attribute may= be of >interest to both the communciations layer and the application layer. > >Consideration should be given to an extensible ability to convey meta-data = of >interest to the application layer with the same transmission as the data. = The >location and syntax for conveyance of meta-data should be defined, but the = list >of attributes that may be conveyed should be open-ended. > >ZZ: Comments: Bob Miller > >The above comments represent my professional advice on these issues, and= may or=20 >may not represent the views of my employer, GEIS, and likewise may or may n= ot >represent the views of the ANSI X12 Committee, on which I serve as Vice Cha= ir, >X12C Communciations and Controls. ------------------------------------------------- | Rik Drummond - The Drummond Group | | 3120 Clovermeadow, Ft. Worth, TX 76123 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------- From owner-ietf-ediint Thu Mar 14 07:23:31 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA06477 for ietf-ediint-bks; Thu, 14 Mar 1996 07:23:31 -0800 (PST) Received: from wiau.wi.mt.np.els-gms.att.net (wiau.wi.mt.np.els-gms.att.net [199.191.147.41]) by imc.org (8.7.4/8.7.1) with SMTP id HAA06472 for ; Thu, 14 Mar 1996 07:23:25 -0800 (PST) Date: Thu, 14 Mar 1996 15:20:28 +0000 From: jamster@attmail.com (Jim Amster) Received: from jamster by attmail; Thu Mar 14 15:20:19 GMT 1996 Phone: +1 908 576 6462 Subject: **EDIINT Vote** To: ietf-ediint@imc.org X-MAPI-Message-ID: 00000000407F12B6D5E2CE119EA744455354000004CA2600 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Sender: owner-ietf-ediint@imc.org Precedence: bulk Here is my vote and some comments. Priority 1: 02 Priority 2: 07 Priority 3: 11 Priority 4: 12 Priority 5: 04 Priority 6: 13 02 Comments: From Jim Amster We should agree on an encryption scheme that can be used for both EDI and email. The same holds true for requirements 07, 11 and 12. 04 Comments: From Jim Amster Once encrypted, a message should be routed based on the Internet address. The end user or end user agent that must route on the ISA/IEA would have to decrypt the interchange first. If this is not acceptable in a particular scenario, then something like X12.58 (in which only a portion of the interchange is encryprted) might be more suitable for that particular scenario. The statement "use an existing encryption standard standard or combination of....." concerns me a bit. We need to settle on a scheme in conjunction with the IETF folks that are working email security. I believe they recently had a meeting in which they widdled the choices done a bit. We need to follow and coordinate closely with that effort. I believe Dave Crocker is leading that effort. 11 Comments: From Jim Amster We should also use public key cryptography for encryption. That is, not for the encryption key itself but for encrypting the encryption key. I assumed that would be the plan. For example, use public key for encrypting randomly generated DES keys if DES is used for encryption as is commonly done. 12 Comments: From Jim Amster I would like to see NRR be the same for EDI and email. In both cases, the NRR should indicate to the sender that the recipient has acknowledged getting the message and the message was not tampered with in transit. Jim Amster AT&T jamster@mail.att.net From owner-ietf-ediint Thu Mar 14 08:38:30 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA06778 for ietf-ediint-bks; Thu, 14 Mar 1996 08:38:30 -0800 (PST) Received: from mail.mel.aone.net.au (mail.mel.aone.net.au [203.12.176.157]) by imc.org (8.7.4/8.7.1) with SMTP id IAA06773 for ; Thu, 14 Mar 1996 08:38:26 -0800 (PST) Received: from mail.techrron.com.au ([203.61.167.8]) by mail.mel.aone.net.au (8.6.11/8.6.11) with SMTP id DAA14814 for ; Fri, 15 Mar 1996 03:38:29 +1100 Message-Id: <199603141638.DAA14814@mail.mel.aone.net.au> X-Sender: ca065472@mail1.mel.aone.net.au X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Mar 1996 00:35:35 +1000 To: ietf-ediint@imc.org From: ejc@techrron.com.au (Erron Criddle) Subject: Issues needed Sender: owner-ietf-ediint@imc.org Precedence: bulk To someone, I would like to vote on EDIINT but I cannot find them in the folder. Could someone please re-post them so I can look at them. Thank you. Erron Criddle Techrron Holdings ejc@techrron.com.au From owner-ietf-ediint Thu Mar 14 12:21:57 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id MAA08231 for ietf-ediint-bks; Thu, 14 Mar 1996 12:21:57 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id MAA08226 for ; Thu, 14 Mar 1996 12:21:46 -0800 (PST) Received: from [199.184.212.203] (stockyard40.onramp.net [199.184.212.203]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id OAA02282 for ; Thu, 14 Mar 1996 14:21:48 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Mar 1996 14:29:28 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: RFC1865 on EDI Meets the Internet Sender: owner-ietf-ediint@imc.org Precedence: bulk >To: IETF-Announce:; >Subject: RFC1865 on EDI Meets the Internet >Cc: jkrey@isi.edu >Mime-Version: 1.0 >Date: Wed, 03 Jan 96 15:02:42 PST >Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US >From: "Joyce K. Reynolds" > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 1865: > > Title: EDI Meets the Internet > Frequently Asked Questions about > Electronic Data Interchange (EDI) on the Internet > Author: W. Houser, J. Griffin & C. Hage > Date: January 1996 > Mailbox: houser@cpcug.org, agriffin@cpcug.org, > carl@chage.com > Pages: 41 > Characters: 98,361 > Updates/Obsoletes: none > > URL: ftp://ds.internic.net/rfc/rfc1865.txt > > >This memo is targeted towards the EDI community that is unfamiliar >with the Internet, including EDI software developers, users, and >service providers. The memo introduces the Internet and assumes a >basic knowledge of EDI. > >This memo provides information for the Internet community. This memo >does not specify an Internet standard of any kind. Distribution of >this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@ISI.EDU. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@ISI.EDU with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@ISI.EDU > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > >Submissions for Requests for Comments should be sent to >RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. > >Content-Type: text/plain >Content-ID: <960103150034.RFC@ISI.EDU> > >[This attachment must be fetched by mail. >Open the stationery below and send the resulting >message to get the attachment.] >Attachment converted: Internal 540:Get RFC1865 on EDI Meets the In (EuSn/CSOm) (00006BF5) >Content-Type: Message/External-body; > name="rfc1865.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="rfc" > >[This attachment must be fetched by ftp. > Open the document below to ask your ftp client to fetch it.] >Attachment converted: Internal 540:Get rfc1865.txt (AURL/Arch) (00006BF6) >Content-Type: text/plain >Content-ID: <960103150034.RFC@ISI.EDU> > ------------------------------------------------- | Rik Drummond - The Drummond Group | | 3120 Clovermeadow, Ft. Worth, TX 76123 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------- From owner-ietf-ediint Fri Mar 15 07:21:46 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA14135 for ietf-ediint-bks; Fri, 15 Mar 1996 07:21:46 -0800 (PST) Received: from tom.compulink.co.uk (tom.compulink.co.uk [194.153.0.51]) by imc.org (8.7.4/8.7.1) with SMTP id HAA14128 for ; Fri, 15 Mar 1996 07:21:35 -0800 (PST) Received: (from root@localhost) by tom.compulink.co.uk (8.6.9/8.6.9) id PAA29497 for ietf-ediint@imc.org; Fri, 15 Mar 1996 15:19:35 GMT Date: Fri, 15 Mar 96 15:19 GMT From: ahinchley@cix.compulink.co.uk (Andrew Hinchley) Subject: EDIINT vote To: ietf-ediint@imc.org Cc: ahinchley@cix.compulink.co.uk Reply-To: ahinchley@cix.compulink.co.uk Message-Id: Sender: owner-ietf-ediint@imc.org Precedence: bulk Here ar my votes on priorities:- Priority 1: 20 Priority 2: 02 Priority 3: 04 Priority 4: 07 Priority 5: 08 Priority 6: 10 Priority 7 12 Developing detailed comments to follow shortly Andrew Hinchley ahinchley@cix.compulink.co.uk From owner-ietf-ediint Sat Mar 16 09:35:51 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id JAA23173 for ietf-ediint-bks; Sat, 16 Mar 1996 09:35:51 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id JAA23168 for ; Sat, 16 Mar 1996 09:35:46 -0800 (PST) Received: from [199.184.212.118] (turnpike19.onramp.net [199.184.212.118]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA14745 for ; Sat, 16 Mar 1996 11:35:53 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 16 Mar 1996 11:43:33 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** EDIINT - The Next Step Sender: owner-ietf-ediint@imc.org Precedence: bulk Chuck Shih, Mats Jansson and I will spend the next 14 days writing up the= statements below into some sort of Statement-of-Work.=20 Priority 1 - 02 ISSUE: STANDARD ENCRYPTION SCHEME=20 Priority 2 - 12 ISSUE: NON-REPUDIATION OF RECEIPT Priority 3 - 04 ISSUE: TRANSACTION PRIVACY Priority 3 - 07 ISSUE: CONTENT INTEGRITY Priority 4 - 08 ISSUE: AUTHENTICATION Priority 5 - 15 REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION= =20 Priority 5 - 20 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND ..= .... Priority 6 - 03 ISSUE: WORLDWIDE ENCRYPTION Priority 6 - 10 ISSUE: NON-REPUDIATION OF ORIGIN Priority 8 - 11 ISSUE: KEY MANAGEMENT Priority 8 - 01 ISSUE: EDI OBJECT BOUNDARIES Until then we as a group need to do two things: - Get further tutorial information on how X12, EDIFACT and RFC's= efforts impact our area - Develop an Outline of the final paper - Due by end of March On the side, I am contacting the companies on the list that _develop EDI= software_ to discuss with them concerns they may have with actually= implementing the resulting recommendations/ standards. It is not clear to me that we have their attention to the appropriate= degree necessary to result in inter operable products. If you are from one of the _EDI software developing companies_ , and you= have not received an invitation for a conference call on the subject from= me, please contact me soonest. We have accomplished a lot.... we have a lot more to do. It is very= important that those of you that have expertise or papers related to our= focus about X12, EDIFACT, IETF or other groups that you distribute them to= the list to further educate others. We need X12.58 info. Have a nice weekend...Later....Rik ------------------------------------------------- | Rik Drummond - The Drummond Group | | 3120 Clovermeadow, Ft. Worth, TX 76123 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------- From owner-ietf-ediint Sat Mar 16 09:41:21 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id JAA23214 for ietf-ediint-bks; Sat, 16 Mar 1996 09:41:21 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id JAA23207 for ; Sat, 16 Mar 1996 09:41:16 -0800 (PST) Received: from [199.184.212.118] (turnpike19.onramp.net [199.184.212.118]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id LAA15308 for ; Sat, 16 Mar 1996 11:41:08 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 16 Mar 1996 11:48:48 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** EDIINT - Vote Results Sender: owner-ietf-ediint@imc.org Precedence: bulk Well, the vote is in. Because of ties 11 issues that predominated in the voting. The scores are: Issue Score --------------- ------- Issue 2 95 Issue 12 66 Issue 4/7 55 Issue 8 41 Issue 15/20 36 Issue 10/3 29 Issue 11/1 25 The issues in order of priority are: Priority 1 - 02 ISSUE: STANDARD ENCRYPTION SCHEME Priority 2 - 12 ISSUE: NON-REPUDIATION OF RECEIPT Priority 3 - 04 ISSUE: TRANSACTION PRIVACY Priority 3 - 07 ISSUE: CONTENT INTEGRITY Priority 4 - 08 ISSUE: AUTHENTICATION Priority 5 - 15 REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION Priority 5 - 20 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND ...... Priority 6 - 03 ISSUE: WORLDWIDE ENCRYPTION Priority 6 - 10 ISSUE: NON-REPUDIATION OF ORIGIN Priority 8 - 11 ISSUE: KEY MANAGEMENT Priority 8 - 01 ISSUE: EDI OBJECT BOUNDARIES Later....Rik ***************************************************************************** 01 ISSUE: EDI OBJECT BOUNDARIES - The specifications by this work group apply to the EDI interchange level, and not the group or document level. Any security services, packaging, transport services, non-repudiation services, etc. is assumed to be applied to an EDI interchange. The definition of an interchange for MIME types Application/EDIFACT and Application/EDI-X12 is controlled by the relevant standards, and should be defined between trading partners who choose to use the Application/EDI-Consent MIME type. Multiple interchanges can however be sent at one time. 01 Comments: From Rik Drummond Since we are only transporting the transactions (EDIFACT messages) our interest should stop at the transaction level (entire X12 envelope) and not the Group level. 01 Comments: From Trevor Richards If I understand the issue correctly, it is suggesting that we only consider transporting transaction sets (X12:ST segment through SE, EDIFACT:UNH segment through UNT) only via the Internet, or at least provide the option to do so. The mandatory control segments (X12:ISA, GS, GE, IEA, EDIFACT:UNB, UNZ) contain both counters to ensure data integrity and information about the interchange control segment standard version (X12:X12.5, EDIFACT: ISO 9735) used to construct the transaction sets/messages. Our interest must start at the interchange level, as this is an integral part of the transmission of transaction sets/messages. The group level is (i) mandatory for X12 interchanges as it contains the standard version used to construct the transaction sets, and (ii) optional for EDIFACT messages as the standard version/release information is carried in the UNB segment. 01 Comments: Chuck Shih The assumption is that the EDI interchange, which includes the enveloping segments is the basic unit of packaging, transport, security services, etc. ******************************************************************************** 02 ISSUE: STANDARD ENCRYPTION SCHEME - In order to provide confidentiality for EDI interchanges on the Internet, a standard encryption algorithm(s) and key length(s) must be specified. 02 Comments: From Harald T. Alvestrand Agreed. MOSS is my recommendation. (NOTE - this may change over time; things are happening quickly. I believe security multiparts is stable, but MOSS might not be.) 02 Comments: From Chuck Shih Giving too many options in a standard will almost guarantee interoperability problems when implemented. This is one problem with the MOSS specification. I feel that for any encryption algorithm or other security algorithms that need specification, that we limit the options, or pick an existing standard that limit the options. 02 Comments: From Rik Drummond We should be thinking about defining a *standards profile* which covers the whole area of EDI over the Internet. A standards profile takes existing standards, and standards-options and reduces them to one or a very few so that implementation issues are reduced to one or a few options. This insures better general interoper- ability, less interoperability testing (less options to test), and less coding personpower. Since we must show interoperability in this effort soon after the RFC is released, we must focus on the *profile* idea for a quick RFC and interoperability establishment. ******************************************************************************** 03 ISSUE: WORLDWIDE ENCRYPTION - The chosen encryption algorithm(s) must work across the world and not be limited by export or legal restrictions. 03 Comments: From Harald T. Alvestrand This is a "can't do". France has outlawed all encryption unless specifically authorized by the French ministry of security. (It is operated in the "we won't do anything to catch you, but if we need to get you for something, we have you on file" mode, I think) 03 Comments: From Chuck Shih From an export and licensing point of view there will always be legal restrictions on exporting security related products, more specifically with key lengths. This still does not invalidate the standardization work in the sense that the standards that are specified, if implemented outside the U.S. should still be able to interoperate with a standard implementation done within the U.S. ******************************************************************************** 04 ISSUE: TRANSACTION PRIVACY - Encryption of the entire EDI transaction within MIME is to include the EDI enveloping segments as well as the EDI documents, i.e., the ISA/IEA or UNA/UNB/UNZ are also encrypted. Use an existing encryp- tion standard or combination of standards such as PGP, DES, MOSS, or S/MIME. 04 Comments: From M. Greely I also believe that the ISA is critical for the document routing by standard means today. I can not route EDI files without it. The catch 22 could be that it also lets you know who is sending what to where. If it stays unencrypted who is to say that the ISA was not changed. 04 Comments: From HARALD T. ALVESTRAND Should be "no problem". Just pick the right standard (MOSS is in my opinion) 04 Comments: From Rik Drummond The sequence of events to accomplish the re-enveloping of an EDI transaction into a MIME envelope is: Step 1) Translator translates the internal format to EDI format (X12, EDIFACT, etc.), Step 2) copies of pertinent control information from "step 1" format are made and the entire EDI formatted transaction is encrypted and placed in a MIME envelope, step 3) the data copied from the EDI transaction (Step 1 output) is appropriately placed in the proper MIME or SMTP message. In step 3 sometimes one-to-one translations may be necessary such as is the case for the DUNS number address being translated into the appropriate Internet Address. If we have to leave the control EDI segments out of the encryption - which implies disassembling encrypting and reassembling the EDI transaction - then we should not even attempt to handle this option. We should push back on the translator vendors to do this. We should not .. ******************************************************************************* ******************************************************************************** ******************************************************************************** 07 ISSUE: CONTENT INTEGRITY - Protect the contents of an EDI message so that the receiver is guaranteed that the message arrived in its originally sent state. Provide a method to detect any modifications - additions, deletions, or changes to the original EDI message. 07 Comments: From HARALD T. ALVESTRAND Already done if you do signatures on the data 07 Comments: From Kit Lueder .... you may want to have integrity without confidentiality (e.g. so that the X12 headers are visible for relay by EDI VANS). 07 Comments: From CHUCK SHIH Content Integrity can be achieved by the sender including with the EDI Interchange an integrity control value. This value can be computed by using an appropriate cryptographic algorithm (MD5, SHA) to 'fingerprint' the EDI Interchange. Since the control value or 'fingerprint' itself is unprotected, additional measures such as digitally signing the control value is usually done. Thus content integrity is typically obtained as a result of message origin authentication or non-repudiation of origin. ******************************************************************************** 08 ISSUE: AUTHENTICATION - Guarantee or authenticate by use of digital signatures the identity of the sender of an EDI Interchange. Specify the algorithms, hash functions, and key lengths to be used in order to provide this functionality. 08 Comments: From CHUCK SHIH EDI Interchange authentication can be achieved by including with the EDI Interchange an authentication value. The authentication value would be dependent on the message contents and a sender's private key. Use of asymmetric or public-key algorithms solves the problem of the sender and receiver having to know or exchange private keys, so it is typically the case that EDI Interchange authentication is obtained as a result of non-repudiation of origin. Non-repudiation of origin can be achieved by use of a digital signature. 08 Comments: From This means a certificate distribution mechanism, I think. 08 Comments: From HARALD T. ALVESTRAND I suggest again sticking with MOSS for the basic standard. ******************************************************************************** ******************************************************************************** 10 ISSUE: NON-REPUDIATION OF ORIGIN - Non-repudiation of origin protects the receiver of the EDI interchange from the sender's denial of having sent the interchange. By using the non-repudiation of origin feature on an EDI inter- change, interchange authentication and content integrity are also achieved. (See issues on integrity and authentication). A key-management infrastructure or key certificate mechanism needs to be specified as well as digital signature algorithms, hash functions, and key lengths. 10 Comments: From HARALD T. ALVESTRAND As above (with authentication) you need a certificate hierarchy. ******************************************************************************** 11 ISSUE: KEY MANAGEMENT - The assumption is that public-key cryptography will be used for non-repudiation of origin/receipt, authentication, and integrity. Use of public-key cryptography requires the use of the trading partner's public-key. Standardization of the mechanism of public-key distribution and authentication among trading partners needs to be specified. 11 Comments: From HARALD T. ALVESTRAND Agreed. I hope we have at least ONE key distribution/authentication mechanism standardized "soon". 11 Comments: From Lori Blackburn Additional issue related to Key Management... Who will be the keepers of the Public and Private keys? I once heard a rumor the Post Office wanted to get into that business...? 11 Comments: From Chuck Shih The strength of any security program is pretty much dependent on your private key. So each trading partner must keep their private keys private. The Post Office and companies like Verisign are considering becoming public key certifying authorities, i.e. they will sign and vouch for public keys. ******************************************************************************** 12 ISSUE: NON-REPUDIATION OF RECEIPT - The sender of an EDI message obtains undeniable proof that the recipient received the message and the message was not altered in transit. Non-repudiation of receipt is implemented via an acknowledgment; the recipient of an EDI message returns this acknowledgment to the sender of the EDI message. This acknowledgment contains a digital signature applied to the original EDI message; also, the acknowledgment itself is digitally signed. Receipt acknowledgment is applied at the EDI Interchange level, and can consist of multiple receipts if multiple EDI Interchanges have been packaged together. 12 Comments: From HARALD T. ALVESTRAND Receipt is an issue being worked on in the RECEIPT WG. But it doesn't address your issues. EDI-formatted receipts, digitally signed using MOSS, might be an answer. 12 Comments: From Ken Steel Might I strongly recommend the non-repudiation of receipt is not tied in any way to an EDI method. Whatever is done should be equally applicable to X.12, EDIFACT, Open-edi and any other flavour that comes along. .... Using solutions such as 997 means we are all wasting our time on this - it is not a universal solution - just another contribution to the non-standard mess called edi. 12 Comments: From Bob Lyons Note that a trusted third party, such as an EDI VAN, can provide non-repudiation of receipt without the use of digital signatures. However, most, if not all, Internet Service Providers do not offer this service. MOSS, PEM, PGP and S/MIME meet most of the security requirements of users doing EDI over the Internet; however, they do not provide non-repudiation of receipt. The IETF-EDIINT group should try to persuade any IETF groups working on e-mail security and e-mail receipts to develop a standard for non- repudiation of receipt. We should also align ourselves with any other groups that need this feature for their Internet e-mail applications. A possible interim solution is to use the 997. The receiver of an EDI message would place the digital signature of this EDI message into a 997, and return the 997 to the sender of the original EDI message. The problem with this solution is that e-mail users, EDIFACT users and proprietary EDI users will not want to use an ANSI X12 transaction set for non-repudiation of receipt. This will result in multiple solutions for non-repudiation of receipt (i.e. one for e-mail, one for X12-based EDI, one for EDIFACT-based EDI, etc.) Another possible interim solution is to use the EDIFACT AUTACK message, which was designed to provide non-repudiation of receipt. This is how Premenos's Templar product provides non-repudiation of receipt. However, this solution has the same problem as the 997-based solution. 12 Comments: From Jim Amster I agree that we need to have a generic method that goes beyond EDI. The effort to define a non-repudiable receipt would seem to be an activity that might be co-worked with the IETF Notary group. That group recently published the following RFCs: RFC 1894 An Extensible Message Format for Delivery Status Notifications RFC 1891 SMTP Service Extension for Delivery Status Notifications There had been some discussion in that group of generating a work item on receipts. I am not sure if that item is still under development, has been suspended or what. It would seem that non-repudiation could be added to that work item. 12 Comments: From Thomas A. Darling I suspect some of the discussion around the NRR can be clarified if we distinguish two alternative types of business needs for NRR. The first, and I suspect far more common, need is to know that the trading partner has received the message (alive and intact). At that point I can expect the TP to be under some obligation to fulfill its responsibilities in our relationship (e.g. send me an order, etc.) Because the functional acknowledgment is generated later in the receiver's processing (after they've had a chance to check that the message makes sense to them), it satisfies this need much better than a notification that the message arrived in a mailbox. [For example, I would be loathe to enter into a TPA in which I incurred obligations because mail was put in my box, whether I had been able to read it or not, etc., etc. (Especially after my ISP went down for 3 hours this afternoon)] With traditional FAs, if my translator doesn't get back the acknowledgement within some agreed upon period I will either re-submit or contact the TP through another medium. In other words, this type of solution needs no furthur attention from the group(?) - it is not related to the transport of the message, but the solution is at the EDI Application layer. Aside - Assuming the TPs are using both authentication and message inte- grity checks, there is no reason I can think of to include the MIC in the reply, since the check of the hash by the receiver has been successful. (Am I confused on this?) ........ 12 Comments: Chuck Shih I mostly agree with T. Darling's analysis of the NRR. The mailbox NRR is being addressed by some of the e-mail working groups in the IETF, and we should make use of any mechanism they come up with. The NRR for EDI is at a higher level than the mailbox NRR. The NRR of the EDI Interchange satisfies the requirement of the sender that not only has the EDI inter- change been delivered to a mailbox, but the receiver has authenticated the EDI interchange (knows it truly is from the TP), and the integrity of the EDI interchange is intact - nobody changed the original purchase order from 50 widgets to 5000 widgets for instance. The receiver can then honor the EDI interchange on its end, and by sending back the NRR the sender knows that the receiver has acknowledged getting the interchange (and not just a mail message) and the interchange was not tampered with in transit. If the EDI NRR contains the MIC of the original interchange, then the sender can verify that what the receiver acknowledged was what the sender actually sent, and this can be archived or logged. By relying only on the subsequent 997, the level of security is not as strong, since the 997 does not directly correlate to a received interchange except by use of the control number. By sending the MIC back with the NRR, the sender can absolutely derive the original message that was sent from the information in the NRR. An additional comment on use of the AUTACK versus 997 for NRR. There is a difference between using AUTACK and 997 for NRR, in that the AUTACK was architected specifically for NRR by EDIFACT and contains the formats for the security objects while the 997 was never architected to do this by X12. I am not even sure how some of the security information could be sent back in the 997. (See Bob Lyons comment.) ******************************************************************************** 15 REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION (Original #15 and #17) The specification must describe what type of notifications and acknowledgments a sender should receive, taking into consideration Non- repudiation of receipt, 997's, 993's, AUTACK's, and existing pre-997 VAN- provided delivery status. 15 COMMENT: From Unknown Currently, you can get from a VAN separate sets of messages denoting message delivery, in advance of a 997. Given that ISPs do not have the management software to provide similar support, it might be advisable for IETF-EDI to be aware of and perhaps integrate the notification work now going on Title : An Extensible Message Format for Delivery Status Notifications Author(s) : K. Moore, G. Vaudreuil Filename : draft-ietf-notary-mime-delivery-07.txt Pages : 35 Date : 09/21/1995 15 COMMENT: From Carl Hage This is now . There are also some related RFCs: -The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages -Enhanced Mail System Status Codes -An Extensible Message Format for Message Disposition Notifications 15 COMMENT: From Harald Alvestrand This is now an RFC (one of a set of four). RFC 1891-1894. 15 COMMENT: From Mats Jansson I think the fact that internet EDI is point-to-point, as compared to the store-and-forward nature of VAN traffic, obliterates the need for any inter- im status. My experience is that non-repudiation of receipt acknowledgments are received within 45-90 seconds - why would I need anything in-between? Also, it brings up the question of the need for a 997. Given the installed base of translators out there, I think we need to assume that 997's will be used, if not as a means of acknowledging receipt, as a way to confirm that a transmission was translated in compliance. ************************************************************* 20 REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND OUT-OF-SEQUENCE MESSAGES (original #23, #26 and #27) Specification should define how message tracking should be handled, and especially its relationship to other tracking mechansims in translators, applications. In addition, weigh the benefit of tracing versus simply re-transmitting in case of problems. Also, address the frequent sequence problems with internet routing. 20 COMMENT: From Unknown EDI users need an automated means to detect missing, duplicate or out-of-sequence messages, where the sequencing problem is caused by the communications layer (e.g., the Internet e-mail software) or the security layer. Sequence problems caused by the business application or the EDI translator are not within the scope of this requirement. This feature is normally provided by the EDI translator that verifies that the interchange control numbers (ICNs) are received in the correct sequence. If this feature was provided by a layer below the EDI translator (e.g., the security layer or the communications layer), then it could be used by e-mail users, proprietary EDI applications that don't use an EDI translator, and EDI applications where one of the trading partner's has a translator that does not validate ICN sequencing. 20 COMMENT: From Unknown I think the thread of this has been touched upon on Interchange sequence numbers, but what additional management constructs do we need to come up with when doing EDI over the Internet. For instance, today if two EDI Interchanges are sent through a VAN with control numbers, and one of them does not arrive at the receiver, the receiver can call the VAN and attempt to trace it. What mechanisms would the receiver use in this scenario when sending EDI over the Internet? 20 COMMENT: From Carl Hage One thing that would simplify the tracking of messages through mailers, ateways, and networks, is to use some standards for the Message-Id: and Subject: headings, where the ICN can be included. This may also simplify some logging and auditing issues. 20 COMMENT: From Harald Alvestrand I can't help you define this :-) 20 COMMENT: From Mats Jansson Although my experience has been very good (eg no lost messages) so far, I believe a mind shift is in order. If a transmission does not arrive within specified time, to generate an acknowledgment back to the sender, don't spend any energy tracing, just re-transmit. It's important to note, though, that this puts the burden of identifying duplicates on translators and/or applications. Is this OK? 20 COMMENT: From Unknown Internet e-mail does not guarantee message sequence integrity. In other words, message N+1 may be delivered before message N. Some EDI VANs provide message sequence integrity. There are probably some EDI applications that require message sequence integrity. 20 COMMENT: From Harald Alvestrand Are you arguing for putting a sequence number into the MIME headers? If so, that should be relatively easy. 20 COMMENT: From Mats Jansson This is a common problem. Frequently, a message (A) sent before message (B) is received in reversed order, due to internet routing paths. I suppose we could say that the internet EDI gateway tool should have the capability to buffer incoming messages and re-order them according to some sequence ID. 20 COMMENT: From Carl Hage The sequence should be enforced by the receiving EDI system, not the mailer. (It's built into X12 and EDIFACT.) However, the message sequence number can be useful for tracking messages through mailers. 20 COMMENT: From Unknown Let's make sure that we don't impose controls at the communications layer which are not in place in the underlying EDI standards. Message sequence integrity is a trading partner dependent issue. If the issuer of the interchange control numbers uses any other scheme than sequential numbers by trading partner, checking for this at the communications layer could cause more problems than it solves. ------------------------------------------------- | Rik Drummond - The Drummond Group | | 3120 Clovermeadow, Ft. Worth, TX 76123 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------- From owner-ietf-ediint Thu Mar 28 21:26:53 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id VAA13083 for ietf-ediint-bks; Thu, 28 Mar 1996 21:26:53 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id VAA13078 for ; Thu, 28 Mar 1996 21:26:49 -0800 (PST) Received: from [199.184.212.216] (stockyard53.onramp.net [199.184.212.216]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id XAA02372 for ; Thu, 28 Mar 1996 23:27:46 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Mar 1996 23:36:03 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: **EDIINT Status Sender: owner-ietf-ediint@imc.org Precedence: bulk The list is still active -- just quiet. The editors and I are editing the comments and putting together the proposed outline. You should see it in less than a week. Also, we will have had two conference calls with EDI software developing companies. The objectives of the calls were five things: - Make sure they believe we are goingin the correct direction - Ensure we are addressing actual problems they are having in using EDI over Internet - Make sure they have the correct personnel on the EDIINT list and will be able to offer manpower to help with the effort - Ensure that they understand the expectation that we need to inter-operability test whatever our recommendations are later this year. - Discuss some inter-cooperation options with CommerceNet The above were all positive during our conference call....Looks like we are on our way. Later...Rik ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Fri Mar 29 07:29:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA17605 for ietf-ediint-bks; Fri, 29 Mar 1996 07:29:54 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id HAA17592; Fri, 29 Mar 1996 07:29:50 -0800 (PST) Received: from [199.184.212.193] (stockyard30.onramp.net [199.184.212.193]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id JAA08055; Fri, 29 Mar 1996 09:30:23 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Mar 1996 09:38:45 -0600 To: ietf-ediint@imc.org, ietf-ediint-request@imc.org From: drummond@onramp.net (Rik Drummond) Sender: owner-ietf-ediint@imc.org Precedence: bulk ietf-ediint-for-rik ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Fri Mar 29 08:19:01 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA17923 for ietf-ediint-bks; Fri, 29 Mar 1996 08:19:01 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id IAA17918 for ; Fri, 29 Mar 1996 08:18:59 -0800 (PST) Received: from [199.184.212.215] (stockyard52.onramp.net [199.184.212.215]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id KAA19343 for ; Fri, 29 Mar 1996 10:19:56 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Mar 1996 10:28:14 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ** EDIINT Paper Outline Sender: owner-ietf-ediint@imc.org Precedence: bulk The proposed paper outline is below. It is a major deliverable and is due the end of March 1996. Let me know if you have any comments on it. The ** indicate complete now. The TBD indicate complete later in the process.......later....Rik Final Paper Outline Purpose - TBD Partisipants - TBD Introduction - The issue / problem - ** - What and how we are attempting to solve it - TBD - The process we used - TBD - Quick overview of the subsections - ** Subsections - ** - ISSUE: STANDARD ENCRYPTION SCHEME - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: NON-REPUDIATION OF RECEIPT - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: TRANSACTION PRIVACY - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: CONTENT INTEGRITY - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: AUTHENTICATION - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - REQUIREMENT - DETECTION OF MISSING, DUPLICATE AND ...... - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: WORLDWIDE ENCRYPTION - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: NON-REPUDIATION OF ORIGIN - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: KEY MANAGEMENT - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc - ISSUE: EDI OBJECT BOUNDARIES - Introduction/ Description - ** - Statement of work - ** - issues (from coments and other) -** - Recommended solution - etc Summary ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Fri Mar 29 08:19:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA17935 for ietf-ediint-bks; Fri, 29 Mar 1996 08:19:18 -0800 (PST) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id IAA17916 for ; Fri, 29 Mar 1996 08:18:48 -0800 (PST) Received: from [199.184.212.215] (stockyard52.onramp.net [199.184.212.215]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id KAA19292 for ; Fri, 29 Mar 1996 10:19:39 -0600 (CST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Mar 1996 10:27:57 -0600 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: A brief comparison of email encryption protocols Sender: owner-ietf-ediint@imc.org Precedence: bulk Since one of the issues we have to address is picking an encryption methodogy, I thought it would be appropriate to reread the below....later....rik >Date: Fri, 16 Feb 1996 09:25:49 -0500 >X-Sender: boblyons@hiway1.exit109.com >Mime-Version: 1.0 >To: ietf-ediint@imc.org >From: boblyons@unidex.com (Robert C. Lyons) >Subject: A brief comparison of email encryption protocols >Sender: owner-ietf-ediint@imc.org >Precedence: bulk > >I thought that this might be of interest to the group. >It was posted to the pem-dev mailing list. > >Bob Lyons > >>Reply-To: pem-dev-request@neptune.tis.com >>Date: Wed, 14 Feb 1996 12:49:44 -0800 (PST) >>From: Raph Levien >>Subject: A brief comparison of email encryption protocols >>To: cypherpunks@toad.com, coderpunks@toad.com, resolving-security@imc.org, >> pgp-mime@purpletape.cs.uchicago.edu, pem-dev@neptune.tis.com >>Sender: pem-dev-request@neptune.tis.com >>Precedence: bulk >> >> This message briefly reviews and compares the four major email >>encryption protocols under discussion: MOSS, PGP, PGP/MIME, and >>S/MIME. Each is capable of adequate security, but also suffers from >>the lack of good implementation, in the context of transparent email >>encryption. >> >> I will try to address issues of underlying cryptographic soundness, >>ease of integration with email, implementation issues, support for >>multimedia and Web datatypes, and backwards compatibility. >> >> An additional grave concern is key management. Contrary to some >>beliefs, key management is not a solved problem. All of the proposals >>contain some mechanism for key management, but none of them have been >>demonstrated to be scalable to an Internet-wide email system. My >>belief is that the problems with key management do not stem from the >>classic Web of trust/certification hierarchy split, but the >>nonexistence of a distributed database (with nice interfaces) for >>holding keys. The encryption protocols also stand in the way of such a >>database, with key formats that are either overly complex, inadequate, >>or both. >> >> In case it is not clear by now, this review will be quite >>subjective, in many cases representing my own beliefs rather than >>objective fact. I'll try to point that out where I can. Also, I do not >>claim to have a thorough understanding of PEM and PKCS. Much of my >>knowledge comes from implementing premail, a tool that acts as "glue" >>between mailers and encryption packages. It supports PGP, MOSS (using >>the TIS/MOSS 7.1 implementation), and a draft of PGP/MIME, in addition >>to a wide range of anonymous remailer services. While usable, premail >>has many limitations, and certainly does not represent the "holy >>grail" of transparent email/crypto integration. Thus, my participation >>in the Internet Mail Consortium Secuirty Workshop >>(http://www.imc.org/security-workshop.html). >> >> I apologize for the wide distribution, and ask that followups be >>trimmed. >> >> >>PGP >>--- >> >> PGP (Pretty Good Privacy) is, of course, the de facto standard for >>email encryption on the Internet. >> PGP's underlying cryptography is quite sound - RSA (up to 2048 bits >>with the most recent implementation), IDEA with a 128 bit key, and >>MD5. PGP is entirely in accordance with the recent recommendations on >>minimum keylength (http://www.bsa.org/bsa/cryptologists.html), and in >>fact does not include a mode of operation in violation of those >>recommendations. This makes PGP (and, by extension, PGP/MIME) unique >>among the encryption protocols. >> PGP is packaged in a single application (i.e. a single binary) >>which performs encryption, decryption, signing, verification, and key >>management. It does not depend on the existence of great deal of >>infrastructure. These factors have, in my opinion, been decisive in >>PGP's popularity. >> >> However, PGP is still not suitable for fully transparent email >>encryption. The reasons are complex, and I will only touch on them >>here. >> >> The main missing feature is the lack of MIME integration. Thus, PGP >>is not suitable for multimedia types other than US-ASCII text. PGP >>does contain some support for 8-bit charsets, but at cross-purposes >>with MIME. Signature checking of non-US-ASCII data is simply not >>reliable. To give an idea of this problem, the most recent >>international version (2.6.3i) tries several different character set >>conversions when verifying signatures, to see if any of them will >>work. >> However, since a large fraction of email _is_ US-ASCII text, this >>feature alone probably does not explain the lack of deployment. PGP >>contains a number of implementation flaws (including silly things like >>not locking files, so that concurrent invocations fail). In addition, >>key management has some problems. Mostly, key management is hard to >>learn, time consuming, and requires a great deal of manual >>intervention. The "Web of trust" is supposed to fix this, by providing >>transitive trust of key authenticity. However, in practice the Web of >>trust has not delivered. In my experience (with many dozen >>correspondents), I have only had one or two keys transitively trusted. >> >> A standard PGP-signed message consists of a "-----BEGIN PGP SIGNED >>MESSAGE-----" line, the signed text (subject to some canonicalization >>rules), a "----BEGIN PGP SIGNATURE-----" line, a version line, the PGP >>signature itself, and an "-----END PGP SIGNATURE-----" line. All this >>is in the message body. The headers indicate that the message is a >>standard 7-bit, us-ascii, text/plain message. Thus, mailers have to >>parse the message contents to identify the message as PGP signed, or >>to extract the signed parts. This is at cross-purposes with MIME. >>Mailer implementors are reluctant to include such ad-hoc extensions. >>Existing extensibility mechanisms, based on MIME, cannot be used. >> PGP encrypted messages are similar - the identification as an >>encrypted message can only be made by parsing the message body. >> >> One technical problem with PGP is its inability to support >>single-pass processing, because the data format includes a size >>field. >> >> >>PGP/MIME >>-------- >> >> PGP/MIME is an effort to integrate MIME and PGP. There is a >>workable draft based on the MIME security multiparts, but the PGP/MIME >>mailing list is divided. Some particpants are happy with the existing >>draft, while others feel that other points in the design space >>(for the most part, labelling existing PGP message formats with >>appropriate MIME types) would be better. >> The design space is large and complex, with many constraints on >>efficiency, simplicity, backwards compatibility, and functionality. It >>is not clear that a consensus will develop at all. >> There are two implementations of the PGP/MIME draft: premail, and >>the PGPMIME reference implementation by Michael Elkins. >> For more information about the PGP/MIME draft, see >>http://www.c2.org/~raph/pgpmime.html . >> >> >>PGP 3.0 >>------- >> >> Many people are hoping that PGP 3.0 will somehow come along and >>solve all their problems. PGP 3.0 is only an evolutionary improvement >>over the existing implementations (MIT PGP 2.6.2 and PGP 2.6.3i). For >>the most part, it will support only the existing message formats. >>There may be support for decoding draft PGP/MIME signed messages, but >>this is still being negotiated. >> The main advance in PGP 3.0 is a cleaned up implemenation. The PGP >>2.6.2 code is disgusting, and should not be integrated directly into >>any mailer application. The 3.0 code will be modular and based on >>published interfaces. Furthermore, the 3.0 development team plans to >>release the code as both a stand-alone application and as a library. >> It is difficult to predict when the public release will happen. >>Based on what I've seen, fall of 1996 seems the most likely. >> >> >>MOSS >>---- >> >> MOSS (MIME Object Security Services) is an attempt at an email >>encryption protocol in accordance with MIME. It is currently an >>Internet RFC. There is a reference implementation (TIS/MOSS 7.1). >> MOSS is mostly cryptographically sound. However, the choice of >>symmetric encryption algorithm (and key size) is left unspecified. >>Thus, it cannot be said that MOSS is in accordance with the >>recommendations for minimum keysize. In fact, the only public >>implementation, TIS/MOSS 7.1, uses 56-bit DES, which is in direct >>violation of these standards. >> The TIS/MOSS implementation has a number of other problems. It is >>big and complex, probably due to its TIS/PEM ancestry. For more >>information about TIS/MOSS, see >>http://www.tis.com/docs/Products/tismoss.html . >> >> MOSS supports two modes of key management: X.509, and completely >>manual key management. In this way, it is a dramatic advance over PEM, >>which only supported X.509, but life for implementors remains hard. >>One feature which I believe is sorely lacking is a cryptographic hash >>of the public key as the basic unit of manual key management. Thus, >>people either have to trust the mechanism by which the key was >>delivered, or examine the base-64 representation of the entire key. I >>consider this to be a serious usability problem. >> For an example of how hashes of keys have been done right, see >>Netscape 2.0's handling of untrusted certificates. >> >> >>S/MIME >>------ >> >> S/MIME is an attempt to graft MIME support onto underlying PEM >>standards. See http://www.rsa.com/rsa/S-MIME/ for more info. >> >> I feel compelled to deal harshly with RSA's S/MIME FAQ >>(http://www.rsa.com/rsa/S-MIME/smimeqa.htm). It suggests that MOSS has >>interoperability problems because of multiple implementations, while >>S/MIME presumably doesn't. I take strong exception to this statement. >>There is no technical basis for it. I consider the possibility of >>admitting multiple implementations as a _requirement_ for an Internet >>email standard. However, because S/MIME is documented, it hopefully >>will be possible to create independent implementations, in spite of >>what RSA says. >> >> The only symmetric encryption algorithm mandated by S/MIME is >>40-bit RC2. Thus, S/MIME is in violation of the key size >>recommendations. Further, RC2 has not been confirmed to be publicly >>known. If RC2 is not known, then an independent implementation of >>S/MIME is impossible. Fortunately, source code for an alleged >>implementation of RC2 has recently been posted to the Internet, >>resolving this problem, if it is authentic. If not, then my >>reservations remain. >> >> S/MIME also recommends 56-bit DES CBC and (either 112 or 168 bit) >>DES EDE3-CBC. This is good; any S/MIME implementation in accordance >>with the recommendations will conform to the keysize recommendations >>as well. >> >> S/MIME remains firmly grounded in the X.509 certification >>hierarchy, although the FAQ claims that the guidelines for hierarchies >>are "more flexible" than in PEM. >> >> One cryptographic weakness of S/MIME is that eavesdroppers can >>distinguish between encrypted and signed-and-encrypted messages. This >>violates the principle of disclosing a minimum amount of information. >>PGP, PGP/MIME, and MOSS do not have this problem. >> >> Probably the most controversial aspect of S/MIME is its signature >>format. An S/MIME signed message is a MIME multipart in which the >>first part is the data to be signed, and the second part is a complete >>PKCS #7 (section 10) signed message. This protects quite well against >>munging by mail transport, but has two problems. First, the size of >>the message is doubled. Second, the fact that the two singed messages >>are identical is not enforced (if it were, mailer munging would cause >>too many signatures to fail). Thus, Eve can send Alice and Bob a >>message (M1, (M2, Signature(M2))). Alice, not having an S/MIME >>implementation, would see only M1. Bob, having an S/MIME >>implementation, would see only M2, for which the signature would >>check. Alice, being suspicious, might call Bob up on the telephone and >>ask whether the signature was really valid. Bob would of course say >>yes. Unless they compared notes on the contents, they would not notice >>the discrepancy. To my mind, this counts as protocol failure, and thus >>it is not possible to claim that S/MIME conforms to best cryptographic >>practice. >> I would expect that doubling the message body will create >>performance problems in a Web environment. For example, if the first >>message is used for display, then it becomes necessary to compare the >>two messages. If, instead, the second message is used, then the first >>message will be responsible for significant added latency. >> >> >>Integration with mailers >>------------------------ >> >> Integration with mailers is quite difficult. In general, the mailer >>implementor will need to add specific features to support >>cryptography. Because of the restrictiveness of ITAR regulations, such >>an approach may not be practical for US developers, at least while >>supporting strong cryptography. >> Perhaps the biggest feature required in the mailer is integration >>of key management and the "address book". If this feature is not >>implemented in the mailer, then two address books are required - one >>to select email addresses, and another to map email addresses to keys. >>This approach is used by premail, and is the source of many usability >>problems. It would be nice if a database existed which could map email >>addresses to public keys without manual intervention, but none of the >>proposals on the table are capable of it. Such a database would >>certainly improve usability, as well as making it considerably easier >>to >> >> Another feature that is required for fully transparent integration >>is caching of decrypted session keys. If not implemented, then the >>user interface delays in navigating a mail folder become unacceptable. >>To my knowledge, no implementation supports this feature. >> One dimension in the design space is whether the cryptographic >>engine is tightly integrated with the mailer (i.e. shares an address >>space), or is a separate process that communicates with the mailer. >>Both approaches have been implemented. Both approaches are subject to >>numerous pitfalls, which have unfortunately not been entirely avoided. >> These issues have more to do with implementation than with the >>encryption protocol, but I thought I'd mention them here, so that they >>are not actively thwarted. >> >> >>Conclusion >>---------- >> >> All of the proposals described here can be used for secure email. >>None of them will be widely deployed in this capacity unless they are >>implemented well. I have concerns that both MOSS and S/MIME are >>susceptible to political pressure which will restrict key sizes >>insecurely in practice. I would like to see consensus develop around >>one of the proposals, so that energies used for implementation can be >>more focussed and effective. It is my hope that this conference will >>move in that direction. >> >>Raph Levien >> >> > ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Fri Mar 29 16:02:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id QAA20470 for ietf-ediint-bks; Fri, 29 Mar 1996 16:02:54 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id QAA20465 for ; Fri, 29 Mar 1996 16:02:52 -0800 (PST) Received: from [204.179.128.10] (mg131-006.ricochet.net [204.179.131.6]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id QAA01710 for ; Fri, 29 Mar 1996 16:14:28 -0800 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 29 Mar 1996 16:00:58 -0800 To: ietf-ediint@imc.org From: Dave Crocker Subject: Re: A brief comparison of email encryption protocols Sender: owner-ietf-ediint@imc.org Precedence: bulk For folks that are really interested in this topic, I commend them to the web reference that Bob gave: which includes a summary of the workshop. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Sat Mar 30 16:05:50 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id QAA28380 for ietf-ediint-bks; Sat, 30 Mar 1996 16:05:50 -0800 (PST) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id QAA28375 for ; Sat, 30 Mar 1996 16:05:48 -0800 (PST) Received: from [205.214.160.52] (d82.netgate.net [205.214.160.118]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id QAA05723 for ; Sat, 30 Mar 1996 16:17:44 -0800 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Sat, 30 Mar 1996 16:06:39 -0800 To: ietf-ediint@imc.org From: Dave Crocker Subject: Re: A brief comparison of email encryption protocols Sender: owner-ietf-ediint@imc.org Precedence: bulk Well, At 4:00 PM 3/29/96, Dave Crocker wrote: >For folks that are really interested in this topic, I commend them to the >web reference that Bob gave: > > > >which includes a summary of the workshop. It would probably help if I gave you the correct URL: and more general information, including a post-workshop press release, is at: sorry for the confusion. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Mon Apr 8 16:01:59 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id QAA06968 for ietf-ediint-bks; Mon, 8 Apr 1996 16:01:59 -0700 (PDT) Received: from enlil.premenos.com (enlil.premenos.com [150.105.100.2]) by imc.org (8.7.4/8.7.1) with SMTP id QAA06963 for ; Mon, 8 Apr 1996 16:01:57 -0700 (PDT) Received: from pilgrim04.templar.net by enlil.premenos.com (AIX 3.2/UCB 5.64/4.03) id AA55302; Mon, 8 Apr 1996 15:57:11 -0700 Date: Mon, 8 Apr 96 15:20:40 From: Steve Botts Subject: NIIT Study - EDI over the Internet To: edi-l@uccvma.ucop.edu, ietf-ediint@imc.org X-Priority: 3 (Normal) X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ietf-ediint@imc.org Precedence: bulk You may be interested in the findings of a study just released by the NIIT. The following news article explains what was tested. To read the entire report point your browser at http://www.niit.org/insight/white/edi.html Testbed Study finds EDI and Internet Compatible Partners Study Highlights Security Issues DENVER, CO - Exchanging electronic documents can be successfully accomplished over the Internet, not just proprietary networks, according to a study released today by the National Information Infrastructure Testbed (NIIT). During the study, project leader Sue Gore, an employee of NIIT member 3M, tested Premenosı Templar product to evaluate the potential of using the Internet for EDI. ³The NIIT study shows that by using Templar it is possible to exchange electronic data over the Internet in a manner that could previously be accomplished only within a proprietary network environment,² said Troy Eid, executive director of the NIIT. ³This is an important breakthrough in the development of the National Information Infrastructure, which depends upon the interoperability between the Internet and existing proprietary networks.² A key advantage of Templar is that it contains the necessary encryption for secure EDI, the study said. ³Security concerns are often raised as an obstacle to using the Internet for Electronic Data Interchange. Our evaluation found the Templar product alleviated the security concerns,² said Gore. Templar also makes the validation of transmissions straightforward. Gore noted that ³Templar proved to be consistently reliable.² For details on the study, visit NIITıs web site at http://www.niit.org. Select the ³Insights on the NII² link to view Electronic Data Interchange over the Internet. Established in 1993, the NIIT is an industry-led consortium working to develop and advance information testbeds that will deliver applications to solve real world problems. NIIT's 50 members participate in a series of application focused demonstration projects designed to assess the technical, operational and commercial feasibility of each application. NIIT's Board of Directors includes several of the nation's most influential and respected organizations, such as 3M Company; AT&T Corporation; Bay Networks; Digital Equipment Corporation; Global Commerce Link, LLC; Hewlett Packard Company; Hughes Electronics; IBM Corporation; Sandia National Laboratories; Sprint; and the University of New Hampshire. #### From owner-ietf-ediint Mon Apr 8 20:07:30 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id UAA08429 for ietf-ediint-bks; Mon, 8 Apr 1996 20:07:30 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id UAA08423 for ; Mon, 8 Apr 1996 20:07:25 -0700 (PDT) Received: from [199.184.212.153] (turnpike54.onramp.net [199.184.212.153]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id WAA17181; Mon, 8 Apr 1996 22:09:01 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Apr 1996 21:17:25 +0100 To: Electronic Data Interchange Issues , ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: ietf-ediint EDI over Internet Workgroup Status Sender: owner-ietf-ediint@imc.org Precedence: bulk We have completed brainstorming the issues for what must be solved for EDI= packages from many vendors to inter-operate over Internet. The outline,= with initial description is currently being written. Our next step is to= focus on recommending solutions for each of the outstanding= inter-operability issues. This effort will start very soon. Many key vendors are involve.=20 The paper proposed outline is below. Proposed Outline 1) Background - overview -What is this document -Who is it for -Why is this important, etc. -Participants 2) Functional requirements -Introduction (interoperable s/w) -Security +Privacy +Message integrity +Authenticity +Non-repudiation of origin (i thi the same as "authenticity"?) +Non-repudiation of receipt +Key management +Global security considerations -Message components (MIME) and flow for complete security loop +EDI object boundaries +??? (your #14?) +Relationship with X12 and EDIFACT security standards (AUTACK...) +Relationhip with MOSS +Relationship with S/MIME -Failure point detection, tracking and acknoledgments +delayed transmissions +lost transmissions +failed transmissions (security) +duplicate transmissions +out-of-sequence transmissions +transaction/transmission ID's +relationship with ISA, GS and ST control numbers +relationship with translator tracking +relationship with 997 -Miscellaneous =20 3) Technical Specifications (this to be worked on later) The original announcement message and how to enroll in the EDIINT listserv= is below. If you wish to be involved please enroll. Sincerely, Rik Drummond Chairperson IETF-EDIINT --- begin forwarded text Date: Sun, 11 Feb 1996 00:04:39 +0100 To: RGIROUAR@disa.org =46rom: drummond@onramp.net (Rik Drummond) Subject: ietf-ediint Workgroup Move Cc:=20 Bcc:=20 X-Attachments:=20 If your are interested in working on the EDI over Internet workgroup we= have been discussing on the EDI-L listserv, please enroll on the new= listserv as described below. We will start work using this listserv on= wednesday Feb. 14. Looking forward to working with each of you.=20 Rik Drummond INSTRUCTIONS To enroll send a message to: ietf-ediint-request@imc.org Leave the subject line blank. Type subscribe on the first line in the body= of the message. EXAMPLE:=20 Date: Fri, 9 Feb 1996 14:11:27 -0600 To:ietf-ediint-request@imc.org From:drummond@onramp.net (Rik Drummond) subscribe --------------------Forwarded message -------------------------------------- To: EDI-L@UCCVMA.UCOP.EDU =46rom: drummond@onramp.net (Rik Drummond) Subject: Workgroup Charter: EDI Internet Integration Cc:=20 Bcc: John C Klensin , Harald Tveit Alvestrand X-Attachments:=20 It has become evident over the last year than even though RFC1767 makes a= major contribution to the transport of EDI over the Internet, other= Internet related issues still remain to be solved in order for Internet EDI= transactions produced by different products to be inter-operable. Below is= a description for a proposed working group that will focus on documenting= the inter-operability issues and recommended solutions for EDI= inter-operability over the Internet transport. The chair is Rik Drummond, The Drummond Group, An Electronic Messaging and= Electronic Commerce consultancy. Mr. Drummond has extensive experience in= implementing electronic commerce in Fortune 100 companies. He is the= co-author of two books, he speaks frequently at conferences, he is the= electronic conference chairperson for Email world and he was, until= recently, the Electronic Messaging editor for EDI World magazine. Please, let us know if you believe this is a worth while effort and if you= are willing to participate. Regards, Rik ----------------------------------------------------------------------- Electronic Data Interchange - Internet Integration (EDIINT) ----------------------------------------------------------------------- Charter Chair: Rik Drummond Editor: TBD=20 Applications Area Director(s) TBD Area Advisor TBD Mailing lists: -------------- General Discussion: TBD To Subscribe: TBD In Body: TBD Archive: TBD Description of Working Group: ----------------------------- Electronic Data Interchange (EDI) is a set of protocols for conducting= highly structured inter-organization exchanges, such as for making= purchases or initiating loan requests. The initial RFC1767 defined the= method for packaging the EDI X12 and UN/EDIFACT transactions sets in a MIME= envelope. However, several additional requirements for obtaining= multi-vendor, inter-operable service, over and above how the EDI= transactions are packaged, have come to light since the effort concluded.= These currently revolve around security issues such as EDI transaction= integrity, privacy and non-repudiation in various forms. Standards in= these and other areas are necessary to ensure inter-operability between EDI= packages over Internet. Various technologies already exist for these= additional features and the primary requirement is to review and select a= common set of components for use by the EDI community when it sends EDI= over the Internet. In effect, the effort is to provide an EDI over the= Internet Requirements Document. Efforts by the working group will focus on a single deliverable:=20 ---------------------------------------------------------------- Define the use of security and associated processes for exchanging EDI= transactions in MIME in a manner which supports core, functional, transport= services requirements. Goals and Milestones: --------------------- March 1996 - Submit Internet-draft outline for requirements document July 1996 - Submit Internet-draft for requirements document.=20 October 1996 - Submit requirements document for proposed standard. --- end forwarded text --- end forwarded text From owner-ietf-ediint Tue Apr 9 14:01:09 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id OAA16916 for ietf-ediint-bks; Tue, 9 Apr 1996 14:01:09 -0700 (PDT) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.org (8.7.4/8.7.1) with SMTP id OAA16911 for ; Tue, 9 Apr 1996 14:01:08 -0700 (PDT) Received: from chage.com by hustle.rahul.net with UUCP id AA11694 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Tue, 9 Apr 1996 14:02:57 -0700 Received: by slick.chage.com (4.1/SMI-4.1) id AA04517; Tue, 9 Apr 96 11:47:13 PDT Date: Tue, 9 Apr 96 11:47:13 PDT From: carl@chage.com (Carl Hage) Message-Id: <9604091847.AA04517@slick.chage.com> To: ietf-ediint@imc.org Subject: Please turn off MIME quoted-printable Sender: owner-ietf-ediint@imc.org Precedence: bulk I have a request to those with MIME email readers to disable the MIME quoted-printable and use plain ASCII instead. Not everyone has MIME mailers. Everyone can read it if messages are converted to ASCII with 75-78 characters per line. From owner-ietf-ediint Tue Apr 9 14:43:30 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id OAA17314 for ietf-ediint-bks; Tue, 9 Apr 1996 14:43:30 -0700 (PDT) Received: from proper.proper.com (root@proper.proper.com [165.227.249.2]) by imc.org (8.7.4/8.7.1) with ESMTP id OAA17309 for ; Tue, 9 Apr 1996 14:43:29 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by proper.proper.com (8.7.4/8.6.5) with ESMTP id OAA25417 for ; Tue, 9 Apr 1996 14:35:04 -0700 (PDT) Received: from [199.184.212.197] (stockyard40.onramp.net [199.184.212.203]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id QAA09480 for ; Tue, 9 Apr 1996 16:39:50 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 9 Apr 1996 15:48:15 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: IISP - April 5, 1996 News Release Sender: owner-ietf-ediint@imc.org Precedence: bulk --- begin forwarded text From: RGIROUAR@SMTP.DISA.ORG Date: Tue, 09 Apr 96 10:14:33 EST Encoding: 142 Text To: distribution:@SMTP.DISA.ORG; (see end of body) Subject: IISP - April 5, 1996 News Release Received: by ccmail from enterprise.disa.org >From owner-iisp-gen@ansi.org X-Envelope-From: owner-iisp-gen@ansi.org Received: from mailserv.ansi.org by enterprise.disa.org (NTMail 3.01.03) id aa002588; Tue, 9 Apr 1996 08:20:56 -0400 Received: by mailserv.ansi.org (5.x/SMI-SVR4) id AA15920; Tue, 9 Apr 1996 07:25:44 -0400 Received: from micromail by mailserv.ansi.org (5.x/SMI-SVR4) id AA15907; Tue, 9 Apr 1996 07:25:41 -0400 Received: by micromail with Microsoft Mail id <316A4976@micromail>; Tue, 09 Apr 96 07:26:46 edt From: PETER LEFKIN To: iisp-gen Subject: IISP - April 5, 1996 News Release Date: Mon, 08 Apr 96 18:26:00 edt Message-Id: <316A4976@micromail> Encoding: 122 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-iisp-gen@ansi.org Precedence: bulk Reply-To: plefkin@ansi.org American National Standards Institute (ANSI) 11 West 42nd Street New York, NY 10036 CONTACT: Marilyn Hernandez ANSI (212) 642-4915 E-Mail: mhernand@ansi.org Esra Ozer/Dan Stepanek/Henry P. Feintuch KCSA 820 Second Avenue New York, NY 10017 (212) 682-6565 ext. 221/202/212 Fax: (212) 697-0910 E-Mail: KCSA@aol.com FOR IMMEDIATE RELEASE INFORMATION SUPERHIGHWAY PANEL FOCUSES ON SECURING FINANCIAL TRANSACTIONS IN CYBERSPACE NEW YORK, April 5, 1996 -- Are Americans risking their funds in on-line banking? Are credit card transactions on the Internet secure? Can our financial privacy be invaded easily in Cyberspace? These are some of the issues being addressed by the Information Infrastructure Standards Panel (IISP), a group of more than 80 companies, organizations, and government agencies working together under the aegis of the American National Standards Institute (ANSI). IISP's objective is to identify the standards needed to facilitate the growth of the information superhighway by determining what standards exist, where new standards development work is needed, and by ensuring that those standards are created and ready in a timely fashion. Speakers at a recent IISP meeting in Washington, D.C. reviewed varying perspectives of ensuring financial and information security in Cyberspace and focused on the role of standards in developing methods to increase security. Separately, the panel approved six new application to application standards needs; these will be added to the 35 standards previously identified as key requirements (http://www.ansi.org/iisp/needlist.html). "Security is one of the most central and complex issues in implementing the information superhighway," said ANSI Board Member Oliver Smoot, chairman of IISP and executive vice president of the Information Technology Industry Council. "Confidence that networks and information are appropriately secure is pivotal to the growth of the National and Global Information Infrastructure (NII/GII)." "The threat, sophistication, and impact of security intrusion has increased dramatically," said John Kimmins, director, Secure Systems and Operations Group, Bellcore, who provided examples of methods "cybercrooks" use to break into networks to steal information. Richard Nevins, director, Global Information Technology Infrastructure, AMP Incorporated, discussed security from the point of view of a company doing business on-line on private and public networks. He cited the Intranet, which is bringing Internet capabilities to internal corporate networks, as a new challenge to company security. According to Tim Schoechle, president, CyberLYNX Gateway Corp., despite consumer concerns about protecting their privacy on the Internet, the "smart home" of the future, with on-line access to and from many sources, may provide cybercrooks with "one-stop" shopping of personal information. Smoot explained that IISP is working to identify the standards needed for networks-- among telecommunications, cable and broadcast/wireless companies, for example --that interconnect and operate compatibly. For consumers, this will mean more choices of providers of services such as telephone, TV or cable, as well as lower cost and better service due to the resulting increased competition. Some specific areas of standards requirements being addressed include: health care informatics, application-to-network issues, nomadicity (facilitating access to services, people and content while "on the move"), entertainment, information security and encryption, and intellectual property rights. The panel also is looking at standards needed for global coordination. Standards needs identified by IISP are reviewed by more than 30 standards organizations to determine where the "gaps" are and where work is needed. This is mostly done on-line. IISP recently hosted a first of its kind roundtable of standards organizations that focused on standards that will tie cross-industry networks together. Participants included the Internet Engineering Task Force, Committee T1-Telecommunications, National Cable Television Association, and the Electronic Industries Association. Additional roundtables on topics such as electronic publishing are being planned. IISP is a broad, cross-industry effort whose members represent sectors --including information technology, telecommunications, cable television, banking, broadcast, intelligent transport, medical and wireless -- that are converging and interconnecting. Panel members include Hewlett-Packard, Motorola, Apple Computer, IBM, AT&T, the National Association of Broadcasters, Federal Communications Commission, and National Institute of Standards & Technology. Information on IISP, including membership and meeting schedules, as well as standards needs so far identified, is available on the panel's World Wide Web site (http://www.ansi.org/iisp/iisphome.html) or by contacting R.M. "Chick" Hayden (telephone: 212/642-4920; e-mail: chayden@ansi.org) or Peter Lefkin (telephone: 212/642-4979; e-mail: plefkin@ansi.org). The panel's next meeting is scheduled for June 18-19, 1996 at the Embassy Suites Hotel in Alexandria, Va. ANSI is a private non-profit organization that coordinates the U.S. voluntary standards system, bringing together interests from the private and public sectors to develop voluntary standards for a wide array of U.S. industries. ANSI is the official U.S. member body to the world's leading standards bodies -- the International Organization for Standardization (ISO) and via the U.S. National Committee, the International Electrotechnical Commission (IEC). The Institute's membership includes approximately 1,300 national and international companies and 285 government agencies, institutions and professional, technical, trade, educational, labor, and consumer organizations. %%% overflow headers %%% To: #X12_IISP_at_DISA@SMTP, jamster@attmail.com, 102677.1140@compuserve.com, lbbedi@aol.com, steve@wpc-edi.com, gbenesc@ix.netcom.com, pbenson@traderights.com, marykay@ix.netcom.com, Stephen.P.Brooks@AC.com, 496-3299@mcimail.com, DCARLSON@MCS.NET, CLIFFORD@EDISCI.MV.COM, codmanapl@attmail.com, Tim_Cronin@Notes.PW.COM, usibmpl3@ibmmail.com, crowley@rtci.com, curtisl@ncr.disa.mil, HGDEAL@sunbelt.net, drummond@onramp.net, dyergunc@usva8.dyncorp.com, EvansGH@msmail.corning.com, dmferguson@attmail.com, dfiles@kodak.com, sgaylor@harbinger.com, gspadin@disa.org, HAMMO001@MC.DUKE.EDU, rhankin@hibcc.org, mph1@cc.bellcore.com, 73311.2736@compuserve.com, bruce_horn@ath.com, HowellR@jlsc.WPAFB.AF.mil, "wmvx::mrgate::a1::hutchekr"@wmvx.dnet.dupont.com, fmiantorno@aol.com, Kubicek , RichLanden@aol.com, JLutz@lms.aar.com, MARTINK@api.org, JWM@MAIL.LM.COM, valda.miller@qm.sprintcorp.com, robert.molino@ccgw1.hq.dla.mil, klaus@enlil.premenos.sf.ca.us, navarroi@cc.ims.disa.mil, Newerla@cc.bellcore.com, owensr@ada.org, 416-4812@mcimail.com, PETERR@VNET.IBM.COM, 102775.2426@compuserve.com, breilly@gartner.com, srobinet@mindspring.com, 496-5653@mcimail.com, carolr@premenos.com, 595-1938@mcimail.com, southl@ncr.disa.mil, JEFFS , USLEVP8A@IBMMAIL.COM, Smwebb@netcom.com, rlw@navistar.com, gmayer@disa.org %%% end overflow headers %%% --- end forwarded text From owner-ietf-ediint Fri Apr 12 06:23:07 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id GAA15708 for ietf-ediint-bks; Fri, 12 Apr 1996 06:23:07 -0700 (PDT) Received: from proper.proper.com (root@proper.proper.com [165.227.249.2]) by imc.org (8.7.4/8.7.1) with ESMTP id GAA15703 for ; Fri, 12 Apr 1996 06:23:06 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by proper.proper.com (8.7.4/8.6.5) with ESMTP id GAA13109 for ; Fri, 12 Apr 1996 06:14:45 -0700 (PDT) Received: from [199.184.212.224] (stockyard61.onramp.net [199.184.212.224]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id IAA12519 for ; Fri, 12 Apr 1996 08:23:39 -0500 (CDT) X-Sender: drummond@onramp.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Date: Fri, 12 Apr 1996 08:26:19 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: EDIINT - Direction and Status Sender: owner-ietf-ediint@imc.org Precedence: bulk The outline will be out this weekend for review and discussion -- Lord willing and the creek don't rise. I know we are now two weeks late on this, but we wished to capture as much information from the initial discussions as possible to facilitate the next phase of the effort -- recommending solutions. I think when you see it you will agree we have a nice format and have advanced the effort significantly. We currently have 250 people on the ietf-ediint listserv. Most of the major VANs and EDI software development companies are in involved. We have representation from fr, uk, ca, au, uk, no, it, and several other countries. The vendors I have talked to on the phone are very interested in the ietf-ediint effort because they believe we have a good shot at accomplishing the goals. (Please read the initial announcement message for these.) I have also been in discussions with Joline Ellenberg of Novell (Joline_Ellenberg@novell.com), who is the CommerceNet Chair for a similar EDI-over-Internet effort. We both believe that we can jointly facilitate the effort of EDI-over-Internet by cooperating. Our cooperative focus is in a manner that does not cause procedural problems to either organization. Let me explain. CommerceNet has several deliverables in their EDI-over-Internet project. The three which pertain to our ietf-ediint effort are: (5) Technical Internet Interoperability Solutions (This is like our ietf-ediint effort) (6) Interoperability Testing Criteria and Test Plan (7) Conference Demo Criteria and Plan Deliverable #5 is the same as our EDI-over-Internet effort. She and I have discussed CommerceNet taking the output of our ietf-ediint effort and using it as deliverable #5 of their effort. They also would implement deliverables #6 and #7, which are a formal Interoperability test of our recommendations and then help sponsor a demo at a large trade show of the vendors which interoperate. If none of you have any problems with this opportunity, I intend to facilitate the cooperation between us and CommerceNet in this area. NOTE: An important point of this cooperation is that, CommerceNet is not a participant in the ietf-ediint effort. The intercooperation on the ietf-ediint side is through individuals who are members of both efforts. CommerceNet will reference the ietf-ediint results and then continue to facilitate Interoperability testing as part of their EDI-over-Internet Project. Regards, Rik From owner-ietf-ediint Fri Apr 12 06:21:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id GAA15700 for ietf-ediint-bks; Fri, 12 Apr 1996 06:21:54 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id GAA15695 for ; Fri, 12 Apr 1996 06:21:49 -0700 (PDT) Received: from [199.184.212.224] (stockyard61.onramp.net [199.184.212.224]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id IAA12536 for ; Fri, 12 Apr 1996 08:23:45 -0500 (CDT) X-Sender: drummond@onramp.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Apr 1996 08:26:24 +0100 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk If we have to select an existing encryption/protection architecture for EDI-over-Internet, are there preferences? Which does the group think is the best for EDI-over-Internet? What are the alternatives?: - S/MIME - MOSS - PGP with additions - Other Do some of offer the ability to support world wide EDI exchanges better than others? Do some facilitate a better exchange with the X.435 standards than others? Do we care? Do any allow us to conduct EDI easier without the need for an _initial_ CA (certification authority) hierarchy? What are your thoughts? Later...Rik From owner-ietf-ediint Fri Apr 12 07:24:16 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA16088 for ietf-ediint-bks; Fri, 12 Apr 1996 07:24:16 -0700 (PDT) Received: from ns1.indirect.com (root@ns1.indirect.com [165.247.1.3]) by imc.org (8.7.4/8.7.1) with SMTP id HAA16083 for ; Fri, 12 Apr 1996 07:24:14 -0700 (PDT) Received: from dave_d.indirect.com (s99.phxslip4.indirect.com [165.247.24.99]) by ns1.indirect.com (8.6.12/8.6.6) with SMTP id HAA05544; Fri, 12 Apr 1996 07:26:22 -0700 Message-Id: <2.2.32.19960412142654.0073f56c@mail.indirect.com> X-Sender: dave_d@mail.indirect.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 12 Apr 1996 07:26:54 -0700 To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org From: Dave Darnell Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk At 08:26 AM 4/12/96 +0100, Rik Drummond wrote: >If we have to select an existing encryption/protection architecture for EDI-over-Internet, are there preferences? > >Which does the group think is the best for EDI-over-Internet? What are the alternatives?: > - S/MIME > - MOSS > - PGP with additions > - Other I lean toward PGP --- mainly because it is so ubiquitous on the net and has plenty of fans. You can even buy 5 or 6 books on it in Borders Book Store. I bought my share last year and have been using it ever since. The signature certification part is worthless to me, but that is just my opinion. I really do not think CA infrastructure is important in the immediate future but is EXTREMELY important if we expect EDI to really be successful in the 6 million plus small business market. Of course we will need some real changes in traditional EDI to make this happen -- like new-EDI (Ken Steel) taking off. But that is another thread -- and mailing list. I demo-ed PGP encrypted EDI with MS Exchange at my DISA session and someone asked me why I did not use X12.58. Does anyone know of any products that implement X12.58 for TCP/IP SMTP/MIME ? I sure don't. S/MIME sounds really promising -- anyone know of an e-mail vendor that has it yet? I know MOSS is available at TIS for download but have not had the opportunity to evaluate it. > >Do some of offer the ability to support world wide EDI exchanges better than others? > >Do some facilitate a better exchange with the X.435 standards than others? Do we care? > I do not see X.435 as being a factor on the Internet -- if anyone has a different view then I would like to see details. >Do any allow us to conduct EDI easier without the need for an _initial_ CA (certification authority) hierarchy? > I think PGP works great if you ignore the "chain of trust" digital signature certification stuff. >What are your thoughts? > >Later...Rik > > > > ====================================== | David Darnell | SysTrends, Inc. | Arizona EC/EDI Roundtable | 1850 East Carver Road | Tempe, AZ 85284 | Tel (602)838-5316 | Fax (602)897-8032 | mailto://dave_d@systrends.com ====================================== From owner-ietf-ediint Fri Apr 12 08:01:54 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA16299 for ietf-ediint-bks; Fri, 12 Apr 1996 08:01:54 -0700 (PDT) Received: from ng.netgate.net (ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id IAA16294 for ; Fri, 12 Apr 1996 08:01:52 -0700 (PDT) Received: from [204.179.128.17] (mg128-17.ricochet.net [204.179.128.17]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id IAA09421; Fri, 12 Apr 1996 08:14:54 -0700 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 12 Apr 1996 08:01:55 -0700 To: drummond@onramp.net (Rik Drummond) From: Dave Crocker Subject: Re: EDI and Encryption Issues Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 12:26 AM 4/12/96, Rik Drummond wrote: >If we have to select an existing encryption/protection architecture for >EDI-over-Internet, are there preferences? I'm strongly in favor of having the group debate this issue an try to make some sort of recommendations. On the other hand, I don't believe the industry is in a position to "choose a winner" yet. This means that the best you can achieve is some profiling for each of a set of alternatives and some sort of prioritization of trade-off recommendation. As a reminder, I commend folks to look at the discussion and review of the IMC Resolving Email Security Workshop under the home page. >Which does the group think is the best for EDI-over-Internet? What are >the alternatives?: Here's my own assessment of the status of each of these, with a special caveat to note that all of the alternatives seem to be evaluated as having acceptable, basic authentication and privacy. I'll save the summary of technical comments and criticisms that I'm hearing about them for later. > - S/MIME Very strong vendor support for this proprietary (consortium) effort led by RSA Data Systems. No products out, yet as far as I know, and certainly no installed base with an operational history. Claims to support a range of CA models. > - MOSS The official Internet standard. No product out yet, as far as I know, and very little installed base that uses the TIS freeware package. Claims to support a range of CA models. > - PGP with additions Small, but significant installed base. Legal issues surrounding PGP have were resolved last year. Limited product release. Supports ad hoc CA model among consenting participants. New version will support a range of CA models. > - Other MSP - Message Security Protocol, from the X.400-based Defense Messaging System project, is likely to come out soon in some products. No installed base. I believe this is the only one that has built-in support for non repudiation of recipient. >Do some of offer the ability to support world wide EDI exchanges better >than others? I believe that EDI places pretty straightforward requirements on the email and security infrastructure and that any of these would be just fine for authentication and privacy. >Do some facilitate a better exchange with the X.435 standards than others? >Do we care? I believe that none of these support gateway translation at all, since they are monolithic encapsulations of the EDI object. Your gateway would have to be a fully-vetted security entity. >Do any allow us to conduct EDI easier without the need for an _initial_ >CA (certification authority) hierarchy? See above. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Fri Apr 12 14:42:07 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id OAA19010 for ietf-ediint-bks; Fri, 12 Apr 1996 14:42:07 -0700 (PDT) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.org (8.7.4/8.7.1) with SMTP id OAA19005 for ; Fri, 12 Apr 1996 14:42:05 -0700 (PDT) Received: from chage.com by hustle.rahul.net with UUCP id AA23043 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Fri, 12 Apr 1996 14:44:05 -0700 Received: by slick.chage.com (4.1/SMI-4.1) id AA09129; Fri, 12 Apr 96 13:28:16 PDT Date: Fri, 12 Apr 96 13:28:16 PDT From: carl@chage.com (Carl Hage) Message-Id: <9604122028.AA09129@slick.chage.com> To: ietf-ediint@imc.org Subject: Re: EDI and Encryption Issues References: Sender: owner-ietf-ediint@imc.org Precedence: bulk drummond@onramp.net (Rik Drummond) writes: : Which does the group think is the best for EDI-over-Internet? What are the alternatives?: : - S/MIME : - MOSS : - PGP with additions : - Other (MSP may be mandated for US .MIL) I think the encryption issue should be dealt with 2 ways. First, there should be a general abstract architecture in which the sign or sign- and-encrypt process is identified using a MIME header, and the sequencing of steps in preparation is clearly defined, e.g. add_RFC822_headers(mime_base64_encode(sign_and_encrypt( mime_concatenate(form_receipt(prior_message),mime_wrap(X12_message)))) is allowed but add_RFC822_headers(mime_concatenate( mime_base64_encode(sign_and_encrypt(form_receipt(prior_message)), mime_base64_encode(sign_and_encrypt(mime_wrap(X12_message)))) is not. Or maybe it is. The point is that the sequencing and process of forming messages is well defined, independent of the specific encryption algorithm. At the outer layer, a MIME header identifies the algorithm, so the software processing system can be easily extended to plug in an independent application. MOSS, S/MIME, PGP-MIME, MSP-MIME, all have a defined MIME type that could be used with this model. This would allow TPs a reasonable ability to select an alternate or future algorithm, if needed. What all the encryption MIME definitions do not specify, is the sequence in which they are used. Besides the above generic encryption specification, there should be a single MIME type defined as minimum support to be fully compliant with the RFC. In other words, we select one of these algorithms, so any TP who buys software supporting the internet-edi standard will be able to exchange messages with any other similar TP, independent of the brand of software. TPs may optionally extend the supported types by agreement. I would suggest MOSS for the following reasons: S/MIME and MOSS are functionally similar in many respects. However, S/MIME uses binary data structures to encode the nearly equivalent information contained in the RFC822/MIME like ASCII headers. I believe the MIME coded header lines are more extensible, and more forward/backwards compatible than the S/MIME encoding. Extending S/MIME is outside the usual RFC process, and is dependent on RSA as a private corporation and dependant on private consortiums. The binary decoding software will also likely be more dependent on RSA, and possibly RSA patents and licensing. MOSS has more flexibility in the algorithm and key management. I can't remember the details off the top of my head, and don't have time to review them now. I think MOSS has a superset of the S/MIME capabilites, including the ability to exchange messages with externally managed keys (as opposed to certificates). I think S/MIME always encodes messages as a binary format, and so requires S/MIME software to decode. For private TP-TP exchanges, this isn't a problem, but for unencrypted, signed messages, e.g. RFQs posted to a newsgroup, people or software couldn't scan articles without decoding them. I think this is a show-stopper. S/MIME has a funny restriction banning standalone signatures (signatures of data located elsewhere), which is defined in PKCS7 source protocol. In contrast, MOSS has the signature parts clearly defined within the message for logging, receipts, or auditing. PGP uses different header formats and data encoding from the usual MIME formats. New versions of PGP and PGP-MIME are extending these, but this is some future development. Changing PGP formatting into MIME form, you end up with MOSS. I believe MOSS can represent the encryptions used by PGP. I think it is easier to stick with MIME-like conventions for the whole packaging process rather than mix formats. The MIME header scanners can then extract headers and data and call coder/decoder subroutines or application programs. It's also easier to use different mixes of software to do a variety of processing, which can be done with simple header pattern matching. Rather than adopt MSP which uses another binary format for the equivalent of MIME headers, it's simpler to just agree upon the details of the receipt needed for non-repudiation. The elements are almost all there from existing RFCs, and mainly need to be packaged precisely. I think all DSN/MSP implementations use the Clipper chip algorithm, and the Fortezza cards can't encrypt/decrypt RSA, etc. codes. That is going to cause grief. The DOD hubs can switch to more expensive general purpose cards, but the average government PC will likely only have the $69 clipper-only cards. :-/ (Can you spell Gateway?) BTW, I think MOSS needs to be tweaked slightly to allow multiple signers (cosigners), but that might not be that important for EDI applications. It would be trivial to extend. (A message might fork to several people, who sign and forward to a collector who merges the message and signatures to one multisigned document.) There are a couple of companies selling email software that supports MOSS, S/MIME, and PGP (and maybe MSP) transparently. Unfortunately, the info is buried in a huge pile of brochures. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Sun Apr 14 03:06:58 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id DAA01884 for ietf-ediint-bks; Sun, 14 Apr 1996 03:06:58 -0700 (PDT) Received: from tom.compulink.co.uk (tom.compulink.co.uk [194.153.0.51]) by imc.org (8.7.4/8.7.1) with SMTP id DAA01879 for ; Sun, 14 Apr 1996 03:06:54 -0700 (PDT) Received: (from root@localhost) by tom.compulink.co.uk (8.6.9/8.6.9) id LAA09130 for ietf-ediint@imc.org; Sun, 14 Apr 1996 11:08:19 +0100 Date: Sun, 14 Apr 96 11:08 BST-1 From: ahinchley@cix.compulink.co.uk (Andrew Hinchley) Subject: Re: EDI and Encryption Issues To: drummond@onramp.net, @cix.compulink.co.uk, Drummond@cix.compulink.co.uk Cc: ahinchley@cix.compulink.co.uk, ietf-ediint@imc.org Reply-To: ahinchley@cix.compulink.co.uk Message-Id: Sender: owner-ietf-ediint@imc.org Precedence: bulk In-Reply-To: There are one or two key principles which might be derived from Dave crcker's points: 1. It is likely that a number of different certification infrastructures will exist. Solutions that allow for this are therefore to be encouraged. 2. Given the marketplace issues,it would probably be unwise to select one solution only. Finally, I support the notion that the X.435 solutions are probably not worth considering further in this context. If we were considering anything else, then for me it would have to be the (separate) X12-specific and EDIFACT-specific security solutions. Andrew Hinchley Communications Planning Limited From owner-ietf-ediint Sun Apr 14 08:10:44 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id IAA03052 for ietf-ediint-bks; Sun, 14 Apr 1996 08:10:44 -0700 (PDT) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id IAA03047 for ; Sun, 14 Apr 1996 08:10:42 -0700 (PDT) Received: from [205.214.160.88] (d25.netgate.net [205.214.160.57]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id IAA26877; Sun, 14 Apr 1996 08:24:39 -0700 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Sun, 14 Apr 1996 07:59:24 -0700 To: ahinchley@cix.compulink.co.uk From: Dave Crocker Subject: Re: EDI and Encryption Issues Cc: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk At 4:08 AM -0700 4/14/96, Andrew Hinchley wrote: >2. Given the marketplace issues,it would probably be unwise to select one >solution only. This is a very, very tough issue. On the one hand, there is little operational history with "interesting" certificate structure. We need time to gain that experience. On the other hand, the presence of multiple, competing standards means that interoperability is threatened. If I support one scheme and you support another, we don't interoperate. Given that EDI is primarily used for longer-term relationships with prior arrangement, there is some ability to "negotiate" ahead of time, but that still involves additional hassles in maintaining tables and having to support multiple technologies. My own suggestion is that the group should define a range of "acceptable" choices but should then try very hard to come to agreement, making one "required". The purpose behind this is to ensure that everyone has at least one choice in common, without prohibiting the use of others. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Sun Apr 14 18:57:25 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id SAA05725 for ietf-ediint-bks; Sun, 14 Apr 1996 18:57:25 -0700 (PDT) Received: from mail1.best.com (mail1.best.com [206.86.8.14]) by imc.org (8.7.4/8.7.1) with SMTP id SAA05720 for ; Sun, 14 Apr 1996 18:57:23 -0700 (PDT) Received: from agraves.vip.best.com (agraves.vip.best.com [205.149.165.153]) by mail1.best.com (8.6.12/8.6.5) with SMTP id SAA08285 for ; Sun, 14 Apr 1996 18:59:28 -0700 Date: Sun, 14 Apr 1996 18:59:28 -0700 Message-Id: <199604150159.SAA08285@mail1.best.com> X-Sender: mjansson@best.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: Mats Jansson Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Sun, 14 Apr 96 11:08 BST-1 >From: ahinchley@cix.compulink.co.uk (Andrew Hinchley) >Subject: Re: EDI and Encryption Issues >To: drummond@onramp.net, @cix.compulink.co.uk, Drummond@cix.compulink.co.uk >Cc: ahinchley@cix.compulink.co.uk, ietf-ediint@imc.org >Reply-To: ahinchley@cix.compulink.co.uk >Sender: owner-ietf-ediint@imc.org > >In-Reply-To: >There are one or two key principles which might be derived from Dave >crcker's points: > >1. It is likely that a number of different certification infrastructures >will exist. Solutions that allow for this are therefore to be encouraged. > >2. Given the marketplace issues,it would probably be unwise to select one >solution only. Seems to me we have to standardize on the architecture, and to my knowledge none of the efforts mentioned covers "non-repudiation of receipt" acknowledg- ment. I feel it is a must. If we can get agreement on the architecture, IOW use of digital envelopes, signatures and message digests, then it makes sense to leave some room for specific algorithm choices (maybe...). Marketplace competition could differentiate along feature set - not architecture. > >Finally, I support the notion that the X.435 solutions are probably not >worth considering further in this context. If we were considering >anything else, then for me it would have to be the (separate) >X12-specific and EDIFACT-specific security solutions. > > >Andrew Hinchley >Communications Planning Limited > > From owner-ietf-ediint Mon Apr 15 05:59:18 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id FAA10870 for ietf-ediint-bks; Mon, 15 Apr 1996 05:59:18 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id FAA10865 for ; Mon, 15 Apr 1996 05:59:17 -0700 (PDT) Received: from [199.184.212.181] (stockyard18.onramp.net [199.184.212.181]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id IAA10082 for ; Mon, 15 Apr 1996 08:01:24 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Apr 1996 20:06:01 -0500 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk Would two or three members of the group like to put together a comparison or profile of the existing Internet encyption standards so that we may compare them easily? This would be very helpful to the EDIINT effort. Rik >At 4:08 AM -0700 4/14/96, Andrew Hinchley wrote: >>2. Given the marketplace issues,it would probably be unwise to select one >>solution only. > > This is a very, very tough issue. On the one hand, there is little >operational history with "interesting" certificate structure. We need time >to gain that experience. On the other hand, the presence of multiple, >competing standards means that interoperability is threatened. If I >support one scheme and you support another, we don't interoperate. > > Given that EDI is primarily used for longer-term relationships with >prior arrangement, there is some ability to "negotiate" ahead of time, but >that still involves additional hassles in maintaining tables and having to >support multiple technologies. > > My own suggestion is that the group should define a range of >"acceptable" choices but should then try very hard to come to agreement, >making one "required". The purpose behind this is to ensure that everyone >has at least one choice in common, without prohibiting the use of others. > >d/ > >-------------------- >Dave Crocker +1 408 246 8253 >Brandenburg Consulting fax: +1 408 249 6205 >675 Spruce Dr. dcrocker@brandenburg.com >Sunnyvale CA 94086 USA http://www.brandenburg.com > >Internet Mail Consortium http://www.imc.org, info@imc.org ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Mon Apr 15 07:05:10 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id HAA11389 for ietf-ediint-bks; Mon, 15 Apr 1996 07:05:10 -0700 (PDT) Received: from ng.netgate.net (root@ng.netgate.net [204.145.147.10]) by imc.org (8.7.4/8.7.1) with SMTP id HAA11384 for ; Mon, 15 Apr 1996 07:05:07 -0700 (PDT) Received: from [205.214.160.58] (d30.netgate.net [205.214.160.62]) by ng.netgate.net (8.6.12/8.6.9) with ESMTP id HAA02713 for ; Mon, 15 Apr 1996 07:19:16 -0700 X-Sender: dcrocker@ng.netgate.net Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Mon, 15 Apr 1996 07:06:35 -0700 To: ietf-ediint@imc.org From: Dave Crocker Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk At 6:06 PM -0700 4/15/96, Rik Drummond wrote: >Would two or three members of the group like to put together a comparison >or profile of the existing Internet encyption standards so that we may >compare them easily? This would be very helpful to the EDIINT effort. To those few folks interested in email security, but unaware of the workshop held by the Internet Mail Consortium in February, I commend you to look at . I believe that the summary I wrote will provide all the data (and even some different views or summaries) to respond to Rik's request, or at least provide a basis for it. I haven't received any screaming complaints (or even quiet ones) about its inaccuracies. Here are two sections from the summary which seem most on-point to Rik's request: 2. OVERVIEW OF TECHNICAL ALTERNATIVES (THE CONTENDERS) This section was to ensure that attendees shared a basic understanding of the technical details for the alternatives. It was not a tutorial but, rather, a quick summary and presentation of status. It also served to start the dialogue... Each of the four technologies was discussed. There was a question of additional alternatives, but brief discussion disclosed product efforts, rather than technology efforts. 2.1. MSP, Message Security Protocol (Peter Yee / Spyrus ) Background Derives from the US Defense Message System. I-D avail, application/MSP Algorithms, packaging Supports alternatives ... Services confidentiality authentication non-repudiation return-receipt signature Implementations in the pipeline Tri-ted Spyrus (Specs mail -- MS-Mail) LGL (Alabama) Nortel ? 2.2. MOSS, MIME Object Security Services (Jim Galvin / EIT- Verifone ) Background Co-author of MOSS, but not specific advocate Official Internet (IETF) standards effort Digital signature & encryption for MIME PEM-derived, with modifications to certificate (borrwed from PGP) and algorithm usage & integration to MIME Trust-model independent; starts with trusted public key Secure MIME framework Generic MIME: multipart/signed, multipart/encrypted MOSS protocol uses above Implementations Public reference: TIS/MOSS Innosoft soon 2.3. PGP/MIME, Pretty Good Privacy /MIME Integration(Mike Elkins / Aerospace ) Background Originally, private effort by Phill Zimmerman, et cie. Expanded participation, e.g., by Aerospace and Sun. 3.0 interoperates with 2.6.2 RFC1847 (multipart security) based integration for PGP 3.0 multipart/signed permits non-security readers access to content One-pass signature-checking Being expanded to support formal trust hierarchies; some examples underway Implementations: Michael Elkins' reference Raph Levien 's "premail". 2.4. S/MIME, Secure MIME (Steve Dusse / RSA Data Security ) Background Consortium effort by RSA Data Security and a collection of email product vendors. Solve *basic* security needs Technical PKCS-7 for algorithms, PKCS-10 for certificates MD5, RSA, RC2(40)/DES/Triple-DES/RC5 X.509v1->X.509v3 certificates; permit others No recommendation on trust models MIME integration is through two application/* types with no current use of multipart security (1847) Implementations Substantial implementation activity; products expected CY96Q2. ---------- 3.2. Matrix for Criteria vs. Technology (Jim Galvin) Jim's presentation set the tone for the rest of the day, focussing on details and features, rather than wholesale support/refutation of an "approach". He developed a summary comparison chart: Criteria Text text supported Multimedia non-text supported Integrity supported, not guaranteed Signature integrity/authentication Backward compatible - rfc822 readable, if signed? Encryption confidentiality supported Separation signature & encryption independent Signatory Signor hidden when encryption Bare keys bare public/priv key pair, w/out certificates 822 easily integrated with installed base MIME easily integrated with Mime Comments multipart/alternative is bad idea because UA not obligated to notify user of secure object exists Unless it is essential to hide structure for specific cases, The Chart 822 MIME PEM PGP MOSS PGP/MIME S/MIME MSP Text + + + + + + + + Multimedia + - + + + + Integrity + + + + + + + Signature + + + + + + Back compat + + + + - Encryption + + + + + + Separation - - + + - Signatory + + + - Bare keys + + + 822 + + MIME + + + + + -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. dcrocker@brandenburg.com Sunnyvale CA 94086 USA http://www.brandenburg.com Internet Mail Consortium http://www.imc.org, info@imc.org From owner-ietf-ediint Tue Apr 16 11:21:55 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id LAA23662 for ietf-ediint-bks; Tue, 16 Apr 1996 11:21:55 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id LAA23657 for ; Tue, 16 Apr 1996 11:21:51 -0700 (PDT) Received: from [199.184.212.201] (stockyard38.onramp.net [199.184.212.201]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id NAA17353 for ; Tue, 16 Apr 1996 13:22:05 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Apr 1996 01:27:05 -0500 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: EDIINT: EDI and Public Key Crypto needs Sender: owner-ietf-ediint@imc.org Precedence: bulk >Date: Wednesday, 10 April 1996 8:40pm ET >To: drummond@onramp.net >From: Richard.Ankney@fisc.com >Subject: EDI and Public Key Crypto needs > >Please be aware there's a PKIX (X.509-based) IETF WG as well. They already >have drafts out. This would likely interwork nicely (at the infrastructure >level) w/ your X.400 work. I don't think SPKI will come up with anything >any better than X.509; in fact, they seem aimed toward a PGP web of trust >approach (no centralized trust management), which I find useless for EDI and >electronic commerce in general. > >/ Rich ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Tue Apr 16 18:33:49 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id SAA26204 for ietf-ediint-bks; Tue, 16 Apr 1996 18:33:49 -0700 (PDT) Received: from hiway1.exit109.com (root@hiway1.exit109.com [205.164.176.32]) by imc.org (8.7.4/8.7.1) with SMTP id SAA26199 for ; Tue, 16 Apr 1996 18:33:44 -0700 (PDT) Received: from port13.cos2-annex.usa.net (port13.cos2-annex.usa.net [192.156.196.177]) by hiway1.exit109.com (8.6.12/8.6.9) with SMTP id VAA07630; Tue, 16 Apr 1996 21:35:38 -0400 Message-Id: <199604170135.VAA07630@hiway1.exit109.com> X-Sender: boblyons@hiway1.exit109.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Apr 1996 21:37:01 -0400 To: drummond@onramp.net (Rik Drummond), ietf-ediint@imc.org From: boblyons@unidex.com (Robert C. Lyons) Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk At 08:06 PM 4/15/96 -0500, Rik Drummond wrote: >Would two or three members of the group like to put together a comparison >or profile of the existing Internet encyption standards so that we may >compare them easily? This would be very helpful to the EDIINT effort. Rik, I wrote an article that contains a comparison of several security solutions for doing EDI over the Internet. The article was published in the first two issues of E-COMM Magazine (publisher@ecommmagazine.com, 1-408-867-8601). Interested parties may be able to get a copy of the article from the publisher. I plan to put this article up on my Web site, but I'm super busy right now. Bob Lyons Electronic Commerce Consultant Unidex, Inc. 1-908-975-9877 BobLyons@unidex.com EDI Help Desk: http://www.wwa.com/unidex/edi/ From owner-ietf-ediint Tue Apr 16 21:52:48 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id VAA27173 for ietf-ediint-bks; Tue, 16 Apr 1996 21:52:48 -0700 (PDT) Received: from austria.it.earthlink.net (austria-c.it.earthlink.net [206.85.92.44]) by imc.org (8.7.4/8.7.1) with SMTP id VAA27168 for ; Tue, 16 Apr 1996 21:52:46 -0700 (PDT) Received: from LICHEN (max1-ot-ca-24.earthlink.net [206.149.196.74]) by austria.it.earthlink.net (8.6.11/8.6.4) with SMTP id VAA09597 for ; Tue, 16 Apr 1996 21:54:57 -0700 Date: Tue, 16 Apr 1996 21:54:57 -0700 Message-Id: <199604170454.VAA09597@austria.it.earthlink.net> X-Sender: lichen@earthlink.net X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ediint@imc.org From: lichen@earthlink.net (Li Chen) Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk >In-Reply-To: >1. It is likely that a number of different certification infrastructures >will exist. Solutions that allow for this are therefore to be encouraged. > >2. Given the marketplace issues,it would probably be unwise to select one >solution only. As we are discussing the certificate infrastructure here, I found from Microsoft Tech Ed '96 Conference at Los Angeles that Microsoft is pushing a standard as a partnership with VeriSign. Basically, it is coded in X.509 version 3 format with several Microsoft extensions. VeriSign will act as certificate agent (CA). Everyone will need to get certified by VeriSign. VeriSign will charge $400-$500 per year for business and $20 per year for individual. It is rumored that GTE and US Postal Service also want to become CA. From owner-ietf-ediint Wed Apr 17 12:44:19 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id MAA04428 for ietf-ediint-bks; Wed, 17 Apr 1996 12:44:19 -0700 (PDT) Received: from hustle.rahul.net (hustle.rahul.net [192.160.13.2]) by imc.org (8.7.4/8.7.1) with SMTP id MAA04423 for ; Wed, 17 Apr 1996 12:44:16 -0700 (PDT) Received: from chage.com by hustle.rahul.net with UUCP id AA21018 (5.67b8/IDA-1.5 for imc.org!ietf-ediint); Wed, 17 Apr 1996 12:46:35 -0700 Received: by slick.chage.com (4.1/SMI-4.1) id AA01289; Wed, 17 Apr 96 12:33:38 PDT Newsgroups: lists.ietf-ediint Path: carl From: carl@chage.com (Carl Hage) Subject: Re: EDI and Encryption Issues Message-Id: Date: Wed, 17 Apr 96 19:33:32 GMT Organization: C. Hage Associates, Sunnyvale, CA References: <199604170454.VAA09597@austria.it.earthlink.net> Apparently-To: ietf-ediint@imc.org Sender: owner-ietf-ediint@imc.org Precedence: bulk lichen@earthlink.net (Li Chen) writes: : As we are discussing the certificate infrastructure here, I found from : Microsoft Tech Ed '96 Conference at Los Angeles that Microsoft is pushing a : standard as a partnership with VeriSign. Basically, it is coded in X.509 : version 3 format with several Microsoft extensions. Note that Microsoft also has a proprietary format for secure email using Microsoft's proprietary fax-modem direct dial. They call it "fax", but it is really proprietary email sent using fax mode of a modem. This comes with MS-Office and Windows 3.11/WFW/NT/95. Keys are exchanged manually, so certificates don't apply. Note also that MOSS supports X.509 certificate chains, but has a provision to identify and support other methods of key exchange as well. -------------------------------------------------------------------------- Carl Hage C. Hage Associates Voice/Fax: 1-408-244-8410 1180 Reed Ave #51 Sunnyvale, CA 94086 From owner-ietf-ediint Wed Apr 17 19:32:47 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id TAA06995 for ietf-ediint-bks; Wed, 17 Apr 1996 19:32:47 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id TAA06989 for ; Wed, 17 Apr 1996 19:32:44 -0700 (PDT) Received: from [199.184.212.125] (turnpike26.onramp.net [199.184.212.125]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id VAA21869; Wed, 17 Apr 1996 21:34:54 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Apr 1996 09:39:40 -0500 To: boblyons@unidex.com (Robert C. Lyons), ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: Re: EDI and Encryption Issues Sender: owner-ietf-ediint@imc.org Precedence: bulk Dave Crocker has a encryption comparison on the IMC.ORG web site also....Let me know when you post it......Later....Rik >At 08:06 PM 4/15/96 -0500, Rik Drummond wrote: >>Would two or three members of the group like to put together a comparison >>or profile of the existing Internet encyption standards so that we may >>compare them easily? This would be very helpful to the EDIINT effort. > > >Rik, > >I wrote an article that contains a comparison of several security solutions >for doing EDI over the Internet. >The article was published in the first two issues of E-COMM Magazine >(publisher@ecommmagazine.com, 1-408-867-8601). Interested parties may be >able to get a copy of the article from the publisher. > >I plan to put this article up on my Web site, but I'm super busy right now. > > >Bob Lyons >Electronic Commerce Consultant >Unidex, Inc. >1-908-975-9877 >BobLyons@unidex.com >EDI Help Desk: http://www.wwa.com/unidex/edi/ ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ From owner-ietf-ediint Wed Apr 17 19:36:27 1996 Received: (from majordomo@localhost) by imc.org (8.7.4/8.7.1) id TAA07032 for ietf-ediint-bks; Wed, 17 Apr 1996 19:36:27 -0700 (PDT) Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3]) by imc.org (8.7.4/8.7.1) with ESMTP id TAA07027 for ; Wed, 17 Apr 1996 19:36:25 -0700 (PDT) Received: from [199.184.212.125] (turnpike26.onramp.net [199.184.212.125]) by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id VAA22575 for ; Wed, 17 Apr 1996 21:38:40 -0500 (CDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Apr 1996 09:43:25 -0500 To: ietf-ediint@imc.org From: drummond@onramp.net (Rik Drummond) Subject: EDIINT Outline (With Descriptions) Draft Sender: owner-ietf-ediint@imc.org Precedence: bulk Did everyone receive the draft outline? Rik >Date: Mon, 15 Apr 1996 20:01:08 -0500 >To:ietf-ediint@imc.org >From:drummond@onramp.net (Rik Drummond) >Subject:EDIINT Outline (With Descriptions) Draft >X-Attachments::Internal 540:18:IETF03.DOC: > >Attached is the first draft of the EDIINT document. We have a major >description to each section to help explain the issuses and capture you >comments from earlier discussions. > >Note: >- it is in Word format, if that is a proplem let me know and I will send >out a text copy, which at this point will be hard to read because of the