[Cscwg-public] FW: Invalidity Date

Tue Feb 15 08:53:17 UTC 2022

Hello,

My understanding is the same as yours.

Atsushi Inaba

―――――――――――――――――――――――――――――

GMO GlobalSign K.K.

Business Planning

Atsushi Inaba

1-2-3, Dogenzaka, Shibuya Ku, Tokyo, Japan

150-0043

TEL: +81-3-6370-6671

FAX: +81-3-6370-6505

E-MAIL:  <mailto:atsushi.inaba at globalsign.com> atsushi.inaba at globalsign.com

 <URL:https://jp.globalsign.com/> URL:https://jp.globalsign.com/

―――――――――――――――――――――――――――――

THANK YOU 26 YEARS Internet for Everyone

―――――――――――――――――――――――――――――

■ GMO INTERNET GROUP ■  <http://www.gmo.jp/> http://www.gmo.jp/

―――――――――――――――――――――――――――――

This e-mail message is intended to be conveyed only to the 

designated recipient(s). If you are NOT the intended 

recipient(s) of this e-mail, please kindly notify the sender 

immediately and delete the original message from your system.

From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Adriano Santoni via Cscwg-public
Sent: Monday, February 14, 2022 9:31 PM
To: cscwg-public at cabforum.org
Subject: Re: [Cscwg-public] FW: Invalidity Date

I also understand it this way.

Adriano

Il 14/02/2022 12:32, Dimitris Zacharopoulos (HARICA) via Cscwg-public ha scritto:

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  <mailto:raji.madduri at oracle.com> <raji.madduri at oracle.com> 
Sent: Thursday, January 27, 2022 4:47 PM
To: Bruce Morton  <mailto:Bruce.Morton at entrust.com> <Bruce.Morton at entrust.com>
Cc: javase-ca-request_ww_grp  <mailto:javase-ca-request_ww_grp at oracle.com> <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 <mailto:Bruce.Morton at entrust.com> > 
Sent: Friday, December 3, 2021 8:54 AM
To: Raji Madduri <raji.madduri at oracle.com <mailto:raji.madduri at oracle.com> >
Cc: javase-ca-request_ww_grp <javase-ca-request_ww_grp at oracle.com <mailto: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 <mailto:raji.madduri at oracle.com> > 
Sent: Thursday, October 14, 2021 1:21 PM
To: Bruce Morton <Bruce.Morton at entrust.com <mailto:Bruce.Morton at entrust.com> >
Cc: javase-ca-request_ww_grp <javase-ca-request_ww_grp at oracle.com <mailto: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 <mailto:Bruce.Morton at entrust.com> > 
Sent: Thursday, October 14, 2021 5:33 AM
To: Raji Madduri <raji.madduri at oracle.com <mailto: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 <mailto: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 <mailto:Cscwg-public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/cscwg-public

_______________________________________________
Cscwg-public mailing list
Cscwg-public at cabforum.org <mailto: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/20220215/4172b709/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8426 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220215/4172b709/attachment-0001.p7s>