JDK-8181841 : A TSA server returns timestamp with precision higher than milliseconds
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.
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.
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.
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.