RV: EDIINT-VAN Interconnectivity problems

----- Original Message ----- 
From: Ricardo Johnson 
To: [email protected] 
Sent: Tuesday, May 29, 2001 5:06 PM
Subject: EDIINT-VAN Interconnectivity (message routing) problems


Mr. Redlund,
I have read your e-mail regarding your intent to secure EDI messages using EDI-INT´s recommended S/MIME. I agree with you that interoperability (routing of messages) to and from traditional EDI VANs is a mayor problem that has not been addressed by the EDI-INT working group. In fact traditionnal VANS (i.e. Harbinger, ATT, STerling, etc) are having to act "gateways" between EDI-INT users and VAN users. They decrypt, unsign, and retransmit plain EDI (unsecured) messages.
 
Furthermore, the lack of interconnectivity that you are referring to may represent only one of many other serious limitations caused by the adoption of S/MIME as a means to secure EDI messages. This limitations are so severe that they should be addressed by the EDI-INT working group ASAP.
 
As for your project, I would like to discourage you from implementing S/MIME and any resulting temporary, unilateral solution, such as the one you propose: pulling out the sender and receiver addresses from the UNH segment. These "patches" may solve the immediate problem, but they violate the standards and will surely create bigger problems in the long term. The choice of a security standard for EDI messages should be one and one only regardless of the transmission media, the messaging protocol, the communications layer, etc. This is clearly not the case with S/MIME.
I strongly believe that the EDI-INT selection and recommendation of S/MIME as "the security standard to transmit EDI messages over the internet" is incorrect. While the use of S/MIME to secure e-mail messages may be rapidly becoming more and more popular, S/MIME has not yet been approved as an industry wide standard, live alone an EDI security standard !.
 
S/MIME was conceived, and is well suited to protect enveloped e-mail messages (i.e. UNHs), but is poorly equipped to address the needs of the more sophisticated EDI transactions (i.e. UNBs), and to manage the more complex EDI interchange rules including: syntax, non-repudiation of origin/receipt, acknowledments, key management, etc.

I have come across the very same problem you are facing today while implementing an Inter-Bank payment system between the Central Bank of Mexico and its 46 affiliated banks. Fortunately, before we were confronted with the issue of transmitting the EDI messages over the Internet, we had already decided to adopt the UN/EDIFACT security rules instead of S/MIME. This decision allowed us to better understand and to anticipate the interoperability, and the many other limitations involving S/MIME and EDI messages. 
So far that crucial decision has paid off. The Mexican Central Bank is currently capable of exchanging any secured EDIFACT message with any trading partner in the world. Interoperability between VANs, e-mail, and any other messaging protocol (i.e. X.400) is assured because encryption, digital signatures, acknowledgements, and key management are all performed at the transaction level, not just on the envelopes. With some added benefits like: consistent use of only one standard (EDIFACT) for both message structure, and security; non-repudiation of origin and/or receipt of transactions (not just envelopes), transaction confidentiality, message routing, etc. Messages are encrypted all the way from sender to receiver without any "gateway" intermediaries.
Finally, I would like to invite you to address this issue with the EDI-INT working group as I have done in the past. Hopefully, as more projects involving Web-VAN interoperability emerge, the EDI-INT working group will better understand the operational problems and will act accordingly to correct them.
In the mean time, I would be glad to offer my practical experience in the matter and to discuss the benefits of our proposed solution in detail. If I can be of any further assistance, please do not hesitate to contact me at: ricardo.johnson @att.net.
 
Regards,
Dr. Ricardo S. Johnson