Paulo, Dániel, Raitskin, Paulo Soares-3 wrote > If iText is producing damaged PDFs please tell where. As far as we know > there are no issues here. You should really take to problem to the Foxit > team, it's their application that is complaining, they should know why.
Yes, it's Foxit that is complaining and unfortunately not verbosely enough, it merely summarizes that "the document has been altered or corrupted since the Signature was applied." Thus, they should be informed about this kind of signatures. On the other hand, though, the signature container in http://www.darina.us/code/uploader/adobe.pdf adobe.pdf really is a funny animal. * It is the first signature I come across that actually makes use of the option to apply indefinite-length Basic Encoding Rules (BER) encoding. * Its single SignerInfo (see below) does not contain any attributes, neither signed nor unsigned ones, especially not a MessageDigest. For a "adbe.pkcs7.detached" kind of signature this to me seems wrong. As a signature of that kind it has an empty encapsulated content field, and as there are no signed attributes either, the data signed according to the "Message Digest Calculation Process" in RFC 3852 are completely empty. Maybe the Adbobe Reader implements the specification's wording "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" in this case by digesting the PDF byte range data...? Anyway, it at least is uncommon to not use the MessageDigest signed attribute for such signatures. Regards, Michael PS: The SignerInfos of adobe.pdf... > signerInfos (SignerInfos) ::= SET OF (1) { > SignerInfo ::= SEQUENCE { > version (Integer) V1 (1) > sid (IssuerAndSerialNumber) ::= SEQUENCE { > issuer (RDNSequence) ::= SEQUENCE OF (1) { > RelativeDistinguishedName ::= SET OF (1) { > AttributeTypeAndValue ::= SEQUENCE { > type (Oid (CommonName|cn)) 2.5.4.3 > value (PrintableString) ALEX-PC2008-CA > } > } > } CN=ALEX-PC2008-CA > serialNumber (CertificateSerialNumber (Asn1Long)) > 84629308518189615808519 > } > digestAlgorithm (AlgorithmIdentifier) ::= SEQUENCE { > algorithm (Oid (SHA1)) 1.3.14.3.2.26 > parameters 0500 > } > signedAttrs - NULL - > signatureAlgorithm (AlgorithmIdentifier) ::= SEQUENCE { > algorithm (Oid (RSA)) 1.2.840.113549.1.1.1 > parameters 0500 > } > signatureValue (SignatureValue (OctetString)) > 5cdbbcb88b7ef6d368ae037077e980dd739eae58f9801ed85d552a6c96d0d0817c4d86c13c1fdb7da9219c9b11cada2e3969e738b61cae7f616faa1a5c32da755378267b1b9473d521e3d5012375154a8197114520f3939087a2a9161427c7658ae1211a18453b24ef8faa30d55251318a6842d53ff1030dbbe469715dd91bfa > unsignedAttrs - NULL - > } > } > -- View this message in context: http://itext-general.2136553.n4.nabble.com/Digital-sigantures-generated-with-itext-are-not-valid-in-Foxit-tp4298723p4299169.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions iText(R) is a registered trademark of 1T3XT BVBA. Many questions posted to this list can (and will) be answered with a reference to the iText book: http://www.itextpdf.com/book/ Please check the keywords list before you ask for examples: http://itextpdf.com/themes/keywords.php
