RE: (Fwd) Mail Delivery Failure.

>From Mr. Hage´s description it is obvious that there is a major error in
unsing S/MIME as secutity to transmit EDI messages. The idea to use a VAN as
a gateway to decrypt and retransmit unencryted EDI messages is wrong ! This
can not, and should never be done particurarky with financial EDI messages
such as PAYMULs or 820s.
I can understand why the VANs like the idea of S/MIME so much, it makes
their clients still dependant on their services. I believe the use of
EDIFACT security rules and ANSIN´s X 12.58 and X 9.9 should be used to
secure EDI messages regdardless of weather you are using VANs, e-mail, or
any other messaging mechanism.
SImple, one standard, one security rap !
Wahy has this not been proposed before, it would solve a lot of problems !

Ricardo Johnson
----- Original Message -----
From: Carl Hage <[email protected]>
To: <[email protected]>
Sent: Wednesday, May 30, 2001 10:39 AM
Subject: (Fwd) Mail Delivery Failure.


> From:           Richard Redlund <[email protected]>
> Date sent:      Tue, 22 May 2001 08:13:13 +0200
>
> > Since routing of EDI interchanges are stil very common and
> > interoperability between users using the Internet and users using VANS
> > are needed, problems concerning this issue is on our table.
> >
> > As mentioned in section 2.4 of the referenced document we are looking
> > for a practical solution whereby information in the UNB segment, such as
> > sender's and recierver's logical addresses and EDI message type from the
> > UNH segment, are pullled out and made "visible" for the VANS.
>
> You need to distinguish between the encrypted and signed S/MIME
> data transmitted over the internet with the VAN users transmitting
> unencrypted/unsigned data.
>
> To implement an EDIINT to VAN gateway, the VAN must decrypt the
> S/MIME data as a proxy for thier client. The decryption key would be
> held by the VAN. Likewise, the VAN would need to sign the data as
> proxy for a client's message when forwarding replies. The VAN
> gateway would generate the MDNs as a proxy as well.
>
> If the trading partner supported S/MIME encryption/decryption, then the
> VAN gateway isn't needed, except perhaps as an internet provider. If
> the VAN performed value-added services (data translation, etc), then
> the VAN would hold the encryption keys and perform services on
> behalf of thier customers.
>
> You could concieve of a VAN acting as a middleman receiving S/MIME
> messages, performing data services, then forwarding processed
> messages to a client using S/MIME. The communications between
> an external trading parter and the VAN would use a different encryption
> key, than the VAN to client communications.
>
> --------------------------------------------------------------------------
> Carl Hage                                              C. Hage Associates
> <mailto:[email protected]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
> <http://www.chage.com/chage/>                          Sunnyvale, CA 94086
>