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

[Sean Mullan]

Hi Jason,

Just a few comments:

* DOMSignatureMethod

- If setParameter throws an exception, I think we should fallback and 
try the old code. This will allow 3rd party JCE providers to continue to 
work until they update their implementations to support the new 
ParameterSpec.

* DSA, ECDSASignature, P11Signature

- engineSetParameter should throw InvalidParameterException if the enum 
is neither ASN1 nor P1363

* SignatureFormatParameterSpec

- can you add a sentence describing what each format is, ex: for ASN.1: 
"An ASN.1 sequence of two INTEGER values: r and s, in that order:
SEQUENCE ::= { r INTEGER, s INTEGER }". For P1363, "an octet-encoding of 
r and s, in that order."

* TestECDSA, TestDSA2

- can you add an @bug 8042967 to each of these tests, since you are 
extending them to test this new format.

- can you also add a test which uses the 
SignatureFormatParameterSpec.ASN1 enum (by passing it to setParameter)?

--Sean

On 01/22/2015 09:46 PM, 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