Looks good.
--Sean
On 02/16/2015 01:53 PM, Jason Uh wrote:
Thanks Sean.
Here it is with your suggested changes:
http://cr.openjdk.java.net/~juh/8042967/04/
Opened an issue to track the docs changes:
https://bugs.openjdk.java.net/browse/JDK-8073261
Jason
On 02/16/2015 10:22 AM, Sean Mullan wrote:
Hi Jason,
Here are my comments -
* General
- please open a corresponding issue to add these new algorithms to the
"Standard Algorithm Names" and "Oracle Providers" security guides. File
in the docs/guides component and add a "securitydocs" label. Please add
a release-notes=yes label to the bug as well.
* DSA.java
- you can move line 215 inside the block starting at line 217.
* ECDSASignature.java
- lines 83-84 can be changed to this(false);
--Sean
On 02/11/2015 06:18 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) by introducing new
algorithm name Strings.
http://cr.openjdk.java.net/~juh/8042967/02/
Thanks,
Jason
On 01/30/2015 02:18 PM, Jason Uh wrote:
Mike,
Thanks again for weighing in. As you're not opposed to the proposal, I
will go ahead and move forward with this plan.
I will put out an updated webrev with the new approach once it is
ready.
Thanks,
Jason
On 1/29/15 3:56 PM, Michael StJohns wrote:
At 03:41 PM 1/29/2015, Jason Uh wrote:
Mike,
Thanks for your feedback.
I'll be changing this fix to introduce new algorithm Strings to
specify the P1363 format. These strings will be of the form:
<digest>with<encryption>in<format>Format
For example:
SHA1withDSAinP1363Format
SHA1withECDSAinP1363Format
Hmm... hadn't gotten that far.
I think that would work, but its not quite right as in this case its
about format, but might be about some other twiddle ( say endianess)
for other specifications. If would be nice if the convention applied
to more than ECDSA and DSA. I'm not opposed to the proposal though.
My counter proposal would be for <algorithm>[/<specification>] as the
naming convention. With the general contract that all implementations
of <algorithm> share the same general math at least for KeyAgreement
and Signature but may not share the same concrete representations or
encodings (e.g. there's difference in the encoding of the shared
secret output from DH for TLS vs pretty much everything else - has to
do with the integer to octet string conversion). Again, not opposed
to the naming convention you suggested, just trying to think in meta
terms.
Mike
The intent is to reduce potential confusion with the extended
algorithm Strings specifying MGF functions
(<digest>with<encryption>and<mgf>) by using the word "in" for
conjunction and to append "Format" to the format name.
Would you be ok with this solution?
Thanks,
Jason
On 1/29/15 7:27 AM, Sean Mullan wrote:
On 01/27/2015 05:40 PM, Michael StJohns wrote:
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.
Yes, your argument makes sense, and we will change the fix to use
new
algorithm Strings that specify the P1363 format. Jason will be
following
up with more details on that.
Thanks for weighing in on this issue and spending the time to
explain
your concerns.
--Sean
