From sibabrata.sahoo at oracle.com Mon Apr 2 08:07:55 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 2 Apr 2018 01:07:55 -0700 (PDT) Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> Message-ID: Hi Sean, My comments In-lined.. Thanks, Siba -----Original Message----- From: Sean Mullan Sent: Saturday, March 31, 2018 12:13 AM To: Sibabrata Sahoo ; Adam Petcher ; security-dev at openjdk.java.net Subject: Re: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 A few comments so far; have not finished my review yet. General comment: Many of these tests test more than XDH. That is fine and good for increasing coverage, but have you looked through existing tests to see if you are duplicating anything we are already testing and maybe those tests could be removed or you could share the same code. One of the things we should be looking at is to figure out how to reduce the overall time the security tests take. There are few Lines of code related to " DiffieHellman " are duplicate in KeyAgreementTest.java and KeySizeTest.java which are available in 2 existing Test folders. i.e. "open\test\jdk\sun\security\pkcs11\KeyAgreement" and "open\test\jdk\com\sun\crypto\provider\KeyAgreement". While there is no equivalent Tests for the same for "ECDH" and "XDH". The remaining files available in the webrev are mostly new. Our initial thinking was to have Test files covering all similar algorithms in one place. In that case I may remove 2-3 existing Test files inside these folders with next patch. * KeyAgreementTest.java 128 // Uses platform supported provider to test interoperability. What do you mean by "platform supported provider"? Isn't this based on the provider search order? So in some cases, you might be testing against the same provider and not really doing interop testing? Yes my thinking here is Provider search order. I may need to change the comment appropriately. Here the intention is not really interop based Test unless a different provider found other than SunJCE. * KeySizeTest.java You are generating some large keys - any issues with test timeouts? Do we need to test the generation of the keypairs? Could we use cached keypairs instead? Yes here my intention is to test generation of keypairs with different key sizes too. I have ran these Test files several times. I have not seen these test files taking more times than few couple of seconds. --Sean On 3/26/18 12:38 PM, Sibabrata Sahoo wrote: > Hi, > > Please review the patch for, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 > > Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ > > All the Test files uses KeyAgreement, KeyPairGenerator, Several > KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with > curve25519 and curve448 algorithms. Each Test files try to address > several cases and the purpose of each has been commented in their own files. > > Thanks, > > Siba > From sha.jiang at oracle.com Mon Apr 2 13:18:12 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 2 Apr 2018 21:18:12 +0800 Subject: RFR JDK-8200403: javax/net/ssl/sanity/interop/ClientJSSEServerJSSE.java needs to clarify the relation between cipher suites and protocols Message-ID: <31da258d-c91b-3daa-269a-564ea3f00b5c@oracle.com> Hi, This fix introduces a couple of common classes, such as CipherSuite.java and Protocol.java, to indicate the relation between cipher suites and SSL/TLS protocols clearly. It would be easier to add cases for new cipher suites and protocols with this fix. It also improves some logic on filtering test cases. Webrev: http://cr.openjdk.java.net/~jjiang/8200403/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8200403 Best regards, John Jiang From sean.mullan at oracle.com Tue Apr 3 16:10:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 3 Apr 2018 12:10:37 -0400 Subject: [11] RFR: 8187218: GSSCredential.getRemainingLifetime() returns negative value for TTL > 24 days. In-Reply-To: <01d3ab48-daf2-450b-ba72-4b33f26d6696@default> References: <01d3ab48-daf2-450b-ba72-4b33f26d6696@default> Message-ID: <3c9dd337-d410-6453-6df4-7d55cd03910f@oracle.com> Looks fine to me. --Sean On 3/30/18 2:29 AM, Prasadrao Koppula wrote: > Hi, > > Can I please have a review for this fix? > > Thanks, > Prasad.K > > *From:* Prasadrao Koppula > *Sent:* Tuesday, March 20, 2018 3:46 PM > *To:* security-dev at openjdk.java.net > *Subject:* [11] RFR: 8187218: GSSCredential.getRemainingLifetime() > returns negative value for TTL > 24 days. > > Could you please review the changes > > Webrev: http://cr.openjdk.java.net/~pkoppula/8187218/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8187218 > > The tests was contributed by Weijun Wang. > > Thanks, > > Prasad.K > From amanda.jiang at oracle.com Tue Apr 3 20:12:41 2018 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 3 Apr 2018 13:12:41 -0700 Subject: RFR 8190333: sun/security/ssl/X509KeyManager/PreferredKey.java failed with "Failed to get the preferable key aliases" Message-ID: <3f7d8936-2cee-861d-ca52-9fb522bb0e34@oracle.com> Hi All, The changeset below updates an expired alias in keystore. Please help to review it. Bug: https://bugs.openjdk.java.net/browse/JDK-8190333 Webrev: http://cr.openjdk.java.net/~amjiang/8190333/webrev.00/ Thanks, Amanda From weijun.wang at oracle.com Wed Apr 4 02:19:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 Apr 2018 10:19:46 +0800 Subject: RFR 8200468: Port the native GSS-API bridge to Windows Message-ID: Hi All Please take a review at http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... You can manually test the change with jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java Thanks Max p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. From magnus.ihse.bursie at oracle.com Wed Apr 4 07:59:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 4 Apr 2018 09:59:28 +0200 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: Hi Max, On 2018-04-04 04:19, Weijun Wang wrote: > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html Please always cc build-dev when making changes to makefiles. /Magnus > > Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: > > java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... > > You can manually test the change with > > jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java > > Thanks > Max > > p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. From weijun.wang at oracle.com Wed Apr 4 08:17:10 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 Apr 2018 16:17:10 +0800 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: <5C07D2E2-AD4A-45C7-8FE1-77F26D7BA28E@oracle.com> I've updated the patch in its original URL. Please confirm it's correct now. Thanks Max > On Apr 4, 2018, at 4:06 PM, Weijun Wang wrote: > > > >> On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie wrote: >> >> Hi Max, >> >> On 2018-04-04 04:19, Weijun Wang wrote: >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ >> >> The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html > > So this is for "2. If a line must be broken, use four spaces for indentation". Right? > >> >> Please always cc build-dev when making changes to makefiles. > > I'll remember it. > > Thanks > Max > >> >> /Magnus >> >> >> >> >> >>> >>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: >>> >>> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... >>> >>> You can manually test the change with >>> >>> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java >>> >>> Thanks >>> Max >>> >>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. >> > From weijun.wang at oracle.com Wed Apr 4 08:06:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 4 Apr 2018 16:06:40 +0800 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: > On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie wrote: > > Hi Max, > > On 2018-04-04 04:19, Weijun Wang wrote: >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ > > The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html So this is for "2. If a line must be broken, use four spaces for indentation". Right? > > Please always cc build-dev when making changes to makefiles. I'll remember it. Thanks Max > > /Magnus > > > > > >> >> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: >> >> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... >> >> You can manually test the change with >> >> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java >> >> Thanks >> Max >> >> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. > From bhanu.prakash.gopularam at oracle.com Wed Apr 4 08:38:30 2018 From: bhanu.prakash.gopularam at oracle.com (bhanu.prakash.gopularam at oracle.com) Date: Wed, 4 Apr 2018 14:08:30 +0530 Subject: RFR 8196540: [Testbug] java/security/AccessController/DoPrivAccompliceTest.java doesn't handle unrelated warnings Message-ID: Hi All, Please review fix for following issue: JBS bug: https://bugs.openjdk.java.net/browse/JDK-8196540 webrev link: http://cr.openjdk.java.net/~bgopularam/8196540/security/webrev.00/ I have added utility method parsing the stderr output and ignore any VM warnings. Thanks, Bhanu From magnus.ihse.bursie at oracle.com Wed Apr 4 10:00:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 4 Apr 2018 12:00:25 +0200 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: On 2018-04-04 10:06, Weijun Wang wrote: > >> On Apr 4, 2018, at 3:59 PM, Magnus Ihse Bursie wrote: >> >> Hi Max, >> >> On 2018-04-04 04:19, Weijun Wang wrote: >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ >> The indentation in Lib-java.security.jgss.gmk has gone wrong. The lines in the "$(eval $(call SetupJdkLibrary" stanza should still be indented four spaces. See the makefile style guide: http://openjdk.java.net/groups/build/doc/code-conventions.html > So this is for "2. If a line must be broken, use four spaces for indentation". Right? Yes. 2 spaces for "logical" indentations (such as in an if statement), and 4 spaces for broken lines. > >> Please always cc build-dev when making changes to makefiles. > I'll remember it. Thanks! /Magnus > > Thanks > Max > >> /Magnus >> >> >> >> >> >>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: >>> >>> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... >>> >>> You can manually test the change with >>> >>> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java >>> >>> Thanks >>> Max >>> >>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. From sean.mullan at oracle.com Wed Apr 4 15:11:54 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 4 Apr 2018 11:11:54 -0400 Subject: RFR 8190333: sun/security/ssl/X509KeyManager/PreferredKey.java failed with "Failed to get the preferable key aliases" In-Reply-To: <3f7d8936-2cee-861d-ca52-9fb522bb0e34@oracle.com> References: <3f7d8936-2cee-861d-ca52-9fb522bb0e34@oracle.com> Message-ID: <593530c8-a9c0-580c-cc8f-359a43878e85@oracle.com> I think you should use a 2048-bit DSA key instead of 1024-bit. Otherwise looks fine. --Sean On 4/3/18 4:12 PM, Amanda Jiang wrote: > Hi All, > > The changeset below updates an expired alias in keystore. Please help to > review it. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190333 > Webrev: http://cr.openjdk.java.net/~amjiang/8190333/webrev.00/ > Thanks, > Amanda From sean.mullan at oracle.com Wed Apr 4 18:11:30 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 4 Apr 2018 14:11:30 -0400 Subject: JEP 332: Transport Layer Security (TLS) 1.3 In-Reply-To: References: <20180330163611.41C131975DE@eggemoggin.niobe.net> Message-ID: <7e6a0331-5769-56a8-afbc-52877c553553@oracle.com> On 3/30/18 12:48 PM, David Lloyd wrote: > Is it possible that this could make Java 11, or is that a long shot? We cannot say that it will make JDK 11 at this time. Also, at this stage in the JEP 2.0 Process, a Candidate means that it "is merely an idea worthy of consideration by JDK Release Projects and related efforts; there is no commitment that it will be delivered in any particular release." [1] With that said, TLS 1.3 is expected to be an important security feature and we are working as hard as we can to deliver it in a timely manner. We have already sent out a preliminary code review on a redesigned handshaking implementation [2]. We should have more information on the overall status of the project over the next few weeks, so stay tuned. Thanks, Sean [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html > > On Fri, Mar 30, 2018 at 11:36 AM, wrote: >> New JEP Candidate: http://openjdk.java.net/jeps/332 >> >> - Mark From sean.mullan at oracle.com Thu Apr 5 15:16:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 5 Apr 2018 11:16:09 -0400 Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> Message-ID: Comments below ... On 4/2/18 4:07 AM, Sibabrata Sahoo wrote: > Hi Sean, > > My comments In-lined.. > > Thanks, > Siba > > -----Original Message----- > From: Sean Mullan > Sent: Saturday, March 31, 2018 12:13 AM > To: Sibabrata Sahoo ; Adam Petcher ; security-dev at openjdk.java.net > Subject: Re: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 > > A few comments so far; have not finished my review yet. > > General comment: > > Many of these tests test more than XDH. That is fine and good for increasing coverage, but have you looked through existing tests to see if you are duplicating anything we are already testing and maybe those tests could be removed or you could share the same code. One of the things we should be looking at is to figure out how to reduce the overall time the security tests take. > > There are few Lines of code related to " DiffieHellman " are duplicate in KeyAgreementTest.java and KeySizeTest.java which are available in 2 existing Test folders. i.e. "open\test\jdk\sun\security\pkcs11\KeyAgreement" and "open\test\jdk\com\sun\crypto\provider\KeyAgreement". While there is no equivalent Tests for the same for "ECDH" and "XDH". The remaining files available in the webrev are mostly new. Our initial thinking was to have Test files covering all similar algorithms in one place. In that case I may remove 2-3 existing Test files inside these folders with next patch. Ok. > * KeyAgreementTest.java > > 128 // Uses platform supported provider to test interoperability. > > What do you mean by "platform supported provider"? Isn't this based on the provider search order? So in some cases, you might be testing against the same provider and not really doing interop testing? > > Yes my thinking here is Provider search order. I may need to change the comment appropriately. Here the intention is not really interop based Test unless a different provider found other than SunJCE. Ok. > > * KeySizeTest.java > > You are generating some large keys - any issues with test timeouts? Do we need to test the generation of the keypairs? Could we use cached keypairs instead? > > Yes here my intention is to test generation of keypairs with different key sizes too. I have ran these Test files several times. I have not seen these test files taking more times than few couple of seconds. Ok. I looked at the other tests and have no further comments. Thanks, Sean > On 3/26/18 12:38 PM, Sibabrata Sahoo wrote: >> Hi, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ >> >> All the Test files uses KeyAgreement, KeyPairGenerator, Several >> KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with >> curve25519 and curve448 algorithms. Each Test files try to address >> several cases and the purpose of each has been commented in their own files. >> >> Thanks, >> >> Siba >> From sean.mullan at oracle.com Thu Apr 5 18:37:07 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 5 Apr 2018 14:37:07 -0400 Subject: RFR 8196540: [Testbug] java/security/AccessController/DoPrivAccompliceTest.java doesn't handle unrelated warnings In-Reply-To: References: Message-ID: <8bc0bb8f-7dd8-2888-fde4-c903174aa2c2@oracle.com> The 2 space indentation in some of the methods of OutputAnalyzer.java is unconventional. I would fix those methods to use 4 spaces. Looks fine otherwise. --Sean On 4/4/18 4:38 AM, bhanu.prakash.gopularam at oracle.com wrote: > Hi All, > > Please review fix for following issue: > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8196540 > > webrev link: > http://cr.openjdk.java.net/~bgopularam/8196540/security/webrev.00/ > > I have added utility method parsing the stderr output and ignore any VM > warnings. > > Thanks, > Bhanu From jottofar at redhat.com Fri Apr 6 14:19:39 2018 From: jottofar at redhat.com (Jack Ottofaro) Date: Fri, 6 Apr 2018 10:19:39 -0400 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider Message-ID: Hi Valerie, I have an important customer awaiting this change. Can you please provide a status update as to the progress of this effort and any information available as to when it may be completed. Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Sun Apr 8 02:08:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 8 Apr 2018 10:08:13 +0800 Subject: RFR 8200792: PKCS12Attribute#hashCode is always constant -1 Message-ID: Please take a review at http://cr.openjdk.java.net/~weijun/8200792/webrev.00/ The fix is trivial, but it's also trivial to write a test, so I added one. Thanks Max From weijun.wang at oracle.com Sun Apr 8 02:34:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 8 Apr 2018 10:34:54 +0800 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> Message-ID: Ping again. > On Mar 23, 2018, at 11:04 AM, Weijun Wang wrote: > > Please take a review of the code change and CSR at > > CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 > webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ > > Thanks > Max > From xuelei.fan at oracle.com Sun Apr 8 02:53:35 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 7 Apr 2018 19:53:35 -0700 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> Message-ID: <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> In the current implementation, the map of the property value looks like: null -> false; "" -> false; "true" -> true; "false" -> false; "not" -> false For compatibility, I think you may only want to update the default value: null or empty property value, otherwise the behavior does not change. null -> true; "" -> true; "true" -> true; "false" -> false; "not" -> false Per the update, "not" property means true. It might not be an issue in practice. I will have you make the final decision. Otherwise, looks fine to me. Xuelei On 3/22/2018 8:04 PM, Weijun Wang wrote: > Please take a review of the code change and CSR at > > CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 > webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ > > Thanks > Max > From xuelei.fan at oracle.com Sun Apr 8 02:55:44 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 7 Apr 2018 19:55:44 -0700 Subject: RFR 8200792: PKCS12Attribute#hashCode is always constant -1 In-Reply-To: References: Message-ID: <029a3638-e29b-e0ee-0aa0-1d189b116ad3@oracle.com> Looks fine to me. Xuelei On 4/7/2018 7:08 PM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8200792/webrev.00/ > > The fix is trivial, but it's also trivial to write a test, so I added one. > > Thanks > Max > From weijun.wang at oracle.com Sun Apr 8 03:30:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 8 Apr 2018 11:30:09 +0800 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> Message-ID: This is more natural. Thanks. Updated webrev at http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. Do you mind reviewing the CSR also? Thanks Max > On Apr 8, 2018, at 10:53 AM, Xuelei Fan wrote: > > In the current implementation, the map of the property value looks like: > null -> false; > "" -> false; > "true" -> true; > "false" -> false; > "not" -> false > > For compatibility, I think you may only want to update the default value: null or empty property value, otherwise the behavior does not change. > > null -> true; > "" -> true; > "true" -> true; > "false" -> false; > "not" -> false > > Per the update, "not" property means true. It might not be an issue in practice. I will have you make the final decision. Otherwise, looks fine to me. > > Xuelei > > On 3/22/2018 8:04 PM, Weijun Wang wrote: >> Please take a review of the code change and CSR at >> CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 >> webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ >> Thanks >> Max From xuelei.fan at oracle.com Sun Apr 8 03:38:29 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 7 Apr 2018 20:38:29 -0700 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> Message-ID: I added myself as reviewer of the CSR. Xuelei On 4/7/2018 8:30 PM, Weijun Wang wrote: > This is more natural. Thanks. > > Updated webrev at http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. > > Do you mind reviewing the CSR also? > > Thanks > Max > >> On Apr 8, 2018, at 10:53 AM, Xuelei Fan wrote: >> >> In the current implementation, the map of the property value looks like: >> null -> false; >> "" -> false; >> "true" -> true; >> "false" -> false; >> "not" -> false >> >> For compatibility, I think you may only want to update the default value: null or empty property value, otherwise the behavior does not change. >> >> null -> true; >> "" -> true; >> "true" -> true; >> "false" -> false; >> "not" -> false >> >> Per the update, "not" property means true. It might not be an issue in practice. I will have you make the final decision. Otherwise, looks fine to me. >> >> Xuelei >> >> On 3/22/2018 8:04 PM, Weijun Wang wrote: >>> Please take a review of the code change and CSR at >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 >>> webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ >>> Thanks >>> Max > From Roger.Riggs at Oracle.com Mon Apr 9 13:03:14 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 Apr 2018 09:03:14 -0400 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> Message-ID: <664d201f-710a-f34b-5d7a-5e64f2a14d3a@Oracle.com> Hi, I've seen a variety of interpretations of non-standard input for parsing booleans and it is likely to cause confusion across properties. I'd prefer that we converge on the interpretation used in the Boolean.parseBoolean. Which uses:? "true".equalsIgnoreCase(s); Better yet, call Boolean.parseBoolean!? Will be compatible with the previous GetBooleanAction(). $.02, Roger On 4/7/2018 10:53 PM, Xuelei Fan wrote: > In the current implementation, the map of the property value looks like: > ?? null??? -> false; > ?? ""????? -> false; > ?? "true"? -> true; > ?? "false" -> false; > ?? "not"?? -> false > > For compatibility, I think you may only want to update the default > value: null or empty property value, otherwise the behavior does not > change. > > ?? null??? -> true; > ?? ""????? -> true; > ?? "true"? -> true; > ?? "false" -> false; > ?? "not"?? -> false > > Per the update, "not" property means true.? It might not be an issue > in practice.? I will have you make the final decision. Otherwise, > looks fine to me. > > Xuelei > > On 3/22/2018 8:04 PM, Weijun Wang wrote: >> Please take a review of the code change and CSR at >> >> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 >> ??? webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ >> >> Thanks >> Max >> From Roger.Riggs at Oracle.com Mon Apr 9 13:04:34 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 9 Apr 2018 09:04:34 -0400 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <664d201f-710a-f34b-5d7a-5e64f2a14d3a@Oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> <664d201f-710a-f34b-5d7a-5e64f2a14d3a@Oracle.com> Message-ID: <03960c6f-0391-7652-04fb-d02a883fdc74@Oracle.com> Never mind, the latest webrev is great! On 4/9/2018 9:03 AM, Roger Riggs wrote: > Hi, > > I've seen a variety of interpretations of non-standard input for > parsing booleans and > it is likely to cause confusion across properties. > > I'd prefer that we converge on the interpretation used in the > Boolean.parseBoolean. > Which uses:? "true".equalsIgnoreCase(s); > > Better yet, call Boolean.parseBoolean!? Will be compatible with the > previous GetBooleanAction(). > > $.02, Roger > > > On 4/7/2018 10:53 PM, Xuelei Fan wrote: >> In the current implementation, the map of the property value looks like: >> ?? null??? -> false; >> ?? ""????? -> false; >> ?? "true"? -> true; >> ?? "false" -> false; >> ?? "not"?? -> false >> >> For compatibility, I think you may only want to update the default >> value: null or empty property value, otherwise the behavior does not >> change. >> >> ?? null??? -> true; >> ?? ""????? -> true; >> ?? "true"? -> true; >> ?? "false" -> false; >> ?? "not"?? -> false >> >> Per the update, "not" property means true.? It might not be an issue >> in practice.? I will have you make the final decision. Otherwise, >> looks fine to me. >> >> Xuelei >> >> On 3/22/2018 8:04 PM, Weijun Wang wrote: >>> Please take a review of the code change and CSR at >>> >>> ??? CSR: https://bugs.openjdk.java.net/browse/JDK-8200153 >>> ??? webrev: http://cr.openjdk.java.net/~weijun/8200152/webrev.00/ >>> >>> Thanks >>> Max >>> > From sibabrata.sahoo at oracle.com Mon Apr 9 14:13:45 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 9 Apr 2018 07:13:45 -0700 (PDT) Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> Message-ID: Hi Sean/Adam, Here is the new patch addressing all comments. Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.01/ Changes includes: 1) KeyAgreementTest.java KeySizeTest.java I have ensured no duplicate Test cases exist for the functionality provided in these 2 files. Due to that I have remove 3 files, DHGenSecretKey.java, SupportedDHKeys.java, UnsupportedDHKeys.java from "open/test/jdk/com/sun/crypto/provider/KeyAgreement" folder. Statements which affected due to merging the missing code from these deleted files are KeyAgreementTest.java[29, 141], KeySizeTest.java[91-100, 112-162]. Also I have observed that KeySizeTest.java Test takes around 2 minute to complete in SOME PLATFORM to complete all 14 @run and approximately 20 seconds for higher keys > 4096 for "DiffieHellman" only after merge. Please suggest if removing the higher Keys from the Test cases will help or 20-30 seconds for these higher keys is accepted here? 2) I have updated the comment in KeyAgreementTest.java[129] to indicate provider search order. As per Adam's comments the following changes, 3) KeySizeTest.java & NegativeTest.java, which need utility methods from Convert.java are using the library instead of defining it's own. 4) MultiThreadTest.java generates two key pairs and do two key agreement operations. Thanks, Siba -----Original Message----- From: Sean Mullan Sent: Thursday, April 05, 2018 8:46 PM To: Sibabrata Sahoo ; Adam Petcher ; security-dev at openjdk.java.net Subject: Re: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 Comments below ... On 4/2/18 4:07 AM, Sibabrata Sahoo wrote: > Hi Sean, > > My comments In-lined.. > > Thanks, > Siba > > -----Original Message----- > From: Sean Mullan > Sent: Saturday, March 31, 2018 12:13 AM > To: Sibabrata Sahoo ; Adam Petcher > ; security-dev at openjdk.java.net > Subject: Re: RFR: 8200219: Develop new tests for using new elliptic > curves: curve25519 and curve448 > > A few comments so far; have not finished my review yet. > > General comment: > > Many of these tests test more than XDH. That is fine and good for increasing coverage, but have you looked through existing tests to see if you are duplicating anything we are already testing and maybe those tests could be removed or you could share the same code. One of the things we should be looking at is to figure out how to reduce the overall time the security tests take. > > There are few Lines of code related to " DiffieHellman " are duplicate in KeyAgreementTest.java and KeySizeTest.java which are available in 2 existing Test folders. i.e. "open\test\jdk\sun\security\pkcs11\KeyAgreement" and "open\test\jdk\com\sun\crypto\provider\KeyAgreement". While there is no equivalent Tests for the same for "ECDH" and "XDH". The remaining files available in the webrev are mostly new. Our initial thinking was to have Test files covering all similar algorithms in one place. In that case I may remove 2-3 existing Test files inside these folders with next patch. Ok. > * KeyAgreementTest.java > > 128 // Uses platform supported provider to test interoperability. > > What do you mean by "platform supported provider"? Isn't this based on the provider search order? So in some cases, you might be testing against the same provider and not really doing interop testing? > > Yes my thinking here is Provider search order. I may need to change the comment appropriately. Here the intention is not really interop based Test unless a different provider found other than SunJCE. Ok. > > * KeySizeTest.java > > You are generating some large keys - any issues with test timeouts? Do we need to test the generation of the keypairs? Could we use cached keypairs instead? > > Yes here my intention is to test generation of keypairs with different key sizes too. I have ran these Test files several times. I have not seen these test files taking more times than few couple of seconds. Ok. I looked at the other tests and have no further comments. Thanks, Sean > On 3/26/18 12:38 PM, Sibabrata Sahoo wrote: >> Hi, >> >> Please review the patch for, >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8184359 >> >> Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.00/ >> >> All the Test files uses KeyAgreement, KeyPairGenerator, Several >> KeySpecs from SunJCE library to Test DiffieHellman, ECDH and XDH with >> curve25519 and curve448 algorithms. Each Test files try to address >> several cases and the purpose of each has been commented in their own files. >> >> Thanks, >> >> Siba >> From weijun.wang at oracle.com Tue Apr 10 02:58:47 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Apr 2018 10:58:47 +0800 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> Message-ID: <1079DDB7-8AAA-4AEC-89AA-F2F5BB049AE0@oracle.com> Thanks. Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8201351? > On Apr 8, 2018, at 11:38 AM, Xuelei Fan wrote: > > I added myself as reviewer of the CSR. > > Xuelei > > On 4/7/2018 8:30 PM, Weijun Wang wrote: >> This is more natural. Thanks. >> Updated webrev at http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. >> Do you mind reviewing the CSR also? >> Thanks >> Max From xuelei.fan at oracle.com Tue Apr 10 03:39:10 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 9 Apr 2018 20:39:10 -0700 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <1079DDB7-8AAA-4AEC-89AA-F2F5BB049AE0@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> <1079DDB7-8AAA-4AEC-89AA-F2F5BB049AE0@oracle.com> Message-ID: <1e059bca-7781-2613-329e-cf933ab9c727@oracle.com> I may use a title/subject that states the new state or behavior changes of a RFE. For example, "Uses UTF-8 for KerberosString". Otherwise, looks fine to me. Xuelei On 4/9/2018 7:58 PM, Weijun Wang wrote: > Thanks. Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8201351? > >> On Apr 8, 2018, at 11:38 AM, Xuelei Fan wrote: >> >> I added myself as reviewer of the CSR. >> >> Xuelei >> >> On 4/7/2018 8:30 PM, Weijun Wang wrote: >>> This is more natural. Thanks. >>> Updated webrev at http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. >>> Do you mind reviewing the CSR also? >>> Thanks >>> Max From sean.mullan at oracle.com Tue Apr 10 14:15:09 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Apr 2018 10:15:09 -0400 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: <1e059bca-7781-2613-329e-cf933ab9c727@oracle.com> References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> <1079DDB7-8AAA-4AEC-89AA-F2F5BB049AE0@oracle.com> <1e059bca-7781-2613-329e-cf933ab9c727@oracle.com> Message-ID: On 4/9/18 11:39 PM, Xuelei Fan wrote: > I may use a title/subject that states the new state or behavior changes > of a RFE.? For example, "Uses UTF-8 for KerberosString".? Otherwise, > looks fine to me. The title should be more specific that KerberosString uses UTF-8. I suggest: "KerberosString uses UTF-8 encoding by default". --Sean > > Xuelei > > On 4/9/2018 7:58 PM, Weijun Wang wrote: >> Thanks. Can you also review the release note at >> https://bugs.openjdk.java.net/browse/JDK-8201351? >> >>> On Apr 8, 2018, at 11:38 AM, Xuelei Fan wrote: >>> >>> I added myself as reviewer of the CSR. >>> >>> Xuelei >>> >>> On 4/7/2018 8:30 PM, Weijun Wang wrote: >>>> This is more natural. Thanks. >>>> Updated webrev at >>>> http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. >>>> Do you mind reviewing the CSR also? >>>> Thanks >>>> Max From weijun.wang at oracle.com Tue Apr 10 14:16:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 10 Apr 2018 22:16:09 +0800 Subject: RFR 8200152: KerberosString should use UTF-8 by default In-Reply-To: References: <340799EE-44EE-476B-BD1E-579151CFD436@oracle.com> <949a9317-9f54-204f-edc0-76767e202e2a@oracle.com> <1079DDB7-8AAA-4AEC-89AA-F2F5BB049AE0@oracle.com> <1e059bca-7781-2613-329e-cf933ab9c727@oracle.com> Message-ID: <2B2F6A98-CC2D-4A8A-9FDB-BD1B84939F13@oracle.com> Updated. Thanks. > On Apr 10, 2018, at 10:15 PM, Sean Mullan wrote: > > On 4/9/18 11:39 PM, Xuelei Fan wrote: >> I may use a title/subject that states the new state or behavior changes of a RFE. For example, "Uses UTF-8 for KerberosString". Otherwise, looks fine to me. > > The title should be more specific that KerberosString uses UTF-8. I suggest: "KerberosString uses UTF-8 encoding by default". > > --Sean > >> Xuelei >> On 4/9/2018 7:58 PM, Weijun Wang wrote: >>> Thanks. Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8201351? >>> >>>> On Apr 8, 2018, at 11:38 AM, Xuelei Fan wrote: >>>> >>>> I added myself as reviewer of the CSR. >>>> >>>> Xuelei >>>> >>>> On 4/7/2018 8:30 PM, Weijun Wang wrote: >>>>> This is more natural. Thanks. >>>>> Updated webrev at http://cr.openjdk.java.net/~weijun/8200152/webrev.01/. >>>>> Do you mind reviewing the CSR also? >>>>> Thanks >>>>> Max From sean.mullan at oracle.com Tue Apr 10 20:11:47 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Apr 2018 16:11:47 -0400 Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> Message-ID: On 4/9/18 10:13 AM, Sibabrata Sahoo wrote: > Here is the new patch addressing all comments. > Webrev:http://cr.openjdk.java.net/~ssahoo/8184359/webrev.01/ > > Changes includes: > 1) > KeyAgreementTest.java > KeySizeTest.java > I have ensured no duplicate Test cases exist for the functionality provided in these 2 files. Due to that I have remove 3 files, DHGenSecretKey.java, SupportedDHKeys.java, UnsupportedDHKeys.java from "open/test/jdk/com/sun/crypto/provider/KeyAgreement" folder. For DHGenSecretKey, can you add the bugid of 4936763 to the test file in this webrev where the changes were merged and also link the bugs together in JBS? That way we know that these tests are now covering the fixes for that bug. For the others, see below. > Statements which affected due to merging the missing code from these deleted files are KeyAgreementTest.java[29, 141], KeySizeTest.java[91-100, 112-162]. Also I have observed that KeySizeTest.java Test takes around 2 minute to complete in SOME PLATFORM to complete all 14 @run and approximately 20 seconds for higher keys > 4096 for "DiffieHellman" only after merge. Please suggest if removing the higher Keys from the Test cases will help or 20-30 seconds for these higher keys is accepted here? It's a bit concerning. One way to make the tests run faster is to split them up into separate tests so that they can be run concurrently by jtreg. So we might be making things worse by merging them :( So I would suggest just merging DHGenSecretKey and leaving the other tests as-is. > 2) I have updated the comment in KeyAgreementTest.java[129] to indicate provider search order. Ok. --Sean > As per Adam's comments the following changes, > 3) KeySizeTest.java & NegativeTest.java, which need utility methods from Convert.java are using the library instead of defining it's own. > 4) MultiThreadTest.java generates two key pairs and do two key agreement operations. From jamil.j.nimeh at oracle.com Tue Apr 10 21:37:24 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 10 Apr 2018 14:37:24 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> Message-ID: <8ad47b35-3678-06f5-2526-c971532785cf@oracle.com> Hello Thomas, et al., On 3/26/2018 1:49 PM, Jamil Nimeh wrote: > Hi Thomas, thanks for the feedback > > 1. Were there guidelines?? Not really, though I looked at other > parameter definitions in com.sun.crypto.provider and tried to > follow along the same lines that they do.? One thing that should > be changed is the LINE_SEP assignment shouldn't be an explicit > getProperty call.? I noticed most are doing System.lineSeparator() > so I'll change my implementation to match that.? None of these > params appear to stringify as json, so I'll probably keep things > consistent with the other parameter output. > 2. You make a fair point with respect to a null SecureRandom. I can > make that spec change. > 3. Let me think on this one - I shied away from ChaCha20ParameterSpec > for AEAD mode only because you have this nonce field that is set > but gets ignored.? But making ChaCha20ParameterSpec an > IvParameterSpec potentially runs into the same issue were it used > for a ChaCha20-Poly1305 cipher. If I had to choose between the two > I think I'd go with allowing ChaCha20ParameterSpec to be used with > CC20-P1305 rather than making it a subclass of IvParameterSpec.? > Doing the former helps from a type safety perspective that you > couldn't use a ChaCha20ParameterSpec with other Ciphers that > require an IvParameterSpec.? I know I had some discussions early > on in the design where we talked about this, I need to refresh my > memory as to why we didn't allow it. > Finally getting back to #3.? Took me a while to find early discussions on this.? The primary objection to ChaCha20ParameterSpec being used with ChaCha20-Poly1305 (as opposed to plain old ChaCha20) has to do with the configurable block counter.? You have this parameter that is not used, and consumption of this type of AlgorithmParameterSpec then leaves it to documentation to define what happens (is it ignored?? Used despite what the spec says?? Set to some default value regardless of what the caller sets there?). Using IvParameterSpec with ChaCha20-Poly1305 is more clear because it only allows the caller what they need to get CC20/P1305 going, the nonce.? Respectfully, I would like to keep this as-is. > > --Jamil > > > On 3/26/2018 12:45 PM, Thomas Lu?nig wrote: >> >> Hi Jamil, >> >> 1) where there any guidelines about how the engineToString should be >> formatted ? >> I ask because i wondering why we need two new lines with access to >> the System property. >> If it is represented as single line json no need to line break would >> be needed. >> >> Gru? Thomas >> >> >> /** * Creates a formatted string describing the parameters. * * >> @return a string representation of the ChaCha20 parameters. */ >> @Override protected String engineToString() { String LINE_SEP = >> System.getProperty("line.separator"); HexDumpEncoder encoder = new >> HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + >> "nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); >> return sb.toString(); } >> 2) I do not think it is an good idea to say no secureRandom=null will cause IV to be null. >> I see here the risk of weak implementations. I would suggest to throw an Exception to >> enforce secure usages. If someone really want an insecure IV he can provide am SecureRandom >> implementation retuning 0 only or an matching IV. >> >> ?* @param random a {@code SecureRandom} implementation. If {@code null} >> * is used for the random object, then a nonce consisting of all >> * zero bytes will be used. Otherwise a random nonce will be >> * used. >> >> 3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for booth modes in engineInit. >> Even if the counter is not needed. >> As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode. >> >> Grup Thomas >> On 3/26/2018 9:08 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>> cipher implementations.? Links to the webrev and the JEP which >>> outlines the characteristics and behavior of the ciphers are listed >>> below. >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>> http://openjdk.java.net/jeps/329 >>> >>> Thanks, >>> --Jamil > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Tue Apr 10 22:34:36 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Tue, 10 Apr 2018 15:34:36 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: Message-ID: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> Hello everyone, This is a quick update to the previous webrev: * When using the form of engineInit that does only takes op, key and random, the nonce will always be random even if the random parameter is null. A default instance of SecureRandom will be used to create the nonce in this case, instead of all zeroes. * Unused debug code was removed from the ChaCha20Cipher.java file * ChaCha20Parameters.engineToString no longer obtains the line separator from a System property directly. It calls System.lineSeparator() similar to how other AlgorithmParameter classes in com.sun.crypto.provider do it. http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ Thanks, --Jamil On 03/26/2018 12:08 PM, Jamil Nimeh wrote: > Hello all, > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > cipher implementations. Links to the webrev and the JEP which > outlines the characteristics and behavior of the ciphers are listed > below. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > http://openjdk.java.net/jeps/329 > > Thanks, > --Jamil From ecki at zusammenkunft.net Wed Apr 11 09:37:15 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 11 Apr 2018 09:37:15 +0000 Subject: SHAKE XOFs Message-ID: Hello, I noticed that the OASIS draft for extending PKCS#11 with SHA-3 also specifies new Mechanisms for SHAKE128/256. They introduce them as Key Derivation functions. I wonder if this would also be the way to introduce this into JCA, at the moment XOFs have been a non-goal of JEP287, but there is some use for them In modern protocols I would guess. (This request was inspired by a discussion on the bouncycastle crypto-dev mailing list about missing algorithms for it). Gruss Bernd -- http://bernd.eckenfels.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.petcher at oracle.com Wed Apr 11 15:29:03 2018 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 11 Apr 2018 11:29:03 -0400 Subject: SHAKE XOFs In-Reply-To: References: Message-ID: <9fc5d5ff-2078-c453-49ad-2f9c8598ceda@oracle.com> On 4/11/2018 5:37 AM, Bernd Eckenfels wrote: > Hello, > > I noticed that the OASIS draft for extending PKCS#11 with SHA-3 also > specifies new Mechanisms for SHAKE128/256. They introduce them as Key > Derivation functions. Interesting. Though to be pedantic, it looks like they introduce key derivation mechanisms that are based on SHAKE128/256. > > I wonder if this would also be the way to introduce this into JCA, at > the moment XOFs have been a non-goal of JEP287, but there is some use > for them In modern protocols I would guess. (This request was inspired > by a discussion ?on the bouncycastle crypto-dev mailing list about > missing algorithms for it). Continuing the pedantry, it would be reasonable to put these SHAKE128/256-based-KDFs under the KDF API (once that API exists). But the underlying SHAKE XOFs probably belong in a different API like MessageDigest or a new API that is more appropriate for XOFs. I expect that adding the XOFs to the API will be non-trivial because we don't have an obviously good place to put them. I think it would be fine to put them in MessageDigest, but we would need a way to specify the output length. We will need SHAKE256 for Ed448[1], but my initial thought was to do a private implementation, because I don't know if these functions are useful enough to justify the effort of the API design. Maybe we can make an API for them as a separate effort. It's also worth noting that the (bare) XOFs are not very good KDFs because they allow key extraction through related output attacks. [1] https://bugs.openjdk.java.net/browse/JDK-8187789 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Wed Apr 11 15:54:38 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Apr 2018 08:54:38 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <06b32b05-b1a6-122e-ea5a-8851efed9d20@suche.org> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> <06b32b05-b1a6-122e-ea5a-8851efed9d20@suche.org> Message-ID: <9e209265-d84c-0e05-abe5-5f6d7a9e3e4b@oracle.com> Yes, that does appear to be the case, good catch!? I'll make that change. --Jamil On 4/11/2018 7:18 AM, Thomas Lu?nig wrote: > Hi, > > i found another point. The "key" field can be removed from > ChaCha20Cipher. > 1) This field is only set once and later checked if it was initialized. > ???? But we do not want to knew is the key exists but if key bytes > exists. > 2) So if two lines are changed from key to keyBytes we can remove this > unused field. > > > Gru? Thomas > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html > > Lines 426 , 461 (change to keyBytes) > ??? if (key == null > Line 75+507 (remove) > ??? private Key key; > ??? this.key = key; > > > On 4/11/2018 12:34 AM, Jamil Nimeh wrote: >> Hello everyone, >> >> This is a quick update to the previous webrev: >> >> * When using the form of engineInit that does only takes op, key and >> random, the nonce will always be random even if the random parameter >> is null.? A default instance of SecureRandom will be used to create >> the nonce in this case, instead of all zeroes. >> >> * Unused debug code was removed from the ChaCha20Cipher.java file >> >> * ChaCha20Parameters.engineToString no longer obtains the line >> separator from a System property directly.? It calls >> System.lineSeparator() similar to how other AlgorithmParameter >> classes in com.sun.crypto.provider do it. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ >> >> Thanks, >> >> --Jamil >> >> >> On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>> cipher implementations.? Links to the webrev and the JEP which >>> outlines the characteristics and behavior of the ciphers are listed >>> below. >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>> http://openjdk.java.net/jeps/329 >>> >>> Thanks, >>> --Jamil >> From jamil.j.nimeh at oracle.com Wed Apr 11 17:57:12 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Wed, 11 Apr 2018 10:57:12 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <70919be9-4b3f-a4b2-234e-1243e1dd57f2@suche.org> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> <06b32b05-b1a6-122e-ea5a-8851efed9d20@suche.org> <9e209265-d84c-0e05-abe5-5f6d7a9e3e4b@oracle.com> <70919be9-4b3f-a4b2-234e-1243e1dd57f2@suche.org> Message-ID: Okay, I will check that out and fix as appropriate.? Thanks for the comments! --Jamil On 4/11/2018 10:56 AM, Thomas Lu?nig wrote: > Hi, > > same with key/keyBytes is with the class Poly1305 also here the key is > not used. > > Gru? Thomas > > On 4/11/2018 5:54 PM, Jamil Nimeh wrote: >> Yes, that does appear to be the case, good catch!? I'll make that >> change. >> >> --Jamil >> >> On 4/11/2018 7:18 AM, Thomas Lu?nig wrote: >>> Hi, >>> >>> i found another point. The "key" field can be removed from >>> ChaCha20Cipher. >>> 1) This field is only set once and later checked if it was initialized. >>> ???? But we do not want to knew is the key exists but if key bytes >>> exists. >>> 2) So if two lines are changed from key to keyBytes we can remove >>> this unused field. >>> >>> >>> Gru? Thomas >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html >>> >>> Lines 426 , 461 (change to keyBytes) >>> ??? if (key == null >>> Line 75+507 (remove) >>> ??? private Key key; >>> ??? this.key = key; >>> >>> >>> On 4/11/2018 12:34 AM, Jamil Nimeh wrote: >>>> Hello everyone, >>>> >>>> This is a quick update to the previous webrev: >>>> >>>> * When using the form of engineInit that does only takes op, key >>>> and random, the nonce will always be random even if the random >>>> parameter is null.? A default instance of SecureRandom will be used >>>> to create the nonce in this case, instead of all zeroes. >>>> >>>> * Unused debug code was removed from the ChaCha20Cipher.java file >>>> >>>> * ChaCha20Parameters.engineToString no longer obtains the line >>>> separator from a System property directly.? It calls >>>> System.lineSeparator() similar to how other AlgorithmParameter >>>> classes in com.sun.crypto.provider do it. >>>> >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ >>>> >>>> Thanks, >>>> >>>> --Jamil >>>> >>>> >>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >>>>> Hello all, >>>>> >>>>> This is a request for review for the ChaCha20 and >>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev and >>>>> the JEP which outlines the characteristics and behavior of the >>>>> ciphers are listed below. >>>>> >>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>>>> http://openjdk.java.net/jeps/329 >>>>> >>>>> Thanks, >>>>> --Jamil >>>> >> From jottofar at redhat.com Thu Apr 5 13:51:50 2018 From: jottofar at redhat.com (Jack Ottofaro) Date: Thu, 5 Apr 2018 09:51:50 -0400 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider Message-ID: Hi Valerie, I have an important customer awaiting this change. Can you please provide a status update as to the progress of this effort and any information available as to when it may be completed. Thanks, Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From lussnig at suche.org Wed Apr 11 14:04:54 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 11 Apr 2018 16:04:54 +0200 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <8ad47b35-3678-06f5-2526-c971532785cf@oracle.com> References: <708677fc-9cdd-a145-6794-283cab51c84e@suche.org> <8ad47b35-3678-06f5-2526-c971532785cf@oracle.com> Message-ID: Hi, ok that is an good point that if we have more values in the structure than we use this can make some confusion. I was only looking from the coding point of view and saw that if i can use the same structure for booth cases this can reduce the coding overhead. But i can fully understand your point. Gru? Thomas On 4/10/2018 11:37 PM, Jamil Nimeh wrote: > Hello Thomas, et al., > > On 3/26/2018 1:49 PM, Jamil Nimeh wrote: >> Hi Thomas, thanks for the feedback >> >> 1. Were there guidelines?? Not really, though I looked at other >> parameter definitions in com.sun.crypto.provider and tried to >> follow along the same lines that they do.? One thing that should >> be changed is the LINE_SEP assignment shouldn't be an explicit >> getProperty call.? I noticed most are doing >> System.lineSeparator() so I'll change my implementation to match >> that.? None of these params appear to stringify as json, so I'll >> probably keep things consistent with the other parameter output. >> 2. You make a fair point with respect to a null SecureRandom.? I can >> make that spec change. >> 3. Let me think on this one - I shied away from >> ChaCha20ParameterSpec for AEAD mode only because you have this >> nonce field that is set but gets ignored.? But making >> ChaCha20ParameterSpec an IvParameterSpec potentially runs into >> the same issue were it used for a ChaCha20-Poly1305 cipher.? If I >> had to choose between the two I think I'd go with allowing >> ChaCha20ParameterSpec to be used with CC20-P1305 rather than >> making it a subclass of IvParameterSpec.? Doing the former helps >> from a type safety perspective that you couldn't use a >> ChaCha20ParameterSpec with other Ciphers that require an >> IvParameterSpec.? I know I had some discussions early on in the >> design where we talked about this, I need to refresh my memory as >> to why we didn't allow it. >> > Finally getting back to #3.? Took me a while to find early discussions > on this.? The primary objection to ChaCha20ParameterSpec being used > with ChaCha20-Poly1305 (as opposed to plain old ChaCha20) has to do > with the configurable block counter.? You have this parameter that is > not used, and consumption of this type of AlgorithmParameterSpec then > leaves it to documentation to define what happens (is it ignored?? > Used despite what the spec says?? Set to some default value regardless > of what the caller sets there?).? Using IvParameterSpec with > ChaCha20-Poly1305 is more clear because it only allows the caller what > they need to get CC20/P1305 going, the nonce.? Respectfully, I would > like to keep this as-is. >> >> --Jamil >> >> >> On 3/26/2018 12:45 PM, Thomas Lu?nig wrote: >>> >>> Hi Jamil, >>> >>> 1) where there any guidelines about how the engineToString should be >>> formatted ? >>> I ask because i wondering why we need two new lines with access to >>> the System property. >>> If it is represented as single line json no need to line break would >>> be needed. >>> >>> Gru? Thomas >>> >>> >>> /** * Creates a formatted string describing the parameters. * * >>> @return a string representation of the ChaCha20 parameters. */ >>> @Override protected String engineToString() { String LINE_SEP = >>> System.getProperty("line.separator"); HexDumpEncoder encoder = new >>> HexDumpEncoder(); StringBuilder sb = new StringBuilder(LINE_SEP + >>> "nonce:" + LINE_SEP + "[" + encoder.encodeBuffer(nonce) + "]"); >>> return sb.toString(); } >>> 2) I do not think it is an good idea to say no secureRandom=null will cause IV to be null. >>> I see here the risk of weak implementations. I would suggest to throw an Exception to >>> enforce secure usages. If someone really want an insecure IV he can provide am SecureRandom >>> implementation retuning 0 only or an matching IV. >>> >>> ?* @param random a {@code SecureRandom} implementation. If {@code null} >>> * is used for the random object, then a nonce consisting of all >>> * zero bytes will be used. Otherwise a random nonce will be >>> * used. >>> >>> 3) If ChaCha20ParameterSpec would extends IvParameterSpec if would be valid for booth modes in engineInit. >>> Even if the counter is not needed. >>> As an alternative i would allow ChaCha20ParameterSpec also for AEAD mode. >>> >>> Grup Thomas >>> On 3/26/2018 9:08 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>>> cipher implementations.? Links to the webrev and the JEP which >>>> outlines the characteristics and behavior of the ciphers are listed >>>> below. >>>> >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>>> http://openjdk.java.net/jeps/329 >>>> >>>> Thanks, >>>> --Jamil >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lussnig at suche.org Wed Apr 11 14:18:37 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 11 Apr 2018 16:18:37 +0200 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> Message-ID: <06b32b05-b1a6-122e-ea5a-8851efed9d20@suche.org> Hi, i found another point. The "key" field can be removed from ChaCha20Cipher. 1) This field is only set once and later checked if it was initialized. ???? But we do not want to knew is the key exists but if key bytes exists. 2) So if two lines are changed from key to keyBytes we can remove this unused field. Gru? Thomas http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html Lines 426 , 461 (change to keyBytes) ??? if (key == null Line 75+507 (remove) ??? private Key key; ??? this.key = key; On 4/11/2018 12:34 AM, Jamil Nimeh wrote: > Hello everyone, > > This is a quick update to the previous webrev: > > * When using the form of engineInit that does only takes op, key and > random, the nonce will always be random even if the random parameter > is null.? A default instance of SecureRandom will be used to create > the nonce in this case, instead of all zeroes. > > * Unused debug code was removed from the ChaCha20Cipher.java file > > * ChaCha20Parameters.engineToString no longer obtains the line > separator from a System property directly.? It calls > System.lineSeparator() similar to how other AlgorithmParameter classes > in com.sun.crypto.provider do it. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ > > Thanks, > > --Jamil > > > On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >> cipher implementations.? Links to the webrev and the JEP which >> outlines the characteristics and behavior of the ciphers are listed >> below. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >> http://openjdk.java.net/jeps/329 >> >> Thanks, >> --Jamil > From lussnig at suche.org Wed Apr 11 17:56:49 2018 From: lussnig at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=) Date: Wed, 11 Apr 2018 19:56:49 +0200 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <9e209265-d84c-0e05-abe5-5f6d7a9e3e4b@oracle.com> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> <06b32b05-b1a6-122e-ea5a-8851efed9d20@suche.org> <9e209265-d84c-0e05-abe5-5f6d7a9e3e4b@oracle.com> Message-ID: <70919be9-4b3f-a4b2-234e-1243e1dd57f2@suche.org> Hi, same with key/keyBytes is with the class Poly1305 also here the key is not used. Gru? Thomas On 4/11/2018 5:54 PM, Jamil Nimeh wrote: > Yes, that does appear to be the case, good catch!? I'll make that change. > > --Jamil > > On 4/11/2018 7:18 AM, Thomas Lu?nig wrote: >> Hi, >> >> i found another point. The "key" field can be removed from >> ChaCha20Cipher. >> 1) This field is only set once and later checked if it was initialized. >> ???? But we do not want to knew is the key exists but if key bytes >> exists. >> 2) So if two lines are changed from key to keyBytes we can remove >> this unused field. >> >> >> Gru? Thomas >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java.html >> >> Lines 426 , 461 (change to keyBytes) >> ??? if (key == null >> Line 75+507 (remove) >> ??? private Key key; >> ??? this.key = key; >> >> >> On 4/11/2018 12:34 AM, Jamil Nimeh wrote: >>> Hello everyone, >>> >>> This is a quick update to the previous webrev: >>> >>> * When using the form of engineInit that does only takes op, key and >>> random, the nonce will always be random even if the random parameter >>> is null.? A default instance of SecureRandom will be used to create >>> the nonce in this case, instead of all zeroes. >>> >>> * Unused debug code was removed from the ChaCha20Cipher.java file >>> >>> * ChaCha20Parameters.engineToString no longer obtains the line >>> separator from a System property directly.? It calls >>> System.lineSeparator() similar to how other AlgorithmParameter >>> classes in com.sun.crypto.provider do it. >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ >>> >>> Thanks, >>> >>> --Jamil >>> >>> >>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >>>> Hello all, >>>> >>>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>>> cipher implementations.? Links to the webrev and the JEP which >>>> outlines the characteristics and behavior of the ciphers are listed >>>> below. >>>> >>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>>> http://openjdk.java.net/jeps/329 >>>> >>>> Thanks, >>>> --Jamil >>> > From weijun.wang at oracle.com Thu Apr 12 04:50:49 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 12 Apr 2018 12:50:49 +0800 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: References: Message-ID: <7475CB0A-76C0-41E6-9D5D-DA2AD4C7512A@oracle.com> Hi Valerie I updated the webrev at http://cr.openjdk.java.net/~weijun/8200468/webrev.01/ The only change is that I prepend "GSS_DLLIMP" to all gss_* functions in gssapi.h. The file has the following lines 283 #if defined (_WIN32) && defined (_MSC_VER) 284 # ifdef GSS_DLL_FILE 285 # define GSS_DLLIMP __declspec(dllexport) 286 # else 287 # define GSS_DLLIMP __declspec(dllimport) 288 # endif 289 #else 290 # define GSS_DLLIMP 291 #endif I added it so the exact same header file can be used to write a native GSS-API library which would export these functions. Is this OK? Tests run fine with both MIT krb5 and Heimdal libraries. Thanks Max > On Apr 4, 2018, at 10:19 AM, Weijun Wang wrote: > > Hi All > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ > > Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: > > java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... > > You can manually test the change with > > jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java > > Thanks > Max > > p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. From claes.redestad at oracle.com Thu Apr 12 17:24:45 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 Apr 2018 19:24:45 +0200 Subject: RFR: 8152821: Merge jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.JavaSecurityProtectionDomainAccess shared secrets Message-ID: Hi, ProtectionDomain creates both the JavaSecurityAccess and the JavaSecurityProtectionDomainAccess SharedSecrets, and since 9 both are always created eagerly during early bootstrap. It seems safe to merge these two, as suggested, which is a tiny startup improvement and cleanup. Webrev: http://cr.openjdk.java.net/~redestad/8152821/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8152821 Thanks! /Claes From sean.mullan at oracle.com Thu Apr 12 18:45:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Apr 2018 14:45:40 -0400 Subject: RFR: 8152821: Merge jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.JavaSecurityProtectionDomainAccess shared secrets In-Reply-To: References: Message-ID: <62bf29a3-35ce-4b2c-8cc9-619207b73d0a@oracle.com> Please update copyright dates. Otherwise looks fine. --Sean On 4/12/18 1:24 PM, Claes Redestad wrote: > Hi, > > ProtectionDomain creates both the JavaSecurityAccess and the > JavaSecurityProtectionDomainAccess SharedSecrets, and since 9 both are > always created eagerly during early bootstrap. It seems safe to merge > these two, as suggested, which is a tiny startup improvement and cleanup. > > Webrev: http://cr.openjdk.java.net/~redestad/8152821/open.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152821 > > Thanks! > > /Claes > From claes.redestad at oracle.com Thu Apr 12 19:36:30 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 12 Apr 2018 21:36:30 +0200 Subject: RFR: 8152821: Merge jdk.internal.misc.JavaSecurityAccess and jdk.internal.misc.JavaSecurityProtectionDomainAccess shared secrets In-Reply-To: <62bf29a3-35ce-4b2c-8cc9-619207b73d0a@oracle.com> References: <62bf29a3-35ce-4b2c-8cc9-619207b73d0a@oracle.com> Message-ID: <45d42f2d-e70f-d6a6-f648-297aae4395fa@oracle.com> On 2018-04-12 20:45, Sean Mullan wrote: > Please update copyright dates. Otherwise looks fine. Sure, and thanks for reviewing! /Claes From rajan.halade at oracle.com Thu Apr 12 21:40:24 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Thu, 12 Apr 2018 14:40:24 -0700 Subject: RFR: 8198240: Allow cacerts test to pass when GTECyberTrust root expires Message-ID: <29fbab89-40ec-789d-258d-6c18c80082e5@oracle.com> Please review this test fix to allow exception list to 90 days expiry policy. Fix also modifies the error reporting to report alias of certificate being checked. Webrev: http://cr.openjdk.java.net/~rhalade/8198240/webrev.00/ Thanks, Rajan From valerie.peng at oracle.com Fri Apr 13 01:09:18 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 12 Apr 2018 18:09:18 -0700 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: <7475CB0A-76C0-41E6-9D5D-DA2AD4C7512A@oracle.com> References: <7475CB0A-76C0-41E6-9D5D-DA2AD4C7512A@oracle.com> Message-ID: <92daea7a-8137-fcd9-a3be-fbb79266899c@oracle.com> Hi Max, Changes look fine, just some very minor nit: Maybe it's better to remove the unused variables which currently are only commented out (GSSLibStub.c and NativeUtil.c). When testing, did u enable debugging? If not, maybe worthwhile to try it out to make sure things work as expected. Thanks, Valerie On 4/11/2018 9:50 PM, Weijun Wang wrote: > Hi Valerie > > I updated the webrev at > > http://cr.openjdk.java.net/~weijun/8200468/webrev.01/ > > The only change is that I prepend "GSS_DLLIMP" to all gss_* functions in gssapi.h. The file has the following lines > > 283 #if defined (_WIN32) && defined (_MSC_VER) > 284 # ifdef GSS_DLL_FILE > 285 # define GSS_DLLIMP __declspec(dllexport) > 286 # else > 287 # define GSS_DLLIMP __declspec(dllimport) > 288 # endif > 289 #else > 290 # define GSS_DLLIMP > 291 #endif > > I added it so the exact same header file can be used to write a native GSS-API library which would export these functions. > > Is this OK? Tests run fine with both MIT krb5 and Heimdal libraries. > > Thanks > Max > > >> On Apr 4, 2018, at 10:19 AM, Weijun Wang wrote: >> >> Hi All >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ >> >> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: >> >> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... >> >> You can manually test the change with >> >> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java >> >> Thanks >> Max >> >> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. From weijun.wang at oracle.com Fri Apr 13 01:11:18 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 13 Apr 2018 09:11:18 +0800 Subject: RFR 8200468: Port the native GSS-API bridge to Windows In-Reply-To: <92daea7a-8137-fcd9-a3be-fbb79266899c@oracle.com> References: <7475CB0A-76C0-41E6-9D5D-DA2AD4C7512A@oracle.com> <92daea7a-8137-fcd9-a3be-fbb79266899c@oracle.com> Message-ID: <3AA07976-9C73-469F-ADE4-6C384952F701@oracle.com> > On Apr 13, 2018, at 9:09 AM, Valerie Peng wrote: > > Hi Max, > > Changes look fine, just some very minor nit: Maybe it's better to remove the unused variables which currently are only commented out (GSSLibStub.c and > NativeUtil.c). Sure. > When testing, did u enable debugging? If not, maybe worthwhile to try it out to make sure things work as expected. Yes I enabled it once or twice. I will try again on all sides. Thanks Max > > Thanks, > Valerie > > On 4/11/2018 9:50 PM, Weijun Wang wrote: >> Hi Valerie >> >> I updated the webrev at >> >> http://cr.openjdk.java.net/~weijun/8200468/webrev.01/ >> >> The only change is that I prepend "GSS_DLLIMP" to all gss_* functions in gssapi.h. The file has the following lines >> >> 283 #if defined (_WIN32) && defined (_MSC_VER) >> 284 # ifdef GSS_DLL_FILE >> 285 # define GSS_DLLIMP __declspec(dllexport) >> 286 # else >> 287 # define GSS_DLLIMP __declspec(dllimport) >> 288 # endif >> 289 #else >> 290 # define GSS_DLLIMP >> 291 #endif >> >> I added it so the exact same header file can be used to write a native GSS-API library which would export these functions. >> >> Is this OK? Tests run fine with both MIT krb5 and Heimdal libraries. >> >> Thanks >> Max >> >> >>> On Apr 4, 2018, at 10:19 AM, Weijun Wang wrote: >>> >>> Hi All >>> >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8200468/webrev.00/ >>> >>> Like in *nix, native GSS-API bridge is turned on by setting -Dsun.security.jgss.native=true. Please note there is no default native GSS-API library on Windows and you need to supply your own, like this: >>> >>> java -Dsun.security.jgss.native=true -Dsun.security.jgss.lib=/path/to/gssapi64.dll App ... >>> >>> You can manually test the change with >>> >>> jtreg -Dnative.krb5.libs=j=,n=/path/to/gssapi64.dll test/jdk/sun/security/krb5/auto/BasicProc.java >>> >>> Thanks >>> Max >>> >>> p.s. You can get a gssapi64.dll from https://web.mit.edu/KERBEROS/kfw-4.1/kfw-4.1.html. > From sean.mullan at oracle.com Fri Apr 13 12:59:31 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Apr 2018 08:59:31 -0400 Subject: RFR: 8198240: Allow cacerts test to pass when GTECyberTrust root expires In-Reply-To: <29fbab89-40ec-789d-258d-6c18c80082e5@oracle.com> References: <29fbab89-40ec-789d-258d-6c18c80082e5@oracle.com> Message-ID: <2483e1ad-85b1-583a-4126-2d71a26cd478@oracle.com> 288 System.err.println("WARNING: "); I don't think you need to print a warning in this case since this expired root is an exception to the policy. Also, once the cert has expired, the subsequent message "will expire" doesn't make sense: 293 System.err.println("cert \"" + alias + "\" expiry \"" 294 + notAfter.toString() + "\" will expire within 90 days"); since it has already expired. Just print out the message above for the error cases. Looks good otherwise. --Sean On 4/12/18 5:40 PM, Rajan Halade wrote: > Please review this test fix to allow exception list to 90 days expiry > policy. Fix also modifies the error reporting to report alias of > certificate being checked. > > Webrev: http://cr.openjdk.java.net/~rhalade/8198240/webrev.00/ > > Thanks, > Rajan From rajan.halade at oracle.com Fri Apr 13 15:46:16 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Fri, 13 Apr 2018 08:46:16 -0700 Subject: RFR: 8198240: Allow cacerts test to pass when GTECyberTrust root expires In-Reply-To: <2483e1ad-85b1-583a-4126-2d71a26cd478@oracle.com> References: <29fbab89-40ec-789d-258d-6c18c80082e5@oracle.com> <2483e1ad-85b1-583a-4126-2d71a26cd478@oracle.com> Message-ID: Thanks for your comments. Updated webrev is at http://cr.openjdk.java.net/~rhalade/8198240/webrev.01/ - Rajan On 4/13/18 5:59 AM, Sean Mullan wrote: > 288 System.err.println("WARNING: "); > > I don't think you need to print a warning in this case since this > expired root is an exception to the policy. Also, once the cert has > expired, the subsequent message "will expire" doesn't make sense: > > ?293???????????????? System.err.println("cert \"" + alias + "\" expiry > \"" > ?294???????????????????????? + notAfter.toString() + "\" will expire > within 90 days"); > > since it has already expired. Just print out the message above for the > error cases. > > Looks good otherwise. > > --Sean > > On 4/12/18 5:40 PM, Rajan Halade wrote: >> Please review this test fix to allow exception list to 90 days expiry >> policy. Fix also modifies the error reporting to report alias of >> certificate being checked. >> >> Webrev: http://cr.openjdk.java.net/~rhalade/8198240/webrev.00/ >> >> Thanks, >> Rajan From sean.mullan at oracle.com Fri Apr 13 16:25:49 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Apr 2018 12:25:49 -0400 Subject: RFR: 8198240: Allow cacerts test to pass when GTECyberTrust root expires In-Reply-To: References: <29fbab89-40ec-789d-258d-6c18c80082e5@oracle.com> <2483e1ad-85b1-583a-4126-2d71a26cd478@oracle.com> Message-ID: <39a940d3-1d49-aa59-07d9-229d3becafb1@oracle.com> On 4/13/18 11:46 AM, Rajan Halade wrote: > Thanks for your comments. Updated webrev is at > http://cr.openjdk.java.net/~rhalade/8198240/webrev.01/ Looks fine. --Sean From jamil.j.nimeh at oracle.com Fri Apr 13 18:59:53 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 13 Apr 2018 11:59:53 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> Message-ID: <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305: * Removed the key field in ChaCha20 and Poly1305 implementations and only retain the key bytes as an object field (thanks Thomas for catching this) * Added additional protections against key/nonce reuse. This is a behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of these ciphers will no longer allow you to do subsequent doUpdate/doFinal calls after the first doFinal without re-initializing the cipher with either a new key or nonce. Attempting to reuse the cipher without a new initialization will throw an IllegalStateException. This is similar to the behavior of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for both encrypt and decrypt. http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/ Thanks, --Jamil On 04/10/2018 03:34 PM, Jamil Nimeh wrote: > Hello everyone, > > This is a quick update to the previous webrev: > > * When using the form of engineInit that does only takes op, key and > random, the nonce will always be random even if the random parameter > is null. A default instance of SecureRandom will be used to create > the nonce in this case, instead of all zeroes. > > * Unused debug code was removed from the ChaCha20Cipher.java file > > * ChaCha20Parameters.engineToString no longer obtains the line > separator from a System property directly. It calls > System.lineSeparator() similar to how other AlgorithmParameter classes > in com.sun.crypto.provider do it. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ > > Thanks, > > --Jamil > > > On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >> cipher implementations. Links to the webrev and the JEP which >> outlines the characteristics and behavior of the ciphers are listed >> below. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >> http://openjdk.java.net/jeps/329 >> >> Thanks, >> --Jamil > From bradford.wetmore at oracle.com Fri Apr 13 19:25:06 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 13 Apr 2018 12:25:06 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: Message-ID: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> My biggest comment below are the algorithm names you've chosen. BC and Android use a different naming convention (details below), and I don't think folks will be able to drop in those alternate crypto impls and use our TLS impl without some modifications of one/other code. Mostly everything else is typos. Unfortunately I'm on break next week, so I got as far as I could. I got all of the non-sun/security/rsa code and it looks ok. I got through some of sun/security/rsa code. I did about 4 of these thoroughly, and took some brief looks in other files. I didn't hit the tests unfortunately. As a general note, throughout your code I'd suggest netbeans to discover stylistic issues, there were lots of little suggestions that could help. I didn't have time to flag all of them, but here's a representative sample in the first file listed. e.g. PSSParameters.java ------------------ 61: Make final? @Overrides throughout? BigInteger is actually needed? (unused import) 101: Extra ; here. 122: You can use a switch on strings here. 240: You could tighten the code a bit with: sb.append("....") .append("...") .append("..." RSACipher.java -------------- using both PKCS#1 v1.5 and OAEP paddings -> using both PKCS#1 v1.5 and OAEP (v2.2) paddings MGF1ParameterSpec.java ---------------------- 49: Add an extra line? 74/79: Nit: maybe add some vertical space here for these other elements? PSSParameterSpec.java --------------------- Maybe add trailerFieldBC(1)? Similar vertical space comments? 157/202: We talked about this in person, but I wanted to mention here for a wider audience. I had concerns about this typo, and any interop problems this might bring. I looked over the Bouncy Castle impl, and it appears as though they also assumed it to be bytes, not bits. Can you check with the other vendors who might have their own PSS implementations and verify this is not going to be a problem? I talked with our CSR lead (Joe Darcy), he doesn't think it should be a problem if other impls are using bytes. 213: Usually @param/@return fragments don't end with a . But would mean updating the rest of the file. Keep (if you so decided) or change. RSAKeyGenParameterSpec.java --------------------------- I see/understand what you're doing underneath, but the following reads a little awkward without the context. Maybe: public-exponent value and null key parameters -> public-exponent value and no key parameters RSAMultiPrimePrivateCrtKeySpec.java ----------------------------------- 80-87/126-132: Any chance of reformatting the @exception text? Very strange to read. 107: If you really want to list out every input for the constructors, you should probably mention the AlgorithmParameterSpec here, otherwise the two methods are exactly the same. 63/107: You seem to be doing it in other classes, so suggest you also update v2.1 -> v2.2 RSAPrivateCrtKeySpec.java ------------------------- 60/88: Do you want to add v1.2? 88: Same comment about the missing AlgorithmParameterSpec. RSAPrivateKeySpec.java ---------------------- 62: "...with additional algorithm parameters." ? RSAPublicKeySpec.java --------------------- 98: fragment. OAEPParameterSpec.java ---------------------- Do you want to split the lines on this one as well, like the other two? Or make them all one line each? RSAPrivateCrtKeyImpl.java ------------------------- must be null -> Must be null 178/183/188/193/198/203/208/213/219/223/229: Do you want to add in the @overrides for this class instead of "// see JCE doc"? 230: This is the "SunRsaSign" provider, but yo are using "Sun" here. SunRsaSignEntries.java ---------------------- 145: Where did you come up with this convention for your aliases? SHA1withRSA-PSS I see Bouncy Castle[1] and Android[2] are both using: SHA*withRSA/PSS RSASSA-PSS (name from PKCS#1) [1] https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java [2] https://developer.android.com/reference/java/security/Signature.html but we have neither style. MGF1.java --------- 36: * @since 10 -> * @since 11 Thanks! Brad On 3/27/2018 6:40 PM, Valerie Peng wrote: > Hi Brad, > > Can you please help review the changes for RSA-PSS support? I also added > some minor enhancement which add 2 more digest algorithms for OAEP padding. > There are quite some changes involved. The main changes are in the > SunRsaSign provider, i.e. sun.security.rsa packages. I reused existing > RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl classes as much > as possible. However, given that RSA-PSS signatures requires parameters, > I put its implementation in a separate class, i.e. RSAPSSSignature.java. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8146293 > Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/ > > Existing and new regression tests have been run and result looks fine. > Thanks, > Valerie From bhanu.prakash.gopularam at oracle.com Mon Apr 16 08:44:17 2018 From: bhanu.prakash.gopularam at oracle.com (bhanu.prakash.gopularam at oracle.com) Date: Mon, 16 Apr 2018 14:14:17 +0530 Subject: RFR 8144806: sun/security/tools/keytool/standard.sh fails intermittently at deleting x.jks Message-ID: <06af5d7f-c6f9-2bf5-cf39-cbefdf54d83e@oracle.com> Hi All, Please review fix for following issue: JBS bug: https://bugs.openjdk.java.net/browse/JDK-8144806 Webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/8144806/webrev.00/ The patch fixes intermittent test failure. The fix uses deleteFileIfExistsWithRetry(..) from test library class FileUtils. I have validated the fix with repeated-run on all supported platform. Thanks, Bhanu From sibabrata.sahoo at oracle.com Mon Apr 16 13:50:52 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 16 Apr 2018 06:50:52 -0700 (PDT) Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> Message-ID: <8801847c-92c7-49e3-b18b-ff78ade2045a@default> Hi Sean/Adam, Please review the updated patch, Webrev: http://cr.openjdk.java.net/~ssahoo/8184359/webrev.02/ Now there is only 1 Test file in the deleted list which has duplicate code. Due to that I have pointed the older JBS bug ID JDK-4936763 in KeyAgreementTest.java and linked the same to JDK-8184359 too. Reverted the duplicate code merge in KeySizeTest.java due to performance issue observed for higher key sizes. That ensured SupportedDHKeys.java & UnsupportedDHKeys.java will not be removed as it was provided in previous patch. Thanks, Siba -----Original Message----- From: Sean Mullan Sent: Wednesday, April 11, 2018 1:42 AM To: Sibabrata Sahoo ; Adam Petcher ; security-dev at openjdk.java.net Subject: Re: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 On 4/9/18 10:13 AM, Sibabrata Sahoo wrote: > Here is the new patch addressing all comments. > Webrev:http://cr.openjdk.java.net/~ssahoo/8184359/webrev.01/ > > Changes includes: > 1) > KeyAgreementTest.java > KeySizeTest.java > I have ensured no duplicate Test cases exist for the functionality provided in these 2 files. Due to that I have remove 3 files, DHGenSecretKey.java, SupportedDHKeys.java, UnsupportedDHKeys.java from "open/test/jdk/com/sun/crypto/provider/KeyAgreement" folder. For DHGenSecretKey, can you add the bugid of 4936763 to the test file in this webrev where the changes were merged and also link the bugs together in JBS? That way we know that these tests are now covering the fixes for that bug. For the others, see below. > Statements which affected due to merging the missing code from these deleted files are KeyAgreementTest.java[29, 141], KeySizeTest.java[91-100, 112-162]. Also I have observed that KeySizeTest.java Test takes around 2 minute to complete in SOME PLATFORM to complete all 14 @run and approximately 20 seconds for higher keys > 4096 for "DiffieHellman" only after merge. Please suggest if removing the higher Keys from the Test cases will help or 20-30 seconds for these higher keys is accepted here? It's a bit concerning. One way to make the tests run faster is to split them up into separate tests so that they can be run concurrently by jtreg. So we might be making things worse by merging them :( So I would suggest just merging DHGenSecretKey and leaving the other tests as-is. > 2) I have updated the comment in KeyAgreementTest.java[129] to indicate provider search order. Ok. --Sean > As per Adam's comments the following changes, > 3) KeySizeTest.java & NegativeTest.java, which need utility methods from Convert.java are using the library instead of defining it's own. > 4) MultiThreadTest.java generates two key pairs and do two key agreement operations. From weijun.wang at oracle.com Mon Apr 16 14:01:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 16 Apr 2018 22:01:40 +0800 Subject: RFR 8144806: sun/security/tools/keytool/standard.sh fails intermittently at deleting x.jks In-Reply-To: <06af5d7f-c6f9-2bf5-cf39-cbefdf54d83e@oracle.com> References: <06af5d7f-c6f9-2bf5-cf39-cbefdf54d83e@oracle.com> Message-ID: The change in KeyToolTest.java looks fine. You might also need to update autotest.sh in the same directory. --Max > On Apr 16, 2018, at 4:44 PM, bhanu.prakash.gopularam at oracle.com wrote: > > Hi All, > > Please review fix for following issue: > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8144806 > > Webrev: http://cr.openjdk.java.net/~bgopularam/bhanu/8144806/webrev.00/ > > The patch fixes intermittent test failure. The fix uses deleteFileIfExistsWithRetry(..) from test library class FileUtils. > > I have validated the fix with repeated-run on all supported platform. > > Thanks, > Bhanu From sean.mullan at oracle.com Mon Apr 16 18:40:56 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Apr 2018 14:40:56 -0400 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> Message-ID: <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> On 4/13/18 3:25 PM, Bradford Wetmore wrote: > SunRsaSignEntries.java > ---------------------- > 145:? Where did you come up with this convention for your aliases? > > ??? SHA1withRSA-PSS > > I see Bouncy Castle[1] and Android[2] are both using: > > ??? SHA*withRSA/PSS > ??? RSASSA-PSS (name from PKCS#1) > > [1] > https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java > > [2] https://developer.android.com/reference/java/security/Signature.html > > but we have neither style. Since these standard names have not yet been defined, we don't necessarily have to be consistent, but I don't see a good enough reason for us to name them differently, so to help with compatibility I would go with the names above. --Sean From weijun.wang at oracle.com Tue Apr 17 16:30:50 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 18 Apr 2018 00:30:50 +0800 Subject: JEP Draft: Client-side GSS-API Library for Windows SSPI Message-ID: Hi All Please take a look at https://bugs.openjdk.java.net/browse/JDK-8199569. With the Windows 10 Credential Guard feature turned on, Java can no longer uses the TGT in MSLSA, even if the allowtgtsessionkey registry value is set to 1. This JEP intends to provide a solution by letting Java directly make SSPI calls inside Windows. The JEP only covers client side using the default credential, but it might do more in future releases. Thanks Max From sean.mullan at oracle.com Tue Apr 17 16:36:58 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Apr 2018 12:36:58 -0400 Subject: JEP Draft: Client-side GSS-API Library for Windows SSPI In-Reply-To: References: Message-ID: <92e3e29d-75cb-fa4e-8624-e7fd6e7d7b38@oracle.com> See http://openjdk.java.net/jeps/8199569 for a more readable form of the JEP. --Sean On 4/17/18 12:30 PM, Weijun Wang wrote: > Hi All > > Please take a look at https://bugs.openjdk.java.net/browse/JDK-8199569. > > With the Windows 10 Credential Guard feature turned on, Java can no longer uses the TGT in MSLSA, even if the allowtgtsessionkey registry value is set to 1. This JEP intends to provide a solution by letting Java directly make SSPI calls inside Windows. > > The JEP only covers client side using the default credential, but it might do more in future releases. > > Thanks > Max > From sean.mullan at oracle.com Tue Apr 17 17:15:31 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Apr 2018 13:15:31 -0400 Subject: RFR: 8200219: Develop new tests for using new elliptic curves: curve25519 and curve448 In-Reply-To: <8801847c-92c7-49e3-b18b-ff78ade2045a@default> References: <8745579b-bf65-3355-25e5-2b2a38d2f118@oracle.com> <8801847c-92c7-49e3-b18b-ff78ade2045a@default> Message-ID: <946b7ded-c6c4-4bc5-ab3b-154213bde4dd@oracle.com> On 4/16/18 9:50 AM, Sibabrata Sahoo wrote: > Now there is only 1 Test file in the deleted list which has duplicate code. Due to that I have pointed the older JBS bug ID JDK-4936763 in KeyAgreementTest.java and linked the same to JDK-8184359 too. > > Reverted the duplicate code merge in KeySizeTest.java due to performance issue observed for higher key sizes. That ensured SupportedDHKeys.java & UnsupportedDHKeys.java will not be removed as it was provided in previous patch. Looks good. --Sean From valerie.peng at oracle.com Wed Apr 18 01:10:06 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 17 Apr 2018 18:10:06 -0700 Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider In-Reply-To: References: Message-ID: Hi Jack, Sorry for the late response, I have not been able to resume working on your patch for JDK-8029661 "Support TLS v1.2 algorithm in SunPKCS11 provider" as I have to work on a critical project for past few months. Now that my work for this critical project work is winding down, I will circle back to work on your patches and other OpenJDK patches as soon as I can. Is there more changes to your patch for JDK-8029661 since mid Feb which I reviewed? Just to be sure that we are on the same page in terms of changes. There is another Redhat patch which is about PKCS11 memory growth, i.e. JDK-6913047, can you please re-send me the patch against latest JDK workspace? I will build and pass the build to our performance team before I start the review. Thanks, Valerie On 4/6/2018 7:19 AM, Jack Ottofaro wrote: > Hi Valerie, > > I have an important customer awaiting this change. Can you please > provide a status update as to the progress of this effort and any > information available as to when it may be completed. > > Thanks, > > Jack From xuelei.fan at oracle.com Wed Apr 18 16:52:24 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Apr 2018 09:52:24 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> Message-ID: The algorithm name decomposer implementation for algorithm restrictions depends on the pattern: with Using the same "encryption" name for signature and PKCS#1 could be easier for applications if there is a need to decompose the algorithms. Xuelei On 4/16/2018 11:40 AM, Sean Mullan wrote: > On 4/13/18 3:25 PM, Bradford Wetmore wrote: >> SunRsaSignEntries.java >> ---------------------- >> 145:? Where did you come up with this convention for your aliases? >> >> ???? SHA1withRSA-PSS >> >> I see Bouncy Castle[1] and Android[2] are both using: >> >> ???? SHA*withRSA/PSS >> ???? RSASSA-PSS (name from PKCS#1) >> >> [1] >> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >> >> [2] https://developer.android.com/reference/java/security/Signature.html >> >> but we have neither style. > > Since these standard names have not yet been defined, we don't > necessarily have to be consistent, but I don't see a good enough reason > for us to name them differently, so to help with compatibility I would > go with the names above. > > --Sean From weijun.wang at oracle.com Wed Apr 18 17:40:01 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Apr 2018 01:40:01 +0800 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues Message-ID: Please take a review of this fix: webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 Basically we fix some bugs and introduce a system property so we can interop with everyone. Thanks Max From sean.mullan at oracle.com Wed Apr 18 18:25:32 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Apr 2018 14:25:32 -0400 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> Message-ID: <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> On 4/18/18 12:52 PM, Xuelei Fan wrote: > The algorithm name decomposer implementation for algorithm restrictions > depends on the pattern: > ?? with > > Using the same "encryption" name for signature and PKCS#1 could be > easier for applications if there is a need? to decompose the algorithms. Hmm, so do you mean this is a problem if you specify the signature algorithm as "RSA-PSS" and require that the digest algorithm be specified as a parameter to the API? Or something else? Not sure I understand you but I have a feeling you are raising a good point ... --Sean > > Xuelei > > On 4/16/2018 11:40 AM, Sean Mullan wrote: >> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>> SunRsaSignEntries.java >>> ---------------------- >>> 145:? Where did you come up with this convention for your aliases? >>> >>> ???? SHA1withRSA-PSS >>> >>> I see Bouncy Castle[1] and Android[2] are both using: >>> >>> ???? SHA*withRSA/PSS >>> ???? RSASSA-PSS (name from PKCS#1) >>> >>> [1] >>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>> >>> [2] https://developer.android.com/reference/java/security/Signature.html >>> >>> but we have neither style. >> >> Since these standard names have not yet been defined, we don't >> necessarily have to be consistent, but I don't see a good enough >> reason for us to name them differently, so to help with compatibility >> I would go with the names above. >> >> --Sean From xuelei.fan at oracle.com Wed Apr 18 18:36:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 18 Apr 2018 11:36:45 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> Message-ID: <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> On 4/18/2018 11:25 AM, Sean Mullan wrote: > On 4/18/18 12:52 PM, Xuelei Fan wrote: >> The algorithm name decomposer implementation for algorithm >> restrictions depends on the pattern: >> ??? with >> >> Using the same "encryption" name for signature and PKCS#1 could be >> easier for applications if there is a need? to decompose the algorithms. > > Hmm, so do you mean this is a problem if you specify the signature > algorithm as "RSA-PSS" and require that the digest algorithm be > specified as a parameter to the API? Or something else? Not sure I > understand you but I have a feeling you are raising a good point ... > The concern is from the names BC and Andriod used: SHA*withRSA/PSS RSASSA-PSS (name from PKCS#1) The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and "RSA/PSS". If the PKCS#1 name use "RSASSA-PSS", it is tricky to map "RSA/PSS" to "RSASSA-PSS". I'm suggesting use a consistent name. Either "SHA*withRSA/PSS"/"RSA/PSS" or "SHA*withRSASSA-PSS"/"RSASSA-PSS". Xuelei > --Sean > >> >> Xuelei >> >> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>> SunRsaSignEntries.java >>>> ---------------------- >>>> 145:? Where did you come up with this convention for your aliases? >>>> >>>> ???? SHA1withRSA-PSS >>>> >>>> I see Bouncy Castle[1] and Android[2] are both using: >>>> >>>> ???? SHA*withRSA/PSS >>>> ???? RSASSA-PSS (name from PKCS#1) >>>> >>>> [1] >>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>> >>>> [2] >>>> https://developer.android.com/reference/java/security/Signature.html >>>> >>>> but we have neither style. >>> >>> Since these standard names have not yet been defined, we don't >>> necessarily have to be consistent, but I don't see a good enough >>> reason for us to name them differently, so to help with compatibility >>> I would go with the names above. >>> >>> --Sean From nezihyigitbasi at gmail.com Thu Apr 19 04:32:05 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Wed, 18 Apr 2018 21:32:05 -0700 Subject: about JDK-8186628 Message-ID: Hi, We are hitting the scalability problem of the SSL session cache in production that JDK-8186628 is addressing. I see that JDK-8186628 has not been updated since Nov'17, so I just wanted to get information about what the current plans are regarding that issue. Thanks, Nezih -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Thu Apr 19 06:54:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 19 Apr 2018 14:54:36 +0800 Subject: RFR CSR 8201906: Use Mozilla Public Suffix List Message-ID: Please take a review at https://bugs.openjdk.java.net/browse/JDK-8201906 OpenJDK will switch from a home-grown list to Mozilla PSL. This is a behavior change, therefore a CSR. Thanks Max From bhanu.prakash.gopularam at oracle.com Thu Apr 19 11:32:07 2018 From: bhanu.prakash.gopularam at oracle.com (bhanu.prakash.gopularam at oracle.com) Date: Thu, 19 Apr 2018 17:02:07 +0530 Subject: RFR 8200101: sun/security/krb5/auto/Renewal.java fails intermittently Message-ID: Hi All, Please review fix for following issue: JBS bug: https://bugs.openjdk.java.net/browse/JDK-8200101 Webrev: http://cr.openjdk.java.net/~bgopularam/8200101/webrev.00/ It was found that test failure happened due to test machine slowdown, so fixed the issue by increasing the time interval. I have validated the change with repeated run on multiple platforms and found no issues. Thanks, Bhanu From weijun.wang at oracle.com Thu Apr 19 12:27:45 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Apr 2018 20:27:45 +0800 Subject: RFR 8200101: sun/security/krb5/auto/Renewal.java fails intermittently In-Reply-To: References: Message-ID: <34E828BC-0BB6-4F1E-8791-DF2416146649@oracle.com> The change looks fine. Thanks Max > ? 2018?4?19??19:32?bhanu.prakash.gopularam at oracle.com ??? > > Hi All, > > Please review fix for following issue: > > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8200101 > > Webrev: http://cr.openjdk.java.net/~bgopularam/8200101/webrev.00/ > > It was found that test failure happened due to test machine slowdown, so fixed the issue by increasing the time interval. I have validated the change with repeated run on multiple platforms and found no issues. > > Thanks, > Bhanu > > > > From mikael.vidstedt at oracle.com Fri Apr 20 00:55:56 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 19 Apr 2018 17:55:56 -0700 Subject: RFR JDK-8202060: Add javax/net/ssl/DTLS/CipherSuite.java to ProblemList Message-ID: Please review this change which adds javax/net/ssl/DTLS/CipherSuite.java to the ProblemList until https://bugs.openjdk.java.net/browse/JDK-8202059 is fixed. Bug: https://bugs.openjdk.java.net/browse/JDK-8202060 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202060/webrev.00/open/webrev/ Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Fri Apr 20 03:30:45 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 19 Apr 2018 20:30:45 -0700 Subject: RFR JDK-8202060: Add javax/net/ssl/DTLS/CipherSuite.java to ProblemList In-Reply-To: References: Message-ID: Looks fine to me. Xuelei On 4/19/2018 5:55 PM, Mikael Vidstedt wrote: > > Please review this change which adds?javax/net/ssl/DTLS/CipherSuite.java > to the ProblemList until > https://bugs.openjdk.java.net/browse/JDK-8202059?is fixed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202060 > Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8202060/webrev.00/open/webrev/ > > Cheers, > Mikael > From xuelei.fan at oracle.com Fri Apr 20 14:58:25 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 20 Apr 2018 07:58:25 -0700 Subject: Code Review Request: TLS 1.3 full handshake (JDK-8196584) In-Reply-To: <602b4435-88c5-30c6-d1ab-de057a5b7fca@oracle.com> References: <4f44f3d0-eb86-83f1-7553-80b4d310cdb4@oracle.com> <0419f803-e67c-074c-ff02-f0d45326d3b4@oracle.com> <602b4435-88c5-30c6-d1ab-de057a5b7fca@oracle.com> Message-ID: <36cb2370-f1cb-47e3-1f5f-761f2d2458ac@oracle.com> Thanks for the review. The update will be in next webrev. Thanks, Xuelei On 3/23/2018 12:35 PM, Adam Petcher wrote: > Note: I am not a Reviewer. This is not a Review. > > I took a look at some of the files that I was working in during my > extension development. I just have a few minor comments: > > TransportContext.java, line 428: It's not clear why the outbound > direction is closed here. Consider adding more comments to describe what > is going on. > > SessionId.java, lines 54: need to clone()? > SessionId.java, lines 81-87: you could do Arrays.hashCode(sessionId) > > SSLExtension.java, line 441: The word "trad" is used here and in other > places in the file. Should this be "trade"? > > KeyShareExtension.java, lines 264-265: I think you can remove the > comment, and the code is fine as it is. The problem of large ClientHello > messages should be addressed when we add support for HelloRetryRequest. > > > On 2/22/2018 3:29 PM, Xuelei Fan wrote: >> Updated to use package private HKDF implementation. >> >> webrev (based on JDK-8185576): >> ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01 >> >> webrev (including JDK-8185576): >> ????? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01 >> >> Thanks, >> Xuelei >> >> On 2/20/2018 11:57 AM, Xuelei Fan wrote: >>> Hi, >>> >>> I'd like to invite you to review the TLS 1.3 full handshake >>> implementation.? I appreciate it if I could have feedback before >>> March 9, 2018. >>> >>> In the "JDK-8185576: New handshake implementation" [1] code review >>> around, I was trying to re-org the TLS handshaking implementation in the >>> SunJSSE provider.? If you had reviewed that part, you can start from >>> the following webrev that based on the update of JDK-8185576: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.00 >>> >>> If you would like start from earlier, here is the webrev that >>> contains the handshaking implementation re-org in JDK-8185576: >>> ???? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00 >>> >>> >>> This changeset only implements the full handshake of TLS 1.3, rather >>> then a fully implementation of the latest TLS 1.3 draft [2]. >>> >>> In this implementation, I removed: >>> 1. the KRB5 cipher suite implementation. >>> Please let me know if you are still using KRB5 cipher suite.? I may >>> not add them back if no objections. >>> >>> 2. OCSP stapling. >>> This feature will be added back later. >>> >>> Resumption and key update, and more features may be added later. >>> >>> Thanks & Regards, >>> Xuelei >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016642.html >>> >>> [2]: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > From ivan.gerasimov at oracle.com Fri Apr 20 16:22:23 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Apr 2018 09:22:23 -0700 Subject: about JDK-8186628 In-Reply-To: References: Message-ID: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> Hello Nezih! This issue is still being discussed off-list. There have been two approaches proposed so far: 1) improve the session cache and 2) provide an option to turn the cache off completely. The former one is good by itself, so I filed an enhancement request [1] with a link to proposal made by Peter Levart [2]. However, as this is an enhancement, it seems unlikely it's going to be backported to earlier releases of JDK. With kind regards, Ivan [1] https://bugs.openjdk.java.net/browse/JDK-8202086 [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html On 4/18/18 9:32 PM, nezih yigitbasi wrote: > Hi, > We are hitting the scalability problem of the SSL session cache in > production that JDK-8186628 is addressing. > I see that JDK-8186628 has not been updated since Nov'17, so I just > wanted to get information about what the current plans are regarding > that issue. > > Thanks, > Nezih -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From nezihyigitbasi at gmail.com Fri Apr 20 17:06:18 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Fri, 20 Apr 2018 10:06:18 -0700 Subject: about JDK-8186628 In-Reply-To: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> References: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> Message-ID: Ivan, thanks for the information. Any ideas about when one of these solutions can be released? Nezih 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov : > Hello Nezih! > This issue is still being discussed off-list. > There have been two approaches proposed so far: 1) improve the session > cache and 2) provide an option to turn the cache off completely. > > The former one is good by itself, so I filed an enhancement request [1] > with a link to proposal made by Peter Levart [2]. > However, as this is an enhancement, it seems unlikely it's going to be > backported to earlier releases of JDK. > > With kind regards, > Ivan > > [1] https://bugs.openjdk.java.net/browse/JDK-8202086 > [2] http://mail.openjdk.java.net/pipermail/security-dev/2017- > November/016512.html > > On 4/18/18 9:32 PM, nezih yigitbasi wrote: > > Hi, > We are hitting the scalability problem of the SSL session cache in > production that JDK-8186628 is addressing. > I see that JDK-8186628 has not been updated since Nov'17, so I just wanted > to get information about what the current plans are regarding that issue. > > Thanks, > Nezih > > > -- > With kind regards, > Ivan Gerasimov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.gerasimov at oracle.com Fri Apr 20 17:45:52 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 20 Apr 2018 10:45:52 -0700 Subject: about JDK-8186628 In-Reply-To: References: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> Message-ID: <20e6db12-dfa4-781e-4d2b-435500484d3b@oracle.com> I'll go ahead with a review of the enhancement request JDK-8202086 shortly on this list. And we'll still need to decide what has to be done in the earlier releases of JDK. With kind regards, Ivan On 4/20/18 10:06 AM, nezih yigitbasi wrote: > Ivan, thanks for the information. Any ideas about when one of these > solutions can be released? > > Nezih > > 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov >: > > Hello Nezih! > > This issue is still being discussed off-list. > There have been two approaches proposed so far: 1) improve the > session cache and 2) provide an option to turn the cache off > completely. > > The former one is good by itself, so I filed an enhancement > request [1] with a link to proposal made by Peter Levart [2]. > However, as this is an enhancement, it seems unlikely it's going > to be backported to earlier releases of JDK. > > With kind regards, > Ivan > > [1] https://bugs.openjdk.java.net/browse/JDK-8202086 > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html > > > > On 4/18/18 9:32 PM, nezih yigitbasi wrote: >> Hi, >> We are hitting the scalability problem of the SSL session cache >> in production that JDK-8186628 is addressing. >> I see that JDK-8186628 has not been updated since Nov'17, so I >> just wanted to get information about what the current plans are >> regarding that issue. >> >> Thanks, >> Nezih > > -- > With kind regards, > Ivan Gerasimov > > -- With kind regards, Ivan Gerasimov -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini at zeus.net.au Sat Apr 21 08:42:05 2018 From: jini at zeus.net.au (Peter) Date: Sat, 21 Apr 2018 18:42:05 +1000 Subject: about JDK-8186628 In-Reply-To: <20e6db12-dfa4-781e-4d2b-435500484d3b@oracle.com> References: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> <20e6db12-dfa4-781e-4d2b-435500484d3b@oracle.com> Message-ID: <5ADAF95D.7080802@zeus.net.au> I wrote caching software that decorated any Java collection with soft, weak, timed or strong references, it utilised a background thread to clean references from underlying collections. It was non blocking if the underlying collection was, although it hasn't been updated to Java 8. Regarding patch comments, I don't mean to sound rude, but I don't think there's such a thing as a harmless data race. Regards, Peter. On 21/04/2018 3:45 AM, Ivan Gerasimov wrote: > > I'll go ahead with a review of the enhancement request JDK-8202086 > shortly on this list. > > And we'll still need to decide what has to be done in the earlier > releases of JDK. > > With kind regards, > > Ivan > > > > > > On 4/20/18 10:06 AM, nezih yigitbasi wrote: >> Ivan, thanks for the information. Any ideas about when one of these >> solutions can be released? >> >> Nezih >> >> 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov > >: >> >> Hello Nezih! >> >> This issue is still being discussed off-list. >> There have been two approaches proposed so far: 1) improve the >> session cache and 2) provide an option to turn the cache off >> completely. >> >> The former one is good by itself, so I filed an enhancement >> request [1] with a link to proposal made by Peter Levart [2]. >> However, as this is an enhancement, it seems unlikely it's going >> to be backported to earlier releases of JDK. >> >> With kind regards, >> Ivan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8202086 >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html >> >> >> >> On 4/18/18 9:32 PM, nezih yigitbasi wrote: >>> Hi, >>> We are hitting the scalability problem of the SSL session cache >>> in production that JDK-8186628 is addressing. >>> I see that JDK-8186628 has not been updated since Nov'17, so I >>> just wanted to get information about what the current plans are >>> regarding that issue. >>> >>> Thanks, >>> Nezih >> >> -- >> With kind regards, >> Ivan Gerasimov >> >> > > -- > With kind regards, > Ivan Gerasimov From peter.levart at gmail.com Sat Apr 21 09:51:50 2018 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 21 Apr 2018 11:51:50 +0200 Subject: about JDK-8186628 In-Reply-To: <5ADAF95D.7080802@zeus.net.au> References: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> <20e6db12-dfa4-781e-4d2b-435500484d3b@oracle.com> <5ADAF95D.7080802@zeus.net.au> Message-ID: Hi Peter, On 04/21/18 10:42, Peter wrote: > I wrote caching software that decorated any Java collection with soft, > weak, timed or strong references, it utilised a background thread to > clean references from underlying collections. > > It was non blocking if the underlying collection was, although it > hasn't been updated to Java 8. > > Regarding patch comments, I don't mean to sound rude, but I don't > think there's such a thing as a harmless data race. > > Regards, > > Peter. Perhaps harmless is not the right expression, but in this case, I think the data race(s) can do no "harm" to the correct / intended execution of program logic. That's my current belief, but you can prove me wrong if you want ;-) The data race is between CacheEntry.[getKey, getValue] and CacheIntry.invalidate that resets both key & value to null. When a CacheEntry is published, it is published without data race, with key & value being non-null. CacheEntry is private class, used only in MemoryCache, so it is never exposed to user code. User code only sees the result(s) of reading CacheEntry.[getKey, getValue] (returned from Cache.get(key) and from Cache.getCachedEntries()). The former allows null returns that logically mean an absence of value while the later constructs a map of live entries that are or were present in the cache at the time of invocation, filtering out null key(s)/value(s). The guarantees of those two methods are enough for correct functioning of user code (the SSL implementation), and this is what I called "harmless" data race because technically it is a data race. Regards, Peter > > On 21/04/2018 3:45 AM, Ivan Gerasimov wrote: >> >> I'll go ahead with a review of the enhancement request JDK-8202086 >> shortly on this list. >> >> And we'll still need to decide what has to be done in the earlier >> releases of JDK. >> >> With kind regards, >> >> Ivan >> >> >> >> >> >> On 4/20/18 10:06 AM, nezih yigitbasi wrote: >>> Ivan, thanks for the information. Any ideas about when one of these >>> solutions can be released? >>> >>> Nezih >>> >>> 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov >> >: >>> >>> ??? Hello Nezih! >>> >>> ??? This issue is still being discussed off-list. >>> ??? There have been two approaches proposed so far:? 1) improve the >>> ??? session cache and 2) provide an option to turn the cache off >>> ??? completely. >>> >>> ??? The former one is good by itself, so I filed an enhancement >>> ??? request [1] with a link to proposal made by Peter Levart [2]. >>> ??? However, as this is an enhancement, it seems unlikely it's going >>> ??? to be backported to earlier releases of JDK. >>> >>> ??? With kind regards, >>> ??? Ivan >>> >>> ??? [1] https://bugs.openjdk.java.net/browse/JDK-8202086 >>> ??? >>> ??? [2] >>> http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html >>> >>> >>> >>> ??? On 4/18/18 9:32 PM, nezih yigitbasi wrote: >>>> Hi, >>>> ??? We are hitting the scalability problem of the SSL session cache >>>> ??? in production that JDK-8186628 is addressing. >>>> ??? I see that JDK-8186628 has not been updated since Nov'17, so I >>>> ??? just wanted to get information about what the current plans are >>>> ??? regarding that issue. >>>> >>>> ??? Thanks, >>>> ??? Nezih >>> >>> ??? -- ??? With kind regards, >>> ??? Ivan Gerasimov >>> >>> >> >> -- >> With kind regards, >> Ivan Gerasimov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini at zeus.net.au Sun Apr 22 02:30:29 2018 From: jini at zeus.net.au (Peter) Date: Sun, 22 Apr 2018 12:30:29 +1000 Subject: about JDK-8186628 In-Reply-To: References: <190e738f-4196-330b-5c81-6268a6f42202@oracle.com> <20e6db12-dfa4-781e-4d2b-435500484d3b@oracle.com> <5ADAF95D.7080802@zeus.net.au> Message-ID: <5ADBF3C5.2070804@zeus.net.au> Thanks for your explanation. I worked on a lot of early java code circa Java 1.2 - 1.4, converting it to the post Java 5 memory model. Latent race conditions caused hundreds of bugs, and problems would occur in other unrelated parts of the code, it was very brittle, any changes to code would result in inexplicable test failures elsewhere. In the end I eliminated every race condition I found, harmless or otherwise, using both visual inspection and static analysis, the code lost it's brittle nature and became much easier to maintain since. Regards, Peter. On 21/04/2018 7:51 PM, Peter Levart wrote: > Hi Peter, > > On 04/21/18 10:42, Peter wrote: >> I wrote caching software that decorated any Java collection with >> soft, weak, timed or strong references, it utilised a background >> thread to clean references from underlying collections. >> >> It was non blocking if the underlying collection was, although it >> hasn't been updated to Java 8. >> >> Regarding patch comments, I don't mean to sound rude, but I don't >> think there's such a thing as a harmless data race. >> >> Regards, >> >> Peter. > > Perhaps harmless is not the right expression, but in this case, I > think the data race(s) can do no "harm" to the correct / intended > execution of program logic. That's my current belief, but you can > prove me wrong if you want ;-) The data race is between > CacheEntry.[getKey, getValue] and CacheIntry.invalidate that resets > both key & value to null. When a CacheEntry is published, it is > published without data race, with key & value being non-null. > CacheEntry is private class, used only in MemoryCache, so it is never > exposed to user code. User code only sees the result(s) of reading > CacheEntry.[getKey, getValue] (returned from Cache.get(key) and from > Cache.getCachedEntries()). The former allows null returns that > logically mean an absence of value while the later constructs a map of > live entries that are or were present in the cache at the time of > invocation, filtering out null key(s)/value(s). The guarantees of > those two methods are enough for correct functioning of user code (the > SSL implementation), and this is what I called "harmless" data race > because technically it is a data race. > > Regards, Peter > >> >> On 21/04/2018 3:45 AM, Ivan Gerasimov wrote: >>> >>> I'll go ahead with a review of the enhancement request JDK-8202086 >>> shortly on this list. >>> >>> And we'll still need to decide what has to be done in the earlier >>> releases of JDK. >>> >>> With kind regards, >>> >>> Ivan >>> >>> >>> >>> >>> >>> On 4/20/18 10:06 AM, nezih yigitbasi wrote: >>>> Ivan, thanks for the information. Any ideas about when one of these >>>> solutions can be released? >>>> >>>> Nezih >>>> >>>> 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov >>> >: >>>> >>>> Hello Nezih! >>>> >>>> This issue is still being discussed off-list. >>>> There have been two approaches proposed so far: 1) improve the >>>> session cache and 2) provide an option to turn the cache off >>>> completely. >>>> >>>> The former one is good by itself, so I filed an enhancement >>>> request [1] with a link to proposal made by Peter Levart [2]. >>>> However, as this is an enhancement, it seems unlikely it's going >>>> to be backported to earlier releases of JDK. >>>> >>>> With kind regards, >>>> Ivan >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8202086 >>>> >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html >>>> >>>> >>>> >>>> On 4/18/18 9:32 PM, nezih yigitbasi wrote: >>>>> Hi, >>>>> We are hitting the scalability problem of the SSL session cache >>>>> in production that JDK-8186628 is addressing. >>>>> I see that JDK-8186628 has not been updated since Nov'17, so I >>>>> just wanted to get information about what the current plans are >>>>> regarding that issue. >>>>> >>>>> Thanks, >>>>> Nezih >>>> >>>> -- With kind regards, >>>> Ivan Gerasimov >>>> >>>> >>> >>> -- >>> With kind regards, >>> Ivan Gerasimov >> > From nezihyigitbasi at gmail.com Thu Apr 19 00:22:57 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Wed, 18 Apr 2018 17:22:57 -0700 Subject: about JDK-8186628 Message-ID: Hi, We are hitting the scalability problem of the SSL session cache in production that JDK-8186628 is addressing, and I see that JDK-8186628 has not been updated since Nov'17. So, I just wanted to check what the current plans are regarding that issue. Thanks, Nezih -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Tue Apr 24 01:16:46 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 24 Apr 2018 09:16:46 +0800 Subject: RFR JDK-8199388: Test development for ChaCha20 and Poly1305 algorithms Message-ID: <6e713b9f-b9bb-7172-4fee-5b750bed33f8@oracle.com> Hi, This patch only adds a test for ChaCha20 key generator. Issue: https://bugs.openjdk.java.net/browse/JDK-8199388 Webrev: http://cr.openjdk.java.net/~jjiang/8199388/webrev.00/ Best regards, John Jiang From weijun.wang at oracle.com Tue Apr 24 14:42:46 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 24 Apr 2018 10:42:46 -0400 Subject: RFR 8201867: Kerberos keytabs with holes in certain places are parsed incorrectly Message-ID: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8201867/webrev.00/ When the hole in keytab is right on the 8192 buffer boundary, skip(n) does not return n. I are not sure if I can do something like "while (i < n) i += skip(n)" because skip(n) can return zero and it does not understand EOF. Therefore I readNBytes(n) and discard the result. If you have a better solution, I'll be happy to know. Thanks Max From valerie.peng at oracle.com Tue Apr 24 22:08:53 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 24 Apr 2018 15:08:53 -0700 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: References: Message-ID: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> Hi Max, Most changes look good. I have only some comments and questions (see below): - InitSecContextToken.java, line 62: bad -> unrecognized? - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? CSR looks good to me. Thanks, Valerie On 4/18/2018 10:40 AM, Weijun Wang wrote: > Please take a review of this fix: > > webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 > > Basically we fix some bugs and introduce a system property so we can interop with everyone. > > Thanks > Max > From weijun.wang at oracle.com Wed Apr 25 00:55:18 2018 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Apr 2018 20:55:18 -0400 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> References: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> Message-ID: <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> RFC 4120 5.5.1 has > seq-number > This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. If it wraps, then it?s 4 bytes. I will read more on it. Thanks Max > ? 2018?4?24??18:08?Valerie Peng ??? > > Hi Max, > > Most changes look good. I have only some comments and questions (see below): > > - InitSecContextToken.java, line 62: bad -> unrecognized? > - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? > > CSR looks good to me. > Thanks, > Valerie > > > >> On 4/18/2018 10:40 AM, Weijun Wang wrote: >> Please take a review of this fix: >> >> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 >> >> Basically we fix some bugs and introduce a system property so we can interop with everyone. >> >> Thanks >> Max >> > From weijun.wang at oracle.com Thu Apr 26 02:38:06 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 25 Apr 2018 22:38:06 -0400 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> References: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> Message-ID: <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2]. I'll do more experiments. Thanks Max [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76 [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825 > On Apr 24, 2018, at 8:55 PM, Wang Weijun wrote: > > RFC 4120 5.5.1 has >> seq-number > >> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. > > > If it wraps, then it?s 4 bytes. > > I will read more on it. > > Thanks > Max > >> ? 2018?4?24??18:08?Valerie Peng ??? >> >> Hi Max, >> >> Most changes look good. I have only some comments and questions (see below): >> >> - InitSecContextToken.java, line 62: bad -> unrecognized? >> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? >> >> CSR looks good to me. >> Thanks, >> Valerie >> >> >> >>> On 4/18/2018 10:40 AM, Weijun Wang wrote: >>> Please take a review of this fix: >>> >>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 >>> >>> Basically we fix some bugs and introduce a system property so we can interop with everyone. >>> >>> Thanks >>> Max >>> >> > From weijun.wang at oracle.com Thu Apr 26 04:06:09 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Apr 2018 00:06:09 -0400 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com> References: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com> Message-ID: <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words * Workaround implementation incompatibilities by not generating * initial sequence numbers greater than 2^30 So bad thing could only happen after 2^30 messages. --Max > On Apr 25, 2018, at 10:38 PM, Weijun Wang wrote: > > It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2]. > > I'll do more experiments. > > Thanks > Max > > [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76 > [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825 > >> On Apr 24, 2018, at 8:55 PM, Wang Weijun wrote: >> >> RFC 4120 5.5.1 has >>> seq-number >> >>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. >> >> >> If it wraps, then it?s 4 bytes. >> >> I will read more on it. >> >> Thanks >> Max >> >>> ? 2018?4?24??18:08?Valerie Peng ??? >>> >>> Hi Max, >>> >>> Most changes look good. I have only some comments and questions (see below): >>> >>> - InitSecContextToken.java, line 62: bad -> unrecognized? >>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? >>> >>> CSR looks good to me. >>> Thanks, >>> Valerie >>> >>> >>> >>>> On 4/18/2018 10:40 AM, Weijun Wang wrote: >>>> Please take a review of this fix: >>>> >>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 >>>> >>>> Basically we fix some bugs and introduce a system property so we can interop with everyone. >>>> >>>> Thanks >>>> Max >>>> >>> >> > From weijun.wang at oracle.com Thu Apr 26 04:48:16 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 26 Apr 2018 00:48:16 -0400 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com> References: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com> <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com> Message-ID: <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com> I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11. --Max > On Apr 26, 2018, at 12:06 AM, Weijun Wang wrote: > > I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words > > * Workaround implementation incompatibilities by not generating > * initial sequence numbers greater than 2^30 > > So bad thing could only happen after 2^30 messages. > > --Max > >> On Apr 25, 2018, at 10:38 PM, Weijun Wang wrote: >> >> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2]. >> >> I'll do more experiments. >> >> Thanks >> Max >> >> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76 >> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825 >> >>> On Apr 24, 2018, at 8:55 PM, Wang Weijun wrote: >>> >>> RFC 4120 5.5.1 has >>>> seq-number >>> >>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. >>> >>> >>> If it wraps, then it?s 4 bytes. >>> >>> I will read more on it. >>> >>> Thanks >>> Max >>> >>>> ? 2018?4?24??18:08?Valerie Peng ??? >>>> >>>> Hi Max, >>>> >>>> Most changes look good. I have only some comments and questions (see below): >>>> >>>> - InitSecContextToken.java, line 62: bad -> unrecognized? >>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? >>>> >>>> CSR looks good to me. >>>> Thanks, >>>> Valerie >>>> >>>> >>>> >>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote: >>>>> Please take a review of this fix: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 >>>>> >>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >>> >> > From sean.mullan at oracle.com Thu Apr 26 15:57:25 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Apr 2018 11:57:25 -0400 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: References: Message-ID: <4a7e820b-5cae-cb0b-d404-1cba453188f5@oracle.com> The ChaCha20ParameterSpec.java file should have an @since 11 annotation on it. --Sean On 3/26/18 3:08 PM, Jamil Nimeh wrote: > Hello all, > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > cipher implementations.? Links to the webrev and the JEP which outlines > the characteristics and behavior of the ciphers are listed below. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > http://openjdk.java.net/jeps/329 > > Thanks, > --Jamil From jamil.j.nimeh at oracle.com Thu Apr 26 17:36:46 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 26 Apr 2018 10:36:46 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <4a7e820b-5cae-cb0b-d404-1cba453188f5@oracle.com> Message-ID: <201804261738.w3QHcgJ0004420@userv0122.oracle.com> Will do.? I made some wording changes there to move away from "96-bit" to "12-byte" also since that probably is more useful to developers. --Jamil -------- Original message --------From: Sean Mullan Date: 4/26/18 8:57 AM (GMT-08:00) To: Jamil Nimeh , OpenJDK Dev list Subject: Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations The ChaCha20ParameterSpec.java file should have an @since 11 annotation on it. --Sean On 3/26/18 3:08 PM, Jamil Nimeh wrote: > Hello all, > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > cipher implementations.? Links to the webrev and the JEP which outlines > the characteristics and behavior of the ciphers are listed below. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > http://openjdk.java.net/jeps/329 > > Thanks, > --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Thu Apr 26 17:38:18 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 26 Apr 2018 10:38:18 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: Message-ID: <201804261738.w3QHcikr030629@userv0121.oracle.com> The NONCE_LENGTH I fixed last night in response to JVT comments.? I will do the clone also.? Thanks for the comments! --Jamil -------- Original message --------From: Sean Mullan Date: 4/26/18 10:22 AM (GMT-08:00) To: Jamil Nimeh , OpenJDK Dev list Subject: Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations On 4/26/18 11:57 AM, Sean Mullan wrote: > The ChaCha20ParameterSpec.java file should have an @since 11 annotation > on it. Also: ?? 65???????? if (nonce.length == 12) { ?? 66???????????? this.nonce = nonce.clone(); ?? 67???????? } else { ?? 68???????????? throw new IllegalArgumentException( ?? 69???????????????????? "Nonce must be 96-bits in length"); ?? 70???????? } You should clone nonce before you check the length and check the length on the copy, not the parameter passed in. Also, you should use NONCE_LENGTH instead of 12 since it is already defined as a constant in the class. --Sean > > --Sean > > On 3/26/18 3:08 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >> cipher implementations.? Links to the webrev and the JEP which >> outlines the characteristics and behavior of the ciphers are listed >> below. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >> http://openjdk.java.net/jeps/329 >> >> Thanks, >> --Jamil -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Thu Apr 26 17:42:37 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Apr 2018 13:42:37 -0400 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations Message-ID: On 4/26/18 1:36 PM, Jamil Nimeh wrote: > Will do.? I made some wording changes there to move away from "96-bit" > to "12-byte" also since that probably is more useful to developers. Yes, I was thinking about that also, and I think it makes more sense to refer to it as bytes. --Sean > > > > --Jamil > > -------- Original message -------- > From: Sean Mullan > Date: 4/26/18 8:57 AM (GMT-08:00) > To: Jamil Nimeh , OpenJDK Dev list > > Subject: Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations > > The ChaCha20ParameterSpec.java file should have an @since 11 annotation > on it. > > --Sean > > On 3/26/18 3:08 PM, Jamil Nimeh wrote: > > Hello all, > > > > This is a request for review for the ChaCha20 and ChaCha20-Poly1305 > > cipher implementations.? Links to the webrev and the JEP which outlines > > the characteristics and behavior of the ciphers are listed below. > > > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ > > http://openjdk.java.net/jeps/329 > > > > Thanks, > > --Jamil From sean.mullan at oracle.com Thu Apr 26 17:22:56 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Apr 2018 13:22:56 -0400 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <4a7e820b-5cae-cb0b-d404-1cba453188f5@oracle.com> References: <4a7e820b-5cae-cb0b-d404-1cba453188f5@oracle.com> Message-ID: On 4/26/18 11:57 AM, Sean Mullan wrote: > The ChaCha20ParameterSpec.java file should have an @since 11 annotation > on it. Also: 65 if (nonce.length == 12) { 66 this.nonce = nonce.clone(); 67 } else { 68 throw new IllegalArgumentException( 69 "Nonce must be 96-bits in length"); 70 } You should clone nonce before you check the length and check the length on the copy, not the parameter passed in. Also, you should use NONCE_LENGTH instead of 12 since it is already defined as a constant in the class. --Sean > > --Sean > > On 3/26/18 3:08 PM, Jamil Nimeh wrote: >> Hello all, >> >> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >> cipher implementations.? Links to the webrev and the JEP which >> outlines the characteristics and behavior of the ciphers are listed >> below. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >> http://openjdk.java.net/jeps/329 >> >> Thanks, >> --Jamil From sean.mullan at oracle.com Thu Apr 26 18:20:06 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 26 Apr 2018 14:20:06 -0400 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations Message-ID: <9a133a4b-59c0-e2b5-dc21-89bf615e6176@oracle.com> On 4/26/18 1:36 PM, Jamil Nimeh wrote: > Will do.? I made some wording changes there to move away from "96-bit" > to "12-byte" also since that probably is more useful to developers. One other comment is that I think the get methods of ChaCha20ParameterSpec should be final. There should be no reason to override those methods and it will help ensure that the contract of those methods are not being overridden by a subclass incorrectly. --Sean From jamil.j.nimeh at oracle.com Thu Apr 26 18:45:53 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Thu, 26 Apr 2018 11:45:53 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <9a133a4b-59c0-e2b5-dc21-89bf615e6176@oracle.com> References: <9a133a4b-59c0-e2b5-dc21-89bf615e6176@oracle.com> Message-ID: <7866443f-d325-fa55-5284-82015ee98e04@oracle.com> Agreed.? I will make that change. --Jamil On 04/26/2018 11:20 AM, Sean Mullan wrote: > On 4/26/18 1:36 PM, Jamil Nimeh wrote: >> Will do.? I made some wording changes there to move away from >> "96-bit" to "12-byte" also since that probably is more useful to >> developers. > > One other comment is that I think the get methods of > ChaCha20ParameterSpec should be final. There should be no reason to > override those methods and it will help ensure that the contract of > those methods are not being overridden by a subclass incorrectly. > > --Sean From valerie.peng at oracle.com Thu Apr 26 21:58:23 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 26 Apr 2018 14:58:23 -0700 Subject: RFR (+CSR) 8201627: Kerberos sequence number issues In-Reply-To: <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com> References: <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com> <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com> <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com> <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com> <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com> Message-ID: Sure, should be fine... Valerie On 4/25/2018 9:48 PM, Weijun Wang wrote: > I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11. > > --Max > >> On Apr 26, 2018, at 12:06 AM, Weijun Wang wrote: >> >> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words >> >> * Workaround implementation incompatibilities by not generating >> * initial sequence numbers greater than 2^30 >> >> So bad thing could only happen after 2^30 messages. >> >> --Max >> >>> On Apr 25, 2018, at 10:38 PM, Weijun Wang wrote: >>> >>> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2]. >>> >>> I'll do more experiments. >>> >>> Thanks >>> Max >>> >>> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76 >>> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825 >>> >>>> On Apr 24, 2018, at 8:55 PM, Wang Weijun wrote: >>>> >>>> RFC 4120 5.5.1 has >>>>> seq-number >>>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1. >>>> >>>> If it wraps, then it?s 4 bytes. >>>> >>>> I will read more on it. >>>> >>>> Thanks >>>> Max >>>> >>>>> ? 2018?4?24??18:08?Valerie Peng ??? >>>>> >>>>> Hi Max, >>>>> >>>>> Most changes look good. I have only some comments and questions (see below): >>>>> >>>>> - InitSecContextToken.java, line 62: bad -> unrecognized? >>>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number? >>>>> >>>>> CSR looks good to me. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> >>>>> >>>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote: >>>>>> Please take a review of this fix: >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814 >>>>>> >>>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone. >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> From weijun.wang at oracle.com Fri Apr 27 16:56:03 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 27 Apr 2018 12:56:03 -0400 Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 Message-ID: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8202299/webrev.00/ Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac. Thanks Max p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0]. p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice. From ecki at zusammenkunft.net Fri Apr 27 17:10:02 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 27 Apr 2018 17:10:02 +0000 Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 In-Reply-To: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com> References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com> Message-ID: Hello, Is the following comment correct, it looks like it should read ?with NUL terminator? instead? // without a NULL terminator Greetings Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ From: security-dev on behalf of Weijun Wang Sent: Friday, April 27, 2018 6:56:03 PM To: security-dev at openjdk.java.net Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016 Please take a look at http://cr.openjdk.java.net/~weijun/8202299/webrev.00/ Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac. Thanks Max p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0]. p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamil.j.nimeh at oracle.com Fri Apr 27 21:21:08 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 27 Apr 2018 14:21:08 -0700 Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations In-Reply-To: <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com> References: <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com> <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com> Message-ID: Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff mostly: * Added words in the description of javax.crypto.Cipher recommending callers reinitialize the Cipher to use different nonces after each complete encryption or decryption (similar language to what exists already for AES-GCM encryption). * Added an additional test case for ChaCha20NoReuse * Made accessor methods for ChaCha20ParameterSpec final and cleaned up the code a bit based on comments from the field. http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/ Thanks! --Jamil On 04/13/2018 11:59 AM, Jamil Nimeh wrote: > Round 3 of updates for ChaCha20 and ChaCha20-Poly1305: > > * Removed the key field in ChaCha20 and Poly1305 implementations and > only retain the key bytes as an object field (thanks Thomas for > catching this) > > * Added additional protections against key/nonce reuse.? This is a > behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of > these ciphers will no longer allow you to do subsequent > doUpdate/doFinal calls after the first doFinal without re-initializing > the cipher with either a new key or nonce. Attempting to reuse the > cipher without a new initialization will throw an > IllegalStateException.? This is similar to the behavior of AES-GCM in > encrypt mode, but for ChaCha20 it needs to be done for both encrypt > and decrypt. > > http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/ > > Thanks, > --Jamil > > On 04/10/2018 03:34 PM, Jamil Nimeh wrote: >> Hello everyone, >> >> This is a quick update to the previous webrev: >> >> * When using the form of engineInit that does only takes op, key and >> random, the nonce will always be random even if the random parameter >> is null.? A default instance of SecureRandom will be used to create >> the nonce in this case, instead of all zeroes. >> >> * Unused debug code was removed from the ChaCha20Cipher.java file >> >> * ChaCha20Parameters.engineToString no longer obtains the line >> separator from a System property directly.? It calls >> System.lineSeparator() similar to how other AlgorithmParameter >> classes in com.sun.crypto.provider do it. >> >> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/ >> >> Thanks, >> >> --Jamil >> >> >> On 03/26/2018 12:08 PM, Jamil Nimeh wrote: >>> Hello all, >>> >>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 >>> cipher implementations.? Links to the webrev and the JEP which >>> outlines the characteristics and behavior of the ciphers are listed >>> below. >>> >>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/ >>> http://openjdk.java.net/jeps/329 >>> >>> Thanks, >>> --Jamil >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Fri Apr 27 23:27:01 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 27 Apr 2018 16:27:01 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> Message-ID: <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com> Hi Brad, Thanks for the pointer on netbeans, I will use it to catch stylistic issues later. I updated the changes with most of your comments except those very minor ones (i.e. finish with . or not). Please find comments below: On 4/13/2018 12:25 PM, Bradford Wetmore wrote: > > PSSParameterSpec.java > --------------------- > Maybe add trailerFieldBC(1)? Not sure what do u want me to add. A constants for TrailerFieldBC, or else? > 157/202: We talked about this in person, but I wanted to mention here > for a wider audience.? I had concerns about this typo, and any interop > problems this might bring.? I looked over the Bouncy Castle impl, and > it appears as though they also assumed it to be bytes, not bits.? Can > you check with the other vendors who might have their own PSS > implementations and verify this is not going to be a problem?? I > talked with our CSR lead (Joe Darcy), he doesn't think it should be a > problem if other impls are using bytes. Thanks for checking on BouncyCastle, given the default is stated in the class javadoc to be 20 and the norm is to use byte as the unit, I feel the chance of other vendors using bits are very low. We can remind other vendors about this typo, but we should fix this regardless. > > RSAPrivateCrtKeySpec.java > ------------------------- > 60/88:? Do you want to add v1.2? > I think you mean v2.2. Actually, I prefer to only mention the version information in class javadoc. Easier to maintain this way. So, I actually removed the version info from the method javadoc of other classes for consistency. > > SunRsaSignEntries.java > ---------------------- > 145:? Where did you come up with this convention for your aliases? > > ??? SHA1withRSA-PSS > > I see Bouncy Castle[1] and Android[2] are both using: > > ??? SHA*withRSA/PSS > ??? RSASSA-PSS (name from PKCS#1) > > [1] > https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java > [2] https://developer.android.com/reference/java/security/Signature.html > I removed the withRSA-PSS aliasses and am considering removing the withRSAandMGF1 impls. The RSA-PSS (or RSASSA-PSS) scheme in PKCS#1 v2.2 passes in the digest as part of signature parameters (required) at runtime. Also, the oid corresponds to RSA-PSS unlike in PKCS#1 v1.5 where oid is defined for each digest with RSA signature scheme. So, I am having second thought on supporting the withRSAandMGF1 names. The RSA-PSS signature impl code can use less checks if we don't support these "friendly" names. As for the standard name, I didn't want to use RSA/PSS as the Cipher transformation string uses "/" in its syntax. As for RSASSA-PSS, it is also a little different from what we normally use. I don't have a strong preference on names though. I can change it to whatever the groups' preference is. Thanks, Valerie > > > On 3/27/2018 6:40 PM, Valerie Peng wrote: >> Hi Brad, >> >> Can you please help review the changes for RSA-PSS support? I also >> added some minor enhancement which add 2 more digest algorithms for >> OAEP padding. >> There are quite some changes involved. The main changes are in the >> SunRsaSign provider, i.e. sun.security.rsa packages. I reused >> existing RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl >> classes as much as possible. However, given that RSA-PSS signatures >> requires parameters, I put its implementation in a separate class, >> i.e. RSAPSSSignature.java. >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8146293 >> Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/ >> >> Existing and new regression tests have been run and result looks fine. >> Thanks, >> Valerie From valerie.peng at oracle.com Fri Apr 27 23:41:58 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 27 Apr 2018 16:41:58 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> Message-ID: <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> I'd also strongly prefer to pick one as standard name for RSA PSS signature and use it consistently. Here are the possible choices for RSA PSS standard names: 1. RSA-PSS 2. RSASSA-PSS 3. RSA/PSS 4. RSAPSS #1,#2 are from 3rd party provider, #3 is what I have in current webrev, #4 is just a new alternative in case people may prefer it over #1. My preference is #1, #2, and #4. My reason for steering away from #3 is due to that "/" is used by Cipher transformation string. Though Signature algorithm is separate from Cipher transformation, but RSA can be used for encryption and having that "/" is potentially very confusing. Comments? Please share your preference soon so I can update the webrev accordingly... Thanks, Valerie On 4/18/2018 11:36 AM, Xuelei Fan wrote: > On 4/18/2018 11:25 AM, Sean Mullan wrote: >> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>> The algorithm name decomposer implementation for algorithm >>> restrictions depends on the pattern: >>> ??? with >>> >>> Using the same "encryption" name for signature and PKCS#1 could be >>> easier for applications if there is a need? to decompose the >>> algorithms. >> >> Hmm, so do you mean this is a problem if you specify the signature >> algorithm as "RSA-PSS" and require that the digest algorithm be >> specified as a parameter to the API? Or something else? Not sure I >> understand you but I have a feeling you are raising a good point ... >> > The concern is from the names BC and Andriod used: > > ???? SHA*withRSA/PSS > ???? RSASSA-PSS (name from PKCS#1) > > The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and > "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map > "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. > Either "SHA*withRSA/PSS"/"RSA/PSS" or "SHA*withRSASSA-PSS"/"RSASSA-PSS". > > Xuelei > >> --Sean >> >>> >>> Xuelei >>> >>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>> SunRsaSignEntries.java >>>>> ---------------------- >>>>> 145:? Where did you come up with this convention for your aliases? >>>>> >>>>> ???? SHA1withRSA-PSS >>>>> >>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>> >>>>> ???? SHA*withRSA/PSS >>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>> >>>>> [1] >>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>> >>>>> [2] >>>>> https://developer.android.com/reference/java/security/Signature.html >>>>> >>>>> but we have neither style. >>>> >>>> Since these standard names have not yet been defined, we don't >>>> necessarily have to be consistent, but I don't see a good enough >>>> reason for us to name them differently, so to help with >>>> compatibility I would go with the names above. >>>> >>>> --Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Apr 27 23:51:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 27 Apr 2018 19:51:39 -0400 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: My vote is #1. --Sean On 4/27/18 7:41 PM, Valerie Peng wrote: > > I'd also strongly prefer to pick one as standard name for RSA PSS > signature and use it consistently. > > Here are the possible choices for RSA PSS standard names: > > 1. RSA-PSS > 2. RSASSA-PSS > 3. RSA/PSS > 4. RSAPSS > > #1,#2 are from 3rd party provider, #3 is what I have in current webrev, > #4 is just a new alternative in case people may prefer it over #1. > > My preference is #1, #2, and #4. My reason for steering away from #3 is > due to that "/" is used by Cipher transformation string. Though > Signature algorithm is separate from Cipher transformation, but RSA can > be used for encryption and having that "/" is potentially very confusing. > > Comments? Please share your preference soon so I can update the webrev > accordingly... > > Thanks, > Valerie > > On 4/18/2018 11:36 AM, Xuelei Fan wrote: >> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>> The algorithm name decomposer implementation for algorithm >>>> restrictions depends on the pattern: >>>> ??? with >>>> >>>> Using the same "encryption" name for signature and PKCS#1 could be >>>> easier for applications if there is a need? to decompose the >>>> algorithms. >>> >>> Hmm, so do you mean this is a problem if you specify the signature >>> algorithm as "RSA-PSS" and require that the digest algorithm be >>> specified as a parameter to the API? Or something else? Not sure I >>> understand you but I have a feeling you are raising a good point ... >>> >> The concern is from the names BC and Andriod used: >> >> ???? SHA*withRSA/PSS >> ???? RSASSA-PSS (name from PKCS#1) >> >> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >> Either "SHA*withRSA/PSS"/"RSA/PSS" or "SHA*withRSASSA-PSS"/"RSASSA-PSS". >> >> Xuelei >> >>> --Sean >>> >>>> >>>> Xuelei >>>> >>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>> SunRsaSignEntries.java >>>>>> ---------------------- >>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>> >>>>>> ???? SHA1withRSA-PSS >>>>>> >>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>> >>>>>> ???? SHA*withRSA/PSS >>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>> >>>>>> [1] >>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>> >>>>>> [2] >>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>> >>>>>> but we have neither style. >>>>> >>>>> Since these standard names have not yet been defined, we don't >>>>> necessarily have to be consistent, but I don't see a good enough >>>>> reason for us to name them differently, so to help with >>>>> compatibility I would go with the names above. >>>>> >>>>> --Sean > From jamil.j.nimeh at oracle.com Sat Apr 28 01:31:58 2018 From: jamil.j.nimeh at oracle.com (Jamil Nimeh) Date: Fri, 27 Apr 2018 18:31:58 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: Same here.? It is more recognizable/colloquial than #2 and it looks better with the hyphen vs. #4. --Jamil On 4/27/2018 4:51 PM, Sean Mullan wrote: > My vote is #1. > > --Sean > > On 4/27/18 7:41 PM, Valerie Peng wrote: >> >> I'd also strongly prefer to pick one as standard name for RSA PSS >> signature and use it consistently. >> >> Here are the possible choices for RSA PSS standard names: >> >> ?1. RSA-PSS >> ?2. RSASSA-PSS >> ?3. RSA/PSS >> ?4. RSAPSS >> >> #1,#2 are from 3rd party provider, #3 is what I have in current >> webrev, #4 is just a new alternative in case people may prefer it >> over #1. >> >> My preference is #1, #2, and #4. My reason for steering away from #3 >> is due to that "/" is used by Cipher transformation string. Though >> Signature algorithm is separate from Cipher transformation, but RSA >> can be used for encryption and having that "/" is potentially very >> confusing. >> >> Comments? Please share your preference soon so I can update the >> webrev accordingly... >> >> Thanks, >> Valerie >> >> On 4/18/2018 11:36 AM, Xuelei Fan wrote: >>> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>>> The algorithm name decomposer implementation for algorithm >>>>> restrictions depends on the pattern: >>>>> ??? with >>>>> >>>>> Using the same "encryption" name for signature and PKCS#1 could be >>>>> easier for applications if there is a need? to decompose the >>>>> algorithms. >>>> >>>> Hmm, so do you mean this is a problem if you specify the signature >>>> algorithm as "RSA-PSS" and require that the digest algorithm be >>>> specified as a parameter to the API? Or something else? Not sure I >>>> understand you but I have a feeling you are raising a good point ... >>>> >>> The concern is from the names BC and Andriod used: >>> >>> ???? SHA*withRSA/PSS >>> ???? RSASSA-PSS (name from PKCS#1) >>> >>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >>> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >>> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >>> Either "SHA*withRSA/PSS"/"RSA/PSS" or >>> "SHA*withRSASSA-PSS"/"RSASSA-PSS". >>> >>> Xuelei >>> >>>> --Sean >>>> >>>>> >>>>> Xuelei >>>>> >>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>>> SunRsaSignEntries.java >>>>>>> ---------------------- >>>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>>> >>>>>>> ???? SHA1withRSA-PSS >>>>>>> >>>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>>> >>>>>>> ???? SHA*withRSA/PSS >>>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>>> >>>>>>> [2] >>>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>>> >>>>>>> >>>>>>> but we have neither style. >>>>>> >>>>>> Since these standard names have not yet been defined, we don't >>>>>> necessarily have to be consistent, but I don't see a good enough >>>>>> reason for us to name them differently, so to help with >>>>>> compatibility I would go with the names above. >>>>>> >>>>>> --Sean >> From bradford.wetmore at oracle.com Sat Apr 28 02:37:53 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 27 Apr 2018 19:37:53 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: <9db4cb97-b253-5dd1-ab5c-88062eb6ea9d@oracle.com> I'm fine with #1. So for Signature, it will only be: map.put("Signature.RSA-PSS", "sun.security.rsa.RSAPSSSignature"); Right? Brad On 4/27/2018 6:31 PM, Jamil Nimeh wrote: > Same here.? It is more recognizable/colloquial than #2 and it looks > better with the hyphen vs. #4. > > --Jamil > > On 4/27/2018 4:51 PM, Sean Mullan wrote: >> My vote is #1. >> >> --Sean >> >> On 4/27/18 7:41 PM, Valerie Peng wrote: >>> >>> I'd also strongly prefer to pick one as standard name for RSA PSS >>> signature and use it consistently. >>> >>> Here are the possible choices for RSA PSS standard names: >>> >>> ?1. RSA-PSS >>> ?2. RSASSA-PSS >>> ?3. RSA/PSS >>> ?4. RSAPSS >>> >>> #1,#2 are from 3rd party provider, #3 is what I have in current >>> webrev, #4 is just a new alternative in case people may prefer it >>> over #1. >>> >>> My preference is #1, #2, and #4. My reason for steering away from #3 >>> is due to that "/" is used by Cipher transformation string. Though >>> Signature algorithm is separate from Cipher transformation, but RSA >>> can be used for encryption and having that "/" is potentially very >>> confusing. >>> >>> Comments? Please share your preference soon so I can update the >>> webrev accordingly... >>> >>> Thanks, >>> Valerie >>> >>> On 4/18/2018 11:36 AM, Xuelei Fan wrote: >>>> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>>>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>>>> The algorithm name decomposer implementation for algorithm >>>>>> restrictions depends on the pattern: >>>>>> ??? with >>>>>> >>>>>> Using the same "encryption" name for signature and PKCS#1 could be >>>>>> easier for applications if there is a need? to decompose the >>>>>> algorithms. >>>>> >>>>> Hmm, so do you mean this is a problem if you specify the signature >>>>> algorithm as "RSA-PSS" and require that the digest algorithm be >>>>> specified as a parameter to the API? Or something else? Not sure I >>>>> understand you but I have a feeling you are raising a good point ... >>>>> >>>> The concern is from the names BC and Andriod used: >>>> >>>> ???? SHA*withRSA/PSS >>>> ???? RSASSA-PSS (name from PKCS#1) >>>> >>>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >>>> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >>>> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >>>> Either "SHA*withRSA/PSS"/"RSA/PSS" or >>>> "SHA*withRSASSA-PSS"/"RSASSA-PSS". >>>> >>>> Xuelei >>>> >>>>> --Sean >>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>>>> SunRsaSignEntries.java >>>>>>>> ---------------------- >>>>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>>>> >>>>>>>> ???? SHA1withRSA-PSS >>>>>>>> >>>>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>>>> >>>>>>>> ???? SHA*withRSA/PSS >>>>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>>>> >>>>>>>> [2] >>>>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>>>> >>>>>>>> >>>>>>>> but we have neither style. >>>>>>> >>>>>>> Since these standard names have not yet been defined, we don't >>>>>>> necessarily have to be consistent, but I don't see a good enough >>>>>>> reason for us to name them differently, so to help with >>>>>>> compatibility I would go with the names above. >>>>>>> >>>>>>> --Sean >>> > From xuelei.fan at oracle.com Sat Apr 28 02:41:50 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 27 Apr 2018 19:41:50 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: I don't like #3 as well, as it looks like "RSA" key get used, and '/' has special meaning when there is a need to parse the algorithm name. I like more of #2 "RSASSA-PSS", as it is the formal name used in RFC 8017, TLS 1.3 and RFC 4056, etc. Xuelei On 4/27/2018 4:41 PM, Valerie Peng wrote: > > I'd also strongly prefer to pick one as standard name for RSA PSS > signature and use it consistently. > > Here are the possible choices for RSA PSS standard names: > > 1. RSA-PSS > 2. RSASSA-PSS > 3. RSA/PSS > 4. RSAPSS > > #1,#2 are from 3rd party provider, #3 is what I have in current webrev, > #4 is just a new alternative in case people may prefer it over #1. > > My preference is #1, #2, and #4. My reason for steering away from #3 is > due to that "/" is used by Cipher transformation string. Though > Signature algorithm is separate from Cipher transformation, but RSA can > be used for encryption and having that "/" is potentially very confusing. > > Comments? Please share your preference soon so I can update the webrev > accordingly... > > Thanks, > Valerie > > On 4/18/2018 11:36 AM, Xuelei Fan wrote: >> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>> The algorithm name decomposer implementation for algorithm >>>> restrictions depends on the pattern: >>>> ??? with >>>> >>>> Using the same "encryption" name for signature and PKCS#1 could be >>>> easier for applications if there is a need? to decompose the >>>> algorithms. >>> >>> Hmm, so do you mean this is a problem if you specify the signature >>> algorithm as "RSA-PSS" and require that the digest algorithm be >>> specified as a parameter to the API? Or something else? Not sure I >>> understand you but I have a feeling you are raising a good point ... >>> >> The concern is from the names BC and Andriod used: >> >> ???? SHA*withRSA/PSS >> ???? RSASSA-PSS (name from PKCS#1) >> >> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >> Either "SHA*withRSA/PSS"/"RSA/PSS" or "SHA*withRSASSA-PSS"/"RSASSA-PSS". >> >> Xuelei >> >>> --Sean >>> >>>> >>>> Xuelei >>>> >>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>> SunRsaSignEntries.java >>>>>> ---------------------- >>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>> >>>>>> ???? SHA1withRSA-PSS >>>>>> >>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>> >>>>>> ???? SHA*withRSA/PSS >>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>> >>>>>> [1] >>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>> >>>>>> [2] >>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>> >>>>>> but we have neither style. >>>>> >>>>> Since these standard names have not yet been defined, we don't >>>>> necessarily have to be consistent, but I don't see a good enough >>>>> reason for us to name them differently, so to help with >>>>> compatibility I would go with the names above. >>>>> >>>>> --Sean > From anthony.scarpino at oracle.com Sat Apr 28 04:00:10 2018 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 27 Apr 2018 21:00:10 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: I'm fine with 1 or 2. Maybe leaning more toward 2 given what Xuelei said about the RFCs. Tony On 04/27/2018 04:41 PM, Valerie Peng wrote: > > I'd also strongly prefer to pick one as standard name for RSA PSS > signature and use it consistently. > > Here are the possible choices for RSA PSS standard names: > > 1. RSA-PSS > 2. RSASSA-PSS > 3. RSA/PSS > 4. RSAPSS > > #1,#2 are from 3rd party provider, #3 is what I have in current webrev, > #4 is just a new alternative in case people may prefer it over #1. > > My preference is #1, #2, and #4. My reason for steering away from #3 is > due to that "/" is used by Cipher transformation string. Though > Signature algorithm is separate from Cipher transformation, but RSA can > be used for encryption and having that "/" is potentially very confusing. > > Comments? Please share your preference soon so I can update the webrev > accordingly... > > Thanks, > Valerie > > On 4/18/2018 11:36 AM, Xuelei Fan wrote: >> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>> The algorithm name decomposer implementation for algorithm >>>> restrictions depends on the pattern: >>>> ??? with >>>> >>>> Using the same "encryption" name for signature and PKCS#1 could be >>>> easier for applications if there is a need? to decompose the >>>> algorithms. >>> >>> Hmm, so do you mean this is a problem if you specify the signature >>> algorithm as "RSA-PSS" and require that the digest algorithm be >>> specified as a parameter to the API? Or something else? Not sure I >>> understand you but I have a feeling you are raising a good point ... >>> >> The concern is from the names BC and Andriod used: >> >> ???? SHA*withRSA/PSS >> ???? RSASSA-PSS (name from PKCS#1) >> >> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >> Either "SHA*withRSA/PSS"/"RSA/PSS" or "SHA*withRSASSA-PSS"/"RSASSA-PSS". >> >> Xuelei >> >>> --Sean >>> >>>> >>>> Xuelei >>>> >>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>> SunRsaSignEntries.java >>>>>> ---------------------- >>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>> >>>>>> ???? SHA1withRSA-PSS >>>>>> >>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>> >>>>>> ???? SHA*withRSA/PSS >>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>> >>>>>> [1] >>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>> >>>>>> [2] >>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>> >>>>>> but we have neither style. >>>>> >>>>> Since these standard names have not yet been defined, we don't >>>>> necessarily have to be consistent, but I don't see a good enough >>>>> reason for us to name them differently, so to help with >>>>> compatibility I would go with the names above. >>>>> >>>>> --Sean > From claes.redestad at oracle.com Mon Apr 30 12:25:03 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 14:25:03 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early Message-ID: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Hi, moving a couple of local permission constants to sun.security.util.SecurityConstants ensures we delay and avoid loading permission classes very early during bootstrap. Delaying load is profitable since it's happening early enough (before System.initPhase1) to contribute to delaying the initialization of VM subsystems. Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ Thanks! /Claes From Alan.Bateman at oracle.com Mon Apr 30 12:47:41 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Apr 2018 13:47:41 +0100 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> On 30/04/2018 13:25, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before > System.initPhase1) to contribute to delaying the initialization of VM > subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ This looks okay to me. Just a few nits - the comment from AccessibleObject has moved to SecurityConstants. I think it would be better to leave the comment in AccessibleObject, then you can just comment the SecurityConstants update with the class name so that it's consistent with the other constants. Also this class uses 4-space indent so best to keep that consistent too. -Alan From claes.redestad at oracle.com Mon Apr 30 12:58:29 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 14:58:29 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> <3e19a15e-d2e5-c734-3b54-504d2333a44f@oracle.com> Message-ID: On 2018-04-30 14:47, Alan Bateman wrote: > This looks okay to me. Thanks! > > Just a few nits - the comment from AccessibleObject has moved to > SecurityConstants. I think it would be better to leave the comment in > AccessibleObject, then you can just comment the SecurityConstants > update with the class name so that it's consistent with the other > constants. Also this class uses 4-space indent so best to keep that > consistent too. http://cr.openjdk.java.net/~redestad/8202419/open.01/ ? /Claes From sean.mullan at oracle.com Mon Apr 30 13:05:26 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Apr 2018 09:05:26 -0400 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> Looks fine to me. I think the TO DO comment on line 131 of ReflectionFactory can be removed - it looks like a leftover comment which doesn't seem relevant anymore. --Sean On 4/30/18 8:25 AM, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before System.initPhase1) > to contribute to delaying the initialization of VM subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Apr 30 13:11:08 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 30 Apr 2018 15:11:08 +0200 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> <523d1159-ecc9-42ee-bea9-cca7629a549a@oracle.com> Message-ID: <6e15e3c0-d4ce-9fb0-a23b-2a19ce8361fa@oracle.com> On 2018-04-30 15:05, Sean Mullan wrote: > Looks fine to me. Thanks! > I think the TO DO comment on line 131 of ReflectionFactory can be > removed - it looks like a leftover comment which doesn't seem relevant > anymore. Sure /Claes From mandy.chung at oracle.com Mon Apr 30 16:34:26 2018 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 1 May 2018 00:34:26 +0800 Subject: RFR: 8202419: Avoid creating Permission constants early In-Reply-To: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> References: <85f31369-ba35-5d60-0d8c-cca0a3fd9598@oracle.com> Message-ID: On 4/30/18 8:25 PM, Claes Redestad wrote: > Hi, > > moving a couple of local permission constants to > sun.security.util.SecurityConstants ensures we delay and avoid loading > permission classes very early during bootstrap. Delaying load is > profitable since it's happening early enough (before > System.initPhase1) to contribute to delaying the initialization of VM > subsystems. > > Webrev: http://cr.openjdk.java.net/~redestad/8202419/open.00/ Looks okay to me. I agree with Alan and Sean w.r.t. to the comment in ACCESS_PERMISSION that would be better to keep it in AccessibleObject::checkPermission and remove line 131 in ReflectionFactory. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Mon Apr 30 18:40:57 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Apr 2018 11:40:57 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: I reordered the names and missed to update some of the description. #2 and #3 are from 3rd party providers. #1 is what I have in the webrev, #4 is just a new alternative in case people may prefer it over #1. Can you all please re-confirm your preference is? Thanks! Valerie On 4/27/2018 4:51 PM, Sean Mullan wrote: > My vote is #1. > > --Sean > > On 4/27/18 7:41 PM, Valerie Peng wrote: >> >> I'd also strongly prefer to pick one as standard name for RSA PSS >> signature and use it consistently. >> >> Here are the possible choices for RSA PSS standard names: >> >> ?1. RSA-PSS >> ?2. RSASSA-PSS >> ?3. RSA/PSS >> ?4. RSAPSS >> >> #1,#2 are from 3rd party provider, #3 is what I have in current >> webrev, #4 is just a new alternative in case people may prefer it >> over #1. >> >> My preference is #1, #2, and #4. My reason for steering away from #3 >> is due to that "/" is used by Cipher transformation string. Though >> Signature algorithm is separate from Cipher transformation, but RSA >> can be used for encryption and having that "/" is potentially very >> confusing. >> >> Comments? Please share your preference soon so I can update the >> webrev accordingly... >> >> Thanks, >> Valerie >> >> On 4/18/2018 11:36 AM, Xuelei Fan wrote: >>> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>>> The algorithm name decomposer implementation for algorithm >>>>> restrictions depends on the pattern: >>>>> ??? with >>>>> >>>>> Using the same "encryption" name for signature and PKCS#1 could be >>>>> easier for applications if there is a need? to decompose the >>>>> algorithms. >>>> >>>> Hmm, so do you mean this is a problem if you specify the signature >>>> algorithm as "RSA-PSS" and require that the digest algorithm be >>>> specified as a parameter to the API? Or something else? Not sure I >>>> understand you but I have a feeling you are raising a good point ... >>>> >>> The concern is from the names BC and Andriod used: >>> >>> ???? SHA*withRSA/PSS >>> ???? RSASSA-PSS (name from PKCS#1) >>> >>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >>> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >>> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >>> Either "SHA*withRSA/PSS"/"RSA/PSS" or >>> "SHA*withRSASSA-PSS"/"RSASSA-PSS". >>> >>> Xuelei >>> >>>> --Sean >>>> >>>>> >>>>> Xuelei >>>>> >>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>>> SunRsaSignEntries.java >>>>>>> ---------------------- >>>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>>> >>>>>>> ???? SHA1withRSA-PSS >>>>>>> >>>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>>> >>>>>>> ???? SHA*withRSA/PSS >>>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>>> >>>>>>> [2] >>>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>>> >>>>>>> >>>>>>> but we have neither style. >>>>>> >>>>>> Since these standard names have not yet been defined, we don't >>>>>> necessarily have to be consistent, but I don't see a good enough >>>>>> reason for us to name them differently, so to help with >>>>>> compatibility I would go with the names above. >>>>>> >>>>>> --Sean >> From ivan.gerasimov at oracle.com Mon Apr 30 19:16:34 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 30 Apr 2018 12:16:34 -0700 Subject: [8u-dev] 8193171 : keytool -list displays "JKS" for a PKCS12 keystore Message-ID: <6952bad9-e230-8dce-be2d-2bb8f22c0b4c@oracle.com> Hello! This is 8u-dev only bug fix. It was noticed that the keytool from the latest JDK 8 update release displays type of PKCS12 keystore as JKS. Would you please help review the patch? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8193171 WEBREV: http://cr.openjdk.java.net/~igerasim/8193171/00/webrev/ Thanks in advance! -- With kind regards, Ivan Gerasimov From xuelei.fan at oracle.com Mon Apr 30 19:27:26 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Apr 2018 12:27:26 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: <4df67291-a305-df83-90a5-4cc1d76cbd53@oracle.com> #2. Otherwise, please don't use #3. Xuelei On 4/30/2018 11:40 AM, Valerie Peng wrote: > > I reordered the names and missed to update some of the description. > > #2 and #3 are from 3rd party providers. #1 is what I have in the webrev, > #4 is just a new alternative in case people may prefer it over #1. > > Can you all please re-confirm your preference is? > Thanks! > Valerie > > On 4/27/2018 4:51 PM, Sean Mullan wrote: >> My vote is #1. >> >> --Sean >> >> On 4/27/18 7:41 PM, Valerie Peng wrote: >>> >>> I'd also strongly prefer to pick one as standard name for RSA PSS >>> signature and use it consistently. >>> >>> Here are the possible choices for RSA PSS standard names: >>> >>> ?1. RSA-PSS >>> ?2. RSASSA-PSS >>> ?3. RSA/PSS >>> ?4. RSAPSS >>> >>> #1,#2 are from 3rd party provider, #3 is what I have in current >>> webrev, #4 is just a new alternative in case people may prefer it >>> over #1. >>> >>> My preference is #1, #2, and #4. My reason for steering away from #3 >>> is due to that "/" is used by Cipher transformation string. Though >>> Signature algorithm is separate from Cipher transformation, but RSA >>> can be used for encryption and having that "/" is potentially very >>> confusing. >>> >>> Comments? Please share your preference soon so I can update the >>> webrev accordingly... >>> >>> Thanks, >>> Valerie >>> >>> On 4/18/2018 11:36 AM, Xuelei Fan wrote: >>>> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>>>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>>>> The algorithm name decomposer implementation for algorithm >>>>>> restrictions depends on the pattern: >>>>>> ??? with >>>>>> >>>>>> Using the same "encryption" name for signature and PKCS#1 could be >>>>>> easier for applications if there is a need? to decompose the >>>>>> algorithms. >>>>> >>>>> Hmm, so do you mean this is a problem if you specify the signature >>>>> algorithm as "RSA-PSS" and require that the digest algorithm be >>>>> specified as a parameter to the API? Or something else? Not sure I >>>>> understand you but I have a feeling you are raising a good point ... >>>>> >>>> The concern is from the names BC and Andriod used: >>>> >>>> ???? SHA*withRSA/PSS >>>> ???? RSASSA-PSS (name from PKCS#1) >>>> >>>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >>>> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >>>> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >>>> Either "SHA*withRSA/PSS"/"RSA/PSS" or >>>> "SHA*withRSASSA-PSS"/"RSASSA-PSS". >>>> >>>> Xuelei >>>> >>>>> --Sean >>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>>>> SunRsaSignEntries.java >>>>>>>> ---------------------- >>>>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>>>> >>>>>>>> ???? SHA1withRSA-PSS >>>>>>>> >>>>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>>>> >>>>>>>> ???? SHA*withRSA/PSS >>>>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>>>> >>>>>>>> [2] >>>>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>>>> >>>>>>>> >>>>>>>> but we have neither style. >>>>>>> >>>>>>> Since these standard names have not yet been defined, we don't >>>>>>> necessarily have to be consistent, but I don't see a good enough >>>>>>> reason for us to name them differently, so to help with >>>>>>> compatibility I would go with the names above. >>>>>>> >>>>>>> --Sean >>> > From bradford.wetmore at oracle.com Mon Apr 30 19:27:50 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 30 Apr 2018 12:27:50 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: Xuelei/Tony changed my mind. I'm now more preferring #2, since it's in a 3rd party already. I'd still be happy with #1. Brad On 4/30/2018 11:40 AM, Valerie Peng wrote: > > I reordered the names and missed to update some of the description. > > #2 and #3 are from 3rd party providers. #1 is what I have in the webrev, > #4 is just a new alternative in case people may prefer it over #1. > > Can you all please re-confirm your preference is? > Thanks! > Valerie > > On 4/27/2018 4:51 PM, Sean Mullan wrote: >> My vote is #1. >> >> --Sean >> >> On 4/27/18 7:41 PM, Valerie Peng wrote: >>> >>> I'd also strongly prefer to pick one as standard name for RSA PSS >>> signature and use it consistently. >>> >>> Here are the possible choices for RSA PSS standard names: >>> >>> ?1. RSA-PSS >>> ?2. RSASSA-PSS >>> ?3. RSA/PSS >>> ?4. RSAPSS >>> >>> #1,#2 are from 3rd party provider, #3 is what I have in current >>> webrev, #4 is just a new alternative in case people may prefer it >>> over #1. >>> >>> My preference is #1, #2, and #4. My reason for steering away from #3 >>> is due to that "/" is used by Cipher transformation string. Though >>> Signature algorithm is separate from Cipher transformation, but RSA >>> can be used for encryption and having that "/" is potentially very >>> confusing. >>> >>> Comments? Please share your preference soon so I can update the >>> webrev accordingly... >>> >>> Thanks, >>> Valerie >>> >>> On 4/18/2018 11:36 AM, Xuelei Fan wrote: >>>> On 4/18/2018 11:25 AM, Sean Mullan wrote: >>>>> On 4/18/18 12:52 PM, Xuelei Fan wrote: >>>>>> The algorithm name decomposer implementation for algorithm >>>>>> restrictions depends on the pattern: >>>>>> ??? with >>>>>> >>>>>> Using the same "encryption" name for signature and PKCS#1 could be >>>>>> easier for applications if there is a need? to decompose the >>>>>> algorithms. >>>>> >>>>> Hmm, so do you mean this is a problem if you specify the signature >>>>> algorithm as "RSA-PSS" and require that the digest algorithm be >>>>> specified as a parameter to the API? Or something else? Not sure I >>>>> understand you but I have a feeling you are raising a good point ... >>>>> >>>> The concern is from the names BC and Andriod used: >>>> >>>> ???? SHA*withRSA/PSS >>>> ???? RSASSA-PSS (name from PKCS#1) >>>> >>>> The signature algorithm decomposing SHA*withRSA/PSS and "SHA*" and >>>> "RSA/PSS".? If the PKCS#1 name use "RSASSA-PSS", it is tricky to map >>>> "RSA/PSS" to "RSASSA-PSS".? I'm suggesting use a consistent name. >>>> Either "SHA*withRSA/PSS"/"RSA/PSS" or >>>> "SHA*withRSASSA-PSS"/"RSASSA-PSS". >>>> >>>> Xuelei >>>> >>>>> --Sean >>>>> >>>>>> >>>>>> Xuelei >>>>>> >>>>>> On 4/16/2018 11:40 AM, Sean Mullan wrote: >>>>>>> On 4/13/18 3:25 PM, Bradford Wetmore wrote: >>>>>>>> SunRsaSignEntries.java >>>>>>>> ---------------------- >>>>>>>> 145:? Where did you come up with this convention for your aliases? >>>>>>>> >>>>>>>> ???? SHA1withRSA-PSS >>>>>>>> >>>>>>>> I see Bouncy Castle[1] and Android[2] are both using: >>>>>>>> >>>>>>>> ???? SHA*withRSA/PSS >>>>>>>> ???? RSASSA-PSS (name from PKCS#1) >>>>>>>> >>>>>>>> [1] >>>>>>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java >>>>>>>> >>>>>>>> [2] >>>>>>>> https://developer.android.com/reference/java/security/Signature.html >>>>>>>> >>>>>>>> >>>>>>>> but we have neither style. >>>>>>> >>>>>>> Since these standard names have not yet been defined, we don't >>>>>>> necessarily have to be consistent, but I don't see a good enough >>>>>>> reason for us to name them differently, so to help with >>>>>>> compatibility I would go with the names above. >>>>>>> >>>>>>> --Sean >>> > From sean.mullan at oracle.com Mon Apr 30 19:37:38 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Apr 2018 15:37:38 -0400 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> Message-ID: <097a9a94-46c8-5782-1a83-a2f78665abaf@oracle.com> On 4/30/18 3:27 PM, Bradford Wetmore wrote: > Xuelei/Tony changed my mind.? I'm now more preferring #2, since it's in > a 3rd party already.? I'd still be happy with #1. > > Brad > > > On 4/30/2018 11:40 AM, Valerie Peng wrote: >> >> I reordered the names and missed to update some of the description. >> >> #2 and #3 are from 3rd party providers. #1 is what I have in the >> webrev, #4 is just a new alternative in case people may prefer it over >> #1. >> >> Can you all please re-confirm your preference is? I also now think #2 is more appropriate than #1 even though it is longer. My change of mind is based on the RFCs using that name. --Sean >> Thanks! >> Valerie >> >> On 4/27/2018 4:51 PM, Sean Mullan wrote: >>> My vote is #1. >>> >>> --Sean >>> >>> On 4/27/18 7:41 PM, Valerie Peng wrote: >>>> >>>> I'd also strongly prefer to pick one as standard name for RSA PSS >>>> signature and use it consistently. >>>> >>>> Here are the possible choices for RSA PSS standard names: >>>> >>>> ?1. RSA-PSS >>>> ?2. RSASSA-PSS >>>> ?3. RSA/PSS >>>> ?4. RSAPSS From valerie.peng at oracle.com Mon Apr 30 20:59:35 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 30 Apr 2018 13:59:35 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <097a9a94-46c8-5782-1a83-a2f78665abaf@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <16644943-0dbc-2366-f1fe-f3a18f22558e@oracle.com> <621bce5a-edf5-29d3-e6fe-2a5bc9497df8@oracle.com> <4762f41c-cc81-fb9c-5752-4f835752567e@oracle.com> <22bba7fa-9e7e-f163-65dc-3118e405a939@oracle.com> <097a9a94-46c8-5782-1a83-a2f78665abaf@oracle.com> Message-ID: <40756827-cf86-d341-40ef-1e04c0c92337@oracle.com> Alright, it seems majority prefers RSASSA-PSS. I will update the webrev and CSR accordingly. Valerie On 4/30/2018 12:37 PM, Sean Mullan wrote: > On 4/30/18 3:27 PM, Bradford Wetmore wrote: >> Xuelei/Tony changed my mind.? I'm now more preferring #2, since it's >> in a 3rd party already.? I'd still be happy with #1. >> >> Brad >> >> >> On 4/30/2018 11:40 AM, Valerie Peng wrote: >>> >>> I reordered the names and missed to update some of the description. >>> >>> #2 and #3 are from 3rd party providers. #1 is what I have in the >>> webrev, #4 is just a new alternative in case people may prefer it >>> over #1. >>> >>> Can you all please re-confirm your preference is? > > I also now think #2 is more appropriate than #1 even though it is > longer. My change of mind is based on the RFCs using that name. > > --Sean > >>> Thanks! >>> Valerie >>> >>> On 4/27/2018 4:51 PM, Sean Mullan wrote: >>>> My vote is #1. >>>> >>>> --Sean >>>> >>>> On 4/27/18 7:41 PM, Valerie Peng wrote: >>>>> >>>>> I'd also strongly prefer to pick one as standard name for RSA PSS >>>>> signature and use it consistently. >>>>> >>>>> Here are the possible choices for RSA PSS standard names: >>>>> >>>>> ?1. RSA-PSS >>>>> ?2. RSASSA-PSS >>>>> ?3. RSA/PSS >>>>> ?4. RSAPSS