ricardo.johnson | 13 Nov 23:48 2001
Picon
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 08:20 2001
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 15:51 2001
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 03:47 2001

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 07:18 2001
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 12:19 2001

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 16:03 2001

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 11:58 2001
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 19:35 2001
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 22:29 2001
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


Gmane