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

[Eirik Bjørsnøs]

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