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

[Sean Mullan]

I thought a bit more about this and I think you have a good point.

If other new Signature algorithms are added that require parameters, 
then this design won't work, because setParameter is only supposed to be 
called once. For example, I can't do this:

sig.setParameter(SignatureFormatParameterSpec.P1363);
sig.setParameter(curve2519Params);

We shall rethink this and see if we can come up with a better design. 
Thanks for reviewing this.

--Sean

On 01/26/2015 05:42 PM, Sean Mullan wrote:
> On 01/25/2015 11:15 PM, Michael StJohns wrote:
>> Sorry - I missed this the first time around....  I think this may not
>> be the right approach...
>>
>> I'm concerned with trying to overload ECDSA and DSA which have always
>> had relationships with very specific specifications and trying to
>> make them also cover P1363.
>
> Are you more concerned with existing implementations? I'm curious
> because FIPS 186-3 does not (AFAICT) require that the signature bytes be
> formatted using ASN.1 DER. Also, some other standards require the P1363
> format (like XML Signature) and other prominent crypto libraries (I
> think at least MSCrypto and JSS) encode in P1363.
>
>> A better approach may be to create two new Signature plugins (with
>> new registered names):  ECDSA-P1363 and DSA-P1363 which do those
>> specific signature formats rather than overloading the current
>> meanings. (I mention this, because its possible that ECDSA-Curve25519
>> is on the way and it has yet a different set of things going on).
>
> We had originally considered that as an alternative solution. There were
> some concerns (communicated internally) that this was not a good
> solution because the encoding format would not be as apparent, and it
> was a bit ugly to stuff this into an algorithm name String (you have
> many variants, so you would need to do something like
> "<digest>With<encryption>And<blah>Format", and thus you end up with a
> multitude of algorithms Strings that need to be supported in your
> providers to cover all the variants. I think we are open to revisiting
> that solution but I would like to hear a bit more about your concerns.
>
>> If you don't want to do that, then I have to ask whether this the
>> right place to implement the fix?  Why wouldn't you implement this at
>> the java.security.Signature code?  My reasoning is that you've fixed
>> it for the packaged provider, but not for other providers.  If you
>> did the signature reformatting in Signature, you would be able to
>> "fix" the other providers as well.
>
> That doesn't solve the problem nicely, because then you would have to
> strip the ASN.1 DER encoding to convert to P1363 format (and
> vice-versa), which is basically what toolkits/libraries are forced to do
> today. This solution allows the provider to return the formatted bytes
> in the requested form without any need or overhead for additional
> re-formatting.
>
> --Sean
>
>>
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> At 09:46 PM 1/22/2015, Jason Uh wrote:
>>> Please review this change, which enables DSA and ECDSA signatures
>>> in the IEEE P1363 format (the concatenation of r and s).
>>>
>>> This is accomplished through an implementation of
>>> AlgorithmParameterSpec, SignatureFormatParameterSpec, which can be
>>> passed to the existing Signature.setParameter() method before
>>> signing or verifying a signature to indicate the desired signature
>>> format.
>>>
>>> webrev: http://cr.openjdk.java.net/~juh/8042967/00/ bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8042967
>>>
>>> Thanks, Jason
>>
>>