Re: Non-repudiation for Message Disposition Notifications

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Karen,

The draft is changable and still open to discussion. Let me at least
answer your critical questions:

1). Successfully processed means the sender has been authenticated
    and message integrity verified. Because the specification
    is requiring a two step sign and encrypt process for S/MIME,
    if the content is encrypted, then the decryption would need
    to be successful before authentication and message integrity
    could be verified. So your interpretation is correct.

2). This is a difficult problem if you can't get access to
    the original message id. The following solutions
    won't work:

    a). Always return the received MIC because there
        is no guarantee that the receiver can always
        access the MIC. For instance if decryption
        fails, there is no way to read the MIC. 
       
    b). Returning the entire message is not a good
        solution either and I won't recommend it.

A question for you: On the receiving end can you get access to
the message id? You will need to get access to this in order to
send it back in the signed receipt. 

One solution to the above problem is to use a content-md5 on the
original message and return the header information in the third
body part, which of course would contain the content-md5 that
was received by the receiving trading partner.

Again all of this pre-supposes that the UA has access to the header
information since the content-md5 is part of the message header.

It sounds like you are having problems accessing header information.
Is it everything in the header, or just the message id?

3. The request for mdn is part of the RFC822 header and not part of
   the PKCS#7 envelope. AS#1 specifies that if you have a MIME
   multipart, that you sign across the multipart and make this
   MIME multipart the DATA portion of the S/MIME signedData
   content. Does this make sense? There is no provision to
   acknowledgement individual content within a multipart content.

4. I'm not sure what you mean if S/MIME Version 1 is acceptable.
   The AS#1 really defines applicability of S/MIME based on Version 2.
   Not everything in Version 2 needs to be implemented for
   Internet EDI. Is there something specifically that you
   have in Version 1 that is not in Version 2        

  
 
Karen Rosenthal wrote:
> 
> Chuck,
> 
> Thanks for the information - all is appreciated.  Whether we can
> implement the signed receipt as it is specified depends on the answers
> to the following questions:
> 
> 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?
> 
> 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 (I've heard that there are other
> mailers with this same problem). How then, are we able to match up the
> receipt with the original message (PLEASE don't say we need to return
> the entire original message in the 3rd bodypart of the MDN!!)?
> 
> 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?
>    b. If it's in the body part header(s), at which level is it placed
> (i.e. for
>           S/Mime Version 2, at the application header, SignedData header, or
>           EnvelopedData header?
> 
> 4.  Is S/Mime Version 1 still acceptable for use with the Signed MDN, or
> is S/Mime Version 2 required?
> 
> Continuing with some non-critical questions:
> 
> 5.  Is subject: Disposition notification, placed in the multipart/signed
> mime header?  If not, where?
> 
> 6.  Is the content of the MDN's 1st body part text standardized?
> 
> 7.  Are the following the only valid values for EDI?
>         autoprocessed
>         decryption_failed
>         authentication_failed
>         integrity_check_failed
> 
> 8. Is the X-Received-MIC base64 encoded?
> 
> 9. What is the anticipated use of the MDN's 3rd bodypart?
> 
> Thanks again...
> Karen
> 
> Chuck Shih wrote:
> >
> > Karen,
> >
> > The newest AS#1 draft should be posted on the ietf web server
> > today or tomorrow. An announcement will go out on this. I
> > got an e-mail from Roger Fajman and he will put out a new
> > mdn draft on 11/26.
> >
> > Can you implement the signed receipt as it is specified?
> >
> > Karen Rosenthal wrote:
> > >
> > > Greetings,
> > >
> > > I am checking on the status of draft-ieft-receipt-mdn-01.txt, the
> > > Internet Draft for An Extensible Message Format for Message Disposition
> > > Notifications, which is due to expire on November 18th.
> > >
> > > This draft does not provide a mechanism for Non-Repudiation.  It is my
> > > understanding that a group is currently working on a proposal to provide
> > > for NRRs.  In looking through CommerceNet's interoperability test
> > > scripts, it appears that an addition has been made to the MDN's 2nd body
> > > part, which would be headed:
> > >
> > >         MAC_Info:
> > >
> > > and then contain the message digest type used (i.e. MD5), and then the
> > > base 64 encoded (signed?) MD5 of the original message.
> > >
> > > This is my understanding of what has been proposed to-date.  I am only
> > > assuming that the MD5 would be signed as it made the most sense,
> > > although the only thing I've read on what was to be signed, was
> > > CommerceNet's test script # 12, stating that "An MDN should be returned
> > > within a signed bodypart", which was ambiguous to me.  Any clarification
> > > / corrections to my understanding would be greatly appreciated, as would
> > > any information on when an RFC, or updated draft can be expected.
> > >
> > > I'm also curious as to the expected use of the 3rd, optional bodypart.
> > >
> > > Much thanks,
> > > --
> > > Name:   Karen Rosenthal
> > > E-mail: karenr@premenos.com
> > > Phone:  (510)688-2928
> > > Fax:    (510)602-2133
> 
> --
> Name:   Karen Rosenthal
> E-mail: karenr@premenos.com
> Phone:  (510)688-2928
> Fax:    (510)602-2133