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

[Jason Uh]

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