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

[Sean Mullan]

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