Re: Non-repudiation for Message Disposition Notifications

[carl@xxxxxxxxx (Carl Hage)]

Karen Rosenthal (karenr@premenos.com) wrote:

: 1.  Section 4.2 in draft-ietf-ediint-as1-01.txt specifies that the
: X-Received-MIC extension will only be included in the 2nd body part of
: the MDN when 'the received contents are successfully processed'.  Am I
: correct in interpreting 'successfully processed' to mean decryption,
: authentication and integrity checking all succeeded?

As mentioned here and email with Chuck, I have some problems with these
extensions used in the receipt, both on the name 'MIC' and the definition
of the content.

First, I think it would be much simpler to set the algorithm and use
'MD5' rather than 'MIC'. A 'MIC' should imply the general syntax of
multiple algorithms, where an algorithm ID and data value are included.

Also, I think an MDN should not be dependent on the format of the content,
and the MICs included should support any type of message, not just the
specific EDI use of messages. In order to be general, a "Content-MD5:"
(already an RFC) should be used, which covers the content following
the main RFC822 headers.

It would be more convienient to list the MD5's of the EDI X12/EDIFACT
interchange data, rather than the MIME_header+data. To generalize beyond
the simple EDI MDN, a X-Data-MD5: header could contain one or more MD5-MICs
of MIME data, e.g. attached files, application data, etc.

If the purpose is to claim that the recipient has checked the signature
and authenticated (as opposed to simply receiving the document) the
signature, then the name should probably be changed to "X-Authenticated-MD5",
to make this more clear.

: 2.  When the X-Received-MIC is NOT included, I understand that the
: proposed way of matching up the receipt with the original message is via
: the Original-Message-ID.  We are using Simple MAPI with Microsoft
: Exchange, and through Simple MAPI, do not have application access to the
: Message-ID that MS Exchange assigns ...

A Content-MD5 addresses this problem. Add this header to the  RFC822
headers, include this in MDN-part2, and I also suggest adding the
received headers without the content, but with the Content-MD5 in MDN-part3.
This works for any message.

: 3.  Is the request for the MDN placed in the message header, or in the
: body part header(s)?  The draft says message, which concerns me.  
:    a. If it's in the message header:
: 	. we are unable to use it using Simple MAPI with MS Exchange. 
: 	. how would a message containing attachments / multiple body 
:           parts be handled, especially if some are signed, and some are
: unsigned?

MDN requests, by definition are in the RFC822 headers, and is
specifically designed to be used with MTA/UAs.

MS-Mail is severly brain damaged. Too bad it's impractial to discard.

What does MS-Exchange do with header data? (I tried accessing
www.microsoft.com but they now use a Java user interface, which in
addition to making the site almost unnavigable, has severe bugs making it
useless.)

The RFC822 email standards use headers. Any email system that can't
access and use these is going to have serious problems. You will
*have* to build a system that can send and receive the RFC822 headers
properly, possibly by a hack that includes the headers within the MAPI
message body. However, to the outside world of SMTP, headers are by
definition above the message.

You can't use the MS-Mail attachments, etc. These must be first wrapped in
MIME wrappers, then security services applied, then sent.

You could build an interface that sits between the SMTP/POP and the
MAPI message with attachments, which performs security services, then
sends the unencrypted/unsigned data to the MAPI, with results of the
security processing in an attached file. Attachments, etc. can be supported
after decrypting/authentication.

:    b. If it's in the body part header(s), at which level is it placed
: (i.e. for

It's not in the body part, and I would suggest not using any MS-MS
kludge that used nonstandard messaging. You can use a MS kludge for MAPI
as long as the message sent across the Internet complies with the standards.

: 5.  Is subject: Disposition notification, placed in the multipart/signed
: mime header?  If not, where?

Subject: is in the RFC822 headers only, except in a Digest of messages.

: 6.  Is the content of the MDN's 1st body part text standardized?

No it is free form, designed for a person to read. However, this should
include an explaination of errors.

: 7.  Are the following the only valid values for EDI? 
: 	autoprocessed
: 	decryption_failed
: 	authentication_failed
: 	integrity_check_failed

More are needed.

: 8. Is the X-Received-MIC base64 encoded?

It's undefined in the prior spec. If Content-MD5 is used, the encoding
is defined as in RFC1864, a 16 byte base64 value.

: 9. What is the anticipated use of the MDN's 3rd bodypart?  

I suggest including the RFC822 message headers in the message received
including a Content-MD5.  This is useful for tracking the message through
MTAs.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086