On Wednesday August 6th 2008 at 20:42 javierm wrote: [ RFC 4130 calculating MIC, mostly offtopic for OpenSSL ]
> Sorry about the lengthy post, but it's worth to seem or be redundant. I > give proofs I have read it all, but will comment on just a few points. > ... > > I found that commercial packages agree that THIS messageDigest is the VALID > MIC to return on the MDN There really is only one way to calculate the MIC (the message digest) so of course they should all agree! I know the RFC says to canonicalize the contents, but as far as I know this doesn't happen in practice. Canonicalizing the contents would be impossible to begin with, because you would have to know which is "text" (so has line endings) and which isn't. Strictly speaking you should have a "Content-type:" header in every RFC 4130 (AS2) message, but as far as I know no canonicalization of the contents takes place. The MIME headers might be a different story. A certified AS2 product that I have made _never_ canonicalizes received MIME headers and works fine. On sending we always generate MIME headers with "\r\n" (DOS line endings) but that is because RFC 2616 (HTTP) requires (or advises) this. There might be products that canonicalize "\n" MIME headers to "\r\n" before calculating the MIC; I don't know that, it will be safest to just generate the MIME headers (and MIME boundaries of course) with "\r\n". > If you make your message and you sign it, you will find this. I think there might be a problem with your signing which is the problem. > ... > Notice that ALL 3 signatures have the same MESSAGE DIGEST So there is a problem with your signing, it's as simple as that. Different byte sequences should always result in different message digests. At least separate the canonicalization (which I maintain isn't necessary) from the calculation of the MIC itself. This makes analysing what's going on much clearer. Calculating an MIC is basically just feeding a bunch of bytes to some OpenSSL routine, and always results in the exact same answer, which is also exactly the same as the value encoded in the PKCS7 encapsulation. > Notice that EVERY one of the MICs CALCULATED FIRST are different AMMONG > THEMSELVES, this is what you said, and I agree, because data is different > > But also notice that ONLY ONE OF THE MICs MATCH THE messageDigest inside all > signatures Yes, because your signing uses canonicalization, so the input to the message digest calculation is not three different messages but rather only one. And of course the only one that "matches" will be the one that happens to be the same before and after your canonicalization. > Which ONES MATCH? > > > Not the one from the text not canonicalized > Not the one from the text WITH ONLY MIME HEADERS canonicalized > BUT THE ONE from text WITH ***ALL CANONICALIZED*** So your signing process uses full canonicalization. That's wrong and explains the failure with other products. > I have gone through another test about weird UTF-8 encoding but without > success. They send me UTF-8 data (containing a,e,i,o,u "acute" and n with > tilde in their UTF-8 encoding) and all that is further encoded again in > UTF-8. I've done the double decoding, again the things of the > canonicalization but still the MIC and messageDigest don't match. For calculating the MIC al this characterset encoding and possibly transfer encoding like "quoted-printable" (yes even this happens!) is completely irrelevant. Just take the bytes as an opaque structure, calculate the MIC and compare with the original. > These are just facts (not opinions) placed in words meaning "this happens" > if only MIME headers are canonicalized: THE BUSINESS PARTNER'S "certified > software" WILL REJECT your calculated MIC unless you watch the messageDigest > inside the signature and make it MATCH with the MIC calculated. (more > práctical if you forget about calculating MIC and simply fetch the > messageDigest inside the signature and send it back in the MDN's MIC. The wording of the RFC 4130 is sometimes a little vague and there are lots of details only determined in practice but calculating the MIC is possible. As with many RFC's, only see it as a common starting point and concentrate on the way it is used in practice, which often differs. And as they say don't attribute to malice which can be explained by sheer incompetence! ;-) So my advice: on sending use MIME headers and MIME boundaries (and HTTP headers, although not relevant for the MIC) with "\r\n" headers, and do not do any further canonicalization, either on sending or receiving. So in OpenSSL (finally something on topic!) always use the "PKCS7_BINARY" flag in the relevant function calls. -- Marco Roeland ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
