> From: [email protected] On Behalf Of [email protected] > Sent: Sunday, 10 April, 2011 05:48
> For a file exchange (xml files) between internal applications > we have the need to sign them digitally. Till now we are > using the command-line with openssl. The receiving > application uses the S/MIME / CMS format for verifying. > > openssl smime -sign -in department12.export -out > department12s.export -signer transport.crt -inkey > transport.key -certfile chain.crt -outform der -nodetach > > Due to some sysop restrictions we have the need to move from > a file system based signing to a Java String signing. For Your C or C++ app could call OpenSSL library to do this without using any files (if you have key&cert). (Java might be able to do a JNI wrapper, but not trivially.) Java should use byte[] NOT String for (most) crypto data, since the mapping of String to and from bytes can vary. (String is good for *encodings* of data, like S/MIME, but the above example does not actually use S/MIME.) > that I've looked into the BC classes which look very > promising to me. As a test I've build some small classes, > which should "imitate" the above shown openssl command. > But....it doesn't work the way it should. > BouncyCastle is indeed quite nice for Java. > Anybody got an idea how to "imitate" the openssl behavior? Or > can somebody explain to me what the above parameter does with > the text file (smime signing, cms signing, enveloping...??)? > It does CMS signing, encapsulated (not detached). "-sign" and "-nodetach" should be obvious, "-outform der" implies CMS not SMIME since SMIME (like MIME) is textish. Although I use Bouncy for other things not CMS, just looking at src/.../cms/CMSSignedDataGenerator.java and test/src/.../cms/NewSignedData.java (in crypto-146) I easily matched OpenSSL with minor exceptions: - BC doesn't put smime-capabilities in the signed-attrs as OpenSSL does by default (but you can suppress, and probably should, they're not needed here) - BC uses indefinite-length encoding some places Neither should matter to any sensible receiver. OpenSSL (as per manpages) does 'canonical' S/MIME formatting, which apparently means CRLF linebreaks, unless you specify -binary, which you didn't. Bouncy apparently doesn't, at least not that I find on a quick look, so if your data contains lone LF, you will get slightly different results. I don't know if XML specifies CRLF, but it is supposed to be portable text and portable text usually means CRLF.
CMS_Sign.java
Description: Binary data
