0
votes

I'm using iText 2.1.7 and BC 1.49 Even though I can signing and timestamping a file, when I open it with adobe reader I get a "timestamp authority not available" status (signature it's ok and reader tell me that the file is timestamped). Here is my code after when timestamping:

...
byte[] tstoken = timeStampClient.getTimeStampToken(tsdata);
Attribute signatureTimeStamp = new Attribute(PKCSObjectIdentifiers.id_aa_signatureTimeStampToken, new DERSet(ASN1Primitive.fromByteArray(tstoken)));
SignerInformationStore signerStore = cmsSignedData.getSignerInfos();
ArrayList<SignerInformation> siArray = new ArrayList<SignerInformation>();
Iterator<SignerInformation> infos = signerStore.getSigners().iterator();
while (infos.hasNext()) {
    SignerInformation si = infos.next();
    Hashtable<ASN1ObjectIdentifier, Attribute> unsignedAttrHash = si.getUnsignedAttributes().toHashtable();
    unsignedAttrHash.put(PKCSObjectIdentifiers.id_aa_signatureTimeStampToken, signatureTimeStamp);
    siArray.add(SignerInformation.replaceUnsignedAttributes(si, new AttributeTable(unsignedAttrHash)));
}
SignerInformationStore newSignerStore = new SignerInformationStore(siArray);
return CMSSignedData.replaceSigners(cmsSignedData, newSignerStore);
...

The returned CmsSignedData (.getEncoded()) is what I embbed into pdf. I already test the TSA server and signer certificate using Acrobat and those are ok.

Thank you in advance.

-- Added -- Examples:

My signed pdf

Acro signed pdf (same cert, same tsa server)

1
Please provide a sample PDF signed and time stamped using your code; BTW, iText 2.1.7 and BC 1.49 looks like a funny combination, given that that old iText version in its own code relies on BC versions from before the big BC API break 1.46/1.47. Ah, there is one issue visible in your code; I'll create an answer...mkl
My assumption that I had spotted an issue visible in your code proved wrong after I looked at the specification.mkl
mkl, I forgot to mention tha I made some changes in iText source code to make it compatible with BC 1.49. AFAIK that changes are not responsible of my problem, with that same code I succesfully sign several documents in differents formats (xml, doc, etc.)Gabriel
I've started to look into your samples at office but i didn't have enough time. It was weird, though. .. having extracted the cms containers, dumpasn1 ran into a runtime error when trying to open your container and also showed multiple errors for the one generated By Adobe. Furthermore Adobe's signature was gigantic!mkl
Ok, with a newer guidumpasn version I can properly parse both CMS comtainers. At first glance they look ok. The main difference being that Adobe embeds a huge CRL and so makes the PDF size explode. A major difference remaining is that you are creating an ETSI.CAdES.detached signature while Adobe creates an old-fashioned adbe.pkcs7.detached. Have you tried first going for a adbe.pkcs7.detached signature, too? The Reader may have different validations for these different types. And: You do include a signing-time attribute which is forbidden for ETSI.CAdES.detached. Try without.mkl

1 Answers

0
votes

I found the problem. Instead of timestamping the hash of CMSAttributeTableGenerator.SIGNATURE (it is known while signing with BC using CMSAttributeTableGenerator), I was timestamping the hash of the resolved signature (CMSSignedData.getEncoded()). Maybe, my next goal would be to get the correct data outside of CMSAttributeTableGenerator, I tested saving that and timestamping after signing, and putting the timestamp into the SignerInformationStore (using the source code that I wrote above) and the Reader's validation gets correct. I hope you understand what I meant to say (this is not my native language). Thank you all.