RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator
Sean Mullan
sean.mullan at oracle.com
Tue Nov 14 18:47:10 UTC 2017
On 11/8/17 6:47 PM, Valerie Peng wrote:
> Hi, Sean,
>
> I updated the webrev in place - now this change contains only javadoc
> update of DSAKeyPairGenerator interface.
> CSR has also been updated accordingly. Could you please take a look?
Sure.
35 * DSAKeyPairGenerator, each provider must supply (and document) a
36 * default initialization.
I suggest saying "should" instead of "must" since we can't really
require this to be documented, esp. for a 3rd-party provider. Also I
would say "each provider that implements this interface ...".
52 * DSAKeyPairGenerator, then call one of the {@code initialize}
methods
Slight rewording suggestion: "DSAKeyPairGenerator and calling one of the
{@code initialize} methods"
103 * thrown. It is guaranteed that there will always be
104 * default parameters for modulus lengths of 512, 1024, and
2048 bits.
I guess "guaranteed" is referring to any impl of DSAKeyPairGenerator,
but it is kind of hard to enforce that if you are using a 3rd-party
provider. I think we should consider just removing this sentence
entirely and leaving the requirements up to the implementation. It's
also unusual that we would require 512-bits, and hard-coding that might
make it hard to remove later on. Minimally, I think we should remove 512.
--Sean
>
> Thanks,
> Valerie
>
> On 11/2/2017 6:24 PM, Valerie Peng wrote:
>> Sean,
>>
>> Could you help review this RFE below? It's mainly the javadoc update
>> of java.security.interfaces.DSAKeyPairGenerator which replaces the
>> 1024-bit default value with provider-specific one and removal of the
>> earlier changes for working around this javadoc limitation. I reused
>> the wordings from existing security classes.
>>
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8182484
>> Webrev: http://cr.openjdk.java.net/~valeriep/8182484/webrev.00/
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190569
>>
>> Thanks,
>> Valerie
>
More information about the security-dev
mailing list