[Cscwg-public] FW: Invalidity Date

Mon Feb 14 11:32:01 UTC 2022

Bruce,

I believe they say that *they do check* the time-stamp signature if the 
code signing certificate has expired.

In my understanding, this is clearly communicated by the following 
statement:

/"This is not true. Assuming the signature of the signed and timestamped 
JAR is still valid then an expired code signing certificate is still 
valid as long as the timestamp is within the certificate validity period 
of all certificates in the signer's chain."/

What do others think?

Dimitris.

On 28/1/2022 5:27 μ.μ., Bruce Morton via Cscwg-public wrote:
>
> Here is a response from Oracle regarding invalidity date and 
> timestamping. I thought I would circulate to ensure that I didn’t 
> mis-interpret.
>
> Thanks, Bruce.
>
> *From:* Raji Madduri <raji.madduri at oracle.com>
> *Sent:* Thursday, January 27, 2022 4:47 PM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>
> *Cc:* javase-ca-request_ww_grp <javase-ca-request_ww_grp at oracle.com>
> *Subject:* [EXTERNAL] RE: Invalidity Date
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know 
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Hi Bruce,
>
> In response to your question:
>
> Is this also true if the certificate has expired? What I mean is that 
> if the certificate expired, the signature would not be trusted, even 
> if it was time-stamped.
>
> This is not true. Assuming the signature of the signed and timestamped 
> JAR is still valid then an expired code signing certificate is still 
> valid as long as the timestamp is within the certificate validity 
> period of all certificates in the signer's chain.
>
> However, if the timestamp or TSA certificate (or any certificates in its
>
> chain) is expired, revoked, or otherwise invalid, then the signed code 
> is treated as if it were not timestamped. In this case, if the 
> signer's certificate had also expired, then it would be treated as 
> invalid.
>
> Before deploying timestamped code, customers should always run 
> "jarsigner -verify" to confirm that the code is properly timestamped. 
> If there is something wrong with the timestamp, jarsigner should print 
> out the following warning:
>
> "This jar contains signatures that do not include a timestamp. Without 
> a timestamp, users may not be able to validate this jar after any of 
> the signer certificates expire (as early as %1$tY-%1$tm-%1$td)."
>
> Running jarsigner again with "-J-Djava.security.debug=jar" should 
> print out information about why the timestamp was invalid.
>
> To check if certificates are revoked, you can add the "-revCheck" 
> option to jarsigner (since JDK 15).
>
> Hope this helps. Let us know if you need any further clarification.
>
> Regards,
>
> Raji
>
> *From:* Bruce Morton <Bruce.Morton at entrust.com>
> *Sent:* Friday, December 3, 2021 8:54 AM
> *To:* Raji Madduri <raji.madduri at oracle.com>
> *Cc:* javase-ca-request_ww_grp <javase-ca-request_ww_grp at oracle.com>
> *Subject:* [External] : RE: Invalidity Date
>
> Hi Raji,
>
> Is this also true if the certificate has expired? What I mean is that 
> if the certificate expired, the signature would not be trusted, even 
> if it was time-stamped.
>
> Thanks, Bruce.
>
> *From:* Raji Madduri <raji.madduri at oracle.com>
> *Sent:* Thursday, October 14, 2021 1:21 PM
> *To:* Bruce Morton <Bruce.Morton at entrust.com>
> *Cc:* javase-ca-request_ww_grp <javase-ca-request_ww_grp at oracle.com>
> *Subject:* [EXTERNAL] RE: Invalidity Date
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know 
> the content is safe.
>
> ------------------------------------------------------------------------
>
> Hi Bruce,
>
> In Java Web Start and Plug-in, with respect to signed code, if a 
> certificate is revoked, we will not load that code, regardless of when 
> it was revoked. In other words, we don't look at either the revocation 
> date or the invalidity date. We simply don't trust it if it is revoked.
>
> Thanks,
>
> Raji
>
> *From:* Bruce Morton <Bruce.Morton at entrust.com>
> *Sent:* Thursday, October 14, 2021 5:33 AM
> *To:* Raji Madduri <raji.madduri at oracle.com>
> *Subject:* [External] : RE: Invalidity Date
>
> Hi Raji,
>
> Just following up on this request. I believe a ballot which will 
> suggest that the CAs stop using invalidity date will soon be proposed. 
> I would like to change the ballot, if this will impact Java signatures.
>
> Thanks, Bruce.
>
> *From:* Bruce Morton
> *Sent:* Wednesday, October 6, 2021 12:18 PM
> *To:* Raji Madduri <raji.madduri at oracle.com>
> *Subject:* Invalidity Date
>
> Hi Raji,
>
> Can you please advise if Java uses the invalidity date per RFC 5280, 
> see https://datatracker.ietf.org/doc/html/rfc5280#section-5.3.2 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5280*section-5.3.2__;Iw!!ACWV5N9M2RV99hQ!Ysj5IUx4t6IjHNJxLooKWVbWrCyJpeSeeyxLTEHx4LwHewlHMcBMN9C-t0gD-qHRiQ$>?
>
> Windows does not use this date, so they request that we “back-date” 
> the revocation date to support the invalidity date concept. Would like 
> to know what to expect from Java.
>
> Thanks, Bruce.
>
> /Any email and files/attachments transmitted with it are confidential 
> and are intended solely for the use of the individual or entity to 
> whom they are addressed. If this message has been sent to you in 
> error, you must not copy, distribute or disclose of the information it 
> contains. _Please notify Entrust immediately_ and delete the message 
> from your system./
>
>
> _______________________________________________
> Cscwg-public mailing list
> Cscwg-public at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/cscwg-public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220214/d4440a7b/attachment.html>