MIC calculation

Good afternoon. 

If you would be so kind as to clarify one point. This is regarding the MIC 
calculation. 
The MDN seems clear for signatures. The problem I am having is not seeing (for 
sure)
when this applies and is calculated on specific data (sometimes it includes the 
MIME and sometimes not it seems).

When the ANSI X12 file is not encrypted it seems that RFC Draft 19 para 7.1 
applies:
"When the EDI Interchange is part of a multi-part MIME content-type, the MIC 
MUST be calculated across the entire multi-part content, including the MIME 
headers."

This may be pretty clear, I am just confirming.
 
There are two points I hope to clarify. The first is that the question relates 
to just an AS2 Message (not the MDN message or reply) and the digital signature 
when the file is encrypted and when the file is not encrypted, keeping in mind 
the draft extract above.
 
However, the way I understand is 

1. The hash is calculated on the file (raw unencrypted edi file) as a detached 
body
2. The hash (document digest) is encrytpted with my private key thus creating a 
digital signature
3. The digital signature and document are then encrypted with a one-type 
symmetric symmetric key (say 3DES)
4. The one time key is now encrypted with my trading partners public key. We 
now have a "package" or digital envolope that can be sent out to the partner.

I must assume that encrypted data is handled differently than unencrypted data 
as far as the hash calc is concerned as it relates to signatures. 

Below is an encrypted and decrypted method of calculating the hash (MIC) using 
MD5 or Sha1. Note the "&" which shows what data is calculated.
 
synchronous MDN Request  UN-ENCRYPTED DATA :
Message-ID: < 1234555646566356636345646365646363456346546 >
Date: Thu, 23 Dec 2004 03:07:56 GMT
From: SYSTREND
Subject:  your AS2 DATA:SYSTREND
Mime-Version: 1.0
Content-Type: multipart/signed;  boundary="----=4686652.1103771276335"; 
protocol="application/pkcs7-signature"; micalg="sha1"
Recipient-Address: 127.0.0.1// whatever 
Disposition-Notification-To: http://127.0.0.1:4080/AS2/SYSTREND
Disposition-Notification-Options: signed-receipt-protocol=optional, 
pkcs7-signature; signed-receipt-micalg=optional, sha1
Receipt-Delivery-Option: http://127.0.0.1:4080/AS2/SYSTREND
AS2-From: SYSTREND
AS2-To:  xxx 
AS2-Version: 1.1
Host: 127.0.0.1:4080
Connection: close
Content-Length: 11681
 
------=4686652.1103771276335
& Content-Type: application/EDI-X12; name=SYSTREND_ xxx_111.edi
& Content-Transfer-Encoding: binary
& Content-Disposition: attachment; filename=SYSTREND_ xxx_111.edi
&
& ISA*00*          *01*XXXXXX    *SY*STREND         *ZZ*asdfasdf         
*961106*2106*U*00302*000000111*0*P*>
& GS*DX*2162523233*2102468507*961106*2106*666*X*003020UCS
& ST*894*6300001
 
[Some EDI data removed]
 
& SE*2591*6300001
& GE*1*666
& IEA*01*000000111&
------=_Part_91_4686652.1103771276335
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
 
0   U    US10  U   Tempe1 0   U   SYSTREND  U    SHAN0Ÿ  *†H†       0‰  
Þz<u 4Ò¡ U(âº|e  ÕéÒ¨Ãÿ©N]v·BÔÃ~‚M/…ýË› ð€\®öìÞí§›"ÉŠ¡¢"Oï ~YÐ-sfOH
------=_Part_91_4686652.1103771276335--
 
 
 
synchronous MDN Request  ENCRYPTED DATA :
 
Hash is calculated on the un-encrypted file only and then attached to the MIME 
as a multi-part signed object (encrypted data and signature). It does not seem 
possible to consider the MIME headers in the mime calculation here.

For example, the MIC would have ben calcualted over the encrypted below but not 
the MIME because its not a content type multi-part:


Host: 127.0.0.1:4080
Connection: close
Content-Length: 1998

------=_1103771206224_000
Content-Type: application/pkcs7-mime; smime-type=compressed-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m

& 0€ *†H†÷               €0€   0 *†H†÷     0€   *†H†÷   €$€ ‚ gxœíšAOÛ0 
†ïHü‡œrø¤vc; h“ºÆj#U´Šƒ(½ Ê     Ò záßï³ ” 
& ;ìøù 5Îó¾Óç˜ñÛoºý yÙmÎ’õn÷ÐÞ®÷íûfËj°äâ<é֏›ïîÚ5µ½(ošùÍjU•å²²7œ³áæ®== 
¿µ<­»çûÍÓÀv•Û»û}–
& üj»õÓË )ÛçÝö¹õKàzûýúöÏ#Ο'÷íÃæ–:=©Ü  ƒä} ã°#ܹkè Àj }ÏaªÐX©AøË%öeLàÕ œ ø‘N 
”KD´P" Yæi!µQ,?Êk­aÙw°Ë±K] ¦ ³P—
& NŒ€ $“¾±¼ 2W •m ÞJn  þ Ç_¡˜ótæ€3†Ù8äbˆM`ýÁ¹Áy¦•É Ç › À¤©.&ÉxT—!$€ 
¥²—ð)î`ÌÓ.àÙ—¸.^q\ä — ä':W š°¥ @°˜–
& \2ÕwË ×`bXj.z¸ˆà t¼m© 7=ÍÅ1mð” ­r£‹°m Á Â:¦‹Œ ¯ÛŽp´æSyf´`7Þ\ 
®F³Ùb´°uŸâÀãã*Ãrññ½cê§ ÕÉt>+ýŸ<Å›>-
&  V˜\êp ø]ñì‹ã …1ÑZãËÆ&aÁÚÎìÈU}Z~N‹Â{ 
4”AC;¸šV˜®çκd17ó>ÞÂä3ùL>“Ïä3ùL>“Ïä3ùL>“Ïä3ùL>“Ïä3ùL>“Ïä3ùL>“Ïä3ùL>“Ïä3ùL
& >“Ïä3ùL>“ÏÿËçÔY ½zÿZÏ¢àZë´ò½ X œ³ô/w³§„            
------=_1103771206224_000
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary

0‚ ¦    *†H†  ‚ —0‚ “   1 0       +     0       *†H†   ‚  0‚  0‚ {       
U<|ÕÔ¿…¹ .îĝcP       *†H†      0?10    U    US1 0  U   Tempe1 0   U   
SYSTREND1  U    SHAN0  041223023830Z  061223023830Z0?10          U    US10  U   
Tempe1 0   U    SYSTREND1  U    SHAN0Ÿ        *†H†       0‰  Þz<u 4Ò¡ U(
âº|e éÒ¨Ãÿ©N]v•BÔÃ~‚M/…ýË› ð€\®öìÞí§›„ÉŠ¡¢„Oï ~YЗsfOH 
¿ð_K©Ý[“h‘°4YPÃ¥F³æ³žLµª²ã²76G»ä Ÿý|—õ'Š!%AšaG Üîn?èC‹     £ 0  U        0      
*†H†       Ñ'•…~ }€UùaeỶ(¨ °ö…,9c›À ßࡤþ´ h¥{…À$÷ †qÿîS  ÷Áía͐ RŸ 
ÖW0ÏúçrWq'm¾/ß  [ý€> ÿ êbÿpÉIQMÖ" € Ý î’¨ B»ã½Gáä(÷ 1uÏêtØé<å%Ò”MÅ‹1‚ X0‚ T   
0S0?10  U    US10  U   Tempe1 0   U    SYSTREND1   U    SHAN  U<|ÕÔ¿…¹ .îĝcP0 
    +      ]0     *†H†-ÆBqXÞ  £íAk³;‹™X\² ° C„Ÿ IÉC ѵÁ, IÖõG”á
------=_1103771206224_000--

 
Thank you for your help.
 
Shan





CONFIDENTIALITY NOTE:
This message and any of the attached documents contain privileged and 
confidential information only for the use of the individual or entity 
that was the intended recipient.  If you are not the  intended recipient 
you may not read, copy, distribute, retain or use this information. If 
you have received this message and any of the attached documents in 
error, please immediately notify the sender by reply e-mail and then 
delete this message.  Thank you.