[9] RFR: 8042967: Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

Sean Mullan sean.mullan at oracle.com
Tue Feb 17 18:36:26 UTC 2015


Looks good.

--Sean

On 02/16/2015 01:53 PM, Jason Uh wrote:
> Thanks Sean.
>
> Here it is with your suggested changes:
> http://cr.openjdk.java.net/~juh/8042967/04/
>
> Opened an issue to track the docs changes:
> https://bugs.openjdk.java.net/browse/JDK-8073261
>
> Jason
>
>
> On 02/16/2015 10:22 AM, Sean Mullan wrote:
>> Hi Jason,
>>
>> Here are my comments -
>>
>> * General
>>
>> - please open a corresponding issue to add these new algorithms to the
>> "Standard Algorithm Names" and "Oracle Providers" security guides. File
>> in the docs/guides component and add a "securitydocs" label. Please add
>> a release-notes=yes label to the bug as well.
>>
>> * DSA.java
>>
>> - you can move line 215 inside the block starting at line 217.
>>
>> * ECDSASignature.java
>>
>> - lines 83-84 can be changed to this(false);
>>
>> --Sean
>>
>> On 02/11/2015 06:18 PM, Jason Uh wrote:
>>> Please review this change, which enables DSA and ECDSA signatures in the
>>> IEEE P1363 format (the concatenation of r and s) by introducing new
>>> algorithm name Strings.
>>>
>>> http://cr.openjdk.java.net/~juh/8042967/02/
>>>
>>> Thanks,
>>> Jason
>>>
>>> On 01/30/2015 02:18 PM, Jason Uh wrote:
>>>> Mike,
>>>>
>>>> Thanks again for weighing in. As you're not opposed to the proposal, I
>>>> will go ahead and move forward with this plan.
>>>>
>>>> I will put out an updated webrev with the new approach once it is
>>>> ready.
>>>>
>>>> Thanks,
>>>> Jason
>>>>
>>>>
>>>>
>>>> On 1/29/15 3:56 PM, Michael StJohns wrote:
>>>>> At 03:41 PM 1/29/2015, Jason Uh wrote:
>>>>>> Mike,
>>>>>>
>>>>>> Thanks for your feedback.
>>>>>>
>>>>>> I'll be changing this fix to introduce new algorithm Strings to
>>>>>> specify the P1363 format. These strings will be of the form:
>>>>>>
>>>>>>   <digest>with<encryption>in<format>Format
>>>>>>
>>>>>> For example:
>>>>>>
>>>>>>   SHA1withDSAinP1363Format
>>>>>>   SHA1withECDSAinP1363Format
>>>>>
>>>>> Hmm... hadn't gotten that far.
>>>>>
>>>>> I think that would work, but its not quite right as in this case its
>>>>> about format, but might be about some other twiddle ( say endianess)
>>>>> for other specifications.  If would be nice if the convention applied
>>>>> to more than ECDSA and DSA.  I'm not opposed to the proposal though.
>>>>>
>>>>> My counter proposal would be for <algorithm>[/<specification>] as the
>>>>> naming convention.  With the general contract that all implementations
>>>>> of <algorithm> share the same general math at least for KeyAgreement
>>>>> and Signature but may not share the same concrete representations or
>>>>> encodings (e.g. there's difference in the encoding of the shared
>>>>> secret output from DH for TLS vs pretty much everything else - has to
>>>>> do with the integer to octet string conversion).  Again, not opposed
>>>>> to the naming convention you suggested, just trying to think in meta
>>>>> terms.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> The intent is to reduce potential confusion with the extended
>>>>>> algorithm Strings specifying MGF functions
>>>>>> (<digest>with<encryption>and<mgf>) by using the word "in" for
>>>>>> conjunction and to append "Format" to the format name.
>>>>>>
>>>>>> Would you be ok with this solution?
>>>>>>
>>>>>> Thanks,
>>>>>> Jason
>>>>>>
>>>>>> On 1/29/15 7:27 AM, Sean Mullan wrote:
>>>>>>> On 01/27/2015 05:40 PM, Michael StJohns wrote:
>>>>>>>> So what I'm concerned with is surprise.  I'm also concerned with
>>>>>>>> "default signature formats" from new providers.  Right now, I
>>>>>>>> know if
>>>>>>>> I ask for ECDSA, the output of Signature will be in a very specific
>>>>>>>> format, and the math will match what's in FIPS 186-4, X9.62 and
>>>>>>>> SECG.
>>>>>>>> I'm really uncomfortable about changing that.  I think the
>>>>>>>> algorithm
>>>>>>>> name should map to one specific suite of math and input/output
>>>>>>>> formats.
>>>>>>>
>>>>>>> Yes, your argument makes sense, and we will change the fix to use
>>>>>>> new
>>>>>>> algorithm Strings that specify the P1363 format. Jason will be
>>>>>>> following
>>>>>>> up with more details on that.
>>>>>>>
>>>>>>> Thanks for weighing in on this issue and spending the time to
>>>>>>> explain
>>>>>>> your concerns.
>>>>>>>
>>>>>>> --Sean
>>>>>
>>>>>
>>>>


More information about the security-dev mailing list