Ok, then let me quote from a conversation we had on the adobe forum. You said:
"For example, for true PDF/A-1 compatibility you should not use SHA256 since it didn't exist in PDF 1.4 (on which PDF/A-1 is based) even though it would be a perfectly valid PDF file." SHA256 wasn't supported in PDF 1.4 nor was PKCS#7. So where's the difference for true PDF/A combatibility? Regards, ToM "Currently the only defined raw signature format is adbe.x509.rsa_sha1 [...]" [ch. 2.2 from the "Public-Key Digital Signature and Encryption Specification" referenced in the PDF 1.4 spec) 2011/2/8 Leonard Rosenthol <[email protected]>: > You were doing great, up until this one: > >>PDF/A is based on PDF 1.4. To that time the adbe.x509.rsa_sha1 subfilter was >>the only one defined - which is thus >>the only valid subfilter to use for signatures in PDF/A compliant documents. >> > > Actually, there is NOTHING in PDF/A that prohibits the use of newer signature > models on PDF/A files - and in fact every implementation that I know uses the > PKCS#7 signatures with it. The only thing is that there is, however, no > expectation that a "pure" PDF/A conforming reader know what to do with them. > > Leonard > > -----Original Message----- > From: TvT [mailto:[email protected]] > Sent: Tuesday, February 08, 2011 8:57 AM > To: Post all your questions about iText here > Subject: Re: [iText-questions] Digital signature with DSA key > > Hi folks, > > i agree and disagree with the things discussed here. > Before we "drop" something we should be very careful. Somebody quoted > the ISO spec: > "The format for encoding signature values should be adbe.pkcs7.detached." > > That is correct for new documents (PDF version >= 1.5) and if you are > starting in the open countryside so to speak - the (future) way to > create documents. Additionally the PAdES standard (ETSI TS 102778) > does indeed prohibit the use of PKCS#1 signatures. > > Now the 'however' part: > The quoted sentence says: " *should* " - meaning the use of all three > subfilters > - adbe.pkcs7.detached > - adbe.pkcs7.sha1 > - adbe.x509.rsa.sha1 > > is perfectly compliant according to ISO-32000. There is absolutely no > place in the spec forbidding to use the last two subfilters. > Additionally there are other important ISO specs to consider: ISO > 19005-1 also known as PDF/A for example. Many people use this format > to store PDF/A documents in their unalterable archive system. And my > guess is that many people also use iText to create PDF/A compliant PDF > documents. PDF/A is based on PDF 1.4. To that time the > adbe.x509.rsa_sha1 subfilter was the only one defined - which is thus > the only valid subfilter to use for signatures in PDF/A compliant > documents. If we drop the support of the subfilters iText will be, > slightly overexaggerated, unable to create valid PDF/A documents > anymore. > > So if future specs (ISO-32000 successor, ISO PDF/A-2, PDF/X-6? etc.) > forbid to use those subfilters then that functionality should not be > used for a document in that version (e.g. >= PDF1.8). If somebody > wants to create and 'older' file (PDF 1.0-1.7) it should still be > possible to use those subfilters. > > Regards, > ToM > > 2011/2/8 <[email protected]>: >> Yes Michael, >> >> I fully agree to drop adbe.pkcs7.sha1, too. >> >> You outlined the way to go ! >> >> reetings >> >> Andreas >> >> ----- original Nachricht -------- >> >> Betreff: Re: [iText-questions] Digital signature with DSA key >> Gesendet: Di, 08. Feb 2011 >> Von: mkl<[email protected]> >> >>> >>> Andreas, >>> >>> kuehne wrote: >>> > I hope you support last nights call to drop PKCS1 support from iText! >>> >>> Yes, indeed, at least as far as signature creation is concerned. Actually I >>> would go even further and restrict the signature creation routines to >>> adbe.pkcs7.detached, i.e. drop support for adbe.pkcs7.sha1, too. This goes >>> along with the ISO spec which just before Table 257 states "The format for >>> encoding signature values should be adbe.pkcs7.detached. This encoding >>> allows the most options in terms of algorithm use." >>> >>> The only argument for keeping adbe.pkcs7.sha1 alive for signature creation >>> is that PAdES Part 2 for some weird reason explicitly includes it in the >>> allowed subfilters without properly stating a preference for >>> adbe.pkcs7.detached. >>> >>> Bruno, >>> >>> 1T3XT BVBA wrote: >>> > As digital signatures are somewhat outside my area of expertise, I didn't >>> > follow this discussion from the start, but obviously I'm interested in >>> > improving iText and the book. Would it be possible to summarize the >>> > problem: >>> > - which examples in the book should be removed (or how can they be >>> > changed)? >>> > - what exactly would need to be removed from iText? >>> > - can you give me suggestions for refactoring the signing process? >>> >>> The examples in the books should be changed to not create >>> adbe.x509.rsa.sha1 >>> or adbe.pkcs7.sha1 signatures anymore, only adbe.pkcs7.detached and >>> ETSI.CAdES.detached (yeah!) signatures and ETSI.RFC 3161 time stamps. >>> >>> As I'm only creating signatures with externally built CMS containers, I'm >>> not too sure about the code changes. If I understood Paulo correctly, >>> though, the whole iText signature creation API was due for a major change. >>> >>> IMO the new API should be PAdES-centric. This would include the good old >>> adbe.pkcs7.* signatures in Part 2, ETSI.CAdES.detached in Part 3 and >>> ETSI.RFC 3161 in Part 4. >>> >>> Regards, Michael. >>> -- >>> View this message in context: >>> http://itext-general.2136553.n4.nabble.com/Digital-signature-with-DSA-key-tp >>> 3264088p3275555.html >>> Sent from the iText - General mailing list archive at Nabble.com. >>> >>> ---------------------------------------------------------------------------- >>> -- >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> iText-questions mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/itext-questions >>> >>> 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 >>> >> >> --- original Nachricht Ende ---- >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> iText-questions mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/itext-questions >> >> 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 >> > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > iText-questions mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/itext-questions > > 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 > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > iText-questions mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/itext-questions > > 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 > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions 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
