Technically, the mime-type application/xml requires that ALL content be encoded in UTF-8. (This is an artifact of XML itself specifying that it is always UTF-8.)
If it's not valid UTF-8, then it's not valid XML, which (depending on your environment) may not even need to be evaluated for its signature. -Kyle H On Tue, Jun 24, 2008 at 12:18 PM, javierm <[EMAIL PROTECTED]> wrote: > 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: Re: RFC 4130 checksum in SHA1 > 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]
