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

[Michael StJohns]

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.

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

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.

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