Hello,
I'm using this post to publish the files related to a thread started across internal mailing lists.
I'm available for a Connect session to show the workflow I'm covering in my messages. "jboss_install_config_sec_7_2_2.pdf" is the original one that was provided to Digital Signatures, and "jboss_install_config_sec_7_2_2signed.pdf" is the output from LiveCycle that does not validate when opening it in Acrobat.
Here's the thread so far, including my latest message via email:
Hi,
I’ve found a good way to share the files, they’re both at http://forums.adobe.com/message/2537737 in a post where all this thread is pasted.
I’m available for a Connect to show this simple workflow:
1) I copy a file, never opened in Acrobat before, to a watched folder associated to a LC process
2) The file goes through the process that adds a signature field and signs the document with LC DigSig
3) The output from 2) is opened in Acrobat, and the first feedback I get is that the signature is not valid.
A few additional notes:
a) Neither files are truncated
b) Both files cause at least three COS viewing utilities to crash
c) LiveCycle Digital Signatures raises no exceptions when generating the file
d) Acrobat reports an error regarding byte ranges as the cause for the non valid signature, but if you look at the output from LC with a hex editor you can clearly see that the byte range is correct
e) Acrobat is never used to save either file
f) With both files, Acrobat repairs the file while opening it
I have now added another test to better explain my point. I have used a simple process to validate the signature with LiveCycle, and it validates correctly. This is what I expected anyway since I’ve already noticed that the byte ranges were correct, and that without any change occurring to those bytes the signature would be valid. So:
g) The signed file reported as invalid by Acrobat, validates successfully with LiveCycle Digital Signatures
With Connect it would take 5 minutes to show everything, please let me know if anyone’s interested or if this message clarifies the context well enough.
Thanks and best regards,
Giovanni
-----
Giovanni Sarbia
Senior Systems Engineer
Enterprise and Developer Solutions
Adobe Systems Italia S.r.l.
Tel.: +39 039655036 (VOIP: 85036)
Mobile: +39 3480854502
From: Philip Levy
Sent: venerdì 22 gennaio 2010 20.24
To: Marc Kaufman; Giovanni Sarbia
Cc: John B Harris; Acrobat-security@adobe.com; Ankit Bal; epaper-techies@adobe.com
Subject: RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
I think the only possible options here are:
1) Acrobat reports a corruption in the file but there isn't really any problem. This would be a bug in Acrobat
2) Acrobat should refuse to open corrupted files. Is this what you are requesting?
3) Acrobat opens the file, repairs it, reports the signature invalid. Is the problem that the reason for the signature being invalid is not clearly stated? So the bug is to improve the error message.
I don't think there are other viable options in this situation.
thanks
phil
From: owner-acrobat-security-engineering@adobe.com [mailto:owner-acrobat-security-engineering@adobe.com] On Behalf Of Marc Kaufman
Sent: Friday, January 22, 2010 11:18 AM
To: Giovanni Sarbia
Cc: John B Harris; Acrobat-security@adobe.com; Ankit Bal; epaper-techies@adobe.com
Subject: acrobat-security-engineering RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
I’d have to look at the file, but since the file needed repair, and Acrobat never saves a broken file, something happened during the trip the file made to your machine. Typical problems include rewriting the end-of-line (CR, LF, CRLF) or adding/deleting some bytes at the front of the file. That’s the only way the objects will get out of sync with the XREF table. Any of that will break the byte hash.
Marc
From: Giovanni Sarbia
Sent: Friday, January 22, 2010 11:10 AM
To: Marc Kaufman
Cc: John B Harris; Acrobat-security@adobe.com; Ankit Bal; epaper-techies@adobe.com
Subject: RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
Marc,
Thanks for your reply.
The point is that Acrobat fails to validate the signature *before* any save has occurred yet. The sequence is just open->validate. Then, when I’m closing the file, Acrobat asks me to save the file. Until then, though, I had no other clue that the document was modified after opening it (except for the instant when the little “repair” window appears, but often it’s too fast to be noticeable).
I haven’t even tried to save that file yet after validation. I’m opening a signed PDF that LiveCycle signed with no complaints, and when I open it in Acrobat it fails to validate. That’s it, really, but it doesn’t seem entirely OK to me.
Thanks again and best regards,
Giovanni
-----
Giovanni Sarbia
Senior Systems Engineer
Enterprise and Developer Solutions
Adobe Systems Italia S.r.l.
Tel.: +39 039655036 (VOIP: 85036)
Mobile: +39 3480854502
From: Marc Kaufman
Sent: venerdì 22 gennaio 2010 20.01
To: Giovanni Sarbia; Ankit Bal; epaper-techies@adobe.com
Cc: John B Harris; Acrobat-security@adobe.com
Subject: RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
The “repair” occurs while the file is being read, and only affects the COS store. HOWEVER, if the file was repaired a FULL SAVE is forced the next time the file is saved. This will break any signatures. Don’t write broken files.
Marc
From: owner-acrobat-security-engineering@adobe.com [mailto:owner-acrobat-security-engineering@adobe.com] On Behalf Of Giovanni Sarbia
Sent: Friday, January 22, 2010 10:10 AM
To: Ankit Bal; epaper-techies@adobe.com
Cc: John B Harris; Acrobat-security@adobe.com
Subject: acrobat-security-engineering RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
Hi Ankit,
Thanks a lot for your reply.
I haven’t yet shared the files because they’re not small (the original one, interestingly, is the “Installing and Configuring LiveCycle Security Products” for LiveCycle 7.2) and Acrobat.com encounters an error probably due to the syntax error in the PDF (apparently it’s just a hex string, but I’ve tried three low-level Cos viewers and they all crash so I haven’t pinpointed the root cause yet).
Please let me know if you or anyone else wants to get the files so I’ll send them over as attachments or I’ll copy them to some network folder.
However, my case is not a case where Acrobat does any signing. The signing is done only by LC. Acrobat opens the correctly signed file, changes its bytes to repair it, and then when validating the PDF it throws an error due to a bad byte range. The byte range was actually good in relation to the file produced by LC DigSig, but it is obviously misaligned with the new binary layout of the file.
I would expect either that:
a) LiveCycle does not generate such a file
b) Acrobat validates correctly the file and then, should any change occur, it would occur respecting the original signed PDF (maybe with some warning to the user).
I suppose b) would be easier to reach than a), and also if b) was solved it would make it easier to introduce LiveCycle Digital Signatures in contexts where the PDF are already generated elsewhere (these are always risky cases but I’m seeing these cases more and more often). Please note, though, that in this case the problem seems to be related to a PDF produced with our technology (application: “FrameMaker 7.2”; producer: “Acrobat Distiller 7.0.5”). It is unlikely that the error has been introduced later via file copy operations because it’s not a case where the “.pdf” file ends before the PDF’s “EOF”. The error is in the Cos structure of the PDF, and according to an error message produced by one of the tools I’ve tried, it’s probably a malformed hex string.
In the worst case, I believe that Acrobat should at least not complain about the byte range but refer to the quality of the original PDF as the cause for the validation to fail.
Thanks again and best regards,
Giovanni
-----
Giovanni Sarbia
Senior Systems Engineer
Enterprise and Developer Solutions
Adobe Systems Italia S.r.l.
Tel.: +39 039655036 (VOIP: 85036)
Mobile: +39 3480854502
From: Ankit Bal
Sent: venerdì 22 gennaio 2010 18.37
To: Giovanni Sarbia; epaper-techies@adobe.com
Cc: John B Harris; Acrobat-security@adobe.com
Subject: RE: Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
In my understanding, LC does an incremental save during application of digital signatures. This is not desired but is done for performance reasons. IMO, in case of Acrobat, signing results in a full save. This difference in save styles during signing should, ideally, be acceptable and should cause no pain during interoperability. However, in this case, it results in Acrobat signing the repaired file, while LC doesn’t repair it (assuming LC can repair it) during signing.
I can only assume this to be the cause of the issue. However, the Acrobat folks can explain better whether it would lead to the error you specified below.
-Ankit
From: owner-acrobat-security-engineering@adobe.com [mailto:owner-acrobat-security-engineering@adobe.com] On Behalf Of Giovanni Sarbia
Sent: Friday, January 22, 2010 8:51 PM
To: epaper-techies@adobe.com
Cc: John B Harris; Acrobat-security@adobe.com
Subject: acrobat-security-engineering Question about LiveCycle Digital Signatures and the automatic repair feature in Acrobat
Hello,
While doing some tests with LiveCycle Digital Signatures, I’ve bumped into one of those files that triggers Acrobat’s “repair” feature which allows you to read PDF documents with slight defects.
Interestingly, since the PDF error is obviously not that big to cause Gibson to “choke” and since Digital Signatures has no notion of “autorepair”, the file goes through a LiveCycle signing process and generates the signed output without any hint of an error. When Acrobat opens the signed file, you can see for a second that it’s trying to repair the file and when validating the signature it states that the signature is not valid because of an error in the byte range. Actually, if you look at the signed file using a hex editor, you can easily see that the byte range is perfect. My guess is that Acrobat repairs the document before seeing that it’s signed, and so changes parts of the file that have been already signed, causing a misalignment between the byte range and the “new” bytes of the repaired file.
I would like to open a bug about this behaviour, but I’d like to have some feedback about this issue first.
IMHO, in a case like this Acrobat should at most change the file in a way that’s compliant with existing digital signatures, i.e. appending the changes to the existing bytes. Maybe, in such a case, it could even ask the end user first so that it doesn’t necessarily cause a “signature valid, document changed later” case.
I know this might be a fringe case, but either LiveCycle should not generate a “doomed-to-be-invalid” signed PDF or Acrobat should not invalidate the signature once it’s been placed on the document by another piece of our technology.
Another option would be to have some sort of “repair” feature in LiveCycle, but I feel it would be more “expensive” than fixing Acrobat.
Basically, I’m not sure if this should be a bug related to Acrobat, to LiveCycle, to both or to none of them.
Thanks in advance for your feedback and best regards,
Giovanni
-----
Giovanni Sarbia
Senior Systems Engineer
Enterprise and Developer Solutions
Adobe Systems Italia S.r.l.
Tel.: +39 039655036 (VOIP: 85036)
Mobile: +39 3480854502
