RFR: 8061842: Package jurisdiction policy files as something other than JAR

[Bradford Wetmore]

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