RE: [EDI-L] RE: ISA14 & MIME-based Secure EDI

True. S/MIME still may be used in case of proprietary or XML document
interchange. It is a nice option to have.

-----Original Message-----
From: Ricardo Johnson [mailto:[email protected]]
Sent: Tuesday, November 27, 2001 10:01 PM
To: Frndjibachian, Levon; [email protected]
Subject: RE: [EDI-L] RE: ISA14 & MIME-based Secure EDI


If you are encrypting at the bodypart level (X12.58) then why bother 
encrypting at the envelope level (S/MIME) ? With X12.58 you could even 
encrypt and sign messages as attachments then route them through VANs, 
X.400, and even proprietary or internal email systems (i.e. cc:mail) from 
any sender to any receiver encrypted and digitally signed all the way. With 
X12.58 the security protocol (layer) is independent of the messaging and 
communications protocol (layer). Plus there are many more advantages as 
well key management, confidentiality, integrity, non repudiation, etc.
Ricardo
At 03:15 p.m. 27/11/01 -0500, Frndjibachian, Levon wrote:

>What if the content 'application/edi-x12' will be encoded according to
>X12.58? Gateway will be able to extract bodypart and route it through VAN.
>So, you always have a choice to encrypt either on S/MIME level or on
>application specific level inside the bodypart.
>Comments?
>
>-----Original Message-----
>From: Jonathan Allen [mailto:[email protected]]
>Sent: Tuesday, November 27, 2001 11:26 AM
>To: [email protected]
>Cc: [email protected]; [email protected]
>Subject: Re: [EDI-L] RE: ISA14 & MIME-based Secure EDI
>
>
>
>Joe,
>
> > This is an interesting point you've made, "The TA1 is only used inside
> > an ISA/IEA pair, and must come before any functional groups.  A VAN
> > shouldn't even be aware of it, since they aren't supposed to open the
> > envelope."
>
>The VAN is only supposed to route on the ISA envelope contents, and
>should not [although, of course, there are always special services :-)]
>go inside the envelope.  That is why one option of the X12.58 security
>operates immediately inside the ISA/IEA pairings.
>
> > There are some who want to receive documents via the internet mail
> > and then pass it through their VAN system.
>
>Our VAN system will operate in precisely that way, so yes, it can
>be a desirable thing to do.
>
> > By encrypting the whole document the encrypted text would hamper the
> > pass-through functionality.  Since a VAN can't look into the ISA to
> > see where the document should go next.
>
>Our VAN has to strip the encoding and MIME stuff in order to determine
>whose mailbox or VAN-forwarding loop the stuff gets sent to.  We don't
>go inside the ISA/IEA envelope for that at all.  But it would mean that
>if we send stuff on by MIME, we recode after mailbox despatching, and
>so the assurances will be from us, not the original sender.
>
> > So if VANs "aren't supposed to open the envelope" then encrypting the
> > envelope should not be an issue for these folks.
>
>But if you encrypt the envelope then you can't read the ISA in plaintext
>and know who to route it to.  I think we have two issues going on at once
>here.  In a MIME/EDI package there are two apparently 'outside' envelopes.
>One is the RFC email headers which have routed the whole email package to
>its current point.  The other is the X12/ISA segment, which tells an
>EDI-aware process how to route or process the EDI next.  The RFC headers
>are outside the encryption, the ISA is inside the encryption.
>
>If anyone is going to route or forward on the basis of the ISA envelope
>then they have to be able to read it in plaintext, so as to be able to
>lookup the receiver and work out how to get there from here.  If you are
>routing only on the RFC headers then you don't need the ISA, so you don't
>need to decrypt the MIME payload.
>
>Jonathan
>---------------------------------------------------------------------------
-
>--
>Jonathan Allen             | [email protected] | Voice:
>01404-823670
>Barum Computer Consultants |                             | Fax:
>01404-823671
>---------------------------------------------------------------------------
-
>--