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. :)
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? Related to that: are there any other useful uses for those jce policies? (Never encounter them besides the restricted ciphers). 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? 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... 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 >
