Attach PKCS7 Signature data externally [duplicate] - itext

Question

How can this be done in iText? I have a PDF with a signature from a client. I need to add an ocsp response to unsigned attributes.
I know how to change the signature itself using
org.bouncycastle.cms.CMSSignedData.replaceSigners(...).getEncoded()
but I don't know how to replace PdfName.CONTENTS in the PDF using new PdfString(newSignature).setHexWriting(true). If I use this code:
PdfDictionary other = new PdfDictionary();
other.put(PdfName.CONTENTS, new PdfString(newSignature).setHexWriting(true));
dicSignature.merge(other);
where dicSignature is the dictionary which contains the signature, then the signature (when the document is opened in Adobe Reader) is broken.

Answer 1

When iText manipulates a document using aPdfStamperin normal mode, it can (and often does) re-arrange the existing PDF objects. This obviously breaks the hash value of any existing integrated signature. Furthermore the byte ranges which would have to be signed, change. This most likely is your problem.
When iText manipulates a document using aPdfStamperin append mode, it leaves the PDF as is and only appends its additions and changes. While this in general is the way to go to keep integrated signatures from breaking, you cannot change the content of a signature this way because there are stricter rules concerning embedding signatures than for PDFs in general. Switching to append mode, therefore, would not fix your problem.
Thus, iText has an explicit method doing a signature insertion without otherwise changing the PDF:
MakeSignature.signDeferred(PdfReader reader,
String fieldName,
OutputStream outs,
ExternalSignatureContainer externalSignatureContainer)
throws DocumentException, IOException, GeneralSecurityException
Its name is due to the fact that this method originally is intended for the use case of deferred signing, i.e. first preparing the PDF for signing (i.e. adding all dictionaries and other necessary structures required to hash the byte ranges, including leaving a gap into which a signature container eventually shall be injected), calculating the hash value, and sending it to some other service while storing the prepared PDF locally. As soon as that other service returns the signature, the prepared PDF is located and the retrieved signature is inserted into it using this method.
The only difference to your use case is that there already is a signature in the gap. That signature, though, will be overwritten by your updated one when using signDeferred.
Having said all this, you may be in for a surprise if you expect that after you add an ocsp response to unsigned attributes, Adobe Reader uses these information for verification. In the context of integrated PDF signatures according to ISO-32000-1, section 12.8.3.3 PKCS#7 Signatures as used in ISO 32000,
the PKCS#7 object should contain [...] Revocation information as an signed attribute (PDF 1.6): This attribute may include all the revocation information that is necessary to carry out revocation checks for the signer's certificate and its issuer certificates. Since revocation information is a signed attribute, it must be obtained before the computation of the digital signature. This means that the software used by the signer must be able to construct the certification path and the associated revocation information. If one of the elements cannot be obtained (e.g. no connection is possible), a signature with this attribute will not be possible.