Sorry, busy on something else.
> On May 11, 2018, at 11:47 PM, Michael StJohns <mstjo...@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 <mstjo...@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
>>>
>>>
>>>
>>>
>>>
>
