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

[Sean Mullan]

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