Hi Tony,
Thanks for pointing this out. Your observation is right.
We looked at this problem from a different angle, when defining internal
consistency of a filter value as out of scope [1]. Our concern was that
a filter value may render services unusable because of dependencies
(e.g. Signatur
Hi Martin,
Thanks for the additional motivation.
While thinking about this PR, I found that the filter can be
inconsistently applied between JDK and 3rd party providers. The java
providers use the JCA to build combined algorithms. For example, the
ECDSAwithSHA1 that comes from SunEC uses get
Hi Tony,
Thanks for having a look at our proposal.
The main motivation for this enhancement is related to cryptographic
policy enforcement and, in particular, the following capabilities: 1)
enforcing that cryptographic services are provided by chosen security
providers only, and 2) allowing o
Hi Martin,
Thanks for the proposal. Your documents mostly describe the solution.
Can you provide more of the motivations and use-cases for the change?
Do you see non FIPS-140 applications using this feature?
The feature does provide a comprehensive filtering system for JCA. The
syntax, while
Hi Sean,
Thanks for clarifying your idea. I understand your motivation and share
your concerns. I can think of how this application-specific knowledge can
turn into a library-specific one in real scenarios, which may open the door
for undesired dependencies. I also agree with being wary about doin
On 7/13/23 12:27 PM, Martin Balao wrote:
On 7/13/23 12:06, Sean Mullan wrote:
One other comment that I thought of - is that from a practical
standpoint, I think it will be hard to unilaterally disable an algorithm
at the JCE layer unless it is so broken that almost no code ever uses
it, say M
On 7/13/23 12:06, Sean Mullan wrote:
One other comment that I thought of - is that from a practical
standpoint, I think it will be hard to unilaterally disable an algorithm
at the JCE layer unless it is so broken that almost no code ever uses
it, say MD2 or RC2. There may be cases where a weak
One other comment that I thought of - is that from a practical
standpoint, I think it will be hard to unilaterally disable an algorithm
at the JCE layer unless it is so broken that almost no code ever uses
it, say MD2 or RC2. There may be cases where a weak algorithm is
acceptable, for example
Hi Sean,
Thanks for your feedback.
Just to give some visibility, we have implemented most of the
functionality and are now working on final adjustments, more tests
coverage, documentation and internal reviews. The implementation is
pretty much aligned to what we previously discussed, with the
This proposal looks pretty good, although I think I would like to see
more examples and a prototype if you have it.
I think this would work well in conjunction with Sean Coffey's
enhancement to add a security category to the java -XshowSettings option
[1]. This would help debug issues with the
On 5/25/23 19:54, Wei-Jun Wang wrote:
So, the filter will look like this?
SunPKCS11-Name.Signature.*,!*.Signature.*,*
Yes, that's right. The filter that you showed will do the following:
1) Accept Signature services provided by SunPKCS11-Name, irrespective of
the algorithm;
2) Block S
I see.
So, the filter will look like this?
SunPKCS11-Name.Signature.*,!*.Signature.*,*
--Max
> On May 25, 2023, at 6:40 PM, Martin Balao wrote:
>
> Hi Max,
>
> In this example, we want certificates validation from SUN but signature
> verification from SunPKCS11 (only). The problem with t
Hi Max,
In this example, we want certificates validation from SUN but signature
verification from SunPKCS11 (only). The problem with the current design
is that there could be a signature algorithm implemented in SUN but not
in SunPKCS11. If that is the case, there is no way to prevent SUN from
Or this, which is an example of limiting a codebase by it's SHA-384
signature:
https://github.com/pfirmstone/JGDMS/blob/14608ea34eb7c109d41e296a62669522862f6a49/qa/harness/policy/defaultsecuretest.policy#L2241
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
On 25/05/
These are examples of how we currently lock down the JVM, to limit
providers, policy files are generated using a tool, it may do as an
interim control measure, until something else is provided, it is of
course a deprecated feature, subject to future removal, but it may do
the job temporarily, w
> On May 24, 2023, at 5:03 PM, Martin Balao wrote:
>
>>> To better illustrate, let's say that the user requires that all
>>> cryptographic operations are performed in a Hardware Security Module (HSM).
>>> On the OpenJDK side, this means that the implementation for Cipher,
>>> Signature, Mac
Hi,
Thanks Anthony for your feedback.
We've been exploring the syntax and semantics for this new property
further, with the goal of making it more consistent and simple while
retaining expressiveness power. We understand the importance of clarity
to minimize the risk of security providers, se
Hi Martin,
Interesting proposal. I think Alternative 1 is a better direction to
explore from a code structure standpoint. If I remember correctly,
Preferred Provider is accessed when getting a service or instance of the
algorithm. That happens on a per-operation basis. What you describe is
Hi,
We would like to discuss a limitation in the current configuration
capabilities for security providers and possible solutions that we are
exploring (†).
As you know, current configuration capabilities in java.security allow
users to install security providers, decide their priority in a
19 matches
Mail list logo
