jkoehring wrote:
>
> I have to admit, I am not very familiar with the openssl commands. The one
> question I have is exactly what are the contents of original.txt after
> running the commands you list? Does it contain exactly the contents of the
> first part of the multipart/signed?
>
> javierm wrote:
>>
>> Thanks for the wait:
>>
>> Well, these are the steps followed
>>
>> <ul>
>> <li> Encrypted body with Mime headers.- body decrypted and
>> multipart/signed message obtained</li>
>> <li> Signature in binary, so processed with openssl pkcs7 to convert the
>> binary signature to b64 (script in perl to extract the binary signature,
>> process it with pkcs7 it and put it back in between the 2nd an 3rd
>> boundary, Content-transfer-encoding changed from : binary to base64--->
>> file produced: signed.txt</li>
>> <li> openssl smime -verify -in signed.txt -nosigs -noverify -signer
>> who.pem -out original.txt (successful, cert found inside used in
>> signature written to who.pem-yes the signer is right)</li>
>> <li> openssl sha1 -binary original.txt|openssl enc -a , </li>
>> <li> and... I don't get the signature that the signer claims I should
>> get!! :confused:</li>
>> </ul>
>>
>> What do you think?
>> Thanks
>>
>>
>> javierm wrote:
>>>
>>> Hi jkoehring:
>>>
>>> <p>Thanks a lot for the help, (ah just noticed another reply from you on
>>> this question placed in another way, thanks). I tried that part too but
>>> did not get the expected checksum. Not that I doubt what you say, but
>>> perhaps I'm mistaken at some point. When I do the verify, the openssl
>>> smime -verify outputs the original document and optionally the
>>> certificate. I was doing the checksum not after the verification, but
>>> instead, I was just processing the multipart/signed document, and
>>> extracting the first portion between the first and second boundary. I
>>> will do it again right now and be right back.</p>
>>>
>>> <p>On the other hand, don't you think the 7.1.8 paragraph of RFC4130
>>> misleads one, by saying <div style="background-color:#ffffcc; border:1px
>>> solid red; margin:20px"> MIC MUST
>>> be calculated across the entire multi-part content, including the
>>> MIME headers."</div> It seems to me a trick to give clients to
>>> "somebody".</p>
>>>
>>> <p>Thanks</p>
>>> Later, <br>
>>> Javier
>>>
>>>
>>> jkoehring wrote:
>>>>
>>>> If I understand your question correctly, you are asking how to
>>>> calculate the MIC (SHA1 checksum) to put in an AS2 MDN.
>>>> <p>
>>>> The MIC should be calculated over exactly that data that was signed in
>>>> the original AS2 message. The data used to calculate the MIC should not
>>>> include the actual signature. Thus, the MIC should be calculated over
>>>> that data that appears between the first two boundary markers in the
>>>> multipart/signed of the original AS2 message. Note that the first
>>>> boundary marker includes the trailing CRLF and the second boundary
>>>> marker includes the leading CRLF. Thus, those CRLF sequences should not
>>>> be included in the MIC calculation.
>>>>
>>>>
>>>> javierm wrote:
>>>>>
>>>>> Can anyone help me with the procedure to calculate the message
>>>>> integrity check in this RFC?
>>>>>
>>>>> it's about calculating the sha1 checksum over a multipart message.
>>>>>
>>>>> This is the text in the RFC (http://www.ietf.org/rfc/rfc4130.txt),
>>>>> chapter 7.1, paragraph 8)
>>>>>
>>>>> <div style="color:#0000ff; background:#ffffcc; font-size:8pt;
>>>>> border:1px solid red; margin:20px"> The EC Interchange and the RFC
>>>>> 1767 MIME EDI content header can
>>>>> actually be part of a multi-part MIME content-type. 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.
>>>>> </div>
>>>>>
>>>>> My problem is that i think I understood, but another software gives me
>>>>> a different checksum for the same message.
>>>>>
>>>>> <ul>
>>>>> <li>I canonicalize headers, no problem</li>
>>>>> <li>I process signature of message with openssl which provides a
>>>>> multipart file</li>
>>>>> <li>I calculate sha1 over exactly that output file</li>
>>>>> </ul>
>>>>>
>>>>> Is there something done wrong in this procedure? Whant to try some
>>>>> examples?
>>>>> This file is a multipart output from openssl
>>>>> http://www.nabble.com/file/p18034577/mictest.txt mictest.txt
>>>>>
>>>>> Ok, not directly. Because openssl produces the base64 signature,
>>>>> which I detach to then transform to binary or "DER" and I attach it
>>>>> back, with the corresponding change in Content-enconding: binary.
>>>>>
>>>>> For this file I get IpWFspJ2hKwfja5CkOPnDW2ctT8=
>>>>> The other trading partner says: Uiaz1kOChhlSb/f3SJsmJ/O/8SI=
>>>>>
>>>>> Could this be a mere misunderstanding of the RFC?, I've seen way
>>>>> different "interpretations" on the net, which I have tried but don't
>>>>> work either.
>>>>>
>>>>> Well thanks for the help
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18067148.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
