RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Valerie Peng
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
Reply | Threaded
Open this post in threaded view
|

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Valerie Peng
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?

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

Reply | Threaded
Open this post in threaded view
|

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Sean Mullan
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
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Valerie Peng

Thanks for the feedback.

I have updated webrev to address your comments:
http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/
CSR has also been updated and proposed.
Valerie

On 11/14/2017 10:47 AM, Sean Mullan wrote:

> 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
>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Sean Mullan
One more small comment:

   51  * <li>Check if the returned key pair generator is an instance of the
   52  * DSAKeyPairGenerator interface before casting the result to a

I would just say "... instance of DSAKeyPairGenerator before ..."

--Sean

On 11/16/17 7:39 PM, Valerie Peng wrote:

>
> Thanks for the feedback.
>
> I have updated webrev to address your comments:
> http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/
> CSR has also been updated and proposed.
> Valerie
>
> On 11/14/2017 10:47 AM, Sean Mullan wrote:
>> 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
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR [10]: JDK-8182484: Remove 1024-bit default requirement from javadoc of java.security.interfaces.DSAKeyPairGenerator

Valerie Peng
Sure, webrev updated  and CSR moved to finalized state.

http://cr.openjdk.java.net/~valeriep/8182484/webrev.02/
Thanks,
Valerie

On 11/21/2017 9:28 AM, Sean Mullan wrote:

> One more small comment:
>
>   51  * <li>Check if the returned key pair generator is an instance of
> the
>   52  * DSAKeyPairGenerator interface before casting the result to a
>
> I would just say "... instance of DSAKeyPairGenerator before ..."
>
> --Sean
>
> On 11/16/17 7:39 PM, Valerie Peng wrote:
>>
>> Thanks for the feedback.
>>
>> I have updated webrev to address your comments:
>> http://cr.openjdk.java.net/~valeriep/8182484/webrev.01/
>> CSR has also been updated and proposed.
>> Valerie
>>
>> On 11/14/2017 10:47 AM, Sean Mullan wrote:
>>> 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
>>>>
>>