JDK-8181841 : A TSA server returns timestamp with precision higher than milliseconds
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7,8,10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-06-09
  • Updated: 2023-12-06
  • Resolved: 2017-06-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 7 JDK 8 Other
10 b12Fixed 7u271Fixed 8u261Fixed openjdk7uFixed
Related Reports
Duplicate :  
Description
In a test, http://zd.e-guven.com/TSS/HttpTspServer sends back a time of 20170609022450.4436Z. Java's DerInputBuffer.getTime() accepts at most milliseconds but this one goes to 1/10000 of a second (.4436).

Jarsigner failed and jar not signed.
Comments
Fix request (8u) I'd like to request an 8u backport of this fix because 8u is affected by this bug and to maintain parity between JDKs. The patch applies cleanly modulo paths. The risk should be low because: 1) only DER time parsing is affected, 2) there is good testing coverage in sun/security/util/DerInputBuffer/TimeParsing.java (which passes in JDK-8 after the backport), and 3) there is nothing who looks JDK-10 release specific.
20-04-2020

URL: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/8be1b92492d2 User: weijun Date: 2017-06-14 04:34:17 +0000
14-06-2017

An easy fix is just treat all precisions (number of digits after .) greater than or equal to 3 the same, and only read the first 3 digits as millisecond. In fact, Java's DER parsing returns Date and millisecond is the smallest time unit it can deal with. But this means we are silently dropping data from the input and it might have negative impacts, e.g. comparing 2 timestamps. Maybe we should introduce a series of new methods that returns an Instant object so we can have nanoseconds. This time we should clearly specify that any digits after nanoseconds will be ignored.
09-06-2017