From naoto at openjdk.org Mon Aug 1 16:46:01 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 1 Aug 2022 16:46:01 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk19/pull/154 From duke at openjdk.org Mon Aug 1 22:29:46 2022 From: duke at openjdk.org (Neustradamus) Date: Mon, 1 Aug 2022 22:29:46 GMT Subject: RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos [v2] In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 20:19:21 GMT, Alexey Bakhtin wrote: >> Hi, >> >> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support for Java GSS/Kerberos. >> Initial review is available at core-devs: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html >> This version removes "tls-unique" CB type from the list of possible channel binding types. The only supported type is "tls-server-end-point" >> >> CSR is also updated : https://bugs.openjdk.java.net/browse/JDK-8247311 >> >> Thank you >> Alexey > > Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: > > 8245527: version.01 @alexeybakhtin: It is official for TLS 1.3 Binding! - RFC 9266: Channel Bindings for TLS 1.3: https://tools.ietf.org/html/rfc9266 Details: - tls-unique for TLS =< 1.2 - tls-exporter for TLS = 1.3 Can you look to add it? Thanks in advance. ------------- PR: https://git.openjdk.org/jdk/pull/278 From weijun at openjdk.org Mon Aug 1 22:31:04 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 1 Aug 2022 22:31:04 GMT Subject: Integrated: 8282730: LdapLoginModule throw NPE from logout method after login failure In-Reply-To: References: Message-ID: On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang wrote: > Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`. This pull request has now been integrated. Changeset: 554f44ec Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/554f44ecb1134acff3eaf02e2e1c0e01158ab7e5 Stats: 223 lines in 11 files changed: 151 ins; 2 del; 70 mod 8282730: LdapLoginModule throw NPE from logout method after login failure Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/9348 From duke at openjdk.org Tue Aug 2 05:54:13 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 2 Aug 2022 05:54:13 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment to change the test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/b91e7554..3bce8d96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=01-02 Stats: 842 lines in 6 files changed: 103 ins; 739 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From bradford.wetmore at oracle.com Tue Aug 2 21:55:59 2022 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Tue, 2 Aug 2022 14:55:59 -0700 Subject: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression In-Reply-To: <2b0e381c-d41d-2b03-238e-cf2d4af4201c@oracle.com> References: <2b0e381c-d41d-2b03-238e-cf2d4af4201c@oracle.com> Message-ID: <8c1fadcd-6613-02a8-db38-a2fc1b195563@oracle.com> Hi Xuelei, Sean wrote: > I haven't had time to look at this in detail yet. I would like a > couple more weeks to review the draft. We've been looking closely at RFC 8879 and your proposal to add support into JSSE. I think we're in agreement that this would be a good addition for the reasons you outline. We are currently busy with some high-priority projects so reviewing this JEP will need more time. This means that we'll need to wait a release or two for proper and thorough discussion and review. Timeline wise this is reasonable as other TLS implementations such as OpenSSL and GoLang are at a similar assessment stage [1][2]. On the technical side, while having a pluggable API for supporting different/additional compression types has its merits, my preference is to have some/all of these compression types directly supported within JSSE so that this works out-of-the-box, and developers don't introduce unexpected/hard-to-debug compression errors. Otherwise everyone would have to copy the same compression code everywhere. Seems a bit painful when a simple implementation could be provided that works for many/most. The other big benefit is that this will allow for trivial backports as no API will be needed for earlier releases. When more implementations start supporting this Certificate Compression RFC, I think Zlib might be the most widely used. Adding the ZLIB extension seems a natural first target as there is already an implementation in JDK, and you demonstrated how easy encoding in ZLIB is. I see Chrome already has brotli, and zstd seems like it would be a faster algorithm with tighter compression, though without prototyping, I'm not sure how much gain we'll get with smallish cert chains (i.e. 10's of kb) vs. large data sets that I've seen numbers for[3]. Patrick McManus/Fastly felt anecdotally that the difference between the three wasn't that different, compared to not having compression at all. The TLS certificate compression specification allows any of the deflate, brotli, or zstd formats for compression. Anecdotally, the differences between them were very small compared to the difference between compressed and uncompressed representations. [4] Brad [1] https://github.com/openssl/openssl/issues/13597 [2] https://github.com/golang/go/issues/42967 [3] https://facebook.github.io/zstd/ [4] https://www.fastly.com/blog/quic-handshake-tls-compression-certificates-extension-study From xuelei.f at gmail.com Wed Aug 3 02:53:19 2022 From: xuelei.f at gmail.com (Xuelei Fan) Date: Tue, 2 Aug 2022 19:53:19 -0700 Subject: [Internet]Re: Re: Re: JEP Review Request: TLS Certificate Compression In-Reply-To: <8c1fadcd-6613-02a8-db38-a2fc1b195563@oracle.com> References: <2b0e381c-d41d-2b03-238e-cf2d4af4201c@oracle.com> <8c1fadcd-6613-02a8-db38-a2fc1b195563@oracle.com> Message-ID: <6D8F2B44-D17F-424E-853C-743834C2F0C4@gmail.com> > On Aug 2, 2022, at 2:55 PM, Bradford Wetmore wrote: > > Hi Xuelei, > > Sean wrote: > >> I haven't had time to look at this in detail yet. I would like a >> couple more weeks to review the draft. > > We've been looking closely at RFC 8879 and your proposal to add support into JSSE. I think we're in agreement that this would be a good addition for the reasons you outline. > > We are currently busy with some high-priority projects so reviewing this JEP will need more time. This means that we'll need to wait a release or two for proper and thorough discussion and review. Timeline wise this is reasonable as other TLS implementations such as OpenSSL and GoLang are at a similar assessment stage [1][2]. Thanks for the feedback. The timeline sounds reasonable to me. > > On the technical side, while having a pluggable API for supporting different/additional compression types has its merits, my preference is to have some/all of these compression types directly supported within JSSE so that this works out-of-the-box, and developers don't introduce unexpected/hard-to-debug compression errors. Otherwise everyone would have to copy the same compression code everywhere. Seems a bit painful when a simple implementation could be provided that works for many/most. The other big benefit is that this will allow for trivial backports as no API will be needed for earlier releases. > It?s fine to me to add default compression implementations, while we are keeping the flexibility for customization. I may come back for a revised design at around version 22. > When more implementations start supporting this Certificate Compression RFC, I think Zlib might be the most widely used. Adding the ZLIB extension seems a natural first target as there is already an implementation in JDK, and you demonstrated how easy encoding in ZLIB is. I see Chrome already has brotli, and zstd seems like it would be a faster algorithm with tighter compression, though without prototyping, I'm not sure how much gain we'll get with smallish cert chains (i.e. 10's of kb) vs. large data sets that I've seen numbers for[3]. Patrick McManus/Fastly felt anecdotally that the difference between the three wasn't that different, compared to not having compression at all. > > The TLS certificate compression specification allows any of the > deflate, brotli, or zstd formats for compression. Anecdotally, the > differences between them were very small compared to the difference > between compressed and uncompressed representations. [4] > I?m not sure if the performance really plays a critical role in practice. The support of compression algorithms could be an impact of interoperability (for example, work with Internet browsers such as Chrome). Thanks for the feedback! Best, Xuelei > Brad > > [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F13597&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916681863507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EGu0LBAOv9KVtgP5ivRjFI9HLLelX4mIVy5raBQm0EU%3D&reserved=0 > [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgolang%2Fgo%2Fissues%2F42967&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916681863507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eOwziZmg2Kee8KdO31pvfiXAzIxOu9plShJ11bngo2I%3D&reserved=0 > [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffacebook.github.io%2Fzstd%2F&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916682019740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TBR0haf0nGvb73pqbzcsbJlUvpSuARCSlgjUMt140As%3D&reserved=0 > [4] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fastly.com%2Fblog%2Fquic-handshake-tls-compression-certificates-extension-study&data=05%7C01%7Cxueleifan%40global.tencent.com%7Cc21799c52d1540bd324b08da74fa8a0a%7Ca32856f21731405cb53d480e26413adf%7C1%7C0%7C637950916682019740%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jmMY1Y4876EvoxfU%2F0XUPUnuEN0z2466JxnQfOC%2BX7k%3D&reserved=0 > > From duke at openjdk.org Wed Aug 3 06:52:55 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 3 Aug 2022 06:52:55 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v2] In-Reply-To: References: Message-ID: On Sat, 16 Jul 2022 13:32:44 GMT, Weijun Wang wrote: >> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test case to verify the patch > > There are quite some JAAS tests inside `test/jdk/javax/security/auth/login` where you can copy. The one you found has a very old copyright header and invalid format (like trailing spaces...). Also, I don't think it's worth implementing a new principal and a new login module. You can just using the out-of-box UnixLoginModule and NTLoginModule. @wangweij I am trying to make use of UnixLoginModule with the new test case added with latest commit. Looks like it turns out to be a positive test case without injecting some wrong `uid` or `gid` etc. I tried to explore how we can programmatically induce a wrong `uid` or `gid` so that the stack trace which is expected to be printed when wrong credentials are fed. Honestly I spent good amount of time and not getting how to get this test case into proper shape? Could you please help? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From mullan at openjdk.org Wed Aug 3 15:03:43 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Aug 2022 15:03:43 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> On Wed, 27 Jul 2022 20:24:19 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8290975 src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java line 130: > 128: * @serial > 129: */ > 130: private final boolean testing = false; This should really use java.security.debug so this tracing can be enabled at runtime, but that's probably more of a separate fix - feel free to file a separate issue. src/java.base/share/classes/javax/security/auth/Subject.java line 28: > 26: package javax.security.auth; > 27: > 28: import sun.security.util.ResourcesMgr; I suggest putting the internal imports below the java.* or other standard imports. This isn't a rule, but is more consistent with other code. src/java.base/share/classes/javax/security/auth/Subject.java line 854: > 852: * > 853: *

If a security manager is installed, the caller must have a > 854: * {@link PrivateCredentialPermission} to access all the requested Hmm. I think the previous text was more correct/readable. src/java.base/share/classes/javax/security/auth/callback/NameCallback.java line 45: > 43: * @since 1.4 > 44: */ > 45: private final String prompt; I think you can also mark `defaultName` final. src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java line 46: > 44: * @since 1.4 > 45: */ > 46: private final String prompt; I think you can also mark `defaultText` final. src/java.base/share/classes/javax/security/auth/x500/X500Principal.java line 94: > 92: * NOTE: The constructor is package private. It is intended to be accessed > 93: * using privileged reflection from classes in sun.security.*. > 94: * Currently, referenced from sun.security.x509.X500Name.asX500Principal(). Change to "Currently, it is referenced from ..." ------------- PR: https://git.openjdk.org/jdk/pull/9664 From weijun at openjdk.org Thu Aug 4 01:43:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 4 Aug 2022 01:43:53 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3] In-Reply-To: References: Message-ID: On Tue, 2 Aug 2022 05:54:13 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment to change the test case I meant you can add **both** `UnixLoginModule` and `NTLoginModule` as OPTIONAL. On Windows, `UnixLoginModule` would fail, and on *nix, `NTLoginModule` will fail. Then you can observe the newly added debug info. BTW, have you reverted your change on `LoginContext.java`. I remembered we agreed that this bug is all about debug info instead of updating the exception thrown. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From jwaters at openjdk.org Thu Aug 4 04:20:58 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 4 Aug 2022 04:20:58 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 17:23:05 GMT, Julian Waters wrote: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. Comment to keep thread alive ------------- PR: https://git.openjdk.org/jdk/pull/9678 From plevart at openjdk.org Thu Aug 4 11:06:40 2022 From: plevart at openjdk.org (Peter Levart) Date: Thu, 4 Aug 2022 11:06:40 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) Message-ID: This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. ------------- Commit messages: - new internal CarrierThreadLocal as a base for TerminatingThreadLocal Changes: https://git.openjdk.org/jdk/pull/9743/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9743&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291897 Stats: 255 lines in 9 files changed: 193 ins; 9 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/9743.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9743/head:pull/9743 PR: https://git.openjdk.org/jdk/pull/9743 From wetmore at openjdk.org Thu Aug 4 17:19:09 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 Aug 2022 17:19:09 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: On Wed, 27 Jul 2022 20:24:19 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8290975 LMGTM, don't need to rereview, but would appreciate comments on the import style you used. src/java.base/share/classes/javax/security/auth/Subject.java line 36: > 34: import java.security.*; > 35: import java.text.MessageFormat; > 36: import java.util.*; What is the style convention you're trying to conform to here? src/java.base/share/classes/javax/security/auth/Subject.java line 1230: > 1228: if (sm != null) { > 1229: switch (which) { > 1230: case Subject.PRINCIPAL_SET: The original style guide convention has the switch and case at the same level. https://www.oracle.com/technetwork/java/codeconventions-150003.pdf Is this a reformat from IJ (Settings->Editor->Code Style->Java->Wrapping Braces->'switch statement'? IIRC, this is one setting where the default value isn't what we used to do. src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 29: > 27: > 28: import javax.security.auth.Subject; > 29: import javax.security.auth.callback.CallbackHandler; Out of curiosity, did IJ point this out somehow? ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9664 From wetmore at openjdk.org Thu Aug 4 17:19:12 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 Aug 2022 17:19:12 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: On Wed, 3 Aug 2022 14:49:25 GMT, Sean Mullan wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > src/java.base/share/classes/javax/security/auth/callback/NameCallback.java line 45: > >> 43: * @since 1.4 >> 44: */ >> 45: private final String prompt; > > I think you can also mark `defaultName` final. First constructor doesn't set defaultName (or inputName), so there will be a error "might not have been initialized". > src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java line 46: > >> 44: * @since 1.4 >> 45: */ >> 46: private final String prompt; > > I think you can also mark `defaultText` final. Same as above. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From alanb at openjdk.org Thu Aug 4 19:40:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 4 Aug 2022 19:40:34 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart wrote: > This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. > The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. > The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. > The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. I did a quick pass over this and it looks good. Adding CarrierThreadLocal is a good idea and as it allows the use-sites to be revert/cleaned up. Just a few minor comments so far. src/java.base/share/classes/sun/nio/ch/Util.java line 233: > 231: } > 232: > 233: BufferCache cache = bufferCache.get(); I assume JLA is no longer needed. test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40: > 38: * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java > 39: * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal > 40: */ If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. You might want to add the bugId to the `@bug` list too. ------------- PR: https://git.openjdk.org/jdk/pull/9743 From mpowers at openjdk.org Thu Aug 4 20:26:05 2022 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 4 Aug 2022 20:26:05 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: On Thu, 4 Aug 2022 17:02:48 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/security/auth/callback/NameCallback.java line 45: >> >>> 43: * @since 1.4 >>> 44: */ >>> 45: private final String prompt; >> >> I think you can also mark `defaultName` final. > > First constructor doesn't set defaultName (or inputName), so there will be a error "might not have been initialized". I verified the error message happens when `defaultName` is final. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Thu Aug 4 20:26:03 2022 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 4 Aug 2022 20:26:03 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: On Wed, 3 Aug 2022 14:37:20 GMT, Sean Mullan wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java line 130: > >> 128: * @serial >> 129: */ >> 130: private final boolean testing = false; > > This should really use java.security.debug so this tracing can be enabled at runtime, but that's probably more of a separate fix - feel free to file a separate issue. I'll file a bug later today and add to this bug report. > src/java.base/share/classes/javax/security/auth/Subject.java line 28: > >> 26: package javax.security.auth; >> 27: >> 28: import sun.security.util.ResourcesMgr; > > I suggest putting the internal imports below the java.* or other standard imports. This isn't a rule, but is more consistent with other code. IJ complains about unnecessary imports and asks If I want to let it automatically optimize them. I always answer "yes". I'll fix as you suggest. > src/java.base/share/classes/javax/security/auth/Subject.java line 854: > >> 852: * >> 853: *

If a security manager is installed, the caller must have a >> 854: * {@link PrivateCredentialPermission} to access all the requested > > Hmm. I think the previous text was more correct/readable. Okay. I'll revert the change. It was just an IJ suggestion. > src/java.base/share/classes/javax/security/auth/x500/X500Principal.java line 94: > >> 92: * NOTE: The constructor is package private. It is intended to be accessed >> 93: * using privileged reflection from classes in sun.security.*. >> 94: * Currently, referenced from sun.security.x509.X500Name.asX500Principal(). > > Change to "Currently, it is referenced from ..." Okay. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Thu Aug 4 20:28:56 2022 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 4 Aug 2022 20:28:56 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: <9pfVjWKeoZ-H5dQGTAz0X2M_eKVXeqn_XJuYHB2olcA=.a6033fe5-0215-430a-a821-1d862c1d9434@github.com> On Thu, 4 Aug 2022 16:45:36 GMT, Bradford Wetmore wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > src/java.base/share/classes/javax/security/auth/Subject.java line 36: > >> 34: import java.security.*; >> 35: import java.text.MessageFormat; >> 36: import java.util.*; > > What is the style convention you're trying to conform to here? I'm letting IJ optimize imports. I didn't see anything in the style guide. > src/java.base/share/classes/javax/security/auth/Subject.java line 1230: > >> 1228: if (sm != null) { >> 1229: switch (which) { >> 1230: case Subject.PRINCIPAL_SET: > > The original style guide convention has the switch and case at the same level. > > https://www.oracle.com/technetwork/java/codeconventions-150003.pdf > > Is this a reformat from IJ (Settings->Editor->Code Style->Java->Wrapping Braces->'switch statement'? IIRC, this is one setting where the default value isn't what we used to do. I changed my IJ settings: switch and case now at same level. > src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 29: > >> 27: >> 28: import javax.security.auth.Subject; >> 29: import javax.security.auth.callback.CallbackHandler; > > Out of curiosity, did IJ point this out somehow? Yes. IJ complained about unused imports and offered to optimize them for me. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From wetmore at openjdk.org Thu Aug 4 21:31:09 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 Aug 2022 21:31:09 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <9pfVjWKeoZ-H5dQGTAz0X2M_eKVXeqn_XJuYHB2olcA=.a6033fe5-0215-430a-a821-1d862c1d9434@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <9pfVjWKeoZ-H5dQGTAz0X2M_eKVXeqn_XJuYHB2olcA=.a6033fe5-0215-430a-a821-1d862c1d9434@github.com> Message-ID: On Thu, 4 Aug 2022 20:26:11 GMT, Mark Powers wrote: >> src/java.base/share/classes/javax/security/auth/Subject.java line 36: >> >>> 34: import java.security.*; >>> 35: import java.text.MessageFormat; >>> 36: import java.util.*; >> >> What is the style convention you're trying to conform to here? > > I'm letting IJ optimize imports. I didn't see anything in the style guide. Ah, I see it now. Ctrl+Alt+O. And you can configure from the Settings Import menu. >> src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 29: >> >>> 27: >>> 28: import javax.security.auth.Subject; >>> 29: import javax.security.auth.callback.CallbackHandler; >> >> Out of curiosity, did IJ point this out somehow? > > Yes. IJ complained about unused imports and offered to optimize them for me. Ah, so this is where it asked if you wanted to optimize. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From wetmore at openjdk.org Thu Aug 4 21:51:23 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Thu, 4 Aug 2022 21:51:23 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: On Thu, 4 Aug 2022 20:21:17 GMT, Mark Powers wrote: >> src/java.base/share/classes/javax/security/auth/Subject.java line 28: >> >>> 26: package javax.security.auth; >>> 27: >>> 28: import sun.security.util.ResourcesMgr; >> >> I suggest putting the internal imports below the java.* or other standard imports. This isn't a rule, but is more consistent with other code. > > IJ complains about unnecessary imports and asks If I want to let it automatically optimize them. I always answer "yes". I'll fix as you suggest. The default setup wants to put the sun.* imports above the java.*. The default order is defined in "Import Layout": all other imports import javax.* import java.* import static all other imports I have mine set to: import java.* import javax.* all other imports import static all other imports ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Thu Aug 4 22:50:47 2022 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 4 Aug 2022 22:50:47 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: On Thu, 4 Aug 2022 21:32:04 GMT, Bradford Wetmore wrote: >> IJ complains about unnecessary imports and asks If I want to let it automatically optimize them. I always answer "yes". I'll fix as you suggest. > > The default setup wants to put the sun.* imports above the java.*. The default order is defined in "Import Layout": > > > all other imports > > import javax.* > import java.* > > import static all other imports > > > I have mine set to: > > > import java.* > import javax.* > > all other imports > > import static all other imports I changed my IJ defaults. Thanks for the suggestion. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Fri Aug 5 03:50:48 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 03:50:48 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: > https://bugs.openjdk.org/browse/JDK-8290975 Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - just one more thing - Merge - sean and brad comments - second iteration - first iteration ------------- Changes: https://git.openjdk.org/jdk/pull/9664/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=01 Stats: 110 lines in 16 files changed: 8 ins; 24 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/9664.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9664/head:pull/9664 PR: https://git.openjdk.org/jdk/pull/9664 From xuelei at openjdk.org Fri Aug 5 05:33:16 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 5 Aug 2022 05:33:16 GMT Subject: RFR: 8291949: Unexpected extending of SupportedGroups Message-ID: In the SunJSSE implementation, there are a few unexpected extending of static class SupportedGroups. It may be nice to clean them up so that the code is easier to read. Please review this simple code clean up. ------------- Commit messages: - 8291949: Unexpected extending of SupportedGroups Changes: https://git.openjdk.org/jdk/pull/9765/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9765&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291949 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9765.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9765/head:pull/9765 PR: https://git.openjdk.org/jdk/pull/9765 From plevart at openjdk.org Fri Aug 5 09:43:46 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 5 Aug 2022 09:43:46 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:54:29 GMT, Alan Bateman wrote: >> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. >> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. >> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. >> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. > > src/java.base/share/classes/sun/nio/ch/Util.java line 233: > >> 231: } >> 232: >> 233: BufferCache cache = bufferCache.get(); > > I assume JLA is no longer needed. Right, I forgot to remove this one. ------------- PR: https://git.openjdk.org/jdk/pull/9743 From plevart at openjdk.org Fri Aug 5 09:54:36 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 5 Aug 2022 09:54:36 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) [v2] In-Reply-To: References: Message-ID: > This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. > The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. > The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. > The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. Peter Levart has updated the pull request incrementally with one additional commit since the last revision: Removed unused JLA, SharedSecrets, added @enablePreview test annotation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9743/files - new: https://git.openjdk.org/jdk/pull/9743/files/fa2078e4..2339b87f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9743&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9743&range=00-01 Stats: 10 lines in 2 files changed: 3 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9743.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9743/head:pull/9743 PR: https://git.openjdk.org/jdk/pull/9743 From plevart at openjdk.org Fri Aug 5 09:54:39 2022 From: plevart at openjdk.org (Peter Levart) Date: Fri, 5 Aug 2022 09:54:39 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) [v2] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 15:55:38 GMT, Alan Bateman wrote: >> Peter Levart has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed unused JLA, SharedSecrets, added @enablePreview test annotation > > test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40: > >> 38: * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java >> 39: * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal >> 40: */ > > If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. > > You might want to add the bugId to the `@bug` list too. Done in next commit. ------------- PR: https://git.openjdk.org/jdk/pull/9743 From mullan at openjdk.org Fri Aug 5 10:13:46 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Aug 2022 10:13:46 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: <5y_TtXwRhxpQSZDxOWcAf8WyTL7k3kBr1EAcFBBkUEM=.d39550c0-3ea9-4f63-ac7f-b4e7936a513e@github.com> On Thu, 4 Aug 2022 20:21:44 GMT, Mark Powers wrote: >> First constructor doesn't set defaultName (or inputName), so there will be a error "might not have been initialized". > > I verified the error message happens when `defaultName` is final. Yes but `defaultName` (like `prompt`) should never change once the object is constructed. So it seems inconsistent not to also mark it final (and if necessary, set it to a default value (`null`) in the constructors). ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mullan at openjdk.org Fri Aug 5 10:13:49 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Aug 2022 10:13:49 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: <_Z7_Wyg4YIZ4xgiMZ7GopghWGq0qavCW6kXDkXdT4zI=.7982f144-0f2d-496c-919f-fc5157d0a2ce@github.com> On Thu, 4 Aug 2022 17:03:37 GMT, Bradford Wetmore wrote: >> src/java.base/share/classes/javax/security/auth/callback/TextInputCallback.java line 46: >> >>> 44: * @since 1.4 >>> 45: */ >>> 46: private final String prompt; >> >> I think you can also mark `defaultText` final. > > Same as above. Same comment as above about setting it to a default value in the constructors. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From djelinski at openjdk.org Fri Aug 5 12:47:09 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 5 Aug 2022 12:47:09 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big Message-ID: Fix `SSLEngineService` test class to make sure it does not discard any network data between `handshaking` and `receive`. With TLS1.3 the client starts sending application data immediately after sending the Finished message. The server may read some of that data in the `handshaking` method. This patch makes sure that any such data is delivered to the `receive` method for processing. ------------- Commit messages: - Preserve excess network data Changes: https://git.openjdk.org/jdk/pull/9773/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9773&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8227651 Stats: 51 lines in 8 files changed: 5 ins; 5 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/9773.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9773/head:pull/9773 PR: https://git.openjdk.org/jdk/pull/9773 From mpowers at openjdk.org Fri Aug 5 14:25:42 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 14:25:42 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: <5y_TtXwRhxpQSZDxOWcAf8WyTL7k3kBr1EAcFBBkUEM=.d39550c0-3ea9-4f63-ac7f-b4e7936a513e@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> <5y_TtXwRhxpQSZDxOWcAf8WyTL7k3kBr1EAcFBBkUEM=.d39550c0-3ea9-4f63-ac7f-b4e7936a513e@github.com> Message-ID: On Fri, 5 Aug 2022 10:04:43 GMT, Sean Mullan wrote: >> I verified the error message happens when `defaultName` is final. > > Yes but `defaultName` (like `prompt`) should never change once the object is constructed. So it seems inconsistent not to also mark it final (and if necessary, set it to a default value (`null`) in the constructors). Agreed. I'll make the change. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From redestad at openjdk.org Fri Aug 5 14:27:03 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 5 Aug 2022 14:27:03 GMT Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v3] In-Reply-To: References: Message-ID: > - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts. > > Reduces runtime from estimated 10+ hours to 54 minutes. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Address comments on SSLHandshake ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9189/files - new: https://git.openjdk.org/jdk/pull/9189/files/8330c018..aa843dd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9189&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9189&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9189.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9189/head:pull/9189 PR: https://git.openjdk.org/jdk/pull/9189 From redestad at openjdk.org Fri Aug 5 14:27:08 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 5 Aug 2022 14:27:08 GMT Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2] In-Reply-To: References: Message-ID: On Tue, 19 Jul 2022 20:55:54 GMT, David Schlosnagle wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Copyrights, apply consistent settings to PermissionsImplies > > test/micro/org/openjdk/bench/java/security/SSLHandshake.java line 56: > >> 54: @Warmup(iterations = 5, time = 1) >> 55: @Measurement(iterations = 5, time = 1) >> 56: @Fork(value = 3) > > should the `@Warmup`, `@Measurement`, and `@Fork` be removed from the `doHandshake()` benchmark on lines 115-117 below so that these take effect? > > https://github.com/openjdk/jdk/blob/c2cbeb3ee875936c98bb15ec32d692f7d866df76/test/micro/org/openjdk/bench/java/security/SSLHandshake.java#L111-L115 Good observation. This means this benchmark was already tuned, and the pre-existing tuning overrides the setting I thought I was testing with. I've effectively reverted the changes but moved the annotations to class scope for consistency. ------------- PR: https://git.openjdk.org/jdk/pull/9189 From mpowers at openjdk.org Fri Aug 5 14:35:40 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 14:35:40 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> Message-ID: <1Yu4DEQk2OATnp_9yFYqNxwa0QjDlDyz5EVKoMYjQCc=.d4607f10-b25f-4356-a869-284cd7ba4f52@github.com> On Thu, 4 Aug 2022 20:20:35 GMT, Mark Powers wrote: >> src/java.base/share/classes/javax/security/auth/PrivateCredentialPermission.java line 130: >> >>> 128: * @serial >>> 129: */ >>> 130: private final boolean testing = false; >> >> This should really use java.security.debug so this tracing can be enabled at runtime, but that's probably more of a separate fix - feel free to file a separate issue. > > I'll file a bug later today and add to this bug report. You must mean sun.security.util.Debug. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Fri Aug 5 14:59:09 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 14:59:09 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: <1Yu4DEQk2OATnp_9yFYqNxwa0QjDlDyz5EVKoMYjQCc=.d4607f10-b25f-4356-a869-284cd7ba4f52@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> <1Yu4DEQk2OATnp_9yFYqNxwa0QjDlDyz5EVKoMYjQCc=.d4607f10-b25f-4356-a869-284cd7ba4f52@github.com> Message-ID: On Fri, 5 Aug 2022 14:29:38 GMT, Mark Powers wrote: >> I'll file a bug later today and add to this bug report. > > You must mean sun.security.util.Debug. JDK-8291974 ------------- PR: https://git.openjdk.org/jdk/pull/9664 From wetmore at openjdk.org Fri Aug 5 17:38:18 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 5 Aug 2022 17:38:18 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v2] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> <3GDTOU0Mwb3ucqujk_2xpeEFU14HkloZwgloxGFgIus=.5e173777-b13d-4646-8e83-43846f32c5b2@github.com> <5y_TtXwRhxpQSZDxOWcAf8WyTL7k3kBr1EAcFBBkUEM=.d39550c0-3ea9-4f63-ac7f-b4e7936a513e@github.com> Message-ID: On Fri, 5 Aug 2022 14:09:18 GMT, Mark Powers wrote: >> Yes but `defaultName` (like `prompt`) should never change once the object is constructed. So it seems inconsistent not to also mark it final (and if necessary, set it to a default value (`null`) in the constructors). > > Agreed. I'll make the change. That works also, as the API allows for these values to be set/reset to null. Can't do the same for inputName, as that can be set later. ------------- PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Fri Aug 5 21:16:25 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 21:16:25 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v3] In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: > https://bugs.openjdk.org/browse/JDK-8290975 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: comment from sean ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9664/files - new: https://git.openjdk.org/jdk/pull/9664/files/70606fd9..2f54c822 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9664.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9664/head:pull/9664 PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Fri Aug 5 21:49:01 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 21:49:01 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v4] In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: > https://bugs.openjdk.org/browse/JDK-8290975 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: comment applies to two files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9664/files - new: https://git.openjdk.org/jdk/pull/9664/files/2f54c822..21355258 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9664.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9664/head:pull/9664 PR: https://git.openjdk.org/jdk/pull/9664 From wetmore at openjdk.org Fri Aug 5 22:24:08 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 5 Aug 2022 22:24:08 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v4] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: <_VKZBX9KZ6umxRfP2pbxdRzSTDrmKrdCWAgCQaOqZrw=.f7ebd5ee-1ed5-4f11-8937-d9807dbc43f8@github.com> On Fri, 5 Aug 2022 21:49:01 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment applies to two files LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9664 From mpowers at openjdk.org Fri Aug 5 22:56:06 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 5 Aug 2022 22:56:06 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v4] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: On Fri, 5 Aug 2022 21:49:01 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment applies to two files Thanks Sean and Brad for the review! ------------- PR: https://git.openjdk.org/jdk/pull/9664 From duke at openjdk.org Sat Aug 6 09:05:12 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 09:05:12 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: >> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed. Additionally: >> >> The Java manpage was missing updates from: >> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page. >> >> The Java manpage has slight formatting differences from: >> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux >> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS >> >> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20) >> >> >> The keytool manpage was missing updates from: >> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The jar manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jarsigner manpage was missing updates from: >> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page. >> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA >> >> The javadoc manpage was missing updates from: >> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option >> >> The jmod manpage was missing updates from: >> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755) >> >> The jpackage manpage was missing updates from: >> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature >> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19 >> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code >> >> The jshell manpage was missing updates from: >> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page. > > src/java.base/share/man/keytool.1 line 456: > >> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >> 455: keystore. >> 456: This option is used to sign the certificate with the signer?s private > > Not a problem with this PR as such, but we still have a `?` character in the output. Hello @jonathan-gibbons Excuse my hijacking / piggy-backing on this conversation! When you say > Not a problem with this PR as such, but we still have a `?` character in the output. This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? ------------- PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Sat Aug 6 13:54:20 2022 From: duke at openjdk.org (Patrick Pfeifer) Date: Sat, 6 Aug 2022 13:54:20 GMT Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <_53Ro95x3TDbVcRUoOr4L0HiWCyepU8CgcyPCwLwKLA=.6ce49e6c-9b4b-4c8e-b0b8-7ec76b0f3d85@github.com> On Sat, 6 Aug 2022 09:01:39 GMT, Patrick Pfeifer wrote: >> src/java.base/share/man/keytool.1 line 456: >> >>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the >>> 455: keystore. >>> 456: This option is used to sign the certificate with the signer?s private >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? > > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? It did not take much effort to answer the last of the above question myself. > Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? Obviously "yes". HTML renderings can be found by following the, e.g. "[Java Development Kit Version 18 Tool Specifications](https://docs.oracle.com/en/java/javase/18/docs/specs/man/index.html)" Link on the "Specifications Overview" page at, e.g. "https://docs.oracle.com/en/java/javase/18/docs/specs/". Still hunting for the sources. ------------- PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Sat Aug 6 15:35:00 2022 From: duke at openjdk.org (raspberry-hu) Date: Sat, 6 Aug 2022 15:35:00 GMT Subject: RFR: 8291957: Redundant import statements in sun.security.ec Message-ID: remove unused imports ------------- Commit messages: - Update XDHPublicKeyImpl.java - Update SunEC.java - Update ECKeyPairGenerator.java Changes: https://git.openjdk.org/jdk/pull/9792/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9792&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291957 Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9792.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9792/head:pull/9792 PR: https://git.openjdk.org/jdk/pull/9792 From xuelei at openjdk.org Sat Aug 6 16:17:37 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 6 Aug 2022 16:17:37 GMT Subject: RFR: 8281236: (D)TLS key exchange named groups Message-ID: This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well: CSR: https://bugs.openjdk.org/browse/JDK-8291950 RFE: https://bugs.openjdk.org/browse/JDK-8281236 Release-note: https://bugs.openjdk.org/browse/JDK-8291975 This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494) ------------- Commit messages: - add test cases - 8281236: (D)TLS key exchange algorithms Changes: https://git.openjdk.org/jdk/pull/9776/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8281236 Stats: 907 lines in 17 files changed: 657 ins; 200 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/9776.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9776/head:pull/9776 PR: https://git.openjdk.org/jdk/pull/9776 From xuelei at openjdk.org Sat Aug 6 16:47:00 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Sat, 6 Aug 2022 16:47:00 GMT Subject: RFR: 8291957: Redundant import statements in sun.security.ec In-Reply-To: References: Message-ID: <5X4MalfKyYeRph_PWuF5diiGZOACwNPvMdqWc9nPD6U=.1e06a777-7277-4367-aa69-0bd45ce4c054@github.com> On Sat, 6 Aug 2022 15:12:44 GMT, raspberry-hu wrote: > remove unused imports Looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.org/jdk/pull/9792 From jwaters at openjdk.org Sun Aug 7 08:51:50 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 7 Aug 2022 08:51:50 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v2] In-Reply-To: References: Message-ID: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into patch-2 - Comment out EXIT_FAILURE redefinition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9678/files - new: https://git.openjdk.org/jdk/pull/9678/files/3c71527c..91ffab89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=00-01 Stats: 8701 lines in 478 files changed: 5279 ins; 2233 del; 1189 mod Patch: https://git.openjdk.org/jdk/pull/9678.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9678/head:pull/9678 PR: https://git.openjdk.org/jdk/pull/9678 From mullan at openjdk.org Sun Aug 7 13:52:05 2022 From: mullan at openjdk.org (Sean Mullan) Date: Sun, 7 Aug 2022 13:52:05 GMT Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security [v4] In-Reply-To: References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: On Fri, 5 Aug 2022 21:49:01 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8290975 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > comment applies to two files Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9664 From ecki at zusammenkunft.net Sun Aug 7 19:18:16 2022 From: ecki at zusammenkunft.net (Bernd) Date: Sun, 7 Aug 2022 21:18:16 +0200 Subject: PKCS8 with PBES2 protection supported by EncryptedPrivateKeyInfo? Message-ID: Hello, there is a longstanding issue in the PostgreSQL JDBC driver which reads secret keys in PKCS#8 format, but does not support the newer PKCS#5 2.0 (PBES2) modes (-v1 works). The (naive) code is here: pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec ? pgjdbc/pgjdbc ? GitHub I was playing around with EncryptedPrivateKeyInfo in order to see whats needed to get it working with PBES2 encryption, but it did not work with quite a few tries. I wonder is the Code behind PBES2Parameters in JCE supposed to work and interoperable with openssl PKCS#8? If I understand the api correctly the following code should work, but it results in a padding error: public static void main(String[] args) throws Throwable { byte[] b = readFileFully("test-key.p8"); // DER Format EncryptedPrivateKeyInfo ePKInfo = new EncryptedPrivateKeyInfo(b); System.out.println("en " + ePKInfo + " alg=" + ePKInfo.getAlgName() + " p=" + ePKInfo.getAlgParameters().toString()); AlgorithmParameters algParams = ePKInfo.getAlgParameters(); //PBEParameterSpec pbep = algParams.getParameterSpec(PBEParameterSpec.class); //System.out.println("pbep " + pbep); //AlgorithmParameterSpec cp = pbep.getParameterSpec(); //System.out.println("cp = " + cp ); // IvParameters PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray()); //PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray(), // pbep.getSalt(), pbep.getIterationCount(), 256); SecretKeyFactory skFac = SecretKeyFactory.getInstance(algParams.toString()); Key pbeKey = skFac.generateSecret(pbeKeySpec); Cipher cipher = Cipher.getInstance(algParams.toString()); cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams); // Decrypt the encrypted private key // when passing pbeKey here instead of cipher the algParams are lost KeySpec pkcs8KeySpec = ePKInfo.getKeySpec(cipher); // L61 --> throws // not reached KeyFactory kf = KeyFactory.getInstance("RSA"); PrivateKey key = kf.generatePrivate(pkcs8KeySpec); System.out.println("k=" + key); } The test object created with openssl: > openssl req -x509 -newkey rsa:2048 -keyout test-key.pem -out test-cert.pem -sha256 -days 365 -nodes > openssl pkcs8 -topk8 -in test-key.pem -out test-key.p8 -outform der # password "test" > openssl asn1parse -in test-key.p8 -inform DER 0:d=0 hl=4 l=1325 cons: SEQUENCE 4:d=1 hl=2 l= 87 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :PBES2 17:d=2 hl=2 l= 74 cons: SEQUENCE 19:d=3 hl=2 l= 41 cons: SEQUENCE 21:d=4 hl=2 l= 9 prim: OBJECT :PBKDF2 32:d=4 hl=2 l= 28 cons: SEQUENCE 34:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:BDCF0B11DB8BAFAB 44:d=5 hl=2 l= 2 prim: INTEGER :0800 48:d=5 hl=2 l= 12 cons: SEQUENCE 50:d=6 hl=2 l= 8 prim: OBJECT :hmacWithSHA256 60:d=6 hl=2 l= 0 prim: NULL 62:d=3 hl=2 l= 29 cons: SEQUENCE 64:d=4 hl=2 l= 9 prim: OBJECT :aes-256-cbc 75:d=4 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:E355E1C72C9F486DDBE2E1F58EE7B61E 93:d=1 hl=4 l=1232 prim: OCTET STRING [HEX DUMP]:E4D9C29E4789840093EE371AB6EACB3111920E636CCB924651125D97CBD5312156214AD173CF4159AEEDBB497900815FE3B24184846CA252A421784CAD121B59C93EE3427BEA7CF0E404FAD0F226A2D13B86BD4898455B0750FBA6C4FB5F0B66980BD586CFFCBB5FA2170A67917FD55F7AF0E03D03078E5191965F74C099E357F28B6DA969E3CF3D713ABBC35C20A513E8068822A1C9B67BAFB650FB4B8EB7755A9F1760CD0B82AEBFBCCA01F575C377CD5AA2732D42F10A43EEF46048650E492F9FE1FD56596DDAC70461BF3E60CEA97F7EA99741254D1C1452CF1081DD799EACC74C8C0E806104230AE91E560C8F458B7BB358F031726355E99D31938CF39EC40B76D963FC3D45A59C7BE14CC769E7E4DA8C9FC08F4BD1A4C4CC07141BA0D5A31F0319E32D48A12A2BA4ABA4979A68447AFA57B8A9F82D465B1E765169B1C339C88F9EC9934B0B1B58C5793991FB9990F44C9C7A816ABE97015ECFB408CBF906BABAF9C7F5D0F32673AA1D9D72A0C3738FC9C1909FB24A029A3928C583B2DE4CCF3247F7C89D97E8DEEF3E08796789D43B56A66D1C07B3D368948964FAA1746EEC59605A14934B02BFE14B6BC8A281973E76215E7FF9A43FD33780F34D76A21791586EDBA5999BCE08D8DF5E20B736DDA9B91091991B0EE883CC3E8358D8403486B53D205C0DD33EE3224D1BE40DE9FCD444D70BDE6500B08FF843153EC8EF01F5CDC9D01CB9372BBCA6F42D5D13159AC9E67CAB075A20D86F9538AE604E87DEBF1300D3E6A8BEB72F1F2124F903E95A558DE3BEB61A1AAE792E9A77A6F860BD736D2C0BA97FDA25D4E3AEAF8149415E68E473F48D99860DC2A49F108AE5468DFC36A5764E3B06412D2C3498D87E9F5D487421FD5C15C0EA8306A69BFA2956D8F8C1F4CD4786EDE575515202F8442CBA2E3AA21CB267DDEC5BA7BB1CBC54F471E84CD522FCE9A69F084DD4EB100F00875A0A32BCCD6D5F5473FF8CA6E6B448BAB76A659E0350AAFC3A2EFBCCAF1AFB52F3C8A7F3B452E5B35CDC2CD05710D86529EE3544DE9AB5A7FAA9AD8ADC93B0F7F5432FF8EB280A3BEE3C094796C9938DC5A4956D47CE4CE7A7D2300E328D47F030332EC84296CD57F02B61B63A099210C78F64B3DB618E79A17585030CB82B8B39BB34333D148F5856D04B4083BD0F006B8A747D7E020DDD8DCA99AEF6B719367DB619C7736D7897F071875CC9C17F7AF3E742F06CDBEBECDF486CC6B143BB96FC4FE34A54CB1CBFDF877598094B459DBAA6B101B0DE8000A5E2D06ABAE1C651EDF3EA3A7D37EA263AC999B65F621E1F65FFD06F461B7285EB90AE2C32AA60C8424966BF37F2C4F502BFE253E252C1CD652FC8667E488BF8B282D0379B38AC9B53014C87C55E8DE8EB7A217F521F46FC13F983C3E77B61417A552D7ACC147FC40C295DD87DDC4972AF340384B449A8A888BD1F4AB7B5B2D6AB3E963F7E90870639709075FA4A618A640753B6E2B6B4C0734BFEEE7A14C94C64131C666749E813A07FB8622278BF7F823675883F8B57C9BC081420F96C7F71E006D3A41299711E6E283F7C97E1ECC1202D98DF0BB13742D8DB5FDFE4569C35E207983645AE86AA2286680A9EDB69742DBD164D499096C90A063EE6304C81D2DB8311A73F80D7E1BB14B2C0C249D14F7D953369513731A5DEDB2AAD671E74F704CAFBCF4CDEDB72E42A238DD9CA2AB77ABAE80350F508062276A66C9BF81C325368E496C9490B >From debugging it looks like it picked up the salt for PBKFD#2 and the Iv for AES, but it is a bit nested, so I tried passing Cipher and/or Key to getKeySpec(). The output en javax.crypto.EncryptedPrivateKeyInfo at 27716f4 alg=1.2.840.113549.1.5.13 p=PBEWithHmacSHA1AndAES_256 Exception in thread "main" java.security.spec.InvalidKeySpecException: Cannot retrieve the PKCS8EncodedKeySpec at javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:255) at bernd.TestKey.main(TestKey.java:61) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975) at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056) at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) at com.sun.crypto.provider.PBES2Core.engineDoFinal(PBES2Core.java:323) at javax.crypto.Cipher.doFinal(Cipher.java:2168) at javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:250) ... 1 more I see there are some test cases for a similar usage, but they depend on an initialized key with defaults, so I am not sure if that would actually use AES IV? https://github.com/openjdk/jdk/blob/357f990e3244feaba6d8709b7ea50660220a418b/test/jdk/sun/security/x509/AlgorithmId/PBES2.java#L89 BTW: its hard to say if the problem is "only" caused by UTF-8 vs. UTF-16 password encoding. In that case it would be a bit unfortunate, is it maybe an option to add that support? (however I am not sure what password encoding openssl uses in this case). -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Aug 7 23:59:08 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2022 09:59:08 +1000 Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC In-Reply-To: References: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com> Message-ID: <161d24ca-ff52-b2fe-0874-461e98900e28@oracle.com> Hi Patrick, On 6/08/2022 7:05 pm, Patrick Pfeifer wrote: > On Mon, 18 Jul 2022 15:22:01 GMT, Jonathan Gibbons wrote: > >>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains. >> >> Not a problem with this PR as such, but we still have a `?` character in the output. > > Hello @jonathan-gibbons > > Excuse my hijacking / piggy-backing on this conversation! > > When you say > >> Not a problem with this PR as such, but we still have a `?` character in the output. > > This strongly suggests that there must be an input to those man pages somewhere. :-) Would you mind to point me to it? Are they even included in the git repo? The sources to the manpages are not currently open sourced and so are held in Oracle's internal repository. Making them open-sourced has been a goal for some time now but has to overcome legal obstacles, but we are hopeful it will be "soon". > Also, I was wondering why these man pages (i.e. the outputs) are obviously not included any more in the OpenJDK builds, e.g. https://jdk.java.net/19/ ? I am not sure when they were removed or if they were ever included in _open_jdk builds at all, but I see them in the Oracle JDK 1.8 Build. > > I find them really nice to read! Are there other output formats, e.g. HTML, that might be are deployed somewhere on the web? As you found, Oracle does provide these in html format. Cheers, David > ------------- > > PR: https://git.openjdk.org/jdk19/pull/145 From duke at openjdk.org Mon Aug 8 02:53:17 2022 From: duke at openjdk.org (raspberry-hu) Date: Mon, 8 Aug 2022 02:53:17 GMT Subject: Integrated: 8291957: Redundant import statements in sun.security.ec In-Reply-To: References: Message-ID: On Sat, 6 Aug 2022 15:12:44 GMT, raspberry-hu wrote: > remove unused imports This pull request has now been integrated. Changeset: 8e2c006c Author: raspberry-hu <76903172+raspberry-hu at users.noreply.github.com> Committer: John Jiang URL: https://git.openjdk.org/jdk/commit/8e2c006cd14905c06e8c2cc30f13de249d54ed79 Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod 8291957: Redundant import statements in sun.security.ec Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/9792 From jwaters at openjdk.org Mon Aug 8 05:45:03 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:45:03 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v3] In-Reply-To: References: Message-ID: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Comment out EXIT_FAILURE redefinition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9678/files - new: https://git.openjdk.org/jdk/pull/9678/files/91ffab89..76e0a33d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=01-02 Stats: 9 lines in 3 files changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9678.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9678/head:pull/9678 PR: https://git.openjdk.org/jdk/pull/9678 From jwaters at openjdk.org Mon Aug 8 05:45:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 8 Aug 2022 05:45:06 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v2] In-Reply-To: References: Message-ID: On Sun, 7 Aug 2022 08:51:50 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition Successfully merged with latest, awaiting review and/or sponsorship ------------- PR: https://git.openjdk.org/jdk/pull/9678 From alanb at openjdk.org Mon Aug 8 08:38:03 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Aug 2022 08:38:03 GMT Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) [v2] In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 09:54:36 GMT, Peter Levart wrote: >> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. >> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. >> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. >> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. > > Peter Levart has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused JLA, SharedSecrets, added @enablePreview test annotation Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9743 From duke at openjdk.org Mon Aug 8 08:46:06 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 8 Aug 2022 08:46:06 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3] In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 01:40:36 GMT, Weijun Wang wrote: > BTW, have you reverted your change on `LoginContext.java`. I remembered we agreed that this bug is all about debug info instead of updating the exception thrown. Actually here: https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug , the ask is that its better to print the stack trace of an exception so I didn't revert it back. And sorry I didn't mention that in the conversation. Already the `debug.println` is there for `OPTIONAL` section here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L880 where `debug!=null`. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From coffeys at openjdk.org Mon Aug 8 10:27:00 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 8 Aug 2022 10:27:00 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing Message-ID: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. CSR in progress. ------------- Commit messages: - Update bug summary in test - 8155246 Changes: https://git.openjdk.org/jdk/pull/9747/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8155246 Stats: 119 lines in 3 files changed: 101 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9747.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9747/head:pull/9747 PR: https://git.openjdk.org/jdk/pull/9747 From plevart at openjdk.org Mon Aug 8 12:41:51 2022 From: plevart at openjdk.org (Peter Levart) Date: Mon, 8 Aug 2022 12:41:51 GMT Subject: Integrated: 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) In-Reply-To: References: Message-ID: On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart wrote: > This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup. > The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses. > The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently with a CarrierThreadLocal. > The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly. This pull request has now been integrated. Changeset: 861cc671 Author: Peter Levart URL: https://git.openjdk.org/jdk/commit/861cc671e2e4904d94f50710be99a511e2f9bb68 Stats: 262 lines in 9 files changed: 196 ins; 12 del; 54 mod 8291897: TerminatingThreadLocal(s) not registered from virtual thread(s) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/9743 From duke at openjdk.org Mon Aug 8 16:47:29 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 8 Aug 2022 16:47:29 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v4] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/3bce8d96..e3ab4348 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=02-03 Stats: 109 lines in 3 files changed: 0 ins; 109 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From mpowers at openjdk.org Mon Aug 8 17:33:45 2022 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 8 Aug 2022 17:33:45 GMT Subject: Integrated: JDK-8290975 Minor cleanup could be done in javax.security In-Reply-To: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> References: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com> Message-ID: On Wed, 27 Jul 2022 20:24:19 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8290975 This pull request has now been integrated. Changeset: 08274e6f Author: Mark Powers Committer: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/08274e6fea982e71ccc5964f4919c65501b048e1 Stats: 114 lines in 16 files changed: 10 ins; 24 del; 80 mod 8290975: Minor cleanup could be done in javax.security Reviewed-by: wetmore, mullan ------------- PR: https://git.openjdk.org/jdk/pull/9664 From duke at openjdk.org Mon Aug 8 17:34:59 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 8 Aug 2022 17:34:59 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v5] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Added test case using {Unix,NT}LoginModule ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/e3ab4348..a7997f05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=03-04 Stats: 82 lines in 1 file changed: 82 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 8 17:37:22 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 8 Aug 2022 17:37:22 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v3] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 08:42:11 GMT, Jayashree Huttanagoudar wrote: > > BTW, have you reverted your change on `LoginContext.java`. I remembered we agreed that this bug is all about debug info instead of updating the exception thrown. > > Actually here: https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug , the ask is that its better to print the stack trace of an exception so I didn't revert it back. And sorry I didn't mention that in the conversation. Already the `debug.println` is there for `OPTIONAL` section here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L880 where `debug!=null`. I have reverted my changes to LoginContext.java. I verified that, the change I added wasn't making any difference with the test case I wrote using {Unix,NT}LoginModule. Further, I am not sure which could be the right place to add logging information to help developer understand the failure reason of an optional JAAS LoginModule. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From ascarpino at openjdk.org Mon Aug 8 18:37:05 2022 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Mon, 8 Aug 2022 18:37:05 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Thu, 4 Aug 2022 15:22:23 GMT, Sean Coffey wrote: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. What's the need for this change? Perhaps I'm missing the bigger problem here. Certainly not having a java.security file is sub-optimal and I suspect very very rare, but throwing exceptions that breaks existing apps seems like a big hammer and would now need a property added to override Doing this change for jdk-dev only I could see, but as the CSR points toward backporting, that seems more risky ------------- PR: https://git.openjdk.org/jdk/pull/9747 From coffeys at openjdk.org Mon Aug 8 20:22:04 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 8 Aug 2022 20:22:04 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Thu, 4 Aug 2022 15:22:23 GMT, Sean Coffey wrote: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. Hi Tony, there are a few points for the change IMO: * The fall back to the "static" security policy file is broken since JDK 9/Modules. Some providers don't register correctly. See JDK-8291888 * The fall back mode used a minimal security config setting and is not actively maintained. I'd argue that it's dangerous - all the JDK protection aids added via the java.security file aren't available if the default one is missing. One is still free to override the property file, as before. We just ensure that $JDK/conf/security/java.security exists. It's a bad JDK install if such a file doesn't exist. This might only make JDK 20 - perhaps we review feedback from that release and decide if we want to proceed with backports then. regards, Sean. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From anthony.scarpino at oracle.com Tue Aug 9 00:12:04 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 8 Aug 2022 17:12:04 -0700 Subject: PKCS8 with PBES2 protection supported by EncryptedPrivateKeyInfo? In-Reply-To: References: Message-ID: <478e9032-1b47-1ffc-38cb-93bbe05d1903@oracle.com> Hi, I did this not long ago. You are close, but you do not need to do the Cipher.init() separately, it is done as part of EncryptedPrivateKeyInfo.getKeySpec(). It also reads the encoding for the count and iv. The below will decrypt the DER-encoded 'data' into a PKCS8EncryptedKeySpec for you to use. EncryptedPrivateKeyInfo epki = new EncryptedPrivateKeyInfo(data); PBEKeySpec pks = new PBEKeySpec(password); SecretKeyFactory skf = SecretKeyFactory.getInstance(epki.getAlgName()); SecretKey sk = skf.generateSecret(pks); PKCS8EncodedKeySpec keySpec = epki.getKeySpec(sk); Tony On 8/7/22 12:18 PM, Bernd wrote: > Hello, > > there is a longstanding issue in the PostgreSQL JDBC driver which reads > secret keys in PKCS#8 format, but does not support the newer PKCS#5 2.0 > (PBES2) modes (-v1 works). The (naive) code is here: > > pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec ? > pgjdbc/pgjdbc ? GitHub > > > I was playing around with EncryptedPrivateKeyInfo in order to see whats > needed to get it working with PBES2 encryption, but it did not work with > quite a few tries. > > I wonder is the Code behind PBES2Parameters?in JCE supposed to work > and?interoperable with openssl PKCS#8? If I understand the api correctly > the following code should work, but it results in a padding error: > > ? ? public static void main(String[] args) throws Throwable > ? ? { > ? ? ? ? byte[] b = readFileFully("test-key.p8"); // DER Format > ? ? ? ? EncryptedPrivateKeyInfo ePKInfo = new EncryptedPrivateKeyInfo(b); > ? ? ? ? System.out.println("en " + ePKInfo + " alg=" + > ePKInfo.getAlgName() > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+ " p=" + > ePKInfo.getAlgParameters().toString()); > ? ? ? ? AlgorithmParameters algParams = ePKInfo.getAlgParameters(); > ? ? ? ? //PBEParameterSpec pbep = > algParams.getParameterSpec(PBEParameterSpec.class); > ? ? ? ? //System.out.println("pbep " + pbep); > ? ? ? ? //AlgorithmParameterSpec cp = pbep.getParameterSpec(); > ? ? ? ? //System.out.println("cp = " + cp ); // IvParameters > > ? ? ? ? PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray()); > ? ? ? ? //PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray(), > ? ? ? ? // > ?pbep.getSalt(), pbep.getIterationCount(), 256); > ? ? ? ? SecretKeyFactory skFac = > SecretKeyFactory.getInstance(algParams.toString()); > ? ? ? ? Key pbeKey = skFac.generateSecret(pbeKeySpec); > > ? ? ? ? Cipher cipher = Cipher.getInstance(algParams.toString()); > ? ? ? ? cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams); > > ? ? ? ? // Decrypt the encrypted private key > ? ? ? ? // when passing pbeKey here instead of cipher the algParams are > lost > ? ? ? ? KeySpec pkcs8KeySpec = ePKInfo.getKeySpec(cipher); // L61 --> > throws > > ? ? ? ? // not reached > ? ? ? ? KeyFactory kf = KeyFactory.getInstance("RSA"); > ? ? ? ? PrivateKey key = kf.generatePrivate(pkcs8KeySpec); > ? ? ? ? System.out.println("k=" + key); > } > > The test object created with openssl: > > openssl req -x509 -newkey rsa:2048 -keyout test-key.pem -out > test-cert.pem -sha256 -days 365 -nodes > > openssl pkcs8 -topk8 -in test-key.pem -out test-key.p8 -outform der > # password "test" > > openssl asn1parse -in test-key.p8 -inform DER > ? ? 0:d=0? hl=4 l=1325 cons: SEQUENCE > ? ? 4:d=1? hl=2 l=? 87 cons: SEQUENCE > ? ? 6:d=2? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :PBES2 > ? ?17:d=2? hl=2 l=? 74 cons: SEQUENCE > ? ?19:d=3? hl=2 l=? 41 cons: SEQUENCE > ? ?21:d=4? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :PBKDF2 > ? ?32:d=4? hl=2 l=? 28 cons: SEQUENCE > ? ?34:d=5? hl=2 l=? ?8 prim: OCTET STRING? ? ? [HEX DUMP]:BDCF0B11DB8BAFAB > ? ?44:d=5? hl=2 l=? ?2 prim: INTEGER? ? ? ? ? ?:0800 > ? ?48:d=5? hl=2 l=? 12 cons: SEQUENCE > ? ?50:d=6? hl=2 l=? ?8 prim: OBJECT? ? ? ? ? ? :hmacWithSHA256 > ? ?60:d=6? hl=2 l=? ?0 prim: NULL > ? ?62:d=3? hl=2 l=? 29 cons: SEQUENCE > ? ?64:d=4? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :aes-256-cbc > ? ?75:d=4? hl=2 l=? 16 prim: OCTET STRING? ? ? [HEX > DUMP]:E355E1C72C9F486DDBE2E1F58EE7B61E > ? ?93:d=1? hl=4 l=1232 prim: OCTET STRING? ? ? [HEX > DUMP]:E4D9C29E4789840093EE371AB6EACB3111920E636CCB924651125D97CBD5312156214AD173CF4159AEEDBB497900815FE3B24184846CA252A421784CAD121B59C93EE3427BEA7CF0E404FAD0F226A2D13B86BD4898455B0750FBA6C4FB5F0B66980BD586CFFCBB5FA2170A67917FD55F7AF0E03D03078E5191965F74C099E357F28B6DA969E3CF3D713ABBC35C20A513E8068822A1C9B67BAFB650FB4B8EB7755A9F1760CD0B82AEBFBCCA01F575C377CD5AA2732D42F10A43EEF46048650E492F9FE1FD56596DDAC70461BF3E60CEA97F7EA99741254D1C1452CF1081DD799EACC74C8C0E806104230AE91E560C8F458B7BB358F031726355E99D31938CF39EC40B76D963FC3D45A59C7BE14CC769E7E4DA8C9FC08F4BD1A4C4CC07141BA0D5A31F0319E32D48A12A2BA4ABA4979A68447AFA57B8A9F82D465B1E765169B1C339C88F9EC9934B0B1B58C5793991FB9990F44C9C7A816ABE97015ECFB408CBF906BABAF9C7F5D0F32673AA1D9D72A0C3738FC9C1909FB24A029A3928C583B2DE4CCF3247F7C89D97E8DEEF3E08796789D43B56A66D1C07B3D368948964FAA1746EEC59605A14934B02BFE14B6BC8A281973E76215E7FF9A43FD33780F34D76A21791586EDBA5999BCE08D8DF5E20B736DDA9B91091991B0EE883CC3E8358D8403486B53D205C0DD33EE3224D1BE40DE9FCD444D70BDE6500B08FF843153EC8EF01F5CDC9D01CB9372BBCA6F42D5D13159AC9E67CAB075A20D86F9538AE604E87DEBF1300D3E6A8BEB72F1F2124F903E95A558DE3BEB61A1AAE792E9A77A6F860BD736D2C0BA97FDA25D4E3AEAF8149415E68E473F48D99860DC2A49F108AE5468DFC36A5764E3B06412D2C3498D87E9F5D487421FD5C15C0EA8306A69BFA2956D8F8C1F4CD4786EDE575515202F8442CBA2E3AA21CB267DDEC5BA7BB1CBC54F471E84CD522FCE9A69F084DD4EB100F00875A0A32BCCD6D5F5473FF8CA6E6B448BAB76A659E0350AAFC3A2EFBCCAF1AFB52F3C8A7F3B452E5B35CDC2CD05710D86529EE3544DE9AB5A7FAA9AD8ADC93B0F7F5432FF8EB280A3BEE3C094796C9938DC5A4956D47CE4CE7A7D2300E328D47F030332EC84296CD57F02B61B63A099210C78F64B3DB618E79A17585030CB82B8B39BB34333D148F5856D04B4083BD0F006B8A747D7E020DDD8DCA99AEF6B719367DB619C7736D7897F071875CC9C17F7AF3E742F06CDBEBECDF486CC6B143BB96FC4FE34A54CB1CBFDF877598094B459DBAA6B101B0DE8000A5E2D06ABAE1C651EDF3EA3A7D37EA263AC999B65F621E1F65FFD06F461B7285EB90AE2C32AA60C8424966BF37F2C4F502BFE253E252C1CD652FC8667E488BF8B282D0379B38AC9B53014C87C55E8DE8EB7A217F521F46FC13F983C3E77B61417A552D7ACC147FC40C295DD87DDC4972AF340384B449A8A888BD1F4AB7B5B2D6AB3E963F7E90870639709075FA4A618A640753B6E2B6B4C0734BFEEE7A14C94C64131C666749E813A07FB8622278BF7F823675883F8B57C9BC081420F96C7F71E006D3A41299711E6E283F7C97E1ECC1202D98DF0BB13742D8DB5FDFE4569C35E207983645AE86AA2286680A9EDB69742DBD164D499096C90A063EE6304C81D2DB8311A73F80D7E1BB14B2C0C249D14F7D953369513731A5DEDB2AAD671E74F704CAFBCF4CDEDB72E42A238DD9CA2AB77ABAE80350F508062276A66C9BF81C325368E496C9490B > > From debugging it looks like it picked up the salt for PBKFD#2?and the > Iv for AES, but it is a bit nested, so I tried passing Cipher and/or Key > to getKeySpec(). > > The output > > en javax.crypto.EncryptedPrivateKeyInfo at 27716f4 > alg=1.2.840.113549.1.5.13 p=PBEWithHmacSHA1AndAES_256 > Exception in thread "main" java.security.spec.InvalidKeySpecException: > Cannot retrieve the PKCS8EncodedKeySpec > at > javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:255) > at bernd.TestKey.main(TestKey.java:61) > Caused by: javax.crypto.BadPaddingException: Given final block not > properly padded. Such issues can arise if a bad key is used during > decryption. > at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975) > at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056) > at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) > at com.sun.crypto.provider.PBES2Core.engineDoFinal(PBES2Core.java:323) > at javax.crypto.Cipher.doFinal(Cipher.java:2168) > at > javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:250) > ... 1 more > > I see there are some test cases for a similar usage, but they depend on > an initialized key with defaults, so I am not sure if that would > actually use AES IV? > > https://github.com/openjdk/jdk/blob/357f990e3244feaba6d8709b7ea50660220a418b/test/jdk/sun/security/x509/AlgorithmId/PBES2.java#L89 > > BTW: its hard to say if the problem is "only" caused by UTF-8 vs. UTF-16 > password encoding. In that case it would be a bit unfortunate, is it > maybe an option to add that support? (however I am not sure what > password encoding openssl uses in this case). > From anthony.scarpino at oracle.com Tue Aug 9 01:26:46 2022 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 8 Aug 2022 18:26:46 -0700 Subject: PKCS8 with PBES2 protection supported by EncryptedPrivateKeyInfo? In-Reply-To: <478e9032-1b47-1ffc-38cb-93bbe05d1903@oracle.com> References: <478e9032-1b47-1ffc-38cb-93bbe05d1903@oracle.com> Message-ID: Oops.. I think I suggested something that only works in my development repo with PBES2. I ran you code and it worked on jdk-dev. Other than setting -v2 on the 'openssl pkcs8' cmdline, en javax.crypto.EncryptedPrivateKeyInfo at 46d56d67 alg=PBEWithHmacSHA1AndAES_256 p=PBEWithHmacSHA1AndAES_256 k=SunRsaSign RSA private CRT key, 2048 bits params: null modulus: ... Tony On 8/8/22 5:12 PM, Anthony Scarpino wrote: > Hi, > > I did this not long ago. You are close, but you do not need to do the > Cipher.init() separately, it is done as part of > EncryptedPrivateKeyInfo.getKeySpec().? It also reads the encoding for > the count and iv. > > The below will decrypt the DER-encoded 'data' into a > PKCS8EncryptedKeySpec for you to use. > > EncryptedPrivateKeyInfo epki = new EncryptedPrivateKeyInfo(data); > PBEKeySpec pks = new PBEKeySpec(password); > SecretKeyFactory skf = SecretKeyFactory.getInstance(epki.getAlgName()); > SecretKey sk = skf.generateSecret(pks); > PKCS8EncodedKeySpec keySpec = epki.getKeySpec(sk); > > Tony > > On 8/7/22 12:18 PM, Bernd wrote: >> Hello, >> >> there is a longstanding issue in the PostgreSQL JDBC driver which >> reads secret keys in PKCS#8 format, but does not support the newer >> PKCS#5 2.0 (PBES2) modes (-v1 works). The (naive) code is here: >> >> pgjdbc/LazyKeyManager.java at 80d4ed34c99d51dd8b06df00baad0265fd620fec >> ? pgjdbc/pgjdbc ? GitHub >> >> >> I was playing around with EncryptedPrivateKeyInfo in order to see >> whats needed to get it working with PBES2 encryption, but it did not >> work with quite a few tries. >> >> I wonder is the Code behind PBES2Parameters?in JCE supposed to work >> and?interoperable with openssl PKCS#8? If I understand the api >> correctly the following code should work, but it results in a padding >> error: >> >> ?? ? public static void main(String[] args) throws Throwable >> ?? ? { >> ?? ? ? ? byte[] b = readFileFully("test-key.p8"); // DER Format >> ?? ? ? ? EncryptedPrivateKeyInfo ePKInfo = new >> EncryptedPrivateKeyInfo(b); >> ?? ? ? ? System.out.println("en " + ePKInfo + " alg=" + >> ePKInfo.getAlgName() >> ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?+ " p=" + >> ePKInfo.getAlgParameters().toString()); >> ?? ? ? ? AlgorithmParameters algParams = ePKInfo.getAlgParameters(); >> ?? ? ? ? //PBEParameterSpec pbep = >> algParams.getParameterSpec(PBEParameterSpec.class); >> ?? ? ? ? //System.out.println("pbep " + pbep); >> ?? ? ? ? //AlgorithmParameterSpec cp = pbep.getParameterSpec(); >> ?? ? ? ? //System.out.println("cp = " + cp ); // IvParameters >> >> ?? ? ? ? PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray()); >> ?? ? ? ? //PBEKeySpec pbeKeySpec = new PBEKeySpec("test".toCharArray(), >> ?? ? ? ? // ??pbep.getSalt(), pbep.getIterationCount(), 256); >> ?? ? ? ? SecretKeyFactory skFac = >> SecretKeyFactory.getInstance(algParams.toString()); >> ?? ? ? ? Key pbeKey = skFac.generateSecret(pbeKeySpec); >> >> ?? ? ? ? Cipher cipher = Cipher.getInstance(algParams.toString()); >> ?? ? ? ? cipher.init(Cipher.DECRYPT_MODE, pbeKey, algParams); >> >> ?? ? ? ? // Decrypt the encrypted private key >> ?? ? ? ? // when passing pbeKey here instead of cipher the algParams >> are lost >> ?? ? ? ? KeySpec pkcs8KeySpec = ePKInfo.getKeySpec(cipher); // L61 --> >> throws >> >> ?? ? ? ? // not reached >> ?? ? ? ? KeyFactory kf = KeyFactory.getInstance("RSA"); >> ?? ? ? ? PrivateKey key = kf.generatePrivate(pkcs8KeySpec); >> ?? ? ? ? System.out.println("k=" + key); >> } >> >> The test object created with openssl: >> ?> openssl req -x509 -newkey rsa:2048 -keyout test-key.pem -out >> test-cert.pem -sha256 -days 365 -nodes >> ?> openssl pkcs8 -topk8 -in test-key.pem -out test-key.p8 -outform der >> # password "test" >> ?> openssl asn1parse -in test-key.p8 -inform DER >> ?? ? 0:d=0? hl=4 l=1325 cons: SEQUENCE >> ?? ? 4:d=1? hl=2 l=? 87 cons: SEQUENCE >> ?? ? 6:d=2? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :PBES2 >> ?? ?17:d=2? hl=2 l=? 74 cons: SEQUENCE >> ?? ?19:d=3? hl=2 l=? 41 cons: SEQUENCE >> ?? ?21:d=4? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :PBKDF2 >> ?? ?32:d=4? hl=2 l=? 28 cons: SEQUENCE >> ?? ?34:d=5? hl=2 l=? ?8 prim: OCTET STRING? ? ? [HEX >> DUMP]:BDCF0B11DB8BAFAB >> ?? ?44:d=5? hl=2 l=? ?2 prim: INTEGER? ? ? ? ? ?:0800 >> ?? ?48:d=5? hl=2 l=? 12 cons: SEQUENCE >> ?? ?50:d=6? hl=2 l=? ?8 prim: OBJECT? ? ? ? ? ? :hmacWithSHA256 >> ?? ?60:d=6? hl=2 l=? ?0 prim: NULL >> ?? ?62:d=3? hl=2 l=? 29 cons: SEQUENCE >> ?? ?64:d=4? hl=2 l=? ?9 prim: OBJECT? ? ? ? ? ? :aes-256-cbc >> ?? ?75:d=4? hl=2 l=? 16 prim: OCTET STRING? ? ? [HEX >> DUMP]:E355E1C72C9F486DDBE2E1F58EE7B61E >> ?? ?93:d=1? hl=4 l=1232 prim: OCTET STRING? ? ? [HEX >> DUMP]:E4D9C29E4789840093EE371AB6EACB3111920E636CCB924651125D97CBD5312156214AD173CF4159AEEDBB497900815FE3B24184846CA252A421784CAD121B59C93EE3427BEA7CF0E404FAD0F226A2D13B86BD4898455B0750FBA6C4FB5F0B66980BD586CFFCBB5FA2170A67917FD55F7AF0E03D03078E5191965F74C099E357F28B6DA969E3CF3D713ABBC35C20A513E8068822A1C9B67BAFB650FB4B8EB7755A9F1760CD0B82AEBFBCCA01F575C377CD5AA2732D42F10A43EEF46048650E492F9FE1FD56596DDAC70461BF3E60CEA97F7EA99741254D1C1452CF1081DD799EACC74C8C0E806104230AE91E560C8F458B7BB358F031726355E99D31938CF39EC40B76D963FC3D45A59C7BE14CC769E7E4DA8C9FC08F4BD1A4C4CC07141BA0D5A31F0319E32D48A12A2BA4ABA4979A68447AFA57B8A9F82D465B1E765169B1C339C88F9EC9934B0B1B58C5793991FB9990F44C9C7A816ABE97015ECFB408CBF906BABAF9C7F5D0F32673AA1D9D72A0C3738FC9C1909FB24A029A3928C583B2DE4CCF3247F7C89D97E8DEEF3E08796789D43B56A66D1C07B3D368948964FAA1746EEC59605A14934B02BFE14B6BC8A281973E76215E7FF9A43FD33780F34D76A21791586EDBA5999BCE08D8DF5E20B736DDA9B91091991B0EE883CC3E8358D8403486B53D205C0DD33EE3224D1BE40DE9FCD444D70BDE6500B08FF843153EC8EF01F5CDC9D01CB9372BBCA6F42D5D13159AC9E67CAB075A20D86F9538AE604E87DEBF1300D3E6A8BEB72F1F2124F903E95A558DE3BEB61A1AAE792E9A77A6F860BD736D2C0BA97FDA25D4E3AEAF8149415E68E473F48D99860DC2A49F108AE5468DFC36A5764E3B06412D2C3498D87E9F5D487421FD5C15C0EA8306A69BFA2956D8F8C1F4CD4786EDE575515202F8442CBA2E3AA21CB267DDEC5BA7BB1CBC54F471E84CD522FCE9A69F084DD4EB100F00875A0A32BCCD6D5F5473FF8CA6E6B448BAB76A659E0350AAFC3A2EFBCCAF1AFB52F3C8A7F3B452E5B35CDC2CD05710D86529EE3544DE9AB5A7FAA9AD8ADC93B0F7F5432FF8EB280A3BEE3C094796C9938DC5A4956D47CE4CE7A7D2300E328D47F030332EC84296CD57F02B61B63A099210C78F64B3DB618E79A17585030CB82B8B39BB34333D148F5856D04B4083BD0F006B8A747D7E020DDD8DCA99AEF6B719367DB619C7736D7897F071875CC9C17F7AF3E742F06CDBEBECDF486CC6B143BB96FC4FE34A54CB1CBFDF877598094B459DBAA6B101B0DE8000A5E2D06ABAE1C651EDF3EA3A7D37EA263AC999B65F621E1F65FFD06F461B7285EB90AE2C32AA60C8424966BF37F2C4F502BFE253E252C1CD652FC8667E488BF8B282D0379B38AC9B53014C87C55E8DE8EB7A217F521F46FC13F983C3E77B61417A552D7ACC147FC40C295DD87DDC4972AF340384B449A8A888BD1F4AB7B5B2D6AB3E963F7E90870639709075FA4A618A640753B6E2B6B4C0734BFEEE7A14C94C64131C666749E813A07FB8622278BF7F823675883F8B57C9BC081420F96C7F71E006D3A41299711E6E283F7C97E1ECC1202D98DF0BB13742D8DB5FDFE4569C35E207983645AE86AA2286680A9EDB69742DBD164D499096C90A063EE6304C81D2DB8311A73F80D7E1BB14B2C0C249D14F7D953369513731A5DEDB2AAD671E74F704CAFBCF4CDEDB72E42A238DD9CA2AB77ABAE80350F508062276A66C9BF81C325368E496C9490B >> >> ?From debugging it looks like it picked up the salt for PBKFD#2?and >> the Iv for AES, but it is a bit nested, so I tried passing Cipher >> and/or Key to getKeySpec(). >> >> The output >> >> en javax.crypto.EncryptedPrivateKeyInfo at 27716f4 >> alg=1.2.840.113549.1.5.13 p=PBEWithHmacSHA1AndAES_256 >> Exception in thread "main" java.security.spec.InvalidKeySpecException: >> Cannot retrieve the PKCS8EncodedKeySpec >> at >> javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:255) >> at bernd.TestKey.main(TestKey.java:61) >> Caused by: javax.crypto.BadPaddingException: Given final block not >> properly padded. Such issues can arise if a bad key is used during >> decryption. >> at com.sun.crypto.provider.CipherCore.unpad(CipherCore.java:975) >> at >> com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1056) >> at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) >> at com.sun.crypto.provider.PBES2Core.engineDoFinal(PBES2Core.java:323) >> at javax.crypto.Cipher.doFinal(Cipher.java:2168) >> at >> javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(EncryptedPrivateKeyInfo.java:250) >> ... 1 more >> >> I see there are some test cases for a similar usage, but they depend >> on an initialized key with defaults, so I am not sure if that would >> actually use AES IV? >> >> https://github.com/openjdk/jdk/blob/357f990e3244feaba6d8709b7ea50660220a418b/test/jdk/sun/security/x509/AlgorithmId/PBES2.java#L89 >> >> BTW: its hard to say if the problem is "only" caused by UTF-8 vs. >> UTF-16 password encoding. In that case it would be a bit unfortunate, >> is it maybe an option to add that support? (however I am not sure what >> password encoding openssl uses in this case). >> From xuelei at openjdk.org Tue Aug 9 15:30:57 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 9 Aug 2022 15:30:57 GMT Subject: RFR: 8281236: (D)TLS key exchange named groups [v2] In-Reply-To: References: Message-ID: > This update is to support key exchange named groups customization for individual (D)TLS connection. Please review the CSR as well: > CSR: https://bugs.openjdk.org/browse/JDK-8291950 > RFE: https://bugs.openjdk.org/browse/JDK-8281236 > Release-note: https://bugs.openjdk.org/browse/JDK-8291975 > > This is an effort similar to [JDK-8280494: "(D)TLS signature schemes"](https://bugs.openjdk.org/browse/JDK-8280494) Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - add test cases - 8281236: (D)TLS key exchange algorithms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9776/files - new: https://git.openjdk.org/jdk/pull/9776/files/30697d04..d2b9999c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9776&range=00-01 Stats: 8136 lines in 395 files changed: 4969 ins; 2096 del; 1071 mod Patch: https://git.openjdk.org/jdk/pull/9776.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9776/head:pull/9776 PR: https://git.openjdk.org/jdk/pull/9776 From xuelei at openjdk.org Tue Aug 9 15:32:24 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 9 Aug 2022 15:32:24 GMT Subject: RFR: 8291949: Unexpected extending of SupportedGroups [v2] In-Reply-To: References: Message-ID: <0WBGynp6vbcoCGa0SsODPQ-uPJcawHOOtI91mLLjVMU=.b7b1db84-aebe-4c33-9d6e-1e2e1d698243@github.com> > In the SunJSSE implementation, there are a few unexpected extending of static class SupportedGroups. It may be nice to clean them up so that the code is easier to read. Please review this simple code clean up. Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge - 8291949: Unexpected extending of SupportedGroups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9765/files - new: https://git.openjdk.org/jdk/pull/9765/files/90be6884..455d4846 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9765&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9765&range=00-01 Stats: 8136 lines in 395 files changed: 4969 ins; 2096 del; 1071 mod Patch: https://git.openjdk.org/jdk/pull/9765.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9765/head:pull/9765 PR: https://git.openjdk.org/jdk/pull/9765 From asemenyuk at openjdk.org Tue Aug 9 17:53:36 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 9 Aug 2022 17:53:36 GMT Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung wrote: >> open l10n msg drop >> All tests passed. > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good. Approved that part. ------------- PR: https://git.openjdk.org/jdk19/pull/154 From bdw429s at gmail.com Tue Aug 9 19:29:03 2022 From: bdw429s at gmail.com (Brad Wood) Date: Tue, 9 Aug 2022 14:29:03 -0500 Subject: Post handshake client verification with TLSv1.3 Message-ID: I have some questions about this ticket https://bugs.openjdk.org/browse/JDK-8206923 which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL renegotiation after the handshake in the traditional manner, but I'm curious if the process defined here can be used instead: https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. There's not a lot of information online, but this ticket appears to be Python adding support for this: https://bugs.python.org/issue34670 Can we discuss reopening the openjdk ticket if this is actually possible? The use case for this is a rather common requirement-- to have an SSL site which doesn't prompt the user for a client cert until they visit a secured area, and then the client cert request is sent, prompting the user at that point. Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to work. I don't mind sticking to HTTP/1. but I have concerns about disabling TLSv1.3 and what that means for the future security of my apps. Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From achung at openjdk.org Tue Aug 9 22:30:54 2022 From: achung at openjdk.org (Alisen Chung) Date: Tue, 9 Aug 2022 22:30:54 GMT Subject: [jdk19] Integrated: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote: > open l10n msg drop > All tests passed. This pull request has now been integrated. Changeset: 0def5316 Author: Alisen Chung Committer: Alexey Semenyuk URL: https://git.openjdk.org/jdk19/commit/0def5316cd2ec7699c649bf67bf58e6315c3010b Stats: 684 lines in 42 files changed: 87 ins; 540 del; 57 mod 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 Reviewed-by: naoto, asemenyuk ------------- PR: https://git.openjdk.org/jdk19/pull/154 From xuelei.f at gmail.com Wed Aug 10 02:05:13 2022 From: xuelei.f at gmail.com (Xuelei Fan) Date: Tue, 9 Aug 2022 19:05:13 -0700 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: References: Message-ID: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> If we have a look from the viewpoint of HTTP/2, how applications could meet the requirements in HTTP/2? Did you have a plan to have the application works with HTTP/2 in the future? Xuelei > On Aug 9, 2022, at 12:29 PM, Brad Wood wrote: > > I have some questions about this ticket > https://bugs.openjdk.org/browse/JDK-8206923 > which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL renegotiation after the handshake in the traditional manner, but I'm curious if the process defined here can be used instead: > https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html > > I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. > > There's not a lot of information online, but this ticket appears to be Python adding support for this: > https://bugs.python.org/issue34670 > > Can we discuss reopening the openjdk ticket if this is actually possible? The use case for this is a rather common requirement-- to have an SSL site which doesn't prompt the user for a client cert until they visit a secured area, and then the client cert request is sent, prompting the user at that point. > Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to work. I don't mind sticking to HTTP/1. but I have concerns about disabling TLSv1.3 and what that means for the future security of my apps. > > Thanks! > > ~Brad > > Developer Advocate > Ortus Solutions, Corp > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeys at openjdk.org Wed Aug 10 08:56:30 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 10 Aug 2022 08:56:30 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeli?ski wrote: > Fix `SSLEngineService` test class to make sure it does not discard any network data between `handshaking` and `receive`. > > With TLS1.3 the client starts sending application data immediately after sending the Finished message. The server may read some of that data in the `handshaking` method. This patch makes sure that any such data is delivered to the `receive` method for processing. Nice work! ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.org/jdk/pull/9773 From bdw429s at gmail.com Wed Aug 10 13:49:32 2022 From: bdw429s at gmail.com (Brad Wood) Date: Wed, 10 Aug 2022 08:49:32 -0500 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> Message-ID: Honestly, what does HTTP/2 have to do with the ticket in question? TLS 1.3 supports a post-handshake method of requesting client certs without renegotiating the entire SSL handshake. Java needs to support this. >From my research, any other web server such as Nginx simply requires that HTTP/1 be used when this feature is needed. I suggest we do the same. If you are concerned about the future of HTP/2, I would direct you to some proposed updates to the HTTP/2 which will accommodate post handshake client cert requests: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs In the mean time, I have no issues using HTTP/1 for the specific apps that require this. Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan wrote: > If we have a look from the viewpoint of HTTP/2, how applications could > meet the requirements in HTTP/2? Did you have a plan to have the > application works with HTTP/2 in the future? > > Xuelei > > On Aug 9, 2022, at 12:29 PM, Brad Wood wrote: > > I have some questions about this ticket > https://bugs.openjdk.org/browse/JDK-8206923 > which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL > renegotiation after the handshake in the traditional manner, but I'm > curious if the process defined here can be used instead: > > https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html > > I'm new to this, but it appears to be describing how to accomplish > post-handshake client verification which works on TLS 1.3. > > There's not a lot of information online, but this ticket appears to be > Python adding support for this: > https://bugs.python.org/issue34670 > > Can we discuss reopening the openjdk ticket if this is actually possible? > The use case for this is a rather common requirement-- to have an SSL site > which doesn't prompt the user for a client cert until they visit a secured > area, and then the client cert request is sent, prompting the user at that > point. > Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to > work. I don't mind sticking to HTTP/1. but I have concerns about disabling > TLSv1.3 and what that means for the future security of my apps. > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeys at openjdk.org Wed Aug 10 13:52:48 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 10 Aug 2022 13:52:48 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: CSR review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9747/files - new: https://git.openjdk.org/jdk/pull/9747/files/2f8fc74f..e2f04835 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=00-01 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9747.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9747/head:pull/9747 PR: https://git.openjdk.org/jdk/pull/9747 From alanb at openjdk.org Wed Aug 10 14:07:38 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Aug 2022 14:07:38 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Wed, 10 Aug 2022 13:52:48 GMT, Sean Coffey wrote: >> In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. >> >> CSR in progress. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > CSR review comments src/java.base/share/classes/java/security/Security.java line 52: > 50: * @implNote If the master security properties file is missing, the JDK > 51: * implementation will throw an {@code InternalError} when initializing the > 52: * {@code Security} class. Is "master security properties file" the right term here? The only use of "master" in this class seems to be a deprecated method. I'm also not sure about the word "missing" as there can be many reasons why opening a file may fail, e.g. something changes the permissions or file owner so that it can't be opened for example. The implNote need not be specific on the exception that is thrown, it could say "will throw an unspecified exception ..." ------------- PR: https://git.openjdk.org/jdk/pull/9747 From coffeys at openjdk.org Wed Aug 10 14:26:42 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 10 Aug 2022 14:26:42 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Wed, 10 Aug 2022 14:03:59 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> CSR review comments > > src/java.base/share/classes/java/security/Security.java line 52: > >> 50: * @implNote If the master security properties file is missing, the JDK >> 51: * implementation will throw an {@code InternalError} when initializing the >> 52: * {@code Security} class. > > Is "master security properties file" the right term here? The only use of "master" in this class seems to be a deprecated method. > > I'm also not sure about the word "missing" as there can be many reasons why opening a file may fail, e.g. something changes the permissions or file owner so that it can't be opened for example. > > The implNote need not be specific on the exception that is thrown, it could say "will throw an unspecified exception ..." The opening line of the java.security file denotes it as the "master security properties file". I think it works well but open to suggestions. Maybe we can re-use the terminology from previous paragraph. Fair point about the "missing" and error clause -- perhaps: ``` @implNote If the file containing the default values of security properties fails to load, * the JDK implementation will throw an unspecified error when initializing the * {@code Security} class. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From xuelei.f at gmail.com Wed Aug 10 14:36:38 2022 From: xuelei.f at gmail.com (Xuelei Fan) Date: Wed, 10 Aug 2022 07:36:38 -0700 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> Message-ID: <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> > On Aug 10, 2022, at 6:49 AM, Brad Wood wrote: > > Honestly, what does HTTP/2 have to do with the ticket in question? The future of HTTP is my concern here. Thank you for sharing the link (draft RFC) bellow. Xuelei > TLS 1.3 supports a post-handshake method of requesting client certs without renegotiating the entire SSL handshake. Java needs to support this. > > From my research, any other web server such as Nginx simply requires that HTTP/1 be used when this feature is needed. I suggest we do the same. If you are concerned about the future of HTP/2, I would direct you to some proposed updates to the HTTP/2 which will accommodate post handshake client cert requests: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs In the mean time, I have no issues using HTTP/1 for the specific apps that require this. > > Thanks! > > ~Brad > > Developer Advocate > Ortus Solutions, Corp > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan > wrote: > If we have a look from the viewpoint of HTTP/2, how applications could meet the requirements in HTTP/2? Did you have a plan to have the application works with HTTP/2 in the future? > > Xuelei > >> On Aug 9, 2022, at 12:29 PM, Brad Wood > wrote: >> >> I have some questions about this ticket >> https://bugs.openjdk.org/browse/JDK-8206923 >> which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL renegotiation after the handshake in the traditional manner, but I'm curious if the process defined here can be used instead: >> https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html >> >> I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. >> >> There's not a lot of information online, but this ticket appears to be Python adding support for this: >> https://bugs.python.org/issue34670 >> >> Can we discuss reopening the openjdk ticket if this is actually possible? The use case for this is a rather common requirement-- to have an SSL site which doesn't prompt the user for a client cert until they visit a secured area, and then the client cert request is sent, prompting the user at that point. >> Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to work. I don't mind sticking to HTTP/1. but I have concerns about disabling TLSv1.3 and what that means for the future security of my apps. >> >> Thanks! >> >> ~Brad >> >> Developer Advocate >> Ortus Solutions, Corp >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mullan at openjdk.org Wed Aug 10 14:46:33 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 10 Aug 2022 14:46:33 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Wed, 10 Aug 2022 14:22:43 GMT, Sean Coffey wrote: >> src/java.base/share/classes/java/security/Security.java line 52: >> >>> 50: * @implNote If the master security properties file is missing, the JDK >>> 51: * implementation will throw an {@code InternalError} when initializing the >>> 52: * {@code Security} class. >> >> Is "master security properties file" the right term here? The only use of "master" in this class seems to be a deprecated method. >> >> I'm also not sure about the word "missing" as there can be many reasons why opening a file may fail, e.g. something changes the permissions or file owner so that it can't be opened for example. >> >> The implNote need not be specific on the exception that is thrown, it could say "will throw an unspecified exception ..." > > The opening line of the java.security file denotes it as the "master security properties file". I think it works well but open to suggestions. Maybe we can re-use the terminology from previous paragraph. > > Fair point about the "missing" and error clause -- perhaps: > ``` > @implNote If the file containing the default values of security properties fails to load, > * the JDK implementation will throw an unspecified error when initializing the > * {@code Security} class. I think if you just said "If this properties file ..." it would be sufficient, as the previous paragraph provided enough context as to what you are referring to. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From xuelei at openjdk.org Wed Aug 10 15:42:40 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 10 Aug 2022 15:42:40 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: References: Message-ID: <1rQxCSF1xIGE5ChsUE-cCqjt3R_cAE0h5QuKN09t8us=.f949a093-0f73-400c-baa7-80c5a062606d@github.com> On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeli?ski wrote: > Fix `SSLEngineService` test class to make sure it does not discard any network data between `handshaking` and `receive`. > > With TLS1.3 the client starts sending application data immediately after sending the Finished message. The server may read some of that data in the `handshaking` method. This patch makes sure that any such data is delivered to the `receive` method for processing. Could it be a TLS implementation problem that the server should not read application data as handshaking data? ------------- PR: https://git.openjdk.org/jdk/pull/9773 From ecki at zusammenkunft.net Wed Aug 10 16:02:29 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 10 Aug 2022 16:02:29 +0000 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> Message-ID: Hello Brad, (Unrelated to the discussion if the feature should be added to JSSE TLS 1.3, but then again an argument about priotizing it since it seems to be not used with future HTTPS versions - which is relevant for the discussion if it?s needed) Just want to mention my feeling that with all the ongoing complications and unclear future http behavior I think it would now be a good time for you to seperate the (virtual) hostnames for admin and normal activities. This would not only allows you to request certificates unconditionally, it also will increase session/cookie and XSS/CSP separation. Not to mention the additional benefit of using different access control lists in infrastructure - if needed. Before implementing this I would prefer to have more hybrid encryption features, access to existing TLS session cache (FTP Server) or more per-connection parameters instead. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: security-dev im Auftrag von Xuelei Fan Gesendet: Wednesday, August 10, 2022 4:36:38 PM An: Brad Wood Cc: security-dev at openjdk.org Betreff: Re: Post handshake client verification with TLSv1.3 On Aug 10, 2022, at 6:49 AM, Brad Wood > wrote: Honestly, what does HTTP/2 have to do with the ticket in question? The future of HTTP is my concern here. Thank you for sharing the link (draft RFC) bellow. Xuelei TLS 1.3 supports a post-handshake method of requesting client certs without renegotiating the entire SSL handshake. Java needs to support this. >From my research, any other web server such as Nginx simply requires that HTTP/1 be used when this feature is needed. I suggest we do the same. If you are concerned about the future of HTP/2, I would direct you to some proposed updates to the HTTP/2 which will accommodate post handshake client cert requests: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs In the mean time, I have no issues using HTTP/1 for the specific apps that require this. Thanks! ~Brad Developer Advocate Ortus Solutions, Corp E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan > wrote: If we have a look from the viewpoint of HTTP/2, how applications could meet the requirements in HTTP/2? Did you have a plan to have the application works with HTTP/2 in the future? Xuelei On Aug 9, 2022, at 12:29 PM, Brad Wood > wrote: I have some questions about this ticket https://bugs.openjdk.org/browse/JDK-8206923 which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL renegotiation after the handshake in the traditional manner, but I'm curious if the process defined here can be used instead: https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. There's not a lot of information online, but this ticket appears to be Python adding support for this: https://bugs.python.org/issue34670 Can we discuss reopening the openjdk ticket if this is actually possible? The use case for this is a rather common requirement-- to have an SSL site which doesn't prompt the user for a client cert until they visit a secured area, and then the client cert request is sent, prompting the user at that point. Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to work. I don't mind sticking to HTTP/1. but I have concerns about disabling TLSv1.3 and what that means for the future security of my apps. Thanks! ~Brad Developer Advocate Ortus Solutions, Corp E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdw429s at gmail.com Wed Aug 10 16:04:06 2022 From: bdw429s at gmail.com (Brad Wood) Date: Wed, 10 Aug 2022 11:04:06 -0500 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> Message-ID: > > The future of HTTP is my concern here > I get that, but my current client requirements is my concern here :) Let's not throw the baby out with the bathwater because of what may come. If there is a post-handshake client verification that works via TLSv1.3 over HTTP/1, let's not prevent people from using that today (taking into account Browser support, of course). Once the HTTP/2 spec has been ironed out (which I know can take years) then java can cross that bridge when it comes to it. Thanks! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan wrote: > > > On Aug 10, 2022, at 6:49 AM, Brad Wood wrote: > > Honestly, what does HTTP/2 have to do with the ticket in question? > > > The future of HTTP is my concern here. Thank you for sharing the link > (draft RFC) bellow. > > Xuelei > > > > TLS 1.3 supports a post-handshake method of requesting client certs > without renegotiating the entire SSL handshake. Java needs to support > this. > > From my research, any other web server such as Nginx simply requires that > HTTP/1 be used when this feature is needed. I suggest we do the same. If > you are concerned about the future of HTP/2, I would direct you to some > proposed updates to the HTTP/2 which will accommodate post handshake client > cert requests: > https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs > In the mean time, I have no issues using HTTP/1 for the specific apps that > require this. > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan wrote: > >> If we have a look from the viewpoint of HTTP/2, how applications could >> meet the requirements in HTTP/2? Did you have a plan to have the >> application works with HTTP/2 in the future? >> >> Xuelei >> >> On Aug 9, 2022, at 12:29 PM, Brad Wood wrote: >> >> I have some questions about this ticket >> https://bugs.openjdk.org/browse/JDK-8206923 >> which was closed as "won't fix". I fully realize that TLS 1.3 forbids >> SSL renegotiation after the handshake in the traditional manner, but I'm >> curious if the process defined here can be used instead: >> >> https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html >> >> I'm new to this, but it appears to be describing how to accomplish >> post-handshake client verification which works on TLS 1.3. >> >> There's not a lot of information online, but this ticket appears to be >> Python adding support for this: >> https://bugs.python.org/issue34670 >> >> Can we discuss reopening the openjdk ticket if this is actually >> possible? The use case for this is a rather common requirement-- to have >> an SSL site which doesn't prompt the user for a client cert until they >> visit a secured area, and then the client cert request is sent, prompting >> the user at that point. >> Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to >> work. I don't mind sticking to HTTP/1. but I have concerns about disabling >> TLSv1.3 and what that means for the future security of my apps. >> >> Thanks! >> >> ~Brad >> >> *Developer Advocate* >> *Ortus Solutions, Corp * >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Aug 10 16:13:40 2022 From: duke at openjdk.org (Bernd) Date: Wed, 10 Aug 2022 16:13:40 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Wed, 10 Aug 2022 14:43:00 GMT, Sean Mullan wrote: >> The opening line of the java.security file denotes it as the "master security properties file". I think it works well but open to suggestions. Maybe we can re-use the terminology from previous paragraph. >> >> Fair point about the "missing" and error clause -- perhaps: >> ``` >> @implNote If the file containing the default values of security properties fails to load, >> * the JDK implementation will throw an unspecified error when initializing the >> * {@code Security} class. > > I think if you just said "If this properties file ..." it would be sufficient, as the previous paragraph provided enough context as to what you are referring to. Btw the current code does not handlmissing or unreadable overwrite files very well. PropsLoaded will be true even when the replacing overwrite file could not be loaded (resulting in an empty list). ------------- PR: https://git.openjdk.org/jdk/pull/9747 From djelinski at openjdk.org Wed Aug 10 16:35:41 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 Aug 2022 16:35:41 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: <1rQxCSF1xIGE5ChsUE-cCqjt3R_cAE0h5QuKN09t8us=.f949a093-0f73-400c-baa7-80c5a062606d@github.com> References: <1rQxCSF1xIGE5ChsUE-cCqjt3R_cAE0h5QuKN09t8us=.f949a093-0f73-400c-baa7-80c5a062606d@github.com> Message-ID: On Wed, 10 Aug 2022 15:40:26 GMT, Xue-Lei Andrew Fan wrote: > Could it be a TLS implementation problem that the server should not read application data as handshaking data? Not really; `SSLEngine#unwrap` does not have to consume the entire ByteBuffer, and it's the application's responsibility to preserve unconsumed data for subsequent `unwrap` calls in case of buffer underflow/overflow. There are 2 problems with the existing implementation: - `unwrap` in `handshaking` can consume (and discard) application data because `peerAppData` has nonzero size (does not happen in practice) - `handshaking` can lose unconsumed `peerNetData` Both are fixed here. ------------- PR: https://git.openjdk.org/jdk/pull/9773 From xuelei.f at gmail.com Wed Aug 10 16:59:42 2022 From: xuelei.f at gmail.com (Xuelei Fan) Date: Wed, 10 Aug 2022 09:59:42 -0700 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> Message-ID: I opened the bug. As this feature does not apply to HTTP/2, it may be not enabled by default. But please stay tuned for what it may look like. Xuelei > On Aug 10, 2022, at 9:04 AM, Brad Wood wrote: > > The future of HTTP is my concern here > > I get that, but my current client requirements is my concern here :) Let's not throw the baby out with the bathwater because of what may come. If there is a post-handshake client verification that works via TLSv1.3 over HTTP/1, let's not prevent people from using that today (taking into account Browser support, of course). Once the HTTP/2 spec has been ironed out (which I know can take years) then java can cross that bridge when it comes to it. > > Thanks! > > ~Brad > > Developer Advocate > Ortus Solutions, Corp > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan > wrote: > > >> On Aug 10, 2022, at 6:49 AM, Brad Wood > wrote: >> >> Honestly, what does HTTP/2 have to do with the ticket in question? > > The future of HTTP is my concern here. Thank you for sharing the link (draft RFC) bellow. > > Xuelei > > > >> TLS 1.3 supports a post-handshake method of requesting client certs without renegotiating the entire SSL handshake. Java needs to support this. >> >> From my research, any other web server such as Nginx simply requires that HTTP/1 be used when this feature is needed. I suggest we do the same. If you are concerned about the future of HTP/2, I would direct you to some proposed updates to the HTTP/2 which will accommodate post handshake client cert requests: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs In the mean time, I have no issues using HTTP/1 for the specific apps that require this. >> >> Thanks! >> >> ~Brad >> >> Developer Advocate >> Ortus Solutions, Corp >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> >> >> On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan > wrote: >> If we have a look from the viewpoint of HTTP/2, how applications could meet the requirements in HTTP/2? Did you have a plan to have the application works with HTTP/2 in the future? >> >> Xuelei >> >>> On Aug 9, 2022, at 12:29 PM, Brad Wood > wrote: >>> >>> I have some questions about this ticket >>> https://bugs.openjdk.org/browse/JDK-8206923 >>> which was closed as "won't fix". I fully realize that TLS 1.3 forbids SSL renegotiation after the handshake in the traditional manner, but I'm curious if the process defined here can be used instead: >>> https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html >>> >>> I'm new to this, but it appears to be describing how to accomplish post-handshake client verification which works on TLS 1.3. >>> >>> There's not a lot of information online, but this ticket appears to be Python adding support for this: >>> https://bugs.python.org/issue34670 >>> >>> Can we discuss reopening the openjdk ticket if this is actually possible? The use case for this is a rather common requirement-- to have an SSL site which doesn't prompt the user for a client cert until they visit a secured area, and then the client cert request is sent, prompting the user at that point. >>> Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this to work. I don't mind sticking to HTTP/1. but I have concerns about disabling TLSv1.3 and what that means for the future security of my apps. >>> >>> Thanks! >>> >>> ~Brad >>> >>> Developer Advocate >>> Ortus Solutions, Corp >>> >>> E-mail: brad at coldbox.org >>> ColdBox Platform: http://www.coldbox.org >>> Blog: http://www.codersrevolution.com >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei at openjdk.org Wed Aug 10 17:00:30 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 10 Aug 2022 17:00:30 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeli?ski wrote: > Fix `SSLEngineService` test class to make sure it does not discard any network data between `handshaking` and `receive`. > > With TLS1.3 the client starts sending application data immediately after sending the Finished message. The server may read some of that data in the `handshaking` method. This patch makes sure that any such data is delivered to the `receive` method for processing. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9773 From xuelei at openjdk.org Wed Aug 10 17:00:32 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 10 Aug 2022 17:00:32 GMT Subject: RFR: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: References: <1rQxCSF1xIGE5ChsUE-cCqjt3R_cAE0h5QuKN09t8us=.f949a093-0f73-400c-baa7-80c5a062606d@github.com> Message-ID: On Wed, 10 Aug 2022 16:33:27 GMT, Daniel Jeli?ski wrote: > > Could it be a TLS implementation problem that the server should not read application data as handshaking data? > > Not really; `SSLEngine#unwrap` does not have to consume the entire ByteBuffer, and it's the application's responsibility to preserve unconsumed data for subsequent `unwrap` calls in case of buffer underflow/overflow. > > There are 2 problems with the existing implementation: > > * `unwrap` in `handshaking` can consume (and discard) application data because `peerAppData` has nonzero size (does not happen in practice) > * `handshaking` can lose unconsumed `peerNetData` > > Both are fixed here. Thank you for the details. ------------- PR: https://git.openjdk.org/jdk/pull/9773 From bdw429s at gmail.com Wed Aug 10 17:03:16 2022 From: bdw429s at gmail.com (Brad Wood) Date: Wed, 10 Aug 2022 12:03:16 -0500 Subject: Post handshake client verification with TLSv1.3 In-Reply-To: References: <125B2FF3-7F24-491F-8173-2F7964998AEB@gmail.com> <11A51D4B-BA16-4EB0-B36F-CE71CFF0AED9@gmail.com> Message-ID: Thanks for the help Xuelei! ~Brad *Developer Advocate* *Ortus Solutions, Corp * E-mail: brad at coldbox.org ColdBox Platform: http://www.coldbox.org Blog: http://www.codersrevolution.com On Wed, Aug 10, 2022 at 11:59 AM Xuelei Fan wrote: > I opened the bug. As this feature does not apply to HTTP/2, it may be not > enabled by default. But please stay tuned for what it may look like. > > Xuelei > > On Aug 10, 2022, at 9:04 AM, Brad Wood wrote: > > The future of HTTP is my concern here >> > > I get that, but my current client requirements is my concern here :) > Let's not throw the baby out with the bathwater because of what may come. > If there is a post-handshake client verification that works via TLSv1.3 > over HTTP/1, let's not prevent people from using that today (taking into > account Browser support, of course). Once the HTTP/2 spec has been ironed > out (which I know can take years) then java can cross that bridge when it > comes to it. > > Thanks! > > ~Brad > > *Developer Advocate* > *Ortus Solutions, Corp * > > E-mail: brad at coldbox.org > ColdBox Platform: http://www.coldbox.org > Blog: http://www.codersrevolution.com > > > > On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan wrote: > >> >> >> On Aug 10, 2022, at 6:49 AM, Brad Wood wrote: >> >> Honestly, what does HTTP/2 have to do with the ticket in question? >> >> >> The future of HTTP is my concern here. Thank you for sharing the link >> (draft RFC) bellow. >> >> Xuelei >> >> >> >> TLS 1.3 supports a post-handshake method of requesting client certs >> without renegotiating the entire SSL handshake. Java needs to support >> this. >> >> From my research, any other web server such as Nginx simply requires that >> HTTP/1 be used when this feature is needed. I suggest we do the same. If >> you are concerned about the future of HTP/2, I would direct you to some >> proposed updates to the HTTP/2 which will accommodate post handshake client >> cert requests: >> https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs >> In the mean time, I have no issues using HTTP/1 for the specific apps that >> require this. >> >> Thanks! >> >> ~Brad >> >> *Developer Advocate* >> *Ortus Solutions, Corp * >> >> E-mail: brad at coldbox.org >> ColdBox Platform: http://www.coldbox.org >> Blog: http://www.codersrevolution.com >> >> >> >> On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan wrote: >> >>> If we have a look from the viewpoint of HTTP/2, how applications could >>> meet the requirements in HTTP/2? Did you have a plan to have the >>> application works with HTTP/2 in the future? >>> >>> Xuelei >>> >>> On Aug 9, 2022, at 12:29 PM, Brad Wood wrote: >>> >>> I have some questions about this ticket >>> https://bugs.openjdk.org/browse/JDK-8206923 >>> which was closed as "won't fix". I fully realize that TLS 1.3 forbids >>> SSL renegotiation after the handshake in the traditional manner, but I'm >>> curious if the process defined here can be used instead: >>> >>> https://www.openssl.org/docs/manmaster/man3/SSL_verify_client_post_handshake.html >>> >>> I'm new to this, but it appears to be describing how to accomplish >>> post-handshake client verification which works on TLS 1.3. >>> >>> There's not a lot of information online, but this ticket appears to be >>> Python adding support for this: >>> https://bugs.python.org/issue34670 >>> >>> Can we discuss reopening the openjdk ticket if this is actually >>> possible? The use case for this is a rather common requirement-- to have >>> an SSL site which doesn't prompt the user for a client cert until they >>> visit a secured area, and then the client cert request is sent, prompting >>> the user at that point. >>> Currently, I have to disable both HTTP/2 and TLS 1.3 in order for this >>> to work. I don't mind sticking to HTTP/1. but I have concerns about >>> disabling TLSv1.3 and what that means for the future security of my apps. >>> >>> Thanks! >>> >>> ~Brad >>> >>> *Developer Advocate* >>> *Ortus Solutions, Corp * >>> >>> E-mail: brad at coldbox.org >>> ColdBox Platform: http://www.coldbox.org >>> Blog: http://www.codersrevolution.com >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski at openjdk.org Wed Aug 10 18:18:43 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 10 Aug 2022 18:18:43 GMT Subject: Integrated: 8227651: Tests fail with SSLProtocolException: Input record too big In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeli?ski wrote: > Fix `SSLEngineService` test class to make sure it does not discard any network data between `handshaking` and `receive`. > > With TLS1.3 the client starts sending application data immediately after sending the Finished message. The server may read some of that data in the `handshaking` method. This patch makes sure that any such data is delivered to the `receive` method for processing. This pull request has now been integrated. Changeset: 7b029ea6 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/7b029ea6ba1d44d361fdf980816732d8454b8194 Stats: 51 lines in 8 files changed: 5 ins; 5 del; 41 mod 8227651: Tests fail with SSLProtocolException: Input record too big 8212096: javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java failed intermittently due to SSLException: Tag mismatch Reviewed-by: coffeys, xuelei ------------- PR: https://git.openjdk.org/jdk/pull/9773 From dholmes at openjdk.org Thu Aug 11 05:26:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Aug 2022 05:26:56 GMT Subject: Integrated: Merge jdk19 Message-ID: Forward port JDK 19 -> JDK 20 ------------- Commit messages: - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19 - 8288769: Revert unintentional change to deflate.c - 8291496: Allocating card table before heap causes underflow asserts in CardTable::addr_for() - 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9828/files Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/9828.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9828/head:pull/9828 PR: https://git.openjdk.org/jdk/pull/9828 From dholmes at openjdk.org Thu Aug 11 05:26:56 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 11 Aug 2022 05:26:56 GMT Subject: Integrated: Merge jdk19 In-Reply-To: References: Message-ID: On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes wrote: > Forward port JDK 19 -> JDK 20 This pull request has now been integrated. Changeset: 85a60235 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4 Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/9828 From coffeys at openjdk.org Thu Aug 11 07:07:12 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 11 Aug 2022 07:07:12 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Wed, 10 Aug 2022 16:10:02 GMT, Bernd wrote: >> I think if you just said "If this properties file ..." it would be sufficient, as the previous paragraph provided enough context as to what you are referring to. > > Btw the current code does not handlmissing or unreadable overwrite files very well. PropsLoaded will be true even when the replacing overwrite file could not be loaded (resulting in an empty list). it's a fair point @ecki -- the 2nd `loadedProps = true;` call is redundant since the code block is not executed unless the `security.overridePropertiesFile` is set to true by reading the props from default/master file. one option here might be to delay the re-initialization of `props` until we successfully load the override security props file i.e. push this code block down if (overrideAll) { props = new Properties(); if (sdebug != null) { sdebug.println ("overriding other security properties files!"); } } I'll log another JBS issue to track that. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From coffeys at openjdk.org Thu Aug 11 07:13:34 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 11 Aug 2022 07:13:34 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v3] In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Incorporate review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9747/files - new: https://git.openjdk.org/jdk/pull/9747/files/e2f04835..0ae24472 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9747.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9747/head:pull/9747 PR: https://git.openjdk.org/jdk/pull/9747 From alanb at openjdk.org Thu Aug 11 10:41:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 11 Aug 2022 10:41:23 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v3] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Thu, 11 Aug 2022 07:13:34 GMT, Sean Coffey wrote: >> In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. >> >> CSR in progress. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments src/java.base/share/classes/java/security/Security.java line 52: > 50: * @implNote If this property file fails to load, the JDK implementation will > 51: * throw an unspecified error when initializing the {@code Security} class. > 52: * I think I'd probably "the property file" rather than "this property file" here but otherwise the implNote looks okay to me. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From redestad at openjdk.org Thu Aug 11 15:31:56 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 11 Aug 2022 15:31:56 GMT Subject: Integrated: 8288568: Reduce runtime of java.security microbenchmarks In-Reply-To: References: Message-ID: <_RJH72XltbGuNuoz_xuYBNg_r0d1zLqZc0QGC1fYeuQ=.29873ebd-6a5c-4662-a0d2-d5014fcfef66@github.com> On Thu, 16 Jun 2022 15:35:04 GMT, Claes Redestad wrote: > - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts. > > Reduces runtime from estimated 10+ hours to 54 minutes. This pull request has now been integrated. Changeset: a28ab7b6 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/a28ab7b62abcfce56425d62d5a8162d8f1623393 Stats: 49 lines in 10 files changed: 25 ins; 3 del; 21 mod 8288568: Reduce runtime of java.security microbenchmarks Reviewed-by: ecaspole, hchao, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9189 From djelinski at openjdk.org Fri Aug 12 09:52:28 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 12 Aug 2022 09:52:28 GMT Subject: RFR: 8291949: Unexpected extending of SupportedGroups [v2] In-Reply-To: <0WBGynp6vbcoCGa0SsODPQ-uPJcawHOOtI91mLLjVMU=.b7b1db84-aebe-4c33-9d6e-1e2e1d698243@github.com> References: <0WBGynp6vbcoCGa0SsODPQ-uPJcawHOOtI91mLLjVMU=.b7b1db84-aebe-4c33-9d6e-1e2e1d698243@github.com> Message-ID: On Tue, 9 Aug 2022 15:32:24 GMT, Xue-Lei Andrew Fan wrote: >> In the SunJSSE implementation, there are a few unexpected extending of static class SupportedGroups. It may be nice to clean them up so that the code is easier to read. Please review this simple code clean up. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge > - 8291949: Unexpected extending of SupportedGroups Nice cleanup! ------------- Marked as reviewed by djelinski (Committer). PR: https://git.openjdk.org/jdk/pull/9765 From mullan at openjdk.org Fri Aug 12 10:46:22 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Aug 2022 10:46:22 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v3] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Thu, 11 Aug 2022 10:37:27 GMT, Alan Bateman wrote: >> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: >> >> Incorporate review comments > > src/java.base/share/classes/java/security/Security.java line 52: > >> 50: * @implNote If this property file fails to load, the JDK implementation will >> 51: * throw an unspecified error when initializing the {@code Security} class. >> 52: * > > I think I'd probably use "the property file" rather than "this property file" here but otherwise the implNote looks okay to me. Change "property file" to "properties file". ------------- PR: https://git.openjdk.org/jdk/pull/9747 From mullan at openjdk.org Fri Aug 12 10:46:22 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Aug 2022 10:46:22 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v3] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Fri, 12 Aug 2022 10:31:17 GMT, Sean Mullan wrote: >> src/java.base/share/classes/java/security/Security.java line 52: >> >>> 50: * @implNote If this property file fails to load, the JDK implementation will >>> 51: * throw an unspecified error when initializing the {@code Security} class. >>> 52: * >> >> I think I'd probably use "the property file" rather than "this property file" here but otherwise the implNote looks okay to me. > > Change "property file" to "properties file". > I think I'd probably use "the property file" rather than "this property file" here but otherwise the implNote looks okay to me. Ok with me. ------------- PR: https://git.openjdk.org/jdk/pull/9747 From mullan at openjdk.org Fri Aug 12 10:46:24 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Aug 2022 10:46:24 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v3] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Thu, 11 Aug 2022 07:13:34 GMT, Sean Coffey wrote: >> In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. >> >> CSR in progress. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Incorporate review comments src/java.base/share/conf/security/java.security line 26: > 24: # by default. > 25: # > 26: # If this property file fails to load, the JDK implementation will throw Change "property file" to "properties file". ------------- PR: https://git.openjdk.org/jdk/pull/9747 From coffeys at openjdk.org Fri Aug 12 11:38:34 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 12 Aug 2022 11:38:34 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v4] In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Update comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9747/files - new: https://git.openjdk.org/jdk/pull/9747/files/0ae24472..a8cd24d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9747&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9747.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9747/head:pull/9747 PR: https://git.openjdk.org/jdk/pull/9747 From mullan at openjdk.org Fri Aug 12 12:20:20 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 12 Aug 2022 12:20:20 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v4] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: On Fri, 12 Aug 2022 11:38:34 GMT, Sean Coffey wrote: >> In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. >> >> CSR in progress. > > Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: > > Update comments Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9747 From kdriver at openjdk.org Fri Aug 12 17:53:15 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 17:53:15 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified Message-ID: add @exception message to indicate an NPE might be thrown when the input parameter is null ------------- Commit messages: - https://bugs.openjdk.org/browse/JDK-6205692 : add @exception message to indicate an NPE might be thrown when the input parameter is null Changes: https://git.openjdk.org/jdk/pull/9859/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6205692 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From lancea at openjdk.org Fri Aug 12 18:05:13 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 12 Aug 2022 18:05:13 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: References: Message-ID: <1yIwOP1g37oAlK3mmK0DvC5pvsy7yYWQZ19rzX1Wh9U=.d389268b-a248-41dd-8fc3-50523d0099bc@github.com> On Fri, 12 Aug 2022 17:41:16 GMT, Kevin Driver wrote: > add @exception message to indicate an NPE might be thrown when the input parameter is null This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Fri Aug 12 18:27:53 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 18:27:53 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for Message-ID: Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods ------------- Commit messages: - Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods Changes: https://git.openjdk.org/jdk/pull/9860/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9860&range=00 Issue: https://bugs.openjdk.org/browse/JDK-4958071 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9860.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9860/head:pull/9860 PR: https://git.openjdk.org/jdk/pull/9860 From kdriver at openjdk.org Fri Aug 12 18:28:26 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 18:28:26 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: <1yIwOP1g37oAlK3mmK0DvC5pvsy7yYWQZ19rzX1Wh9U=.d389268b-a248-41dd-8fc3-50523d0099bc@github.com> References: <1yIwOP1g37oAlK3mmK0DvC5pvsy7yYWQZ19rzX1Wh9U=.d389268b-a248-41dd-8fc3-50523d0099bc@github.com> Message-ID: On Fri, 12 Aug 2022 18:03:08 GMT, Lance Andersen wrote: > This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update @LanceAndersen I can add a test, if needed; however this is only a javadoc update and no new code is introduced. In other words, we could add a test to demonstrate existing behavior, but a test would not help with verifying this change. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Fri Aug 12 18:51:16 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Aug 2022 18:51:16 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 17:41:16 GMT, Kevin Driver wrote: > add @exception message to indicate an NPE might be thrown when the input parameter is null src/java.base/share/classes/javax/crypto/MacSpi.java line 105: > 103: * @param input the ByteBuffer > 104: * > 105: * @exception NullPointerException if {@code input} is null nit: I recall @throws is preferred. How about the update(...) methods in javax.crypto.Mac class? Perhaps the NPE there should be documented as well? ------------- PR: https://git.openjdk.org/jdk/pull/9859 From lancea at openjdk.org Fri Aug 12 18:55:33 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 12 Aug 2022 18:55:33 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: References: <1yIwOP1g37oAlK3mmK0DvC5pvsy7yYWQZ19rzX1Wh9U=.d389268b-a248-41dd-8fc3-50523d0099bc@github.com> Message-ID: <7uTtupe-8SXW1yYFI1kGFHC6ivslESK13ZYlC8UVL-k=.7f1f8a4c-ea29-43b0-83cf-13dd73f83a90@github.com> On Fri, 12 Aug 2022 18:20:21 GMT, Kevin Driver wrote: > > This looks OK. I did a quick scan and did not see a test in open/test which covers this and it probably would be worth considering adding one as part of this update > > @LanceAndersen I can add a test, if needed; however this is only a javadoc update and no new code is introduced. In other words, we could add a test to demonstrate existing behavior, but a test would not help with verifying this change. Understand it is just updating the spec/javadoc. It would be good for coverage going forward. At a minimum, the JCK should add a test. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Fri Aug 12 19:11:19 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 19:11:19 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: References: Message-ID: <9yo79oeFdnY_AgP2CcM0Dd6Gn_Hr0asytDDIk29D9k8=.0914534c-21c4-4463-bd8a-8fae871818cf@github.com> On Fri, 12 Aug 2022 18:47:21 GMT, Valerie Peng wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > src/java.base/share/classes/javax/crypto/MacSpi.java line 105: > >> 103: * @param input the ByteBuffer >> 104: * >> 105: * @exception NullPointerException if {@code input} is null > > nit: I recall @throws is preferred. > > How about the update(...) methods in javax.crypto.Mac class? Perhaps the NPE there should be documented as well? @valeriepeng I totally agree about `@throws`. I was just going for consistency within the file. There are other `@exception` appearances. Yes, I do agree about the `update(ByteBuffer)` in Mac as well; however this one throws `IllegalArgumentException` if the parameter is null. Or were you referring to another version of the `update` method? ------------- PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Fri Aug 12 19:20:52 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 19:20:52 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v2] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/1fd2ef49..0bc0394e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Fri Aug 12 19:20:52 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 19:20:52 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 18:47:21 GMT, Valerie Peng wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> review comment > > src/java.base/share/classes/javax/crypto/MacSpi.java line 105: > >> 103: * @param input the ByteBuffer >> 104: * >> 105: * @exception NullPointerException if {@code input} is null > > nit: I recall @throws is preferred. > > How about the update(...) methods in javax.crypto.Mac class? Perhaps the NPE there should be documented as well? @valeriepeng see https://github.com/openjdk/jdk/pull/9859/commits/0bc0394e7a72f40b1f8f7cd4056b5906d4b89eda for the proposed change. Let me know what you think about consistency within the files wrt `@throws` vs `@exception`. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Fri Aug 12 19:27:17 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Aug 2022 19:27:17 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v2] In-Reply-To: References: Message-ID: <93dZCXTrHXTWsblnklNosV-a5xPQJ9RB-LLU2UFVwJ4=.4f71d4d7-ff57-43a5-afa2-1445e8502904@github.com> On Fri, 12 Aug 2022 19:14:34 GMT, Kevin Driver wrote: >> src/java.base/share/classes/javax/crypto/MacSpi.java line 105: >> >>> 103: * @param input the ByteBuffer >>> 104: * >>> 105: * @exception NullPointerException if {@code input} is null >> >> nit: I recall @throws is preferred. >> >> How about the update(...) methods in javax.crypto.Mac class? Perhaps the NPE there should be documented as well? > > @valeriepeng see https://github.com/openjdk/jdk/pull/9859/commits/0bc0394e7a72f40b1f8f7cd4056b5906d4b89eda for the proposed change. > > Let me know what you think about consistency within the files wrt `@throws` vs `@exception`. For this particular case, I would go for @throws. Moving toward the newer notation seems better. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Fri Aug 12 19:33:12 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Aug 2022 19:33:12 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v2] In-Reply-To: <93dZCXTrHXTWsblnklNosV-a5xPQJ9RB-LLU2UFVwJ4=.4f71d4d7-ff57-43a5-afa2-1445e8502904@github.com> References: <93dZCXTrHXTWsblnklNosV-a5xPQJ9RB-LLU2UFVwJ4=.4f71d4d7-ff57-43a5-afa2-1445e8502904@github.com> Message-ID: On Fri, 12 Aug 2022 19:25:04 GMT, Valerie Peng wrote: >> @valeriepeng see https://github.com/openjdk/jdk/pull/9859/commits/0bc0394e7a72f40b1f8f7cd4056b5906d4b89eda for the proposed change. >> >> Let me know what you think about consistency within the files wrt `@throws` vs `@exception`. > > For this particular case, I would go for @throws. Moving toward the newer notation seems better. > @valeriepeng I totally agree about `@throws`. I was just going for consistency within the file. There are other `@exception` appearances. > > Yes, I do agree about the `update(ByteBuffer)` in Mac as well; however this one throws `IllegalArgumentException` if the parameter is null. Or were you referring to another version of the `update` method? Right, I should have not stated NPE, but rather the IAE caused by null argument. For completeness sake, perhaps we can cover NPE for Mac.update(byte[]) also? Since we are filing CSR already. It'd be great if this fix covers both Mac and MacSpi regarding null argument of the update(...)/engineUpdate(..) methods. Or, if that's a bit much, then we should strive to cover Mac.update(ByteBuffer)/MacSpi.engineUpdate(ByteBuffer) methods for completeness sake. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Fri Aug 12 19:42:34 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 12 Aug 2022 19:42:34 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v3] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: changed to uses @throws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/0bc0394e..05f54f80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From lancea at openjdk.org Fri Aug 12 19:49:13 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 12 Aug 2022 19:49:13 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v3] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 19:42:34 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > changed to uses @throws Perhaps consider converting the remaining `@exceptions` to `@throws` as part of this update ------------- PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Fri Aug 12 19:59:16 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Aug 2022 19:59:16 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v3] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 19:42:34 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > changed to uses @throws Looks good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Fri Aug 12 21:27:11 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 12 Aug 2022 21:27:11 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 18:15:53 GMT, Kevin Driver wrote: > Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods Looks good. Thanks. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.org/jdk/pull/9860 From wetmore at openjdk.org Fri Aug 12 22:52:13 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Aug 2022 22:52:13 GMT Subject: RFR: 8291949: Unexpected extending of SupportedGroups [v2] In-Reply-To: <0WBGynp6vbcoCGa0SsODPQ-uPJcawHOOtI91mLLjVMU=.b7b1db84-aebe-4c33-9d6e-1e2e1d698243@github.com> References: <0WBGynp6vbcoCGa0SsODPQ-uPJcawHOOtI91mLLjVMU=.b7b1db84-aebe-4c33-9d6e-1e2e1d698243@github.com> Message-ID: On Tue, 9 Aug 2022 15:32:24 GMT, Xue-Lei Andrew Fan wrote: >> In the SunJSSE implementation, there are a few unexpected extending of static class SupportedGroups. It may be nice to clean them up so that the code is easier to read. Please review this simple code clean up. > > Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge > - 8291949: Unexpected extending of SupportedGroups LGTM. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9765 From wetmore at openjdk.org Fri Aug 12 22:58:28 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Aug 2022 22:58:28 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v3] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 19:42:34 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > changed to uses @throws What's currently here is ok, but I concur about the suggestions for adding test(s), and changing @exception to @throws in both Mac and MacSpi. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9859 From wetmore at openjdk.org Fri Aug 12 23:07:12 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Fri, 12 Aug 2022 23:07:12 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 18:15:53 GMT, Kevin Driver wrote: > Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods LGTM, but needs test cases. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9860 From duke at openjdk.org Sat Aug 13 00:23:16 2022 From: duke at openjdk.org (duke) Date: Sat, 13 Aug 2022 00:23:16 GMT Subject: Withdrawn: JDK-8288475: Initializing RandomGeneratorFactory.FactoryMapHolder fails if a SecurityManager is installed In-Reply-To: References: Message-ID: <53Dnge1Le-058leML_e2fyFDzIDV1dE_6yRcQJ3RXYk=.85fbb878-5f9b-4a40-a903-c337bb367bfd@github.com> On Thu, 16 Jun 2022 07:08:20 GMT, Johannes Kuhn wrote: > * This adds additional permissions to the jdk.random module (`RuntimePermission "accessClassInPackage.jdk.internal.util.random"`) > * The annotations of the provider classes are now parsed early. > This avoids putting the parts that can trigger the parsing into an `AccessController.doPrivileged()` block. > * If a `SecurityManager` is installed, `RandomGeneratorFactory.all()` will only return `RandomGenerator`s that are loaded by a system domain loader. > This avoids parsing annotations of user classes from a privileged context. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9180 From jwaters at openjdk.org Sun Aug 14 06:39:58 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Aug 2022 06:39:58 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v4] In-Reply-To: References: Message-ID: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Comment out EXIT_FAILURE redefinition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9678/files - new: https://git.openjdk.org/jdk/pull/9678/files/76e0a33d..55434243 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=02-03 Stats: 8200 lines in 328 files changed: 4166 ins; 2257 del; 1777 mod Patch: https://git.openjdk.org/jdk/pull/9678.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9678/head:pull/9678 PR: https://git.openjdk.org/jdk/pull/9678 From jwaters at openjdk.org Sun Aug 14 06:40:01 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 14 Aug 2022 06:40:01 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v3] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 05:45:03 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition Merged with latest, review pending ------------- PR: https://git.openjdk.org/jdk/pull/9678 From coffeys at openjdk.org Mon Aug 15 08:56:15 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 15 Aug 2022 08:56:15 GMT Subject: RFR: 8155246: Throw error if default java.security file is missing [v2] In-Reply-To: References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: <8isfAJVIK-Y6YCMdYGZQJW2-y85Ragw0mkNUQqiWHfY=.f00a0b38-e705-497f-bc0d-627a79711311@github.com> On Wed, 10 Aug 2022 16:10:02 GMT, Bernd wrote: >> I think if you just said "If this properties file ..." it would be sufficient, as the previous paragraph provided enough context as to what you are referring to. > > Btw the current code does not handlmissing or unreadable overwrite files very well. PropsLoaded will be true even when the replacing overwrite file could not be loaded (resulting in an empty list). @ecki -- Logged JDK-8292297 to track the issue you raised ------------- PR: https://git.openjdk.org/jdk/pull/9747 From coffeys at openjdk.org Mon Aug 15 09:11:18 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 15 Aug 2022 09:11:18 GMT Subject: Integrated: 8155246: Throw error if default java.security file is missing In-Reply-To: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> References: <_jNWNsTAzs3gc3crfEK8m2GFroB_YvcKuW17r2T46ZI=.a03726c8-3371-4455-a048-a715c81d1528@github.com> Message-ID: <12Ptg3hDIT2gOyxaQ_doh9shkRn2tRnL0ktmNABf8nM=.62d0e644-c9ca-4fd5-af6b-04d1b5c79014@github.com> On Thu, 4 Aug 2022 15:22:23 GMT, Sean Coffey wrote: > In the broken case where the conf/security/java.security configuration file doesn't exist, the JDK should throw an Error. > > CSR in progress. This pull request has now been integrated. Changeset: 9d7c13eb Author: Sean Coffey URL: https://git.openjdk.org/jdk/commit/9d7c13eb14c525485e7739fcfacd044aa3bbc12d Stats: 125 lines in 4 files changed: 107 ins; 17 del; 1 mod 8155246: Throw error if default java.security file is missing Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/9747 From weijun at openjdk.org Mon Aug 15 14:05:32 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Aug 2022 14:05:32 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v4] In-Reply-To: References: Message-ID: <6aHTZGYpZKHCyPeA7k4PPlaU3ot01kTAlPS2lTMMxo0=.3fd61bd4-b8fa-4242-ad51-ddc3ba698ed1@github.com> On Sun, 14 Aug 2022 06:39:58 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition Changes looks good to me. Can you also remove the unused `ExitProcess` call as well? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/9678 From jwaters at openjdk.org Mon Aug 15 14:13:15 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 14:13:15 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v4] In-Reply-To: References: Message-ID: On Sun, 14 Aug 2022 06:39:58 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition I did contemplate doing so, but I think it may have been commented out instead of being completely removed for a reason, do we really not need it anymore? ------------- PR: https://git.openjdk.org/jdk/pull/9678 From weijun at openjdk.org Mon Aug 15 15:06:19 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Aug 2022 15:06:19 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v4] In-Reply-To: References: Message-ID: On Sun, 14 Aug 2022 06:39:58 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition I don't think a library should call `ExitProcess` anyway. If you do want to keep it, I'd suggest modify that `EXIT_FAILURE` argument to -1, which is what the original author meant. Or, move the useless `#define EXIT_FAILURE -1` line there and also comment it out. This way we keep the history. ------------- PR: https://git.openjdk.org/jdk/pull/9678 From weijun at openjdk.org Mon Aug 15 16:02:14 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Aug 2022 16:02:14 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v5] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 17:34:59 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Added test case using {Unix,NT}LoginModule My own suggestion is that we dump the call stack info of the exception if an OPTIONAL login module fails to login and when debug is on. This is not a behavior change but in a test we can confirm it by grabbing the log output using `System.setErr(yourOwnByteArrayOutputStream)`. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From jwaters at openjdk.org Mon Aug 15 16:17:42 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 16:17:42 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v5] In-Reply-To: References: Message-ID: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into patch-2 - Move commented define next to commented out ExitProcess call - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Merge branch 'openjdk:master' into patch-2 - Comment out EXIT_FAILURE redefinition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9678/files - new: https://git.openjdk.org/jdk/pull/9678/files/55434243..ac7e7e55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9678&range=03-04 Stats: 1056 lines in 61 files changed: 678 ins; 307 del; 71 mod Patch: https://git.openjdk.org/jdk/pull/9678.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9678/head:pull/9678 PR: https://git.openjdk.org/jdk/pull/9678 From weijun at openjdk.org Mon Aug 15 16:20:05 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Aug 2022 16:20:05 GMT Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth [v5] In-Reply-To: References: Message-ID: <_HvMhjjpWhUeXobdnD_O6Cc9xZtvpxR2cwdZtLSfI5k=.bc336052-a050-402e-95cf-694ae1e8b0aa@github.com> On Mon, 15 Aug 2022 16:17:42 GMT, Julian Waters wrote: >> EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-2 > - Move commented define next to commented out ExitProcess call > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Merge branch 'openjdk:master' into patch-2 > - Comment out EXIT_FAILURE redefinition Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9678 From jwaters at openjdk.org Mon Aug 15 16:30:56 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 15 Aug 2022 16:30:56 GMT Subject: Integrated: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 17:23:05 GMT, Julian Waters wrote: > EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well. This pull request has now been integrated. Changeset: b00eedeb Author: Julian Waters Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/b00eedeb029445417f99e8aa4e8fca12e5c69155 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/9678 From xuelei at openjdk.org Mon Aug 15 17:04:40 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 15 Aug 2022 17:04:40 GMT Subject: Integrated: 8291949: Unexpected extending of SupportedGroups In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 05:23:15 GMT, Xue-Lei Andrew Fan wrote: > In the SunJSSE implementation, there are a few unexpected extending of static class SupportedGroups. It may be nice to clean them up so that the code is easier to read. Please review this simple code clean up. This pull request has now been integrated. Changeset: ea2c82e7 Author: Xue-Lei Andrew Fan URL: https://git.openjdk.org/jdk/commit/ea2c82e74f5580f396920f9e561cbec80c03f373 Stats: 5 lines in 2 files changed: 0 ins; 1 del; 4 mod 8291949: Unexpected extending of SupportedGroups Reviewed-by: djelinski, wetmore ------------- PR: https://git.openjdk.org/jdk/pull/9765 From duke at openjdk.org Tue Aug 16 07:24:31 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 07:24:31 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v5] In-Reply-To: References: Message-ID: On Mon, 15 Aug 2022 15:58:50 GMT, Weijun Wang wrote: > System.setErr Looks like call stack info of the exception is not produced for OPTIONAL login module when debug is on. Here : https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L877 we don't dump call stack for exception thrown when manually the credentials are supplied. So we don't get what we are expecting in out output stream. But when we use Unix/NT Login module which uses gid and uid to verify the login then already the test case dumps the stack trace: https://github.com/openjdk/jdk/pull/9159/files#diff-455563a58230c5d5d6e24f73ab094d4d7572dc2c2771e3db70feb53c7d9b3a18R78 ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 08:44:03 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 08:44:03 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v6] In-Reply-To: References: Message-ID: <_P4GVg-B0qCacsH44F5CTKCeCcoRUS3wKCCVXzDdMQA=.0fb1b396-fdf9-4405-9ccb-abf44c6f6dd8@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment for test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/a7997f05..704cfefd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=04-05 Stats: 16 lines in 1 file changed: 10 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 08:44:05 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 08:44:05 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v5] In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 17:34:59 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Added test case using {Unix,NT}LoginModule I have modified the test case to include `System.setErr` and `ByteArrayOutputStream` ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Tue Aug 16 12:36:33 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 12:36:33 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v6] In-Reply-To: <_P4GVg-B0qCacsH44F5CTKCeCcoRUS3wKCCVXzDdMQA=.0fb1b396-fdf9-4405-9ccb-abf44c6f6dd8@github.com> References: <_P4GVg-B0qCacsH44F5CTKCeCcoRUS3wKCCVXzDdMQA=.0fb1b396-fdf9-4405-9ccb-abf44c6f6dd8@github.com> Message-ID: On Tue, 16 Aug 2022 08:44:03 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment for test case Great, the test looks fine. Now, let's come back to the bug fix itself about failure reason of an optional LoginModule. In the "cross-platform" test case, only "[LoginContext]: login OPTIONAL failure" is shown in the debug output. It will nice to include the stack trace of the exception there. (the same exception we observed in the "windows" case). ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 13:49:34 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 13:49:34 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment for cross-platform in the test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/704cfefd..a4bf014f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Tue Aug 16 14:21:18 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 14:21:18 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 13:49:34 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment for cross-platform in the test case Why the new change? The bug is about an optional LoginModule failure not logged, and it only happens when there are multiple login modules and the overall login succeeds. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 14:31:16 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 14:31:16 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 14:17:43 GMT, Weijun Wang wrote: > Why the new change? The bug is about an optional LoginModule failure not logged, and it only happens when there are multiple login modules and the overall login succeeds. Hmm then I misunderstood your previous comment : >In the "cross-platform" test case, only "[LoginContext]: login OPTIONAL failure" is shown in the debug output. It will nice to include the stack trace of the exception there. (the same exception we observed in the "windows" case). To address above comment I have split the cross-platform piece of code in the test case. If the current change was not expected I think I didn't get it :( Could you please elaborate ? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Tue Aug 16 14:31:17 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 14:31:17 GMT Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5] In-Reply-To: References: <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com> <51WLxTGgTwzYNlUntlEwlE-vCkfBTDLste5FjSbRnCk=.a326e20c-6195-4040-ab4b-a573425d4fd9@github.com> Message-ID: On Sat, 23 Jul 2022 05:37:16 GMT, jquanC wrote: >> Looks good to me. Thanks! > >> Looks good to me. Thanks! > > Cheers and appreciation! And I have learned more from your guidance. @jquanC Please type`/integrate` if you want to get the fix included in OpenJDK. ------------- PR: https://git.openjdk.org/jdk/pull/9585 From weijun at openjdk.org Tue Aug 16 14:36:12 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 14:36:12 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 13:49:34 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment for cross-platform in the test case The original "cross-platform" case is exactly what this bug is about. The overall login succeeds but the reason of the optional login module failure is not logged in the debug output. You need to update the source code of `LoginContext.java` to print out the reason and then confirm it in the test by examining the content of `new String(byes)`. Until now, you still only have a test change in your commits. This is not a test-only bug. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 14:40:15 2022 From: duke at openjdk.org (jquanC) Date: Tue, 16 Aug 2022 14:40:15 GMT Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5] In-Reply-To: References: <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com> <51WLxTGgTwzYNlUntlEwlE-vCkfBTDLste5FjSbRnCk=.a326e20c-6195-4040-ab4b-a573425d4fd9@github.com> Message-ID: On Sat, 23 Jul 2022 05:37:16 GMT, jquanC wrote: >> Looks good to me. Thanks! > >> Looks good to me. Thanks! > > Cheers and appreciation! And I have learned more from your guidance. > @jquanC Please type`/integrate` if you want to get the fix included in OpenJDK. Thanks for your reminder! I just marked it, please check if it is correct. ------------- PR: https://git.openjdk.org/jdk/pull/9585 From duke at openjdk.org Tue Aug 16 14:42:17 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 14:42:17 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 14:32:46 GMT, Weijun Wang wrote: > The original "cross-platform" case is exactly what this bug is about. The overall login succeeds but the reason of the optional login module failure is not logged in the debug output. You need to update the source code of `LoginContext.java` to print out the reason and then confirm it in the test by examining the content of `new String(byes)`. > > Until now, you still only have a test change in your commits. This is not a test-only bug. Ok. But the change what I had for LoginContext.java in this commit was not appropriate : https://github.com/openjdk/jdk/pull/9159/commits/13a51a6d2e026225ec8ac9f1516c7f709c72ce08 right? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 14:49:25 2022 From: duke at openjdk.org (jquanC) Date: Tue, 16 Aug 2022 14:49:25 GMT Subject: Integrated: 8290775: Some doc errors in DerOutputStream.java In-Reply-To: References: Message-ID: On Thu, 21 Jul 2022 08:53:31 GMT, jquanC wrote: > There are some doc errors in sun.security.util.DerOutputStream, like the followings, > > > /** > * Private helper routine for writing DER encoded string values. > * @param s the string to write > * @param stringTag one of the DER string tags that indicate which > * encoding should be used to write the string out. > * @param enc the name of the encoder that should be used corresponding > * to the above tag. > */ > private void writeString(String s, byte stringTag, Charset charset) throws IOException > > The parameter is charset, but not enc. > > > /** > * Marshals a DER integer on the output stream. > * > * @param i the integer in bytes, equivalent to BigInteger::toByteArray. > */ > public void putInteger(byte[] buf) throws IOException { > > The parameter is buf, but not i. This pull request has now been integrated. Changeset: 3e122419 Author: jquanC Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/3e122419b2979235f57c0dd549ca63647ea73753 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8290775: Some doc errors in DerOutputStream.java Reviewed-by: xuelei ------------- PR: https://git.openjdk.org/jdk/pull/9585 From weijun at openjdk.org Tue Aug 16 14:52:19 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 14:52:19 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: On Tue, 16 Aug 2022 13:49:34 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment for cross-platform in the test case > Ok. But the change what I had for LoginContext.java in this commit was not appropriate : [13a51a6](https://github.com/openjdk/jdk/commit/13a51a6d2e026225ec8ac9f1516c7f709c72ce08) right? No. If you only put the reason inside an exception but the overall login succeeds, this exception is dismissed and will not show up anywhere. You just need to add an extra `le.printStackTrace()` call next to the existing "[LoginContext]: login OPTIONAL failure" output. Then no matter if the overall login succeeds or not you can always find it in the debug output. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 14:59:27 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 14:59:27 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: References: Message-ID: <-4GL2ePbdGAUi50VpdC8fD0S7Y0tuBWLTk63dySm8kQ=.36255b95-ec6d-4288-99b8-42d657c6d3e7@github.com> On Tue, 16 Aug 2022 14:50:11 GMT, Weijun Wang wrote: > > Ok. But the change what I had for LoginContext.java in this commit was not appropriate : [13a51a6](https://github.com/openjdk/jdk/commit/13a51a6d2e026225ec8ac9f1516c7f709c72ce08) right? > > No. If you only put the reason inside an exception but the overall login succeeds, this exception is dismissed and will not show up anywhere. > > You just need to add an extra `le.printStackTrace()` call next to the existing "[LoginContext]: login OPTIONAL failure" output. Then no matter if the overall login succeeds or not you can always find it in the debug output. That means in the source code here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L881 ? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Tue Aug 16 15:07:26 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 16 Aug 2022 15:07:26 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v7] In-Reply-To: <-4GL2ePbdGAUi50VpdC8fD0S7Y0tuBWLTk63dySm8kQ=.36255b95-ec6d-4288-99b8-42d657c6d3e7@github.com> References: <-4GL2ePbdGAUi50VpdC8fD0S7Y0tuBWLTk63dySm8kQ=.36255b95-ec6d-4288-99b8-42d657c6d3e7@github.com> Message-ID: On Tue, 16 Aug 2022 14:57:06 GMT, Jayashree Huttanagoudar wrote: > That means in the source code here: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/javax/security/auth/login/LoginContext.java#L881 ? Yes. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 16 15:44:32 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 16 Aug 2022 15:44:32 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v8] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment to revert back the previous changes in the test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/a4bf014f..0bcf670e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=06-07 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Wed Aug 17 11:55:34 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 17 Aug 2022 11:55:34 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v9] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment to add call stacktrace changes to OPTIONAL login module when debug is on ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/0bcf670e..94c5c8dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=07-08 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Wed Aug 17 12:26:04 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 17 Aug 2022 12:26:04 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode Message-ID: Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. ------------- Commit messages: - remove the whitespace - update wording and case of varialbe name - modify the error message for key exchange failure - refine the log message for tlsv1.3 - address the comment from code review - update the test to combine protocol version of tsl1.2 and tsl1.3 - improve the implementation to print server cipher suites - Merge branch 'display-server-side-enabled-cipher-suites-for-debug-mode' of https://github.com/weibxiao/jdk into display-server-side-enabled-cipher-suites-for-debug-mode - Merge branch 'openjdk:master' into display-server-side-enabled-cipher-suites-for-debug-mode - remove duplicat key exchange algorith - ... and 1 more: https://git.openjdk.org/jdk/compare/ce61eb6f...360b8ed6 Changes: https://git.openjdk.org/jdk/pull/9731/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9731&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8133816 Stats: 236 lines in 2 files changed: 224 ins; 7 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9731.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9731/head:pull/9731 PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Wed Aug 17 12:26:04 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 17 Aug 2022 12:26:04 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: <7Qixq--r_nSXQ-jXH9msn752Ua1biywl3Gf0HarQnRo=.5ef5ce8b-b817-4b6c-978f-b6512c4f0313@github.com> On Wed, 3 Aug 2022 15:40:54 GMT, Weibing Xiao wrote: > Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. The build and test for Oracle Mach5 were passed. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From coffeys at openjdk.org Wed Aug 17 12:26:07 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 17 Aug 2022 12:26:07 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 15:40:54 GMT, Weibing Xiao wrote: > Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 440: > 438: } > 439: > 440: if (sun.security.ssl.SSLLogger.isOn && sun.security.ssl.SSLLogger.isOn("ssl,handshake")) { avoid the FQ class name - for SSLLogger - no need. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 764: > 762: > 763: // no cipher suites in common > 764: printServerEnabledCipherSuites(shc, null, null); I'd suggest removing the debug flag checks from line 776 and wrapping each call of `printServerEnabledCipherSuites` with the debug flag check instead - it's more obvious to reader IMO. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 772: > 770: * When debugging enabled with the value of "ssl, handshake", print out enabled cipher suites on the server side > 771: */ > 772: private static void printServerEnabledCipherSuites(sun.security.ssl.ServerHandshakeContext shc, maybe use `printServerSocketConfig` might suit better for method name ? ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Wed Aug 17 12:26:08 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 17 Aug 2022 12:26:08 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Mon, 8 Aug 2022 15:59:29 GMT, Sean Coffey wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 440: > >> 438: } >> 439: >> 440: if (sun.security.ssl.SSLLogger.isOn && sun.security.ssl.SSLLogger.isOn("ssl,handshake")) { > > avoid the FQ class name - for SSLLogger - no need. Updated the code, see new commit. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 764: > >> 762: >> 763: // no cipher suites in common >> 764: printServerEnabledCipherSuites(shc, null, null); > > I'd suggest removing the debug flag checks from line 776 and wrapping each call of `printServerEnabledCipherSuites` with the debug flag check instead - it's more obvious to reader IMO. Updated the code, see new commit. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 772: > >> 770: * When debugging enabled with the value of "ssl, handshake", print out enabled cipher suites on the server side >> 771: */ >> 772: private static void printServerEnabledCipherSuites(sun.security.ssl.ServerHandshakeContext shc, > > maybe use `printServerSocketConfig` might suit better for method name ? Updated the code, see new commit. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Wed Aug 17 12:34:15 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 17 Aug 2022 12:34:15 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v10] In-Reply-To: References: Message-ID: <4G_V7ekHFKYLQsRfAxcPVTDwr8s8gD5TGDUT0LAl7s4=.c7269fdc-d5a1-43a3-97da-2f924bdc19d0@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address whitespace error by jcheck ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/94c5c8dc..c0f5aa35 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Wed Aug 17 12:50:37 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 17 Aug 2022 12:50:37 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v11] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address whitespace error by jcheck ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/c0f5aa35..00797408 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From xuelei at openjdk.org Wed Aug 17 14:40:41 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 17 Aug 2022 14:40:41 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Wed, 3 Aug 2022 15:40:54 GMT, Weibing Xiao wrote: > Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409: > 407: if (shc.sslConfig.preferLocalCipherSuites) { > 408: preferred = shc.activeCipherSuites; > 409: proposed = clientHello.cipherSuites; Instead of wrapping all information in one block, I may prefer to break down and place them in the close place where is happens. I may dump the debug log here for cipher suite preference and server activated cipher suites. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 416: > 414: > 415: List legacySuites = new LinkedList<>(); > 416: boolean CSFound = false; This variable may be not necessary if the debug log has been broken down into multiple place. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 420: > 418: if (!HandshakeContext.isNegotiable( > 419: proposed, shc.negotiatedProtocol, cs)) { > 420: continue; I may add a debug log that the cipher suite is not negotiable her for the protocol. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 438: > 436: > 437: if (ke == null) { > 438: continue; I may add a debug log here that the key exchange is not good for the cipher suite and protocol. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 447: > 445: continue; > 446: } > 447: I may not remove this blank line. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 449: > 447: SSLPossession[] hcds = ke.createPossessions(shc); > 448: if ((hcds == null) || (hcds.length == 0)) { > 449: continue; I may add a debug log here that the cipher suite is legacy. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 452: > 450: SSLLogger.fine("use cipher suite " + cs.name); > 451: } > 452: I may not remove this blank line. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 461: > 459: SSLKeyExchange ke = SSLKeyExchange.valueOf( > 460: cs.keyExchange, shc.negotiatedProtocol); > 461: I may not add this extra line. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 472: > 470: > 471: throw shc.conContext.fatal(Alert.HANDSHAKE_FAILURE, > 472: "no cipher suites in common"); As there are detailed negotiation debug log, I may just update this line from "no cipher suites in common" to "no cipher suites or key exchange algorithms in common" src/java.base/share/classes/sun/security/ssl/ServerHello.java line 757: > 755: if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { > 756: printServerSocketConfig(shc, null); > 757: } Similarly, I may break down the debug log closer to the actions. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Wed Aug 17 17:11:36 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 17 Aug 2022 17:11:36 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:25:40 GMT, Xue-Lei Andrew Fan wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409: > >> 407: if (shc.sslConfig.preferLocalCipherSuites) { >> 408: preferred = shc.activeCipherSuites; >> 409: proposed = clientHello.cipherSuites; > > Instead of wrapping all information in one block, I may prefer to break down and place them in the close place where is happens. > > I may dump the debug log here for cipher suite preference and server activated cipher suites. The intention to group all the information together allows the developer to find the configuration of the server socket in one place. Previously the log message will only print out the error message of "on cipher suite in common" when the handshake failed between the client and server. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From weijun at openjdk.org Wed Aug 17 17:36:28 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 17 Aug 2022 17:36:28 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v11] In-Reply-To: References: Message-ID: <8AdAJ45vIKs2C2BxPEmuQBiNLS5D-MLybEHGXk0AQ90=.a47c3f0d-17b1-4f99-a9c8-d721e829c399@github.com> On Wed, 17 Aug 2022 12:50:37 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address whitespace error by jcheck src/java.base/share/classes/javax/security/auth/login/LoginContext.java line 883: > 881: debug.println(methodName + " OPTIONAL failure"); > 882: > 883: le.printStackTrace(); This line should only be called when `debug != null`. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 85: > 83: byte[] byes = stream.toByteArray(); > 84: String s = new String(byes); > 85: System.out.printf("-- error -- %n%s%n", s); The test should ensure the stack trace is included in the debug output. Please check the content of `s`. Make sure this test succeeds after the code change and fails before it. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 11:08:29 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 11:08:29 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v12] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/00797408..36f5b44b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=10-11 Stats: 12 lines in 2 files changed: 3 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 11:21:52 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 11:21:52 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v13] In-Reply-To: References: Message-ID: <5k5cKSTzQjSyAFaEYSue0_w7VD7V2LzMO8h4kzHUKuQ=.c526de1a-268f-4d10-a8cd-9daff3ef6bce@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address errors by bot to the previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/36f5b44b..8610f437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=11-12 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 11:48:01 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 11:48:01 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v14] In-Reply-To: References: Message-ID: <9_kd5zPCj5nANVhxnW-Bq9WJJg0U0f1GqcEwjDVeKgc=.3f88cbdb-cd79-478c-9673-6077fb092e04@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into JDK-8215916 - Address errors by bot to the previous commit - Address review comment - Address whitespace error by jcheck - Address whitespace error by jcheck - Address review comment to add call stacktrace changes to OPTIONAL login module when debug is on - Address review comment to revert back the previous changes in the test case - Address review comment for cross-platform in the test case - Address review comment for test case - Added test case using {Unix,NT}LoginModule - ... and 4 more: https://git.openjdk.org/jdk/compare/f2773f64...93a22f7a ------------- Changes: https://git.openjdk.org/jdk/pull/9159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=13 Stats: 93 lines in 2 files changed: 91 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 13:20:18 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 13:20:18 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v11] In-Reply-To: <8AdAJ45vIKs2C2BxPEmuQBiNLS5D-MLybEHGXk0AQ90=.a47c3f0d-17b1-4f99-a9c8-d721e829c399@github.com> References: <8AdAJ45vIKs2C2BxPEmuQBiNLS5D-MLybEHGXk0AQ90=.a47c3f0d-17b1-4f99-a9c8-d721e829c399@github.com> Message-ID: On Wed, 17 Aug 2022 17:31:50 GMT, Weijun Wang wrote: > The test should ensure the stack trace is included in the debug output. Please check the content of `s`. Make sure this test succeeds after the code change and fails before it. I have made an attempt to include what you suggested. I didn't get how will this test case fails without my fix. In other words this test case seems to pass overall with or without fix. The difference is with my fix the stack trace is printed and without the fix stack trace is not printed. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Thu Aug 18 13:31:23 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Aug 2022 13:31:23 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v14] In-Reply-To: <9_kd5zPCj5nANVhxnW-Bq9WJJg0U0f1GqcEwjDVeKgc=.3f88cbdb-cd79-478c-9673-6077fb092e04@github.com> References: <9_kd5zPCj5nANVhxnW-Bq9WJJg0U0f1GqcEwjDVeKgc=.3f88cbdb-cd79-478c-9673-6077fb092e04@github.com> Message-ID: <9MaQ6j3tFae94gbOUG_kBedfeHEPsNXKwtb-_i6QysE=.aafad2b1-9159-4ff9-8d21-168316458fde@github.com> On Thu, 18 Aug 2022 11:48:01 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into JDK-8215916 > - Address errors by bot to the previous commit > - Address review comment > - Address whitespace error by jcheck > - Address whitespace error by jcheck > - Address review comment to add call stacktrace changes to OPTIONAL login module when debug is on > - Address review comment to revert back the previous changes in the test case > - Address review comment for cross-platform in the test case > - Address review comment for test case > - Added test case using {Unix,NT}LoginModule > - ... and 4 more: https://git.openjdk.org/jdk/compare/f2773f64...93a22f7a test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 87: > 85: if (s.contains("Failed in attempt to import the underlying")) { > 86: System.out.printf("-- call stack is -- %n%s%n", s); > 87: } To make this a test, it should fail when the string is not found. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 13:47:58 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 18 Aug 2022 13:47:58 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:25:40 GMT, Xue-Lei Andrew Fan wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409: > >> 407: if (shc.sslConfig.preferLocalCipherSuites) { >> 408: preferred = shc.activeCipherSuites; >> 409: proposed = clientHello.cipherSuites; > > Instead of wrapping all information in one block, I may prefer to break down and place them in the close place where is happens. > > I may dump the debug log here for cipher suite preference and server activated cipher suites. Intend to log all of the collected information in one place. It is easy for the developer to see the configuration of the server socket. Previously when the handshake is failing, no information is available for the server socket in the log file. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From weijun at openjdk.org Thu Aug 18 13:48:25 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Aug 2022 13:48:25 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v14] In-Reply-To: <9_kd5zPCj5nANVhxnW-Bq9WJJg0U0f1GqcEwjDVeKgc=.3f88cbdb-cd79-478c-9673-6077fb092e04@github.com> References: <9_kd5zPCj5nANVhxnW-Bq9WJJg0U0f1GqcEwjDVeKgc=.3f88cbdb-cd79-478c-9673-6077fb092e04@github.com> Message-ID: On Thu, 18 Aug 2022 11:48:01 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into JDK-8215916 > - Address errors by bot to the previous commit > - Address review comment > - Address whitespace error by jcheck > - Address whitespace error by jcheck > - Address review comment to add call stacktrace changes to OPTIONAL login module when debug is on > - Address review comment to revert back the previous changes in the test case > - Address review comment for cross-platform in the test case > - Address review comment for test case > - Added test case using {Unix,NT}LoginModule > - ... and 4 more: https://git.openjdk.org/jdk/compare/f2773f64...93a22f7a src change looks fine. See my other reply on test. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Thu Aug 18 13:48:27 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Aug 2022 13:48:27 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v11] In-Reply-To: References: <8AdAJ45vIKs2C2BxPEmuQBiNLS5D-MLybEHGXk0AQ90=.a47c3f0d-17b1-4f99-a9c8-d721e829c399@github.com> Message-ID: On Thu, 18 Aug 2022 13:18:15 GMT, Jayashree Huttanagoudar wrote: >> test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 85: >> >>> 83: byte[] byes = stream.toByteArray(); >>> 84: String s = new String(byes); >>> 85: System.out.printf("-- error -- %n%s%n", s); >> >> The test should ensure the stack trace is included in the debug output. Please check the content of `s`. Make sure this test succeeds after the code change and fails before it. > >> The test should ensure the stack trace is included in the debug output. Please check the content of `s`. Make sure this test succeeds after the code change and fails before it. > > I have made an attempt to include what you suggested. I didn't get how will this test case fails without my fix. In other words this test case seems to pass overall with or without fix. The difference is with my fix the stack trace is printed and without the fix stack trace is not printed. You can just call `if (!s.contains("Failed in attempt")) throw new RuntimeException()`. The substring should always be there in the "cross-platform" case. Maybe you can drop the other 2 cases since they are not related to this bug. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 13:52:17 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 18 Aug 2022 13:52:17 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:27:15 GMT, Xue-Lei Andrew Fan wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 416: > >> 414: >> 415: List legacySuites = new LinkedList<>(); >> 416: boolean CSFound = false; > > This variable may be not necessary if the debug log has been broken down into multiple place. There are two failing scenarios, one is "no common cipher suite" between the client and server and the other is the failure of key exchange after the server finds the shared cipher suites with the client. We are using the flag to give the developer a more specific error message. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Thu Aug 18 14:05:38 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 18 Aug 2022 14:05:38 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: > Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: add or remove the blank line according to the comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9731/files - new: https://git.openjdk.org/jdk/pull/9731/files/360b8ed6..68a12183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9731&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9731&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9731.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9731/head:pull/9731 PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Thu Aug 18 14:05:41 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 18 Aug 2022 14:05:41 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: On Wed, 17 Aug 2022 14:27:56 GMT, Xue-Lei Andrew Fan wrote: >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> add or remove the blank line according to the comments > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 420: > >> 418: if (!HandshakeContext.isNegotiable( >> 419: proposed, shc.negotiatedProtocol, cs)) { >> 420: continue; > > I may add a debug log that the cipher suite is not negotiable her for the protocol. If there is no common cipher suite between the client and server. All of the server cipher suites will be printed out. The error message of "no common cipher suites" will be logged. If any cipher suites are shared between the client and server, the rest of the cipher suites would not be used. For this case, the error message of "key exchange failed" will be logged. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 438: > >> 436: >> 437: if (ke == null) { >> 438: continue; > > I may add a debug log here that the key exchange is not good for the cipher suite and protocol. As mentioned in my previous reply, if handshaking failed, all of the cipher suites will be logged. Technically key name is included in cipher suite name. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 447: > >> 445: } >> 446: >> 447: SSLPossession[] hcds = ke.createPossessions(shc); > > I may not remove this blank line. Updated accordingly > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 449: > >> 447: SSLPossession[] hcds = ke.createPossessions(shc); >> 448: if ((hcds == null) || (hcds.length == 0)) { >> 449: continue; > > I may add a debug log here that the cipher suite is legacy. It is logged in the new method. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 452: > >> 450: } >> 451: // The cipher suite has been negotiated. >> 452: if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { > > I may not remove this blank line. Updated accordingly > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 461: > >> 459: SSLKeyExchange ke = SSLKeyExchange.valueOf( >> 460: cs.keyExchange, shc.negotiatedProtocol); >> 461: > > I may not add this extra line. Updated accordingly > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 472: > >> 470: >> 471: throw shc.conContext.fatal(Alert.HANDSHAKE_FAILURE, >> 472: "no cipher suites in common"); > > As there are detailed negotiation debug log, I may just update this line from "no cipher suites in common" to "no cipher suites or key exchange algorithms in common" See my previous reply. > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 757: > >> 755: if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) { >> 756: printServerSocketConfig(shc, null); >> 757: } > > Similarly, I may break down the debug log closer to the actions. See my previous reply. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From xuelei at openjdk.org Thu Aug 18 15:44:21 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 Aug 2022 15:44:21 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 13:44:49 GMT, Weibing Xiao wrote: >> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409: >> >>> 407: if (shc.sslConfig.preferLocalCipherSuites) { >>> 408: preferred = shc.activeCipherSuites; >>> 409: proposed = clientHello.cipherSuites; >> >> Instead of wrapping all information in one block, I may prefer to break down and place them in the close place where is happens. >> >> I may dump the debug log here for cipher suite preference and server activated cipher suites. > > Intend to log all of the collected information in one place. It is easy for the developer to see the configuration of the server socket. Previously when the handshake is failing, no information is available for the server socket in the log file. So, do you want to make the log where the configuration happens? Logging in one place cannot have the accuracy debug log where the problem happens, and cannot easy the analysis of the debug. One just gets the configuration information, but did not get the code line numbers and processes why the information is not good. We can have all log in one place for the TLS implementation, and tell the log reader to analysis the configuration by himself, but the style was not chosen because more debug information was expected to carry in the log. >> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 416: >> >>> 414: >>> 415: List legacySuites = new LinkedList<>(); >>> 416: boolean CSFound = false; >> >> This variable may be not necessary if the debug log has been broken down into multiple place. > > There are two failing scenarios, one is "no common cipher suite" between the client and server and the other is the failure of key exchange after the server finds the shared cipher suites with the client. We are using the flag to give the developer a more specific error message. I see, but could you make it without define a variable that is purely for debug? ------------- PR: https://git.openjdk.org/jdk/pull/9731 From xuelei at openjdk.org Thu Aug 18 15:49:15 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 18 Aug 2022 15:49:15 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 13:56:38 GMT, Weibing Xiao wrote: >> src/java.base/share/classes/sun/security/ssl/ServerHello.java line 438: >> >>> 436: >>> 437: if (ke == null) { >>> 438: continue; >> >> I may add a debug log here that the key exchange is not good for the cipher suite and protocol. > > As mentioned in my previous reply, if handshaking failed, all of the cipher suites will be logged. Technically key name is included in cipher suite name. Hm, all cipher suites are logged, please analysis the failure by yourself. Is it really the purpose of debug log and what you want to do? ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Thu Aug 18 19:13:33 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 19:13:33 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/93a22f7a..70563d7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=13-14 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Thu Aug 18 19:21:27 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Thu, 18 Aug 2022 19:21:27 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:13:33 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Now the test case failed without patch and passed with patch. Thank you :) for suggesting the change for test case. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Thu Aug 18 22:40:14 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Aug 2022 22:40:14 GMT Subject: Integrated: 6587699: Document DigestInputStream behavior when skip() or mark() / reset() is used In-Reply-To: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com> References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com> Message-ID: On Wed, 27 Jul 2022 23:02:03 GMT, Weijun Wang wrote: > Add an `@implNote` to clarify the behavior when these methods are called. A new test is added. This pull request has now been integrated. Changeset: 54ce1143 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/54ce11431d194c23d3b674bcc54be1acf94e7f89 Stats: 76 lines in 2 files changed: 76 ins; 0 del; 0 mod 6587699: Document DigestInputStream behavior when skip() or mark() / reset() is used Reviewed-by: wetmore ------------- PR: https://git.openjdk.org/jdk/pull/9667 From weijun at openjdk.org Thu Aug 18 22:42:43 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 18 Aug 2022 22:42:43 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:13:33 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Great. Two comments to the test: 1. Since there is only one case now, maybe you can write out the JAAS config file as a literal string. You can use the new multi-line string feature. 2. If the test fails, will the exception show up? I'm asking because you haven't restored the original `System.err` and I wonder if the exception stack trace is still in the byte array output stream. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Fri Aug 19 09:01:39 2022 From: duke at openjdk.org (Josef Eisl) Date: Fri, 19 Aug 2022 09:01:39 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v6] In-Reply-To: References: Message-ID: On Wed, 8 Dec 2021 00:18:44 GMT, Valerie Peng wrote: >> It is observed that when running crypto benchmark with large number of threads, a lot of time is spent on the synchronized block inside the Provider.getService() method. The cause for this is that Provider.getService() method first uses the 'serviceMap' field to find the requested service. However, when the requested service is not supported by this provider, e.g. requesting Cipher.RSA from SUN provider, the impl continues to try searching the legacy registrations whose processing is guarded by the "synchronized" keyword. When apps use getInstance() calls without the provider argument, Provider class has to iterate through existing providers trying to find one that supports the requested service. >> >> Now that the parent class of Provider no longer synchronizes all of its methods, Provider class should follow suit and de-synchronize its methods. Parsing of the legacy registration is done eagerly (at the time of put(...) calls) instead of lazily (at the time of getService(...) calls). This also makes "legacyStrings" redundant as the registration is parsed and stored directly into "legacyMap". >> >> The bug reporter has confirmed that the changes resolve the performance bottleneck and all regression tests pass. >> >> Please review and thanks in advance, >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to address review comments. src/java.base/share/classes/java/security/Provider.java line 1276: > 1274: } > 1275: if (serviceSet == null) { > 1276: ensureLegacyParsed(); Hi @valeriepeng! I believe that with this change, `getServices()` will return invalid legacy services. Before we called `ensureLegacyParsed()`, which eventually called `removeInvalidServices()`. In `getService(String, String)`, we are now explicitly checking for `isValid()` to keep the old behavior. Shouldn't we do something similar here as well? Am I missing something or is this an intended change? ------------- PR: https://git.openjdk.org/jdk/pull/6513 From duke at openjdk.org Fri Aug 19 09:49:32 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Fri, 19 Aug 2022 09:49:32 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:13:33 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments > 3. java.nio.file.Path.of I will try to include your suggestions. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Fri Aug 19 15:21:25 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 15:21:25 GMT Subject: RFR: 8292676: Remove two kerberos tests from problem list Message-ID: The two tests are no longer manual and should be removed from the problem list. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/9943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292676 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9943.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9943/head:pull/9943 PR: https://git.openjdk.org/jdk/pull/9943 From mpowers at openjdk.org Fri Aug 19 16:10:36 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 19 Aug 2022 16:10:36 GMT Subject: RFR: 8292676: Remove two kerberos tests from problem list In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 15:13:34 GMT, Weijun Wang wrote: > The two tests are no longer manual and should be removed from the problem list. Looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/9943 From xuelei at openjdk.org Fri Aug 19 16:53:41 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 19 Aug 2022 16:53:41 GMT Subject: RFR: 8292676: Remove two kerberos tests from problem list In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 15:13:34 GMT, Weijun Wang wrote: > The two tests are no longer manual and should be removed from the problem list. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9943 From John.Gray at entrust.com Thu Aug 18 20:37:44 2022 From: John.Gray at entrust.com (John Gray) Date: Thu, 18 Aug 2022 20:37:44 +0000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? Message-ID: We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. ss, ct := encapsulate(PublicKey) ss := decapsulate(PrivateKey, ct) -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) -ct is a Cipher Text (a byte array would make sense) -Public and Private Keys would use the regular public and private key interface. -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). Then algorithms could be registered in providers as usual: put("KEM.Kyber","com.blah.Kyber") put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... Cheers, John Gray Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. From dgh at cryptoworkshop.com Thu Aug 18 23:04:57 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Fri, 19 Aug 2022 09:04:57 +1000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: Message-ID: <898d0628-6c8a-db21-7c99-728f81fde0af@cryptoworkshop.com> I'd like to just add a supporting comment on this by showing what we've currently done. At the moment KEM usage in the JCA is provided in the BC API by doing the following: // key pair generation ??????? KeyPairGenerator kpg = KeyPairGenerator.getInstance("Kyber", "BCPQC"); ??????? kpg.initialize(KyberParameterSpec.kyber1024, new SecureRandom()); ??????? KeyPair kp = kpg.generateKeyPair(); //kem usage ??????? KeyGenerator keyGen = KeyGenerator.getInstance("Kyber", "BCPQC"); //encapsulation step ??????? keyGen.init(new KEMGenerateSpec(kp.getPublic(), "AES"), new SecureRandom()); ??????? SecretKeyWithEncapsulation secEnc1 = (SecretKeyWithEncapsulation)keyGen.generateKey(); //decapsulation step ??????? keyGen.init(new KEMExtractSpec(kp.getPrivate(), secEnc1.getEncapsulation(), "AES")); ??????? SecretKeyWithEncapsulation secEnc2 = (SecretKeyWithEncapsulation)keyGen.generateKey(); The above code will return an extension to SecretKey that has a getEncapsulation() method on it for "AES", with SecretKey.getEncoded() returning the actual shared secret. The result can either be used directly or getEncoded() might be called to provide a T value for a hybrid key agreement using ECCDH and then the destroy() method invoked. In the decapsulation step just SecretKey as a return would have been enough, but it just looked downright weird given how we were trying to do it and it seemed less confusing for developers if both ends produced the same result. While this does mean we've got it to "fit" (it's basically the same pattern we used for the RSA-KEM in BCFIPS), it's clearly not portable and it does feel like we've stretched the API a bit much - the other init() methods now have to throw UnsupportedOperationException which does suggest this isn't really what the class is for. Some people have also shoehorned KEMs into KeyAgreement instead which, while it can be made to work, does also involve ignoring how the class is used normally and doing things like faking a public key. That it is even possible to do this multiple ways in the existing API, with neither working cleanly, does suggest that KEMs are a bit different from what we've seen before. All that said, we are probably about 2 years out from when the first standards for these algorithms will appear and in some cases use of these algorithms will become mandatory. Now would be a really good time to have a universal solution that all of us can start supporting developed. Thanks, David On 19/8/22 06:37, John Gray wrote: > We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: > See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). > > I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. > > ss, ct := encapsulate(PublicKey) > ss := decapsulate(PrivateKey, ct) > > -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) > -ct is a Cipher Text (a byte array would make sense) > -Public and Private Keys would use the regular public and private key interface. > -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. > > Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). > > Then algorithms could be registered in providers as usual: > > put("KEM.Kyber","com.blah.Kyber") > put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") > > Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... > > Cheers, > > John Gray > > > > Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. From ecaspole at openjdk.org Fri Aug 19 19:23:33 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Fri, 19 Aug 2022 19:23:33 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain Message-ID: Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. ------------- Commit messages: - 8292681: Add JMH for ProtectionDomain Changes: https://git.openjdk.org/jdk/pull/9950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292681 Stats: 129 lines in 2 files changed: 128 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9950.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9950/head:pull/9950 PR: https://git.openjdk.org/jdk/pull/9950 From weijun at openjdk.org Fri Aug 19 19:24:45 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 19:24:45 GMT Subject: RFR: 8292682: Code change of JDK-8282730 not updated to reflect CSR update Message-ID: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> The final version of the CSR at https://bugs.openjdk.org/browse/JDK-8290119 uses `@implNote` for the new text, but the code change was not updated before the integration. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/9949/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9949&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292682 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9949.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9949/head:pull/9949 PR: https://git.openjdk.org/jdk/pull/9949 From xuelei at openjdk.org Fri Aug 19 19:31:54 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 19 Aug 2022 19:31:54 GMT Subject: RFR: 8292682: Code change of JDK-8282730 not updated to reflect CSR update In-Reply-To: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> References: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> Message-ID: On Fri, 19 Aug 2022 18:47:40 GMT, Weijun Wang wrote: > The final version of the CSR at https://bugs.openjdk.org/browse/JDK-8290119 uses `@implNote` for the new text, but the code change was not updated before the integration. Per the CSR, this is a straightforward update to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.org/jdk/pull/9949 From weijun at openjdk.org Fri Aug 19 19:33:50 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 19:33:50 GMT Subject: RFR: 8292683: Remove BadKeyUsageTest.java from Problem List Message-ID: Sigh. I removed the test file itself long time ago but forgot to remove a line on it in the problem list. ------------- Commit messages: - the fix Changes: https://git.openjdk.org/jdk/pull/9951/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9951&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292683 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9951.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9951/head:pull/9951 PR: https://git.openjdk.org/jdk/pull/9951 From xuelei at openjdk.org Fri Aug 19 19:38:47 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 19 Aug 2022 19:38:47 GMT Subject: RFR: 8292683: Remove BadKeyUsageTest.java from Problem List In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 19:01:10 GMT, Weijun Wang wrote: > Sigh. I removed the test file itself long time ago but forgot to remove a line on it in the problem list. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9951 From hchao at openjdk.org Fri Aug 19 19:46:06 2022 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 19 Aug 2022 19:46:06 GMT Subject: RFR: 8292682: Code change of JDK-8282730 not updated to reflect CSR update In-Reply-To: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> References: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> Message-ID: On Fri, 19 Aug 2022 18:47:40 GMT, Weijun Wang wrote: > The final version of the CSR at https://bugs.openjdk.org/browse/JDK-8290119 uses `@implNote` for the new text, but the code change was not updated before the integration. Marked as reviewed by hchao (Committer). Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/9949 From hchao at openjdk.org Fri Aug 19 19:47:51 2022 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 19 Aug 2022 19:47:51 GMT Subject: RFR: 8292683: Remove BadKeyUsageTest.java from Problem List In-Reply-To: References: Message-ID: <_ODdzR0_fIO5z9V14Xme_IB8-UdGB0i9gNLFpMtZb98=.4eedae7d-3887-45d9-8bbd-8b5486314b0f@github.com> On Fri, 19 Aug 2022 19:01:10 GMT, Weijun Wang wrote: > Sigh. I removed the test file itself long time ago but forgot to remove a line on it in the problem list. Marked as reviewed by hchao (Committer). Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/9951 From hchao at openjdk.org Fri Aug 19 19:48:56 2022 From: hchao at openjdk.org (Hai-May Chao) Date: Fri, 19 Aug 2022 19:48:56 GMT Subject: RFR: 8292676: Remove two kerberos tests from problem list In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 15:13:34 GMT, Weijun Wang wrote: > The two tests are no longer manual and should be removed from the problem list. Marked as reviewed by hchao (Committer). Looks good. ------------- PR: https://git.openjdk.org/jdk/pull/9943 From weijun at openjdk.org Fri Aug 19 20:02:01 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 20:02:01 GMT Subject: Integrated: 8292682: Code change of JDK-8282730 not updated to reflect CSR update In-Reply-To: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> References: <1uw9umQ15jdwxbm7287yG-gxNG3YctBAUnBmg-xo-Ys=.50b3ad7b-c3ac-435f-9dff-d5affd227c99@github.com> Message-ID: <0ATtT5xzS_sgAPh1W6FSW0tESN9UQps5MFij9ifV7b8=.3e00905a-92bf-4f2a-a144-a495ead5ed7e@github.com> On Fri, 19 Aug 2022 18:47:40 GMT, Weijun Wang wrote: > The final version of the CSR at https://bugs.openjdk.org/browse/JDK-8290119 uses `@implNote` for the new text, but the code change was not updated before the integration. This pull request has now been integrated. Changeset: 74d3330e Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/74d3330e106f2f920bf264356e4f25f8f6c11580 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8292682: Code change of JDK-8282730 not updated to reflect CSR update Reviewed-by: xuelei, hchao ------------- PR: https://git.openjdk.org/jdk/pull/9949 From weijun at openjdk.org Fri Aug 19 20:02:22 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 20:02:22 GMT Subject: Integrated: 8292676: Remove two kerberos tests from problem list In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 15:13:34 GMT, Weijun Wang wrote: > The two tests are no longer manual and should be removed from the problem list. This pull request has now been integrated. Changeset: 235151ea Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/235151ead89f9102e3a57ba8f88807f180887866 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8292676: Remove two kerberos tests from problem list Reviewed-by: xuelei, hchao ------------- PR: https://git.openjdk.org/jdk/pull/9943 From weijun at openjdk.org Fri Aug 19 20:03:09 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 20:03:09 GMT Subject: Integrated: 8292683: Remove BadKeyUsageTest.java from Problem List In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 19:01:10 GMT, Weijun Wang wrote: > Sigh. I removed the test file itself long time ago but forgot to remove a line on it in the problem list. This pull request has now been integrated. Changeset: df5209e7 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/df5209e70fd92ec6bda4e7356a3ad121732f6c66 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8292683: Remove BadKeyUsageTest.java from Problem List Reviewed-by: xuelei, hchao ------------- PR: https://git.openjdk.org/jdk/pull/9951 From duke at openjdk.org Fri Aug 19 20:33:23 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Fri, 19 Aug 2022 20:33:23 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/70563d7c..eceebabe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=14-15 Stats: 12 lines in 1 file changed: 0 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Fri Aug 19 20:33:24 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Fri, 19 Aug 2022 20:33:24 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 19:13:33 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I have included your suggestions for the test case. Since we are using `PrintStream` the `flush` is automatically called itseems so I didn't see any exception trace in the .jtr file when the test case fails. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Fri Aug 19 21:46:00 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 21:46:00 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: <2BVsAl-9UxGtXxfSH-RCnBysHcfdy8VHTUknU0uj27c=.99dddec4-b17d-411b-9e04-fbe0bbd63339@github.com> On Fri, 19 Aug 2022 20:33:23 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Almost done. Some comments. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 2: > 1: /* > 2: * Copyright (c) 2014, 2022, Oracle and/or its affiliates. All rights reserved. Only "Copyright (c) 2022" is needed. Actually, you don't need to include "Oracle" here. See https://github.com/openjdk/jdk/blob/3e60e828148a0490a4422d0724d15f3eccec17f0/test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java for an example. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 50: > 48: } > 49: > 50: static void login(String test, String... conf) throws Exception { All arguments are useless now. You can simply remove this `login` method and merge the content into `main`. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 61: > 59: > 60: System.out.println("config is : \n"+config); > 61: Files.write(java.nio.file.Path.of(test), config.toString().getBytes()); Use `Files.writeString`. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 64: > 62: > 63: // Must be called. Configuration has an internal static field. > 64: Configuration.setConfiguration(null); Is this necessary since you run this test in othervm mode? test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 69: > 67: ByteArrayOutputStream stream = new ByteArrayOutputStream(); > 68: PrintStream ps = new PrintStream(stream); > 69: System.setErr(ps); Store `System.err` in a local variable so you can call `System.setErr(oldSystemErr)` in a `finally` clause of the `try` block at line 71 below.. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Fri Aug 19 21:46:00 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 21:46:00 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v15] In-Reply-To: References: Message-ID: <4YOTCc_si248QBpRV0wdZSZgO7A7HEmK-Xn4JaYJXHY=.813bdc1d-52e2-4249-949d-7a8d4886562a@github.com> On Fri, 19 Aug 2022 20:29:18 GMT, Jayashree Huttanagoudar wrote: > I have included your suggestions for the test case. > Since we are using `PrintStream` the `flush` is automatically called itseems so I didn't see any exception trace in the .jtr file when the test case fails. This is because exception stack trace is printed into `System.err` but you haven't restored the previous one -- which is the console output. See my comment in line. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From mstjohns at comcast.net Fri Aug 19 21:53:40 2022 From: mstjohns at comcast.net (Mike StJohns) Date: Fri, 19 Aug 2022 17:53:40 -0400 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: Message-ID: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. Mike Sent from my iPad > On Aug 19, 2022, at 12:56, John Gray wrote: > > ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: > See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). > > I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. > > ss, ct := encapsulate(PublicKey) > ss := decapsulate(PrivateKey, ct) > > -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) > -ct is a Cipher Text (a byte array would make sense) > -Public and Private Keys would use the regular public and private key interface. > -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. > > Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). > > Then algorithms could be registered in providers as usual: > > put("KEM.Kyber","com.blah.Kyber") > put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") > > Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... > > Cheers, > > John Gray > > > > Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. From weijun at openjdk.org Fri Aug 19 21:57:21 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 19 Aug 2022 21:57:21 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 20:33:23 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Some more comments. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 27: > 25: * @test > 26: * @bug 8215916 > 27: * @summary This Sample application attempts to authenticate a user Update the summary. test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 85: > 83: throw new RuntimeException(); > 84: } else { > 85: System.out.printf("-- call stack is -- %n%s%n", s); I'd rather print out the call stack if the test fails. Who would want to read the test output if it succeeds? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From valeriep at openjdk.org Fri Aug 19 23:34:44 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 19 Aug 2022 23:34:44 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v6] In-Reply-To: References: Message-ID: <46NjER7jae3jHXj2jDq_RM3RAf_GmgT7qX91yCn19Y4=.b8e393f0-0e25-4144-a997-d3b6da643d2b@github.com> On Fri, 19 Aug 2022 08:40:39 GMT, Josef Eisl wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated to address review comments. > > src/java.base/share/classes/java/security/Provider.java line 1276: > >> 1274: } >> 1275: if (serviceSet == null) { >> 1276: ensureLegacyParsed(); > > Hi @valeriepeng! I believe that with this change, `getServices()` will return invalid legacy services. Before we called `ensureLegacyParsed()`, which eventually called `removeInvalidServices()`. In `getService(String, String)`, we are now explicitly checking for `isValid()` to keep the old behavior. Shouldn't we do something similar here as well? Am I missing something or is this an intended change? Hmm, could be. Let me check into it and I will have to file a separate bug to address this since the changes have already been integrated. Thanks for the comments. ------------- PR: https://git.openjdk.org/jdk/pull/6513 From dgh at cryptoworkshop.com Fri Aug 19 22:38:03 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Sat, 20 Aug 2022 08:38:03 +1000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> Message-ID: Hi Mike, KEMs can be used for key wrapping - we've actually implemented support for this too. But they are not actually key wrapping ciphers. Here's a simple example of using Kyber for key wrapping in BC: SecretKey key =new SecretKeySpec(keyBytes,"AES"); w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); byte[]data =w1.wrap(key); Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the secret key separately. This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. Thanks, David On 20/8/22 07:53, Mike StJohns wrote: > Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. > > Mike > > Sent from my iPad > >> On Aug 19, 2022, at 12:56, John Gray wrote: >> >> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >> >> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >> >> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >> >> ss, ct := encapsulate(PublicKey) >> ss := decapsulate(PrivateKey, ct) >> >> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >> -ct is a Cipher Text (a byte array would make sense) >> -Public and Private Keys would use the regular public and private key interface. >> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >> >> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >> >> Then algorithms could be registered in providers as usual: >> >> put("KEM.Kyber","com.blah.Kyber") >> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >> >> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >> >> Cheers, >> >> John Gray >> >> >> >> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Gray at entrust.com Sat Aug 20 01:25:12 2022 From: John.Gray at entrust.com (John Gray) Date: Sat, 20 Aug 2022 01:25:12 +0000 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> Message-ID: Thanks David for your Support. I have been developing cryptographic algorithms in our Entrust Java toolkit since the early 2000?s, so between us we have a lot of years of experience using the JCA. ? Mike, a KEM is not a Cipher. I think of it as a kind of middle ground between a Key Agreement and a Cipher. That is why it can be forced to fit in either model, but it doesn?t fit well with either of them. Not having a clean KEM API will lead to lots of confusion, likely implementation bugs and inconsistent usage. The Cipher.wrap () is not the same as a KEM.encapsulate(). As David mentions, wrap() returns a byte[], but a KEM actually returns a shared secret AND a Ciphertext. The PQ algorithm ?Kyber? selected by NIST is a KEM and it will return a shared-secret that it has generated internally. Returning only a byte[] is not good enough even if you did a na?ve concatenation as you would then have to know the shared-secret length and the cipherText length and you would have to have an agreement with the producing party on which order they came back. For example, if David implemented SS || Ciphertext in BC and I implemented CipherText || SS in our Entrust toolkit, we would fail to interoperate. At minimum we would need to agree on the order, and we would need a function tied to a KEM Cipher to properly separate the values. This just seems like a mess that could be easily solved by adding a clean KEM interface in the JCA. Otherwise everyone is going to try to fit it into the JCA in their own inconsistent way, no one will agree, and we will have lots of interoperability problems down the road. David example below shows it *can* fit, but it is not ideal because you have limited what the key can be used for, and the calling convention is not straight forward like Cipher or Signature are today. KEM allows the establishment of a common shared-secret between two parties, but does not combine the public key and private key of different parties together to obtain the shared secret (like in a Key Agreement). Instead an encapsulation(PublicKey) takes a public key and outputs a CipherText AND Shared Secret. The Shared Secret can be used to derive a SecretKey (like AES) to perform encryption operations or the key could be used to generate a key for other purposes. On the receiving side, the CipherText needs to be combined with the receivers private key (in this regard it is like a Cipher), but it outputs a shared-secret which as mentioned can have many different purposes. KEM has a lot of interesting properties in that the Ciphertexts length is fixed and based on the algorithm. For example, Kyber's CipherText size is 768 bytes at lowest security and 1568 bytes at highest security. For an HSM use-case, it would be very feasible to use KEM as a key transport mechanism to set up the symmetric keys for protection of keys to and from the HSM, or for use-cases which require centralized/HSM generation of symmetric keys (for example a FIPS engine) which can?t be done efficiently by a Cipher. KEM could also be used as a proof-of-possession or in challenge response scenarios. There are many other uses we could enumerate. KEM seems to be the way forward in terms of the NIST standardization process, so it makes sense for us to implement a proper KEM interface in Java now. Cheers, John Gray From: David Hook Sent: Friday, August 19, 2022 6:38 PM To: Mike StJohns ; John Gray Cc: security-dev at openjdk.org Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ Hi Mike, KEMs can be used for key wrapping - we've actually implemented support for this too. But they are not actually key wrapping ciphers. Here's a simple example of using Kyber for key wrapping in BC: SecretKey key = new SecretKeySpec(keyBytes, "AES"); w1.init(Cipher.WRAP_MODE, kp.getPublic(), new KEMParameterSpec("AES-KWP")); byte[] data = w1.wrap(key); Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new KEMParameterSpec("AES-KWP")); Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the secret key separately. This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. Thanks, David On 20/8/22 07:53, Mike StJohns wrote: Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. Mike Sent from my iPad On Aug 19, 2022, at 12:56, John Gray wrote: ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. ss, ct := encapsulate(PublicKey) ss := decapsulate(PrivateKey, ct) -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) -ct is a Cipher Text (a byte array would make sense) -Public and Private Keys would use the regular public and private key interface. -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). Then algorithms could be registered in providers as usual: put("KEM.Kyber","com.blah.Kyber") put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... Cheers, John Gray Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Sat Aug 20 16:23:39 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 20 Aug 2022 12:23:39 -0400 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> Message-ID: <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> Hi David/John - I would submit that you're trying too hard to make your life simple! :-) Cipher.wrap/unwrap are the correct methods. For example: Cipher? kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); The "opaqueEncapsulatedKey" would contain the data needed by the unwrap function - specifically a) the ecies ephemeral public key, b) the fact that the derived key is a GCM key of length 128 and that the GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins other than defaults required by the KDF - which would be passed in a parameter blob during init.? Cipher would NOT return the underlying generated secret used to wrap the key.? Just the public part of the key pair used to do the ECDH operation against the passed in public key.?? In the RSA case, the wrapped encrypting secret would be an opaque data blob and would be part of the data passed to the unwrap function. If you want a key generated for other purposes, then the right thing is using a KDF and a Key agreement function in tandem.?? Strangely the KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. "What's the difference between a bureaucrat and an engineer?? A bureaucrat takes small solvable pieces and combines them into one insoluble mass." In this case, Java provides a number of flexible primitives that can be combined as needed.? In this case, the underlying Cipher implementation would wrap key agreement and kdf and cipher (GCM) instances.? It should return UnsupportedOperationException for all operations execept wrap/unwrap and the appropriate init methods. Later, Mike On 8/19/2022 6:38 PM, David Hook wrote: > Hi Mike, > > KEMs can be used for key wrapping - we've actually implemented support > for this too. But they are not actually key wrapping ciphers. > > Here's a simple example of using Kyber for key wrapping in BC: > > SecretKey key =new SecretKeySpec(keyBytes,"AES"); > > w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); > > byte[]data =w1.wrap(key); > > Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); > > w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); > > Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); > > The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated > by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the > secret key separately. > > This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where > someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to > take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement > class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the > generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a > generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). > > If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since > the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. > > Thanks, > > David > On 20/8/22 07:53, Mike StJohns wrote: >> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. >> >> Mike >> >> Sent from my iPad >> >>> On Aug 19, 2022, at 12:56, John Gray wrote: >>> >>> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >>> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >>> >>> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >>> >>> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >>> >>> ss, ct := encapsulate(PublicKey) >>> ss := decapsulate(PrivateKey, ct) >>> >>> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >>> -ct is a Cipher Text (a byte array would make sense) >>> -Public and Private Keys would use the regular public and private key interface. >>> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >>> >>> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >>> >>> Then algorithms could be registered in providers as usual: >>> >>> put("KEM.Kyber","com.blah.Kyber") >>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >>> >>> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >>> >>> Cheers, >>> >>> John Gray >>> >>> >>> >>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgh at cryptoworkshop.com Sat Aug 20 18:08:08 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Sun, 21 Aug 2022 04:08:08 +1000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> Message-ID: <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> Hi Michael, I don't know anything about bureaucrats, I am an engineer. You may need to consult someone else on bureaucrats. I apologize for my apparent deficiencies in this area, but would you mind explaining how Cipher.wrap() is either supposed to take a public key and create an encapsulation based on it and return a secret key implicitly in one clean move, or why it even makes sense to do so. The method was never conceived as providing the functionality for what a KEM actually does, and when I did the initial PKCS11 implementation at Eracom in the late 90's and the team at Sun added the wrap/unwrap functions to support it, this is definitely not was intended either - it was for explicit key wrapping based on the key that was passed to Cipher.init(). On BC's part, we've already implemented RFC 5990/SP 800-56B in Java and the experience has, at best, been awkward. The new algorithms have moved awkward to inappropriate. With the new algorithms, there's no longer only one case of this, it's not an outlier, there should be a general way of supporting KEMs in the API that doesn't involve over engineering KeyGenerator and Cipher. I work with a team that has had to implement all of them and had to make them fit into the JCA. We have done so. Like John, I am simply relaying our experience. In about 18 months these algorithms are going to become mandatory, what all of us think is irrelevant. We, for our part, already have a solution, but we both realize it's not "the solution" - we recognize that the JVM is uniquely positioned to provide leadership on this and provide a universal way of doing it. Of course, if it's felt that these algorithms should be ignored, it's not my place to revolt, although I do feel obliged to argue. I will simply try and do the best by my users, as I have no doubt will John. Both of us have simply offered our comments in good faith and to alert the community that things have changed and that with these new algorithms there is room for a new approach. The ambiguity about how these algorithms can be implemented and the excessive need to fallback on propritary classes for them does suggest that there are some additions to the JCA which would help. I appreciate to understand this statement does involve actually understanding what these algorithms do and may require some additional reading. As I said, I'm an engineer, my users will be able to use these algorithms properly, my team will ensure that, as I have no doubt will John's. What John and myself, apparently mistakenly, care about is that our users should also be able to use these algorithms portably. Are you saying portability is no longer a consideration? Regards, David On 21/8/22 02:23, Michael StJohns wrote: > Hi David/John - > > I would submit that you're trying too hard to make your life simple! :-) > > Cipher.wrap/unwrap are the correct methods. > > For example: > > Cipher? kem = Cipher.getInstance > ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); > kem.init (Cipher.WRAP_MODE, pubkey); > byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); > > The "opaqueEncapsulatedKey" would contain the data needed by the > unwrap function - specifically a) the ecies ephemeral public key, b) > the fact that the derived key is a GCM key of length 128 and that the > GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins other > than defaults required by the KDF - which would be passed in a > parameter blob during init.? Cipher would NOT return the underlying > generated secret used to wrap the key.? Just the public part of the > key pair used to do the ECDH operation against the passed in public > key.?? In the RSA case, the wrapped encrypting secret would be an > opaque data blob and would be part of the data passed to the unwrap > function. > > If you want a key generated for other purposes, then the right thing > is using a KDF and a Key agreement function in tandem.?? Strangely the > KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. > > "What's the difference between a bureaucrat and an engineer?? A > bureaucrat takes small solvable pieces and combines them into one > insoluble mass." > > In this case, Java provides a number of flexible primitives that can > be combined as needed.? In this case, the underlying Cipher > implementation would wrap key agreement and kdf and cipher (GCM) > instances.? It should return UnsupportedOperationException for all > operations execept wrap/unwrap and the appropriate init methods. > > Later, Mike > > > > On 8/19/2022 6:38 PM, David Hook wrote: >> Hi Mike, >> >> KEMs can be used for key wrapping - we've actually implemented >> support for this too. But they are not actually key wrapping ciphers. >> >> Here's a simple example of using Kyber for key wrapping in BC: >> >> SecretKey key =new SecretKeySpec(keyBytes,"AES"); >> >> w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); >> >> byte[]data =w1.wrap(key); >> >> Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); >> >> w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); >> >> Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); >> >> The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated >> by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the >> secret key separately. >> >> This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where >> someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to >> take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement >> class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the >> generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a >> generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). >> >> If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since >> the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. >> >> Thanks, >> >> David >> On 20/8/22 07:53, Mike StJohns wrote: >>> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. >>> >>> Mike >>> >>> Sent from my iPad >>> >>>> On Aug 19, 2022, at 12:56, John Gray wrote: >>>> >>>> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >>>> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >>>> >>>> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >>>> >>>> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >>>> >>>> ss, ct := encapsulate(PublicKey) >>>> ss := decapsulate(PrivateKey, ct) >>>> >>>> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >>>> -ct is a Cipher Text (a byte array would make sense) >>>> -Public and Private Keys would use the regular public and private key interface. >>>> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >>>> >>>> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >>>> >>>> Then algorithms could be registered in providers as usual: >>>> >>>> put("KEM.Kyber","com.blah.Kyber") >>>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >>>> >>>> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >>>> >>>> Cheers, >>>> >>>> John Gray >>>> >>>> >>>> >>>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Sun Aug 21 03:52:01 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Sat, 20 Aug 2022 23:52:01 -0400 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> Message-ID: <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> On 8/20/2022 2:08 PM, David Hook wrote: > Hi Michael, > > I don't know anything about bureaucrats, I am an engineer. You may > need to consult someone else on bureaucrats. > > I apologize for my apparent deficiencies in this area, but would you > mind explaining how Cipher.wrap() is either supposed to take a public > key and create an encapsulation based on it and return a secret key > implicitly in one clean move, or why it even makes sense to do so. The > method was never conceived as providing the functionality for what a > KEM actually does, and when I did the initial PKCS11 implementation at > Eracom in the late 90's and the team at Sun added the wrap/unwrap > functions to support it, this is definitely not was intended either - > it was for explicit key wrapping based on the key that was passed to > Cipher.init(). > First - PKCS11 is a 40 year old API that probably needs to be retired.? I spent the better part of 2 years working with the PKCS11 Oasis group trying to get them to properly support master secrets and KDFs and failed utterly.?? You should not use PKCS11 as an example that the JCE should use as a goal. At the base, a java class is a collection of objects.? A Cipher object Let's build a non-parameterized ECIES-KEM which implicitly uses AES256 bit keys to key a GCM cipher, and a KDF based on SP800-108 counter mode with SHA256 as the underlying hash, and with a well known label and context for the KDF since there is a new key for every wrap. 1) Implement CipherSpi - public class EciesKemCipher extends CipherSpi { ??? private KeyAgreement ka; ??? private Cipher gcm; ??? private KeyPair kp; ??? private KeyPairGenerator kg; ??? EciesKemCipher() { ??????? ka = KeyAgreement.getInstance("ECDH"); ??????? kpg = KeyPairGenerator.getInstance ("EC"); ??????? gcm = Cipher.getInstance ("AES/GCM/NoPadding"); ?? } ?? // implement a single example ?? @override ??? protected void engineInit (int opMode, Key key, SecureRandom dontcare) { ?????? switch (opMode) { ???????? Cipher.MODE_WRAP: ?????????????? initWrap((ECPublicKey) key); ?????????????? break; ???????? default: ?????????? // unimpl ????????? } ????? } ??? private void initWrap (ECPublicKey k) { ?????????? ECParameterSpec spec = k.getParams(); ????????? kpg.initialize(spec); ????????? kp = kpg.genKeyPair(); ????????? ka.init (kp.getPrivate()); ????????? ka.doPhase (k, true); ????????? byte[] sharedSecret = ka.generateSecret(); ????????? byte[] keyStream = kdf(sharedSecret, 32 + 12); // output 44 bytes for Key and IV ????????? SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, 32, "AES"); ????????? IvParameterSpec gcmIv = new IVParameterSpec(keyStream, 32, 12); ????????? gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); ????????? // all ready to go ???? } ???? protected byte[] engineWrap (Key k) { ?????????? ByteBuffer outData = ByteBuffer.allocate (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; ?????????? // Place a copy of the ephemeral public key I generated in init here for the use of the receiver. ?????????? outData.put (kp.getEncoded()); ?????????? // One s ?????????? outData.put (gcm.doFinal(k.getEncoded()); ??????????? outData.flip(); ??????????? byte[] result = outdata.remaining(); ??????????? outData.get(result); ??????????? // kp = null; clear cipher if it hasn't already been cleared, clear ka if necessary (e.g. un-init) ??????????? return result; ?? } ? ... and unwrap and kdf function } 2) Implement a provider and add the above. > On BC's part, we've already implemented RFC 5990/SP 800-56B in Java > and the experience has, at best, been awkward. The new algorithms have > moved awkward to inappropriate. With the new algorithms, there's no > longer only one case of this, it's not an outlier, there should be a > general way of supporting KEMs in the API that doesn't involve over > engineering KeyGenerator and Cipher. > There's a big difference between the API and your underlying implementation.? Everything you want to do can be done using the current APIs.? As I said before, Cipher.wrap/unwrap are the appropriate APIs for this as they meet the contract requirements you need.?? Most Ciphers require some extra data -e.g. IVs - that have to either be carried or implicitly derived.? In this case, what needs to be carried in addition to the encrypted key material is at least the ephemeral public key the wrapper creates.?? I used a very simple encoding scheme above and this assumes that both ends know exactly what "ECIES-KEM" means.?? Obviously, there are 100s of possible combinations of parameters and KDFs and key wrap algorithms.?? What I would suggest is heading over to LAMPS at the IETF and proposing a data encoding scheme for carrying the parameters.? Once you have that done, then come here and map JCE names against parameter sets to close the loop.? It won't require an API change. > I work with a team that has had to implement all of them and had to > make them fit into the JCA. We have done so. Like John, I am simply > relaying our experience. In about 18 months these algorithms are going > to become mandatory, what all of us think is irrelevant. We, for our > part, already have a solution, but we both realize it's not "the > solution" - we recognize that the JVM is uniquely positioned to > provide leadership on this and provide a universal way of doing it. > Then suggest an API and we'll start knocking it around.? I personally don't think its necessary at this time and will add to API bloat. > Of course, if it's felt that these algorithms should be ignored, it's > not my place to revolt, although I do feel obliged to argue. I will > simply try and do the best by my users, as I have no doubt will John. > Both of us have simply offered our comments in good faith and to alert > the community that things have changed and that with these new > algorithms there is room for a new approach. The ambiguity about how > these algorithms can be implemented and the excessive need to fallback > on propritary classes for them does suggest that there are some > additions to the JCA which would help. I appreciate to understand this > statement does involve actually understanding what these algorithms do > and may require some additional reading. > > As I said, I'm an engineer, my users will be able to use these > algorithms properly, my team will ensure that, as I have no doubt will > John's. What John and myself, apparently mistakenly, care about is > that our users should also be able to use these algorithms portably. > > Are you saying portability is no longer a consideration? > I have no idea where you got that idea. > Regards, > > David > > > > On 21/8/22 02:23, Michael StJohns wrote: >> Hi David/John - >> >> I would submit that you're trying too hard to make your life simple! :-) >> >> Cipher.wrap/unwrap are the correct methods. >> >> For example: >> >> Cipher? kem = Cipher.getInstance >> ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); >> kem.init (Cipher.WRAP_MODE, pubkey); >> byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); >> >> The "opaqueEncapsulatedKey" would contain the data needed by the >> unwrap function - specifically a) the ecies ephemeral public key, b) >> the fact that the derived key is a GCM key of length 128 and that the >> GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins other >> than defaults required by the KDF - which would be passed in a >> parameter blob during init.? Cipher would NOT return the underlying >> generated secret used to wrap the key.? Just the public part of the >> key pair used to do the ECDH operation against the passed in public >> key.?? In the RSA case, the wrapped encrypting secret would be an >> opaque data blob and would be part of the data passed to the unwrap >> function. >> >> If you want a key generated for other purposes, then the right thing >> is using a KDF and a Key agreement function in tandem.?? Strangely >> the KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. >> >> "What's the difference between a bureaucrat and an engineer?? A >> bureaucrat takes small solvable pieces and combines them into one >> insoluble mass." >> >> In this case, Java provides a number of flexible primitives that can >> be combined as needed. In this case, the underlying Cipher >> implementation would wrap key agreement and kdf and cipher (GCM) >> instances.? It should return UnsupportedOperationException for all >> operations execept wrap/unwrap and the appropriate init methods. >> >> Later, Mike >> >> >> >> On 8/19/2022 6:38 PM, David Hook wrote: >>> Hi Mike, >>> >>> KEMs can be used for key wrapping - we've actually implemented >>> support for this too. But they are not actually key wrapping ciphers. >>> >>> Here's a simple example of using Kyber for key wrapping in BC: >>> >>> SecretKey key =new SecretKeySpec(keyBytes,"AES"); >>> >>> w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); >>> >>> byte[]data =w1.wrap(key); >>> >>> Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); >>> >>> w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); >>> >>> Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); >>> >>> The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated >>> by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the >>> secret key separately. >>> >>> This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where >>> someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to >>> take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement >>> class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the >>> generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a >>> generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). >>> >>> If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since >>> the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. >>> >>> Thanks, >>> >>> David >>> On 20/8/22 07:53, Mike StJohns wrote: >>>> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. >>>> >>>> Mike >>>> >>>> Sent from my iPad >>>> >>>>> On Aug 19, 2022, at 12:56, John Gray wrote: >>>>> >>>>> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >>>>> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >>>>> >>>>> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >>>>> >>>>> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >>>>> >>>>> ss, ct := encapsulate(PublicKey) >>>>> ss := decapsulate(PrivateKey, ct) >>>>> >>>>> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >>>>> -ct is a Cipher Text (a byte array would make sense) >>>>> -Public and Private Keys would use the regular public and private key interface. >>>>> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >>>>> >>>>> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >>>>> >>>>> Then algorithms could be registered in providers as usual: >>>>> >>>>> put("KEM.Kyber","com.blah.Kyber") >>>>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >>>>> >>>>> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >>>>> >>>>> Cheers, >>>>> >>>>> John Gray >>>>> >>>>> >>>>> >>>>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgh at cryptoworkshop.com Sun Aug 21 03:57:31 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Sun, 21 Aug 2022 13:57:31 +1000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> Message-ID: On rereading, I've realised I neglected to comment on the KeyAgreement class. It might be useful to see how these things would look in practice. For the 3 code fragment below vPubKey and vPrivKey should be assumed to be the public and private keys of the recipient V. paramSpec is assumed to be carrying KDF or other details - it might be absent. Using KeyAgreement looks like this: ??? // U side ??? KeyAgreement agreement = KeyAgreement.getInstance("Kyber"); ??? agreement.init(null, paramSpec); ??? PublicKey uPub = agreement.doPhase(vPubKey, true); ??? byte[] secret = agreement.generateSecret(); ??? // U sends uPub.getEncoded(), which is the encapsulation ??? // V side - V has encoded a byte[] ??? KeyFactory kFact = KeyFactory.getInstance("KyberEncapsulation"); ??? PublicKey uPub = kFact.generatePublic(new X509EncodedKeySpec(encoded)); ??? KeyAgreement agreement = KeyAgreement.getInstance("Kyber"); ??? agreement.init(vPrivKey, paramSpec); ??? agreement.doPhase(uPub, true);? // return ignored ??? byte[] secret = agreement.generateSecret(); Up side is there's no new API, down side is, to me at least, almost none of the above makes sense, why is null passed to U's init? why isn't uPub a real public key? why does the encapsulation have to be turned into a PublicKey? why is invalid data (probably) being passed to X509EncodedKeySpec? what possible relevance is boolean, other than it has to be there? Okay, I appreciate these things are in the eye of the beholder, but it just looks bad. Here's what is currently done in BC: ??? ??? // U side ??? ??? KeyGenerator keyGen = KeyGenerator.getInstance("Kyber"); ??????? keyGen.init(new KEMGenerateSpec(vPubKey, "AES"), new SecureRandom()); ??????? SecretKeyWithEncapsulation secEnc1 = (SecretKeyWithEncapsulation)keyGen.generateKey(); ??????? byte[] secret = secEnc1.getEncoded(); ??? ??? // U sends secEnc1.getEncapsulation(), which is the encapsulation ??? ??? // V side - V has encoded a byte[] ??? ??? KeyGenerator keyGen = KeyGenerator.getInstance("Kyber"); ??????? keyGen.init(new KEMExtractSpec(vPrivKey, encoded, "AES")); ??????? SecretKeyWithEncapsulation secEnc2 = (SecretKeyWithEncapsulation)keyGen.generateKey(); ??????? byte[] secret = secEnc2.getEncoded(); This feels like it makes more sense, but it is stretching the KeyGenerator class a bit (suddenly some init() methods don't make sense) and we've also had to introduce "vendor specific" classes and it does mean you're always creating a SecretKey even if you just want to do a getEncoded() from it. As much as I prefer it, it still kind of sucks. Here, I think, is what John was proposing earlier could look like: ??? ??? // U side ??? ??? KEM kem = KEM.getInstance("Kyber"); ??????? kem.initGenerate(vPubKey, paramSpec, new SecureRandom()); ??????? byte[] encapsulation = kem.generateEncapsulation(); ??? ??? byte[] secret = kem.generateSecret(); ??? ??? // U sends encapsulation to V ??? ??? // V side - V has encapsulation a byte[] ??? ??? KEM kem = KEM.getInstance("Kyber"); ??????? kem.initExtract(vPrivKey, paramSpec); ??? ??? byte[] secret = kem.extractSecret(encapsulation); As I said, "could look like", I'm not saying "should", but it's really much cleaner, simpler, and less confusing than the first two, and I really think the above demonstrates that these new algorithms are really not properly covered in the existing API. Regards, David On 21/8/22 04:08, David Hook wrote: > Hi Michael, > > I don't know anything about bureaucrats, I am an engineer. You may > need to consult someone else on bureaucrats. > > I apologize for my apparent deficiencies in this area, but would you > mind explaining how Cipher.wrap() is either supposed to take a public > key and create an encapsulation based on it and return a secret key > implicitly in one clean move, or why it even makes sense to do so. The > method was never conceived as providing the functionality for what a > KEM actually does, and when I did the initial PKCS11 implementation at > Eracom in the late 90's and the team at Sun added the wrap/unwrap > functions to support it, this is definitely not was intended either - > it was for explicit key wrapping based on the key that was passed to > Cipher.init(). > > On BC's part, we've already implemented RFC 5990/SP 800-56B in Java > and the experience has, at best, been awkward. The new algorithms have > moved awkward to inappropriate. With the new algorithms, there's no > longer only one case of this, it's not an outlier, there should be a > general way of supporting KEMs in the API that doesn't involve over > engineering KeyGenerator and Cipher. > > I work with a team that has had to implement all of them and had to > make them fit into the JCA. We have done so. Like John, I am simply > relaying our experience. In about 18 months these algorithms are going > to become mandatory, what all of us think is irrelevant. We, for our > part, already have a solution, but we both realize it's not "the > solution" - we recognize that the JVM is uniquely positioned to > provide leadership on this and provide a universal way of doing it. > > Of course, if it's felt that these algorithms should be ignored, it's > not my place to revolt, although I do feel obliged to argue. I will > simply try and do the best by my users, as I have no doubt will John. > Both of us have simply offered our comments in good faith and to alert > the community that things have changed and that with these new > algorithms there is room for a new approach. The ambiguity about how > these algorithms can be implemented and the excessive need to fallback > on propritary classes for them does suggest that there are some > additions to the JCA which would help. I appreciate to understand this > statement does involve actually understanding what these algorithms do > and may require some additional reading. > > As I said, I'm an engineer, my users will be able to use these > algorithms properly, my team will ensure that, as I have no doubt will > John's. What John and myself, apparently mistakenly, care about is > that our users should also be able to use these algorithms portably. > > Are you saying portability is no longer a consideration? > > Regards, > > David > > > > On 21/8/22 02:23, Michael StJohns wrote: >> Hi David/John - >> >> I would submit that you're trying too hard to make your life simple! :-) >> >> Cipher.wrap/unwrap are the correct methods. >> >> For example: >> >> Cipher? kem = Cipher.getInstance >> ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); >> kem.init (Cipher.WRAP_MODE, pubkey); >> byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); >> >> The "opaqueEncapsulatedKey" would contain the data needed by the >> unwrap function - specifically a) the ecies ephemeral public key, b) >> the fact that the derived key is a GCM key of length 128 and that the >> GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins other >> than defaults required by the KDF - which would be passed in a >> parameter blob during init.? Cipher would NOT return the underlying >> generated secret used to wrap the key.? Just the public part of the >> key pair used to do the ECDH operation against the passed in public >> key.?? In the RSA case, the wrapped encrypting secret would be an >> opaque data blob and would be part of the data passed to the unwrap >> function. >> >> If you want a key generated for other purposes, then the right thing >> is using a KDF and a Key agreement function in tandem.?? Strangely >> the KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. >> >> "What's the difference between a bureaucrat and an engineer?? A >> bureaucrat takes small solvable pieces and combines them into one >> insoluble mass." >> >> In this case, Java provides a number of flexible primitives that can >> be combined as needed. In this case, the underlying Cipher >> implementation would wrap key agreement and kdf and cipher (GCM) >> instances.? It should return UnsupportedOperationException for all >> operations execept wrap/unwrap and the appropriate init methods. >> >> Later, Mike >> >> >> >> On 8/19/2022 6:38 PM, David Hook wrote: >>> Hi Mike, >>> >>> KEMs can be used for key wrapping - we've actually implemented >>> support for this too. But they are not actually key wrapping ciphers. >>> >>> Here's a simple example of using Kyber for key wrapping in BC: >>> >>> SecretKey key =new SecretKeySpec(keyBytes,"AES"); >>> >>> w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); >>> >>> byte[]data =w1.wrap(key); >>> >>> Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); >>> >>> w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); >>> >>> Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); >>> >>> The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated >>> by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the >>> secret key separately. >>> >>> This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where >>> someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to >>> take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement >>> class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the >>> generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a >>> generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). >>> >>> If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since >>> the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. >>> >>> Thanks, >>> >>> David >>> On 20/8/22 07:53, Mike StJohns wrote: >>>> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. >>>> >>>> Mike >>>> >>>> Sent from my iPad >>>> >>>>> On Aug 19, 2022, at 12:56, John Gray wrote: >>>>> >>>>> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >>>>> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >>>>> >>>>> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >>>>> >>>>> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >>>>> >>>>> ss, ct := encapsulate(PublicKey) >>>>> ss := decapsulate(PrivateKey, ct) >>>>> >>>>> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >>>>> -ct is a Cipher Text (a byte array would make sense) >>>>> -Public and Private Keys would use the regular public and private key interface. >>>>> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >>>>> >>>>> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >>>>> >>>>> Then algorithms could be registered in providers as usual: >>>>> >>>>> put("KEM.Kyber","com.blah.Kyber") >>>>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >>>>> >>>>> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >>>>> >>>>> Cheers, >>>>> >>>>> John Gray >>>>> >>>>> >>>>> >>>>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgh at cryptoworkshop.com Mon Aug 22 02:51:22 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Mon, 22 Aug 2022 12:51:22 +1000 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> Message-ID: <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> I'd have to agree about PKCS 11. One more thing about the PQC KEMs - the KDF step is built in. As you've mentioned, previously there's been a lot of possible combinations with key agreement, with PQC KEMs this has changed (of course, you could still use a KDF too, but the original reasons for doing so no longer apply). Regards, David On 21/8/22 13:52, Michael StJohns wrote: > On 8/20/2022 2:08 PM, David Hook wrote: >> Hi Michael, >> >> I don't know anything about bureaucrats, I am an engineer. You may >> need to consult someone else on bureaucrats. >> >> I apologize for my apparent deficiencies in this area, but would you >> mind explaining how Cipher.wrap() is either supposed to take a public >> key and create an encapsulation based on it and return a secret key >> implicitly in one clean move, or why it even makes sense to do so. >> The method was never conceived as providing the functionality for >> what a KEM actually does, and when I did the initial PKCS11 >> implementation at Eracom in the late 90's and the team at Sun added >> the wrap/unwrap functions to support it, this is definitely not was >> intended either - it was for explicit key wrapping based on the key >> that was passed to Cipher.init(). >> > First - PKCS11 is a 40 year old API that probably needs to be > retired.? I spent the better part of 2 years working with the PKCS11 > Oasis group trying to get them to properly support master secrets and > KDFs and failed utterly.?? You should not use PKCS11 as an example > that the JCE should use as a goal. > > > At the base, a java class is a collection of objects.? A Cipher object > > Let's build a non-parameterized ECIES-KEM which implicitly uses AES256 > bit keys to key a GCM cipher, and a KDF based on SP800-108 counter > mode with SHA256 as the underlying hash, and with a well known label > and context for the KDF since there is a new key for every wrap. > > 1) Implement CipherSpi - > > public class EciesKemCipher extends CipherSpi { > > ??? private KeyAgreement ka; > ??? private Cipher gcm; > ??? private KeyPair kp; > ??? private KeyPairGenerator kg; > > ??? EciesKemCipher() { > ??????? ka = KeyAgreement.getInstance("ECDH"); > ??????? kpg = KeyPairGenerator.getInstance ("EC"); > ??????? gcm = Cipher.getInstance ("AES/GCM/NoPadding"); > > ?? } > > ?? // implement a single example > > ?? @override > ??? protected void engineInit (int opMode, Key key, SecureRandom > dontcare) { > > ?????? switch (opMode) { > ???????? Cipher.MODE_WRAP: > ?????????????? initWrap((ECPublicKey) key); > ?????????????? break; > ???????? default: > ?????????? // unimpl > ????????? } > ????? } > > ??? private void initWrap (ECPublicKey k) { > > ?????????? ECParameterSpec spec = k.getParams(); > ????????? kpg.initialize(spec); > ????????? kp = kpg.genKeyPair(); > ????????? ka.init (kp.getPrivate()); > ????????? ka.doPhase (k, true); > ????????? byte[] sharedSecret = ka.generateSecret(); > > ????????? byte[] keyStream = kdf(sharedSecret, 32 + 12); // output 44 > bytes for Key and IV > ????????? SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, 32, > "AES"); > ????????? IvParameterSpec gcmIv = new IVParameterSpec(keyStream, 32, 12); > > ????????? gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); > ????????? // all ready to go > ???? } > > ???? protected byte[] engineWrap (Key k) { > > ?????????? ByteBuffer outData = ByteBuffer.allocate > (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; > > ?????????? // Place a copy of the ephemeral public key I generated in > init here for the use of the receiver. > ?????????? outData.put (kp.getEncoded()); > ?????????? // One s > ?????????? outData.put (gcm.doFinal(k.getEncoded()); > > ??????????? outData.flip(); > ??????????? byte[] result = outdata.remaining(); > > ??????????? outData.get(result); > ??????????? // kp = null; clear cipher if it hasn't already been > cleared, clear ka if necessary (e.g. un-init) > > ??????????? return result; > ?? } > > ? ... and unwrap and kdf function > } > > > 2) Implement a provider and add the above. > > >> On BC's part, we've already implemented RFC 5990/SP 800-56B in Java >> and the experience has, at best, been awkward. The new algorithms >> have moved awkward to inappropriate. With the new algorithms, there's >> no longer only one case of this, it's not an outlier, there should be >> a general way of supporting KEMs in the API that doesn't involve over >> engineering KeyGenerator and Cipher. >> > There's a big difference between the API and your underlying > implementation.? Everything you want to do can be done using the > current APIs.? As I said before, Cipher.wrap/unwrap are the > appropriate APIs for this as they meet the contract requirements you > need.?? Most Ciphers require some extra data -e.g. IVs - that have to > either be carried or implicitly derived.? In this case, what needs to > be carried in addition to the encrypted key material is at least the > ephemeral public key the wrapper creates.?? I used a very simple > encoding scheme above and this assumes that both ends know exactly > what "ECIES-KEM" means. Obviously, there are 100s of possible > combinations of parameters and KDFs and key wrap algorithms.?? What I > would suggest is heading over to LAMPS at the IETF and proposing a > data encoding scheme for carrying the parameters.? Once you have that > done, then come here and map JCE names against parameter sets to close > the loop.? It won't require an API change. > >> I work with a team that has had to implement all of them and had to >> make them fit into the JCA. We have done so. Like John, I am simply >> relaying our experience. In about 18 months these algorithms are >> going to become mandatory, what all of us think is irrelevant. We, >> for our part, already have a solution, but we both realize it's not >> "the solution" - we recognize that the JVM is uniquely positioned to >> provide leadership on this and provide a universal way of doing it. >> > Then suggest an API and we'll start knocking it around.? I personally > don't think its necessary at this time and will add to API bloat. > >> Of course, if it's felt that these algorithms should be ignored, it's >> not my place to revolt, although I do feel obliged to argue. I will >> simply try and do the best by my users, as I have no doubt will John. >> Both of us have simply offered our comments in good faith and to >> alert the community that things have changed and that with these new >> algorithms there is room for a new approach. The ambiguity about how >> these algorithms can be implemented and the excessive need to >> fallback on propritary classes for them does suggest that there are >> some additions to the JCA which would help. I appreciate to >> understand this statement does involve actually understanding what >> these algorithms do and may require some additional reading. >> >> As I said, I'm an engineer, my users will be able to use these >> algorithms properly, my team will ensure that, as I have no doubt >> will John's. What John and myself, apparently mistakenly, care about >> is that our users should also be able to use these algorithms portably. >> >> Are you saying portability is no longer a consideration? >> > I have no idea where you got that idea. > >> Regards, >> >> David >> >> >> >> On 21/8/22 02:23, Michael StJohns wrote: >>> Hi David/John - >>> >>> I would submit that you're trying too hard to make your life simple! :-) >>> >>> Cipher.wrap/unwrap are the correct methods. >>> >>> For example: >>> >>> Cipher? kem = Cipher.getInstance >>> ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); >>> kem.init (Cipher.WRAP_MODE, pubkey); >>> byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); >>> >>> The "opaqueEncapsulatedKey" would contain the data needed by the >>> unwrap function - specifically a) the ecies ephemeral public key, b) >>> the fact that the derived key is a GCM key of length 128 and that >>> the GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins >>> other than defaults required by the KDF - which would be passed in a >>> parameter blob during init.? Cipher would NOT return the underlying >>> generated secret used to wrap the key.? Just the public part of the >>> key pair used to do the ECDH operation against the passed in public >>> key.?? In the RSA case, the wrapped encrypting secret would be an >>> opaque data blob and would be part of the data passed to the unwrap >>> function. >>> >>> If you want a key generated for other purposes, then the right thing >>> is using a KDF and a Key agreement function in tandem.?? Strangely >>> the KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. >>> >>> "What's the difference between a bureaucrat and an engineer?? A >>> bureaucrat takes small solvable pieces and combines them into one >>> insoluble mass." >>> >>> In this case, Java provides a number of flexible primitives that can >>> be combined as needed.? In this case, the underlying Cipher >>> implementation would wrap key agreement and kdf and cipher (GCM) >>> instances.? It should return UnsupportedOperationException for all >>> operations execept wrap/unwrap and the appropriate init methods. >>> >>> Later, Mike >>> >>> >>> >>> On 8/19/2022 6:38 PM, David Hook wrote: >>>> Hi Mike, >>>> >>>> KEMs can be used for key wrapping - we've actually implemented >>>> support for this too. But they are not actually key wrapping ciphers. >>>> >>>> Here's a simple example of using Kyber for key wrapping in BC: >>>> >>>> SecretKey key =new SecretKeySpec(keyBytes,"AES"); >>>> >>>> w1.init(Cipher.WRAP_MODE, kp.getPublic(),new KEMParameterSpec("AES-KWP")); >>>> >>>> byte[]data =w1.wrap(key); >>>> >>>> Cipher w2 =Cipher.getInstance(algorithm,"BCPQC"); >>>> >>>> w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(),new KEMParameterSpec("AES-KWP")); >>>> >>>> Key k =w2.unwrap(data,"AES",Cipher.SECRET_KEY); >>>> >>>> The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated >>>> by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the >>>> secret key separately. >>>> >>>> This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where >>>> someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to >>>> take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement >>>> class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the >>>> generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a >>>> generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). >>>> >>>> If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since >>>> the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. >>>> >>>> Thanks, >>>> >>>> David >>>> On 20/8/22 07:53, Mike StJohns wrote: >>>>> Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. >>>>> >>>>> Mike >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Aug 19, 2022, at 12:56, John Gray wrote: >>>>>> >>>>>> ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: >>>>>> See:https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ >>>>>> >>>>>> However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). >>>>>> >>>>>> I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. >>>>>> >>>>>> ss, ct := encapsulate(PublicKey) >>>>>> ss := decapsulate(PrivateKey, ct) >>>>>> >>>>>> -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) >>>>>> -ct is a Cipher Text (a byte array would make sense) >>>>>> -Public and Private Keys would use the regular public and private key interface. >>>>>> -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. >>>>>> >>>>>> Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). >>>>>> >>>>>> Then algorithms could be registered in providers as usual: >>>>>> >>>>>> put("KEM.Kyber","com.blah.Kyber") >>>>>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") >>>>>> >>>>>> Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... >>>>>> >>>>>> Cheers, >>>>>> >>>>>> John Gray >>>>>> >>>>>> >>>>>> >>>>>> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Aug 22 08:36:47 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 08:36:47 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: <2BVsAl-9UxGtXxfSH-RCnBysHcfdy8VHTUknU0uj27c=.99dddec4-b17d-411b-9e04-fbe0bbd63339@github.com> References: <2BVsAl-9UxGtXxfSH-RCnBysHcfdy8VHTUknU0uj27c=.99dddec4-b17d-411b-9e04-fbe0bbd63339@github.com> Message-ID: On Fri, 19 Aug 2022 21:35:17 GMT, Weijun Wang wrote: >> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 2: > >> 1: /* >> 2: * Copyright (c) 2014, 2022, Oracle and/or its affiliates. All rights reserved. > > Only "Copyright (c) 2022" is needed. Actually, you don't need to include "Oracle" here. See https://github.com/openjdk/jdk/blob/3e60e828148a0490a4422d0724d15f3eccec17f0/test/jdk/sun/security/pkcs11/Cipher/TestPaddingOOB.java for an example. ok > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 27: > >> 25: * @test >> 26: * @bug 8215916 >> 27: * @summary This Sample application attempts to authenticate a user > > Update the summary. Ok > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 50: > >> 48: } >> 49: >> 50: static void login(String test, String... conf) throws Exception { > > All arguments are useless now. You can simply remove this `login` method and merge the content into `main`. The config file name can be hardcoded. ok > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 61: > >> 59: >> 60: System.out.println("config is : \n"+config); >> 61: Files.write(java.nio.file.Path.of(test), config.toString().getBytes()); > > Use `Files.writeString`. I will try > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 64: > >> 62: >> 63: // Must be called. Configuration has an internal static field. >> 64: Configuration.setConfiguration(null); > > Is this necessary since you run this test in othervm mode? I am not sure about that. Let me give a try by removing this and see what happens. > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 69: > >> 67: ByteArrayOutputStream stream = new ByteArrayOutputStream(); >> 68: PrintStream ps = new PrintStream(stream); >> 69: System.setErr(ps); > > Store `System.err` in a local variable so you can call `System.setErr(oldSystemErr)` in a `finally` clause of the `try` block at line 71 below.. Ok. But at present I am not getting why we should do this :) I mean, is it going to improvise something or helpful ? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 08:39:00 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 08:39:00 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 21:47:00 GMT, Weijun Wang wrote: >> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 85: > >> 83: throw new RuntimeException(); >> 84: } else { >> 85: System.out.printf("-- call stack is -- %n%s%n", s); > > I'd rather print out the call stack if the test fails. Who would want to read the test output if it succeeds? Aim of this patch is to print the call stack trace right ? And if the test case passes that means we have to print the call stack trace. And if the test case fails are suggesting to print the exception we are throwing (i.e RuntimeException) ? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 12:42:49 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 12:42:49 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 20:33:23 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Answers. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 12:42:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 12:42:53 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: <2BVsAl-9UxGtXxfSH-RCnBysHcfdy8VHTUknU0uj27c=.99dddec4-b17d-411b-9e04-fbe0bbd63339@github.com> Message-ID: On Mon, 22 Aug 2022 08:33:54 GMT, Jayashree Huttanagoudar wrote: >> test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 69: >> >>> 67: ByteArrayOutputStream stream = new ByteArrayOutputStream(); >>> 68: PrintStream ps = new PrintStream(stream); >>> 69: System.setErr(ps); >> >> Store `System.err` in a local variable so you can call `System.setErr(oldSystemErr)` in a `finally` clause of the `try` block at line 71 below.. > > Ok. But at present I am not getting why we should do this :) > I mean, is it going to improvise something or helpful ? The exception thrown on line 83 is meant to be observed by the user. Only the `login()` exception needs to be captured for content inspection. If all exceptions are captured, people might be wondering where the test fails (before the fix) since the test output has no hint on it. >> test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 85: >> >>> 83: throw new RuntimeException(); >>> 84: } else { >>> 85: System.out.printf("-- call stack is -- %n%s%n", s); >> >> I'd rather print out the call stack if the test fails. Who would want to read the test output if it succeeds? > > Aim of this patch is to print the call stack trace right ? And if the test case passes that means we have to print the call stack trace. > And if the test case fails are suggesting to print the exception we are throwing (i.e RuntimeException) ? Aim of the fix is to print out the call stack, and the aim of the test is to ensure it's correctly printed. When the test fails, it's necessary to see what was printed so people can check where the problem is. For example, someone in the future might casually simplify the message to "Failed to import the underlying" and this test will fail. Without the content it's not easy to find out what goes wrong. I'm not against printing out the call stack when the test succeeds. I just feel it's more useful if it fails. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From mullan at openjdk.org Mon Aug 22 13:02:55 2022 From: mullan at openjdk.org (Sean Mullan) Date: Mon, 22 Aug 2022 13:02:55 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 14:05:38 GMT, Weibing Xiao wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > add or remove the blank line according to the comments src/java.base/share/classes/sun/security/ssl/ServerHello.java line 475: > 473: } > 474: > 475: //negotiation failed between client and server, print server enabled cipher suites add space after `//` src/java.base/share/classes/sun/security/ssl/ServerHello.java line 775: > 773: LinkedList fieldsList = new LinkedList<>(); > 774: > 775: fieldsList.add("SSLSeverSocket info"); Typo: SSLServerSocket src/java.base/share/classes/sun/security/ssl/ServerHello.java line 778: > 776: fieldsList.add(shc.sslConfig.preferLocalCipherSuites ? "Server preference" : "Client preference"); > 777: fieldsList.add(shc.sslConfig.clientAuthType.toString()); > 778: fieldsList.add(shc.activeCipherSuites != null ? shc.activeCipherSuites.toString() : "Not Set"); Why is this capitalized? "not set" seems better. src/java.base/share/classes/sun/security/ssl/ServerHello.java line 781: > 779: fieldsList.add(Security.getProperty(LegacyAlgorithmConstraints.PROPERTY_TLS_LEGACY_ALGS)); > 780: > 781: if (!shc.negotiatedProtocol.name.equalsIgnoreCase(ProtocolVersion.TLS13.name)) { This check is somewhat incorrect in my opinion, just because none of the legacy algs don't apply to TLS 1.3 doesn't mean that we won't add one in the future or someone could configure it themselves. It feels like this is the wrong place to be logging about legacy/disabled suites and this should be logged only if the constraints have been applied. I would remove the logging of the legacy algs as it doesn't seem critical. Plus it doesn't make sense to only log legacy algs and not disabled algs. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From duke at openjdk.org Mon Aug 22 14:56:34 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 14:56:34 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v17] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/eceebabe..a0fc0e43 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=15-16 Stats: 18 lines in 1 file changed: 2 ins; 8 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 14:56:35 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 14:56:35 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v16] In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 20:33:23 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I have tried my best to include your suggestions :) Could you please take a look? ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 15:18:35 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 15:18:35 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v17] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 14:56:34 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The new `setErr` is good. You still haven't printed out the stack trace when the test fails. I know this has not effect on whether the test fails or not. The benefit of it is for diagnosis once the test fails. Has I seen a failure, the 1st thing I would do is to look into the stack trace and see why that message is not there. So, why not add it now? Another comment: the 2 constants defined at the beginning of the test are useless now. You can remove them. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 15:42:45 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 15:42:45 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v17] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 15:15:07 GMT, Weijun Wang wrote: > The new `setErr` is good. > > You still haven't printed out the stack trace when the test fails. I know this has not effect on whether the test fails or not. The benefit of it is for diagnosis once the test fails. Has I seen a failure, the 1st thing I would do is to look into the stack trace and see why that message is not there. So, why not add it now? > Hmm I saw some exception trace is printed out here for failure case: [root at hp-z210-01 jdk]# jtreg/bin/jtreg -jdk:/root/jdk/build.master/linux-x86_64-server-release/images/jdk/ test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java Test results: failed: 1 Report written to /root/jdk/JTreport/html/report.html Results written to /root/jdk/JTwork Error: Some tests failed or other problems occurred. [root at hp-z210-01 jdk]# cat JTwork/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.jtr #Test Results (version 2) #Mon Aug 22 10:47:19 EDT 2022 #-----testdescription----- $file=/root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java $root=/root/jdk/test/jdk keywords=bug8215916 othervm run=USER_SPECIFIED main/othervm -Djava.security.debug=logincontext UnixNTPlatform\n source=UnixNTPlatform.java title=This test case attempts to verify whether call stack trace is printed when JAAS optional login fails when debug is true. #-----environment----- #-----testresult----- description=file:/root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java elapsed=828 0:00:00.828 end=Mon Aug 22 10:47:19 EDT 2022 environment=regtest execStatus=Failed. Execution failed: `main' threw exception: java.lang.RuntimeException harnessLoaderMode=Classpath Loader harnessVariety=Full Bundle hostname=hp-z210-01.ml3.eng.bos.redhat.com javatestOS=Linux 5.18.13-200.fc36.x86_64 (amd64) javatestVersion=6.0-ea+b14-2022-02-03 jtregVersion=jtreg 6.2 dev 0 script=com.sun.javatest.regtest.exec.RegressionScript sections=script_messages build compile main start=Mon Aug 22 10:47:18 EDT 2022 test=javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java testJDK=/root/jdk/build.master/linux-x86_64-server-release/images/jdk totalTime=831 user.name=root work=/root/jdk/JTwork/javax/security/auth/login/LoginContext/OptionalJaas #section:script_messages ----------messages:(4/263)---------- JDK under test: /root/jdk/build.master/linux-x86_64-server-release/images/jdk openjdk version "20-internal" 2023-03-21 OpenJDK Runtime Environment (build 20-internal-adhoc.root.jdk) OpenJDK 64-Bit Server VM (build 20-internal-adhoc.root.jdk, mixed mode, sharing) #section:build ----------messages:(5/141)---------- command: build UnixNTPlatform reason: Named class compiled on demand Test directory: compile: UnixNTPlatform elapsed time (seconds): 0.671 result: Passed. Build successful #section:compile ----------messages:(4/202)---------- command: compile /root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java reason: .class file out of date or does not exist Mode: othervm elapsed time (seconds): 0.669 ----------configuration:(5/312)---------- javac compilation environment source path: /root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas class path: /root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 15:58:49 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 15:58:49 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v18] In-Reply-To: References: Message-ID: <2_64rSpX4Jukk4eQg47KLRlUG1YFtV1x2WU9nR0IEI8=.5c702c5d-58af-460d-a400-326c2fa5aa9a@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/a0fc0e43..477aef0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=16-17 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 16:10:00 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 16:10:00 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v18] In-Reply-To: <2_64rSpX4Jukk4eQg47KLRlUG1YFtV1x2WU9nR0IEI8=.5c702c5d-58af-460d-a400-326c2fa5aa9a@github.com> References: <2_64rSpX4Jukk4eQg47KLRlUG1YFtV1x2WU9nR0IEI8=.5c702c5d-58af-460d-a400-326c2fa5aa9a@github.com> Message-ID: On Mon, 22 Aug 2022 15:58:49 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The exception only shows the test failed. But, what's the reason? There will be more info if you print out `s`. On the other hand, it's not worth printing it out when the test succeeds. Just to clarify, I might have confused the stack trace of the exception thrown by the test and the newly printed one thrown inside `LoginContext`. I meant the latter, which is captured in `s` and this bug is about its content. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 17:15:39 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 17:15:39 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v18] In-Reply-To: References: <2_64rSpX4Jukk4eQg47KLRlUG1YFtV1x2WU9nR0IEI8=.5c702c5d-58af-460d-a400-326c2fa5aa9a@github.com> Message-ID: <-gfJdgxlNEpSNRCCdARyWCYTqnf4ZZ3KJLRzNDWjEPQ=.1da4002e-2f6f-4f4b-87d1-46b7d2cb2f4b@github.com> On Mon, 22 Aug 2022 16:07:49 GMT, Weijun Wang wrote: > Just to clarify, I might have confused the stack trace of the exception thrown by the test and the newly printed one thrown inside `LoginContext`. I meant the latter, which is captured in `s` and this bug is about its content. So the patch should look like : # git diff diff --git a/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java b/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java index 6ce0c0ae8fa..5a1aa98ec99 100644 --- a/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java +++ b/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java @@ -39,7 +39,7 @@ import java.io.PrintStream; public class UnixNTPlatform { public static void main(String[] args) throws Exception { - System.out.println("Testing cross-platform"); + System.out.println("Testing cross-platform"); String config = """ hello { @@ -71,7 +71,9 @@ public class UnixNTPlatform { byte[] byes = stream.toByteArray(); String s = new String(byes); if (!s.contains("Failed in attempt to import the underlying")) { - throw new RuntimeException(); + //throw new RuntimeException(); + System.out.printf("-- call stack is -- %n%s%n", s); + throw new RuntimeException(); } else { System.out.printf("-- call stack is -- %n%s%n", s); } ? I tried to execute the test case with this change and I don't see anything changed much. # jtreg/bin/jtreg -jdk:/root/jdk/build.master/linux-x86_64-server-release/images/jdk/ test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java Test results: failed: 1 Report written to /root/jdk/JTreport/html/report.html Results written to /root/jdk/JTwork Error: Some tests failed or other problems occurred. [root at hp-z210-01 jdk]# cat JTwork/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.jtr #Test Results (version 2) #Mon Aug 22 12:59:50 EDT 2022 #-----testdescription----- $file=/root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java $root=/root/jdk/test/jdk keywords=bug8215916 othervm run=USER_SPECIFIED main/othervm -Djava.security.debug=logincontext UnixNTPlatform\n source=UnixNTPlatform.java title=This test case attempts to verify whether call stack trace is printed when JAAS optional login fails when debug is true. #-----environment----- #-----testresult----- description=file:/root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java elapsed=159 0:00:00.159 end=Mon Aug 22 12:59:50 EDT 2022 environment=regtest execStatus=Failed. Execution failed: `main' threw exception: java.lang.RuntimeException harnessLoaderMode=Classpath Loader harnessVariety=Full Bundle hostname=hp-z210-01.ml3.eng.bos.redhat.com javatestOS=Linux 5.18.13-200.fc36.x86_64 (amd64) javatestVersion=6.0-ea+b14-2022-02-03 jtregVersion=jtreg 6.2 dev 0 script=com.sun.javatest.regtest.exec.RegressionScript sections=script_messages build main start=Mon Aug 22 12:59:50 EDT 2022 test=javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java testJDK=/root/jdk/build.master/linux-x86_64-server-release/images/jdk totalTime=162 user.name=root work=/root/jdk/JTwork/javax/security/auth/login/LoginContext/OptionalJaas #section:script_messages ----------messages:(4/263)---------- JDK under test: /root/jdk/build.master/linux-x86_64-server-release/images/jdk openjdk version "20-internal" 2023-03-21 OpenJDK Runtime Environment (build 20-internal-adhoc.root.jdk) OpenJDK 64-Bit Server VM (build 20-internal-adhoc.root.jdk, mixed mode, sharing) #section:build ----------messages:(3/99)---------- command: build UnixNTPlatform reason: Named class compiled on demand elapsed time (seconds): 0.001 result: Passed. All files up to date #section:main ----------messages:(4/228)---------- command: main -Djava.security.debug=logincontext UnixNTPlatform reason: User specified action: run main/othervm -Djava.security.debug=logincontext UnixNTPlatform Mode: othervm [/othervm specified] elapsed time (seconds): 0.111 ----------configuration:(0/0)---------- ----------System.out:(43/1841)---------- Testing cross-platform config is : hello { com.sun.security.auth.module.UnixLoginModule optional debug=true; com.sun.security.auth.module.NTLoginModule optional debug=true; }; [UnixLoginModule]: succeeded importing info: uid = 0 gid = 0 supp gid = 0 [NTLoginModule] Failed in NT login [UnixLoginModule]: added UnixPrincipal, UnixNumericUserPrincipal, UnixNumericGroupPrincipal(s), to Subject [NTLoginModule]: did not add any Principals to Subject because own authentication failed. Subject: Principal: UnixPrincipal: root Principal: UnixNumericUserPrincipal: 0 Principal: UnixNumericGroupPrincipal [Primary Group]: 0 [UnixLoginModule]: logged out Subject [NTLoginModule] completed logout processing -- call stack is -- [LoginContext]: Build ServiceProviders cache for ClassLoader: app [LoginContext]: Discovered ServiceProviders for ClassLoader: app java.util.ServiceLoader$ProviderImpl at 26235ac3 java.util.ServiceLoader$ProviderImpl at b2ec215d java.util.ServiceLoader$ProviderImpl at a4b0c752 java.util.ServiceLoader$ProviderImpl at 7231ae26 java.util.ServiceLoader$ProviderImpl at 20ac495b java.util.ServiceLoader$ProviderImpl at 2f3bbd71 java.util.ServiceLoader$ProviderImpl at 78ff4ab0 [LoginContext]: com.sun.security.auth.module.UnixLoginModule loaded as a service [LoginContext]: com.sun.security.auth.module.UnixLoginModule login success [LoginContext]: com.sun.security.auth.module.NTLoginModule loaded as a service [LoginContext]: com.sun.security.auth.module.NTLoginModule login OPTIONAL failure [LoginContext]: com.sun.security.auth.module.UnixLoginModule commit success [LoginContext]: com.sun.security.auth.module.NTLoginModule commit ignored [LoginContext]: com.sun.security.auth.module.UnixLoginModule logout success [LoginContext]: com.sun.security.auth.module.NTLoginModule logout success ----------System.err:(11/552)---------- java.lang.RuntimeException at UnixNTPlatform.main(UnixNTPlatform.java:76) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:578) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:1589) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException ----------rerun:(23/1650)*---------- cd /root/jdk/JTwork/scratch && \\ HOME=/root \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin:/usr/sbin \\ XMODIFIERS=@im=ibus \\ CLASSPATH=/root/jdk/JTwork/classes/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.d:/root/jdk/test/jdk/javax/security/auth/login/LoginContext/OptionalJaas:/root/jdk/jtreg/lib/javatest.jar:/root/jdk/jtreg/lib/jtreg.jar \\ ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 17:44:38 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 17:44:38 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v18] In-Reply-To: <-gfJdgxlNEpSNRCCdARyWCYTqnf4ZZ3KJLRzNDWjEPQ=.1da4002e-2f6f-4f4b-87d1-46b7d2cb2f4b@github.com> References: <2_64rSpX4Jukk4eQg47KLRlUG1YFtV1x2WU9nR0IEI8=.5c702c5d-58af-460d-a400-326c2fa5aa9a@github.com> <-gfJdgxlNEpSNRCCdARyWCYTqnf4ZZ3KJLRzNDWjEPQ=.1da4002e-2f6f-4f4b-87d1-46b7d2cb2f4b@github.com> Message-ID: <3W-2-pT6_29Tw-PzGFj82JLVf3ceCY5yuQJbx6_Em-8=.984330d8-04f1-4bd7-81a8-0b6eda7ab472@github.com> On Mon, 22 Aug 2022 17:08:09 GMT, Jayashree Huttanagoudar wrote: > So the patch should look like : > ... Yes. If you decide to print out `s` no matter if success or not, you can move it out of the if block. > I tried to execute the test case with this change and I don't see anything changed much. Of course not. It would be useful if the test fails one day. For example, you can try to modify the exception message on line 150 of `NTLoginModule` and see how the test fails. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:05:26 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:05:26 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v19] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/477aef0a..5c38a3b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=17-18 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:11:21 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:11:21 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v20] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address jcheck space errors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/5c38a3b1..2964c8f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 18:11:24 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 18:11:24 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v19] In-Reply-To: References: Message-ID: <7Gr8lyLNFW1RLZyEcrQTO-1ApBEBNYcuymRpsvK_aAQ=.f92e3840-32c5-4bef-9ddd-f0507f9fdafe@github.com> On Mon, 22 Aug 2022 18:05:26 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 76: > 74: throw new RuntimeException(); > 75: } > 76: System.out.printf("-- call stack is -- %n%s%n", s); Print before the exception is thrown. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:11:24 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:11:24 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v19] In-Reply-To: <7Gr8lyLNFW1RLZyEcrQTO-1ApBEBNYcuymRpsvK_aAQ=.f92e3840-32c5-4bef-9ddd-f0507f9fdafe@github.com> References: <7Gr8lyLNFW1RLZyEcrQTO-1ApBEBNYcuymRpsvK_aAQ=.f92e3840-32c5-4bef-9ddd-f0507f9fdafe@github.com> Message-ID: On Mon, 22 Aug 2022 18:05:11 GMT, Weijun Wang wrote: >> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 76: > >> 74: throw new RuntimeException(); >> 75: } >> 76: System.out.printf("-- call stack is -- %n%s%n", s); > > Print before the exception is thrown. Yes ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:15:14 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:15:14 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v21] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address jcheck space errors and review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/2964c8f8..1d04a324 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=19-20 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 18:26:35 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 18:26:35 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v21] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 18:15:14 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address jcheck space errors and review comment Please update the copyright line of the test to "Copyright (c) 2022, Red Hat, Inc." since this is a new test. No other comment. Thanks for the patience. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:39:14 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:39:14 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v22] In-Reply-To: References: Message-ID: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment to update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/1d04a324..09fcde17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=20-21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:39:15 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:39:15 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v21] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 18:22:48 GMT, Weijun Wang wrote: > Please update the copyright line of the test to "Copyright (c) 2022, Red Hat, Inc." since this is a new test. No other comment. Thanks for the patience. Done :) In fact I have to thank you a lot for such patience to guide me throughout. Through this one activity I feel I had lot of learning. Thank you so so much! ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 18:46:35 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 18:46:35 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v22] In-Reply-To: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> References: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> Message-ID: On Mon, 22 Aug 2022 18:39:14 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment to update copyright I've submitted the change to our test servers. Will approve the change once the job is finished. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Mon Aug 22 18:56:17 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Mon, 22 Aug 2022 18:56:17 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v22] In-Reply-To: References: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> Message-ID: On Mon, 22 Aug 2022 18:44:21 GMT, Weijun Wang wrote: > I've submitted the change to our test servers. Will approve the change once the job is finished. Sure thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Mon Aug 22 19:49:59 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 22 Aug 2022 19:49:59 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v22] In-Reply-To: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> References: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> Message-ID: On Mon, 22 Aug 2022 18:39:14 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment to update copyright Approved. Some tiny comments (sorry for more): 1. No need to import `Configuration` class now. 2. No need to import `Paths` class now, or, you can change it to `Path` and simplify its reference on line 52. No need for more code review for these changes. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/9159 From mpowers at openjdk.org Tue Aug 23 03:49:07 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 Aug 2022 03:49:07 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security Message-ID: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> https://bugs.openjdk.org/browse/JDK-8291509 ------------- Commit messages: - Merge - fourth iteration - third iteration - mismerge - Merge - second iteration - first iteration Changes: https://git.openjdk.org/jdk/pull/9972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291509 Stats: 4088 lines in 307 files changed: 378 ins; 767 del; 2943 mod Patch: https://git.openjdk.org/jdk/pull/9972.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972 PR: https://git.openjdk.org/jdk/pull/9972 From duke at openjdk.org Tue Aug 23 06:39:45 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 23 Aug 2022 06:39:45 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v22] In-Reply-To: References: <9F7JEXmyTgQVwO1rTAHiI8bIhdVmN7VYerXMosU0IGg=.f5ce29f1-8a9a-4f7d-b4f7-9c9ca5f30c5c@github.com> Message-ID: On Mon, 22 Aug 2022 19:47:01 GMT, Weijun Wang wrote: > Approved. > > Some tiny comments (sorry for more): > > 1. No need to import `Configuration` class now. > > 2. No need to import `Paths` class now, or, you can change it to `Path` and simplify its reference on line 52. > > > No need for more code review for these changes. Done. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 23 06:39:44 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Tue, 23 Aug 2022 06:39:44 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v23] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment for import statements ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/09fcde17..6d833913 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=21-22 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From jeisl at openjdk.org Tue Aug 23 10:27:35 2022 From: jeisl at openjdk.org (Josef Eisl) Date: Tue, 23 Aug 2022 10:27:35 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v6] In-Reply-To: <46NjER7jae3jHXj2jDq_RM3RAf_GmgT7qX91yCn19Y4=.b8e393f0-0e25-4144-a997-d3b6da643d2b@github.com> References: <46NjER7jae3jHXj2jDq_RM3RAf_GmgT7qX91yCn19Y4=.b8e393f0-0e25-4144-a997-d3b6da643d2b@github.com> Message-ID: <6x05TsjwoHe_2Wx5UDWogTK9DVxiVAqnwQ3biTRz2fc=.67a321cf-787a-4d0c-acd6-40cef132b030@github.com> On Fri, 19 Aug 2022 23:32:17 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Provider.java line 1276: >> >>> 1274: } >>> 1275: if (serviceSet == null) { >>> 1276: ensureLegacyParsed(); >> >> Hi @valeriepeng! I believe that with this change, `getServices()` will return invalid legacy services. Before we called `ensureLegacyParsed()`, which eventually called `removeInvalidServices()`. In `getService(String, String)`, we are now explicitly checking for `isValid()` to keep the old behavior. Shouldn't we do something similar here as well? Am I missing something or is this an intended change? > > Hmm, could be. Let me check into it and I will have to file a separate bug to address this since the changes have already been integrated. Thanks for the comments. Thanks for looking into this! Please let me if you open a new bug so we can track it. ------------- PR: https://git.openjdk.org/jdk/pull/6513 From weijun at openjdk.org Tue Aug 23 13:09:31 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 23 Aug 2022 13:09:31 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v23] In-Reply-To: References: Message-ID: <5cygolC_DgYCDjcbFF2UhLrPyR3XAagyibXLVOebRpU=.ac5afa8e-4297-43a8-902b-09d3dab3690e@github.com> On Tue, 23 Aug 2022 06:39:44 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment for import statements test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 51: > 49: > 50: System.out.println("config is : \n"+config); > 51: Files.writeString(java.nio.file.Path.of("cross-platform"), config.toString()); No need to write full package name here then. ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Tue Aug 23 15:04:44 2022 From: duke at openjdk.org (Weibing Xiao) Date: Tue, 23 Aug 2022 15:04:44 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: > Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: update the code according to review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9731/files - new: https://git.openjdk.org/jdk/pull/9731/files/68a12183..d60b219b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9731&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9731&range=01-02 Stats: 28 lines in 2 files changed: 2 ins; 9 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/9731.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9731/head:pull/9731 PR: https://git.openjdk.org/jdk/pull/9731 From mpowers at openjdk.org Tue Aug 23 15:06:32 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 23 Aug 2022 15:06:32 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Mon, 22 Aug 2022 21:45:39 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8291509 Mach5 tier1 and tier2 tests all pass on all platforms. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From duke at openjdk.org Tue Aug 23 15:08:37 2022 From: duke at openjdk.org (Weibing Xiao) Date: Tue, 23 Aug 2022 15:08:37 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 15:04:44 GMT, Weibing Xiao wrote: >> Log the debugging info for server cipher suites when setting javax.net.debug == ssl, handshake. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > update the code according to review comments This change will let the developer know the configuration of the server socket when the errors happen through debugging enabled. 1. Updated the code format, the case of log messages 2. New boolean variable CSFound is removed by combining the error messages together 3. Only enabled cipher suites of server socket will be printed out 4. Still keep the list of the legacy suites since it is created during the process. It will only be printed out when it is available. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From valeriep at openjdk.org Tue Aug 23 16:55:49 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 Aug 2022 16:55:49 GMT Subject: RFR: 8276660: Scalability bottleneck in java.security.Provider.getService() [v6] In-Reply-To: <6x05TsjwoHe_2Wx5UDWogTK9DVxiVAqnwQ3biTRz2fc=.67a321cf-787a-4d0c-acd6-40cef132b030@github.com> References: <46NjER7jae3jHXj2jDq_RM3RAf_GmgT7qX91yCn19Y4=.b8e393f0-0e25-4144-a997-d3b6da643d2b@github.com> <6x05TsjwoHe_2Wx5UDWogTK9DVxiVAqnwQ3biTRz2fc=.67a321cf-787a-4d0c-acd6-40cef132b030@github.com> Message-ID: On Tue, 23 Aug 2022 10:25:19 GMT, Josef Eisl wrote: >> Hmm, could be. Let me check into it and I will have to file a separate bug to address this since the changes have already been integrated. Thanks for the comments. > > Thanks for looking into this! Please let me if you open a new bug so we can track it. Filed https://bugs.openjdk.org/browse/JDK-8292739 A PR should be out in a day or two. ------------- PR: https://git.openjdk.org/jdk/pull/6513 From coffeys at openjdk.org Tue Aug 23 20:12:43 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 23 Aug 2022 20:12:43 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: On Thu, 18 Aug 2022 15:36:43 GMT, Xue-Lei Andrew Fan wrote: >> Intend to log all of the collected information in one place. It is easy for the developer to see the configuration of the server socket. Previously when the handshake is failing, no information is available for the server socket in the log file. > > So, do you want to make the log where the configuration happens? Logging in one place cannot have the accuracy debug log where the problem happens, and cannot easy the analysis of the debug. One just gets the configuration information, but did not get the code line numbers and processes why the information is not good. We can have all log in one place for the TLS implementation, and tell the log reader to analysis the configuration by himself, but the style was not chosen because more debug information was expected to carry in the log. I think Weibing is trying to achieve a balance here - the current TLS logs are quite verbose. I'm not sure if we need verbose SSLServerSocket info for every server socket operation. The current approach is to print the SSLServerSocket details when a handshake fails due to a ciphersuite/keyexchange config issue ------------- PR: https://git.openjdk.org/jdk/pull/9731 From coffeys at openjdk.org Tue Aug 23 20:12:45 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 23 Aug 2022 20:12:45 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v2] In-Reply-To: References: Message-ID: On Mon, 22 Aug 2022 12:52:54 GMT, Sean Mullan wrote: >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> add or remove the blank line according to the comments > > src/java.base/share/classes/sun/security/ssl/ServerHello.java line 781: > >> 779: fieldsList.add(Security.getProperty(LegacyAlgorithmConstraints.PROPERTY_TLS_LEGACY_ALGS)); >> 780: >> 781: if (!shc.negotiatedProtocol.name.equalsIgnoreCase(ProtocolVersion.TLS13.name)) { > > This check is somewhat incorrect in my opinion, just because none of the legacy algs don't apply to TLS 1.3 doesn't mean that we won't add one in the future or someone could configure it themselves. It feels like this is the wrong place to be logging about legacy/disabled suites and this should be logged only if the constraints have been applied. I would remove the logging of the legacy algs as it doesn't seem critical. Plus it doesn't make sense to only log legacy algs and not disabled algs. Looks like the TLS Legacy algs and the disabled cipher suites values are final static. I think we should remove them from this patch and open a new JBS enhancement. The new issue can log these two final values when set by the JDK -- useful values to know for debug logs. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From kdriver at openjdk.org Tue Aug 23 20:33:30 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Aug 2022 20:33:30 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v4] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: code review comments -- replace all occurences of @exception with @throws ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/05f54f80..167cb658 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=02-03 Stats: 15 lines in 2 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From xuelei at openjdk.org Tue Aug 23 21:52:39 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Tue, 23 Aug 2022 21:52:39 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 20:03:19 GMT, Sean Coffey wrote: >> So, do you want to make the log where the configuration happens? Logging in one place cannot have the accuracy debug log where the problem happens, and cannot easy the analysis of the debug. One just gets the configuration information, but did not get the code line numbers and processes why the information is not good. We can have all log in one place for the TLS implementation, and tell the log reader to analysis the configuration by himself, but the style was not chosen because more debug information was expected to carry in the log. > > I think Weibing is trying to achieve a balance here - the current TLS logs are quite verbose. I'm not sure if we need verbose SSLServerSocket info for every server socket operation. The current approach is to print the SSLServerSocket details when a handshake fails due to a ciphersuite/keyexchange config issue Thanks for the comments. I'm not sure if it is really helpful for developers to understand and debug the failure by reading the additionally dumped cipher suites and/or key exchange configuration. Given the server cipher suites TLS_AES_128_GCM_SHA256, can one really know the failure reason exactly? ------------- PR: https://git.openjdk.org/jdk/pull/9731 From kdriver at openjdk.org Tue Aug 23 23:34:27 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 23 Aug 2022 23:34:27 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v5] In-Reply-To: References: Message-ID: <0W_zpGG-6RJ3ARBvoXjGbwihVtVfEJL1eHSdx6ntIVw=.26b21dd8-27bf-41e4-8742-243ab441ec4d@github.com> > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: - move test - new test for MacSpi demo purposes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/167cb658..8fa4e15e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=03-04 Stats: 112 lines in 1 file changed: 112 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From valeriep at openjdk.org Tue Aug 23 23:59:31 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Tue, 23 Aug 2022 23:59:31 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v5] In-Reply-To: <0W_zpGG-6RJ3ARBvoXjGbwihVtVfEJL1eHSdx6ntIVw=.26b21dd8-27bf-41e4-8742-243ab441ec4d@github.com> References: <0W_zpGG-6RJ3ARBvoXjGbwihVtVfEJL1eHSdx6ntIVw=.26b21dd8-27bf-41e4-8742-243ab441ec4d@github.com> Message-ID: On Tue, 23 Aug 2022 23:34:27 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: > > - move test > - new test for MacSpi demo purposes test/jdk/com/sun/crypto/provider/Mac/Test6205692.java line 112: > 110: } > 111: } > 112: } Can remove all these and directly instantiate the dummy MacSpi object and call the public engineUpdate(ByteBuffer) method in the execute method. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Wed Aug 24 00:12:45 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 24 Aug 2022 00:12:45 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for [v2] In-Reply-To: References: Message-ID: <961symodqLori42c3f0MTOG4zXkCtVO7vPqgfQXWRFY=.f813159b-9cae-435d-96ea-2049aead1835@github.com> > Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: adding test to demonstrate exception being thrown ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9860/files - new: https://git.openjdk.org/jdk/pull/9860/files/a11d57ab..d0f62e66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9860&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9860&range=00-01 Stats: 102 lines in 1 file changed: 102 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9860.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9860/head:pull/9860 PR: https://git.openjdk.org/jdk/pull/9860 From kdriver at openjdk.org Wed Aug 24 00:12:46 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 24 Aug 2022 00:12:46 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for [v2] In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 23:05:11 GMT, Bradford Wetmore wrote: >> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: >> >> adding test to demonstrate exception being thrown > > LGTM, but needs test cases. @bradfordwetmore test added ------------- PR: https://git.openjdk.org/jdk/pull/9860 From valeriep at openjdk.org Wed Aug 24 00:15:04 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Aug 2022 00:15:04 GMT Subject: RFR: 8292739: Invalid legacy entries may be returned by Provider.getServices() call Message-ID: Invalid legacy services are screened and removed in Provider.getService(...) call. This fix is to also screen and remove the invalid legacy services when Provider.getServices() is called. Leveraged existing test case to test this particular scenario by adding one invalid legacy registration. Thanks! Valerie ------------- Commit messages: - 8292739: Invalid legacy entries may be returned by Provider.getServices() call Changes: https://git.openjdk.org/jdk/pull/9992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292739 Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/9992.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9992/head:pull/9992 PR: https://git.openjdk.org/jdk/pull/9992 From kdriver at openjdk.org Wed Aug 24 00:19:50 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 24 Aug 2022 00:19:50 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v6] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: remove unnecessary code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/8fa4e15e..80c11e48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=04-05 Stats: 16 lines in 1 file changed: 0 ins; 13 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Wed Aug 24 00:19:51 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 24 Aug 2022 00:19:51 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v5] In-Reply-To: References: <0W_zpGG-6RJ3ARBvoXjGbwihVtVfEJL1eHSdx6ntIVw=.26b21dd8-27bf-41e4-8742-243ab441ec4d@github.com> Message-ID: On Tue, 23 Aug 2022 23:55:33 GMT, Valerie Peng wrote: >> Kevin Driver has updated the pull request incrementally with two additional commits since the last revision: >> >> - move test >> - new test for MacSpi demo purposes > > test/jdk/com/sun/crypto/provider/Mac/Test6205692.java line 112: > >> 110: } >> 111: } >> 112: } > > Can remove all these and directly instantiate the dummy MacSpi object and call the public engineUpdate(ByteBuffer) method in the execute method. removed! please re-review ------------- PR: https://git.openjdk.org/jdk/pull/9859 From wetmore at openjdk.org Wed Aug 24 00:35:26 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 24 Aug 2022 00:35:26 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v6] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 00:19:50 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary code There is no "newline" at the end of the new test file. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9859 From wetmore at openjdk.org Wed Aug 24 00:43:34 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 24 Aug 2022 00:43:34 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v6] In-Reply-To: References: Message-ID: <2Uwbe4PActRzbtLy12yVTjelxoTvQ3k1Km-ucEUEm2k=.e225fb95-0eac-4a55-b0ca-cda48c5d7332@github.com> On Wed, 24 Aug 2022 00:19:50 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > remove unnecessary code Minor nits, don't need to be rereviewed after fixing. test/jdk/com/sun/crypto/provider/Mac/Test6205692.java line 33: > 31: import jdk.test.lib.Utils; > 32: > 33: import javax.crypto.Mac; Mac and Provider no longer needed. test/jdk/com/sun/crypto/provider/Mac/Test6205692.java line 79: > 77: > 78: @Override > 79: protected void engineInit(Key key, AlgorithmParameterSpec params) throws InvalidKeyException, InvalidAlgorithmParameterException { More than 80 chars ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.org/jdk/pull/9859 From kdriver at openjdk.org Wed Aug 24 00:57:06 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Wed, 24 Aug 2022 00:57:06 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v7] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/80c11e48..f41dd862 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=05-06 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From duke at openjdk.org Wed Aug 24 05:39:37 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 24 Aug 2022 05:39:37 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v24] In-Reply-To: References: Message-ID: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9159/files - new: https://git.openjdk.org/jdk/pull/9159/files/6d833913..df47b57e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=22-23 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9159.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9159/head:pull/9159 PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Wed Aug 24 05:39:39 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 24 Aug 2022 05:39:39 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v23] In-Reply-To: <5cygolC_DgYCDjcbFF2UhLrPyR3XAagyibXLVOebRpU=.ac5afa8e-4297-43a8-902b-09d3dab3690e@github.com> References: <5cygolC_DgYCDjcbFF2UhLrPyR3XAagyibXLVOebRpU=.ac5afa8e-4297-43a8-902b-09d3dab3690e@github.com> Message-ID: On Tue, 23 Aug 2022 13:06:12 GMT, Weijun Wang wrote: >> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment for import statements > > test/jdk/javax/security/auth/login/LoginContext/OptionalJaas/UnixNTPlatform.java line 51: > >> 49: >> 50: System.out.println("config is : \n"+config); >> 51: Files.writeString(java.nio.file.Path.of("cross-platform"), config.toString()); > > No need to write full package name here then. Done. Thank you! ------------- PR: https://git.openjdk.org/jdk/pull/9159 From duke at openjdk.org Wed Aug 24 05:47:49 2022 From: duke at openjdk.org (David Schlosnagle) Date: Wed, 24 Aug 2022 05:47:49 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:48:10 GMT, Eric Caspole wrote: > Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 49: > 47: @OutputTimeUnit(TimeUnit.MILLISECONDS) > 48: @Warmup(iterations = 15) > 49: @Measurement(iterations = 15) Given the recent work to reduce microbenchmark runtimes, does this actually need this many iterations and time to get a stable microbenchmark? test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 73: > 71: + " intField++;" > 72: + " }" > 73: + "}"); Curious why copying to new String? Is this to try to avoid string deduplication? Could it be simplified? Suggestion: return "public class B" + count + " {" + " static int intField;" + " public static void compiledMethod() { " + " intField++;" + " }" + "}"; ------------- PR: https://git.openjdk.org/jdk/pull/9950 From wetmore at openjdk.org Wed Aug 24 13:26:34 2022 From: wetmore at openjdk.org (Bradford Wetmore) Date: Wed, 24 Aug 2022 13:26:34 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v7] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 00:57:06 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > review comments Newline is still missing at the end of the file, and CSR needs to be approved. Will sponsor after that is fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9859 From weijun at openjdk.org Wed Aug 24 13:28:48 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Aug 2022 13:28:48 GMT Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule is not logged [v24] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 05:39:37 GMT, Jayashree Huttanagoudar wrote: >> Could you please review the changes? >> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug > > Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9159 From weijun at openjdk.org Wed Aug 24 14:38:21 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 24 Aug 2022 14:38:21 GMT Subject: RFR: 8292739: Invalid legacy entries may be returned by Provider.getServices() call In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 00:07:21 GMT, Valerie Peng wrote: > Invalid legacy services are screened and removed in Provider.getService(...) call. This fix is to also screen and remove the invalid legacy services when Provider.getServices() is called. > > Leveraged existing test case to test this particular scenario by adding one invalid legacy registration. > > Thanks! > Valerie Marked as reviewed by weijun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9992 From duke at openjdk.org Wed Aug 24 15:51:40 2022 From: duke at openjdk.org (Jayashree Huttanagoudar) Date: Wed, 24 Aug 2022 15:51:40 GMT Subject: Integrated: 8215916: The failure reason of an optional JAAS LoginModule is not logged In-Reply-To: References: Message-ID: On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar wrote: > Could you please review the changes? > This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug This pull request has now been integrated. Changeset: 3c2289d6 Author: Jayashree Huttanagoudar Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/3c2289d65157fca3f303d2fe703b31ef53b2f5bf Stats: 81 lines in 2 files changed: 79 ins; 1 del; 1 mod 8215916: The failure reason of an optional JAAS LoginModule is not logged Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/9159 From valeriep at openjdk.org Wed Aug 24 18:27:22 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Aug 2022 18:27:22 GMT Subject: Integrated: 8292739: Invalid legacy entries may be returned by Provider.getServices() call In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 00:07:21 GMT, Valerie Peng wrote: > Invalid legacy services are screened and removed in Provider.getService(...) call. This fix is to also screen and remove the invalid legacy services when Provider.getServices() is called. > > Leveraged existing test case to test this particular scenario by adding one invalid legacy registration. > > Thanks! > Valerie This pull request has now been integrated. Changeset: 14623c60 Author: Valerie Peng URL: https://git.openjdk.org/jdk/commit/14623c6087105a4228ff190e9e27372729b2bc4b Stats: 19 lines in 2 files changed: 15 ins; 0 del; 4 mod 8292739: Invalid legacy entries may be returned by Provider.getServices() call Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/9992 From John.Gray at entrust.com Wed Aug 24 20:12:23 2022 From: John.Gray at entrust.com (John Gray) Date: Wed, 24 Aug 2022 20:12:23 +0000 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> Message-ID: Just catching up on emails. I agree about PKCS11 as well, but vast amounts of people use it and I don?t think it is going away anytime soon. This is a great discussion. So Michael, I think you are saying we should be able to use a combination of KeyAgreement and Cipher to implement a KEM in the JCA. I think that works in practice for any existing Key Agreement or Cipher (that is what we essentially use in our IETF draft for turning existing Key agreement or Cipher algorithms into a KEM). https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ However, for a pure KEM like Kyber I don?t think you can just assume you will be able to break up the encapsulation() procedure which returns a CipherText and Shared-Secret given a Kyber public key. It defines the encapsulation and decapsulation operations (see https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/). A Cipher encrypt can?t model the Encapsulation operation as it just returns a byte[]. I suppose a Cipher Decrypt could model the Decapsulation() operation with the result being the shared secret, but that is only half the picture?. Kyber has internal functions that do encrypt and decrypt like operations which could be modeled as a Cipher in JCA (but the message would have to be some type of specially formatted structure containing the m and cpaSeed values, or if a keywrap the public key would have to be structured along with those required values). So even if we did that, how do you propose the rest of the Kyber KEM operations fit in the current Java JCA? It seems you would need to somehow split up the components of the algorithm across different parts of the JCA and would it be possible to hide the complexity as simply as adding a KEM JCA object type with an encapsulate() method and a decapsulate() method? From https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ 11.2. Encapsulation Kyber encapsulation takes a public key and a 32-octet seed and deterministically generates a shared secret and ciphertext for the public key as follows. 1. Compute 1. m = H(seed) 2. (Kbar, cpaSeed) = G(m || H(pk)) 3. cpaCipherText = Kyber.CPAPKE.Enc(m, publicKey, cpaSeed) 2. Return 1. cipherText = cpaCipherText 2. sharedSecret = KDF(KBar || H(cpaCipherText)) 11.3. Decapsulation Kyber decapsulation takes a private key and a cipher text and returns a shared secret as follows. 1. Split privateKey into 1. A 12*k*n/8-octet cpaPrivateKey 2. A 12*k*n/8+32-octet cpaPublicKey 3. A 32-octet h 4. A 32-octet z 2. Compute 1. m2 = Kyber.CPAPKE.Dec(cipherText, cpaPrivateKey) 2. (KBar2, cpaSeed2) = G(m2 || h) 3. cipherText2 = Kyber.CPAPKE.Enc(m2, cpaPublicKey, cpaSeed2) 4. K1 = KDF(KBar2 || H(cipherText)) 5. K2 = KDF(z || H(cipherText)) 3. In constant-time, set K = K1 if cipherText == cipherText2 else set K = K2. 4. Return 1. sharedSecret = K It can *sort of* fit with a KeyAgreement if you do this, but its kludgy: On sending side: KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); Kem.init(null, KEMparameters) - I?m generating the CipherText and shared-secret for 1 other person, I don?t have their private key and its not multi-party KEMCipherTextKey = Kem.doPhase(Key kemPublicKey, true) byte[] sharedSecret = generateSecret() The KEMCipherTextKey contains the CipherText that just happens to implements the Key interface. It is very weird, but we something to carry the cipher text. Send KEMCipherTextKey to the receiver: On receiving side: KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); Kem.init(KEMCipherTextKey, KEMParameters); -> The CipherTExt is the KEMCipherTExtKey null = Kem.doPhase(KemPrivateKey, true) -> Shared secret is generated from CipherText and PrivateKey, but a Key object is not returned byte[] sharedSecret = generateSecret() So it can work, but it is kludgy. The placement of the keys could be reversed (the public and private keys could be passed in via init, then null in the first doPhase, and the CipherTextKey in the second doPhase. I don?t know which is better as it could work either way. This just shows how it doesn?t fit cleanly? In the openSSL-OQS port which is in C, they have KEM?s defined simply as follows: https://github.com/open-quantum-safe/liboqs/blob/main/src/kem/kem.h Which follows which NIST outlines in https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf Obviously we can make it better in Java while keeping it simple. For example: KEMEncapsulation = KEM.encapsulate(publicKey); byte[] ss = KEM.decapsulate(privateKey, CipherText); KEMEncapsualtion simply contains the shared secret (ss) and CipherText? Or to fit with init() pattern the rest of them use: KEM.init(publicKey); KEMEncapsulation = KEM.encapsulate() byte[] cipherText = KEMEncapsulation.getCipherText(); And then KEM.init(privateKey); byte[] ss = KEM.decapsulate(cipherText) or maybe even better: KEM.init(publicKey); byte[] cipherText = KEM.encapsulate() byte[] sharedSecret = KEM.getSharedSecret() And then KEM.init(privateKey); byte[] ss = KEM.decapsulate(cipherText) Cheers, John Gray From: David Hook Sent: Sunday, August 21, 2022 10:51 PM To: Michael StJohns ; John Gray Cc: security-dev at openjdk.org Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ I'd have to agree about PKCS 11. One more thing about the PQC KEMs - the KDF step is built in. As you've mentioned, previously there's been a lot of possible combinations with key agreement, with PQC KEMs this has changed (of course, you could still use a KDF too, but the original reasons for doing so no longer apply). Regards, David On 21/8/22 13:52, Michael StJohns wrote: On 8/20/2022 2:08 PM, David Hook wrote: Hi Michael, I don't know anything about bureaucrats, I am an engineer. You may need to consult someone else on bureaucrats. I apologize for my apparent deficiencies in this area, but would you mind explaining how Cipher.wrap() is either supposed to take a public key and create an encapsulation based on it and return a secret key implicitly in one clean move, or why it even makes sense to do so. The method was never conceived as providing the functionality for what a KEM actually does, and when I did the initial PKCS11 implementation at Eracom in the late 90's and the team at Sun added the wrap/unwrap functions to support it, this is definitely not was intended either - it was for explicit key wrapping based on the key that was passed to Cipher.init(). First - PKCS11 is a 40 year old API that probably needs to be retired. I spent the better part of 2 years working with the PKCS11 Oasis group trying to get them to properly support master secrets and KDFs and failed utterly. You should not use PKCS11 as an example that the JCE should use as a goal. At the base, a java class is a collection of objects. A Cipher object Let's build a non-parameterized ECIES-KEM which implicitly uses AES256 bit keys to key a GCM cipher, and a KDF based on SP800-108 counter mode with SHA256 as the underlying hash, and with a well known label and context for the KDF since there is a new key for every wrap. 1) Implement CipherSpi - public class EciesKemCipher extends CipherSpi { private KeyAgreement ka; private Cipher gcm; private KeyPair kp; private KeyPairGenerator kg; EciesKemCipher() { ka = KeyAgreement.getInstance("ECDH"); kpg = KeyPairGenerator.getInstance ("EC"); gcm = Cipher.getInstance ("AES/GCM/NoPadding"); } // implement a single example @override protected void engineInit (int opMode, Key key, SecureRandom dontcare) { switch (opMode) { Cipher.MODE_WRAP: initWrap((ECPublicKey) key); break; default: // unimpl } } private void initWrap (ECPublicKey k) { ECParameterSpec spec = k.getParams(); kpg.initialize(spec); kp = kpg.genKeyPair(); ka.init (kp.getPrivate()); ka.doPhase (k, true); byte[] sharedSecret = ka.generateSecret(); byte[] keyStream = kdf(sharedSecret, 32 + 12); // output 44 bytes for Key and IV SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, 32, "AES"); IvParameterSpec gcmIv = new IVParameterSpec(keyStream, 32, 12); gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); // all ready to go } protected byte[] engineWrap (Key k) { ByteBuffer outData = ByteBuffer.allocate (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; // Place a copy of the ephemeral public key I generated in init here for the use of the receiver. outData.put (kp.getEncoded()); // One s outData.put (gcm.doFinal(k.getEncoded()); outData.flip(); byte[] result = outdata.remaining(); outData.get(result); // kp = null; clear cipher if it hasn't already been cleared, clear ka if necessary (e.g. un-init) return result; } ... and unwrap and kdf function } 2) Implement a provider and add the above. On BC's part, we've already implemented RFC 5990/SP 800-56B in Java and the experience has, at best, been awkward. The new algorithms have moved awkward to inappropriate. With the new algorithms, there's no longer only one case of this, it's not an outlier, there should be a general way of supporting KEMs in the API that doesn't involve over engineering KeyGenerator and Cipher. There's a big difference between the API and your underlying implementation. Everything you want to do can be done using the current APIs. As I said before, Cipher.wrap/unwrap are the appropriate APIs for this as they meet the contract requirements you need. Most Ciphers require some extra data -e.g. IVs - that have to either be carried or implicitly derived. In this case, what needs to be carried in addition to the encrypted key material is at least the ephemeral public key the wrapper creates. I used a very simple encoding scheme above and this assumes that both ends know exactly what "ECIES-KEM" means. Obviously, there are 100s of possible combinations of parameters and KDFs and key wrap algorithms. What I would suggest is heading over to LAMPS at the IETF and proposing a data encoding scheme for carrying the parameters. Once you have that done, then come here and map JCE names against parameter sets to close the loop. It won't require an API change. I work with a team that has had to implement all of them and had to make them fit into the JCA. We have done so. Like John, I am simply relaying our experience. In about 18 months these algorithms are going to become mandatory, what all of us think is irrelevant. We, for our part, already have a solution, but we both realize it's not "the solution" - we recognize that the JVM is uniquely positioned to provide leadership on this and provide a universal way of doing it. Then suggest an API and we'll start knocking it around. I personally don't think its necessary at this time and will add to API bloat. Of course, if it's felt that these algorithms should be ignored, it's not my place to revolt, although I do feel obliged to argue. I will simply try and do the best by my users, as I have no doubt will John. Both of us have simply offered our comments in good faith and to alert the community that things have changed and that with these new algorithms there is room for a new approach. The ambiguity about how these algorithms can be implemented and the excessive need to fallback on propritary classes for them does suggest that there are some additions to the JCA which would help. I appreciate to understand this statement does involve actually understanding what these algorithms do and may require some additional reading. As I said, I'm an engineer, my users will be able to use these algorithms properly, my team will ensure that, as I have no doubt will John's. What John and myself, apparently mistakenly, care about is that our users should also be able to use these algorithms portably. Are you saying portability is no longer a consideration? I have no idea where you got that idea. Regards, David On 21/8/22 02:23, Michael StJohns wrote: Hi David/John - I would submit that you're trying too hard to make your life simple! :-) Cipher.wrap/unwrap are the correct methods. For example: Cipher kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); The "opaqueEncapsulatedKey" would contain the data needed by the unwrap function - specifically a) the ecies ephemeral public key, b) the fact that the derived key is a GCM key of length 128 and that the GCM tag is 64 bytes long, c) the KDF, d) (optional) any mixins other than defaults required by the KDF - which would be passed in a parameter blob during init. Cipher would NOT return the underlying generated secret used to wrap the key. Just the public part of the key pair used to do the ECDH operation against the passed in public key. In the RSA case, the wrapped encrypting secret would be an opaque data blob and would be part of the data passed to the unwrap function. If you want a key generated for other purposes, then the right thing is using a KDF and a Key agreement function in tandem. Strangely the KDF appears in the javacard API for 3.1, but not in the JCE/JDK API. "What's the difference between a bureaucrat and an engineer? A bureaucrat takes small solvable pieces and combines them into one insoluble mass." In this case, Java provides a number of flexible primitives that can be combined as needed. In this case, the underlying Cipher implementation would wrap key agreement and kdf and cipher (GCM) instances. It should return UnsupportedOperationException for all operations execept wrap/unwrap and the appropriate init methods. Later, Mike On 8/19/2022 6:38 PM, David Hook wrote: Hi Mike, KEMs can be used for key wrapping - we've actually implemented support for this too. But they are not actually key wrapping ciphers. Here's a simple example of using Kyber for key wrapping in BC: SecretKey key = new SecretKeySpec(keyBytes, "AES"); w1.init(Cipher.WRAP_MODE, kp.getPublic(), new KEMParameterSpec("AES-KWP")); byte[] data = w1.wrap(key); Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new KEMParameterSpec("AES-KWP")); Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); The behavior in this case is in line with what is given in RFC 5990 for the RSA KEM. How it works is by using the key generated by the KEM to create an AES-KWP key, which is then used to wrap keyBytes. The shortcoming is it means you have to generate the secret key separately. This is the problem though - a KEM can actually be used to generate a secret key for other purposes. For example, where someone is trying to implement a hybrid KAS scheme. But there is currently no mechanism in the Java APIs for being able to take advantage of this directly, hence our use of the KeyGenerator class and other people's attempts to make use of the KeyAgreement class. The Cipher.wrap() returns a byte[] - to be used with a KEM for secret generation it would also have to return the generated secret (I would probably also argue that passing a public key to wrap in order to generate an encapsulation of a generated encrypted secret was not the correct use of the API either, but the fact remains a byte[] is not really going to cut it). If you have any further questions, please feel free to ask. For what it is worth, I have been developing providers for the JCE/JCA since the late 90's and am actually one of the people responsible for the introduction of the existing wrap/unwrap API in the Cipher class. Thanks, David On 20/8/22 07:53, Mike StJohns wrote: Hi This implemented as part of Javax.crypto.Cipher. See the Java doc for the wrap and unwrap methods. Mike Sent from my iPad On Aug 19, 2022, at 12:56, John Gray wrote: ? We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. ss, ct := encapsulate(PublicKey) ss := decapsulate(PrivateKey, ct) -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) -ct is a Cipher Text (a byte array would make sense) -Public and Private Keys would use the regular public and private key interface. -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). Then algorithms could be registered in providers as usual: put("KEM.Kyber","com.blah.Kyber") put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... Cheers, John Gray Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.org Wed Aug 24 20:31:03 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Aug 2022 20:31:03 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions Message-ID: Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. Thanks in advance for review~ ------------- Commit messages: - 6447816: Provider filtering (getProviders) is not working with OR'd conditions Changes: https://git.openjdk.org/jdk/pull/10008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6447816 Stats: 238 lines in 2 files changed: 169 ins; 38 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008 PR: https://git.openjdk.org/jdk/pull/10008 From duke at openjdk.org Wed Aug 24 20:41:34 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 24 Aug 2022 20:41:34 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 21:48:46 GMT, Xue-Lei Andrew Fan wrote: >> I think Weibing is trying to achieve a balance here - the current TLS logs are quite verbose. I'm not sure if we need verbose SSLServerSocket info for every server socket operation. The current approach is to print the SSLServerSocket details when a handshake fails due to a ciphersuite/keyexchange config issue > > Thanks for the comments. I'm not sure if it is really helpful for developers to understand and debug the failure by reading the additionally dumped cipher suites and/or key exchange configuration. Given the server cipher suites TLS_AES_128_GCM_SHA256, can one really know the failure reason exactly? The cipher suite enabled on the server side is not logged when "no common in cipher suites" error is thrown. Hope the developer could find the difference in the cipher suites between client and server. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From ecaspole at openjdk.org Wed Aug 24 20:45:29 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Wed, 24 Aug 2022 20:45:29 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v2] In-Reply-To: References: Message-ID: > Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: Updates from reviewers comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9950/files - new: https://git.openjdk.org/jdk/pull/9950/files/63e61fe9..a77e6a5d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9950&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9950&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9950.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9950/head:pull/9950 PR: https://git.openjdk.org/jdk/pull/9950 From ecaspole at openjdk.org Wed Aug 24 20:45:32 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Wed, 24 Aug 2022 20:45:32 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 05:35:54 GMT, David Schlosnagle wrote: >> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates from reviewers comments > > test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 49: > >> 47: @OutputTimeUnit(TimeUnit.MILLISECONDS) >> 48: @Warmup(iterations = 15) >> 49: @Measurement(iterations = 15) > > Given the recent work to reduce microbenchmark runtimes, does this actually need this many iterations and time to get a stable microbenchmark? You are right, I changed it back to throughput mode and 5/2. Also the main work is in the Setup and it can be done per Trial, not per Iteration. > test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 73: > >> 71: + " intField++;" >> 72: + " }" >> 73: + "}"); > > Curious why copying to new String? Is this to try to avoid string deduplication? Could it be simplified? > > Suggestion: > > return "public class B" + count + " {" > + " static int intField;" > + " public static void compiledMethod() { " > + " intField++;" > + " }" > + "}"; I agree on this, chnaged. ------------- PR: https://git.openjdk.org/jdk/pull/9950 From valeriep at openjdk.org Wed Aug 24 21:51:37 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Wed, 24 Aug 2022 21:51:37 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v7] In-Reply-To: References: Message-ID: <5LoF0RR8Fsp7JQOo2klC_DHXE9gbDpyFgn-mPapn63U=.aafc6af7-16bb-4399-a3c1-2ad3d1ad49cf@github.com> On Wed, 24 Aug 2022 00:57:06 GMT, Kevin Driver wrote: >> add @exception message to indicate an NPE might be thrown when the input parameter is null > > Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: > > review comments Marked as reviewed by valeriep (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9859 From xuelei at openjdk.org Wed Aug 24 22:04:34 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Wed, 24 Aug 2022 22:04:34 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: Message-ID: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> On Wed, 24 Aug 2022 20:38:07 GMT, Weibing Xiao wrote: >> Thanks for the comments. I'm not sure if it is really helpful for developers to understand and debug the failure by reading the additionally dumped cipher suites and/or key exchange configuration. Given the server cipher suites TLS_AES_128_GCM_SHA256, can one really know the failure reason exactly? > > The cipher suite enabled on the server side is not logged when "no common in cipher suites" error is thrown. Hope the developer could find the difference in the cipher suites between client and server. Even the cipher suites are the same between client and server, it may still fail with "no common in cipher suites" error. The cause of the bug is not only about "no common in cipher suites" between client and server, but also about the cases that the server cannot negotiate any of the common cipher suites because of other facts. If the cause is only about ""no common in cipher suites", I don't think we need a fix as the message has been tell the story. It is not objected that cipher suite should not be logged. The question raised here is about when and how to log the cipher suite, and how to make the log easier to read and easier to debug. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From valeriep at openjdk.org Thu Aug 25 02:59:42 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 02:59:42 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: Message-ID: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> > Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. > > Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: update test to use SHA256 and DSA throughout. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10008/files - new: https://git.openjdk.org/jdk/pull/10008/files/86ee729e..d8679caf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008 PR: https://git.openjdk.org/jdk/pull/10008 From franco.nieddu at iaik.tugraz.at Thu Aug 25 06:32:50 2022 From: franco.nieddu at iaik.tugraz.at (Franco Nieddu) Date: Thu, 25 Aug 2022 08:32:50 +0200 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> Message-ID: Hi David, Michael, and John, and everyone else! I will give my two cents to the Cipher/KEM topic and add on the latest mail from John. For why this topic is interesting to me, I work at the TU Graz, where we have developed the IAIK-JCE Provider since the beginning of the 2000s. Anticipating the end of NIST's PQC, we started implementing the third- round KEMs approximately a year ago. I have to agree with David and John. KEMs and Ciphers are strictly different. To map KEMs operations to the existing API, we would be forced to break a lot of the contracts/definitions of multiple classes, but at the bare minimum from the Cipher.wrap(Key) method itself. Moving forward, KEMs will rise in popularity, and we should reduce confusion for developers using our libraries. It may be possible to use e.g., McEliece as an asymmetric cipher, but I would not want my users to start using McEliece in such a way. Clear segregation would help prevent this. The other option will be to throw exceptions if a caller provides something different than WRAP_MODE in Cipher.init(), breaking more contracts. Furthermore, the Cipher.unwrap(byte[], String, int) method is tedious to use, but maybe this is just me... In his last message, John showed, better than I could, that the KeyAgreement classes only fit with great difficulty. The API mapping just does not work, and there is no denying that. Nevertheless, the biggest issue I have (if we ignore all the broken contracts for a moment) is the serialization/deserialization of the ciphertext-secret pair. The Cipher.wrap() method simply does not allow to return both values. Concating the two values into a single byte array just begs for incompatibility between implementations. Another option to return the ciphertext and the secret to the caller is by defining a new class/interface like: public final class KEMSecret implements Key { private byte[] secret_; public final void setSecret(byte[] secret) { this.secret_ = secret; } public final byte[] getSecret() { return this.secret; } } Then enforce that for all KEMs, the Cipher.wrap() method uses this KEMSecret as parameter, breaking another contract, as the KEMSecret IS NOT a key (it can be but is not limited to). Our implementation for the moment looks something like this: public abstract class KeyEncapsulationMechanismSpi { //some init methods.... protected abstract void engineDeriveKey(byte[] output, byte[]... input) throws DigestException; protected abstract byte[] engineEncapsule(byte[] k) throws InvalidKeyException, DigestException; protected abstract void engineDecapsule(byte[] c, byte[] k) throws InvalidKeyException, DigestException; } The engineDeriveKey() method is a call to a KDF (for the PQC always SHAKE), where output is the derived key, and the varargs depict the input to the KDF. At least in McEliece, there are multiple calls to the KDF; therefore, adding a separate engine method seemed reasonable. Furthermore, it is possible to plug in different KDFs for the same KEM instance. Taking inspiration from the Cipher classes, we could do something like: KEM.getInstance("Kyber/SHAKE128") or KEM.getInstance("Kyber/KDF3") At the moment, this is not necessary, but already defining a modular interface should at least be considered. engineEncapsule() returns the ciphertext of the encap operation. Additionally, the implementation fills the provided byte[] with the secret. The secret produced by KEMs is not strictly limited in size; therefore, it seemed appropriate to let the caller decide the size of the byte[]. engineDecapsule() is the inverse of engineEncapsule(). I am, of course, open to discussions regarding the actual implementation, e.g. returning the result as some kind of EncapsulatedKEMData as suggested by John, but I see the necessity of adding KEM classes to the security API. To close this already long message, something about bureaucrats. Bureaucrats, at least in my country, are fond of the status quo. Luckily, we are not bureaucrats and are permitted to improve a barely working solution. Cheers, Franco On Wed, 2022-08-24 at 20:12 +0000, John Gray wrote: > Just catching up on emails. > > I agree about PKCS11 as well, but vast amounts of people use it and I > don?t think it is going away anytime soon. > > This is a great discussion. > > So Michael, I think you are saying we should be able to use a > combination of KeyAgreement and Cipher to implement a KEM in the > JCA. I think that works in practice for any existing Key Agreement > or Cipher (that is what we essentially use in our IETF draft for > turning existing Key agreement or Cipher algorithms into a KEM). > https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > However, for a pure KEM like Kyber I don?t think you can just assume > you will be able to break up the encapsulation() procedure which > returns a CipherText and Shared-Secret given a Kyber public key. > It defines the encapsulation and decapsulation operations (see > https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/). A > Cipher encrypt can?t model the Encapsulation operation as it just > returns a byte[]. I suppose a Cipher Decrypt could model the > Decapsulation() operation with the result being the shared secret, > but that is only half the picture?. Kyber has internal > functions that do encrypt and decrypt like operations which could be > modeled as a Cipher in JCA (but the message would have to be some > type of specially formatted structure containing the m and cpaSeed > values, or if a keywrap the public key would have to be structured > along with those required values). So even if we did that, how do > you propose the rest of the Kyber KEM operations fit in the current > Java JCA? It seems you would need to somehow split up the > components of the algorithm across different parts of the JCA and > would it be possible to hide the complexity as simply as adding a KEM > JCA object type with an encapsulate() method and a decapsulate() > method? > > From https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ > > 11.2. Encapsulation > > Kyber encapsulation takes a public key and a 32-octet seed and > deterministically generates a shared secret and ciphertext for the > public key as follows. > > 1. Compute > > 1. m = H(seed) > > 2. (Kbar, cpaSeed) = G(m || H(pk)) > > 3. cpaCipherText = Kyber.CPAPKE.Enc(m, publicKey, cpaSeed) > > 2. Return > > 1. cipherText = cpaCipherText > > 2. sharedSecret = KDF(KBar || H(cpaCipherText)) > > > 11.3. Decapsulation > > Kyber decapsulation takes a private key and a cipher text and > returns > a shared secret as follows. > > 1. Split privateKey into > > 1. A 12*k*n/8-octet cpaPrivateKey > > 2. A 12*k*n/8+32-octet cpaPublicKey > > 3. A 32-octet h > > 4. A 32-octet z > > 2. Compute > > 1. m2 = Kyber.CPAPKE.Dec(cipherText, cpaPrivateKey) > > 2. (KBar2, cpaSeed2) = G(m2 || h) > > 3. cipherText2 = Kyber.CPAPKE.Enc(m2, cpaPublicKey, cpaSeed2) > > 4. K1 = KDF(KBar2 || H(cipherText)) > > 5. K2 = KDF(z || H(cipherText)) > > 3. In constant-time, set K = K1 if cipherText == cipherText2 else > set K = K2. > > 4. Return > > 1. sharedSecret = K > > > > It can *sort of* fit with a KeyAgreement if you do this, but its > kludgy: > > On sending side: > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > Kem.init(null, KEMparameters) - I?m generating the CipherText and > shared-secret for 1 other person, I don?t have their private key and > its not multi-party > > KEMCipherTextKey = Kem.doPhase(Key kemPublicKey, true) > byte[] sharedSecret = generateSecret() > > > The KEMCipherTextKey contains the CipherText that just happens to > implements the Key interface. It is very weird, but we something to > carry the cipher text. > > Send KEMCipherTextKey to the receiver: > > On receiving side: > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > Kem.init(KEMCipherTextKey, KEMParameters); -> The CipherTExt is > the KEMCipherTExtKey > null = Kem.doPhase(KemPrivateKey, true) -> Shared secret is > generated from CipherText and PrivateKey, but a Key object is not > returned > byte[] sharedSecret = generateSecret() > > > So it can work, but it is kludgy. The placement of the keys could > be reversed (the public and private keys could be passed in via init, > then null in the first doPhase, and the CipherTextKey in the second > doPhase. I don?t know which is better as it could work either > way. This just shows how it doesn?t fit cleanly? > > > > In the openSSL-OQS port which is in C, they have KEM?s defined simply > as follows: > https://github.com/open-quantum-safe/liboqs/blob/main/src/kem/kem.h > > Which follows which NIST outlines in > https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf > > > Obviously we can make it better in Java while keeping it simple. For > example: > > KEMEncapsulation = KEM.encapsulate(publicKey); > byte[] ss = KEM.decapsulate(privateKey, CipherText); > > KEMEncapsualtion simply contains the shared secret (ss) and > CipherText? > > > Or to fit with init() pattern the rest of them use: > > KEM.init(publicKey); > KEMEncapsulation = KEM.encapsulate() > > byte[] cipherText = KEMEncapsulation.getCipherText(); > > And then > KEM.init(privateKey); > byte[] ss = KEM.decapsulate(cipherText) > > or maybe even better: > KEM.init(publicKey); > byte[] cipherText = KEM.encapsulate() > byte[] sharedSecret = KEM.getSharedSecret() > > And then > KEM.init(privateKey); > byte[] ss = KEM.decapsulate(cipherText) > > > Cheers, > > John Gray > > > > > From: David Hook > Sent: Sunday, August 21, 2022 10:51 PM > To: Michael StJohns ; John Gray < > John.Gray at entrust.com> > Cc: security-dev at openjdk.org > Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) > architecture being proposed for the JCA? > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and > know the content is safe. > > I'd have to agree about PKCS 11. > > One more thing about the PQC KEMs - the KDF step is built in. As > you've mentioned, previously there's been a lot of possible > combinations with key agreement, with PQC KEMs this has changed (of > course, you could still use a KDF too, but the original reasons for > doing so no longer apply). > > Regards, > > David > > On 21/8/22 13:52, Michael StJohns wrote: > > On 8/20/2022 2:08 PM, David Hook wrote: > > > Hi Michael, > > > > > > I don't know anything about bureaucrats, I am an engineer. You > > > may need to consult someone else on bureaucrats. > > > I apologize for my apparent deficiencies in this area, but would > > > you mind explaining how Cipher.wrap() is either supposed to take > > > a public key and create an encapsulation based on it and return a > > > secret key implicitly in one clean move, or why it even makes > > > sense to do so. The method was never conceived as providing the > > > functionality for what a KEM actually does, and when I did the > > > initial PKCS11 implementation at Eracom in the late 90's and the > > > team at Sun added the wrap/unwrap functions to support it, this > > > is definitely not was intended either - it was for explicit key > > > wrapping based on the key that was passed to Cipher.init(). > > > > > > > First - PKCS11 is a 40 year old API that probably needs to be > > retired. I spent the better part of 2 years working with the > > PKCS11 Oasis group trying to get them to properly support master > > secrets and KDFs and failed utterly. You should not use PKCS11 as > > an example that the JCE should use as a goal. > > > > > > > > At the base, a java class is a collection of objects. A Cipher > > object > > > > Let's build a non-parameterized ECIES-KEM which implicitly uses > > AES256 bit keys to key a GCM cipher, and a KDF based on SP800-108 > > counter mode with SHA256 as the underlying hash, and with a well > > known label and context for the KDF since there is a new key for > > every wrap. > > > > 1) Implement CipherSpi - > > > > public class EciesKemCipher extends CipherSpi { > > > > private KeyAgreement ka; > > private Cipher gcm; > > private KeyPair kp; > > private KeyPairGenerator kg; > > > > EciesKemCipher() { > > ka = KeyAgreement.getInstance("ECDH"); > > kpg = KeyPairGenerator.getInstance ("EC"); > > gcm = Cipher.getInstance ("AES/GCM/NoPadding"); > > > > } > > > > // implement a single example > > > > @override > > protected void engineInit (int opMode, Key key, SecureRandom > > dontcare) { > > > > switch (opMode) { > > Cipher.MODE_WRAP: > > initWrap((ECPublicKey) key); > > break; > > default: > > // unimpl > > } > > } > > > > private void initWrap (ECPublicKey k) { > > > > ECParameterSpec spec = k.getParams(); > > kpg.initialize(spec); > > kp = kpg.genKeyPair(); > > ka.init (kp.getPrivate()); > > ka.doPhase (k, true); > > byte[] sharedSecret = ka.generateSecret(); > > > > byte[] keyStream = kdf(sharedSecret, 32 + 12); // output > > 44 bytes for Key and IV > > SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, > > 32, "AES"); > > IvParameterSpec gcmIv = new IVParameterSpec(keyStream, > > 32, 12); > > > > gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); > > // all ready to go > > } > > > > > > protected byte[] engineWrap (Key k) { > > > > ByteBuffer outData = ByteBuffer.allocate > > (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; > > > > // Place a copy of the ephemeral public key I generated > > in init here for the use of the receiver. > > outData.put (kp.getEncoded()); > > // One s > > outData.put (gcm.doFinal(k.getEncoded()); > > > > outData.flip(); > > byte[] result = outdata.remaining(); > > > > outData.get(result); > > // kp = null; clear cipher if it hasn't already been > > cleared, clear ka if necessary (e.g. un-init) > > > > return result; > > } > > > > ... and unwrap and kdf function > > } > > > > > > > > 2) Implement a provider and add the above. > > > > > > > > > On BC's part, we've already implemented RFC 5990/SP 800-56B in > > > Java and the experience has, at best, been awkward. The new > > > algorithms have moved awkward to inappropriate. With the new > > > algorithms, there's no longer only one case of this, it's not an > > > outlier, there should be a general way of supporting KEMs in the > > > API that doesn't involve over engineering KeyGenerator and > > > Cipher. > > > > > > > There's a big difference between the API and your underlying > > implementation. Everything you want to do can be done using the > > current APIs. As I said before, Cipher.wrap/unwrap are the > > appropriate APIs for this as they meet the contract requirements > > you need. Most Ciphers require some extra data -e.g. IVs - that > > have to either be carried or implicitly derived. In this case, > > what needs to be carried in addition to the encrypted key material > > is at least the ephemeral public key the wrapper creates. I used > > a very simple encoding scheme above and this assumes that both ends > > know exactly what "ECIES-KEM" means. Obviously, there are 100s of > > possible combinations of parameters and KDFs and key wrap > > algorithms. What I would suggest is heading over to LAMPS at the > > IETF and proposing a data encoding scheme for carrying the > > parameters. Once you have that done, then come here and map JCE > > names against parameter sets to close the loop. It won't require > > an API change. > > > > > I work with a team that has had to implement all of them and had > > > to make them fit into the JCA. We have done so. Like John, I am > > > simply relaying our experience. In about 18 months these > > > algorithms are going to become mandatory, what all of us think is > > > irrelevant. We, for our part, already have a solution, but we > > > both realize it's not "the solution" - we recognize that the JVM > > > is uniquely positioned to provide leadership on this and provide > > > a universal way of doing it. > > > > > > > Then suggest an API and we'll start knocking it around. I > > personally don't think its necessary at this time and will add to > > API bloat. > > > > > Of course, if it's felt that these algorithms should be ignored, > > > it's not my place to revolt, although I do feel obliged to argue. > > > I will simply try and do the best by my users, as I have no doubt > > > will John. Both of us have simply offered our comments in good > > > faith and to alert the community that things have changed and > > > that with these new algorithms there is room for a new approach. > > > The ambiguity about how these algorithms can be implemented and > > > the excessive need to fallback on propritary classes for them > > > does suggest that there are some additions to the JCA which would > > > help. I appreciate to understand this statement does involve > > > actually understanding what these algorithms do and may require > > > some additional reading. > > > > > > As I said, I'm an engineer, my users will be able to use these > > > algorithms properly, my team will ensure that, as I have no doubt > > > will John's. What John and myself, apparently mistakenly, care > > > about is that our users should also be able to use these > > > algorithms portably. > > > > > > Are you saying portability is no longer a consideration? > > > > > > > I have no idea where you got that idea. > > > > > Regards, > > > > > > David > > > > > > > > > > > > On 21/8/22 02:23, Michael StJohns wrote: > > > > Hi David/John - > > > > > > > > I would submit that you're trying too hard to make your life > > > > simple! :-) > > > > > > > > Cipher.wrap/unwrap are the correct methods. > > > > > > > > For example: > > > > > > > > Cipher kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800- > > > > 108-COUNTER-SHA256"); > > > > kem.init (Cipher.WRAP_MODE, pubkey); > > > > byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); > > > > > > > > The "opaqueEncapsulatedKey" would contain the data needed by > > > > the unwrap function - specifically a) the ecies ephemeral > > > > public key, b) the fact that the derived key is a GCM key of > > > > length 128 and that the GCM tag is 64 bytes long, c) the KDF, > > > > d) (optional) any mixins other than defaults required by the > > > > KDF - which would be passed in a parameter blob during init. > > > > Cipher would NOT return the underlying generated secret used to > > > > wrap the key. Just the public part of the key pair used to do > > > > the ECDH operation against the passed in public key. In the > > > > RSA case, the wrapped encrypting secret would be an opaque data > > > > blob and would be part of the data passed to the unwrap > > > > function. > > > > > > > > If you want a key generated for other purposes, then the right > > > > thing is using a KDF and a Key agreement function in tandem. > > > > Strangely the KDF appears in the javacard API for 3.1, but not > > > > in the JCE/JDK API. > > > > > > > > "What's the difference between a bureaucrat and an engineer? A > > > > bureaucrat takes small solvable pieces and combines them into > > > > one insoluble mass." > > > > > > > > In this case, Java provides a number of flexible primitives > > > > that can be combined as needed. In this case, the underlying > > > > Cipher implementation would wrap key agreement and kdf and > > > > cipher (GCM) instances. It should return > > > > UnsupportedOperationException for all operations execept > > > > wrap/unwrap and the appropriate init methods. > > > > > > > > Later, Mike > > > > > > > > > > > > > > > > On 8/19/2022 6:38 PM, David Hook wrote: > > > > > Hi Mike, > > > > > > > > > > KEMs can be used for key wrapping - we've actually > > > > > implemented support for this too. But they are not actually > > > > > key wrapping ciphers. > > > > > > > > > > Here's a simple example of using Kyber for key wrapping in > > > > > BC: > > > > > > > > > > SecretKey key = new SecretKeySpec(keyBytes, "AES"); > > > > > > > > > > w1.init(Cipher.WRAP_MODE, kp.getPublic(), new > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > byte[] data = w1.wrap(key); > > > > > > > > > > Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); > > > > > > > > > > w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); > > > > > > > > > > The behavior in this case is in line with what is given in > > > > > RFC 5990 for the RSA KEM. How it works is by using the key > > > > > generated > > > > > by the KEM to create an AES-KWP key, which is then used to > > > > > wrap keyBytes. The shortcoming is it means you have to > > > > > generate the > > > > > secret key separately. > > > > > > > > > > This is the problem though - a KEM can actually be used to > > > > > generate a secret key for other purposes. For example, where > > > > > someone is trying to implement a hybrid KAS scheme. But there > > > > > is currently no mechanism in the Java APIs for being able to > > > > > take advantage of this directly, hence our use of the > > > > > KeyGenerator class and other people's attempts to make use of > > > > > the KeyAgreement > > > > > class. The Cipher.wrap() returns a byte[] - to be used with a > > > > > KEM for secret generation it would also have to return the > > > > > generated secret (I would probably also argue that passing a > > > > > public key to wrap in order to generate an encapsulation of a > > > > > generated encrypted secret was not the correct use of the API > > > > > either, but the fact remains a byte[] is not really going to > > > > > cut it). > > > > > > > > > > If you have any further questions, please feel free to ask. > > > > > For what it is worth, I have been developing providers for > > > > > the JCE/JCA since > > > > > the late 90's and am actually one of the people responsible > > > > > for the introduction of the existing wrap/unwrap API in the > > > > > Cipher class. > > > > > > > > > > Thanks, > > > > > > > > > > David > > > > > On 20/8/22 07:53, Mike StJohns wrote: > > > > > > Hi This implemented as part of Javax.crypto.Cipher. See > > > > > > the Java doc for the wrap and unwrap methods. > > > > > > > > > > > > Mike > > > > > > > > > > > > Sent from my iPad > > > > > > > > > > > > > On Aug 19, 2022, at 12:56, John Gray < > > > > > > > John.Gray at entrust.com> wrote: > > > > > > > > > > > > > > ? We are starting to make use of the new PQ algorithms > > > > > > > adopted by NIST for prototyping and development of > > > > > > > standards. In particular we are working on a composite > > > > > > > KEM standard: > > > > > > > See: > > > > > > > https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > > > > > > > > > > > > > However, there is no KEM interface in the JCA (which make > > > > > > > sense because these are new algorithms, although RSA-KEM > > > > > > > has been out since 2010). > > > > > > > > > > > > > > I can add one into our toolkit (and I think David may > > > > > > > have already added on into BC), but I assume at some > > > > > > > point there will be an official one added in Java and > > > > > > > likely it won't be identical to what we do even if it is > > > > > > > very close, which would cause backwards compatibility > > > > > > > pain... Perhaps we could collaborate on extending the > > > > > > > JCA to support KEM? Essentially it requires methods. > > > > > > > > > > > > > > ss, ct := encapsulate(PublicKey) > > > > > > > ss := decapsulate(PrivateKey, ct) > > > > > > > > > > > > > > -ss is a shared secret (could come back as a Java > > > > > > > SecretKey if you wanted as it would usually be used to > > > > > > > derive something like an AES afterwards) > > > > > > > -ct is a Cipher Text (a byte array would make sense) > > > > > > > -Public and Private Keys would use the regular public and > > > > > > > private key interface. > > > > > > > -An object holding the ss and ct from the encapsulate() > > > > > > > method could be returned, with accessor methods to get > > > > > > > the ss and ct. It could be called 'EncapsulatedKEMData' > > > > > > > for example. > > > > > > > > > > > > > > Likely you would want a new type of KEM crypto object > > > > > > > (like you have for Signature, MessageDigest, Cipher, Mac, > > > > > > > SecureRandom, KeyAgreement.. etc). Calling it KEM would > > > > > > > seem to make sense. ? It could also use similar > > > > > > > calling patterns and have a > > > > > > > KEM.initKEM(keypair.getPublic()) or > > > > > > > KEM.initKEM(keypair.getPrivate()), and then you would > > > > > > > just call KEM.encapsulate() or KEM.decapsulate(ct). > > > > > > > > > > > > > > Then algorithms could be registered in providers as > > > > > > > usual: > > > > > > > > > > > > > > put("KEM.Kyber","com.blah.Kyber") > > > > > > > > > > > > > > put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.co > > > > > > > mpositeKEM") > > > > > > > > > > > > > > Then the above methods (encapsulate and decapsulate) > > > > > > > could be defined in that new object type. Then we would > > > > > > > be able to make use of it and not have to worry about > > > > > > > incompatibility issues down the road... > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > John Gray > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any email and files/attachments transmitted with it are > > > > > > > confidential and are intended solely for the use of the > > > > > > > individual or entity to whom they are addressed. If this > > > > > > > message has been sent to you in error, you must not copy, > > > > > > > distribute or disclose of the information it contains. > > > > > > > Please notify Entrust immediately and delete the message > > > > > > > from your system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Franco Nieddu SIC - Software Engineer Phone: +43 (316) 873 - 5507 SIC Homepage: https://jce.iaik.tugraz.at/ IAIK Homepage: https://www.iaik.tugraz.at/ From mullan at openjdk.org Thu Aug 25 09:17:35 2022 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 Aug 2022 09:17:35 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v2] In-Reply-To: References: Message-ID: On Wed, 24 Aug 2022 20:45:29 GMT, Eric Caspole wrote: >> Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. > > Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: > > Updates from reviewers comments test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 90: > 88: for (int i = 0; i < numberOfClasses; i++) { > 89: classNames[i] = "B" + i; > 90: compiledClasses[i] = InMemoryJavaCompiler.compile(classNames[i], B(i)); Is it possible to use the existing `jdk.test.lib.compiler.InMemoryJavaCompiler` class instead of writing a new one? ------------- PR: https://git.openjdk.org/jdk/pull/9950 From ecaspole at openjdk.org Thu Aug 25 14:30:28 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Thu, 25 Aug 2022 14:30:28 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v2] In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 09:14:07 GMT, Sean Mullan wrote: >> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: >> >> Updates from reviewers comments > > test/micro/org/openjdk/bench/java/security/ProtectionDomainBench.java line 90: > >> 88: for (int i = 0; i < numberOfClasses; i++) { >> 89: classNames[i] = "B" + i; >> 90: compiledClasses[i] = InMemoryJavaCompiler.compile(classNames[i], B(i)); > > Is it possible to use the existing `jdk.test.lib.compiler.InMemoryJavaCompiler` class instead of writing a new one? It needs to be added into the benchmarks.jar, and there are already 2 copies of it in different test suites so it seems like this is how it's done. ------------- PR: https://git.openjdk.org/jdk/pull/9950 From John.Gray at entrust.com Thu Aug 25 14:49:08 2022 From: John.Gray at entrust.com (John Gray) Date: Thu, 25 Aug 2022 14:49:08 +0000 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> Message-ID: Thanks Franco, I am very familiar with the IAIK toolkit as our Entrust Java toolkit actually makes use of the IAIK ASN.1 library from a 2003 version and IAIK and Entrust used to work very closely together regarding our toolkits in the early 2000's. So I think between the 3 of us we represent a majority of the JCA cypto toolkits that exist (except for BSAFE which I have never used). So it is great to see we agree that there needs to be KEM classes added to the JCA as we have all struggled with fitting KEM into the JCA. We certainly want their to be an interoperable implementations of KEM. Franco, could you send a simple sample of doing a KEM keygen and then the encapsulate and decapsulate with your API? I am assuming the public and private keys are initialized in an init() method of some sorts? I see the encapsule(byte[] k) method assumes you know the size of the shared-secret, and expects you to size the array as a way to specify the size of the secret you want. If you are using a KEM with a fixed Cipher size, or you use the wrong size (by mistake), or you later decided to change to a different KEM that uses a different size then maybe that might cause issues? Perhaps just have a init() that takes a public or private key and a KEMParameterSpec (of type AlgorithmParameterSpec) that has an option to specify the SharedSecret size would be better? If you don't specify anything it could use the default provided by the KEM, or if you provide a size then it could be used. Then returning the shared secret in a separate method, or an Object that includes both the CipherText and shared-secret could work. Then this would remove the possibility of byte array initialization issues... Doing thing might also help to make the same code more crypto agile as you could easily switch from say Kyber to McEliece or Composite KEM just by changing the getInstance() call and modifying the KEMParameterSpec object. Perhaps we could meet together sometime and hash out a KEM API we all agree on and then propose it to Oracle/OpenJDK? If it is not accepted and OpenJDK/Oracle has no plans to add a KEM API we could just agree to implement it in our own toolkits and then at least we would have a common KEM interface for use across our toolkits? We could also do it over email if time-zones don't work out. I know David is in Australia, I am in Canada (Eastern Time). Cheers, John Gray -----Original Message----- From: Franco Nieddu Sent: Thursday, August 25, 2022 2:33 AM To: John Gray ; David Hook ; Michael StJohns Cc: security-dev at openjdk.org Subject: Re: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? Hi David, Michael, and John, and everyone else! I will give my two cents to the Cipher/KEM topic and add on the latest mail from John. For why this topic is interesting to me, I work at the TU Graz, where we have developed the IAIK-JCE Provider since the beginning of the 2000s. Anticipating the end of NIST's PQC, we started implementing the third- round KEMs approximately a year ago. I have to agree with David and John. KEMs and Ciphers are strictly different. To map KEMs operations to the existing API, we would be forced to break a lot of the contracts/definitions of multiple classes, but at the bare minimum from the Cipher.wrap(Key) method itself. Moving forward, KEMs will rise in popularity, and we should reduce confusion for developers using our libraries. It may be possible to use e.g., McEliece as an asymmetric cipher, but I would not want my users to start using McEliece in such a way. Clear segregation would help prevent this. The other option will be to throw exceptions if a caller provides something different than WRAP_MODE in Cipher.init(), breaking more contracts. Furthermore, the Cipher.unwrap(byte[], String, int) method is tedious to use, but maybe this is just me... In his last message, John showed, better than I could, that the KeyAgreement classes only fit with great difficulty. The API mapping just does not work, and there is no denying that. Nevertheless, the biggest issue I have (if we ignore all the broken contracts for a moment) is the serialization/deserialization of the ciphertext-secret pair. The Cipher.wrap() method simply does not allow to return both values. Concating the two values into a single byte array just begs for incompatibility between implementations. Another option to return the ciphertext and the secret to the caller is by defining a new class/interface like: public final class KEMSecret implements Key { private byte[] secret_; public final void setSecret(byte[] secret) { this.secret_ = secret; } public final byte[] getSecret() { return this.secret; } } Then enforce that for all KEMs, the Cipher.wrap() method uses this KEMSecret as parameter, breaking another contract, as the KEMSecret IS NOT a key (it can be but is not limited to). Our implementation for the moment looks something like this: public abstract class KeyEncapsulationMechanismSpi { //some init methods.... protected abstract void engineDeriveKey(byte[] output, byte[]... input) throws DigestException; protected abstract byte[] engineEncapsule(byte[] k) throws InvalidKeyException, DigestException; protected abstract void engineDecapsule(byte[] c, byte[] k) throws InvalidKeyException, DigestException; } The engineDeriveKey() method is a call to a KDF (for the PQC always SHAKE), where output is the derived key, and the varargs depict the input to the KDF. At least in McEliece, there are multiple calls to the KDF; therefore, adding a separate engine method seemed reasonable. Furthermore, it is possible to plug in different KDFs for the same KEM instance. Taking inspiration from the Cipher classes, we could do something like: KEM.getInstance("Kyber/SHAKE128") or KEM.getInstance("Kyber/KDF3") At the moment, this is not necessary, but already defining a modular interface should at least be considered. engineEncapsule() returns the ciphertext of the encap operation. Additionally, the implementation fills the provided byte[] with the secret. The secret produced by KEMs is not strictly limited in size; therefore, it seemed appropriate to let the caller decide the size of the byte[]. engineDecapsule() is the inverse of engineEncapsule(). I am, of course, open to discussions regarding the actual implementation, e.g. returning the result as some kind of EncapsulatedKEMData as suggested by John, but I see the necessity of adding KEM classes to the security API. To close this already long message, something about bureaucrats. Bureaucrats, at least in my country, are fond of the status quo. Luckily, we are not bureaucrats and are permitted to improve a barely working solution. Cheers, Franco On Wed, 2022-08-24 at 20:12 +0000, John Gray wrote: > Just catching up on emails. > > I agree about PKCS11 as well, but vast amounts of people use it and I > don?t think it is going away anytime soon. > > This is a great discussion. > > So Michael, I think you are saying we should be able to use a > combination of KeyAgreement and Cipher to implement a KEM in the > JCA. I think that works in practice for any existing Key Agreement > or Cipher (that is what we essentially use in our IETF draft for > turning existing Key agreement or Cipher algorithms into a KEM). > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-oun > sworth-pq-composite-kem/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7 > Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-K6fkXJ8$ > > However, for a pure KEM like Kyber I don?t think you can just assume > you will be able to break up the encapsulation() procedure which > returns a CipherText and Shared-Secret given a Kyber public key. > It defines the encapsulation and decapsulation operations (see > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ ). A > Cipher encrypt can?t model the Encapsulation operation as it just > returns a byte[]. I suppose a Cipher Decrypt could model the > Decapsulation() operation with the result being the shared secret, > but that is only half the picture?. Kyber has internal > functions that do encrypt and decrypt like operations which could be > modeled as a Cipher in JCA (but the message would have to be some type > of specially formatted structure containing the m and cpaSeed values, > or if a keywrap the public key would have to be structured along with > those required values). So even if we did that, how do you propose > the rest of the Kyber KEM operations fit in the current > Java JCA? It seems you would need to somehow split up the > components of the algorithm across different parts of the JCA and > would it be possible to hide the complexity as simply as adding a KEM > JCA object type with an encapsulate() method and a decapsulate() > method? > > From > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfr > g-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4 > vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ > > 11.2. Encapsulation > > Kyber encapsulation takes a public key and a 32-octet seed and > deterministically generates a shared secret and ciphertext for the > public key as follows. > > 1. Compute > > 1. m = H(seed) > > 2. (Kbar, cpaSeed) = G(m || H(pk)) > > 3. cpaCipherText = Kyber.CPAPKE.Enc(m, publicKey, cpaSeed) > > 2. Return > > 1. cipherText = cpaCipherText > > 2. sharedSecret = KDF(KBar || H(cpaCipherText)) > > > 11.3. Decapsulation > > Kyber decapsulation takes a private key and a cipher text and > returns > a shared secret as follows. > > 1. Split privateKey into > > 1. A 12*k*n/8-octet cpaPrivateKey > > 2. A 12*k*n/8+32-octet cpaPublicKey > > 3. A 32-octet h > > 4. A 32-octet z > > 2. Compute > > 1. m2 = Kyber.CPAPKE.Dec(cipherText, cpaPrivateKey) > > 2. (KBar2, cpaSeed2) = G(m2 || h) > > 3. cipherText2 = Kyber.CPAPKE.Enc(m2, cpaPublicKey, cpaSeed2) > > 4. K1 = KDF(KBar2 || H(cipherText)) > > 5. K2 = KDF(z || H(cipherText)) > > 3. In constant-time, set K = K1 if cipherText == cipherText2 else > set K = K2. > > 4. Return > > 1. sharedSecret = K > > > > It can *sort of* fit with a KeyAgreement if you do this, but its > kludgy: > > On sending side: > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > Kem.init(null, KEMparameters) - I?m generating the CipherText and > shared-secret for 1 other person, I don?t have their private key and > its not multi-party > > KEMCipherTextKey = Kem.doPhase(Key kemPublicKey, true) byte[] > sharedSecret = generateSecret() > > > The KEMCipherTextKey contains the CipherText that just happens to > implements the Key interface. It is very weird, but we something to > carry the cipher text. > > Send KEMCipherTextKey to the receiver: > > On receiving side: > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > Kem.init(KEMCipherTextKey, KEMParameters); -> The CipherTExt is > the KEMCipherTExtKey > null = Kem.doPhase(KemPrivateKey, true) -> Shared secret is generated > from CipherText and PrivateKey, but a Key object is not returned > byte[] sharedSecret = generateSecret() > > > So it can work, but it is kludgy. The placement of the keys could > be reversed (the public and private keys could be passed in via init, > then null in the first doPhase, and the CipherTextKey in the second > doPhase. I don?t know which is better as it could work either > way. This just shows how it doesn?t fit cleanly? > > > > In the openSSL-OQS port which is in C, they have KEM?s defined simply > as follows: > https://urldefense.com/v3/__https://github.com/open-quantum-safe/liboq > s/blob/main/src/kem/kem.h__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu > 7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-st7vufc$ > > Which follows which NIST outlines in > https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/ > Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!FJ > -Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwN > wVqx3ZsUUu2AVJSJMccMLY00KoUQ-ArPLprc$ > > > Obviously we can make it better in Java while keeping it simple. For > example: > > KEMEncapsulation = KEM.encapsulate(publicKey); byte[] ss = > KEM.decapsulate(privateKey, CipherText); > > KEMEncapsualtion simply contains the shared secret (ss) and > CipherText? > > > Or to fit with init() pattern the rest of them use: > > KEM.init(publicKey); > KEMEncapsulation = KEM.encapsulate() > > byte[] cipherText = KEMEncapsulation.getCipherText(); > > And then > KEM.init(privateKey); > byte[] ss = KEM.decapsulate(cipherText) > > or maybe even better: > KEM.init(publicKey); > byte[] cipherText = KEM.encapsulate() > byte[] sharedSecret = KEM.getSharedSecret() > > And then > KEM.init(privateKey); > byte[] ss = KEM.decapsulate(cipherText) > > > Cheers, > > John Gray > > > > > From: David Hook > Sent: Sunday, August 21, 2022 10:51 PM > To: Michael StJohns ; John Gray < > John.Gray at entrust.com> > Cc: security-dev at openjdk.org > Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) > architecture being proposed for the JCA? > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know > the content is safe. > > I'd have to agree about PKCS 11. > > One more thing about the PQC KEMs - the KDF step is built in. As > you've mentioned, previously there's been a lot of possible > combinations with key agreement, with PQC KEMs this has changed (of > course, you could still use a KDF too, but the original reasons for > doing so no longer apply). > > Regards, > > David > > On 21/8/22 13:52, Michael StJohns wrote: > > On 8/20/2022 2:08 PM, David Hook wrote: > > > Hi Michael, > > > > > > I don't know anything about bureaucrats, I am an engineer. You may > > > need to consult someone else on bureaucrats. > > > I apologize for my apparent deficiencies in this area, but would > > > you mind explaining how Cipher.wrap() is either supposed to take a > > > public key and create an encapsulation based on it and return a > > > secret key implicitly in one clean move, or why it even makes > > > sense to do so. The method was never conceived as providing the > > > functionality for what a KEM actually does, and when I did the > > > initial PKCS11 implementation at Eracom in the late 90's and the > > > team at Sun added the wrap/unwrap functions to support it, this is > > > definitely not was intended either - it was for explicit key > > > wrapping based on the key that was passed to Cipher.init(). > > > > > > > First - PKCS11 is a 40 year old API that probably needs to be > > retired. I spent the better part of 2 years working with the > > PKCS11 Oasis group trying to get them to properly support master > > secrets and KDFs and failed utterly. You should not use PKCS11 as > > an example that the JCE should use as a goal. > > > > > > > > At the base, a java class is a collection of objects. A Cipher > > object > > > > Let's build a non-parameterized ECIES-KEM which implicitly uses > > AES256 bit keys to key a GCM cipher, and a KDF based on SP800-108 > > counter mode with SHA256 as the underlying hash, and with a well > > known label and context for the KDF since there is a new key for > > every wrap. > > > > 1) Implement CipherSpi - > > > > public class EciesKemCipher extends CipherSpi { > > > > private KeyAgreement ka; > > private Cipher gcm; > > private KeyPair kp; > > private KeyPairGenerator kg; > > > > EciesKemCipher() { > > ka = KeyAgreement.getInstance("ECDH"); > > kpg = KeyPairGenerator.getInstance ("EC"); > > gcm = Cipher.getInstance ("AES/GCM/NoPadding"); > > > > } > > > > // implement a single example > > > > @override > > protected void engineInit (int opMode, Key key, SecureRandom > > dontcare) { > > > > switch (opMode) { > > Cipher.MODE_WRAP: > > initWrap((ECPublicKey) key); > > break; > > default: > > // unimpl > > } > > } > > > > private void initWrap (ECPublicKey k) { > > > > ECParameterSpec spec = k.getParams(); > > kpg.initialize(spec); > > kp = kpg.genKeyPair(); > > ka.init (kp.getPrivate()); > > ka.doPhase (k, true); > > byte[] sharedSecret = ka.generateSecret(); > > > > byte[] keyStream = kdf(sharedSecret, 32 + 12); // output > > 44 bytes for Key and IV > > SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, > > 32, "AES"); > > IvParameterSpec gcmIv = new IVParameterSpec(keyStream, 32, > > 12); > > > > gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); > > // all ready to go > > } > > > > > > protected byte[] engineWrap (Key k) { > > > > ByteBuffer outData = ByteBuffer.allocate > > (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; > > > > // Place a copy of the ephemeral public key I generated > > in init here for the use of the receiver. > > outData.put (kp.getEncoded()); > > // One s > > outData.put (gcm.doFinal(k.getEncoded()); > > > > outData.flip(); > > byte[] result = outdata.remaining(); > > > > outData.get(result); > > // kp = null; clear cipher if it hasn't already been > > cleared, clear ka if necessary (e.g. un-init) > > > > return result; > > } > > > > ... and unwrap and kdf function > > } > > > > > > > > 2) Implement a provider and add the above. > > > > > > > > > On BC's part, we've already implemented RFC 5990/SP 800-56B in > > > Java and the experience has, at best, been awkward. The new > > > algorithms have moved awkward to inappropriate. With the new > > > algorithms, there's no longer only one case of this, it's not an > > > outlier, there should be a general way of supporting KEMs in the > > > API that doesn't involve over engineering KeyGenerator and Cipher. > > > > > > > There's a big difference between the API and your underlying > > implementation. Everything you want to do can be done using the > > current APIs. As I said before, Cipher.wrap/unwrap are the > > appropriate APIs for this as they meet the contract requirements > > you need. Most Ciphers require some extra data -e.g. IVs - that > > have to either be carried or implicitly derived. In this case, what > > needs to be carried in addition to the encrypted key material > > is at least the ephemeral public key the wrapper creates. I used > > a very simple encoding scheme above and this assumes that both ends > > know exactly what "ECIES-KEM" means. Obviously, there are 100s of > > possible combinations of parameters and KDFs and key wrap > > algorithms. What I would suggest is heading over to LAMPS at the > > IETF and proposing a data encoding scheme for carrying the > > parameters. Once you have that done, then come here and map JCE > > names against parameter sets to close the loop. It won't require an > > API change. > > > > > I work with a team that has had to implement all of them and had > > > to make them fit into the JCA. We have done so. Like John, I am > > > simply relaying our experience. In about 18 months these > > > algorithms are going to become mandatory, what all of us think is > > > irrelevant. We, for our part, already have a solution, but we both > > > realize it's not "the solution" - we recognize that the JVM is > > > uniquely positioned to provide leadership on this and provide a > > > universal way of doing it. > > > > > > > Then suggest an API and we'll start knocking it around. I > > personally don't think its necessary at this time and will add to > > API bloat. > > > > > Of course, if it's felt that these algorithms should be ignored, > > > it's not my place to revolt, although I do feel obliged to argue. > > > I will simply try and do the best by my users, as I have no doubt > > > will John. Both of us have simply offered our comments in good > > > faith and to alert the community that things have changed and that > > > with these new algorithms there is room for a new approach. > > > The ambiguity about how these algorithms can be implemented and > > > the excessive need to fallback on propritary classes for them does > > > suggest that there are some additions to the JCA which would help. > > > I appreciate to understand this statement does involve actually > > > understanding what these algorithms do and may require some > > > additional reading. > > > > > > As I said, I'm an engineer, my users will be able to use these > > > algorithms properly, my team will ensure that, as I have no doubt > > > will John's. What John and myself, apparently mistakenly, care > > > about is that our users should also be able to use these > > > algorithms portably. > > > > > > Are you saying portability is no longer a consideration? > > > > > > > I have no idea where you got that idea. > > > > > Regards, > > > > > > David > > > > > > > > > > > > On 21/8/22 02:23, Michael StJohns wrote: > > > > Hi David/John - > > > > > > > > I would submit that you're trying too hard to make your life > > > > simple! :-) > > > > > > > > Cipher.wrap/unwrap are the correct methods. > > > > > > > > For example: > > > > > > > > Cipher kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800- > > > > 108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); > > > > byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); > > > > > > > > The "opaqueEncapsulatedKey" would contain the data needed by the > > > > unwrap function - specifically a) the ecies ephemeral public > > > > key, b) the fact that the derived key is a GCM key of length 128 > > > > and that the GCM tag is 64 bytes long, c) the KDF, > > > > d) (optional) any mixins other than defaults required by the KDF > > > > - which would be passed in a parameter blob during init. > > > > Cipher would NOT return the underlying generated secret used to > > > > wrap the key. Just the public part of the key pair used to do > > > > the ECDH operation against the passed in public key. In the > > > > RSA case, the wrapped encrypting secret would be an opaque data > > > > blob and would be part of the data passed to the unwrap > > > > function. > > > > > > > > If you want a key generated for other purposes, then the right > > > > thing is using a KDF and a Key agreement function in tandem. > > > > Strangely the KDF appears in the javacard API for 3.1, but not > > > > in the JCE/JDK API. > > > > > > > > "What's the difference between a bureaucrat and an engineer? A > > > > bureaucrat takes small solvable pieces and combines them into > > > > one insoluble mass." > > > > > > > > In this case, Java provides a number of flexible primitives that > > > > can be combined as needed. In this case, the underlying Cipher > > > > implementation would wrap key agreement and kdf and cipher (GCM) > > > > instances. It should return UnsupportedOperationException for > > > > all operations execept wrap/unwrap and the appropriate init > > > > methods. > > > > > > > > Later, Mike > > > > > > > > > > > > > > > > On 8/19/2022 6:38 PM, David Hook wrote: > > > > > Hi Mike, > > > > > > > > > > KEMs can be used for key wrapping - we've actually implemented > > > > > support for this too. But they are not actually key wrapping > > > > > ciphers. > > > > > > > > > > Here's a simple example of using Kyber for key wrapping in > > > > > BC: > > > > > > > > > > SecretKey key = new SecretKeySpec(keyBytes, "AES"); > > > > > > > > > > w1.init(Cipher.WRAP_MODE, kp.getPublic(), new > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > byte[] data = w1.wrap(key); > > > > > > > > > > Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); > > > > > > > > > > w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); > > > > > > > > > > The behavior in this case is in line with what is given in RFC > > > > > 5990 for the RSA KEM. How it works is by using the key > > > > > generated by the KEM to create an AES-KWP key, which is then > > > > > used to wrap keyBytes. The shortcoming is it means you have to > > > > > generate the secret key separately. > > > > > > > > > > This is the problem though - a KEM can actually be used to > > > > > generate a secret key for other purposes. For example, where > > > > > someone is trying to implement a hybrid KAS scheme. But there > > > > > is currently no mechanism in the Java APIs for being able to > > > > > take advantage of this directly, hence our use of the > > > > > KeyGenerator class and other people's attempts to make use of > > > > > the KeyAgreement class. The Cipher.wrap() returns a byte[] - > > > > > to be used with a KEM for secret generation it would also have > > > > > to return the generated secret (I would probably also argue > > > > > that passing a public key to wrap in order to generate an > > > > > encapsulation of a generated encrypted secret was not the > > > > > correct use of the API either, but the fact remains a byte[] > > > > > is not really going to cut it). > > > > > > > > > > If you have any further questions, please feel free to ask. > > > > > For what it is worth, I have been developing providers for the > > > > > JCE/JCA since the late 90's and am actually one of the people > > > > > responsible for the introduction of the existing wrap/unwrap > > > > > API in the Cipher class. > > > > > > > > > > Thanks, > > > > > > > > > > David > > > > > On 20/8/22 07:53, Mike StJohns wrote: > > > > > > Hi This implemented as part of Javax.crypto.Cipher. See the > > > > > > Java doc for the wrap and unwrap methods. > > > > > > > > > > > > Mike > > > > > > > > > > > > Sent from my iPad > > > > > > > > > > > > > On Aug 19, 2022, at 12:56, John Gray < > > > > > > > John.Gray at entrust.com> wrote: > > > > > > > > > > > > > > ? We are starting to make use of the new PQ algorithms > > > > > > > adopted by NIST for prototyping and development of > > > > > > > standards. In particular we are working on a composite > > > > > > > KEM standard: > > > > > > > See: > > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/d > > > > > > > oc/draft-ounsworth-pq-composite-kem/__;!!FJ-Y8qCqXTj2!dRvG > > > > > > > TjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVq > > > > > > > x3ZsUUu2AVJSJMccMLY00KoUQ-K6fkXJ8$ > > > > > > > > > > > > > > However, there is no KEM interface in the JCA (which make > > > > > > > sense because these are new algorithms, although RSA-KEM > > > > > > > has been out since 2010). > > > > > > > > > > > > > > I can add one into our toolkit (and I think David may have > > > > > > > already added on into BC), but I assume at some point > > > > > > > there will be an official one added in Java and likely it > > > > > > > won't be identical to what we do even if it is very close, > > > > > > > which would cause backwards compatibility > > > > > > > pain... Perhaps we could collaborate on extending the > > > > > > > JCA to support KEM? Essentially it requires methods. > > > > > > > > > > > > > > ss, ct := encapsulate(PublicKey) ss := > > > > > > > decapsulate(PrivateKey, ct) > > > > > > > > > > > > > > -ss is a shared secret (could come back as a Java > > > > > > > SecretKey if you wanted as it would usually be used to > > > > > > > derive something like an AES afterwards) -ct is a Cipher > > > > > > > Text (a byte array would make sense) -Public and Private > > > > > > > Keys would use the regular public and private key > > > > > > > interface. > > > > > > > -An object holding the ss and ct from the encapsulate() > > > > > > > method could be returned, with accessor methods to get > > > > > > > the ss and ct. It could be called 'EncapsulatedKEMData' > > > > > > > for example. > > > > > > > > > > > > > > Likely you would want a new type of KEM crypto object > > > > > > > (like you have for Signature, MessageDigest, Cipher, Mac, > > > > > > > SecureRandom, KeyAgreement.. etc). Calling it KEM would > > > > > > > seem to make sense. ? It could also use similar > > > > > > > calling patterns and have a > > > > > > > KEM.initKEM(keypair.getPublic()) or > > > > > > > KEM.initKEM(keypair.getPrivate()), and then you would just > > > > > > > call KEM.encapsulate() or KEM.decapsulate(ct). > > > > > > > > > > > > > > Then algorithms could be registered in providers as > > > > > > > usual: > > > > > > > > > > > > > > put("KEM.Kyber","com.blah.Kyber") > > > > > > > > > > > > > > put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.co > > > > > > > mpositeKEM") > > > > > > > > > > > > > > Then the above methods (encapsulate and decapsulate) > > > > > > > could be defined in that new object type. Then we would > > > > > > > be able to make use of it and not have to worry about > > > > > > > incompatibility issues down the road... > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > John Gray > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any email and files/attachments transmitted with it are > > > > > > > confidential and are intended solely for the use of the > > > > > > > individual or entity to whom they are addressed. If this > > > > > > > message has been sent to you in error, you must not copy, > > > > > > > distribute or disclose of the information it contains. > > > > > > > Please notify Entrust immediately and delete the message > > > > > > > from your system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Franco Nieddu SIC - Software Engineer Phone: +43 (316) 873 - 5507 SIC Homepage: https://urldefense.com/v3/__https://jce.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-2W4oa1s$ IAIK Homepage: https://urldefense.com/v3/__https://www.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-Ov0Iano$ From mullan at openjdk.org Thu Aug 25 15:11:28 2022 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 25 Aug 2022 15:11:28 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Mon, 22 Aug 2022 21:45:39 GMT, Mark Powers wrote: > https://bugs.openjdk.org/browse/JDK-8291509 Some initial comments so far. src/java.base/share/classes/sun/security/jca/ProviderList.java line 129: > 127: int j = 0; > 128: for (ProviderConfig config : providerList.configs) { > 129: if (!Objects.requireNonNull(config.getProvider()).getName().equals(name)) { This is an unusual usage of `Objects.requireNonNull`. Is a null provider ever expected here? I don't see why this is better, the prior code will also throw NPE. Replacing `== false` with `!` is ok though. Same comment on other cases in this file. src/java.base/share/classes/sun/security/jca/ProviderList.java line 679: > 677: private final String algorithm; > 678: private final String provider; > 679: private String[] alternateNames = null; shouldn't this also be final? src/java.base/share/classes/sun/security/jca/Providers.java line 104: > 102: * Start JAR verification. This sets a special provider list for > 103: * the current thread. You MUST save the return value from this > 104: * method, and you MUST call stopJarVerification() with that object Hmm, I'm not sure this is more grammatically correct. src/java.base/share/classes/sun/security/jca/Providers.java line 212: > 210: > 211: // Change the thread local provider list. Use only if the current thread > 212: // is already using a thread local list, and you want to change it in place. Hmm, I'm not sure this is more grammatically correct. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Thu Aug 25 15:29:06 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 25 Aug 2022 15:29:06 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 02:59:42 GMT, Valerie Peng wrote: >> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. >> >> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > update test to use SHA256 and DSA throughout. Some comments. src/java.base/share/classes/java/security/Security.java line 530: > 528: // . : > 529: key = filter.substring(0, index); > 530: value = filter.substring(index + 1); Do you need to ensure `value` is non-empty here? I am worried that somewhere later a `string.indexOf("")` is called and it's always true. src/java.base/share/classes/java/security/Security.java line 599: > 597: // Returns all installed providers > 598: // if the selection criteria is null. > 599: if ((keySet == null) || (allProviders == null)) { I'm not sure, but can `keySet` or `allProviders` be null? Or you meant `isEmpty()`? src/java.base/share/classes/java/security/Security.java line 931: > 929: // check individual component for match and bail if no match > 930: if (prop.indexOf(st.nextToken()) == -1) { > 931: return false; So if `value` has several sub-values, all of them must appear in the `prop` value. Do we need to make this clear in the spec? Also, you use `indexOf` instead of an exact match to a sub-value in `prop`. Is this always correct? I am wondering if a value can be substring of a different value. I see you support simple class name in the test. Is it worth we doing this? I would rather be strict at the beginning. src/java.base/share/classes/java/security/Security.java line 945: > 943: > 944: static String[] getFilterComponents(String filterKey, String filterValue) { > 945: Can we create a new class for the return value plus `filterValue`? Then we can make `isCriterionSatisfied(Provider)` a method of it. test/jdk/java/security/Security/ProviderFiltering.java line 89: > 87: doit(key + ":" + valComp2 + " ", p); > 88: // 4. partial value, e.g. class name only > 89: doit(key + ":" + valComp2CN, p); Do we really need to support cases 2-4? In fact, the only place mentioning spaces in the spec is about the ones between "SHA256withDSA" and "SupportedKeyClasses". I'd rather you add a test case on it. test/jdk/java/security/Security/ProviderFiltering.java line 109: > 107: filters.put("Signature.SHA256withDSA", ""); > 108: doit(filters, p); > 109: filters.put("Cipher.Nonexisting", ""); Even if it's not "Nonexisting", I assume it's still empty after filtering? ------------- PR: https://git.openjdk.org/jdk/pull/10008 From mpowers at openjdk.org Thu Aug 25 18:47:38 2022 From: mpowers at openjdk.org (Mark Powers) Date: Thu, 25 Aug 2022 18:47:38 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> On Thu, 25 Aug 2022 15:00:55 GMT, Sean Mullan wrote: >> https://bugs.openjdk.org/browse/JDK-8291509 > > src/java.base/share/classes/sun/security/jca/ProviderList.java line 129: > >> 127: int j = 0; >> 128: for (ProviderConfig config : providerList.configs) { >> 129: if (!Objects.requireNonNull(config.getProvider()).getName().equals(name)) { > > This is an unusual usage of `Objects.requireNonNull`. Is a null provider ever expected here? I don't see why this is better, the prior code will also throw NPE. Replacing `== false` with `!` is ok though. > > Same comment on other cases in this file. IntelliJ seems to think it could. The point of requireNonNull is that you control when an exception is thrown, and sooner rather than later is better. This code appears to have been working fine for a long time, so maybe NPE can't happen in practice. I'm fine with reverting this requireNonNull change here and elsewhere if you think it is unnecessary. > src/java.base/share/classes/sun/security/jca/ProviderList.java line 679: > >> 677: private final String algorithm; >> 678: private final String provider; >> 679: private String[] alternateNames = null; > > shouldn't this also be final? If I make alternateNames final, then IJ complains "cannot assign a value to final variable". If I make it final and remove initialization, then make complains that alternateNames might not have been initialized. > src/java.base/share/classes/sun/security/jca/Providers.java line 212: > >> 210: >> 211: // Change the thread local provider list. Use only if the current thread >> 212: // is already using a thread local list, and you want to change it in place. > > Hmm, I'm not sure this is more grammatically correct. I could go either way. The sentence is not that long (it's not a German sentence). IJ is only a recommendation. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From valeriep at openjdk.org Thu Aug 25 20:03:09 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 20:03:09 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: <8x_-hT0hw6GqQho_CxlpCmmJm-OBvlvZrkqpMD3ItYY=.b8850e45-a380-4002-ab6d-6d512597b57c@github.com> On Thu, 25 Aug 2022 14:30:01 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update test to use SHA256 and DSA throughout. > > src/java.base/share/classes/java/security/Security.java line 599: > >> 597: // Returns all installed providers >> 598: // if the selection criteria is null. >> 599: if ((keySet == null) || (allProviders == null)) { > > I'm not sure, but can `keySet` or `allProviders` be null? Or you meant `isEmpty()`? Both may be null as their javadoc didn't state explicitly what is returned. This is existing code and it returns null upon empty keySet which I keep the same behavior. Perhaps for consistency sake, it should also check for the empty keySet condition and return allProviders. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From coffeys at openjdk.org Thu Aug 25 20:03:09 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 25 Aug 2022 20:03:09 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: On Wed, 24 Aug 2022 21:59:59 GMT, Xue-Lei Andrew Fan wrote: >> The cipher suite enabled on the server side is not logged when "no common in cipher suites" error is thrown. Hope the developer could find the difference in the cipher suites between client and server. > > Even the cipher suites are the same between client and server, it may still fail with "no common in cipher suites" error. The cause of the bug is not only about "no common in cipher suites" between client and server, but also about the cases that the server cannot negotiate any of the common cipher suites because of other facts. If the cause is only about ""no common in cipher suites", I don't think we need a fix as the message has been tell the story. > > It is not objected that cipher suite should not be logged. The question raised here is about when and how to log the cipher suite, and how to make the log easier to read and easier to debug. @XueleiFan - I think it's fair to say that the current "no cipher suites in common" exception message is misleading for some scenarios. If not misleading, it's ambiguous. You could be dealing with a simple scenario where the server socket simply has no enabled cipher suites to match those coming in from the ClientHello. In the more complex scenario, something else has caused the fatal issues like a key exchange issue in TLSv1.2. With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required. If you feel strongly about printing debug data for each TLSServerSocket handshake, (including the extra data points that you've suggested) then please shout now. I do feel it'll add considerably to log size on busy TLS Servers. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From valeriep at openjdk.org Thu Aug 25 20:06:53 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 20:06:53 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 14:41:44 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update test to use SHA256 and DSA throughout. > > src/java.base/share/classes/java/security/Security.java line 945: > >> 943: >> 944: static String[] getFilterComponents(String filterKey, String filterValue) { >> 945: > > Can we create a new class for the return value plus `filterValue`? Then we can make `isCriterionSatisfied(Provider)` a method of it. Sure, sounds good. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From rhalade at openjdk.org Thu Aug 25 20:30:39 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 25 Aug 2022 20:30:39 GMT Subject: RFR: 8247698: Add Certigna Root CAs Message-ID: This fix adds Certigna root CA to cacerts trust store. ------------- Commit messages: - remove control-M characters - Added Certigna CA cert and updated VerifyCACerts.java test - Merge remote-tracking branch 'origin/master' into 8247698-certigna - 8247698: Evaluate the inclusion of DHIMYOTIS (certigna) roots Changes: https://git.openjdk.org/jdk/pull/10030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8247698 Stats: 254 lines in 3 files changed: 251 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10030/head:pull/10030 PR: https://git.openjdk.org/jdk/pull/10030 From xuelei at openjdk.org Thu Aug 25 21:06:44 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Thu, 25 Aug 2022 21:06:44 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: On Thu, 25 Aug 2022 20:00:45 GMT, Sean Coffey wrote: >> Even the cipher suites are the same between client and server, it may still fail with "no common in cipher suites" error. The cause of the bug is not only about "no common in cipher suites" between client and server, but also about the cases that the server cannot negotiate any of the common cipher suites because of other facts. If the cause is only about ""no common in cipher suites", I don't think we need a fix as the message has been tell the story. >> >> It is not objected that cipher suite should not be logged. The question raised here is about when and how to log the cipher suite, and how to make the log easier to read and easier to debug. > > @XueleiFan - I think it's fair to say that the current "no cipher suites in common" exception message is misleading for some scenarios. If not misleading, it's ambiguous. You could be dealing with a simple scenario where the server socket simply has no enabled cipher suites to match those coming in from the ClientHello. In the more complex scenario, something else has caused the fatal issues like a key exchange issue in TLSv1.2. With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. > > I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required. > > If you feel strongly about printing debug data for each TLSServerSocket handshake, (including the extra data points that you've suggested) then please shout now. I do feel it'll add considerably to log size on busy TLS Servers. @coffeys Before we go further, I think we'd better have a look if the information added could help for debugging. I'm not sure of that now. > With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. If I understand correctly, the preference of client or server suites should not impact the success of handshaking. Did you see examples otherwise in practice? What's the purpose by adding this information for failed handshaking? The client authentication type is also logged for failed server hello handshake message. What's the purpose for the adding? Did you see server hello failure that caused by client authentication type in practice? With server debug log enabled, there have already been a lot debug information, especially for verberos debug mode. Is it a really concern to you to dump server enabled cipher suites, just as the dump of ClientHello message? Yes, it make debug logger worse for a busy server, but the impact may be 1/10K? I have to run for now, and will try to reply more for your comments. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/9731 From valeriep at openjdk.org Thu Aug 25 21:40:16 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 21:40:16 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 15:01:28 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update test to use SHA256 and DSA throughout. > > test/jdk/java/security/Security/ProviderFiltering.java line 89: > >> 87: doit(key + ":" + valComp2 + " ", p); >> 88: // 4. partial value, e.g. class name only >> 89: doit(key + ":" + valComp2CN, p); > > Do we really need to support cases 2-4? In fact, the only place mentioning spaces in the spec is about the ones between "SHA256withDSA" and "SupportedKeyClasses". I'd rather you add a test case on it. I can go either way, just try to be more accommodating. Maybe that's not necessary. I will remove them and add the case of extra spaces between algName and attrName. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From dgh at cryptoworkshop.com Thu Aug 25 22:36:08 2022 From: dgh at cryptoworkshop.com (David Hook) Date: Fri, 26 Aug 2022 08:36:08 +1000 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> Message-ID: <0320a143-178d-6bfb-99cc-8cff28cae426@cryptoworkshop.com> Happy to offer any assistance I can. The existing API maps well for key wrapping if you follow the example of RFC 5990 - the RSA-KEM - but for actual secret sharing, every? solution that "fits", including our current one, doesn't really fit either the JCA, or the algorithms themselves. Even with our current solution, overloading the KeyGenerator class, it only solves a specific use case. It's obvious there are others, so the solution means the burden on the parameter spec classes is just going to get worse. A more general solution would mean we would only have to explain things once, rather than once each. Regards, David On 26/8/22 00:49, John Gray wrote: > Thanks Franco, > > I am very familiar with the IAIK toolkit as our Entrust Java toolkit actually makes use of the IAIK ASN.1 library from a 2003 version and IAIK and Entrust used to work very closely together regarding our toolkits in the early 2000's. So I think between the 3 of us we represent a majority of the JCA cypto toolkits that exist (except for BSAFE which I have never used). So it is great to see we agree that there needs to be KEM classes added to the JCA as we have all struggled with fitting KEM into the JCA. > > We certainly want their to be an interoperable implementations of KEM. Franco, could you send a simple sample of doing a KEM keygen and then the encapsulate and decapsulate with your API? I am assuming the public and private keys are initialized in an init() method of some sorts? I see the encapsule(byte[] k) method assumes you know the size of the shared-secret, and expects you to size the array as a way to specify the size of the secret you want. If you are using a KEM with a fixed Cipher size, or you use the wrong size (by mistake), or you later decided to change to a different KEM that uses a different size then maybe that might cause issues? Perhaps just have a init() that takes a public or private key and a KEMParameterSpec (of type AlgorithmParameterSpec) that has an option to specify the SharedSecret size would be better? If you don't specify anything it could use the default provided by the KEM, or if you provide a size then it could be used. Then returning the shared secret in a separate method, or an Object that includes both the CipherText and shared-secret could work. Then this would remove the possibility of byte array initialization issues... Doing thing might also help to make the same code more crypto agile as you could easily switch from say Kyber to McEliece or Composite KEM just by changing the getInstance() call and modifying the KEMParameterSpec object. > > Perhaps we could meet together sometime and hash out a KEM API we all agree on and then propose it to Oracle/OpenJDK? If it is not accepted and OpenJDK/Oracle has no plans to add a KEM API we could just agree to implement it in our own toolkits and then at least we would have a common KEM interface for use across our toolkits? We could also do it over email if time-zones don't work out. I know David is in Australia, I am in Canada (Eastern Time). > > Cheers, > > John Gray > > > -----Original Message----- > From: Franco Nieddu > Sent: Thursday, August 25, 2022 2:33 AM > To: John Gray ; David Hook ; Michael StJohns > Cc: security-dev at openjdk.org > Subject: Re: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? > > Hi David, Michael, and John, and everyone else! > > I will give my two cents to the Cipher/KEM topic and add on the latest mail from John. For why this topic is interesting to me, I work at the TU Graz, where we have developed the IAIK-JCE Provider since the beginning of the 2000s. > > Anticipating the end of NIST's PQC, we started implementing the third- round KEMs approximately a year ago. > > I have to agree with David and John. KEMs and Ciphers are strictly different. To map KEMs operations to the existing API, we would be forced to break a lot of the contracts/definitions of multiple classes, but at the bare minimum from the Cipher.wrap(Key) method itself. Moving forward, KEMs will rise in popularity, and we should reduce confusion for developers using our libraries. > It may be possible to use e.g., McEliece as an asymmetric cipher, but I would not want my users to start using McEliece in such a way. Clear segregation would help prevent this. The other option will be to throw exceptions if a caller provides something different than WRAP_MODE in Cipher.init(), breaking more contracts. Furthermore, the Cipher.unwrap(byte[], String, int) method is tedious to use, but maybe this is just me... > > In his last message, John showed, better than I could, that the KeyAgreement classes only fit with great difficulty. > > The API mapping just does not work, and there is no denying that. > Nevertheless, the biggest issue I have (if we ignore all the broken contracts for a moment) is the serialization/deserialization of the ciphertext-secret pair. The Cipher.wrap() method simply does not allow to return both values. Concating the two values into a single byte array just begs for incompatibility between implementations. > Another option to return the ciphertext and the secret to the caller is by defining a new class/interface like: > > public final class KEMSecret implements Key { > > private byte[] secret_; > > > public final void setSecret(byte[] secret) { > this.secret_ = secret; > } > > public final byte[] getSecret() { > return this.secret; > } > } > > Then enforce that for all KEMs, the Cipher.wrap() method uses this KEMSecret as parameter, breaking another contract, as the KEMSecret IS NOT a key (it can be but is not limited to). > > > > Our implementation for the moment looks something like this: > > public abstract class KeyEncapsulationMechanismSpi { > //some init methods.... > protected abstract void engineDeriveKey(byte[] output, byte[]... > input) throws DigestException; > protected abstract byte[] engineEncapsule(byte[] k) throws InvalidKeyException, DigestException; > protected abstract void engineDecapsule(byte[] c, byte[] k) throws InvalidKeyException, DigestException; } > > The engineDeriveKey() method is a call to a KDF (for the PQC always SHAKE), where output is the derived key, and the varargs depict the input to the KDF. At least in McEliece, there are multiple calls to the KDF; therefore, adding a separate engine method seemed reasonable. > Furthermore, it is possible to plug in different KDFs for the same KEM instance. Taking inspiration from the Cipher classes, we could do something like: > > KEM.getInstance("Kyber/SHAKE128") or KEM.getInstance("Kyber/KDF3") > > At the moment, this is not necessary, but already defining a modular interface should at least be considered. > > engineEncapsule() returns the ciphertext of the encap operation. > Additionally, the implementation fills the provided byte[] with the secret. The secret produced by KEMs is not strictly limited in size; therefore, it seemed appropriate to let the caller decide the size of the byte[]. > > engineDecapsule() is the inverse of engineEncapsule(). > > I am, of course, open to discussions regarding the actual implementation, e.g. returning the result as some kind of EncapsulatedKEMData as suggested by John, but I see the necessity of adding KEM classes to the security API. > > To close this already long message, something about bureaucrats. > Bureaucrats, at least in my country, are fond of the status quo. > Luckily, we are not bureaucrats and are permitted to improve a barely working solution. > > Cheers, > Franco > > On Wed, 2022-08-24 at 20:12 +0000, John Gray wrote: >> Just catching up on emails. >> >> I agree about PKCS11 as well, but vast amounts of people use it and I >> don?t think it is going away anytime soon. >> >> This is a great discussion. >> >> So Michael, I think you are saying we should be able to use a >> combination of KeyAgreement and Cipher to implement a KEM in the >> JCA. I think that works in practice for any existing Key Agreement >> or Cipher (that is what we essentially use in our IETF draft for >> turning existing Key agreement or Cipher algorithms into a KEM). >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-oun >> sworth-pq-composite-kem/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7 >> Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-K6fkXJ8$ >> >> However, for a pure KEM like Kyber I don?t think you can just assume >> you will be able to break up the encapsulation() procedure which >> returns a CipherText and Shared-Secret given a Kyber public key. >> It defines the encapsulation and decapsulation operations (see >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ ). A >> Cipher encrypt can?t model the Encapsulation operation as it just >> returns a byte[]. I suppose a Cipher Decrypt could model the >> Decapsulation() operation with the result being the shared secret, >> but that is only half the picture?. Kyber has internal >> functions that do encrypt and decrypt like operations which could be >> modeled as a Cipher in JCA (but the message would have to be some type >> of specially formatted structure containing the m and cpaSeed values, >> or if a keywrap the public key would have to be structured along with >> those required values). So even if we did that, how do you propose >> the rest of the Kyber KEM operations fit in the current >> Java JCA? It seems you would need to somehow split up the >> components of the algorithm across different parts of the JCA and >> would it be possible to hide the complexity as simply as adding a KEM >> JCA object type with an encapsulate() method and a decapsulate() >> method? >> >> From >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfr >> g-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4 >> vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ >> >> 11.2. Encapsulation >> >> Kyber encapsulation takes a public key and a 32-octet seed and >> deterministically generates a shared secret and ciphertext for the >> public key as follows. >> >> 1. Compute >> >> 1. m = H(seed) >> >> 2. (Kbar, cpaSeed) = G(m || H(pk)) >> >> 3. cpaCipherText = Kyber.CPAPKE.Enc(m, publicKey, cpaSeed) >> >> 2. Return >> >> 1. cipherText = cpaCipherText >> >> 2. sharedSecret = KDF(KBar || H(cpaCipherText)) >> >> >> 11.3. Decapsulation >> >> Kyber decapsulation takes a private key and a cipher text and >> returns >> a shared secret as follows. >> >> 1. Split privateKey into >> >> 1. A 12*k*n/8-octet cpaPrivateKey >> >> 2. A 12*k*n/8+32-octet cpaPublicKey >> >> 3. A 32-octet h >> >> 4. A 32-octet z >> >> 2. Compute >> >> 1. m2 = Kyber.CPAPKE.Dec(cipherText, cpaPrivateKey) >> >> 2. (KBar2, cpaSeed2) = G(m2 || h) >> >> 3. cipherText2 = Kyber.CPAPKE.Enc(m2, cpaPublicKey, cpaSeed2) >> >> 4. K1 = KDF(KBar2 || H(cipherText)) >> >> 5. K2 = KDF(z || H(cipherText)) >> >> 3. In constant-time, set K = K1 if cipherText == cipherText2 else >> set K = K2. >> >> 4. Return >> >> 1. sharedSecret = K >> >> >> >> It can *sort of* fit with a KeyAgreement if you do this, but its >> kludgy: >> >> On sending side: >> KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); >> >> Kem.init(null, KEMparameters) - I?m generating the CipherText and >> shared-secret for 1 other person, I don?t have their private key and >> its not multi-party >> >> KEMCipherTextKey = Kem.doPhase(Key kemPublicKey, true) byte[] >> sharedSecret = generateSecret() >> >> >> The KEMCipherTextKey contains the CipherText that just happens to >> implements the Key interface. It is very weird, but we something to >> carry the cipher text. >> >> Send KEMCipherTextKey to the receiver: >> >> On receiving side: >> KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); >> >> Kem.init(KEMCipherTextKey, KEMParameters); -> The CipherTExt is >> the KEMCipherTExtKey >> null = Kem.doPhase(KemPrivateKey, true) -> Shared secret is generated >> from CipherText and PrivateKey, but a Key object is not returned >> byte[] sharedSecret = generateSecret() >> >> >> So it can work, but it is kludgy. The placement of the keys could >> be reversed (the public and private keys could be passed in via init, >> then null in the first doPhase, and the CipherTextKey in the second >> doPhase. I don?t know which is better as it could work either >> way. This just shows how it doesn?t fit cleanly? >> >> >> >> In the openSSL-OQS port which is in C, they have KEM?s defined simply >> as follows: >> https://urldefense.com/v3/__https://github.com/open-quantum-safe/liboq >> s/blob/main/src/kem/kem.h__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu >> 7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-st7vufc$ >> >> Which follows which NIST outlines in >> https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/ >> Post-Quantum-Cryptography/documents/example-files/api-notes.pdf__;!!FJ >> -Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwN >> wVqx3ZsUUu2AVJSJMccMLY00KoUQ-ArPLprc$ >> >> >> Obviously we can make it better in Java while keeping it simple. For >> example: >> >> KEMEncapsulation = KEM.encapsulate(publicKey); byte[] ss = >> KEM.decapsulate(privateKey, CipherText); >> >> KEMEncapsualtion simply contains the shared secret (ss) and >> CipherText? >> >> >> Or to fit with init() pattern the rest of them use: >> >> KEM.init(publicKey); >> KEMEncapsulation = KEM.encapsulate() >> >> byte[] cipherText = KEMEncapsulation.getCipherText(); >> >> And then >> KEM.init(privateKey); >> byte[] ss = KEM.decapsulate(cipherText) >> >> or maybe even better: >> KEM.init(publicKey); >> byte[] cipherText = KEM.encapsulate() >> byte[] sharedSecret = KEM.getSharedSecret() >> >> And then >> KEM.init(privateKey); >> byte[] ss = KEM.decapsulate(cipherText) >> >> >> Cheers, >> >> John Gray >> >> >> >> >> From: David Hook >> Sent: Sunday, August 21, 2022 10:51 PM >> To: Michael StJohns ; John Gray < >> John.Gray at entrust.com> >> Cc: security-dev at openjdk.org >> Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) >> architecture being proposed for the JCA? >> >> WARNING: This email originated outside of Entrust. >> DO NOT CLICK links or attachments unless you trust the sender and know >> the content is safe. >> >> I'd have to agree about PKCS 11. >> >> One more thing about the PQC KEMs - the KDF step is built in. As >> you've mentioned, previously there's been a lot of possible >> combinations with key agreement, with PQC KEMs this has changed (of >> course, you could still use a KDF too, but the original reasons for >> doing so no longer apply). >> >> Regards, >> >> David >> >> On 21/8/22 13:52, Michael StJohns wrote: >>> On 8/20/2022 2:08 PM, David Hook wrote: >>>> Hi Michael, >>>> >>>> I don't know anything about bureaucrats, I am an engineer. You may >>>> need to consult someone else on bureaucrats. >>>> I apologize for my apparent deficiencies in this area, but would >>>> you mind explaining how Cipher.wrap() is either supposed to take a >>>> public key and create an encapsulation based on it and return a >>>> secret key implicitly in one clean move, or why it even makes >>>> sense to do so. The method was never conceived as providing the >>>> functionality for what a KEM actually does, and when I did the >>>> initial PKCS11 implementation at Eracom in the late 90's and the >>>> team at Sun added the wrap/unwrap functions to support it, this is >>>> definitely not was intended either - it was for explicit key >>>> wrapping based on the key that was passed to Cipher.init(). >>>> >>> First - PKCS11 is a 40 year old API that probably needs to be >>> retired. I spent the better part of 2 years working with the >>> PKCS11 Oasis group trying to get them to properly support master >>> secrets and KDFs and failed utterly. You should not use PKCS11 as >>> an example that the JCE should use as a goal. >>> >>> >>> >>> At the base, a java class is a collection of objects. A Cipher >>> object >>> >>> Let's build a non-parameterized ECIES-KEM which implicitly uses >>> AES256 bit keys to key a GCM cipher, and a KDF based on SP800-108 >>> counter mode with SHA256 as the underlying hash, and with a well >>> known label and context for the KDF since there is a new key for >>> every wrap. >>> >>> 1) Implement CipherSpi - >>> >>> public class EciesKemCipher extends CipherSpi { >>> >>> private KeyAgreement ka; >>> private Cipher gcm; >>> private KeyPair kp; >>> private KeyPairGenerator kg; >>> >>> EciesKemCipher() { >>> ka = KeyAgreement.getInstance("ECDH"); >>> kpg = KeyPairGenerator.getInstance ("EC"); >>> gcm = Cipher.getInstance ("AES/GCM/NoPadding"); >>> >>> } >>> >>> // implement a single example >>> >>> @override >>> protected void engineInit (int opMode, Key key, SecureRandom >>> dontcare) { >>> >>> switch (opMode) { >>> Cipher.MODE_WRAP: >>> initWrap((ECPublicKey) key); >>> break; >>> default: >>> // unimpl >>> } >>> } >>> >>> private void initWrap (ECPublicKey k) { >>> >>> ECParameterSpec spec = k.getParams(); >>> kpg.initialize(spec); >>> kp = kpg.genKeyPair(); >>> ka.init (kp.getPrivate()); >>> ka.doPhase (k, true); >>> byte[] sharedSecret = ka.generateSecret(); >>> >>> byte[] keyStream = kdf(sharedSecret, 32 + 12); // output >>> 44 bytes for Key and IV >>> SecretKeySpec gcmKey = new SecretKeySpec (keyStream, 0, >>> 32, "AES"); >>> IvParameterSpec gcmIv = new IVParameterSpec(keyStream, 32, >>> 12); >>> >>> gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); >>> // all ready to go >>> } >>> >>> >>> protected byte[] engineWrap (Key k) { >>> >>> ByteBuffer outData = ByteBuffer.allocate >>> (k.getEncoded().length + kp.getPublic().getEncoded().length) + 16; >>> >>> // Place a copy of the ephemeral public key I generated >>> in init here for the use of the receiver. >>> outData.put (kp.getEncoded()); >>> // One s >>> outData.put (gcm.doFinal(k.getEncoded()); >>> >>> outData.flip(); >>> byte[] result = outdata.remaining(); >>> >>> outData.get(result); >>> // kp = null; clear cipher if it hasn't already been >>> cleared, clear ka if necessary (e.g. un-init) >>> >>> return result; >>> } >>> >>> ... and unwrap and kdf function >>> } >>> >>> >>> >>> 2) Implement a provider and add the above. >>> >>> >>> >>>> On BC's part, we've already implemented RFC 5990/SP 800-56B in >>>> Java and the experience has, at best, been awkward. The new >>>> algorithms have moved awkward to inappropriate. With the new >>>> algorithms, there's no longer only one case of this, it's not an >>>> outlier, there should be a general way of supporting KEMs in the >>>> API that doesn't involve over engineering KeyGenerator and Cipher. >>>> >>> There's a big difference between the API and your underlying >>> implementation. Everything you want to do can be done using the >>> current APIs. As I said before, Cipher.wrap/unwrap are the >>> appropriate APIs for this as they meet the contract requirements >>> you need. Most Ciphers require some extra data -e.g. IVs - that >>> have to either be carried or implicitly derived. In this case, what >>> needs to be carried in addition to the encrypted key material >>> is at least the ephemeral public key the wrapper creates. I used >>> a very simple encoding scheme above and this assumes that both ends >>> know exactly what "ECIES-KEM" means. Obviously, there are 100s of >>> possible combinations of parameters and KDFs and key wrap >>> algorithms. What I would suggest is heading over to LAMPS at the >>> IETF and proposing a data encoding scheme for carrying the >>> parameters. Once you have that done, then come here and map JCE >>> names against parameter sets to close the loop. It won't require an >>> API change. >>> >>>> I work with a team that has had to implement all of them and had >>>> to make them fit into the JCA. We have done so. Like John, I am >>>> simply relaying our experience. In about 18 months these >>>> algorithms are going to become mandatory, what all of us think is >>>> irrelevant. We, for our part, already have a solution, but we both >>>> realize it's not "the solution" - we recognize that the JVM is >>>> uniquely positioned to provide leadership on this and provide a >>>> universal way of doing it. >>>> >>> Then suggest an API and we'll start knocking it around. I >>> personally don't think its necessary at this time and will add to >>> API bloat. >>> >>>> Of course, if it's felt that these algorithms should be ignored, >>>> it's not my place to revolt, although I do feel obliged to argue. >>>> I will simply try and do the best by my users, as I have no doubt >>>> will John. Both of us have simply offered our comments in good >>>> faith and to alert the community that things have changed and that >>>> with these new algorithms there is room for a new approach. >>>> The ambiguity about how these algorithms can be implemented and >>>> the excessive need to fallback on propritary classes for them does >>>> suggest that there are some additions to the JCA which would help. >>>> I appreciate to understand this statement does involve actually >>>> understanding what these algorithms do and may require some >>>> additional reading. >>>> >>>> As I said, I'm an engineer, my users will be able to use these >>>> algorithms properly, my team will ensure that, as I have no doubt >>>> will John's. What John and myself, apparently mistakenly, care >>>> about is that our users should also be able to use these >>>> algorithms portably. >>>> >>>> Are you saying portability is no longer a consideration? >>>> >>> I have no idea where you got that idea. >>> >>>> Regards, >>>> >>>> David >>>> >>>> >>>> >>>> On 21/8/22 02:23, Michael StJohns wrote: >>>>> Hi David/John - >>>>> >>>>> I would submit that you're trying too hard to make your life >>>>> simple! :-) >>>>> >>>>> Cipher.wrap/unwrap are the correct methods. >>>>> >>>>> For example: >>>>> >>>>> Cipher kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800- >>>>> 108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); >>>>> byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); >>>>> >>>>> The "opaqueEncapsulatedKey" would contain the data needed by the >>>>> unwrap function - specifically a) the ecies ephemeral public >>>>> key, b) the fact that the derived key is a GCM key of length 128 >>>>> and that the GCM tag is 64 bytes long, c) the KDF, >>>>> d) (optional) any mixins other than defaults required by the KDF >>>>> - which would be passed in a parameter blob during init. >>>>> Cipher would NOT return the underlying generated secret used to >>>>> wrap the key. Just the public part of the key pair used to do >>>>> the ECDH operation against the passed in public key. In the >>>>> RSA case, the wrapped encrypting secret would be an opaque data >>>>> blob and would be part of the data passed to the unwrap >>>>> function. >>>>> >>>>> If you want a key generated for other purposes, then the right >>>>> thing is using a KDF and a Key agreement function in tandem. >>>>> Strangely the KDF appears in the javacard API for 3.1, but not >>>>> in the JCE/JDK API. >>>>> >>>>> "What's the difference between a bureaucrat and an engineer? A >>>>> bureaucrat takes small solvable pieces and combines them into >>>>> one insoluble mass." >>>>> >>>>> In this case, Java provides a number of flexible primitives that >>>>> can be combined as needed. In this case, the underlying Cipher >>>>> implementation would wrap key agreement and kdf and cipher (GCM) >>>>> instances. It should return UnsupportedOperationException for >>>>> all operations execept wrap/unwrap and the appropriate init >>>>> methods. >>>>> >>>>> Later, Mike >>>>> >>>>> >>>>> >>>>> On 8/19/2022 6:38 PM, David Hook wrote: >>>>>> Hi Mike, >>>>>> >>>>>> KEMs can be used for key wrapping - we've actually implemented >>>>>> support for this too. But they are not actually key wrapping >>>>>> ciphers. >>>>>> >>>>>> Here's a simple example of using Kyber for key wrapping in >>>>>> BC: >>>>>> >>>>>> SecretKey key = new SecretKeySpec(keyBytes, "AES"); >>>>>> >>>>>> w1.init(Cipher.WRAP_MODE, kp.getPublic(), new >>>>>> KEMParameterSpec("AES-KWP")); >>>>>> >>>>>> byte[] data = w1.wrap(key); >>>>>> >>>>>> Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); >>>>>> >>>>>> w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new >>>>>> KEMParameterSpec("AES-KWP")); >>>>>> >>>>>> Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); >>>>>> >>>>>> The behavior in this case is in line with what is given in RFC >>>>>> 5990 for the RSA KEM. How it works is by using the key >>>>>> generated by the KEM to create an AES-KWP key, which is then >>>>>> used to wrap keyBytes. The shortcoming is it means you have to >>>>>> generate the secret key separately. >>>>>> >>>>>> This is the problem though - a KEM can actually be used to >>>>>> generate a secret key for other purposes. For example, where >>>>>> someone is trying to implement a hybrid KAS scheme. But there >>>>>> is currently no mechanism in the Java APIs for being able to >>>>>> take advantage of this directly, hence our use of the >>>>>> KeyGenerator class and other people's attempts to make use of >>>>>> the KeyAgreement class. The Cipher.wrap() returns a byte[] - >>>>>> to be used with a KEM for secret generation it would also have >>>>>> to return the generated secret (I would probably also argue >>>>>> that passing a public key to wrap in order to generate an >>>>>> encapsulation of a generated encrypted secret was not the >>>>>> correct use of the API either, but the fact remains a byte[] >>>>>> is not really going to cut it). >>>>>> >>>>>> If you have any further questions, please feel free to ask. >>>>>> For what it is worth, I have been developing providers for the >>>>>> JCE/JCA since the late 90's and am actually one of the people >>>>>> responsible for the introduction of the existing wrap/unwrap >>>>>> API in the Cipher class. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David >>>>>> On 20/8/22 07:53, Mike StJohns wrote: >>>>>>> Hi This implemented as part of Javax.crypto.Cipher. See the >>>>>>> Java doc for the wrap and unwrap methods. >>>>>>> >>>>>>> Mike >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>>> On Aug 19, 2022, at 12:56, John Gray < >>>>>>>> John.Gray at entrust.com> wrote: >>>>>>>> >>>>>>>> ? We are starting to make use of the new PQ algorithms >>>>>>>> adopted by NIST for prototyping and development of >>>>>>>> standards. In particular we are working on a composite >>>>>>>> KEM standard: >>>>>>>> See: >>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/d >>>>>>>> oc/draft-ounsworth-pq-composite-kem/__;!!FJ-Y8qCqXTj2!dRvG >>>>>>>> TjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVq >>>>>>>> x3ZsUUu2AVJSJMccMLY00KoUQ-K6fkXJ8$ >>>>>>>> >>>>>>>> However, there is no KEM interface in the JCA (which make >>>>>>>> sense because these are new algorithms, although RSA-KEM >>>>>>>> has been out since 2010). >>>>>>>> >>>>>>>> I can add one into our toolkit (and I think David may have >>>>>>>> already added on into BC), but I assume at some point >>>>>>>> there will be an official one added in Java and likely it >>>>>>>> won't be identical to what we do even if it is very close, >>>>>>>> which would cause backwards compatibility >>>>>>>> pain... Perhaps we could collaborate on extending the >>>>>>>> JCA to support KEM? Essentially it requires methods. >>>>>>>> >>>>>>>> ss, ct := encapsulate(PublicKey) ss := >>>>>>>> decapsulate(PrivateKey, ct) >>>>>>>> >>>>>>>> -ss is a shared secret (could come back as a Java >>>>>>>> SecretKey if you wanted as it would usually be used to >>>>>>>> derive something like an AES afterwards) -ct is a Cipher >>>>>>>> Text (a byte array would make sense) -Public and Private >>>>>>>> Keys would use the regular public and private key >>>>>>>> interface. >>>>>>>> -An object holding the ss and ct from the encapsulate() >>>>>>>> method could be returned, with accessor methods to get >>>>>>>> the ss and ct. It could be called 'EncapsulatedKEMData' >>>>>>>> for example. >>>>>>>> >>>>>>>> Likely you would want a new type of KEM crypto object >>>>>>>> (like you have for Signature, MessageDigest, Cipher, Mac, >>>>>>>> SecureRandom, KeyAgreement.. etc). Calling it KEM would >>>>>>>> seem to make sense. ? It could also use similar >>>>>>>> calling patterns and have a >>>>>>>> KEM.initKEM(keypair.getPublic()) or >>>>>>>> KEM.initKEM(keypair.getPrivate()), and then you would just >>>>>>>> call KEM.encapsulate() or KEM.decapsulate(ct). >>>>>>>> >>>>>>>> Then algorithms could be registered in providers as >>>>>>>> usual: >>>>>>>> >>>>>>>> put("KEM.Kyber","com.blah.Kyber") >>>>>>>> >>>>>>>> put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.co >>>>>>>> mpositeKEM") >>>>>>>> >>>>>>>> Then the above methods (encapsulate and decapsulate) >>>>>>>> could be defined in that new object type. Then we would >>>>>>>> be able to make use of it and not have to worry about >>>>>>>> incompatibility issues down the road... >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> John Gray >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Any email and files/attachments transmitted with it are >>>>>>>> confidential and are intended solely for the use of the >>>>>>>> individual or entity to whom they are addressed. If this >>>>>>>> message has been sent to you in error, you must not copy, >>>>>>>> distribute or disclose of the information it contains. >>>>>>>> Please notify Entrust immediately and delete the message >>>>>>>> from your system. >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -- > Franco Nieddu > SIC - Software Engineer > Phone: +43 (316) 873 - 5507 > SIC Homepage: https://urldefense.com/v3/__https://jce.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-2W4oa1s$ > IAIK Homepage: https://urldefense.com/v3/__https://www.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-Ov0Iano$ > From valeriep at openjdk.org Thu Aug 25 23:33:57 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 23:33:57 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 15:06:04 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update test to use SHA256 and DSA throughout. > > test/jdk/java/security/Security/ProviderFiltering.java line 109: > >> 107: filters.put("Signature.SHA256withDSA", ""); >> 108: doit(filters, p); >> 109: filters.put("Cipher.Nonexisting", ""); > > Even if it's not "Nonexisting", I assume it's still empty after filtering? You mean the result should be empty even if it's not "Nonexisting"? Yes, the result is empty even if you change to use "AES" instead of "Nonexisting". ------------- PR: https://git.openjdk.org/jdk/pull/10008 From valeriep at openjdk.org Thu Aug 25 23:58:56 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Thu, 25 Aug 2022 23:58:56 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 15:25:57 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> update test to use SHA256 and DSA throughout. > > src/java.base/share/classes/java/security/Security.java line 530: > >> 528: // . : >> 529: key = filter.substring(0, index); >> 530: value = filter.substring(index + 1); > > Do you need to ensure `value` is non-empty here? I am worried that somewhere later a `string.indexOf("")` is called and it's always true. Makes sense, I will add a check. Thanks! > src/java.base/share/classes/java/security/Security.java line 931: > >> 929: // check individual component for match and bail if no match >> 930: if (prop.indexOf(st.nextToken()) == -1) { >> 931: return false; > > So if `value` has several sub-values, all of them must appear in the `prop` value. Do we need to make this clear in the spec? > > Also, you use `indexOf` instead of an exact match to a sub-value in `prop`. Is this always correct? I am wondering if a value can be substring of a different value. I see you support simple class name in the test. Is it worth we doing this? I would rather be strict at the beginning. Yes, I'd expect if multiple sub-values are specified, it means all of them should appear in `prop` in order to be matched. It does raise an interesting question as to how to do the filtering based on an "OR" relationship. Perhaps an union of 2 separate filter result? I'd suspect that "AND" relationship would be more useful. One alternative is to disallow multiple sub-values, and treat the value as one sub-value. Thoughts? As for strict vs loose, I am on the fence, thought that it'd be nice to not having to enter the entire value. Could switch direction to be strict for now and loosen it up if requested. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From weijun at openjdk.org Fri Aug 26 00:31:53 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Aug 2022 00:31:53 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 23:31:53 GMT, Valerie Peng wrote: >> test/jdk/java/security/Security/ProviderFiltering.java line 109: >> >>> 107: filters.put("Signature.SHA256withDSA", ""); >>> 108: doit(filters, p); >>> 109: filters.put("Cipher.Nonexisting", ""); >> >> Even if it's not "Nonexisting", I assume it's still empty after filtering? > > You mean the result should be empty even if it's not "Nonexisting"? Yes, the result is empty even if you change to use "AES" instead of "Nonexisting". Yes, that's what I mean. Otherwise it looks like it's because of the "NonExisting" word that makes the result empty. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From weijun at openjdk.org Fri Aug 26 00:41:57 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 26 Aug 2022 00:41:57 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Thu, 25 Aug 2022 23:54:05 GMT, Valerie Peng wrote: >> src/java.base/share/classes/java/security/Security.java line 931: >> >>> 929: // check individual component for match and bail if no match >>> 930: if (prop.indexOf(st.nextToken()) == -1) { >>> 931: return false; >> >> So if `value` has several sub-values, all of them must appear in the `prop` value. Do we need to make this clear in the spec? >> >> Also, you use `indexOf` instead of an exact match to a sub-value in `prop`. Is this always correct? I am wondering if a value can be substring of a different value. I see you support simple class name in the test. Is it worth we doing this? I would rather be strict at the beginning. > > Yes, I'd expect if multiple sub-values are specified, it means all of them should appear in `prop` in order to be matched. It does raise an interesting question as to how to do the filtering based on an "OR" relationship. Perhaps an union of 2 separate filter result? I'd suspect that "AND" relationship would be more useful. One alternative is to disallow multiple sub-values, and treat the value as one sub-value. Thoughts? > > As for strict vs loose, I am on the fence, thought that it'd be nice to not having to enter the entire value. Could switch direction to be strict for now and loosen it up if requested. The spec says the result of `getProviders(map)` must satisfy all criteria, so we already have AND. That sounds like it's better to treat multiple values in a single criterion to be OR. In fact, I don't know who would want to check for OR. For example, a user might be OK with either GCM or CCM, but it still makes no sense to check for "GCM or CCM". After all, at the end they need to decide whether to call `getInstance("GCM")` or `getInstance("CCM")`. They'd better call `getProviders()` twice to find out which exact one is supported. Maybe we can only support one value at the moment. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From valeriep at openjdk.org Fri Aug 26 01:17:01 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 26 Aug 2022 01:17:01 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v2] In-Reply-To: References: <-ws8CzY5840jultJy8Nbs9e146U43kKFKKTHiHgprQo=.f4c7dbb7-1c01-4d72-a688-287c0f506bcf@github.com> Message-ID: On Fri, 26 Aug 2022 00:38:36 GMT, Weijun Wang wrote: >> Yes, I'd expect if multiple sub-values are specified, it means all of them should appear in `prop` in order to be matched. It does raise an interesting question as to how to do the filtering based on an "OR" relationship. Perhaps an union of 2 separate filter result? I'd suspect that "AND" relationship would be more useful. One alternative is to disallow multiple sub-values, and treat the value as one sub-value. Thoughts? >> >> As for strict vs loose, I am on the fence, thought that it'd be nice to not having to enter the entire value. Could switch direction to be strict for now and loosen it up if requested. > > The spec says the result of `getProviders(map)` must satisfy all criteria, so we already have AND. That sounds like it's better to treat multiple values in a single criterion to be OR. > > In fact, I don't know who would want to check for OR. For example, a user might be OK with either GCM or CCM, but it still makes no sense to check for "GCM or CCM". After all, at the end they need to decide whether to call `getInstance("GCM")` or `getInstance("CCM")`. They'd better call `getProviders()` twice to find out which exact one is supported. > > Maybe we can only support one value at the moment. Hmm, ok, then let's just do one-subvalue for now. We can always enhance it later if needed. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From xuelei at openjdk.org Fri Aug 26 04:36:00 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 26 Aug 2022 04:36:00 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: On Thu, 25 Aug 2022 21:03:35 GMT, Xue-Lei Andrew Fan wrote: >> @XueleiFan - I think it's fair to say that the current "no cipher suites in common" exception message is misleading for some scenarios. If not misleading, it's ambiguous. You could be dealing with a simple scenario where the server socket simply has no enabled cipher suites to match those coming in from the ClientHello. In the more complex scenario, something else has caused the fatal issues like a key exchange issue in TLSv1.2. With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. >> >> I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required. >> >> If you feel strongly about printing debug data for each TLSServerSocket handshake, (including the extra data points that you've suggested) then please shout now. I do feel it'll add considerably to log size on busy TLS Servers. > > @coffeys Before we go further, I think we'd better have a look if the information added could help for debugging. I'm not sure of that now. > >> With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. > > If I understand correctly, the preference of client or server suites should not impact the success of handshaking. Did you see examples otherwise in practice? What's the purpose by adding this information for failed handshaking? > > The client authentication type is also logged for failed server hello handshake message. What's the purpose for the adding? Did you see server hello failure that caused by client authentication type in practice? > > With server debug log enabled, there have already been a lot debug information, especially for verberos debug mode. Is it a really concern to you to dump server enabled cipher suites, just as the dump of ClientHello message? Yes, it make debug logger worse for a busy server, but the impact may be 1/10K? > > I have to run for now, and will try to reply more for your comments. Thanks! > I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required. Does the switch on/off the "verbose", "data" or "record" debug option help to reduce the log verbosity? In general, I'm not sure how on failing handshake scenarios could help to make the debug better. Thinking about the failure of the ServerHello in this case, it could be related to ClientHello, named groups/key exchange algorithms, signature algorithms, key store, certificate signature, certificate key algorithms, certificate key length, etc. If these information does not dump when the ClientHello is good, I'm not sure if the developer understand better about what could be the cause from the server cipher suite preference, client authentication types and server enabled cipher suites. Well, we can dump everything in the printServerSocketConfig() method, but do we know everything in the context of printServerSocketConfig and is it easy to maintain the things in the method. I'm not sure of that. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From xuelei at openjdk.org Fri Aug 26 04:36:58 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 26 Aug 2022 04:36:58 GMT Subject: RFR: 8245654: Add Certigna Root CAs In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote: > This fix adds Certigna root CA to cacerts trust store. Marked as reviewed by xuelei (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10030 From mullan at openjdk.org Fri Aug 26 10:42:54 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 10:42:54 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> Message-ID: <4aRNq6CvxBWfwyGegSrfM9QPW2RNxAAMxAYb68oG0hI=.8ed14760-83c1-4d6a-afb7-8d5a5ea5441c@github.com> On Thu, 25 Aug 2022 18:44:54 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/jca/ProviderList.java line 129: >> >>> 127: int j = 0; >>> 128: for (ProviderConfig config : providerList.configs) { >>> 129: if (!Objects.requireNonNull(config.getProvider()).getName().equals(name)) { >> >> This is an unusual usage of `Objects.requireNonNull`. Is a null provider ever expected here? I don't see why this is better, the prior code will also throw NPE. Replacing `== false` with `!` is ok though. >> >> Same comment on other cases in this file. > > IntelliJ seems to think it could. The point of requireNonNull is that you control when an exception is thrown, and sooner rather than later is better. This code appears to have been working fine for a long time, so maybe NPE can't happen in practice. I'm fine with reverting this requireNonNull change here and elsewhere if you think it is unnecessary. Right, but in this case I think if an NPE is ever thrown it would be considered a bug in the JDK because an unexpected RuntimeException would be thrown. I think requireNonNull is used more in cases where caller input is being validated and null is not valid. I find this code less readable. There are lots of cases in the JDK code where some object could theoretically be null, but it would be a bug if it was. If it was a normal case for a provider to sometimes be null here, then I would expect this code to check for null and handle it. @valeriep is more familiar with this code, so I would also like her feedback on these changes to use requireNonNull. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mullan at openjdk.org Fri Aug 26 10:53:13 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 10:53:13 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Thu, 25 Aug 2022 15:07:27 GMT, Sean Mullan wrote: >> https://bugs.openjdk.org/browse/JDK-8291509 > > src/java.base/share/classes/sun/security/jca/Providers.java line 104: > >> 102: * Start JAR verification. This sets a special provider list for >> 103: * the current thread. You MUST save the return value from this >> 104: * method, and you MUST call stopJarVerification() with that object > > Hmm, I'm not sure this is more grammatically correct. same here about dependent clause case. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mullan at openjdk.org Fri Aug 26 10:53:13 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 10:53:13 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> Message-ID: On Thu, 25 Aug 2022 18:45:10 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/jca/Providers.java line 212: >> >>> 210: >>> 211: // Change the thread local provider list. Use only if the current thread >>> 212: // is already using a thread local list, and you want to change it in place. >> >> Hmm, I'm not sure this is more grammatically correct. > > I could go either way. The sentence is not that long (it's not a German sentence). IJ is only a recommendation. I'm not a grammar expert, but I think using a comma before and is not necessary here and possibly incorrect. See https://www.grammarly.com/blog/comma-before-and/. This seem like a "dependent clause" case. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mullan at openjdk.org Fri Aug 26 10:59:56 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 10:59:56 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> Message-ID: <4q0wnlPCrSPkF_cyQIX31S5HDizdH7BtbPyhdLSBkGA=.56e90b34-2f84-4a2e-87a7-ec8c5d88c494@github.com> On Thu, 25 Aug 2022 18:44:59 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/jca/ProviderList.java line 679: >> >>> 677: private final String algorithm; >>> 678: private final String provider; >>> 679: private String[] alternateNames = null; >> >> shouldn't this also be final? > > If I make alternateNames final, then IJ complains "cannot assign a value to final variable". > If I make it final and remove initialization, then make complains that alternateNames might not have been initialized. I would make it final, and then assign it to null in a final else block after line 719. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From franco.nieddu at iaik.tugraz.at Fri Aug 26 11:44:31 2022 From: franco.nieddu at iaik.tugraz.at (Franco Nieddu) Date: Fri, 26 Aug 2022 13:44:31 +0200 Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: <0320a143-178d-6bfb-99cc-8cff28cae426@cryptoworkshop.com> References: <814F78E4-9932-427B-8B65-1AFE5F9D32E2@comcast.net> <783df5b7-e30f-08e7-dbc3-e3d95f427c18@comcast.net> <6f95c68c-4cc6-a039-189e-1d4b75b16ca1@cryptoworkshop.com> <6a9103b9-75ab-6bdf-465f-8d966d7d3476@comcast.net> <8b2d8bc7-9455-a8c2-d339-d62cccce4833@cryptoworkshop.com> <0320a143-178d-6bfb-99cc-8cff28cae426@cryptoworkshop.com> Message-ID: <8302651b2e0d966ff4d7eae56703e2a86f5053d0.camel@iaik.tugraz.at> Hi again to John, David, and all! Yeah, I am glad you guys initiated the discussion regarding the API extension. Internally, we already wondered how the JCA would move forward, and I think everyone who tried to map the PQC KEMs, realized pretty fast that the existing API does not fit. With that out of the way, here is a code fragment to use our API with KYBER: final String algorithm = "KYBER"; KeyPairGenerator kpg = KeyPairGenerator.getInstance(algorithm); kpg.initialize(new KyberAlgorithmParameterSpec()); KeyPair keyPair = kpg.generateKeyPair(); //encap KeyEncapsulationMechanism encap = KeyEncapsulationMechanism.getInstance(algorithm); encap.init(keyPair.getPublic()); //encap.init(keyPair.getPublic(), new SecureRandom()); //encap.init(keyPair.getPublic(), new SaberAlgorithmParameterSpec()); //encap.init(keyPair.getPublic(), new SaberAlgorithmParameterSpec(), new SecureRandom()); byte[] sessionKeyEncap = new byte[32]; byte[] cipher = encap.encapsule(sessionKeyEncap); //decap KeyEncapsulationMechanism decap = KeyEncapsulationMechanism.getInstance(algorithm); decap.init(keyPair.getPrivate()); //the init methods are the same byte[] sessionKeyDecap = new byte[32]; decap.decapsule(cipher, sessionKeyDecap); For key generation, we use the existing KeyPairGenerator API. We modeled the different parameter sets as AlgorithmParameterSpecs, where a caller may request one of NIST's security levels, and the implementation returns the appropriate parameter set. As you proposed, we could use a generic KEMAlgorithmParameterSpecs and derive the parameter sets from the provided keys. This approach works for the PQC algorithms. However, this does not work with RSA-KEM (deriving the parameters from the key). Anyhow, I do not know how important RSA-KEM is moving forward (it never was, to begin with, sadly). I just wanted to point it out. At the moment, there are four ways to initialize a KEM object. The implementation derives the mode (encap, decap) from the provided key; therefore, all init() methods require a key. Furthermore, if possible, it derives the parameters from the key. The other init() methods are self-explanatory, I guess. Regarding the byte array initialization, yes, you are right. Your approach is also possible. We went with this approach because we wanted a possibility for the caller to specify the output length as the output of KDFs is of variable length, and we use the AlgorithmParameterSpecs already to map the different parameter sets. I would argue that the size of the byte[] is not a problem because if two parties want to share a secret, they need to know at least what they use the secret for, and therefore, I think we can assume that they know their respective public, global parameters (including the secret size). This assumption may be too conservative, and I do not have a strong opinion, so if there are arguments for a different approach, I would be glad to change our interface. Furthermore, we designed the API in a way that there is a strict segregation from the KDF and underlying Public-Key Encryption. To be honest, we did not consider a size mismatch of the provided byte array and the KEM instance in our implementation because all KDFs we included so far are inherently unlimited in size, but maybe we did miss something. I am, of course, open to improvements and would be glad to discuss all of this. Currently, I live in Central Europe (Austria, CEST/UTC+2). I would rather discuss this in person instead of by e-mail, but finding a suitable time slot could be difficult. I have no problem with getting up early for a constructive discussion ;) Cheers, Franco On Fri, 2022-08-26 at 08:36 +1000, David Hook wrote: > Happy to offer any assistance I can. > The existing API maps well for key wrapping if you follow the example > of RFC 5990 - the RSA-KEM - but for actual secret sharing, every > solution that "fits", including our current one, doesn't really fit > either the JCA, or the algorithms themselves. > Even with our current solution, overloading the KeyGenerator class, > it only solves a specific use case. It's obvious there are others, so > the solution means the burden on the parameter spec classes is just > going to get worse. A more general solution would mean we would only > have to explain things once, rather than once each. > Regards, > David > On 26/8/22 00:49, John Gray wrote: > > Thanks Franco, > > > > I am very familiar with the IAIK toolkit as our Entrust Java > > toolkit actually makes use of the IAIK ASN.1 library from a 2003 > > version and IAIK and Entrust used to work very closely together > > regarding our toolkits in the early 2000's. So I think between > > the 3 of us we represent a majority of the JCA cypto toolkits that > > exist (except for BSAFE which I have never used). So it is great > > to see we agree that there needs to be KEM classes added to the JCA > > as we have all struggled with fitting KEM into the JCA. > > > > We certainly want their to be an interoperable implementations of > > KEM. Franco, could you send a simple sample of doing a KEM > > keygen and then the encapsulate and decapsulate with your API? I > > am assuming the public and private keys are initialized in an > > init() method of some sorts? I see the encapsule(byte[] k) method > > assumes you know the size of the shared-secret, and expects you to > > size the array as a way to specify the size of the secret you > > want. If you are using a KEM with a fixed Cipher size, or you use > > the wrong size (by mistake), or you later decided to change to a > > different KEM that uses a different size then maybe that might > > cause issues? Perhaps just have a init() that takes a public or > > private key and a KEMParameterSpec (of type AlgorithmParameterSpec) > > that has an option to specify the SharedSecret size would be > > better? If you don't specify anything it could use the default > > provided by the KEM, or if you provide a size then it could be > > used. Then returning the shared secret in a separate method, or > > an Object that includes both the CipherText and shared-secret could > > work. Then this would remove the possibility of byte array > > initialization issues... Doing thing might also help to make the > > same code more crypto agile as you could easily switch from say > > Kyber to McEliece or Composite KEM just by changing the > > getInstance() call and modifying the KEMParameterSpec object. > > > > Perhaps we could meet together sometime and hash out a KEM API we > > all agree on and then propose it to Oracle/OpenJDK? If it is not > > accepted and OpenJDK/Oracle has no plans to add a KEM API we could > > just agree to implement it in our own toolkits and then at least we > > would have a common KEM interface for use across our toolkits? We > > could also do it over email if time-zones don't work out. I know > > David is in Australia, I am in Canada (Eastern Time). > > > > Cheers, > > > > John Gray > > > > > > -----Original Message----- > > From: Franco Nieddu > > Sent: Thursday, August 25, 2022 2:33 AM > > To: John Gray ; David Hook < > > dgh at cryptoworkshop.com>; Michael StJohns > > Cc: security-dev at openjdk.org > > Subject: Re: [EXTERNAL] Re: Is there a KEM (Key Encapsulation > > Mechanism) architecture being proposed for the JCA? > > > > Hi David, Michael, and John, and everyone else! > > > > I will give my two cents to the Cipher/KEM topic and add on the > > latest mail from John. For why this topic is interesting to me, I > > work at the TU Graz, where we have developed the IAIK-JCE Provider > > since the beginning of the 2000s. > > > > Anticipating the end of NIST's PQC, we started implementing the > > third- round KEMs approximately a year ago. > > > > I have to agree with David and John. KEMs and Ciphers are strictly > > different. To map KEMs operations to the existing API, we would be > > forced to break a lot of the contracts/definitions of multiple > > classes, but at the bare minimum from the Cipher.wrap(Key) method > > itself. Moving forward, KEMs will rise in popularity, and we should > > reduce confusion for developers using our libraries. > > It may be possible to use e.g., McEliece as an asymmetric cipher, > > but I would not want my users to start using McEliece in such a > > way. Clear segregation would help prevent this. The other option > > will be to throw exceptions if a caller provides something > > different than WRAP_MODE in Cipher.init(), breaking more contracts. > > Furthermore, the Cipher.unwrap(byte[], String, int) method is > > tedious to use, but maybe this is just me... > > > > In his last message, John showed, better than I could, that the > > KeyAgreement classes only fit with great difficulty. > > > > The API mapping just does not work, and there is no denying that. > > Nevertheless, the biggest issue I have (if we ignore all the broken > > contracts for a moment) is the serialization/deserialization of the > > ciphertext-secret pair. The Cipher.wrap() method simply does not > > allow to return both values. Concating the two values into a single > > byte array just begs for incompatibility between implementations. > > Another option to return the ciphertext and the secret to the > > caller is by defining a new class/interface like: > > > > public final class KEMSecret implements Key { > > > > private byte[] secret_; > > > > > > public final void setSecret(byte[] secret) { > > this.secret_ = secret; > > } > > > > public final byte[] getSecret() { > > return this.secret; > > } > > } > > > > Then enforce that for all KEMs, the Cipher.wrap() method uses this > > KEMSecret as parameter, breaking another contract, as the KEMSecret > > IS NOT a key (it can be but is not limited to). > > > > > > > > Our implementation for the moment looks something like this: > > > > public abstract class KeyEncapsulationMechanismSpi { > > //some init methods.... > > protected abstract void engineDeriveKey(byte[] output, > > byte[]... > > input) throws DigestException; > > protected abstract byte[] engineEncapsule(byte[] k) throws > > InvalidKeyException, DigestException; > > protected abstract void engineDecapsule(byte[] c, byte[] k) > > throws InvalidKeyException, DigestException; } > > > > The engineDeriveKey() method is a call to a KDF (for the PQC always > > SHAKE), where output is the derived key, and the varargs depict the > > input to the KDF. At least in McEliece, there are multiple calls to > > the KDF; therefore, adding a separate engine method seemed > > reasonable. > > Furthermore, it is possible to plug in different KDFs for the same > > KEM instance. Taking inspiration from the Cipher classes, we could > > do something like: > > > > KEM.getInstance("Kyber/SHAKE128") or KEM.getInstance("Kyber/KDF3") > > > > At the moment, this is not necessary, but already defining a > > modular interface should at least be considered. > > > > engineEncapsule() returns the ciphertext of the encap operation. > > Additionally, the implementation fills the provided byte[] with the > > secret. The secret produced by KEMs is not strictly limited in > > size; therefore, it seemed appropriate to let the caller decide the > > size of the byte[]. > > > > engineDecapsule() is the inverse of engineEncapsule(). > > > > I am, of course, open to discussions regarding the actual > > implementation, e.g. returning the result as some kind of > > EncapsulatedKEMData as suggested by John, but I see the necessity > > of adding KEM classes to the security API. > > > > To close this already long message, something about bureaucrats. > > Bureaucrats, at least in my country, are fond of the status quo. > > Luckily, we are not bureaucrats and are permitted to improve a > > barely working solution. > > > > Cheers, > > Franco > > > > On Wed, 2022-08-24 at 20:12 +0000, John Gray wrote: > > > Just catching up on emails. > > > > > > I agree about PKCS11 as well, but vast amounts of people use it > > > and I > > > don?t think it is going away anytime soon. > > > > > > This is a great discussion. > > > > > > So Michael, I think you are saying we should be able to use a > > > combination of KeyAgreement and Cipher to implement a KEM in the > > > JCA. I think that works in practice for any existing Key > > > Agreement > > > or Cipher (that is what we essentially use in our IETF draft for > > > turning existing Key agreement or Cipher algorithms into a KEM). > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-oun > > > sworth-pq-composite-kem/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD- > > > gBr0pkO3DBu7 > > > Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ- > > > K6fkXJ8$ > > > > > > However, for a pure KEM like Kyber I don?t think you can just > > > assume > > > you will be able to break up the encapsulation() procedure which > > > returns a CipherText and Shared-Secret given a Kyber public key. > > > It defines the encapsulation and decapsulation operations (see > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ ). A > > > Cipher encrypt can?t model the Encapsulation operation as it just > > > returns a byte[]. I suppose a Cipher Decrypt could model the > > > Decapsulation() operation with the result being the shared > > > secret, > > > but that is only half the picture?. Kyber has internal > > > functions that do encrypt and decrypt like operations which could > > > be > > > modeled as a Cipher in JCA (but the message would have to be some > > > type > > > of specially formatted structure containing the m and cpaSeed > > > values, > > > or if a keywrap the public key would have to be structured along > > > with > > > those required values). So even if we did that, how do you > > > propose > > > the rest of the Kyber KEM operations fit in the current > > > Java JCA? It seems you would need to somehow split up the > > > components of the algorithm across different parts of the JCA and > > > would it be possible to hide the complexity as simply as adding a > > > KEM > > > JCA object type with an encapsulate() method and a decapsulate() > > > method? > > > > > > From > > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cfr > > > g-schwabe-kyber/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD- > > > gBr0pkO3DBu7Gf13fWJ4 > > > vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-TMAnNfc$ > > > > > > 11.2. Encapsulation > > > > > > Kyber encapsulation takes a public key and a 32-octet seed > > > and > > > deterministically generates a shared secret and ciphertext > > > for the > > > public key as follows. > > > > > > 1. Compute > > > > > > 1. m = H(seed) > > > > > > 2. (Kbar, cpaSeed) = G(m || H(pk)) > > > > > > 3. cpaCipherText = Kyber.CPAPKE.Enc(m, publicKey, > > > cpaSeed) > > > > > > 2. Return > > > > > > 1. cipherText = cpaCipherText > > > > > > 2. sharedSecret = KDF(KBar || H(cpaCipherText)) > > > > > > > > > 11.3. Decapsulation > > > > > > Kyber decapsulation takes a private key and a cipher text and > > > returns > > > a shared secret as follows. > > > > > > 1. Split privateKey into > > > > > > 1. A 12*k*n/8-octet cpaPrivateKey > > > > > > 2. A 12*k*n/8+32-octet cpaPublicKey > > > > > > 3. A 32-octet h > > > > > > 4. A 32-octet z > > > > > > 2. Compute > > > > > > 1. m2 = Kyber.CPAPKE.Dec(cipherText, cpaPrivateKey) > > > > > > 2. (KBar2, cpaSeed2) = G(m2 || h) > > > > > > 3. cipherText2 = Kyber.CPAPKE.Enc(m2, cpaPublicKey, > > > cpaSeed2) > > > > > > 4. K1 = KDF(KBar2 || H(cipherText)) > > > > > > 5. K2 = KDF(z || H(cipherText)) > > > > > > 3. In constant-time, set K = K1 if cipherText == cipherText2 > > > else > > > set K = K2. > > > > > > 4. Return > > > > > > 1. sharedSecret = K > > > > > > > > > > > > It can *sort of* fit with a KeyAgreement if you do this, but its > > > kludgy: > > > > > > On sending side: > > > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > > > > > Kem.init(null, KEMparameters) - I?m generating the CipherText > > > and > > > shared-secret for 1 other person, I don?t have their private key > > > and > > > its not multi-party > > > > > > KEMCipherTextKey = Kem.doPhase(Key kemPublicKey, true) byte[] > > > sharedSecret = generateSecret() > > > > > > > > > The KEMCipherTextKey contains the CipherText that just happens to > > > implements the Key interface. It is very weird, but we > > > something to > > > carry the cipher text. > > > > > > Send KEMCipherTextKey to the receiver: > > > > > > On receiving side: > > > KeyAgreement kem = KeyAgreement.getInstance(?Kyber?); > > > > > > Kem.init(KEMCipherTextKey, KEMParameters); -> The CipherTExt > > > is > > > the KEMCipherTExtKey > > > null = Kem.doPhase(KemPrivateKey, true) -> Shared secret is > > > generated > > > from CipherText and PrivateKey, but a Key object is not returned > > > byte[] sharedSecret = generateSecret() > > > > > > > > > So it can work, but it is kludgy. The placement of the keys > > > could > > > be reversed (the public and private keys could be passed in via > > > init, > > > then null in the first doPhase, and the CipherTextKey in the > > > second > > > doPhase. I don?t know which is better as it could work either > > > way. This just shows how it doesn?t fit cleanly? > > > > > > > > > > > > In the openSSL-OQS port which is in C, they have KEM?s defined > > > simply > > > as follows: > > > https://urldefense.com/v3/__https://github.com/open-quantum-safe/liboq > > > s/blob/main/src/kem/kem.h__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD- > > > gBr0pkO3DBu > > > 7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ- > > > st7vufc$ > > > > > > Which follows which NIST outlines in > > > https://urldefense.com/v3/__https://csrc.nist.gov/CSRC/media/Projects/ > > > Post-Quantum-Cryptography/documents/example-files/api- > > > notes.pdf__;!!FJ > > > -Y8qCqXTj2!dRvGTjD4FlxgYSD- > > > gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwN > > > wVqx3ZsUUu2AVJSJMccMLY00KoUQ-ArPLprc$ > > > > > > > > > Obviously we can make it better in Java while keeping it > > > simple. For > > > example: > > > > > > KEMEncapsulation = KEM.encapsulate(publicKey); byte[] ss = > > > KEM.decapsulate(privateKey, CipherText); > > > > > > KEMEncapsualtion simply contains the shared secret (ss) and > > > CipherText? > > > > > > > > > Or to fit with init() pattern the rest of them use: > > > > > > KEM.init(publicKey); > > > KEMEncapsulation = KEM.encapsulate() > > > > > > byte[] cipherText = KEMEncapsulation.getCipherText(); > > > > > > And then > > > KEM.init(privateKey); > > > byte[] ss = KEM.decapsulate(cipherText) > > > > > > or maybe even better: > > > KEM.init(publicKey); > > > byte[] cipherText = KEM.encapsulate() > > > byte[] sharedSecret = KEM.getSharedSecret() > > > > > > And then > > > KEM.init(privateKey); > > > byte[] ss = KEM.decapsulate(cipherText) > > > > > > > > > Cheers, > > > > > > John Gray > > > > > > > > > > > > > > > From: David Hook > > > Sent: Sunday, August 21, 2022 10:51 PM > > > To: Michael StJohns ; John Gray < > > > John.Gray at entrust.com> > > > Cc: security-dev at openjdk.org > > > Subject: [EXTERNAL] Re: Is there a KEM (Key Encapsulation > > > Mechanism) > > > architecture being proposed for the JCA? > > > > > > WARNING: This email originated outside of Entrust. > > > DO NOT CLICK links or attachments unless you trust the sender and > > > know > > > the content is safe. > > > > > > I'd have to agree about PKCS 11. > > > > > > One more thing about the PQC KEMs - the KDF step is built in. As > > > you've mentioned, previously there's been a lot of possible > > > combinations with key agreement, with PQC KEMs this has changed > > > (of > > > course, you could still use a KDF too, but the original reasons > > > for > > > doing so no longer apply). > > > > > > Regards, > > > > > > David > > > > > > On 21/8/22 13:52, Michael StJohns wrote: > > > > On 8/20/2022 2:08 PM, David Hook wrote: > > > > > Hi Michael, > > > > > > > > > > I don't know anything about bureaucrats, I am an engineer. > > > > > You may > > > > > need to consult someone else on bureaucrats. > > > > > I apologize for my apparent deficiencies in this area, but > > > > > would > > > > > you mind explaining how Cipher.wrap() is either supposed to > > > > > take a > > > > > public key and create an encapsulation based on it and return > > > > > a > > > > > secret key implicitly in one clean move, or why it even makes > > > > > sense to do so. The method was never conceived as providing > > > > > the > > > > > functionality for what a KEM actually does, and when I did > > > > > the > > > > > initial PKCS11 implementation at Eracom in the late 90's and > > > > > the > > > > > team at Sun added the wrap/unwrap functions to support it, > > > > > this is > > > > > definitely not was intended either - it was for explicit key > > > > > wrapping based on the key that was passed to Cipher.init(). > > > > > > > > > First - PKCS11 is a 40 year old API that probably needs to be > > > > retired. I spent the better part of 2 years working with the > > > > PKCS11 Oasis group trying to get them to properly support > > > > master > > > > secrets and KDFs and failed utterly. You should not use > > > > PKCS11 as > > > > an example that the JCE should use as a goal. > > > > > > > > > > > > > > > > At the base, a java class is a collection of objects. A Cipher > > > > object > > > > > > > > Let's build a non-parameterized ECIES-KEM which implicitly uses > > > > AES256 bit keys to key a GCM cipher, and a KDF based on SP800- > > > > 108 > > > > counter mode with SHA256 as the underlying hash, and with a > > > > well > > > > known label and context for the KDF since there is a new key > > > > for > > > > every wrap. > > > > > > > > 1) Implement CipherSpi - > > > > > > > > public class EciesKemCipher extends CipherSpi { > > > > > > > > private KeyAgreement ka; > > > > private Cipher gcm; > > > > private KeyPair kp; > > > > private KeyPairGenerator kg; > > > > > > > > EciesKemCipher() { > > > > ka = KeyAgreement.getInstance("ECDH"); > > > > kpg = KeyPairGenerator.getInstance ("EC"); > > > > gcm = Cipher.getInstance ("AES/GCM/NoPadding"); > > > > > > > > } > > > > > > > > // implement a single example > > > > > > > > @override > > > > protected void engineInit (int opMode, Key key, > > > > SecureRandom > > > > dontcare) { > > > > > > > > switch (opMode) { > > > > Cipher.MODE_WRAP: > > > > initWrap((ECPublicKey) key); > > > > break; > > > > default: > > > > // unimpl > > > > } > > > > } > > > > > > > > private void initWrap (ECPublicKey k) { > > > > > > > > ECParameterSpec spec = k.getParams(); > > > > kpg.initialize(spec); > > > > kp = kpg.genKeyPair(); > > > > ka.init (kp.getPrivate()); > > > > ka.doPhase (k, true); > > > > byte[] sharedSecret = ka.generateSecret(); > > > > > > > > byte[] keyStream = kdf(sharedSecret, 32 + 12); // > > > > output > > > > 44 bytes for Key and IV > > > > SecretKeySpec gcmKey = new SecretKeySpec (keyStream, > > > > 0, > > > > 32, "AES"); > > > > IvParameterSpec gcmIv = new > > > > IVParameterSpec(keyStream, 32, > > > > 12); > > > > > > > > gcm.init (Cipher.MODE_ENCRYPT, gcmKey, gcmIv); > > > > // all ready to go > > > > } > > > > > > > > > > > > protected byte[] engineWrap (Key k) { > > > > > > > > ByteBuffer outData = ByteBuffer.allocate > > > > (k.getEncoded().length + kp.getPublic().getEncoded().length) + > > > > 16; > > > > > > > > // Place a copy of the ephemeral public key I > > > > generated > > > > in init here for the use of the receiver. > > > > outData.put (kp.getEncoded()); > > > > // One s > > > > outData.put (gcm.doFinal(k.getEncoded()); > > > > > > > > outData.flip(); > > > > byte[] result = outdata.remaining(); > > > > > > > > outData.get(result); > > > > // kp = null; clear cipher if it hasn't already > > > > been > > > > cleared, clear ka if necessary (e.g. un-init) > > > > > > > > return result; > > > > } > > > > > > > > ... and unwrap and kdf function > > > > } > > > > > > > > > > > > > > > > 2) Implement a provider and add the above. > > > > > > > > > > > > > > > > > On BC's part, we've already implemented RFC 5990/SP 800-56B > > > > > in > > > > > Java and the experience has, at best, been awkward. The new > > > > > algorithms have moved awkward to inappropriate. With the new > > > > > algorithms, there's no longer only one case of this, it's not > > > > > an > > > > > outlier, there should be a general way of supporting KEMs in > > > > > the > > > > > API that doesn't involve over engineering KeyGenerator and > > > > > Cipher. > > > > > > > > > There's a big difference between the API and your underlying > > > > implementation. Everything you want to do can be done using > > > > the > > > > current APIs. As I said before, Cipher.wrap/unwrap are the > > > > appropriate APIs for this as they meet the contract > > > > requirements > > > > you need. Most Ciphers require some extra data -e.g. IVs - > > > > that > > > > have to either be carried or implicitly derived. In this case, > > > > what > > > > needs to be carried in addition to the encrypted key material > > > > is at least the ephemeral public key the wrapper creates. I > > > > used > > > > a very simple encoding scheme above and this assumes that both > > > > ends > > > > know exactly what "ECIES-KEM" means. Obviously, there are > > > > 100s of > > > > possible combinations of parameters and KDFs and key wrap > > > > algorithms. What I would suggest is heading over to LAMPS at > > > > the > > > > IETF and proposing a data encoding scheme for carrying the > > > > parameters. Once you have that done, then come here and map > > > > JCE > > > > names against parameter sets to close the loop. It won't > > > > require an > > > > API change. > > > > > > > > > I work with a team that has had to implement all of them and > > > > > had > > > > > to make them fit into the JCA. We have done so. Like John, I > > > > > am > > > > > simply relaying our experience. In about 18 months these > > > > > algorithms are going to become mandatory, what all of us > > > > > think is > > > > > irrelevant. We, for our part, already have a solution, but we > > > > > both > > > > > realize it's not "the solution" - we recognize that the JVM > > > > > is > > > > > uniquely positioned to provide leadership on this and provide > > > > > a > > > > > universal way of doing it. > > > > > > > > > Then suggest an API and we'll start knocking it around. I > > > > personally don't think its necessary at this time and will add > > > > to > > > > API bloat. > > > > > > > > > Of course, if it's felt that these algorithms should be > > > > > ignored, > > > > > it's not my place to revolt, although I do feel obliged to > > > > > argue. > > > > > I will simply try and do the best by my users, as I have no > > > > > doubt > > > > > will John. Both of us have simply offered our comments in > > > > > good > > > > > faith and to alert the community that things have changed and > > > > > that > > > > > with these new algorithms there is room for a new approach. > > > > > The ambiguity about how these algorithms can be implemented > > > > > and > > > > > the excessive need to fallback on propritary classes for them > > > > > does > > > > > suggest that there are some additions to the JCA which would > > > > > help. > > > > > I appreciate to understand this statement does involve > > > > > actually > > > > > understanding what these algorithms do and may require some > > > > > additional reading. > > > > > > > > > > As I said, I'm an engineer, my users will be able to use > > > > > these > > > > > algorithms properly, my team will ensure that, as I have no > > > > > doubt > > > > > will John's. What John and myself, apparently mistakenly, > > > > > care > > > > > about is that our users should also be able to use these > > > > > algorithms portably. > > > > > > > > > > Are you saying portability is no longer a consideration? > > > > > > > > > I have no idea where you got that idea. > > > > > > > > > Regards, > > > > > > > > > > David > > > > > > > > > > > > > > > > > > > > On 21/8/22 02:23, Michael StJohns wrote: > > > > > > Hi David/John - > > > > > > > > > > > > I would submit that you're trying too hard to make your > > > > > > life > > > > > > simple! :-) > > > > > > > > > > > > Cipher.wrap/unwrap are the correct methods. > > > > > > > > > > > > For example: > > > > > > > > > > > > Cipher kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF- > > > > > > SP800- > > > > > > 108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); > > > > > > byte[] opaqueEncapsulatedKey = kem.wrap (someOtherKey); > > > > > > > > > > > > The "opaqueEncapsulatedKey" would contain the data needed > > > > > > by the > > > > > > unwrap function - specifically a) the ecies ephemeral > > > > > > public > > > > > > key, b) the fact that the derived key is a GCM key of > > > > > > length 128 > > > > > > and that the GCM tag is 64 bytes long, c) the KDF, > > > > > > d) (optional) any mixins other than defaults required by > > > > > > the KDF > > > > > > - which would be passed in a parameter blob during init. > > > > > > Cipher would NOT return the underlying generated secret > > > > > > used to > > > > > > wrap the key. Just the public part of the key pair used to > > > > > > do > > > > > > the ECDH operation against the passed in public key. In > > > > > > the > > > > > > RSA case, the wrapped encrypting secret would be an opaque > > > > > > data > > > > > > blob and would be part of the data passed to the unwrap > > > > > > function. > > > > > > > > > > > > If you want a key generated for other purposes, then the > > > > > > right > > > > > > thing is using a KDF and a Key agreement function in > > > > > > tandem. > > > > > > Strangely the KDF appears in the javacard API for 3.1, but > > > > > > not > > > > > > in the JCE/JDK API. > > > > > > > > > > > > "What's the difference between a bureaucrat and an > > > > > > engineer? A > > > > > > bureaucrat takes small solvable pieces and combines them > > > > > > into > > > > > > one insoluble mass." > > > > > > > > > > > > In this case, Java provides a number of flexible primitives > > > > > > that > > > > > > can be combined as needed. In this case, the underlying > > > > > > Cipher > > > > > > implementation would wrap key agreement and kdf and cipher > > > > > > (GCM) > > > > > > instances. It should return UnsupportedOperationException > > > > > > for > > > > > > all operations execept wrap/unwrap and the appropriate init > > > > > > methods. > > > > > > > > > > > > Later, Mike > > > > > > > > > > > > > > > > > > > > > > > > On 8/19/2022 6:38 PM, David Hook wrote: > > > > > > > Hi Mike, > > > > > > > > > > > > > > KEMs can be used for key wrapping - we've actually > > > > > > > implemented > > > > > > > support for this too. But they are not actually key > > > > > > > wrapping > > > > > > > ciphers. > > > > > > > > > > > > > > Here's a simple example of using Kyber for key wrapping > > > > > > > in > > > > > > > BC: > > > > > > > > > > > > > > SecretKey key = new SecretKeySpec(keyBytes, "AES"); > > > > > > > > > > > > > > w1.init(Cipher.WRAP_MODE, kp.getPublic(), new > > > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > > > > > byte[] data = w1.wrap(key); > > > > > > > > > > > > > > Cipher w2 = Cipher.getInstance(algorithm, "BCPQC"); > > > > > > > > > > > > > > w2.init(Cipher.UNWRAP_MODE, kp.getPrivate(), new > > > > > > > KEMParameterSpec("AES-KWP")); > > > > > > > > > > > > > > Key k = w2.unwrap(data, "AES", Cipher.SECRET_KEY); > > > > > > > > > > > > > > The behavior in this case is in line with what is given > > > > > > > in RFC > > > > > > > 5990 for the RSA KEM. How it works is by using the key > > > > > > > generated by the KEM to create an AES-KWP key, which is > > > > > > > then > > > > > > > used to wrap keyBytes. The shortcoming is it means you > > > > > > > have to > > > > > > > generate the secret key separately. > > > > > > > > > > > > > > This is the problem though - a KEM can actually be used > > > > > > > to > > > > > > > generate a secret key for other purposes. For example, > > > > > > > where > > > > > > > someone is trying to implement a hybrid KAS scheme. But > > > > > > > there > > > > > > > is currently no mechanism in the Java APIs for being able > > > > > > > to > > > > > > > take advantage of this directly, hence our use of the > > > > > > > KeyGenerator class and other people's attempts to make > > > > > > > use of > > > > > > > the KeyAgreement class. The Cipher.wrap() returns a > > > > > > > byte[] - > > > > > > > to be used with a KEM for secret generation it would also > > > > > > > have > > > > > > > to return the generated secret (I would probably also > > > > > > > argue > > > > > > > that passing a public key to wrap in order to generate an > > > > > > > encapsulation of a generated encrypted secret was not the > > > > > > > correct use of the API either, but the fact remains a > > > > > > > byte[] > > > > > > > is not really going to cut it). > > > > > > > > > > > > > > If you have any further questions, please feel free to > > > > > > > ask. > > > > > > > For what it is worth, I have been developing providers > > > > > > > for the > > > > > > > JCE/JCA since the late 90's and am actually one of the > > > > > > > people > > > > > > > responsible for the introduction of the existing > > > > > > > wrap/unwrap > > > > > > > API in the Cipher class. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > David > > > > > > > On 20/8/22 07:53, Mike StJohns wrote: > > > > > > > > Hi This implemented as part of > > > > > > > > Javax.crypto.Cipher. See theJava doc for the wrap and > > > > > > > > unwrap methods. Mike Sent from my iPad > > > > > > > > > On Aug 19, 2022, at 12:56, John Gray < > > > > > > > > > John.Gray at entrust.com> wrote: > > > > > > > > > > > > > > > > > > ? We are starting to make use of the new PQ > > > > > > > > > algorithms > > > > > > > > > adopted by NIST for prototyping and development of > > > > > > > > > standards. In particular we are working on a > > > > > > > > > composite > > > > > > > > > KEM standard: > > > > > > > > > See: > > > > > > > > > https://urldefense.com/v3/__https://datatracker.ietf.org/d > > > > > > > > > oc/draft-ounsworth-pq-composite-kem/__;!!FJ- > > > > > > > > > Y8qCqXTj2!dRvG > > > > > > > > > TjD4FlxgYSD- > > > > > > > > > gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVq > > > > > > > > > x3ZsUUu2AVJSJMccMLY00KoUQ-K6fkXJ8$ > > > > > > > > > > > > > > > > > > However, there is no KEM interface in the JCA (which > > > > > > > > > make > > > > > > > > > sense because these are new algorithms, although RSA- > > > > > > > > > KEM > > > > > > > > > has been out since 2010). > > > > > > > > > > > > > > > > > > I can add one into our toolkit (and I think David may > > > > > > > > > have > > > > > > > > > already added on into BC), but I assume at some > > > > > > > > > point > > > > > > > > > there will be an official one added in Java and > > > > > > > > > likely it > > > > > > > > > won't be identical to what we do even if it is very > > > > > > > > > close, > > > > > > > > > which would cause backwards compatibility > > > > > > > > > pain... Perhaps we could collaborate on extending > > > > > > > > > the > > > > > > > > > JCA to support KEM? Essentially it requires > > > > > > > > > methods. > > > > > > > > > > > > > > > > > > ss, ct := encapsulate(PublicKey) ss := > > > > > > > > > decapsulate(PrivateKey, ct) > > > > > > > > > > > > > > > > > > -ss is a shared secret (could come back as a Java > > > > > > > > > SecretKey if you wanted as it would usually be used > > > > > > > > > to > > > > > > > > > derive something like an AES afterwards) -ct is a > > > > > > > > > Cipher > > > > > > > > > Text (a byte array would make sense) -Public and > > > > > > > > > Private > > > > > > > > > Keys would use the regular public and private key > > > > > > > > > interface. > > > > > > > > > -An object holding the ss and ct from the > > > > > > > > > encapsulate() > > > > > > > > > method could be returned, with accessor methods to > > > > > > > > > get > > > > > > > > > the ss and ct. It could be called > > > > > > > > > 'EncapsulatedKEMData' > > > > > > > > > for example. > > > > > > > > > > > > > > > > > > Likely you would want a new type of KEM crypto object > > > > > > > > > (like you have for Signature, MessageDigest, Cipher, > > > > > > > > > Mac, > > > > > > > > > SecureRandom, KeyAgreement.. etc). Calling it KEM > > > > > > > > > would > > > > > > > > > seem to make sense. ? It could also use > > > > > > > > > similar > > > > > > > > > calling patterns and have a > > > > > > > > > KEM.initKEM(keypair.getPublic()) or > > > > > > > > > KEM.initKEM(keypair.getPrivate()), and then you would > > > > > > > > > just > > > > > > > > > call KEM.encapsulate() or KEM.decapsulate(ct). > > > > > > > > > > > > > > > > > > Then algorithms could be registered in providers as > > > > > > > > > usual: > > > > > > > > > > > > > > > > > > put("KEM.Kyber","com.blah.Kyber") > > > > > > > > > > > > > > > > > > put("KEM.compositeKEM","com.entrust.toolkit.crypto.ke > > > > > > > > > m.co > > > > > > > > > mpositeKEM") > > > > > > > > > > > > > > > > > > Then the above methods (encapsulate and decapsulate) > > > > > > > > > could be defined in that new object type. Then we > > > > > > > > > would > > > > > > > > > be able to make use of it and not have to worry about > > > > > > > > > incompatibility issues down the road... > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > John Gray > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Any email and files/attachments transmitted with it > > > > > > > > > are > > > > > > > > > confidential and are intended solely for the use of > > > > > > > > > the > > > > > > > > > individual or entity to whom they are addressed. If > > > > > > > > > this > > > > > > > > > message has been sent to you in error, you must not > > > > > > > > > copy, > > > > > > > > > distribute or disclose of the information it > > > > > > > > > contains. > > > > > > > > > Please notify Entrust immediately and delete the > > > > > > > > > message > > > > > > > > > from your system. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Franco Nieddu > > SIC - Software Engineer > > Phone: +43 (316) 873 - 5507 > > SIC Homepage: > > https://urldefense.com/v3/__https://jce.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-2W4oa1s$ > > IAIK Homepage: > > https://urldefense.com/v3/__https://www.iaik.tugraz.at/__;!!FJ-Y8qCqXTj2!dRvGTjD4FlxgYSD-gBr0pkO3DBu7Gf13fWJ4vYkzN8aahzgBH0UE1xfmZwNwVqx3ZsUUu2AVJSJMccMLY00KoUQ-Ov0Iano$ > > -- Franco Nieddu SIC - Software Engineer Phone: +43 (316) 873 - 5507 SIC Homepage: https://jce.iaik.tugraz.at/ IAIK Homepage: https://www.iaik.tugraz.at/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From coffeys at openjdk.org Fri Aug 26 12:07:05 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Fri, 26 Aug 2022 12:07:05 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: On Fri, 26 Aug 2022 04:31:59 GMT, Xue-Lei Andrew Fan wrote: >> @coffeys Before we go further, I think we'd better have a look if the information added could help for debugging. I'm not sure of that now. >> >>> With the new debug data, we have some extra data points like the ciphersuites actually enabled, the preference of client or server suites etc. Coupled with the ClientHello data, I think it helps piece together a better idea of the server side scenario. >> >> If I understand correctly, the preference of client or server suites should not impact the success of handshaking. Did you see examples otherwise in practice? What's the purpose by adding this information for failed handshaking? >> >> The client authentication type is also logged for failed server hello handshake message. What's the purpose for the adding? Did you see server hello failure that caused by client authentication type in practice? >> >> With server debug log enabled, there have already been a lot debug information, especially for verberos debug mode. Is it a really concern to you to dump server enabled cipher suites, just as the dump of ClientHello message? Yes, it make debug logger worse for a busy server, but the impact may be 1/10K? >> >> I have to run for now, and will try to reply more for your comments. Thanks! > >> I've no strong preference on how often we print this debug data on server end. To cut back on log verbosity, perhaps on fatal/failing handshake scenarios is all that's required. > > Does the switch on/off the "verbose", "data" or "record" debug option help to reduce the log verbosity? > > In general, I'm not sure how on failing handshake scenarios could help to make the debug better. Thinking about the failure of the ServerHello in this case, it could be related to ClientHello, named groups/key exchange algorithms, signature algorithms, key store, certificate signature, certificate key algorithms, certificate key length, etc. If these information does not dump when the ClientHello is good, I'm not sure if the developer understand better about what could be the cause from the server cipher suite preference, client authentication types and server enabled cipher suites. Well, we can dump everything in the printServerSocketConfig() method, but do we know everything in the context of printServerSocketConfig and is it easy to maintain the things in the method. I'm not sure of that. I think many engineers use the `-Djavax.net.debug=all` option for TLS debugging at moment. `-Djavax.net.debug=ssl` is pretty much broke. There's an open bug for that IIRC. I revisited the ServerHello produce() code for TLSv12/TLSv13 to see if this approach was making sense. In general, I think it's a good addition to the debug logs. They're all important data points before leading up the initial ServerHello response message. Yes, further fatal errors are possible on the ServerSocket after that but the exception messages are more focussed for those scenarios IMO. Yes - it won't always give the user the full picture but it certainly gives more data about the enc the server socket is being created in. on your "preference of client or server suites" data point question... fair point - it shouldn't be a major factor in establishing a TLS connection. What about the scenario where a server has multiple key exchange algs available ? wouldn't that boolean help deduce why one key exchange was preferred over another when a hand shake might have failed ? It's a useful data point to help diagnose why such a failure occurred IMO. No harm at least. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From mullan at openjdk.org Fri Aug 26 13:33:50 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 13:33:50 GMT Subject: RFR: 8245654: Add Certigna Root CAs In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote: > This fix adds Certigna root CA to cacerts trust store. Can we change the issue title to "Add Certigna Root CA" since only one root is being added? ------------- PR: https://git.openjdk.org/jdk/pull/10030 From mullan at openjdk.org Fri Aug 26 13:37:56 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 26 Aug 2022 13:37:56 GMT Subject: RFR: 8245654: Add Certigna Root CAs In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote: > This fix adds Certigna root CA to cacerts trust store. Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10030 From xuelei at openjdk.org Fri Aug 26 14:54:10 2022 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Fri, 26 Aug 2022 14:54:10 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: On Fri, 26 Aug 2022 12:03:33 GMT, Sean Coffey wrote: > ... on your "preference of client or server suites" data point question .... It is not expected to break the connection by changing the preference even there are multiple key exchange algs. There may be bugs, but did you see failures caused by preference in practice? BTW, the information is logged when ServerHello failed, and it will not be logged if the process goes to key exchange handshake message point. > They're all important data points before leading up the initial ServerHello response message. I agreed that there are all important data points. I'm just not sure if it is the right approach to dump on ServerHello failure. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From mpowers at openjdk.org Fri Aug 26 16:03:55 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 26 Aug 2022 16:03:55 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <4q0wnlPCrSPkF_cyQIX31S5HDizdH7BtbPyhdLSBkGA=.56e90b34-2f84-4a2e-87a7-ec8c5d88c494@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> <4q0wnlPCrSPkF_cyQIX31S5HDizdH7BtbPyhdLSBkGA=.56e90b34-2f84-4a2e-87a7-ec8c5d88c494@github.com> Message-ID: On Fri, 26 Aug 2022 10:57:48 GMT, Sean Mullan wrote: >> If I make alternateNames final, then IJ complains "cannot assign a value to final variable". >> If I make it final and remove initialization, then make complains that alternateNames might not have been initialized. > > I would make it final, and then assign it to null in a final else block after line 719. Fixed. I was also able to make `type` final on line 676. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From rhalade at openjdk.org Fri Aug 26 16:08:11 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 26 Aug 2022 16:08:11 GMT Subject: RFR: 8245654: Add Certigna Root CA In-Reply-To: References: Message-ID: On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote: > This fix adds Certigna root CA to cacerts trust store. I have update the bug summary as suggested by Sean. ------------- PR: https://git.openjdk.org/jdk/pull/10030 From mpowers at openjdk.org Fri Aug 26 17:41:04 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 26 Aug 2022 17:41:04 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: <5-sy6zKq2mNzHh90smW7kXYssqcFMfhLkoS_bqBENlI=.f696f6a7-6afe-489d-bb34-35fd1e03d438@github.com> On Fri, 26 Aug 2022 10:50:54 GMT, Sean Mullan wrote: >> src/java.base/share/classes/sun/security/jca/Providers.java line 104: >> >>> 102: * Start JAR verification. This sets a special provider list for >>> 103: * the current thread. You MUST save the return value from this >>> 104: * method, and you MUST call stopJarVerification() with that object >> >> Hmm, I'm not sure this is more grammatically correct. > > same here about dependent clause case. You are correct. Removing the comma. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Fri Aug 26 17:41:05 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 26 Aug 2022 17:41:05 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> Message-ID: On Fri, 26 Aug 2022 10:49:59 GMT, Sean Mullan wrote: >> I could go either way. The sentence is not that long (it's not a German sentence). IJ is only a recommendation. > > I'm not a grammar expert, but I think using a comma before and is not necessary here and possibly incorrect. See https://www.grammarly.com/blog/comma-before-and/. This seem like a "dependent clause" case. You are correct. Removing the comma. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From valeriep at openjdk.org Fri Aug 26 17:48:56 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Fri, 26 Aug 2022 17:48:56 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <4aRNq6CvxBWfwyGegSrfM9QPW2RNxAAMxAYb68oG0hI=.8ed14760-83c1-4d6a-afb7-8d5a5ea5441c@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> <4aRNq6CvxBWfwyGegSrfM9QPW2RNxAAMxAYb68oG0hI=.8ed14760-83c1-4d6a-afb7-8d5a5ea5441c@github.com> Message-ID: On Fri, 26 Aug 2022 10:39:20 GMT, Sean Mullan wrote: >> IntelliJ seems to think it could. The point of requireNonNull is that you control when an exception is thrown, and sooner rather than later is better. This code appears to have been working fine for a long time, so maybe NPE can't happen in practice. I'm fine with reverting this requireNonNull change here and elsewhere if you think it is unnecessary. > > Right, but in this case I think if an NPE is ever thrown it would be considered a bug in the JDK because an unexpected RuntimeException would be thrown. I think requireNonNull is used more in cases where caller input is being validated and null is not valid. I find this code less readable. There are lots of cases in the JDK code where some object could theoretically be null, but it would be a bug if it was. If it was a normal case for a provider to sometimes be null here, then I would expect this code to check for null and handle it. > > @valeriep is more familiar with this code, so I would also like her feedback on these changes to use requireNonNull. I don't see much benefit of using Objects.requireNonNull() here also for the reasons that Sean have already stated. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Fri Aug 26 18:04:57 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 26 Aug 2022 18:04:57 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <8hCv8lzcAeYrhLU589d6bDuyMGuNljPSCR0mjKuOjPw=.8268237a-95a6-4ac9-921e-4d9676d18fd5@github.com> <4aRNq6CvxBWfwyGegSrfM9QPW2RNxAAMxAYb68oG0hI=.8ed14760-83c1-4d6a-afb7-8d5a5ea5441c@github.com> Message-ID: On Fri, 26 Aug 2022 17:46:44 GMT, Valerie Peng wrote: >> Right, but in this case I think if an NPE is ever thrown it would be considered a bug in the JDK because an unexpected RuntimeException would be thrown. I think requireNonNull is used more in cases where caller input is being validated and null is not valid. I find this code less readable. There are lots of cases in the JDK code where some object could theoretically be null, but it would be a bug if it was. If it was a normal case for a provider to sometimes be null here, then I would expect this code to check for null and handle it. >> >> @valeriep is more familiar with this code, so I would also like her feedback on these changes to use requireNonNull. > > I don't see much benefit of using Objects.requireNonNull() here also for the reasons that Sean have already stated. @valeriepeng agrees with you Sean. I'll remove `requireNonNull` here and elsewhere unless there is a compelling reason to keep it. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From rhalade at openjdk.org Fri Aug 26 18:13:01 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 26 Aug 2022 18:13:01 GMT Subject: RFR: 8245654: Add Certigna Root CA In-Reply-To: References: Message-ID: <7jJE8L73dJLNWDGZ7ex5oX66Nh8owQUGkpjV7WcPIEs=.a3e1ecd2-2c20-40b2-b1a7-bc0b3449c983@github.com> On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote: > This fix adds Certigna root CA to cacerts trust store. I put this on hold to debug a potential issue I am seeing. ------------- PR: https://git.openjdk.org/jdk/pull/10030 From rhalade at openjdk.org Fri Aug 26 18:30:36 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Fri, 26 Aug 2022 18:30:36 GMT Subject: RFR: 8245654: Add Certigna Root CA [v2] In-Reply-To: References: Message-ID: > This fix adds Certigna root CA to cacerts trust store. Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8247698-certigna - remove control-M characters - Added Certigna CA cert and updated VerifyCACerts.java test - Merge remote-tracking branch 'origin/master' into 8247698-certigna - 8247698: Evaluate the inclusion of DHIMYOTIS (certigna) roots ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10030/files - new: https://git.openjdk.org/jdk/pull/10030/files/45156940..19a5d3ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10030&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10030&range=00-01 Stats: 16841 lines in 484 files changed: 6249 ins; 8187 del; 2405 mod Patch: https://git.openjdk.org/jdk/pull/10030.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10030/head:pull/10030 PR: https://git.openjdk.org/jdk/pull/10030 From mpowers at openjdk.org Fri Aug 26 18:30:58 2022 From: mpowers at openjdk.org (Mark Powers) Date: Fri, 26 Aug 2022 18:30:58 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security In-Reply-To: <5-sy6zKq2mNzHh90smW7kXYssqcFMfhLkoS_bqBENlI=.f696f6a7-6afe-489d-bb34-35fd1e03d438@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> <5-sy6zKq2mNzHh90smW7kXYssqcFMfhLkoS_bqBENlI=.f696f6a7-6afe-489d-bb34-35fd1e03d438@github.com> Message-ID: On Fri, 26 Aug 2022 17:37:23 GMT, Mark Powers wrote: >> same here about dependent clause case. > > You are correct. Removing the comma. Maybe not. Each clause stands on its own as a complete sentence. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From kdriver at openjdk.org Fri Aug 26 18:53:07 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 26 Aug 2022 18:53:07 GMT Subject: RFR: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for [v3] In-Reply-To: References: Message-ID: > Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: Update Test4958071.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9860/files - new: https://git.openjdk.org/jdk/pull/9860/files/d0f62e66..54c57179 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9860&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9860&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9860.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9860/head:pull/9860 PR: https://git.openjdk.org/jdk/pull/9860 From kdriver at openjdk.org Fri Aug 26 19:00:22 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Fri, 26 Aug 2022 19:00:22 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v8] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request incrementally with one additional commit since the last revision: Update Test6205692.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/f41dd862..74e7b569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From sean.mullan at oracle.com Fri Aug 26 20:28:48 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 26 Aug 2022 21:28:48 +0100 Subject: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA? In-Reply-To: References: Message-ID: <9cbeb4ad-7b59-0cd8-b2cd-6383c4373930@oracle.com> John, David, Franco, Thank you for your interest in helping define a new KEM API for Java. We agree that KEMs are an important mechanism and expect them to become more prevalent in the future. We also agree that there are challenges associated with retrofitting the current APIs (KeyGenerator, Cipher, KeyAgreement, etc) to implement KEMs, and thus we plan to define a new standard KEM API for Java. Your experience will be valuable (as has your input so far) to help shape the direction of the API and confirm that it is flexible enough to meet your needs. We will be following up with more details soon. --Sean On 8/18/22 9:37 PM, John Gray wrote: > We are starting to make use of the new PQ algorithms adopted by NIST for prototyping and development of standards. In particular we are working on a composite KEM standard: > See: https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-kem/ > > However, there is no KEM interface in the JCA (which make sense because these are new algorithms, although RSA-KEM has been out since 2010). > > I can add one into our toolkit (and I think David may have already added on into BC), but I assume at some point there will be an official one added in Java and likely it won't be identical to what we do even if it is very close, which would cause backwards compatibility pain... Perhaps we could collaborate on extending the JCA to support KEM? Essentially it requires methods. > > ss, ct := encapsulate(PublicKey) > ss := decapsulate(PrivateKey, ct) > > -ss is a shared secret (could come back as a Java SecretKey if you wanted as it would usually be used to derive something like an AES afterwards) > -ct is a Cipher Text (a byte array would make sense) > -Public and Private Keys would use the regular public and private key interface. > -An object holding the ss and ct from the encapsulate() method could be returned, with accessor methods to get the ss and ct. It could be called 'EncapsulatedKEMData' for example. > > Likely you would want a new type of KEM crypto object (like you have for Signature, MessageDigest, Cipher, Mac, SecureRandom, KeyAgreement.. etc). Calling it KEM would seem to make sense. ? It could also use similar calling patterns and have a KEM.initKEM(keypair.getPublic()) or KEM.initKEM(keypair.getPrivate()), and then you would just call KEM.encapsulate() or KEM.decapsulate(ct). > > Then algorithms could be registered in providers as usual: > > put("KEM.Kyber","com.blah.Kyber") > put("KEM.compositeKEM","com.entrust.toolkit.crypto.kem.compositeKEM") > > Then the above methods (encapsulate and decapsulate) could be defined in that new object type. Then we would be able to make use of it and not have to worry about incompatibility issues down the road... > > Cheers, > > John Gray > > > > Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. From valeriep at openjdk.org Sat Aug 27 06:08:08 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Sat, 27 Aug 2022 06:08:08 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v3] In-Reply-To: References: Message-ID: > Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. > > Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: address review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10008/files - new: https://git.openjdk.org/jdk/pull/10008/files/d8679caf..49bad5f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=01-02 Stats: 221 lines in 2 files changed: 77 ins; 98 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/10008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008 PR: https://git.openjdk.org/jdk/pull/10008 From coffeys at openjdk.org Mon Aug 29 12:06:19 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 29 Aug 2022 12:06:19 GMT Subject: RFR: 8133816: Display extra SSLServerSocket info in debug mode [v3] In-Reply-To: References: <4E3E34rLtmRoRVIlxy6PU3vKMUK58QROyF15SeNeS9s=.ccf8cd50-90c6-43e7-89e2-66053d9a5b14@github.com> Message-ID: <2Fv48-Xxx1QD0z6AWw54TJs_moJywdvZVJhJh-qxS5g=.077f9c07-7c8e-4343-b8ef-bab8c86cb529@github.com> On Fri, 26 Aug 2022 14:51:48 GMT, Xue-Lei Andrew Fan wrote: >> I think many engineers use the `-Djavax.net.debug=all` option for TLS debugging at moment. `-Djavax.net.debug=ssl` is pretty much broke. There's an open bug for that IIRC. >> >> I revisited the ServerHello produce() code for TLSv12/TLSv13 to see if this approach was making sense. In general, I think it's a good addition to the debug logs. They're all important data points before leading up the initial ServerHello response message. Yes, further fatal errors are possible on the ServerSocket after that but the exception messages are more focussed for those scenarios IMO. Yes - it won't always give the user the full picture but it certainly gives more data about the enc the server socket is being created in. >> >> on your "preference of client or server suites" data point question... fair point - it shouldn't be a major factor in establishing a TLS connection. What about the scenario where a server has multiple key exchange algs available ? wouldn't that boolean help deduce why one key exchange was preferred over another when a hand shake might have failed ? It's a useful data point to help diagnose why such a failure occurred IMO. No harm at least. > >> ... on your "preference of client or server suites" data point question .... > > It is not expected to break the connection by changing the preference even there are multiple key exchange algs. There may be bugs, but did you see failures caused by preference in practice? BTW, the information is logged when ServerHello failed, and it will not be logged if the process goes to key exchange handshake message point. > >> They're all important data points before leading up the initial ServerHello response message. > > I agreed that there are all important data points. I'm just not sure if it is the right approach to dump on ServerHello failure. No - I haven't seen any such handshake failures as a result of the cipher suites preference. Just a theory. OK - let's have a think about the what the best approach is for the logging frequency of such server-side data points. Perhaps another suggestion is to log such data for scenarios where the server issues a fatal alert during any part of the handshake phase. Let me have a chat with Weibing and others and revert back. ------------- PR: https://git.openjdk.org/jdk/pull/9731 From ecaspole at openjdk.org Mon Aug 29 13:56:28 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Mon, 29 Aug 2022 13:56:28 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v3] In-Reply-To: References: Message-ID: > Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: Changes from advice from Sean M ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9950/files - new: https://git.openjdk.org/jdk/pull/9950/files/a77e6a5d..3a83b732 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9950&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9950&range=01-02 Stats: 30 lines in 1 file changed: 14 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9950.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9950/head:pull/9950 PR: https://git.openjdk.org/jdk/pull/9950 From valeriep at openjdk.org Mon Aug 29 15:42:17 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 29 Aug 2022 15:42:17 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v4] In-Reply-To: References: Message-ID: > Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. > > Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: remove obsolete println. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10008/files - new: https://git.openjdk.org/jdk/pull/10008/files/49bad5f8..440b1047 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008 PR: https://git.openjdk.org/jdk/pull/10008 From weijun at openjdk.org Mon Aug 29 18:39:45 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 29 Aug 2022 18:39:45 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 15:42:17 GMT, Valerie Peng wrote: >> Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. >> >> Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. >> >> Thanks in advance for review~ > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > remove obsolete println. src/java.base/share/classes/java/security/Security.java line 872: > 870: * and remove those which do not contain a match. > 871: */ > 872: private static void applyFilterOnCandidates(Criteria cr, Can you stuff all these methods into the `Criteria` class? ------------- PR: https://git.openjdk.org/jdk/pull/10008 From valeriep at openjdk.org Mon Aug 29 19:05:05 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 29 Aug 2022 19:05:05 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v4] In-Reply-To: References: Message-ID: On Mon, 29 Aug 2022 18:36:20 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> remove obsolete println. > > src/java.base/share/classes/java/security/Security.java line 872: > >> 870: * and remove those which do not contain a match. >> 871: */ >> 872: private static void applyFilterOnCandidates(Criteria cr, > > Can you stuff all these methods into the `Criteria` class? Sure, I can do that. ------------- PR: https://git.openjdk.org/jdk/pull/10008 From valeriep at openjdk.org Mon Aug 29 20:13:42 2022 From: valeriep at openjdk.org (Valerie Peng) Date: Mon, 29 Aug 2022 20:13:42 GMT Subject: RFR: 6447816: Provider filtering (getProviders) is not working with OR'd conditions [v5] In-Reply-To: References: Message-ID: > Existing provider filtering code only handles two standard attribute "KeySize" and "ImplementedIn", the rest are compared by exact match. Over time, more standard attributes are added which contain multiple values separated by "|". We should enhance the provider filtering code to better compare these. > > Documentation update for this is tracked separately under https://bugs.openjdk.org/browse/JDK-6447817. > > Thanks in advance for review~ Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: more refactoring. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10008/files - new: https://git.openjdk.org/jdk/pull/10008/files/440b1047..2ecc0e7e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10008&range=03-04 Stats: 71 lines in 2 files changed: 17 ins; 22 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/10008.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10008/head:pull/10008 PR: https://git.openjdk.org/jdk/pull/10008 From mpowers at openjdk.org Mon Aug 29 20:22:21 2022 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Aug 2022 20:22:21 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v2] In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: > https://bugs.openjdk.org/browse/JDK-8291509 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: remove requireNonNull ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9972/files - new: https://git.openjdk.org/jdk/pull/9972/files/9ca27fad..c23d248b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=00-01 Stats: 523 lines in 57 files changed: 5 ins; 189 del; 329 mod Patch: https://git.openjdk.org/jdk/pull/9972.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972 PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Mon Aug 29 21:48:18 2022 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 29 Aug 2022 21:48:18 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: > https://bugs.openjdk.org/browse/JDK-8291509 Mark Powers has updated the pull request incrementally with one additional commit since the last revision: white space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9972/files - new: https://git.openjdk.org/jdk/pull/9972/files/c23d248b..4157f2a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9972&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9972.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9972/head:pull/9972 PR: https://git.openjdk.org/jdk/pull/9972 From djelinski at openjdk.org Tue Aug 30 12:26:02 2022 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 30 Aug 2022 12:26:02 GMT Subject: RFR: 8293088: Fix compilation with the new Visual Studio preprocessor Message-ID: Fix compilation with Zc:preprocessor enabled. The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue. Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK. I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor. ------------- Commit messages: - Improve standards compliance Changes: https://git.openjdk.org/jdk/pull/10080/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10080&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293088 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10080.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10080/head:pull/10080 PR: https://git.openjdk.org/jdk/pull/10080 From mullan at openjdk.org Tue Aug 30 13:54:15 2022 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Aug 2022 13:54:15 GMT Subject: RFR: 8245654: Add Certigna Root CA [v2] In-Reply-To: References: Message-ID: On Fri, 26 Aug 2022 18:30:36 GMT, Rajan Halade wrote: >> This fix adds Certigna root CA to cacerts trust store. > > Rajan Halade has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into 8247698-certigna > - remove control-M characters > - Added Certigna CA cert and updated VerifyCACerts.java test > - Merge remote-tracking branch 'origin/master' into 8247698-certigna > - 8247698: Evaluate the inclusion of DHIMYOTIS (certigna) roots Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10030 From ihse at openjdk.org Tue Aug 30 15:03:19 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 30 Aug 2022 15:03:19 GMT Subject: RFR: 8293088: Fix compilation with the new Visual Studio preprocessor In-Reply-To: References: Message-ID: On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski wrote: > Fix compilation with Zc:preprocessor enabled. > > The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue. > > Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK. > > I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10080 From kdriver at openjdk.org Tue Aug 30 18:26:24 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 30 Aug 2022 18:26:24 GMT Subject: Integrated: 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 18:15:53 GMT, Kevin Driver wrote: > Fix for JDK-4958071 to add additional @throws stanza to javadocs for all init methods This pull request has now been integrated. Changeset: 550e5d78 Author: Kevin Driver Committer: Valerie Peng URL: https://git.openjdk.org/jdk/commit/550e5d7822c13c3011a445db109aa47d90af7fa6 Stats: 120 lines in 2 files changed: 120 ins; 0 del; 0 mod 4958071: (spec) confusing exception list for javax.crypto.Cipher.init(...) for Reviewed-by: valeriep, wetmore ------------- PR: https://git.openjdk.org/jdk/pull/9860 From kdriver at openjdk.org Tue Aug 30 18:48:29 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 30 Aug 2022 18:48:29 GMT Subject: RFR: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified [v9] In-Reply-To: References: Message-ID: > add @exception message to indicate an NPE might be thrown when the input parameter is null Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into HEAD - Update Test6205692.java - review comments - remove unnecessary code - move test - new test for MacSpi demo purposes - code review comments -- replace all occurences of @exception with @throws - changed to uses @throws - review comment - https://bugs.openjdk.org/browse/JDK-6205692 : add @exception message to indicate an NPE might be thrown when the input parameter is null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9859/files - new: https://git.openjdk.org/jdk/pull/9859/files/74e7b569..6a9dafe2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9859&range=07-08 Stats: 63719 lines in 1041 files changed: 27677 ins; 30483 del; 5559 mod Patch: https://git.openjdk.org/jdk/pull/9859.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9859/head:pull/9859 PR: https://git.openjdk.org/jdk/pull/9859 From mullan at openjdk.org Tue Aug 30 19:34:16 2022 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Aug 2022 19:34:16 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Mon, 29 Aug 2022 21:48:18 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8291509 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > white space src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 1003: > 1001: * @throws IOException The exception is thrown if an error occurs while > 1002: * communicating with the TSA, or a non-null > 1003: * TSAPolicyID is specified in the request, but it The previous text w/o a comma reads more correct to me as it is a complete statement: "or a non-null TSAPolicyID is specified in the request but it does not match the one in the reply". ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mullan at openjdk.org Tue Aug 30 20:01:10 2022 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 30 Aug 2022 20:01:10 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Mon, 29 Aug 2022 21:48:18 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8291509 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > white space A few more comments. src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 133: > 131: private final byte[] certHash; > 132: private GeneralNames issuer; > 133: private SerialNumber serialNumber; You could also mark these as `final` and add an `else` block to the ctor which sets them to `null`. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2319: > 2317: } else { > 2318: // Different keyId. Not a fallback. > 2319: continue; Personally I prefer seeing "continue" here - it makes it clear that none of the remaining code in this loop is relevant. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Tue Aug 30 20:01:13 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Aug 2022 20:01:13 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 19:31:36 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 1003: > >> 1001: * @throws IOException The exception is thrown if an error occurs while >> 1002: * communicating with the TSA, or a non-null >> 1003: * TSAPolicyID is specified in the request, but it > > The previous text w/o a comma reads more correct to me as it is a complete statement: "or a non-null TSAPolicyID is specified in the request but it does not match the one in the reply". Removing the comma. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Tue Aug 30 20:13:40 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Aug 2022 20:13:40 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 19:36:55 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/pkcs/SigningCertificateInfo.java line 133: > >> 131: private final byte[] certHash; >> 132: private GeneralNames issuer; >> 133: private SerialNumber serialNumber; > > You could also mark these as `final` and add an `else` block to the ctor which sets them to `null`. Fixed as suggested. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Tue Aug 30 20:20:14 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Aug 2022 20:20:14 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 19:52:03 GMT, Sean Mullan wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2319: > >> 2317: } else { >> 2318: // Different keyId. Not a fallback. >> 2319: continue; > > Personally I prefer seeing "continue" here - it makes it clear that none of the remaining code in this loop is relevant. Agreed. Adding it back. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From kdriver at openjdk.org Tue Aug 30 20:56:54 2022 From: kdriver at openjdk.org (Kevin Driver) Date: Tue, 30 Aug 2022 20:56:54 GMT Subject: Integrated: 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 17:41:16 GMT, Kevin Driver wrote: > add @exception message to indicate an NPE might be thrown when the input parameter is null This pull request has now been integrated. Changeset: 6335150c Author: Kevin Driver Committer: Bradford Wetmore URL: https://git.openjdk.org/jdk/commit/6335150cea939319e3bdf954b877453db04a3c24 Stats: 117 lines in 3 files changed: 102 ins; 0 del; 15 mod 6205692: (spec) javax.crypto.MacSpi.engineUpdate(ByteBuffer input): NPE should be specified Reviewed-by: valeriep ------------- PR: https://git.openjdk.org/jdk/pull/9859 From weijun at openjdk.org Tue Aug 30 21:10:31 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 30 Aug 2022 21:10:31 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Mon, 29 Aug 2022 21:48:18 GMT, Mark Powers wrote: >> https://bugs.openjdk.org/browse/JDK-8291509 > > Mark Powers has updated the pull request incrementally with one additional commit since the last revision: > > white space Files before (and equals to) `X509Factory`. src/java.base/share/classes/sun/security/jca/ProviderList.java line 672: > 670: "SHA3-384", "SHA3-512" }; > 671: private static final String[] HmacSHA3Group = { "HmacSHA3-224", > 672: "HmacSHA3-256", "HmacSHA3-384", "HmacSHA3-512"}; Shall I change these `static final` fields to UPPERCASE? src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 216: > 214: > 215: private void parseNetscapeCertChain(DerValue val) > 216: throws IOException { No need for a newline here. src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 263: > 261: // signerInfos SignerInfos } > 262: private void parseSignedData(DerValue val) > 263: throws IOException { No need for a newline here. src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 389: > 387: */ > 388: private void parseOldSignedData(DerValue val) > 389: throws IOException No need for a newline here. src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 106: > 104: */ > 105: public SignerInfo(DerInputStream derin) > 106: throws IOException { No need for a newline here. src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 121: > 119: */ > 120: public SignerInfo(DerInputStream derin, boolean oldStyle) > 121: throws IOException { Indent 4 more spaces. src/java.base/share/classes/sun/security/pkcs10/PKCS10.java line 369: > 367: private final PKCS10Attributes attributeSet; > 368: private byte[] encoded; // signed > 369: } Either realign all the names or none. src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 184: > 182: return false; > 183: PKCS10Attribute thisAttr, otherAttr; > 184: String key; This whole `toString` method can be enhanced. Can we just compare `this.map.equals(that.map)`? src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 216: > 214: */ > 215: public String toString() { > 216: return map.size() + "\n" + map.toString(); `toString` not needed. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 47: > 45: > 46: private String digestAlgorithmName; > 47: private AlgorithmParameters digestAlgorithmParams; Yes, this field is not used now. But one day we might see one that has parameters. I'd rather keep them and maybe fix `getEncoded` by then. src/java.base/share/classes/sun/security/pkcs12/MacData.java line 58: > 56: */ > 57: MacData(DerInputStream derin) > 58: throws IOException { No need for a newline here. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1723: > 1721: if (entry instanceof PrivateKeyEntry keyEntry) { > 1722: certs = Objects.requireNonNullElseGet(keyEntry.chain, () -> > 1723: new Certificate[0]); I'd rather use `?:`. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1809: > 1807: */ > 1808: private byte[] createSafeContent() > 1809: throws IOException { No need for a newline here. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2213: > 2211: if (entry.keyId != null) { > 2212: ArrayList chain = > 2213: new ArrayList<>(); No need for a newline here. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2389: > 2387: private void loadSafeContents(DerInputStream stream) > 2388: throws IOException, CertificateException > 2389: { Put brace to previous line. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2554: > 2552: Long.parseLong(keyIdStr.substring(5))); > 2553: } catch (Exception e) { > 2554: date = null; Maybe add a comment? src/java.base/share/classes/sun/security/provider/DomainKeyStore.java line 564: > 562: } > 563: return new AbstractMap.SimpleEntry<>("", > 564: Collections.emptyList()); No need for a newline here. src/java.base/share/classes/sun/security/provider/PolicyParser.java line 576: > 574: } > 575: > 576: return (ignoreEntry == true) ? null : e; Remove definition of `ignoreEntry`. src/java.base/share/classes/sun/security/provider/PolicyParser.java line 956: > 954: ge.principals = new LinkedList<>(this.principals); > 955: ge.permissionEntries = > 956: new Vector<>(this.permissionEntries); No need for a newline here. src/java.base/share/classes/sun/security/provider/SecureRandom.java line 235: > 233: if (r > 0) { > 234: // How many bytes? > 235: todo = Math.min((result.length - index), (DIGEST_SIZE - r)); No need for so many parentheses. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Tue Aug 30 21:29:14 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Aug 2022 21:29:14 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 20:10:43 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/jca/ProviderList.java line 672: > >> 670: "SHA3-384", "SHA3-512" }; >> 671: private static final String[] HmacSHA3Group = { "HmacSHA3-224", >> 672: "HmacSHA3-256", "HmacSHA3-384", "HmacSHA3-512"}; > > Shall I change these `static final` fields to UPPERCASE? Why? ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Tue Aug 30 21:42:15 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 30 Aug 2022 21:42:15 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 21:25:25 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/jca/ProviderList.java line 672: >> >>> 670: "SHA3-384", "SHA3-512" }; >>> 671: private static final String[] HmacSHA3Group = { "HmacSHA3-224", >>> 672: "HmacSHA3-256", "HmacSHA3-384", "HmacSHA3-512"}; >> >> Shall I change these `static final` fields to UPPERCASE? > > Why? http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-constants ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Tue Aug 30 22:56:58 2022 From: mpowers at openjdk.org (Mark Powers) Date: Tue, 30 Aug 2022 22:56:58 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 21:38:26 GMT, Weijun Wang wrote: >> Why? > > http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html#toc-constants Can't argue with that. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Wed Aug 31 04:27:28 2022 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 31 Aug 2022 04:27:28 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 20:12:19 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 216: > >> 214: >> 215: private void parseNetscapeCertChain(DerValue val) >> 216: throws IOException { > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 263: > >> 261: // signerInfos SignerInfos } >> 262: private void parseSignedData(DerValue val) >> 263: throws IOException { > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs/PKCS7.java line 389: > >> 387: */ >> 388: private void parseOldSignedData(DerValue val) >> 389: throws IOException > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 106: > >> 104: */ >> 105: public SignerInfo(DerInputStream derin) >> 106: throws IOException { > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 121: > >> 119: */ >> 120: public SignerInfo(DerInputStream derin, boolean oldStyle) >> 121: throws IOException { > > Indent 4 more spaces. Fixed. > src/java.base/share/classes/sun/security/pkcs10/PKCS10.java line 369: > >> 367: private final PKCS10Attributes attributeSet; >> 368: private byte[] encoded; // signed >> 369: } > > Either realign all the names or none. Fixed. > src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 216: > >> 214: */ >> 215: public String toString() { >> 216: return map.size() + "\n" + map.toString(); > > `toString` not needed. Fixed. > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 47: > >> 45: >> 46: private String digestAlgorithmName; >> 47: private AlgorithmParameters digestAlgorithmParams; > > Yes, this field is not used now. But one day we might see one that has parameters. I'd rather keep them and maybe fix `getEncoded` by then. I put the field back. > src/java.base/share/classes/sun/security/pkcs12/MacData.java line 58: > >> 56: */ >> 57: MacData(DerInputStream derin) >> 58: throws IOException { > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1723: > >> 1721: if (entry instanceof PrivateKeyEntry keyEntry) { >> 1722: certs = Objects.requireNonNullElseGet(keyEntry.chain, () -> >> 1723: new Certificate[0]); > > I'd rather use `?:`. Fixed. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1809: > >> 1807: */ >> 1808: private byte[] createSafeContent() >> 1809: throws IOException { > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2213: > >> 2211: if (entry.keyId != null) { >> 2212: ArrayList chain = >> 2213: new ArrayList<>(); > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2389: > >> 2387: private void loadSafeContents(DerInputStream stream) >> 2388: throws IOException, CertificateException >> 2389: { > > Put brace to previous line. Fixed. > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 2554: > >> 2552: Long.parseLong(keyIdStr.substring(5))); >> 2553: } catch (Exception e) { >> 2554: date = null; > > Maybe add a comment? `// date has been initialized to null` > src/java.base/share/classes/sun/security/provider/DomainKeyStore.java line 564: > >> 562: } >> 563: return new AbstractMap.SimpleEntry<>("", >> 564: Collections.emptyList()); > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/provider/PolicyParser.java line 576: > >> 574: } >> 575: >> 576: return (ignoreEntry == true) ? null : e; > > Remove definition of `ignoreEntry`. I don't see how that can be done. > src/java.base/share/classes/sun/security/provider/PolicyParser.java line 956: > >> 954: ge.principals = new LinkedList<>(this.principals); >> 955: ge.permissionEntries = >> 956: new Vector<>(this.permissionEntries); > > No need for a newline here. Fixed. > src/java.base/share/classes/sun/security/provider/SecureRandom.java line 235: > >> 233: if (r > 0) { >> 234: // How many bytes? >> 235: todo = Math.min((result.length - index), (DIGEST_SIZE - r)); > > No need for so many parentheses. Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Wed Aug 31 12:22:19 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 31 Aug 2022 12:22:19 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 04:22:46 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/provider/PolicyParser.java line 576: >> >>> 574: } >>> 575: >>> 576: return (ignoreEntry == true) ? null : e; >> >> Remove definition of `ignoreEntry`. > > I don't see how that can be done. Oh, sorry, I confused it with the `parseDomainEntry` method where `ignoreEntry` is useless. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mullan at openjdk.org Wed Aug 31 13:04:19 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 31 Aug 2022 13:04:19 GMT Subject: RFR: 8292681: Add JMH for ProtectionDomain [v3] In-Reply-To: References: Message-ID: <6rmgCjUcbDQFMBoozx1jNFXbfvaJYybuvrpW7GnmX6c=.2c1d333f-2d17-4bbd-bb3b-b618a6dde371@github.com> On Mon, 29 Aug 2022 13:56:28 GMT, Eric Caspole wrote: >> Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. > > Eric Caspole has updated the pull request incrementally with one additional commit since the last revision: > > Changes from advice from Sean M Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/9950 From ecaspole at openjdk.org Wed Aug 31 13:27:48 2022 From: ecaspole at openjdk.org (Eric Caspole) Date: Wed, 31 Aug 2022 13:27:48 GMT Subject: Integrated: 8292681: Add JMH for ProtectionDomain In-Reply-To: References: Message-ID: On Fri, 19 Aug 2022 18:48:10 GMT, Eric Caspole wrote: > Add a JMH for ProtectionDomain related to current work on JDK-8292375. Also, add the InMemoryJavaCompiler to the JMH jar, to generate the classes needed for this test and will be useful for future class loading JMH too. This pull request has now been integrated. Changeset: 5d6779f7 Author: Eric Caspole URL: https://git.openjdk.org/jdk/commit/5d6779f70902b691d901e43ae3e17b16bc22d978 Stats: 136 lines in 2 files changed: 135 ins; 0 del; 1 mod 8292681: Add JMH for ProtectionDomain Reviewed-by: mullan ------------- PR: https://git.openjdk.org/jdk/pull/9950 From mpowers at openjdk.org Wed Aug 31 22:28:38 2022 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 31 Aug 2022 22:28:38 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Tue, 30 Aug 2022 20:23:26 GMT, Weijun Wang wrote: >> Mark Powers has updated the pull request incrementally with one additional commit since the last revision: >> >> white space > > src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 184: > >> 182: return false; >> 183: PKCS10Attribute thisAttr, otherAttr; >> 184: String key; > > This whole `toString` method can be enhanced. Can we just compare `this.map.equals(that.map)`? Don't know what you mean about changing `toString`. I could change `equals` to something like: public boolean equals(Object other) { if (!(other instanceof PKCS10Attributes)) return false; Collection othersAttribs = ((PKCS10Attributes)other).getAttributes(); PKCS10Attribute[] attrs = othersAttribs.toArray(new PKCS10Attribute[0]); PKCS10Attributes foo = new PKCS10Attributes(attrs); return this.map.equals(foo.map); } ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Wed Aug 31 22:28:38 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 31 Aug 2022 22:28:38 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:23:42 GMT, Mark Powers wrote: >> src/java.base/share/classes/sun/security/pkcs10/PKCS10Attributes.java line 184: >> >>> 182: return false; >>> 183: PKCS10Attribute thisAttr, otherAttr; >>> 184: String key; >> >> This whole `toString` method can be enhanced. Can we just compare `this.map.equals(that.map)`? > > Don't know what you mean about changing `toString`. I could change `equals` to something like: > > > public boolean equals(Object other) { > if (!(other instanceof PKCS10Attributes)) > return false; > > Collection othersAttribs = > ((PKCS10Attributes)other).getAttributes(); > PKCS10Attribute[] attrs = > othersAttribs.toArray(new PKCS10Attribute[0]); > PKCS10Attributes foo = new PKCS10Attributes(attrs); > return this.map.equals(foo.map); > } Sorry, I meant `equals`. Why cannot we just compare with `other.map`? ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Wed Aug 31 22:34:18 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 31 Aug 2022 22:34:18 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:25:57 GMT, Weijun Wang wrote: >> Don't know what you mean about changing `toString`. I could change `equals` to something like: >> >> >> public boolean equals(Object other) { >> if (!(other instanceof PKCS10Attributes)) >> return false; >> >> Collection othersAttribs = >> ((PKCS10Attributes)other).getAttributes(); >> PKCS10Attribute[] attrs = >> othersAttribs.toArray(new PKCS10Attribute[0]); >> PKCS10Attributes foo = new PKCS10Attributes(attrs); >> return this.map.equals(foo.map); >> } > > Sorry, I meant `equals`. Why cannot we just compare with `other.map`? Ah, I see. The key for an attr might not be the id. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From weijun at openjdk.org Wed Aug 31 22:34:18 2022 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 31 Aug 2022 22:34:18 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:29:59 GMT, Weijun Wang wrote: >> Sorry, I meant `equals`. Why cannot we just compare with `other.map`? > > Ah, I see. The key for an attr might not be the id. In fact, I am not sure if this method works now. `PKCS10Attribute` has not overridden `equals`. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Wed Aug 31 22:46:12 2022 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 31 Aug 2022 22:46:12 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:30:57 GMT, Weijun Wang wrote: >> Ah, I see. The key for an attr might not be the id. > > In fact, I am not sure if this method works now. `PKCS10Attribute` has not overridden `equals`. Is this method ever used? I see it used in `PKCS10` but the encoding is used for comparison there. And, who would want to compare `PKCS10` objects? The tests that we have all pass. I think I'll intentionally break `equals` and see if the tests still pass. From my experience with PKCS#11, there is no reason to check that attribute arrays are equal. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Wed Aug 31 22:57:13 2022 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 31 Aug 2022 22:57:13 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:43:58 GMT, Mark Powers wrote: >> In fact, I am not sure if this method works now. `PKCS10Attribute` has not overridden `equals`. Is this method ever used? I see it used in `PKCS10` but the encoding is used for comparison there. And, who would want to compare `PKCS10` objects? > > The tests that we have all pass. I think I'll intentionally break `equals` and see if the tests still pass. From my experience with PKCS#11, there is no reason to check that attribute arrays are equal. I broke `equals` to always return false, and tests all passed. ------------- PR: https://git.openjdk.org/jdk/pull/9972 From mpowers at openjdk.org Wed Aug 31 23:01:16 2022 From: mpowers at openjdk.org (Mark Powers) Date: Wed, 31 Aug 2022 23:01:16 GMT Subject: RFR: JDK-8291509 Minor cleanup could be done in sun.security [v3] In-Reply-To: References: <7_dH-nuIf3G8tvAD5dACQhKlTuQ0PsWmgIxoQZdSwko=.4c5fa745-a0dd-40c4-a62e-10aeaf7c7788@github.com> Message-ID: On Wed, 31 Aug 2022 22:55:09 GMT, Mark Powers wrote: >> The tests that we have all pass. I think I'll intentionally break `equals` and see if the tests still pass. From my experience with PKCS#11, there is no reason to check that attribute arrays are equal. > > I broke `equals` to always return false, and tests all passed. Never mind. Dumb test since `equals` is not overridden. ------------- PR: https://git.openjdk.org/jdk/pull/9972