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

[Jason Uh]

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