When using the jarsigner utility and the TSA response contains a status string,
the tool fails the following stacktrace:

jarsigner: unable to sign jar: java.io.IOException: DER input not a UTF-8
string
java.io.IOException: DER input not a UTF-8 string
    at sun.security.util.DerInputStream.readString(DerInputStream.java:480)
    at sun.security.util.DerInputStream.getUTF8String(DerInputStream.java:424)
    at sun.security.timestamp.TSResponse.parse(TSResponse.java:344)
    at sun.security.timestamp.TSResponse.<init>(TSResponse.java:205)
    at
sun.security.timestamp.HttpTimestamper.generateTimestamp(HttpTimestamper.java:154)
    at
sun.security.tools.TimestampedSigner.generateTimestampToken(TimestampedSigner.java:334)
    at
sun.security.tools.TimestampedSigner.generateSignedData(TimestampedSigner.java:222)
    at sun.security.tools.SignatureFile$Block.<init>(JarSigner.java:2064)
    at sun.security.tools.SignatureFile.generateBlock(JarSigner.java:1961)
    at sun.security.tools.JarSigner.signJar(JarSigner.java:1063)
    at sun.security.tools.JarSigner.run(JarSigner.java:221)
    at sun.security.tools.JarSigner.main(JarSigner.java:91)

Investigating this a bit leads me to believe there is a bug in
sun.security.timestamp.TSResponse.

Since this is an internal class and I wanted to make a simple test case using a
hardcoded TSA response, I took the code from this class and made a local
stand-along test project to examine the bug.

If I change the line 322 in TSResponse.java to read:

statusString[i] = strings[i].getUTF8String();

the exception is gone.
I'm not fully confident with the code, but I believe taking .data on strings[i]
gets the raw DER data, which is not a tagged UTF8 string.

This seems to happen also with OpenJDK 7.

The bug was reported against 6-open at https://bugs.openjdk.java.net/show_bug.cgi?id=100304. It's already fixed in jdk8 as part of 7102686.