Daniel,
dahepe wrote: > > Code using an external digest and signing the (SHA1) hashed content and > resulting PDF: > http://old.nabble.com/file/p26889586/SignHashedContent.java > SignHashedContent.java > http://old.nabble.com/file/p26889586/itext-signed-hash.pdf > itext-signed-hash.pdf > > The SignHashedContent.java should pretty much do the same as the example > in appendix D of "iText in Action" but without smart card, of course. > That assumption is wrong. What all your code pieces and that example from iText in Action, 1st edition, generate, is a PDF signature with subfilter /adbe.x509.rsa_sha1. This means that a PKCS#1 encoded signature is embedded into your PDF, i.e. essentially an encrypted sequence of a digest algorithm oid and a digest generated using that algorithm. The example in appendix D or more to the point, the method generateNonRepudiationSignature of that BelpicCard class used there, therefore, merely puts the hash presented to it into such a sequence structure (seemingly using a hard-coded SHA1 algorithm identifier) and encodes it. Your SignHashedContent example, on the other hand, applies SHA1withRSA to the calculated hash. This means that it first calculates a SHA1 hash for your hash, then puts that new generated hash into a sequence with a SHA1 identifier, and finally encrypts that sequence using RSA. What you get as a result is not a signature for your document (which is expected by a PDF reader) but a signature for a hash of your document. As it is very unlikely for a document to have the same signature as its hash value has, Adobe will declare your document signature invalid. If you really need a mechanism which does not sign your document directly but its hash, you should use PKCS#7 signature containers, e.g. using subfilters * adbe.pkcs7.detached: The original signed message digest over the document’s byte range shall be incorporated as the normal PKCS#7 SignedData field. No data shall be encapsulated in the PKCS#7 SignedData field; or * adbe.pkcs7.sha1: The SHA1 digest of the document’s byte range shall be encapsulated in the PKCS#7 SignedData field with ContentInfo of type Data. The digest of that SignedData shall be incorporated as the normal PKCS#7 digest. The format for encoding signature values should be adbe.pkcs7.detached anyway, as proposed by the spec. dahepe wrote: > > There is one difference: In line 59 I provide the used hash to the > setExternalDigest method of the signature: > > sig.setExternalDigest(sign.sign(), hash, key.getAlgorithm()); > > In the book's example null is passed instead of hash, but for the non > working validation of the signature this does not matter... > As a matter of fact it does make no difference at all... As you only use that PdfPKCS7 instance sig to generate a PKCS#1 signature (using that getEncodedPKCS1() method), the hash is ignored and only the sign.sign() result is used. Regards, Michael. -- View this message in context: http://old.nabble.com/How-to-sign-examples-tp26886381p26930362.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://www.1t3xt.com/docs/book.php Check the site with examples before you ask questions: http://www.1t3xt.info/examples/ You can also search the keywords list: http://1t3xt.info/tutorials/keywords/
