Electronic Data Interchange-Internet Integration (ediint)

ricardo.johnson | 13 Nov 2001 23:48

Picon

AS#1


I have read eith great interest your MIME-based Secure 
EDI draft document and I have come to a dicovered some 
very serious problems that may diserve special attention.

In Section 2.3.1 you state: "This specification assumes 
that a typical EDI interchange is the lowest level 
object that will be subject to security services".
In my view, this assuption is extremely dangerous and 
may be at the heart of several important limitations to 
the present and future use of EDI over internet. The 
lowest level of sercurity services should not be limited 
to an envelope level.  
The next paragraph in your draft points out one 
immediate consequence of the above limitation: In EDI 
terms (ANSI or EDIFACT), that means "anything between 
and including..the envelope segments". "Congruent with 
the above statement, EDI envelop headers are NOT visoble 
in the MIME package. In order to optimize VAN-to-
internet routing, work may need to be done in the future 
to define ways to pull out some of the envelope 
information to make them sisible, however, this 
specification does not go into any detail on that".
Indeed, by encrypting the entire EDI interchange, 
including the envelope headers, you are no longer able 
to route the message to/from VANs without decrypting the 
message. This is a serious, and in many cases 
unacceptable limitation. 
In other words, by using S/MIME as the encrypting 
standard for EDI over internet, you are are de-facto

(Continue reading)

Avital@netvision.net.il | 16 Nov 2001 08:20

Picon

REMOVE


----- Original Message ----- 
From: <ricardo.johnson <at> att.net>
To: <ietf-ediint <at> imc.org>
Sent: Wednesday, November 14, 2001 12:48 AM
Subject: AS#1

> 
> I have read eith great interest your MIME-based Secure 
> EDI draft document and I have come to a dicovered some 
> very serious problems that may diserve special attention.
> 
> In Section 2.3.1 you state: "This specification assumes 
> that a typical EDI interchange is the lowest level 
> object that will be subject to security services".
> In my view, this assuption is extremely dangerous and 
> may be at the heart of several important limitations to 
> the present and future use of EDI over internet. The 
> lowest level of sercurity services should not be limited 
> to an envelope level.  
> The next paragraph in your draft points out one 
> immediate consequence of the above limitation: In EDI 
> terms (ANSI or EDIFACT), that means "anything between 
> and including..the envelope segments". "Congruent with 
> the above statement, EDI envelop headers are NOT visoble 
> in the MIME package. In order to optimize VAN-to-
> internet routing, work may need to be done in the future 
> to define ways to pull out some of the envelope 
> information to make them sisible, however, this 
> specification does not go into any detail on that".

(Continue reading)

The IESG | 19 Nov 2001 15:51

Picon

Last Call: MIME-based Secure EDI to Proposed Standard


The IESG has received a request from the Electronic Data
Interchange-Internet Integration Working Group to consider MIME-based
Secure EDI <draft-ietf-ediint-as1-14.txt> as a Proposed Standard.

In the same action, the IESG will also consider publication of
 Requirements for Inter-operable Internet EDI
<draft-ietf-ediint-req-09.txt> as an Informational RFC.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by December 3, 2001.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-14.txt

David Fischer | 20 Nov 2001 03:47

RE: AS#1


I think it is important to point out that the whole point of EDIINT/AS1 is to
eliminate the use of intermediate VANs.

AS1 is sometimes used with a VAN but this is not the typical, or the intended
implementation.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of
ricardo.johnson <at> att.net
Sent: Tuesday, November 13, 2001 4:48 PM
To: ietf-ediint <at> imc.org
Subject: AS#1

I have read eith great interest your MIME-based Secure
EDI draft document and I have come to a dicovered some
very serious problems that may diserve special attention.

In Section 2.3.1 you state: "This specification assumes
that a typical EDI interchange is the lowest level
object that will be subject to security services".
In my view, this assuption is extremely dangerous and
may be at the heart of several important limitations to
the present and future use of EDI over internet. The

(Continue reading)

Rishel,Wes | 20 Nov 2001 07:18

Picon

RE: AS#1


There are many reasons for using VANS other than simply getting a secure
connection. They provide valuable add-on services in many industries.

Ideally EDIINT would permit connections to and from VANs over the Internet
as well as connections directly between end-points. (At this point the
"network" is either the Network or a more secure private IP network.)

Generally, the value-added services require decoding, examining and perhaps
changing the payload, so the required key exchange is between the VAN and
each of the endpoints and the final recipient has to trust that the VAN
properly authenticated the initial sender.

-----Original Message-----
From: David Fischer [mailto:david <at> drummondgroup.com]
Sent: Monday, November 19, 2001 6:48 PM
To: ricardo.johnson <at> att.net; ietf-ediint <at> imc.org
Subject: RE: AS#1

I think it is important to point out that the whole point of EDIINT/AS1 is
to
eliminate the use of intermediate VANs.

AS1 is sometimes used with a VAN but this is not the typical, or the
intended
implementation.

Regards,

David Fischer

(Continue reading)

joe mcverry | 20 Nov 2001 12:19

Car Is To Truck as EDIINT Is To...

Hmmm...  there is no equivalence to Truck for EDIINT.   Well, maybe you
could say VANs are equivalent but then VANs are proprietary and their
delivery technology unique while EDIINT is open and a well defined
protocol.

Dr. Johnson's situation is that he provides VAN services to his
customers.  He wants to include internet document delivery for his
customers documents to pass through his network.  This reintroduces the
VAN element to the transmission equation, which  is not part of the
EDIINT agenda and should never be.   What Dr. Johnson can do is use the
EDIINT specifications as a foundation for a proprietary internet
solution - but that defeats the whole purpose of using EDIINT as a
protocol.  Another solution is to use the EBXML protocol includes for
pass-through specifications that meet Dr. Johnson's requirements.

There has never been a description for a pass-through function in the
EDIINT specifications.  Why -  because EDIINT's sole purpose is to
provide a protocol for point-to-point delivery of EDI documents using
Internet technology.  EDIINT is not an all encompassing description for
every possible avenue to do document delivery.

MTCW,

Joe McVerry

"Rishel,Wes" wrote:
> 
> There are many reasons for using VANS other than simply getting a secure
> connection. They provide valuable add-on services in many industries.

(Continue reading)

David Fischer | 20 Nov 2001 16:03

RE: Car Is To Truck as EDIINT Is To...


The few VANs that have participated in AS1 have done exactly as Wes suggests.
AS1 still works as long as it is point-to-point delivery.  However, this is not
what was intended by the AS1 specification and even if this situation works, it
is out-of-scope.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: owner-ietf-ediint <at> mail.imc.org
[mailto:owner-ietf-ediint <at> mail.imc.org]On Behalf Of joe mcverry
Sent: Tuesday, November 20, 2001 5:19 AM
To: ietf-ediint <at> imc.org
Cc: Rishel,Wes; 'David Fischer'; ricardo.johnson <at> att.net
Subject: Car Is To Truck as EDIINT Is To...

Hmmm...  there is no equivalence to Truck for EDIINT.   Well, maybe you
could say VANs are equivalent but then VANs are proprietary and their
delivery technology unique while EDIINT is open and a well defined
protocol.

Dr. Johnson's situation is that he provides VAN services to his
customers.  He wants to include internet document delivery for his
customers documents to pass through his network.  This reintroduces the
VAN element to the transmission equation, which  is not part of the
EDIINT agenda and should never be.   What Dr. Johnson can do is use the
EDIINT specifications as a foundation for a proprietary internet

(Continue reading)

Paul V Ford-Hutchinson | 21 Nov 2001 11:58

Picon

Re: Last Call: MIME-based Secure EDI to Proposed Standard


I have two comments:

1) Is there any disagreement to re-titling the document "MIME-based Secure 
Peer-Peer EDI" ?

2) There are too many options. 

Although the document lists 8 permutations, I can actually count 23.  One 
document defining 23 modes of operation is an interoperability nightmare.

And one of the ennumerated modes of operation in this "Secure EDI" 
document is "Sender sends un-encrypted data, does NOT request a receipt". 
How is this "Secure EDI" ?

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh <at> uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

Paul V Ford-Hutchinson | 21 Nov 2001 19:35

Picon

RE: Last Call: MIME-based Secure EDI to Proposed Standard


Greg Vesper wrote:
>'Secure EDI' is misleading for a spec that allows content types of 
> EDI, XML, binary..
>We do a lot of non-edi transactions using AS1 and AS2.  EDIINT is a
>misleading name..

Interesting, what MIME types do you identify your XML and Binary data by ?

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh <at> uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

Paul V Ford-Hutchinson | 21 Nov 2001 22:29

Picon

RE: Last Call: MIME-based Secure EDI to Proposed Standard


Greg Vesper wrote:
>"application/xml"
>"application/octet-stream"

Which are defined in AS1 where ?  Certainly not here ...

"3.5 RFC 1767 EDI Content [2]

   This RFC defines the use of content type "application" for ANSI
   X12 (application/EDI-X12), EDIFACT (application/EDIFACT) and
   mutually defined EDI (application/EDI-Consent)."

You can break any protocol you like.  EDI-INT is defined for EDI.

Paul

--
Paul Ford-Hutchinson :  eCommerce application security : 
paulfordh <at> uk.ibm.com
MPT-6, IBM , PO Box 31, Birmingham Rd, Warwick, CV34 5JL +44 (0)1926 
462005
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html

Group

gmane.ietf.ediint.

Search Archive

Page

1 | 2 | 3

Articles in period: 23

November 2001

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Information on Certificate Exchange Message (23 Jan 2011)
http://www.ietf.org/id/draft-meadors-certificate-exchange-12.txt (15 Dec 2010)
update on draft-meadors-ediint-features-header and IANA review request (28 May 2010)
Is this mailing list still active? (18 Nov 2009)
I-D Action:draft-ietf-ediint-compression-11.txt (5 May 2008)
I-D Action:draft-ietf-ediint-compression-10.txt (25 Mar 2008)
I-D ACTION:draft-ietf-ediint-compression-09.txt (23 Jul 2007)
I-D ACTION:draft-ietf-ediint-compression-08.txt (11 Jun 2007)
I-D ACTION:draft-ietf-ediint-compression-07.txt (1 Jun 2007)
RFC 4823 on FTP Transport for Secure Peer-to-Peer Business Data Interc (24 Apr 2007)
I-D ACTION:draft-ietf-ediint-compression-06.txt (17 Jan 2007)
Original EDI working group mailing list archive (15 Nov 2006)
Original EDI working group mailing list archive (14 Nov 2006)
Concerning http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mu (21 Jul 2006)
EDI FTP transfer (13 May 2006)
WG Action: Conclusion of Electronic Data Interchange-Internet (14 Mar 2006)
CEM Draft update (7 Mar 2006)
AS2 Reliability and an issue for comment. (7 Mar 2006)
Document Action: 'FTP Transport for Secure Peer-to-Peer Business Data (6 Mar 2006)
update on EDIINT Features (22 Feb 2006)
making a decision on CEM (13 Feb 2006)

Archives

1	January 2011
1	December 2010
9	June 2010
1	May 2010
1	November 2009
1	May 2008
1	March 2008
1	July 2007
1	June 2007
1	May 2007
1	April 2007
1	January 2007
6	November 2006
1	July 2006
1	May 2006
7	March 2006
3	February 2006
4	January 2006
14	December 2005
5	November 2005
22	October 2005
4	August 2005
6	July 2005
6	June 2005
4	May 2005
13	April 2005
1	March 2005
5	February 2005
7	January 2005
3	December 2004
8	November 2004
7	October 2004
4	September 2004
5	August 2004
7	July 2004
2	June 2004
2	May 2004
8	April 2004
4	March 2004
2	February 2004
26	January 2004
1	December 2003
1	November 2003
2	September 2003
7	August 2003
2	July 2003
13	June 2003
3	March 2003
4	February 2003
36	January 2003
1	November 2002
22	October 2002
7	September 2002
3	August 2002
12	June 2002
12	May 2002
16	April 2002
25	March 2002
6	February 2002
4	January 2002
10	December 2001
23	November 2001
1	October 2001
8	September 2001
1	July 2001
2	June 2001
4	May 2001
14	April 2001
10	March 2001
4	February 2001
23	January 2001
6	December 2000
107	November 2000
14	October 2000
5	September 2000
5	August 2000
1	July 2000
4	June 2000
5	May 2000
17	April 2000
16	March 2000
6	February 2000
2	January 2000
4	December 1999
19	November 1999
16	October 1999
5	September 1999
11	August 1999
18	July 1999
21	June 1999
6	May 1999
61	April 1999
56	March 1999
53	February 1999
3	January 1999
22	December 1998
22	November 1998
43	October 1998
1	September 1998
23	August 1998
2	July 1998
8	June 1998
53	May 1998
31	April 1998
23	March 1998
30	February 1998
34	January 1998
48	December 1997
31	November 1997
14	October 1997
5	September 1997
29	August 1997
59	July 1997
101	June 1997
16	May 1997
37	April 1997
87	March 1997
49	February 1997
45	January 1997
44	December 1996
67	November 1996
83	October 1996
98	September 1996
26	August 1996
93	July 1996
73	June 1996
217	May 1996
58	April 1996
37	March 1996
79	February 1996
1	January 1995

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template