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

[Mats Jansson <mjansson@xxxxxxxxxxx>]

I like #2 also.  Mats

At 01:20 PM 11/7/96 -0600, Rik Drummond wrote:
>I vote for #2.....rik
>
>At 11:27 AM 11/7/96, Chuck Shih wrote:
>>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
>
>------------------------------------------------------
>|         Rik Drummond - The Drummond Group          |
>|   5008 Brentwood Ct., Ft. Worth, TX 76132   USA    |
>|      Voice: 817 294 7339    Fax: 817 294 7950      |
>------------------------------------------------------
>
>
>