REMOVE

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
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".
> 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 
>