Re: AS#1 draft-ietf-ediint-as1-01.txt comments

[chucks@xxxxxxxxxxxxx (Chuck Shih)]

Carl,

I think I understand what you are getting at. Lets throw it out to
the list and ask the question as to what people prefer: 

1). Sending a mdn back with a signed MIC in the MDN extension field.
    The MIC that is signed in the MDN is what the receiver calculated
    on the received RFC1767 and EDI Interchange. The MDN is packaged
    as a multipart/report as specified in the fajman draft. This is
    currently what is specified in the EDIINT Draft.

    ---OR--- 

2. Sending the MDN back as part of a multipart/signed. The first
   part of the multipart signed would be the mdn as specified in
   fajman. The mdn extension field would consist of the calculated
   MIC on the received RFC1767 and EDI Interchange.

   Unlike the first proposal, the MIC in the extension field is
   not signed, instead the entire multipart report is signed which
   includes the calculated MIC in the extension field. This is then
   packaged into a multipart/signed message and returned to the
   originator as the signed receipt.


Carl Hage wrote:
> 
> [Note: MIC is "Message Integrity Check", which is a "one way hash" or
> "digital fingerprint", meaning that like a human fingerprint, uniquely
> identifies a piece of data.]
> 
> Rik Drummond (drummond@onramp.net) wrote:
> : Below the question marks (????) are the mic from the initial message which
> : looks like
> 
> :    initial_message= rfc822+rfc1847(mime(data,..,rfc1767,...),signature(mic))
> 
> [The mic in (????) mentioned here is in the receipt.]
> 
> Not quite. The rfc822_headers cannot be part of the MIC since these
> change as the message passes through MTAs. The MIC should be the decoded
> (base64 or quoted-printable content-encoding) content, or in the case of
> a multipart (e.g. rfc1847), the ASCII data following the initial blank
> line up to the terminating separator. Note that it is very important to
> be precise here, as implementors might use slightly different ways to
> calculate the source of the MIC. It is also important to specify the
> line termination, which is <CR><LF> in most other RFCs.
> 
> (By using undecoded content, this allows mailers to encode/decode content
> without affecting the MIC.)
> 
> If the MDN (receipt) contains the rfc822_headers, then it would be
> possible to use a mic over the rfc822_headers+contents.
> 
> : This logic holds for both the pkcs7 and pgp/mime stuff.
> 
> : Now, I forget, should the question marks be the mic or the signature(mic)?
> : I think the signature(mic) but I think I was talked out of that.
> 
> You are talking about two very different ways of signing in a receipt, so
> I wanted to elaborate here so everyone understands. Regarding the mic or
> signature(mic), the former means the complete MDN is signed vs only the
> original message is signed. Returning a signature of the original message
> vs the complete receipt limits the nonrepudiation, as the receipt can be
> altered. I belive it would be better to sign the complete MDN.
> 
>    receipt = rfc822_headers+rfc1847_signed(mdn(blurb,mdn_hdr+mic,headers))
> vs
>    receipt = rfc822_headers+mdn(blurb,mdn_hdr+signature(message_content),
>                                 headers)
> --------------------------------------------------------------------------
> 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