Re: A simpler approach to bilateral non-repudiation of EDI trans

["Carl Hage" <carl@xxxxxxxxx>]

> Date:          Thu, 13 Nov 1997 21:16:11 +0100 (MET)
> From:          Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxxxx>

Working late I see? :-)

> As you say:
> 
>   > [...] By 
>   > using standard MDNs, the receipt process is within the mail system, 
>   > not the application processing content.
> 
> What I think is necessary for EDI over internet is to focus back to
> the "application processing" rather than the message *delivery*
> issues. What I want is to have the applicational aspects that are
> specific to EDI in the MIME-EDI container and not linked to MDNs.

I agree here. What is in the MIME application part should be EDI (or 
other application) and conversely, what is outside this is the 
message transport, security, and reliability/NRR/tracking.


> I understand your
> objection as follows: providing a MIC of the EDI request within the
> reply EDI-MIME container is moving email-transfer issues into
> application specific functionality. Why not see it the other way: what
> I am doing is keep applicational issues out and away from
> email-transport functionality. I am not telling we should abuse EDI
> ACKs as e-mail receipts. I want EDI ACKs to be independent from email
> transport issues.

But I consider the MIC of a prior message to be part of the message 
transfer/transaction, not part of application data. In other words, 
the application does not create the MIC, add the Message-ID, etc.

The EDI ACKs can be independent, but the receipt process used to 
assure message delivery should be at the same level as the security 
encryption/signatures-- separate and layered around the application 
data. The application data _should_ not be used to assure reliable 
delivery or for NRR. Likewise the application _should_ not perform 
the digital signatures and encryption, e.g. the MIME security should 
be used instead of the X12/EDIFACT security.

> Take the following example: MIME can be used not only by e-mail but
> also by HTTP.

MDNs are independent of the transport. They can be used with SMTP, 
POP, UUCP, HTTP, etc. However, if HTTP is used as a transport 
protocol, then NRR requires each transaction to have a unique 
message-ID (for tracking). By including the RFC822 headers in the 
transaction, an HTTP front-end acts essentially like a gateway to 
some proprietary email. All transaction security becomes independent 
of both transport and application.

I can do it with Received-content-MIC inside the
> EDI-MIME wrapper. If I do so, I can even go and replace the MIME
> security multiparts by SSL or whatever, and still, whenever I sighn
> MIME-EDI containers I have a means of tight secure link between
> response and request (or what other conversational patterns you might
> think of).

With SSL, you could strip off everything and pass the contents 
directly for application-application transfer. (No need even for the 
MIME header, unless you want to send multiple types to an SSL 
socket.) An application level ACK is required in this case to pass 
control from sender to receiver. The received MIC is not needed with 
SSL.

There is a flaw with SSL though, in that there is no way to sign the 
data after a transfer-- a signature is only used at the start of a 
session for authentication, and hence there is no NRR. A signature 
could easily be added to SSL though.

> In fact, I still want
> you to be able to use MDNs for youe EDI *e-mail*, but the requirement
> to securely link EDI responses to their requests should be kept on an
> e-mail independednt layer of MIME. I think that RFC1767-ish wrappers
> are the right place to put them.

Actually the MDNs apply to delivery of a transaction, i.e. "message", 
not necessarily of an SMTP email message.

> 
> I would go even further and suggest to define "Content-ID" and
> "In-Reply-To: <content-id>" header fields in the RFC1767
> container.

Sure, then add a Content-Type: multipart/report, a few extra headers, 
and you end up with what I suggest. I think it's a bad idea to 
violate the Content-Type header format by moving headers from other 
MIME types onto it. It's a little bit more in length, but 
MIME is awfully verbose anyway.

> But the receipt processing is tightly linkled with e-mail delivery
> (hence message *delivery* notification). Bilateral non-repudiation of
> EDI transactions is an issue that does not reside on the e-mail
> "layer".

The From:, To:, Date: and Message-ID: headers uniquely identify a 
"transaction". I suppose you could say a MIC alone uniquely 
identifies a transaction. But for non-repudiation, it's useful to 
have all of these labels independent of the application data. That 
way, one system can track data for any kind of application.

> In the following table I picked your keyords and arranged
> them in a layered model.
> 
> 	LAYER		       EXAMPLEs
> 	---------------------  ----------------------
> 	transport	       e-mail, HTTP, ...
> 	security	       secure MIME multiparts
> 	non-repudiation        ???
{This is where the MDN sits in the EDIINT RFC, as a separate layer}
> 	general EDI	       MIME EDI wrapper
> 	protocol-specific EDI  EDIFACT, X12, HL7, ...
> 
> ... Thats why I suggest
> to solve this issue in the EDI wrapper.

What I am saying is that it should be a separate layer, right where 
you've got it. It shouldn't be part of the RFC1767 MIME header (which 
only labels the data with a Content-Type: header), since that 
violates MIME. MIME (which I agree is unnecessarily verbose) is based 
on layered/nested MIME wrappers to complete the set of information 
exchanged. A receipt/ack should be labelled as such with some sort of 
MIME wrapper, whether it's an MDN or some other format.

Mainly what I'm saying is that it's not appropriate to say "if you 
happen to see a Received-content-MIC: header somewhere, then it must 
be the MIC of some other piece of data." All RFC1767 does is define
a Content-Type for EDI application data, and it's not appropriate to 
bundle it with procedures and protocols. What is appropriate is a 
MIME wrapper that says, "I receieved and processed message XXX, and 
here is the MIC. Also, here is some application data for the 
response."
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086