Oh Boy!! Eureka,
Yes the HEX number in "messageDigest" converted to base64 gives me the MIC that the trading partner expects, though, I can not figure out how this value is obtained based on the original content between the first and second boundary. I calculated the message digest for this "original content" in SHA1 obtaining a binary data which I then convert to base64 using openssl, but in all variations of end of line with mime without mime header (the rfc 1767 header for EDI object), with end of line at the end of the EDI record, and I don't get the same value that comes out from the signature in the second part of the signed message. I also used an online tool for translating all sorts of numbers at http://www.paulschou.com/tools/xlate/ and pasting my original content on first box of this translator, gives me a completely new SHA1 value. %-|. Linux has one straightforward "sha1sum" GNU command to do the same without openssl, and it gives the same result as the one obtained with openssl, so I don't think I'm using the tool in a wrong way because it only needs the name of the file...WHAT DO YOU THINK? The rfc 4130 mentions precisely what you said: a. The message integrity check (MIC or Message Digest), is decrypted using the sender's public key. (I use as1parse, and get the messageDigest record) b. A MIC on the signed contents (the MIME header and encoded EDI object, as per RFC 1767) in the message received is calculated using the same one-way hash function that the sending trading partner used. c. The MIC extracted from the message that was sent and the MIC calculated using the same one-way hash function that the sending trading partner used are compared for equality. jkoehring wrote: > > Yes, I believe the messageDigest in the ASN.1 dump is, indeed, the hash of > the data that was signed. > -- View this message in context: http://www.nabble.com/RFC-4130-checksum-in-SHA1-tp18034577p18098049.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
