Add external PdfPKCS7 to pdf
Locked
 
|
Hi,
I'd like to know if it's possible to add an external PdfPKCS7 to a PDF. The reason for this is that we currently have a webService which receives the pdf hash and returns the signature in a byte[]. I am able to instantiate a PdfPKCS7 with the received bytes and would like to add the received (PdfPKCS7) signature to the PDF file. Thanks! |
Re: Add external PdfPKCS7 to pdf
|
First this: you're probably registered on Nabble, but you're not
registered on the iText mailing list. See http://lowagie.com/nabble If you want to avoid that your mails remain unanswered, please register on the iText mailing list. Second remark: about an hour ago, a news letter was sent out. This news letter contained a link to the first 30 pages of a white paper on digital signing. The part you need hasn't been written yet, but you may want to subscribe to the newsletter to get the updates: http://itextpdf.com/newsletter Op 27/06/2012 9:11, rauland schreef: > Hi, > I'd like to know if it's possible to add an external PdfPKCS7 to a PDF. Yes and no. It depends. > The reason for this is that we currently have a webService which receives > the pdf hash and returns the signature in a byte[]. I am able to > instantiate a PdfPKCS7 with the received bytes and would like to add the > received (PdfPKCS7) signature to the PDF file. Since iText 5.3.0, you can create your own ExternalSignature implementation, and pass that as a parameter to the signDetached() method in the MakeSignature class. In the tutorial, there will be an example where iText takes care of the PDF part, but the actual signature is made on a smart card (the example already exists, and it works, but it's not documented yet). You could create a similar implementation where you create an implementation of the ExternalSignature interface and have the sign() method call your web service. This is the "Yes" when I say it depends. The "No" means: you want to prepare the file with iText, store it somewhere with 0x00 bytes for the signature, and then afterwards replace the 0x00 bytes with the actual signature. This is on our TODO list, but not yet supported. You need the original PdfStamper object to create the signature. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
|
In reply to this post by rauland
Read on here:
http://itextpdf.sourceforge.net/howtosign.html 2012/6/27 rauland <[hidden email]>: > Hi, > I'd like to know if it's possible to add an external PdfPKCS7 to a PDF. > > The reason for this is that we currently have a webService which receives > the pdf hash and returns the signature in a byte[]. I am able to > instantiate a PdfPKCS7 with the received bytes and would like to add the > received (PdfPKCS7) signature to the PDF file. > > Thanks! > > > -- > View this message in context: http://itext-general.2136553.n4.nabble.com/Add-external-PdfPKCS7-to-pdf-tp4655466.html > Sent from the iText - General mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > iText-questions mailing list > [hidden email] > 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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
Re: Add external PdfPKCS7 to pdf
|
|
Op 27/06/2012 9:42, TvT schreef:
Read on here: Please don't! Tobias, we've discussed reasons to stay with old iText versions in the past, but now the scale is tilting towards upgrading. The examples on the URL you provided are outdated and will be replaced by the white paper that was distributed with the news letter. Let me copy/paste two extracts: From page 19: In versions
predating iText 5.3.0, you’d sign a
PDF document choosing one of the following parameters for the setCrypto() method: ·
PdfSignatureAppearance.WINCER_SIGNED: this created a signature with
the sub filter /adbe.pkcs7.sha1. ·
PdfSignatureAppearance.SELF_SIGNED: this created a signature with
the sub filter /adbe.x509.rsa_sha1. These options have
been removed in 5.3.0 for
very specific reasons. Although /adbe.x509.rsa_sha1 will still be
available in PDF 2.0,
it’s not mentioned in PAdES. The ETSI standard only talks about
sub filters based
on CMS or CAdES signature formats. We’ve discontinued support
for the creation
of PKCS#1 signatures, so that iText-created signatures comply
with PAdES. As
for /adbe.pkcs7.sha1,
this sub filter will be deprecated in PDF 2.0. ISO-32000-2
recommends: “To
support backward compatibility, PDF readers should process this
value for the /SubFilter key but PDF writers shall not use
this value for that key.” Important notice
about SHA-1: The use of SHA-1 is being phased
out in some countries, hence the use of other hashing algorithms
is
recommended. The white paper is still under development. If you want to be kept up to date regarding its progress please register here: http://itextpdf.com/newsletter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
|
|
Hi Bruno,
> we've discussed reasons to stay with old iText versions in the past, > but now the scale is tilting towards upgrading. The examples on the URL you > provided are outdated and will be replaced by the white paper that was > distributed with the news letter. This time :-) the link wasn't about our upgrading discussion we had in the past... It was just the answer to the question 'How do i sign pdfs with external signatures' and that with a current (still consider 5.2.X version as up-to-date) > In versions predating iText 5.3.0, you’d sign a PDF document choosing one of > the following parameters for the setCrypto() method: > · PdfSignatureAppearance.WINCER_SIGNED: this created a signature with the sub filter /adbe.pkcs7.sha1. > · PdfSignatureAppearance.SELF_SIGNED: this created a signature with the sub filter /adbe.x509.rsa_sha1. In your listing one sub filter is missing. The (current and most up-to-date) pdf standard 32000-1 defines the following: x509.rsa_sha1 adbe.pkcs7.sha1 adbe.pkcs7.detached Despite the SHA1 in the name of x509.rsa_sha1 also newer hash methods can be used (cp. table 257 pdf spec). Then i agree with most of your conclusion: x509.rsa_sha1 - still ok to use according to ISO 32000-1 but not PAdES compatible adbe.pkcs7.sha1 - only SHA1 as hash method (e.g. the german Bundesnetzagentur states not to use SHA1 anymore) adbe.pkcs7.detached - most future proof If you look at the link it is quite possible to generate external signatures using the subfilter 'adbe.pkcs7.detached' - which i would guess most people use right now... But if I would upgrade to a new iText version I would of course use the PAdES standard. The iText PAdES support (when the ISO 32000-2 is released) would be a strong upgrade reason for me personally. However others who are not using the signing functionality at all may decide otherwise... Regards, ToM > These options have been removed in 5.3.0 for very specific reasons. But can you still use the adbe.pkcs7.detached version? > Although /adbe.x509.rsa_sha1 will still be available in PDF 2.0, it’s not > mentioned in PAdES. The ETSI standard only talks about sub filters based on > CMS or CAdES signature formats. We’ve discontinued support for the creation > of PKCS#1 signatures, so that iText-created signatures comply with PAdES. As > for /adbe.pkcs7.sha1, this sub filter will be deprecated in PDF 2.0. > ISO-32000-2 recommends: “To support backward compatibility, PDF readers > should process this value for the /SubFilter key but PDF writers shall not > use this value for that key.” > > From page 22: > > Important notice about SHA-1: The use of SHA-1 is being phased out in some > countries, hence the use of other hashing algorithms is recommended. > > If you insist on using obsolete versions of iText for signing, you are > deliberately choosing to create signatures that are not future-proof. If you > need digital signatures for PDF, you really need to upgrade to iText 5.3.0. > Staying with an old iText version is not an option! > > The white paper is still under development. If you want to be kept up to > date regarding its progress please register here: > http://itextpdf.com/newsletter ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
Re: Add external PdfPKCS7 to pdf
|
|
Op 27/06/2012 11:59, TvT schreef:
> The (current and most > up-to-date) pdf standard 32000-1 defines the following: > > x509.rsa_sha1 > adbe.pkcs7.sha1 > adbe.pkcs7.detached You're completely ignoring PAdES! ETSI.CAdES.detached and ETSI.RFC3161 are standard too (and more up to date than ISO-32000-1). They are supported in Adobe Reader, and the future PDF standard ISO 32000-2 will define the following: adbe.pkcs7.sha1 Supported message digests: SHA1 (since PDF 1.3) RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 and 4096 bits since PDF 1.7. DSA Algorithm: up to 4096 bits since PDF 1.6 Note that the use of this sub filter for signature creation will be deprecated in PDF 2.0 (ISO-32000-2). It’s no longer supported in iText since version 5.3.0. adbe.x509.rss_sha1 Supported message digests: SHA1 (since PDF 1.3), SHA256 (since PDF 1.6), SHA384, SHA512 and RIPEMD160 (since 1.7) RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 and 4096 bits since PDF 1.7. DSA Algorithm: not supported. Note that despite the reference to SHA1 in the name, other digest algorithms are supported. As this sub filter isn’t mentioned in the PAdES standard, we no longer support it in iText (since 5.3.0). adbe.pkcs7.detached, ETSI.CAdES.detached and ETSI.RFC3161 Supported message digests: SHA1 (since PDF 1.3), SHA256 (since PDF 1.6), SHA384, SHA512 and RIPEMD160 (since 1.7) RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 and 4096 bits since PDF 1.7. DSA Algorithm: up to 4096 bits since PDF 1.6 ECDSA: the Elliptic Curve Digital Signature Algorithm will be supported in PDF 2.0 Note that detached signatures are supported by default in iText since version 5.3.0. There’s support for all message digests, RSA and DSA, but not yet for ECDSA. If you knew that a certain specification would be deprecated in less than a year, would you still invest in it? If you know that there are more recent specifications (PAdES) that are more future-proof, why would you ignore them? Why would you write code of which you are sure you'll have to throw it away in half a year (which is the case if you use the "detached" example)? We're working on innovative stuff: see for instance http://lowagie.com/smartcardreaders One of the smart card readers in the picture is a prototype that isn't available in the stores yet, and the drivers that were tested are brandnew. What I meant to say was: don't spend your time on old technology, make sure your applications are future-proof. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
Re: Add external PdfPKCS7 to pdf
|
Just a quick note. Although version 5.3.0 only supports directly the
detached modes, CMS and CADES, and LTV, nothing prevents anyone of using any other signature methods, including the soon to be obsolete ones. We want everybody to use the best practices but external signatures are still present for custom needs, good or bad. Paulo On Wed, Jun 27, 2012 at 11:16 AM, iText Info <[hidden email]> wrote: > Op 27/06/2012 11:59, TvT schreef: >> The (current and most >> up-to-date) pdf standard 32000-1 defines the following: >> >> x509.rsa_sha1 >> adbe.pkcs7.sha1 >> adbe.pkcs7.detached > > You're completely ignoring PAdES! ETSI.CAdES.detached and ETSI.RFC3161 > are standard too (and more up to date than ISO-32000-1). They are > supported in Adobe Reader, and the future PDF standard ISO 32000-2 will > define the following: > > adbe.pkcs7.sha1 > > Supported message digests: SHA1 (since PDF 1.3) > RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 > and 4096 bits since PDF 1.7. > DSA Algorithm: up to 4096 bits since PDF 1.6 > > Note that the use of this sub filter for signature creation will be > deprecated in PDF 2.0 (ISO-32000-2). It’s no longer supported in iText > since version 5.3.0. > > adbe.x509.rss_sha1 > > Supported message digests: SHA1 (since PDF 1.3), SHA256 (since PDF 1.6), > SHA384, SHA512 and RIPEMD160 (since 1.7) > RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 > and 4096 bits since PDF 1.7. > DSA Algorithm: not supported. > > Note that despite the reference to SHA1 in the name, other digest > algorithms are supported. As this sub filter isn’t mentioned in the > PAdES standard, we no longer support it in iText (since 5.3.0). > > adbe.pkcs7.detached, ETSI.CAdES.detached and ETSI.RFC3161 > > Supported message digests: SHA1 (since PDF 1.3), SHA256 (since PDF 1.6), > SHA384, SHA512 and RIPEMD160 (since 1.7) > RSA Algorithm: up to 1024 bits since PDF 1.3, 2048 bits since PDF 1.5 > and 4096 bits since PDF 1.7. > DSA Algorithm: up to 4096 bits since PDF 1.6 > ECDSA: the Elliptic Curve Digital Signature Algorithm will be supported > in PDF 2.0 > > Note that detached signatures are supported by default in iText since > version 5.3.0. There’s support for all message digests, RSA and DSA, but > not yet for ECDSA. > > If you knew that a certain specification would be deprecated in less > than a year, would you still invest in it? > If you know that there are more recent specifications (PAdES) that are > more future-proof, why would you ignore them? > Why would you write code of which you are sure you'll have to throw it > away in half a year (which is the case if you use the "detached" example)? > > We're working on innovative stuff: see for instance > http://lowagie.com/smartcardreaders > One of the smart card readers in the picture is a prototype that isn't > available in the stores yet, and the drivers that were tested are brandnew. > > What I meant to say was: don't spend your time on old technology, make > sure your applications are future-proof. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > iText-questions mailing list > [hidden email] > 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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ iText-questions mailing list [hidden email] 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 |
«
Return to iText - General
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |