Take Control Of Your Conference Calls

Mr. Redlund,

I=20 have read your e-mail regarding your intent to secure=20 EDI messages using EDI-INT=B4s recommended S/MIME. I agree = with you that=20 interoperability (routing of messages) to and from traditional EDI VANs = is a=20 mayor problem that has not been addressed by the EDI-INT working group. = In fact=20 traditionnal VANS (i.e. Harbinger, ATT, STerling, etc) are having to act = "gateways" between EDI-INT users and VAN users. They decrypt, unsign, = and=20 retransmit plain EDI (unsecured) messages.

Furthermore, the = lack of=20 interconnectivity that you are referring to may represent only one = of many=20 other serious limitations caused by the adoption of S/MIME as a means to = secure=20 EDI messages. This limitations are so severe that they should be = addressed by=20 the EDI-INT working group ASAP.

As for your project, = I would like=20 to discourage you from implementing S/MIME and any resulting temporary,=20 unilateral solution, such as the one you propose: pulling out the sender = and=20 receiver addresses from the UNH segment. These “patches” may = solve the immediate=20 problem, but they violate the standards and will surely create bigger = problems=20 in the long term. The choice of a security standard for EDI messages = should be=20 one and one only regardless of the transmission media, the messaging = protocol,=20 the communications layer, etc. This is clearly not the case with=20 S/MIME.

I=20 strongly believe that the EDI-INT selection and recommendation of S/MIME = as “the=20 security standard to transmit EDI messages over the internet” is=20 incorrect. While the use of S/MIME to secure e-mail = messages may=20 be rapidly becoming more and more popular, S/MIME has not yet been = approved as=20 an industry wide standard, live alone an EDI security standard = !.

S/MIME was conceived, and is well = suited to=20 protect enveloped e-mail messages (i.e. UNHs), but is poorly equipped to = address=20 the needs of the more sophisticated EDI transactions (i.e. UNBs), and to = manage=20 the more complex EDI interchange rules including: syntax, = non-repudiation of=20 origin/receipt, acknowledments, key management, etc.

I have come across the = very same=20 problem you are facing today while implementing an Inter-Bank payment = system=20 between the Central Bank of Mexico and its 46 affiliated banks. = Fortunately,=20 before we were confronted with the issue of transmitting the EDI = messages over=20 the Internet, we had already decided to adopt the UN/EDIFACT security = rules=20 instead of S/MIME. This decision allowed us to better understand and to=20 anticipate the interoperability, and the many other limitations = involving S/MIME=20 and EDI messages.

So far that = crucial=20 decision has paid off. The Mexican Central Bank is currently capable of=20 exchanging any secured EDIFACT message with any trading partner in the = world.=20 Interoperability between VANs, e-mail, and any other messaging protocol = (i.e.=20 X.400) is assured because encryption, digital signatures, = acknowledgements, and=20 key management are all performed at the transaction level, not just on = the=20 envelopes. With some added benefits like: consistent use of only one = standard=20 (EDIFACT) for both message structure, and security; non-repudiation of = origin=20 and/or receipt of transactions (not just envelopes), transaction=20 confidentiality, message routing, etc. Messages are encrypted all the = way from=20 sender to receiver without any "gateway" intermediaries.

Finally, I = would like to=20 invite you to address this issue with the EDI-INT working group as I = have done=20 in the past. Hopefully, as more projects involving Web-VAN = interoperability=20 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=20 be glad to offer my practical experience in the matter and to discuss = the=20 benefits of our proposed solution in detail. If I can be of any further=20 assistance, please do not hesitate to contact me at: ricardo.johnson=20 @att.net.

Regards,

Dr. Ricardo = S.=20 Johnson