Re: DSA default algorithm for keytool -genkeypair. Bad choice?
For one, it makes the user specify what they want, perhaps learning about certificates and making an educated choice. Secondly, and more importantly, it would not making it our decisions what is a default secure algorithm for all of java. Tony On 10/10/2018 06:33 PM, Weijun Wang wrote: I don't know what benefit it brings to a user to remove the default. Except from forcing DSA users to add a -keyalg option, RSA and EC users will not gain anything. --Max On Oct 11, 2018, at 5:05 AM, Anthony Scarpino wrote: On 10/10/2018 07:42 AM, Weijun Wang wrote: On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). --Max I would rather get rid of the default completely. I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. Tony
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
I don't know what benefit it brings to a user to remove the default. Except from forcing DSA users to add a -keyalg option, RSA and EC users will not gain anything. --Max > On Oct 11, 2018, at 5:05 AM, Anthony Scarpino > wrote: > > On 10/10/2018 07:42 AM, Weijun Wang wrote: >>> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >>> >>> There is really no other reason other than DSA keys have been the default >>> keypairs generated by keytool for a long time, so there are some >>> compatibility issues we would have to think through before changing it to >>> another algorithm such as RSA. Weijun might have more insight into that. >> Not really. It was the default before I join Sun Microsystems many many >> years ago. Maybe it was a NIST standard? >> As for compatibility, as long as someone is still using DSA then they might >> not be specifying the -keyalg option. >> If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if >> RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an >> option to specify ECCurve in keytool yet (a string -keysize). >> --Max > > > I would rather get rid of the default completely. > > I realize there maybe scripting issues with that. If we made some > documentation guarantees a default algorithm then maybe we are stuck with > having a default and can use a security property. A part of me thinks it > would be foolish for an application to assume a default algorithm and may > deserve to be broken so they can fix it. > > Even if we didn't remove defaults from older java version, in future releases > it would be nice to eliminate defaults were possible. > > With regard to a replacement, I'd prefer over EC than RSA given a choice. > But either is ok. > > Tony
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
It might not apply to this specific default but in the past DSA was often chosen (over RSA) as a default as it was regarded as less suspicious to been understood as an encryption capable algorithm (as opposed to RSA). But of course that thinking was never correct and the justification for interpreting crypto law is also gone. Not having a default is actually a good idea Gruss Bernd -- http://bernd.eckenfels.net Von: security-dev on behalf of Anthony Scarpino Gesendet: Mittwoch, Oktober 10, 2018 11:18 PM An: security-dev@openjdk.java.net Betreff: Re: DSA default algorithm for keytool -genkeypair. Bad choice? On 10/10/2018 07:42 AM, Weijun Wang wrote: > > >> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: >> >> There is really no other reason other than DSA keys have been the default >> keypairs generated by keytool for a long time, so there are some >> compatibility issues we would have to think through before changing it to >> another algorithm such as RSA. Weijun might have more insight into that. > > Not really. It was the default before I join Sun Microsystems many many years > ago. Maybe it was a NIST standard? > > As for compatibility, as long as someone is still using DSA then they might > not be specifying the -keyalg option. > > If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if > RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an > option to specify ECCurve in keytool yet (a string -keysize). > > --Max > > I would rather get rid of the default completely. I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. Tony
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
On 10/10/2018 07:42 AM, Weijun Wang wrote: On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). --Max I would rather get rid of the default completely. I realize there maybe scripting issues with that. If we made some documentation guarantees a default algorithm then maybe we are stuck with having a default and can use a security property. A part of me thinks it would be foolish for an application to assume a default algorithm and may deserve to be broken so they can fix it. Even if we didn't remove defaults from older java version, in future releases it would be nice to eliminate defaults were possible. With regard to a replacement, I'd prefer over EC than RSA given a choice. But either is ok. Tony
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
On 10/10/2018 10:42 AM, Weijun Wang wrote: On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? us government FIPS. It still is. But mostly US gov't is doing EC these days... at least until all the quantum fear and doubt started creeping in. As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). I'm away from the source code - but isn't it possible to configure the default in java.security? Maybe what you is add a warning of the new default unless disabled in java.security or explicitly set there? Mike --Max
Re: RFR 8076190: Customizing the generation of a PKCS12 keystore
On Wed, Oct 10, 2018 at 3:10 AM, Weijun Wang wrote: > > > > On Oct 10, 2018, at 1:07 AM, Martin Buchholz > wrote: > > > > Seems alright to this non-crypto expert. > > > > The key thing I would like to see working is: > > > > If I create a keystore for cacerts and then use it via > -with-cacerts-file taking the defaults, this results in goodness (which > presumably means not getting JKS keystore) > > I haven't tried this configure option before, but does it mean just copy > your own file to lib/security/cacerts? > My own mental model of -with-cacerts-file is that it effectively copies the file to replace java.base/share/lib/security/cacerts. Currently, to explore this file you need to know to use JKS and learn about the "well-known" password (where is this documented??) > Then you need to make it correct, i.e. a JKS file, or a password-less > pkcs12 file, or with-password pkcs12 but you set the correct storepass (TLS > system property?). > > > > > Make sure keystore creators don't have to specify a storepass. > > If you want to create a password-less pkcs12 file, you will need to > specify those system properties (certProtectionAlgorithm and macAlgorithm > to NONE). Then I'll make sure there is no need to specify a storepass. > Because we're trying to replace a data file that already comes with the JDK, we'll always prefer to use exactly the same format and password (or lack thereof). If and when openjdk comes with a password-less pkcs12 file, we will switch as well.
Re: RFR [12]: 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html
Looks good to me. -- Jon On 10/10/18 9:33 AM, Sean Mullan wrote: Please review this trivial fix to correct a couple of broken hyperlinks: diff --git a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java --- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java +++ b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -144,7 +144,7 @@ /** * Returns the dereferenced data, if - * reference caching + * reference caching * is enabled. This is the result of dereferencing the URI of this * reference during a validation or generation operation. * @@ -156,7 +156,7 @@ /** * Returns the pre-digested input stream, if - * reference caching + * reference caching * is enabled. This is the input to the digest operation during a * validation or signing operation. * Thanks, Sean
RFR [12]: 8211878: Bad/broken links in docs/api/java.xml.crypto/javax/xml/crypto/dsig/Reference.html
Please review this trivial fix to correct a couple of broken hyperlinks: diff --git a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java --- a/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java +++ b/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/Reference.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -144,7 +144,7 @@ /** * Returns the dereferenced data, if - * reference caching + * reference caching * is enabled. This is the result of dereferencing the URI of this * reference during a validation or generation operation. * @@ -156,7 +156,7 @@ /** * Returns the pre-digested input stream, if - * reference caching + * reference caching * is enabled. This is the input to the digest operation during a * validation or signing operation. * Thanks, Sean
Re: RFR: 8209862:CipherCore performance improvement
Thanks for the review Adam. I've corrected those style issues.
Now waiting on 2nd Reviewer.
Regards,
Sean.
On 08/10/18 19:18, Adam Petcher wrote:
The organization is better now, thanks. The code looks good to me, but
I would like to request another review from Tony (or someone else who
is familiar with this code) before you push. There is a lot of
complexity here, and it is hard for me to be sure that everything will
behave the same after the change. It will be helpful to have another
person examine the new code to ensure that it is correct.
Minor style issues(addressing them is optional):
Lines 848, 915, and 969 are longer than 80 characters
Line 1075: no space before ? character
On 10/2/2018 1:51 PM, Seán Coffey wrote:
Good points from Adam and Tony. I've taken them both on board. Sergey
has already eliminated a lot of duplicate code but there was further
optimizing possible in the two doFinal(..) methods. I've introduced a
new 'fillOutputBuffer' method to help. Please review :
https://cr.openjdk.java.net/~coffeys/webrev.8209862.v2/webrev/
regards,
Sean.
On 01/10/2018 15:32, Adam Petcher wrote:
Looks like a nice improvement, but is it possible to do this without
duplicating code? For example, code almost identical to this also
appears starting on line 860:
971 } else { // encrypting
972 try {
973 outLen = finalNoPadding(finalBuf, finalOffset, output,
974 outputOffset, finalBufLen);
975 } finally {
976 // reset after doFinal() for GCM encryption
977 requireReinit = (cipherMode == GCM_MODE);
978 if (finalBuf != input) {
979 // done with internal finalBuf array. Copied to output
980 Arrays.fill(finalBuf, (byte) 0x00);
981 }
982 }
983 }
It may be possible to factor out the entire if/else statement and
some of the code around it into a separate method and do the short
buffer check and save/restore around it. Ideally, each doFinal
method would have only a small amount of code to either allocate the
array or check array lengths, and then they would call the same
private method to do most of the work.
I would suggest a noreg-sqe label on the ticket to document that
existing regression tests are used to ensure correctness of the
modified code.
Minor code style comments: check for long lines (e.g. line 856) and
missing spaces after commas in actual parameter lists (also e.g.
line 856). Also, line 1076 is missing space around the '?' and ':'
characters. I can check the code again and give you the complete
list after we sort out the code duplication.
On 10/1/2018 9:11 AM, Seán Coffey wrote:
JDK-8207775 introduced some performance regressions in the
ciphercore area. Sergey Kuksenko has been looking at this and has
contributed the following patch:
http://cr.openjdk.java.net/~skuksenko/crypto/8209862/
bug report : https://bugs.openjdk.java.net/browse/JDK-8209862
I've been reviewing it and ran functionality and TCK testing.
Didn't see any issues. Sergey has also confirmed that the patch
helps to alleviate the performance issues introduced. More details
regards approach for fix are in the bug description.
Thanks Sergey! I'm looking for another review from security team.
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
> On Oct 10, 2018, at 7:59 PM, Sean Mullan wrote: > > There is really no other reason other than DSA keys have been the default > keypairs generated by keytool for a long time, so there are some > compatibility issues we would have to think through before changing it to > another algorithm such as RSA. Weijun might have more insight into that. Not really. It was the default before I join Sun Microsystems many many years ago. Maybe it was a NIST standard? As for compatibility, as long as someone is still using DSA then they might not be specifying the -keyalg option. If not DSA, should RSA be the new default? Or maybe RSASSA-PSS (I wonder if RSASSA-PSS signature can always use legacy RSA keys) or EC? We don't have an option to specify ECCurve in keytool yet (a string -keysize). --Max
Re: RFR 8211969: test/jdk/lib/security/CheckBlacklistedCerts.java searching for wrong paths
Looks good to me. --Sean On 10/9/18 8:21 PM, Weijun Wang wrote: Please review the fix at http://cr.openjdk.java.net/~weijun/8211969/webrev.00/ The wrong path was never noticed because we ignore missing files. Now that we only look for the open one and it should always be there, we will not ignore it. There won't be such an error again. Thanks Max
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
Hi Sean, On Wed, 2018-10-10 at 07:59 -0400, Sean Mullan wrote: > On 10/10/18 6:23 AM, Severin Gehwolf wrote: > > Hi, > > > > What is the rationale of using DSA keys (2048 bit) as default for > > genkeypair command? > > http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 > > There is really no other reason other than DSA keys have been the > default keypairs generated by keytool for a long time, so there are some > compatibility issues we would have to think through before changing it > to another algorithm such as RSA. Weijun might have more insight into that. > > It seems a bad choice given that DSA keys are disabled via Fedora's > > crypto policy (not just OpenJDK, but other crypto providers too). > > Actually, only DSA keys < 1024-bit are disabled by default in OpenJDK. Thanks. I should have perhaps clarified. Not sure whether that was clear. In Fedora a global crypto policy is in place. The policy affects OpenSSL, GnuTLS, (patched) OpenJDK etc. It's that global policy which disables DSA unconditionally. > > Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] > > as to why that's a bad choice: > > > > """ > > DSA is not used by new security protocols any more (doesn't exist as a > > negotiation option under TLS1.3), and was a very rarely used option > > under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is > > documented under these protocols. DSA-2048 may or may not work > > depending on the implementation (and even worse may not interoperate). > > """ > > > > Could the default choice of keyalg for genkeypair be reconsidered? > > Yes, I think it should be considered since DSA is rarely used anymore > and not supported by newer security protocols such as TLS 1.3. I have > filed: https://bugs.openjdk.java.net/browse/JDK-8212003 Great, thanks! Cheers, Severin > --Sean > > > If not, why not? > > > > Thanks, > > Severin > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253 > >
Re: JGSS Enhancements (contribution by Two Sigma Open Source)
On 10/10/18 8:06 AM, Alan Bateman wrote: On 09/10/2018 21:55, Nico Williams wrote: On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: On 10/9/18 4:04 PM, Nico Williams wrote: In order to file a bug or post a patch, you need to be an author first. Read here:http://openjdk.java.net/projects/#project-author. So it seems I need to send email to the project lead for... security? And per-the census that would be Sean Mullan. No email address is given, but I guess it must be @openjdk.java.net, yes? I'll try it. Yes, that's me, but first you need to have at least two of your contributions reviewed and pushed. Max will help you with that, and once that is done, I can grant you the Author role. OK, that was not clear, neither was it how to find your email address. Actually, it's Project Lead that grants Author role. Mark Reinhold is the Project Lead for the jdk project. Once you at least two sponsored contributions then I assume Sean will request it on you, esp. when there is a pipeline of patches and interest in maintaining this area. Right, sorry about that, and thanks for the correction. I misread "Project Lead" as "Group Lead" when I was looking at your email and the guidelines yesterday. --Sean
Re: JGSS Enhancements (contribution by Two Sigma Open Source)
On 09/10/2018 21:55, Nico Williams wrote: On Tue, Oct 09, 2018 at 04:31:07PM -0400, Sean Mullan wrote: On 10/9/18 4:04 PM, Nico Williams wrote: In order to file a bug or post a patch, you need to be an author first. Read here:http://openjdk.java.net/projects/#project-author. So it seems I need to send email to the project lead for... security? And per-the census that would be Sean Mullan. No email address is given, but I guess it must be @openjdk.java.net, yes? I'll try it. Yes, that's me, but first you need to have at least two of your contributions reviewed and pushed. Max will help you with that, and once that is done, I can grant you the Author role. OK, that was not clear, neither was it how to find your email address. Actually, it's Project Lead that grants Author role. Mark Reinhold is the Project Lead for the jdk project. Once you at least two sponsored contributions then I assume Sean will request it on you, esp. when there is a pipeline of patches and interest in maintaining this area. -Alan
Re: DSA default algorithm for keytool -genkeypair. Bad choice?
On 10/10/18 6:23 AM, Severin Gehwolf wrote: Hi, What is the rationale of using DSA keys (2048 bit) as default for genkeypair command? http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 There is really no other reason other than DSA keys have been the default keypairs generated by keytool for a long time, so there are some compatibility issues we would have to think through before changing it to another algorithm such as RSA. Weijun might have more insight into that. It seems a bad choice given that DSA keys are disabled via Fedora's crypto policy (not just OpenJDK, but other crypto providers too). Actually, only DSA keys < 1024-bit are disabled by default in OpenJDK. Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] as to why that's a bad choice: """ DSA is not used by new security protocols any more (doesn't exist as a negotiation option under TLS1.3), and was a very rarely used option under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is documented under these protocols. DSA-2048 may or may not work depending on the implementation (and even worse may not interoperate). """ Could the default choice of keyalg for genkeypair be reconsidered? Yes, I think it should be considered since DSA is rarely used anymore and not supported by newer security protocols such as TLS 1.3. I have filed: https://bugs.openjdk.java.net/browse/JDK-8212003 --Sean If not, why not? Thanks, Severin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253
DSA default algorithm for keytool -genkeypair. Bad choice?
Hi, What is the rationale of using DSA keys (2048 bit) as default for genkeypair command? http://hg.openjdk.java.net/jdk/jdk/file/c4a39588a075/src/java.base/share/classes/sun/security/tools/keytool/Main.java#l1120 It seems a bad choice given that DSA keys are disabled via Fedora's crypto policy (not just OpenJDK, but other crypto providers too). Here the explanation from Nikos Mavrogiannopoulos from a Fedora bug[1] as to why that's a bad choice: """ DSA is not used by new security protocols any more (doesn't exist as a negotiation option under TLS1.3), and was a very rarely used option under previous protocols (TLS1.2 or earlier). In fact only DSA-1024 is documented under these protocols. DSA-2048 may or may not work depending on the implementation (and even worse may not interoperate). """ Could the default choice of keyalg for genkeypair be reconsidered? If not, why not? Thanks, Severin [1] https://bugzilla.redhat.com/show_bug.cgi?id=1582253
Re: RFR 8076190: Customizing the generation of a PKCS12 keystore
> On Oct 10, 2018, at 1:07 AM, Martin Buchholz wrote:
>
> Seems alright to this non-crypto expert.
>
> The key thing I would like to see working is:
>
> If I create a keystore for cacerts and then use it via -with-cacerts-file
> taking the defaults, this results in goodness (which presumably means not
> getting JKS keystore)
I haven't tried this configure option before, but does it mean just copy your
own file to lib/security/cacerts?
Then you need to make it correct, i.e. a JKS file, or a password-less pkcs12
file, or with-password pkcs12 but you set the correct storepass (TLS system
property?).
>
> Make sure keystore creators don't have to specify a storepass.
If you want to create a password-less pkcs12 file, you will need to specify
those system properties (certProtectionAlgorithm and macAlgorithm to NONE).
Then I'll make sure there is no need to specify a storepass.
Thanks
Max
>
> On Mon, Oct 8, 2018 at 8:26 AM, Weijun Wang wrote:
> CSR updated. Please take a review.
>
>https://bugs.openjdk.java.net/browse/JDK-8202590
>
> A slightly updated webrev at
>
>https://cr.openjdk.java.net/~weijun/8076190/webrev.05
>
> Thanks
> Max
>
> > On Oct 3, 2018, at 12:51 AM, Sean Mullan wrote:
> >
> > On 10/1/18 8:02 PM, Weijun Wang wrote:
> >>
> >>
> >>> On Oct 2, 2018, at 2:49 AM, Sean Mullan wrote:
> >>>
> >>> Looks good. After you update the CSR with these changes, I can review it.
> >>
> >> Sure.
> >>
> >> How do you think of the following change? Shall I also add it?
> >
> > Yes.
> >>
> >> diff --git a/src/java.base/share/classes/java/security/KeyStore.java
> >> b/src/java.base/share/classes/java/security/KeyStore.java
> >> --- a/src/java.base/share/classes/java/security/KeyStore.java
> >> +++ b/src/java.base/share/classes/java/security/KeyStore.java
> >> @@ -318,7 +318,7 @@
> >> * for a given keystore type is set using the
> >> * {@code 'keystore..keyProtectionAlgorithm'} security
> >> property.
> >> * For example, the
> >> - * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores
> >> the
> >> + * {@code keystore.pkcs12.keyProtectionAlgorithm} property stores
> >> the
> >> * name of the default key protection algorithm used for PKCS12
> >> * keystores. If the security property is not set, an
> >> * implementation-specific algorithm will be used.
> >>
> >> Shall I add some word to this method saying we should use lowercase or are
> >> we going to live with this lower+UPPER for every keystore type forever?
> > No. Let's just continue to check in the code for both variants of the above
> > property, but remove all references to the upper-case variant from the
> > javadocs and java.security file.
> >
> > --Sean
> >>
> >> If yes, there will also be some text for its compatibility risk.
> >>
> >> Thanks
> >> Max
> >>
> >>>
> >>> --Sean
> >>>
> >>> On 9/28/18 9:36 AM, Weijun Wang wrote:
> Webrev updated at
> http://cr.openjdk.java.net/~weijun/8076190/webrev.04/
> Major changes:
> 1. Comment out key=value lines in java.security
> 2. Fix a bug in PBES2Parameters.java
> 3. Test no longer depends on openssl. Instead, use openssl to generate
> some pkcs12 files and included in the test.
> 4. A new test KeyProtAlgCompat.java to ensure compatibility on
> pkcs12/PKCS12 names
> I haven't made any change to KeyStore.java yet. CSR is also not updated.
> Thanks
> Max
> >>
> >>
>
>
