[EXTERNAL] Re: An update on ecosystem concerns removing javax.security.cert

[John Gray]

Thanks for the reply!

If it is not happening until 22 or later that gives us more time.   I understand we already had lots of years, I guess that is the problem with code that has just worked for so many years.  You don’t look at it until it breaks.  Fortunately I noticed this before it breaks…  😊

There aren’t that many places that use getPeerCertificateChain() anymore, and it looks like a couple places in some older code from around 2002 are using javax.security.cert.X509Certificate when they could easily use java.security.cert.

Our toolkit has been around since the Java 1.2 days… So it has gone through all the various incarnations of bundled extensions, installed extension, signed and unsigned jars (JDK 1.4), all that fun stuff from the past.   😊

Looks like its not going to be hard to “modernize” that old stuff.   On a positive note, we support bleeding edge stuff like composite algorithms and hybrid certificates.  😊   So the JCA has stood up well after so many years.   I’m looking forward to the new KEM API’s that you are adding for us.

Cheers,

John Gray


From: Eirik Bjørsnøs <eirbjo at gmail.com>
Sent: Monday, April 17, 2023 10:58 AM
To: John Gray <John.Gray at entrust.com>
Cc: security-dev at openjdk.org
Subject: Re: [EXTERNAL] Re: An update on ecosystem concerns removing javax.security.cert

Hi John, thanks for reaching out!

I just happened to notice this on the list this morning.  We have a 20+ year old commercial Java cryptographic toolkit at Entrust that we maintain and implement security protocols and algorithms which makes use of API’s in the javax.security.cert package.  It is in used by many customers.

Would you be able to share a bit more about how your product is exposed to these APIs? The APIs were introduced around 2002 for compatibility concerns with unbundled JSSE releases. They deprecated in Java 9, but has had a notice discouraging their use since they were introduced.

It looks like you are planning to remove that entire package now?

No decision or commitment has been made yet. But yes, there is an ongoing effort to get this removed, we just don't know when yet.

The topic of removal has been discussed for about five years now. The APIs were marked deprecated for-removal in Java 13. In Java 15, the SSLSession.getPeerCertificateChain interface method was changed to be a default method which throws UnsupportedOperationException.

We still compile with Java 8 (because we have customers that still need Java 8 support), but we need to support later Java runtime versions.

This will compile fine with the current LTS, which is Java 17. The next LTS will be 21, coming this fall.

I would recommend that you start looking at any use of javax.security.cert.X509Certificate for parsing certificates. That should be replaced with java.security.cert.CertificateFactory. Then I'd look to see if you have any calls to SSLSession.getPeerCertificateChain. Those should be replaced with SSLSession.getPeerCertificate.

Once you've done this, you might be left with your own implementations of SSLSession.getPeerCertificateChain. If you have any of those, you'll need to override them to compile on Java 11. From Java 17, there is the mentioned default getPeerCertificate method, so your implementation will not need to override this method.

If you need to support Java 8 AND Java X (where X has removed the package), then you'll need to look into versioned jars, modularization or other forms of build changes such that you can compile against this wide range of Java versions.

I guess we would have eventually noticed this when we upped our base compiler to 11 which probably won’t happen until 8 no longer has extended support (which is 2030 according to this?)

This would give you the deprecation warning introduced in Java 9, yes.

I guess we will have to make a number of changes to our toolkit because this change will break things in a number of areas in Java 19.

I believe there were no changes in this area in Java 19. The removal will not happen until 21, 22, 23 or later.

Thanks again for your feedback, much appreciated!

Eirik.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20230417/28416bca/attachment.htm>