Petras, Stephan, Petras wrote > Indeed, signed attribute " / > signing-certificate / > " is incorrectly constructed. Despite that, the integrity of signature is > correct and validation should pass.
That's well worth considering. Yes, the mathematical integrity of the signature is there, ok, but the very signed attribute which securely indicates the signing certificate is broken! (RFC 2634 which specifies that attribute: /The signing certificate attribute is designed to prevent the simple substitution and re-issue attacks, and to allow for a restricted set of authorization certificates to be used in verifying a signature./) Software designed to not only check the signature mathematically but to also evaluate a level of trust towards the contained identities, therefore, may or even should indicate some doubt concerning the authenticity of the signature. Petras wrote > Besides, this attribute is specified in CAdES, The attribute initially has been specified much earlier; e.g. look at RFC 2634 from June 1999. While initially specified for the S/MIME context, it soon was used in a more general context, e.g. look at ISIS-MTT where it is a required attribute. Petras wrote > while PDF signature dictionary /SubFilter has > <code> > adbe.pkcs7.detached > </code> > value, thus conformance to CAdES is not declared and required. Therefore > validation of this attribute should not be considered when validating the > signature. In countries in which ISIS-MTT or similar profiles for existing standards had been introduced, a complete verification of a PDF signature included a check for and of the SigningCertificate attribute long before the ETSI AdES specification processes were underway. Obviously those were integrated PDF signatures with the subfilter <code>adbe.pkcs7.detached</code>. But all this is not the point here as Stephan already found out that that attribute is not the issue here. Stephan Wagner (calac) wrote >The call that fails is when the digest is verified in the verify() >method of PdfPKCS7 class: > >boolean sigVerify = sig.verify(digest); Here the verification code of the security providers is called to check the digest, so it's not an explicit check of the discussed attribute which fails here. Regards, Michael BTW, iText indeed checks the SigningCertificate value only for /ETSI.CAdES.detached signatures. -- View this message in context: http://itext-general.2136553.n4.nabble.com/Signed-PDF-fails-to-verify-in-iText-Java-but-succeeds-in-iTextSharp-and-Acrobat-Reader-tp4658692p4658706.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ iText-questions mailing list iText-questions@lists.sourceforge.net 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
