<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 5/5/2018 3:38 AM, Weijun Wang wrote:<br>
</div>
<blockquote type="cite"
cite="mid:253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com">
<pre wrap="">Please take a review of
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8202590">https://bugs.openjdk.java.net/browse/JDK-8202590</a>
This enhancement has two major purposes:
1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.
Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.
Thanks
Max
</pre>
</blockquote>
<br>
<code>I think you want to break this into two parts - the first part
specifies the algorithm used to convert a password into key
material. The second defines the algorithms used for protection
for the various parts.<br>
# password to key material scheme<br>
.pbkdf=PBKDF2withHMAC-SHA256 (Form is base function with the PRF)<br>
# PKCS12 macData<br>
.macAlgorithm=HMAC-SHA256 # this is the algorithm for the PKCS12
macData component, if NONE, this component is not present<br>
# protection scheme for PKCS8ShroudedKeyBagn if NONE, then a
PKCS8KeyBag is produced instead.<br>
.keyProtectionAlgorithm=AES-KWA <br>
#protection scheme for certificates - produces an encryptedData
object encrypted under the scheme, or a certBag object if "NONE"
is specified<br>
.certProtectionAlgorithm=NONE<br>
<br>
<br>
Second, you probably want to do this as multi-choice entries in
the java.security file ala providers:<br>
<br>
.pbkdf.0=PBKDF2withSHA256<br>
.pbkdf.9=PBKDF1withSHA1 # the current default aka pbe<br>
<br>
So that you can specify a somewhat secure default, but still allow
for providers that don't implement the stronger versions.<br>
<br>
This requires a bit more work in figuring out what the embedded
OIDs should be, and there is always the chance of mismatch, but it
turns out there is the chance of mismatch even in the proposed
version if you have protection algorithms coming from two
different PBE schemes.<br>
<br>
Specifying it this way is closer to the PKCS5 2.0 model rather
than PKCS12 and matches the recommendations in the IETF's version
of PKCS12. You also *really* don't want to use two different KDFs
with the same password.<br>
<br>
Mike<br>
<br>
<br>
<br>
<br>
</code>
</body>
</html>