Eric, Eric Chow wrote > The sample1.pdf is signed by the certificate that generated by keytool and > the sample2.pdf is signed with the smartcard (PKCS#11). > > sample1.pdf (58K) > http://itext-general.2136553.n4.nabble.com/attachment/4659598/0/sample1.pdf > sample2.pdf (48K) > http://itext-general.2136553.n4.nabble.com/attachment/4659598/1/sample2.pdf
Ok, the main reason why sample1.pdf > shows LTV-enabled in Adobe reader is that it is signed using a self-issued/self-signed certificate while real world user certificates usually are issued by other certificates which in turn are issued by still other other ones, which in turn etc. pp. ... Eventually this chain ends in a certificate like yours which is issued by itself. A certificate is signed using its issuer certificate; thus, a self-issued certificate is also known as self-signed certificate. A small 101 on certificates first... Whenever you are checking whether you put some trust in a signature (beyond the mathematical check whether the hash of the document matches with the signature), you try and build that chain as far as possible (verifying whether each certificate actually has been signed by its alleged issuer and checking numerous other attributes, e.g. validity interval and allowed usage purposes) and check whether you have any of these certificates in your local store of trusted certificates; usually the certificates in your trusted certificate store are self-issued certificates. If find no match, you don't trust the signature. Otherwise you obviously trust the certificate you identified (otherwise it would not be in your trusted store, would it?), but the certificates leading to it from your signer certificate inclusively have to be checked some more because they may meanwhile have been revoked (due to stolen keys or misuse). Thus, you query the respective public key infrastructure of the issuing certificate whether the certificate in question is revoked or not using OCSP or CRL queries. To guarantee that the respective responses are no fakes coming from some man-in-the-middle fooling you (after all you do those queries via some anonymous internet route probably infested by bad guys), these responses themselves also are signed. Thus, you have to verify these signatures, too. Etc. Etc. Etc. Fortunately the responses from the PKI of the issuing certificate usually are signed by a very few certificates which makes this process eventually end because of your unlimited trust in the certificates in your trusted store. If at a later time (maybe a much later time) there is a need to re-check the validity of your signature, those PKIs might be offline and the procedure mentioned above may not be repeatable. For such a case, though, it would suffice to have all those information available you collected earlier in your original attempt to verify the signature. Thus, there is a need to store all these validation related information alongside your signature. This is what the CAdES/XAdES/PAdES standards (and others, too) are all about. When Adobe Reader says some signature is LTV-enabled, it essentially has checked whether it finds all the information required for such a later check in the PDF document given the trust in the certificates in the trusted store. (Actually the situation can be somewhat more complicated due to cross-signed certificates, alternative certificate chains, TSLs, time stamps, differing validation modells... On the other hand the actual checks can be somewhat simplified for PKIs often verified against.) In your case sample1.pdf is signed by a self-issued certificate which you most likely have added to your trusted certificates (otherwise Adobe Reader would warn you about this missing trust). As the signer certificate already is a trusted certificate, there is no need for any other validation related information. Thus the document is LTV-enabled. sample2.pdf on the other hand is signed by a user certificate which is issued by some other certificate. Neither the other certificate nor any revocation information for any certificate are available. Thus: not LTV-enabled. By the way, by adding that user certificate itself to the trusted certificates makes Adobe display it as LTV-enabled... ;) (BTW, the signature in sample2.pdf uses the adbe.pkcs7.sha1 subfilter; for interoperable signatures the current PDF standard has been recommending against using it since the last decade.) I hope this helps to understand which information have to be added to a PDF to make it LTV-enabled. Regards, Michael -- View this message in context: http://itext-general.2136553.n4.nabble.com/LTV-problem-tp4659550p4659604.html Sent from the iText - General mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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
