On 8/4/2016 1:41 PM, Bernd Eckenfels wrote:
Hello,
I am glad as a user that I am only annoyed by the limited policies and
that I do not have to actually implement features to restrict my
software. :)
You are indeed fortunate. :)
However your mail reminded me: will it be a good idea to implement
something like a Fips-compliant runtime in terms of (yet another)
policy?
This policy is just for enforcing maximum JCE keysizes for import/export
purposes, which has been there since pretty much Day 1 of JCE. This is
just repackaging existing policy, as the jigsaw team really wanted to
get rid of the jar files. JEP 220.
A FIPs matrix is a discussion for another release.
Related to that: are there any other useful uses for those jce policies?
(Never encounter them besides the restricted ciphers).
I don't think so. I think for most cases, people are able to install
the unlimited bundle and are done.
This was before my time, but I believe this was only to satisfy
export/import requirements.
For things like
enforcing minimum security (FIPS, PCI-DSS, ...) the policy objects
should not only feature maximum keysizes, but also minimum sizes,
right? Same is true for denying weakening attributes and such. On the
other hand this greatly conflicts with the security properties already
existing (at least for JSSE).
You mail did not talk about signatures, will the new policies require
to be signed by a JCE certifiate (i.e. via Oracle) or can they be
customized without?
Customized without.
Will there be an option "use strongest available"? That way an JDK
upgrade (overwrite the files) will no longer be a problem as the
additional policy persists - but I still would need the system property
to activate it...
I would expect our limited/unlimited files/directories won't change. The
contents have been static for years, but required the extra step of the
download/replacement until earlier in JDK 9.
There have been 2-3 one-off policy file bundles generated over the last
15 years (with even tighter restrictions), but ivery rare.
If you're modifying java.security, that is the only file you'll need for
persistent policy going forward. If you are creating your own
directories, you'll of course need to copy those over too.
BTW, it's a Security property, not a java.lang.System property.
Brad
Gruss
Bernd
Am Thu, 4 Aug 2016 12:35:21 -0700 schrieb Bradford Wetmore
<bradford.wetm...@oracle.com>:
https://bugs.openjdk.java.net/browse/JDK-8061842
http://cr.openjdk.java.net/~wetmore/8061842/webrev.00/
The proposal is to move the configuration files from the jar files in
<java-home>/lib/security to a series of subdirectories under a new
"policy" subdirectory in <java-home>/conf/security. Each
subdirectory within that directory will represent a complete policy
configuration. The existing jar files will be split into flat text
files such that the current/existing policies remain.
The default set of policy files (i.e. directory) is configured using
a new java.security.Security property called "crypto.policy" which
will be added to the <java-home>/conf/security/java.security file.
The default initial options are "limited" or "unlimited", however
additional directories could potentially be created that specify
other as-yet-unknown policies.
The default value of this property will be "limited" which
corresponds to our current policy for JRE/JDK export/import around
the world. However, the build respects the following "configure"
option:
--enable-unlimited-crypto
Enable unlimited crypto policy [disabled]
Within the directory, our implementation will look for files using
the standard filename prefix above ("default_" or "exempt_"), thus
new additional policy restrictions/abstractions can be added with a
simple file addition.
Brad
