The mechanism for calculating the MIC for an AS2 message is exactly the same as that for an AS1 message. The two protocols are practically identical except that the outermost contents of AS1 messages are frequently encoded (base64 , quoted-printable, etc) so that they may be transported safely over SMTP. Otherwise, AS21 and AS2 messages are "packaged" identically.
The paragraph you are referring to in section 7.1 of RFC 4130 is referring to the situation in which the data being transported in an AS2 message is a multipart. That is, the first part of the multipart/signed is, itself, another multipart. It is not saying that the MIC should be calculated over the entire multipart/signed, just the first part of the multipart/signed. Another way to look at it is when the original AS2 message is signed, the MIC for the MDN should be exactly the same as the hash used in the calculation of the signature for the multipart/signed. javierm wrote: > > Just a note, I've found documents like http://ietfreport.isoc.org/all-ids/draft-ietf-ediint-compression-08.txt which in secction 2.1 says to calculate MIC on the original data that was signed as PER [AS1] (but 4130 is AS2) > > In section 7.3.1.3 of 4130, first paragraph in bullets it is said: > > For any signed messages, the MIC to be returned is calculated > on the RFC1767/RFC3023 MIME header and content. > Canonicalization on the MIME headers MUST be performed before > the MIC is calculated, since the sender requesting the signed > receipt was also REQUIRED to canonicalize. > > and in 7.1.8 of 4130 > > > 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. > > > In any case I tried > > *the original data > *the 1767 (edi block with header and content) > *the whole multipart/signed document (this multipart/signed header + the > edi block and the signature block with boundaries, etc) > > > which else should I try? > > Thanks > > > > -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18062776.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
