kaikramer
commented
2 years ago I understand your point, but in reality there is not much to gain when using TLS for a service that performs a signature. Either you trust the signature or you don't. Transportation of a signature is not relevant.
In fact barely any HTTPS TSAs exist at all. All of the currently five configured TSAs in KSE are only HTTP (and I could list ten more), which also indicates that HTTPS is not necessary for a timestamp service: http://timestamp.digicert.com http://rfc3161timestamp.globalsign.com/advanced http://time.certum.pl http://sha256timestamp.ws.symantec.com/sha256/timestamp http://timestamp.sectigo.com/?td=sha384
So, thanks for the ticket, but this is not a problem.
Although Timestamp servers do not need to respond to TLS requests (and is more defined as "should" rather than "must" in the standard), when they are provided over TLS, I would strongly expect that the trust mechanisms that TLS provides (and KSE actively helps you exploit) would be validated.
However, an allow-all trust manager is installed for such TS HTTPS requests. https://github.com/kaikramer/keystore-explorer/blob/master/kse/src/org/kse/crypto/signing/TimeStampingClient.java#L118:L131
Actively completing the signing process of a JAR and marking the signing process as successful, when a normally untrusted TSA is used, just seems wrong.