RFD: Security Providers Filter (JEP)

[Sean Mullan]

Hi Martin,

Our team at Oracle has done another review of the proposed feature and 
we have some questions that we would like to discuss below.

This is a significant effort that would add some valuable features to 
the Security Provider mechanism. However, this is also modifying an 
important core function used by all JCA/JCE APIs to locate 
implementations, so we want to make sure we spend the time to review all 
aspects of the proposal thoroughly.

- The current implementation introduces behavior changes in the Provider 
API which we believe would need to be specified in the specification. 
For example, if an application registers a service that is restricted by 
  the filter using the Provider API, then that service won't be returned 
by methods such as Provider.getServices(). This is a behavior change in 
the API. I don't think it could be specified as an implementation note, 
since it changes the specified behavior of these methods.

Adding specification changes will make any backport much more difficult, 
if that was one of your goals.

- Did you consider implementing the filtering mechanism at a higher 
layer, in the getInstance methods? This could possibly avoid the 
specification concerns above, as the behavior could potentially be added 
as implementation notes in the getInstance methods, similar to the 
implementation note for the jdk.security.provider.preferred Security 
property.

- The syntax doesn't currently support key size constraints, or 
algorithm constraints that are not specified in algorithm names, such as 
the parameters used with the RSASSA-PSS algorithm. How would you add 
support for these in the future?

- Does the filtering work for providers that are not registered, and 
just passed into the getInstance methods?

- Did you consider implementing this as a Provider.configure option? 
There are pros/cons to doing that, but given that the configure method 
is designed to configure providers, we think it should be
considered and described in the Alternatives section.

-  Would early initialization of the filter inadvertently triggered by a 
cryptographic operation (for example, when verifying a signed JAR on the 
classpath) cause subsequent settings of the filter by an application at 
runtime to be ignored? If so, this is something that could easily go 
undetected, as the filter could be silently ignored and thus 
restrictions not enforced as expected - it may be worth considering 
throwing an exception if you can detect that the property has already 
been set and processed. The logging and debugging mechanisms are helpful 
but I view them as being more useful when testing the filter or later 
debugging of issues.

- Does the additional searching for Cipher transformations cause 
significant performance issues?

Thanks,
Sean

On 2/26/24 5:12 PM, Martin Balao wrote:
> Hello,
> 
> We would like to announce that the Security Providers Filter JEP (draft) 
> is available for discussion.
> 
>   * https://openjdk.org/jeps/8325511
> 
> As a reminder, the implementation pull-request is available at https:// 
> github.com/openjdk/jdk/pull/15539
> 
> We look forward to any questions, comments and feedback.
> 
> Thanks,
> Martin and Francisco.-