[Cscwg-public] FW: Invalidity Date

Mon Feb 14 12:30:45 UTC 2022

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 <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
>
>
> _______________________________________________
> 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/d2794d9b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4557 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20220214/d2794d9b/attachment-0001.p7s>