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 |