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

[Michael StJohns]

At 05:42 PM 1/26/2015, 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.


Mostly, the default for the Signature contract is to output things that can immediately be put into the BIT STRING of an ASN1 Signed construct (e.g. to-be-signed body/signature algorithm/signature).  One of the things I've nagged (I think it was) Bret about is how the documentation with respect to the registered algorithm names needs to be tied back to specific standards.  I still think that needs to be done.

X9.62 DOES actually have an ASN1 format (see appendix E).  That format is also specified for the SECG equivalent and in the various ECDSA related RFCs.  FIPS 186-4 just describes the math - it leaves most of the plumbing/formatting to other standards.  Note that it just specifies that the signature is r and s, without giving a concrete representation.

So what I'm concerned with is surprise.  I'm also concerned with "default signature formats" from new providers.  Right now, I know if I ask for ECDSA, the output of Signature will be in a very specific format, and the math will match what's in FIPS 186-4, X9.62 and SECG.  I'm really uncomfortable about changing that.  I think the algorithm name should map to one specific suite of math and input/output formats.


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



For the current problem - it only seems to occur for ECDSA/DSA and I don't think you're going to end up with a lot of the "ECDSAWithP1363Format" stuff.  I also don't like that you're twiddling the model in a way that not all providers will do.   E.g.  I have to explicitly ask for "ECDSA" from the sun provider to ensure that I get an implementation that supports P1363 signature formats.  THAT more than anything else seems to violate the plugin contract.


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

Fair point.

But not really on point here.  If I ask for an ECDSA signature implementation, it should have specific characteristics.  And those characteristics should be pretty much identical regardless of which provider.

I'd rather ask for an ECDSA-p1363 implementation and be told no, rather than having to search through the providers to and ECDSA implementation that also does P1363.

I can always work from the output signature format of ALL current providers and get to P1363 format signatures - yes, additional work, but no surprises and no special coding necessary to get to the right provider.

Mike




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