Thanks for catching that. Here it is with your suggested change:
http://cr.openjdk.java.net/~juh/8042967/03/
Jason
On 02/11/2015 03:42 PM, Xuelei Fan wrote:
I have not read the update. Would you please also update:
sun/security/util/DisabledAlgorithmConstraints.java
Which uses the algorithm format.
// <digest>with<encryption>and<mgf>
+ // <digest>with<encryption>in<format>
Pattern pattern =
- Pattern.compile("with|and", Pattern.CASE_INSENSITIVE);
+ Pattern.compile("with|and|in", Pattern.CASE_INSENSITIVE);
Thanks,
Xuelei
On 2/12/2015 7:18 AM, 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
