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.-
