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 protected]
[mailto:[email protected]]On Behalf Of
[email protected]
Sent: Tuesday, November 13, 2001 4:48 PM
To: [email protected]
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