AS#1

[ricardo.johnson@xxxxxxx]

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