A Security Weakness When Signing without a Timestamp

Question

Hi Guys,
I am exploring the need of timestamping PDF documents using Adobe Acrobat wrt security. I see a lot of signatures made without timestamps and I see an issue here mentioned below. If my assumption is valid then Ideally Adobe Acrobat should strongly mandate to use timestamps with revocation information.
The scenario:
A user uses a high trust credential to legitimately sign PDF documents but chooses not to use a Timestamp to avoid costs.  These documents have an embedded signature plus the signer’s certificate chain CRLs and/or OCSP responses (but no trusted timestamp).
At a point in time (let’s say 1 June 2012) the credential and PIN is stolen.   If the theft is before the end of validity period the credential is of course revoked. However if the theft is of an expired credential it can’t be revoked and most people would not notice and perhaps would not even care.  Let us further assume the thief gains access to a number of old signed documents.  Of course in theory this is not a problem, because these documents are signed and therefore protected and can’t be changed. However the thief now has access to a range of valid CRLs and/or OCSP responses that were properly valid from before the theft and can use them to their advantage.  These documents may even be widely published or perhaps received anyway by an insider thief.
The thief can use the stolen credential and can sign a document at any date/time of their choosing up to 1 June 2012 (by varying their local system date/time) to one that lies within the validity period of any previous OCSP/ CRL data they have captured. Even though the signature covers the validation data this is all done at what seems like a legitimate time. 
Trust Threat Analysis:
A stolen credential and PIN can easily be used at a local desktop time (set to anything you like).  With PDF editing software – no problem for a hacker of course – you can embed a CRL that shows the stolen credential as good during any period up to the revocation or expiry.  The hacker just needs to select a signing date/time that is within a CRL validity period for one of the CRLs they have access to.  The selected CRL is then re-used as part of the signing process on a fraudulent document.
It is now up to the receiving software to make the right trust decision – and a trusted timestamp should always be used to make a trustworthy historic decision.  If there is no embedded trusted timestamp the receiver software could decide to verify the signature at (a) the current time or (b) the (untrusted) time indicated by the signer.  Any software that uses option (b) and trusts the (untrusted) time in the signature rather than defaulting to current time creates a substantial trust issue.  The whole purpose of using and attaching a valid, trusted signature time stamp is to independently confirm the accurate date/time of (potentially untrusted) third party signing events.  The timestamp cannot be re-used since it covers the signature details.  Any substantial variance in time between the signer’s time and the timestamp time is peculiar but systems should always default to trusting the signature timestamp date/time.
Ideally PDF signing software used by a signer that fails to obtain a timestamp should not allow the document to be signed.  If the policy is to sign with a long-term signature then the timestamp must be present to confirm the time.  Some software products create confusion by allowing the timestamp to be missed if it cannot be obtained.  This means that a document that should have a life of several months or years should actually be seen to have an issue immediately after certificate revocation or expiry (could be in a few days or months).  Using such software, users will not be aware of the issue until the problem has manifested itself.
Any Comments?
Regards,
Wahaj

Answer 1

The settings for the warning messages have been removed from the user interface (Bug 513166).
You need to change the related security.warn_* prefs directly on the <b>about:config</b> page.<br />
Filter: security.warn
To open the <i>about:config</i> page, type <b>about:config</b> in the location (address) bar and press the "<i>Enter</i>" key, just like you type the url of a website to open a website.<br />
If you see a warning then you can confirm that you want to access that page.<br />
*Use the Filter bar at to top of the about:config page to locate a preference more easily.
*Preferences that have been modified show as bold(user set).
*Preferences can be reset to the default or changed via the right-click context menu.