Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8

[Gil Tene]

> From: Andrew John Hughes <gnu.andrew at redhat.com>
> Subject: Re: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8
> Date: 12 December 2019 at 08:05:52 GMT+3
> To: Andrew Dinn <adinn at redhat.com>, Volker Simonis <volker.simonis at gmail.com>, Iris Clark <iris.clark at oracle.com>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> 
> 
> 
> On 09/12/2019 10:55, Andrew Dinn wrote:
>> Hi Volker/Iris,
>> 
>> Firstly, thanks to Oracle for offering to update the JDK8u specs and
>> contribute the necessary changes to re-implement the ALPN and RSASSA-PSS
>> APIs.
>> 
>> That said, I can see Volker's point here. Putting the changes into both
>> 8u40 and 8u252 appears to add an extra redundant step as far as the
>> OpenJDK project is concerned. Is there a reason why the 8u40 backport is
>> needed? (more specifically, why does it need to be adopted as the RI?)
>> Is there any reason for Oracle to do the 8u40 backport before
>> backporting to 8u252 and publishing the latter changes?
>> 
>> Of course, if the open project is provided with the relevant 8u252
>> changes in a timely manner then I don't suppose the answers to the above
>> questions are critical. What dominates is the project's ability to
>> respond in time 1) to assimilate the ALPN and RSASSA-PSS API changes and
>> 2) to add TLS 1.3 support on top of those changes. I'll leave it to
>> others (including my Red Hat colleagues) who are more au fait with TLS
>> and the jdk8u schedule to comment on that issue.
>> 
>> regards,
>> 
>> 
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>> 
> 
> As the TLS 1.3 changes don't alter the spec, the only impetus to provide
> those changes is Oracle parity and so, it may be worth pushing that into
> the July CPU timeframe. It may be worth looking at what work can be done
> on TLS 1.3 before the specification changes are required in order to get
> a head start.

When it comes to adding TLS 1.3 support to OpenJDK 8u, there is a good
starting point in https://github.com/openjsse/openjsse . In it's current form it
does not replace or change the default 8u jsse implementation. It is an
optional JSSE provider (hence not needing any spec changes) and is based
on a backport of the 11u TLS1.3 functionality to Java SE 8. It uses it's own
namespace (org.openjsse).

For a built-in support for TLS 1.3, we'd probably want to change the built-in
8u jsse provider, which will have an effect very similar to bringing the various
packages under org.openjsse back to the  root level and dealing with any
conflicts and integration into the current namespace. As some of the Azul
engineers worked on OpenJSSE and are familiar with the details involved
with 8 backporting and compatibility, we'd be happy to contribute to or lead
that effort.

> 
> The other concern regarding the specification changes is also having the
> relevant TCK changes deployed to those who have access to it. We equally
> would prefer not to be in a situation where the changes are in OpenJDK
> 8u252, but the TCK fails without requisite updates.

When the spec is updated, the TCK will be too. To be compliant with the new
spec MR, we'd have to pass the new TCK. But depending on how the spec and TCK
are  updated, it may not require the new functionality, but simply allow it.

E.g. the MR2 update to JSR337 (see https://jcp.org/aboutJava/communityprocess/maintenance/jsr337/jsr337-mr2-changes.html )
relaxed the requirements on cryptographic algorithm names but did not impose
additional restrictions that caused previous implememtations to become
non-compliant. I am hoping that MR3 can be be similarly achieved. Iris,
do you think we'd be able to add the new ALPN and RSASSA-PSS API
capabilities as allowed things that are not absolutely required?

— Gil.