Subject: RE: AS#1

From: "Rishel,Wes" <[email-masked]>
Date: Tue, 20 Nov 2001 01:18:01 -0500

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:[email-masked]]
Sent: Monday, November 19, 2001 6:48 PM
To: [email-masked]; [email-masked]
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
Drummond Group.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Tuesday, November 13, 2001 4:48 PM
To: [email-masked]
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".
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
eliminating the possibility to exchange messages between
traditional EDI VAN users and new intgernet EDI users,
unless either or both of these users go though
a "gateway" to perform the interconnection, and allow
such gateways to decrypt and encrypt tha messages for
them.
The latter is totally unacceptable from a security point
of view. Furthermore, VANs retain the control over EDI
message routing and administration, life will not change
much for current EDI users.
May I suggest a much more logic, simple approach:
1. Use either X12.58 (ANSI) or EDIFACT Security rules as
defined in the guidelines.
2. Secure only the information you wish to secure
according to the guidelines in 1
3. Manage authentication, non-reputiation of origin, key
management, etc. accourding to EDI rules.
The above alternative would all EDI translation and
security software to be compatible regardless of the
platform, internet protocol, and messaging protocol.
I know you have worked very hardr with the security
issues you are trying to resolve, but I have tryed
several of the ideas you are proposing in your draft and
I can assure you that that the issues I am addessing
will surface in the future as companies try to embrace
EDI/internet.
Respectfully,
Dr. Ricardo S. Johnson

---

From: joe mcverry <[email-masked]>
Date: Tue, 20 Nov 2001 06:19:02 -0500

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

-- 
----------- 
Joe McVerry
American Coders Ltd.
POBox 97462
Raleigh, NC   27624  USA
919.846.2014 (voice/fax)
http://www.americancoders.com
Home Of OBOE - an EDI and EDI/XML Translator
    and xBaseJ - xBase Database Engine For Java

---

From: David Fischer <[email-masked]>
Date: Tue, 20 Nov 2001 09:03:49 -0600

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: [email-masked]
[mailto:[email-masked]]On Behalf Of joe mcverry
Sent: Tuesday, November 20, 2001 5:19 AM
To: [email-masked]
Cc: Rishel,Wes; 'David Fischer'; [email-masked]
Subject: Car Is To Truck as EDIINT Is To...

MTCW,

Joe McVerry