RFR CSR 8202590: Customizing the generation of a PKCS12 keystore

[Weijun Wang]

Sorry, busy on something else.

> On May 11, 2018, at 11:47 PM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> On 5/9/2018 6:06 AM, Weijun Wang wrote:
>> Hi Mike
>> 
>> Your comments make sense. However,
>> 
>> 1. I don't think it's easy in JDK to break a PBE algorithm into PBKDF + Cipher. For example, I cannot create a SecretKey from SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") and use it to init a Cipher.getInstance("DESede"). I still have to use Cipher.getInstance("PBEWithSHA1AndDESede").
>> 
> 
> No - you'd instantiate a KDF using PBE, derive the secret key from the password, and use it with DESede.   Right now, you're hiding a KDF under the cover of turning a secret key spec into a secret key.   

Last time I tried, SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") can only generate a PBEKey (which has not been derived) and Cipher.getInstance("DESede") does not accept it. I'll take another look.

I know it's a good practice using the same PBKDF for certs and keys. Must we enforce it and not allow people to use different ones?

> 
> And right now, all of this is actually hidden under the KeyStore covers.    If you're going to use compound algorithm names, what I'd rather do is 
> 
> KeyStore ks = KeyStore.getInstance("PKCS12/PBKDF2/HMAC-SHA256/AES-KW");    
> 
> Or  <keystoretype>/<kdfalg>/<kdfprf and mac alg>/<dataencryption alg>

Big change, not this time.

> 
> And have the generic KeyStore.getInstance("PKCS12")  return what you specify in the preferences, or a general parser for things you're reading in.
> 
> 
>> ....
> 
> 
> But, after thinking about it a bit more, the preference list isn't useful without additional providers - and at that point you're probably generating stuff by specifying algorithms and such so I agree with no preference list.  Could you please, please, please not use weak algorithms as the default here though?

PBEWithHmacSHA256AndAES_128?

I'll see how other tools support it.

Thanks
Max

> 
>> 
>> Thanks
>> Max
>> 
>> 
>>> On May 5, 2018, at 10:50 PM, Michael StJohns <mstjohns at comcast.net>
>>>  wrote:
>>> 
>>> On 5/5/2018 3:38 AM, Weijun Wang wrote:
>>> 
>>>> Please take a review of
>>>> 
>>>>    
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8202590
>>>> 
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>> 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.
>>> # password to key material scheme
>>> .pbkdf=PBKDF2withHMAC-SHA256  (Form is base function with the PRF)
>>> # PKCS12 macData
>>> .macAlgorithm=HMAC-SHA256  # this is the algorithm for the PKCS12 macData component, if NONE, this component is not present
>>> # protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag is produced instead.
>>> .keyProtectionAlgorithm=AES-KWA 
>>> #protection scheme for certificates - produces an encryptedData object encrypted under the scheme, or a certBag object if "NONE" is specified
>>> .certProtectionAlgorithm=NONE
>>> 
>>> 
>>> Second, you probably want to do this as multi-choice entries in the java.security file ala providers:
>>> 
>>> .pbkdf.0=PBKDF2withSHA256
>>> .pbkdf.9=PBKDF1withSHA1 # the current default aka pbe
>>> 
>>> So that you can specify a somewhat secure default, but still allow for providers that don't implement the stronger versions.
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> 
>