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
