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

[Rik Drummond <drummond@xxxxxxxxxx>]

When we did the requirements for EDI over Internet over a year ago we kept the nrr at the mime level. This does not say that there could not be additional stuff at the transaction level. What do the EDI vendors on the list think about this?  Regards, Rik

-----Original Message-----
From:	Gunther Schadow [SMTP:gunther@xxxxxxxxxxxxxxxxxxxxxxxx]
Sent:	Thursday, November 13, 1997 2:16 PM
To:	carl@xxxxxxxxx; gunther@xxxxxxxxxxxxxxxxxxxxxxxx; ietf-ediint@xxxxxxx
Cc:	hl7-mime@xxxxxxxxx
Subject:	Re: A simpler approach to bilateral non-repudiation of EDI trans

Carl Hage <carl@xxxxxxxxx> wrote:

thank you for your oppinion. It is good to see that the problem of
many mail messages per EDI transaction is seen. It is also good to
hear that other EDI standards have an application ACK as well. To
focus, I wiped off everything that we agree upon. What I am sceptic
about is, whether sticking to signed MDN for completion of EDI
transactions is so essential as you describe it.

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.

  > > Our solution does not need NRR at all, since it focuses not on
  > > singular EDI messages but on complete EDI transactions ...
  > > This is achieved simply by adding a header field named
  > > "Received-content-MIC" to the specification of the RFC1767-ish
  > > application/edi* MIME container.
  >
  > No, please don't do this. You are moving email-transfer functionality 
  > out of the application-independent standards and bundling them with 
  > application-specific information.

That was the feeling everyone had against my proposal the first time,
even myself. But I think it deserves a second look: I unserstand 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.

Take the following example: MIME can be used not only by e-mail but
also by HTTP. If I want to send an EDI message via HTTP, I can put it
into an "Application/EDI*" MIME container and send it over HTTP. Then,
if I want it non-repudiateable, I wrap it into multipart/signed. HTTP
does not know about, nor does it need MDNs because HTTP is not
e-mail. But still I need EDI responses to be securely linked with
their request. 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).

This clearly suggests to me that EDI ACK is an issue that resides on
the MIME level (because I want MIME security multiparts) but should be
treated completely independent from e-mail MDNs. 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.

I would go even further and suggest to define "Content-ID" and
"In-Reply-To: <content-id>" header fields in the RFC1767
container. This would allow the MIME EDI layer to issue (unique)
message IDs independently from both, e-mail Message-IDs *and* EDI
protocol specifics.

  > The extra MIME wrapping material is a little more data, but the 
  > result is an elegant separation of transport, security, 
  > receipt-processing, and application-processing. All can function 
  > independently of each other in different combinations.

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". In the following table I picked your keyords and arranged
them in a layerd model.

	LAYER		       EXAMPLEs
	---------------------  ----------------------
	transport	       e-mail, HTTP, ...
	security	       secure MIME multiparts
	non-repudiation        ???
	general EDI	       MIME EDI wrapper
	protocol-specific EDI  EDIFACT, X12, HL7, ...

As you see, I changed one word: receipt-processing to non-repudiation,
because our main concern in secure EDI is non-repudiation of the whole
transaction, not receipt of singular messages. I find that the
non-repudiation issue lies between security (it certainly is a matter
of security) and general EDI issues, because EDI is used to
communicate legally valid transactions. I suppose that this is an
issue pertaining to EDI in general, whether commercial or health care,
it is not protocol (say: X12, FACT, HL7) specific. Thats why I suggest
to solve this issue in the EDI wrapper. After all, there is no
solution more efficient and straight-forward than that.

best regards
-Gunther


PS: 

So far I suggested the Received-content-MIC to be calculated over the
whole RFC1767 object. However, since an optional Content-MIC
(according to RFC1864's "Content-MD5", but allofing different micalgs)
could appear in the header of RFC1767 and it is non-sense to have a
MIC be calculated over some data including itself, the scope of
Content-MIC and Received-content-MIC should be the *content* of the
RFC1767 wrapper (i.e. the EDI message in its transfer encoding form)
not the wrapper itself.

And here is an other reason why I want the application/edi container
to be more powerful: because it is a problem for any security working
group inside an EDI standards organization to calculate MICs and
implement signatures within their own messages! The problem is, you
can only sign or encrypt bit streams not application objects. That
means, you must provide a readyly presented EDI message in order to
sign it. It is thus very difficult to have an EDI message sign
itself. The MIME container is a good place to abstract out all
checksum/MIC/signature/encryption problems from your EDI application
protocol. That's why I love RFC1767 and RFC1847!