Re: TSA in iText 2.1.6

> -----Original Message-----
> From: Bert Vingerhoets [mailto:Bert_Vingerhoets@...]
> Sent: Thursday, July 02, 2009 12:01 PM
> To: itext-questions@...
> Subject: [iText-questions] TSA in iText 2.1.6
>
> Hi,
>
> I was checking out the new functionality of iText 2.1.6,
> especially the added TSA support.
>
> In absence of documentation or examples, I took a look at the
> code to determine how to use the timestamping functionality.
> However, all I could find about the subject were the
> interface TSAClient and class TSAClientBouncyCastle. Neither
> of which are instantiated anywhere, the only references of
> TSAClient I could find were in one PdfPKCS7#getEncodedPKCS7
> method that isn't used by the rest of iText (except for
> filling the TSAClient argument with null).
>
> When following the examples for PDF signing using external
> signatures, one of the getEncodedPKCS7() methods does get
> called outside of iText (for setting the CONTENTS key in the
> dictionary passed to the final PdfSignatureAppearance#close()
> invocation). However, When I replace this getEncodedPKCS7()
> call by the overload that accepts a TSAClient, the resulting
> array is too large to fit in the allocated buffer.
> Checking where this buffer gets allocated leads to an
> internal invocation of getEncodedPKCS7() (without TSAClient argument).
>
> As far as I can see, being able to use TSA in iText requires
> me to patch the library (luckily we're using the MPL license)
> or try to externalize the entire contents of the 'if
> (cryptoDictionary == null)'-branch from
> PdfSignatureAppearance#preClose() where the CONTENTS buffer
> is allocated with the first call (through
> sigStandard.setSignInfo) to getEncodedPKCS7.
> Patching iText to allow specifying a TSAClient externally
> seems the easiest option to me.
>
> Is this correct? Or is there another way to use TSA in iText?
>
>
> On a brighter note, once I hacked the library to effectively
> use a TSAClient, a correct PDF was indeed produced and
> recognized by Acrobat Reader; so the code does, in fact, work.
>
>
> Regards,
>
> Bert Vingerhoets - Research & Development
> Inventive Designers NV
>
> Phone: +32 3 821 01 70
> Fax: +32 3 821 01 71
> Email: Bert_Vingerhoets at inventivegroup dot com
> http://www.inventivegroup.com/
>
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer