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

[Jason Uh]

Thanks for catching that. Here it is with your suggested change:
http://cr.openjdk.java.net/~juh/8042967/03/

Jason

On 02/11/2015 03:42 PM, Xuelei Fan wrote:
> I have not read the update.  Would you please also update:
>      sun/security/util/DisabledAlgorithmConstraints.java
>
> Which uses the algorithm format.
>
>     // <digest>with<encryption>and<mgf>
> +  // <digest>with<encryption>in<format>
>     Pattern pattern =
> -      Pattern.compile("with|and", Pattern.CASE_INSENSITIVE);
> +      Pattern.compile("with|and|in", Pattern.CASE_INSENSITIVE);
>
> Thanks,
> Xuelei
>
> On 2/12/2015 7:18 AM, 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
>>>>
>>>>
>>>
>