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

[Thomas Kent-Dobias <tomdob@xxxxxxxxxxxxx>]

I'm for #2.

>-----Original Message-----
>From:	chucks@actracorp.com [SMTP:chucks@actracorp.com]
>Sent:	Thursday, November 07, 1996 9:28 AM
>To:	Carl Hage
>Cc:	ietf-ediint@imc.org
>Subject:	Re: AS#1 draft-ietf-ediint-as1-01.txt comments
>
>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