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

Jason Uh jason.uh at oracle.com
Fri Jan 23 21:12:33 UTC 2015


Hi Sean,

Here is a new webrev with changes addressing all of your comments:
http://cr.openjdk.java.net/~juh/8042967/01/

Thanks,
Jason

On 01/23/2015 10:21 AM, Sean Mullan wrote:
> 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


More information about the security-dev mailing list