Hi Sean, thanks for the information.
Can you please let me know when you've crated the Jira item for removal that I can add me as a watcher? Thanks & Best regards Christoph > -----Original Message----- > From: Sean Mullan <sean.mul...@oracle.com> > Sent: Mittwoch, 22. August 2018 15:41 > To: Langer, Christoph <christoph.lan...@sap.com>; Rajan Halade > <rajan.hal...@oracle.com>; security-dev <security-dev@openjdk.java.net> > Subject: Re: RFR: 8209452: VerifyCACerts.java failed with "At least one cacert > test failed" (gtecybertrustglobalca certificate) > > On 8/22/18 5:17 AM, Langer, Christoph wrote: > > Hi, > > > > I've seen the changes that should allow for keeping the GTE cybertrust root > ca around although it has expired on 14th of August, also this one: > http://mail.openjdk.java.net/pipermail/security-dev/2018-April/017023.html > > > > However, I'd like to ask the question if you really plan to keep this > > expired > certificate? Shouldn't there be a replacement for it or are there plans to > remove it at all some time? > > There is no replacement for this root. Let me explain further why we had > been keeping this expired root. Certificates that chain back to this > root have been issued for TLS and code signing. With code signing > certificates, the signed code may have also been timestamped, allowing > that code to continue to be valid even after the code signing > certificate (or any CA in its chain, including the root) expires. Thus, > if we removed this root, there is a risk that we would break existing > signed code that has been timestamped with certificates chaining back to > this root. > > That said, this is primarily a risk for signed applets and Web Start > apps. Applets are deprecated as of JDK 9 and Oracle does not include Web > Start in JDK 11. I am not aware of other use cases for timestamping Java > code, anyone else? Therefore, I think it is safe and of minimal risk to > remove this root going forward and I will file an issue to do that. It's > too late to do that for JDK 11, but we can consider removing it in a > subsequent update as a backport. > > --Sean > > > > > Thanks & Best regards > > Christoph > > > >> -----Original Message----- > >> From: security-dev <security-dev-boun...@openjdk.java.net> On Behalf > Of > >> Sean Mullan > >> Sent: Dienstag, 14. August 2018 18:35 > >> To: Rajan Halade <rajan.hal...@oracle.com>; security-dev <security- > >> d...@openjdk.java.net> > >> Subject: Re: RFR: 8209452: VerifyCACerts.java failed with "At least one > cacert > >> test failed" > >> > >> Looks good. When you push the changeset, can you add a Summary line > with > >> more details of the fix, ex: > >> > >> Summary: allow expired certificates on exception list to pass after they > >> expire > >> > >> Thanks, > >> Sean > >> > >> On 8/14/18 12:22 PM, Rajan Halade wrote: > >>> Please review this fix to allow test to pass if expired certificate is > >>> allowed by exception list. > >>> > >>> Webrev: http://cr.openjdk.java.net/~rhalade/8209452/webrev.00/ > >>> > >>> Thanks, > >>> Rajan
