RFR 8191438: jarsigner should print when a timestamp will expire

[Weijun Wang]

> On Dec 14, 2017, at 5:18 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> Looks good, but just to confirm something -- when verifying, if the signer's certificate chain is still valid and unexpired, then an expired or invalid timestamp or chain should not be an error. Essentially, the validation of the timestamp should only be done when the signer's certificate chain expires. Is that how it works?

No.

Suppose the signer cert is expiring next month and the timestamp is expiring next year, I think we still need to show a warning on the expiring timestamp and validate its cert chain.

I agree that even of the timestamp has expired, this is not an error. I'll need to clean the exit code.

Thanks
Max

> 
> Also, please add a release note and a separate docs issue to update the jarsigner doc with these new warnings/errors.
> 
> --Sean
> 
> On 12/13/17 10:37 AM, Weijun Wang wrote:
>> All suggestions accepted. Here is an updated webrev.
>>    http://cr.openjdk.java.net/~weijun/8191438/webrev.01/
>> New test cases added. Other changes are:
>> 1. noTimestamp == true at signing side means no TSA or timestamping failed.
>> 2. New method certsAndTSInfo() used by both signing and verification to display signer/tsa info and set warning flags.
>> Thanks
>> Max
>>> On Dec 7, 2017, at 5:01 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
>>> 
>>> When signing, I think we should always print when the timestamp will expire, even if it is 10 years from now. For the warning, I would bump it up 6 months to a year. (It could potentially be more than this - a fresh timestamp ideally should be good for > 5 years in my opinion). Perhaps we don't warn when signing - just make it informational. But only warn when verifying.
>>> 
>>> Just some quick thoughts -- I'll think about it some more.
>>> 
>>> --Sean
>>> 
>>> 
>>> 
>>> On 12/5/17 4:35 AM, Weijun Wang wrote:
>>>> Hi All
>>>> Please take a look at http://cr.openjdk.java.net/~weijun/8191438/webrev.00/. Regression tests not added yet. I'd like to hear your comments on the output format.
>>>> Major changes:
>>>> 1. New flags hasExpiringTsaCert and hasExpiredTsaCert for TSA cert chain. They are set and used similar to flags for the signer cert chain. Note that there is no notYetValidTsaCert, which I think is not very useful, and it's already covered by CertPath validation.
>>>> 2. No more validity check on trusted certs in printCert(), since CertPath validation also does not check validity of trust anchors.
>>>> 3. Break getAliasInfo() into 2 parts: getAliasInfo() and showAliasInfo(). showAliasInfo() will set flags and show extra info if -verbose after jar is signed.
>>>> The expiration date for all signer and TSA cert chains are shown when -verbose -certs are provided. Warning is only shown when expiration date (for either cert chain) is near.
>>>> An example:
>>>>  $ jarsigner ... a.jar a -tsa http://localhost:8080/time=2017-11-20T00:00:00Z -verbose
>>>> requesting a signature timestamp
>>>> TSA location: http://localhost:8080/time=2017-11-20T00:00:00Z
>>>>  updating: META-INF/A.SF
>>>>  updating: META-INF/A.RSA
>>>>   signing: ks
>>>>>>> Signer
>>>>     X.509, CN=a
>>>>     [certificate is valid from 11/5/17, 12:27 PM to 12/10/17, 12:27 PM]
>>>>     X.509, CN=ca
>>>>     [trusted certificate]
>>>>>>> TSA
>>>>     X.509, CN=ts
>>>>     [certificate will expire on 12/15/17, 12:27 PM]
>>>>     X.509, CN=ca
>>>>     [trusted certificate]
>>>> jar signed.
>>>> Warning:
>>>> The timestamp will expire within six months on 2017-12-15.
>>>> c $ jarsigner ... a.jar -verify -verbose:grouped -certs
>>>> s k     145 Tue Dec 05 10:23:46 CST 2017 META-INF/MANIFEST.MF
>>>>       [entry was signed on 11/20/17, 8:00 AM]
>>>>       >>> Signer
>>>>       X.509, CN=a (a)
>>>>       [certificate is valid from 11/5/17, 12:27 PM to 12/10/17, 12:27 PM]
>>>>       X.509, CN=ca (ca)
>>>>       [trusted certificate]
>>>>       >>> TSA
>>>>       X.509, CN=ts
>>>>       [certificate will expire on 12/15/17, 12:27 PM]
>>>>       X.509, CN=ca (ca)
>>>>       [trusted certificate]
>>>>         307 Tue Dec 05 12:27:08 CST 2017 META-INF/A.SF
>>>>        3811 Tue Dec 05 12:27:08 CST 2017 META-INF/A.RSA
>>>>       (Signature related entries)
>>>>           0 Tue Dec 05 10:23:42 CST 2017 META-INF/
>>>>       (Unsigned entries)
>>>> smk    8364 Tue Dec 05 10:23:00 CST 2017 ks
>>>>       [entry was signed on 11/20/17, 8:00 AM]
>>>>       >>> Signer
>>>>       X.509, CN=a (a)
>>>>       [certificate is valid from 11/5/17, 12:27 PM to 12/10/17, 12:27 PM]
>>>>       X.509, CN=ca (ca)
>>>>       [trusted certificate]
>>>>       >>> TSA
>>>>       X.509, CN=ts
>>>>       [certificate will expire on 12/15/17, 12:27 PM]
>>>>       X.509, CN=ca (ca)
>>>>       [trusted certificate]
>>>>   s = signature was verified
>>>>   m = entry is listed in manifest
>>>>   k = at least one certificate was found in keystore
>>>> - Signed by "CN=a"
>>>>     Digest algorithm: SHA-256
>>>>     Signature algorithm: SHA256withRSA, 2048-bit key
>>>>   Timestamped by "CN=ts" on Mon Nov 20 00:00:00 UTC 2017
>>>>     Timestamp digest algorithm: SHA-256
>>>>     Timestamp signature algorithm: SHA256withRSA, 2048-bit key
>>>> jar verified.
>>>> Warning:
>>>> The timestamp will expire within six months on 2017-12-15.
>>>> Thanks
>>>> Max