From prem.2007k at gmail.com Tue Nov 3 11:40:36 2015 From: prem.2007k at gmail.com (prem) Date: Tue, 3 Nov 2015 17:10:36 +0530 Subject: Fwd: Need permission for viewing JDK-8067664 In-Reply-To: References: Message-ID: Hey Team , We are been stucked with similar kind of issue here in our system after upgrading to 1.8 jdk. There is workaround mentioned in comment here .But we are not able to view the issue JDK-8067664 ?, its asking for a login ? . Please help us to view the issue Regards, Prem ?, 9884111323? -- Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.coffey at oracle.com Tue Nov 3 12:27:17 2015 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 3 Nov 2015 12:27:17 +0000 Subject: Fwd: Need permission for viewing JDK-8067664 In-Reply-To: References: Message-ID: <5638A825.3000607@oracle.com> There isn't much information available in 8067664. The workaround appears to be as per the short comment - use buffered I/O. /@ DataOutputStream out = new DataOutputStream(new/ /@ BufferedOutputStream(socket.getOutputStream()));/ Seems like a strange bug for sure. Would be good to get some more investigating put into it. Regards, Sean. On 03/11/2015 11:40, prem wrote: > > Hey Team , > We are been stucked with similar kind of issue here > in our system after > upgrading to 1.8 jdk. There is workaround mentioned in comment here > .But > we are not able to view the issue JDK-8067664 > ? , its asking for a login ? > . > > Please help us to view the issue > > > > Regards, > Prem > ? , > 9884111323 ? > > > > -- > > Regards, > Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From prem.2007k at gmail.com Tue Nov 3 12:32:03 2015 From: prem.2007k at gmail.com (prem) Date: Tue, 3 Nov 2015 18:02:03 +0530 Subject: Fwd: Need permission for viewing JDK-8067664 In-Reply-To: <5638A825.3000607@oracle.com> References: <5638A825.3000607@oracle.com> Message-ID: Hey Sean, For us , this seems to be reproducible in production regularly .So we are taking thread dump's for every 10 mins ,all the threads are stuck in sha calculation.BTW we are using SHA512. Will something else data help for investigation ? Thanks for your quick reply :-) On Tue, Nov 3, 2015 at 5:57 PM, Se?n Coffey wrote: > There isn't much information available in 8067664. The workaround appears > to be as per the short comment - use buffered I/O. > > *@ DataOutputStream out = new DataOutputStream(new * > *@ BufferedOutputStream(socket.getOutputStream()));* > > Seems like a strange bug for sure. Would be good to get some more > investigating put into it. > > Regards, > Sean. > > On 03/11/2015 11:40, prem wrote: > > > Hey Team , > We are been stucked with similar kind of issue here > in our system after > upgrading to 1.8 jdk. There is workaround mentioned in comment here > .But > we are not able to view the issue JDK-8067664 > ? , its asking for a login ? > . > > Please help us to view the issue > > > > Regards, > Prem > ? , > 9884111323 ? > > > > -- > > Regards, > Prem > > > -- Regards, Prem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tiantian.du at oracle.com Wed Nov 4 01:55:11 2015 From: tiantian.du at oracle.com (Tim Du) Date: Wed, 4 Nov 2015 09:55:11 +0800 Subject: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA Message-ID: <5639657F.3060006@oracle.com> Hi All: Please help to review testing Preferred provider configuration feature for JCE . JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 https://bugs.openjdk.java.net/browse/JDK-8133151 webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ Thank you very much. Regards Tim From christoph.langer at sap.com Wed Nov 4 11:11:01 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Nov 2015 11:11:01 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F48E21@DEWDFEMB12B.global.corp.sap> Hi Mike, eventually I?ve made a new webrev implementing your suggestion for a simpler patch: http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? Thanks Christoph From: Michael StJohns [mailto:mstjohns at comcast.net] Sent: Donnerstag, 15. Oktober 2015 02:09 To: Langer, Christoph Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here: http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Wed Nov 4 22:19:13 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 4 Nov 2015 14:19:13 -0800 Subject: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <5639657F.3060006@oracle.com> References: <5639657F.3060006@oracle.com> Message-ID: <563A8461.5080703@oracle.com> On 11/03/2015 05:55 PM, Tim Du wrote: > Hi All: > > Please help to review testing Preferred provider configuration feature > for JCE . > > JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 > https://bugs.openjdk.java.net/browse/JDK-8133151 > webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ > > Thank you very much. > > Regards > Tim Thanks for the work Tim, your tests cover pretty much everything.. I've got a few comments, mostly just add-ons or clarifications. 1) I think the best directory for these tests would be test/sun/security/jca/. The jca directory doesn't exist yet, so these would be the first tests. My main code change was in ProviderList.java which is under the java.base module in sun/security/jca/. 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I understand the comment and code correctly, I think you want the comment to say: /* Test that the setting of the security property after Cipher.getInstance() does not influence previously loaded instances */ 3) I think it is valuable to have the failures exceptions to print the expected provider and the provider that was returned. For example: Test Failed: Get wrong provider from Solaris sparcv9 platform Expected provider: SunJCE, Returned provider: OracleUcrypto. 4) In SolarisProviderTest.java, could you add an algorithm test after line 93? I think it is useful to verify an algorithm that is not in the preferred list is not being redirected. For example: MessageDigest md = MessageDigest.getInstance("MD5"); if (!md.getProvider().getName().equals("OracleUcrypto")) { throw new RuntimeException(...); } thanks Tony From tiantian.du at oracle.com Thu Nov 5 08:22:34 2015 From: tiantian.du at oracle.com (Tim Du) Date: Thu, 5 Nov 2015 16:22:34 +0800 Subject: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <563A8461.5080703@oracle.com> References: <5639657F.3060006@oracle.com> <563A8461.5080703@oracle.com> Message-ID: <563B11CA.1070702@oracle.com> Hi Tony: Thanks for reviewing the codes. Updated them follow your suggestion here: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please help to review again. Regards Tim On 11/5/2015 6:19 AM, Anthony Scarpino wrote: > On 11/03/2015 05:55 PM, Tim Du wrote: >> Hi All: >> >> Please help to review testing Preferred provider configuration feature >> for JCE . >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >> https://bugs.openjdk.java.net/browse/JDK-8133151 >> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >> >> Thank you very much. >> >> Regards >> Tim > > Thanks for the work Tim, your tests cover pretty much everything.. > I've got a few comments, mostly just add-ons or clarifications. > > > 1) I think the best directory for these tests would be > test/sun/security/jca/. The jca directory doesn't exist yet, so these > would be the first tests. My main code change was in > ProviderList.java which is under the java.base module in > sun/security/jca/. > > > 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I understand > the comment and code correctly, I think you want the comment to say: > /* Test that the setting of the security property after > Cipher.getInstance() does not influence previously > loaded instances */ > > > 3) I think it is valuable to have the failures exceptions to print the > expected provider and the provider that was returned. For example: > > Test Failed: Get wrong provider from Solaris sparcv9 platform > Expected provider: SunJCE, Returned provider: OracleUcrypto. > > > 4) In SolarisProviderTest.java, could you add an algorithm test after > line 93? I think it is useful to verify an algorithm that is not in > the preferred list is not being redirected. For example: > > MessageDigest md = MessageDigest.getInstance("MD5"); > if (!md.getProvider().getName().equals("OracleUcrypto")) { > throw new RuntimeException(...); > } > > > thanks > > Tony > From anthony.scarpino at oracle.com Thu Nov 5 19:08:46 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 5 Nov 2015 11:08:46 -0800 Subject: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <563B11CA.1070702@oracle.com> References: <5639657F.3060006@oracle.com> <563A8461.5080703@oracle.com> <563B11CA.1070702@oracle.com> Message-ID: <563BA93E.5050602@oracle.com> The changes look good to me. I assume these tests pass? thanks Tony On 11/05/2015 12:22 AM, Tim Du wrote: > Hi Tony: > > Thanks for reviewing the codes. > Updated them follow your suggestion here: > http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please help to > review again. > > Regards > Tim > On 11/5/2015 6:19 AM, Anthony Scarpino wrote: >> On 11/03/2015 05:55 PM, Tim Du wrote: >>> Hi All: >>> >>> Please help to review testing Preferred provider configuration feature >>> for JCE . >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >>> https://bugs.openjdk.java.net/browse/JDK-8133151 >>> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >>> >>> Thank you very much. >>> >>> Regards >>> Tim >> >> Thanks for the work Tim, your tests cover pretty much everything.. >> I've got a few comments, mostly just add-ons or clarifications. >> >> >> 1) I think the best directory for these tests would be >> test/sun/security/jca/. The jca directory doesn't exist yet, so these >> would be the first tests. My main code change was in >> ProviderList.java which is under the java.base module in >> sun/security/jca/. >> >> >> 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I understand >> the comment and code correctly, I think you want the comment to say: >> /* Test that the setting of the security property after >> Cipher.getInstance() does not influence previously >> loaded instances */ >> >> >> 3) I think it is valuable to have the failures exceptions to print the >> expected provider and the provider that was returned. For example: >> >> Test Failed: Get wrong provider from Solaris sparcv9 platform >> Expected provider: SunJCE, Returned provider: OracleUcrypto. >> >> >> 4) In SolarisProviderTest.java, could you add an algorithm test after >> line 93? I think it is useful to verify an algorithm that is not in >> the preferred list is not being redirected. For example: >> >> MessageDigest md = MessageDigest.getInstance("MD5"); >> if (!md.getProvider().getName().equals("OracleUcrypto")) { >> throw new RuntimeException(...); >> } >> >> >> thanks >> >> Tony >> > From tiantian.du at oracle.com Fri Nov 6 06:19:40 2015 From: tiantian.du at oracle.com (Tim Du) Date: Fri, 6 Nov 2015 14:19:40 +0800 Subject: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <563BA93E.5050602@oracle.com> References: <5639657F.3060006@oracle.com> <563A8461.5080703@oracle.com> <563B11CA.1070702@oracle.com> <563BA93E.5050602@oracle.com> Message-ID: <563C467C.7060605@oracle.com> Hi Tony: On 11/6/2015 3:08 AM, Anthony Scarpino wrote: > The changes look good to me. I assume these tests pass? Yes, The tests are designed to run on Solaris platforms, I tested them on Solairs-sparcv9 ans Solairs-x64 , Both of them could pass. For other platforms,The tests will be skipped execution. If so,Could I plan to push the code into openjdk repo? Thanks Regards Tim > > thanks > > Tony > > On 11/05/2015 12:22 AM, Tim Du wrote: >> Hi Tony: >> >> Thanks for reviewing the codes. >> Updated them follow your suggestion here: >> http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please help to >> review again. >> >> Regards >> Tim >> On 11/5/2015 6:19 AM, Anthony Scarpino wrote: >>> On 11/03/2015 05:55 PM, Tim Du wrote: >>>> Hi All: >>>> >>>> Please help to review testing Preferred provider configuration feature >>>> for JCE . >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >>>> https://bugs.openjdk.java.net/browse/JDK-8133151 >>>> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >>>> >>>> Thank you very much. >>>> >>>> Regards >>>> Tim >>> >>> Thanks for the work Tim, your tests cover pretty much everything.. >>> I've got a few comments, mostly just add-ons or clarifications. >>> >>> >>> 1) I think the best directory for these tests would be >>> test/sun/security/jca/. The jca directory doesn't exist yet, so these >>> would be the first tests. My main code change was in >>> ProviderList.java which is under the java.base module in >>> sun/security/jca/. >>> >>> >>> 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I understand >>> the comment and code correctly, I think you want the comment to say: >>> /* Test that the setting of the security property after >>> Cipher.getInstance() does not influence previously >>> loaded instances */ >>> >>> >>> 3) I think it is valuable to have the failures exceptions to print the >>> expected provider and the provider that was returned. For example: >>> >>> Test Failed: Get wrong provider from Solaris sparcv9 platform >>> Expected provider: SunJCE, Returned provider: OracleUcrypto. >>> >>> >>> 4) In SolarisProviderTest.java, could you add an algorithm test after >>> line 93? I think it is useful to verify an algorithm that is not in >>> the preferred list is not being redirected. For example: >>> >>> MessageDigest md = MessageDigest.getInstance("MD5"); >>> if (!md.getProvider().getName().equals("OracleUcrypto")) { >>> throw new RuntimeException(...); >>> } >>> >>> >>> thanks >>> >>> Tony >>> >> > From chris.hegarty at oracle.com Fri Nov 6 09:19:01 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 Nov 2015 09:19:01 +0000 Subject: Fwd: RFR [9] 8140606: Update library code to use internal Unsafe References: Message-ID: <344C92CE-0AC4-4FB1-AE21-3664CD445AB0@oracle.com> Forwarding to additional area specific mailing lists, as there are changes in the webrev that affect their area. -Chris. Begin forwarded message: > From: Chris Hegarty > Subject: RFR [9] 8140606: Update library code to use internal Unsafe > Date: 28 October 2015 19:55:41 GMT > To: "core-libs-dev at openjdk.java.net Libs" > > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 From weijun.wang at oracle.com Fri Nov 6 14:33:15 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 6 Nov 2015 22:33:15 +0800 Subject: Fwd: RFR [9] 8140606: Update library code to use internal Unsafe In-Reply-To: <344C92CE-0AC4-4FB1-AE21-3664CD445AB0@oracle.com> References: <344C92CE-0AC4-4FB1-AE21-3664CD445AB0@oracle.com> Message-ID: <563CBA2B.7080009@oracle.com> The code change in java.security.jgss looks fine to me. Thanks Max On 11/6/2015 17:19, Chris Hegarty wrote: > Forwarding to additional area specific mailing lists, as there are changes > in the webrev that affect their area. > > -Chris. > > Begin forwarded message: > >> >http://cr.openjdk.java.net/~chegar/8140606/00/ From valerie.peng at oracle.com Sat Nov 7 01:26:52 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 06 Nov 2015 17:26:52 -0800 Subject: review request for CCC 8004078 [docs] Create Standard Names for SHA-3 algorithms. Message-ID: <563D535C.8040209@oracle.com> Sean, I have created a CCC for 8004078 [docs] Create Standard Names for SHA-3 algorithms. http://ccc.us.oracle.com/8004078 This is for documenting SHA-3 in the Standard Name Documentation. The actual doc change will be handled by the doc team. Can you please review it before I fast-track? Thanks, Valerie From weijun.wang at oracle.com Sat Nov 7 02:51:34 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 7 Nov 2015 10:51:34 +0800 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac Message-ID: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> I find something strange. Background: a new method getentropy() is available on OpenBSD [1] and Solaris and people are also proposing it on other OSes. Therefore inside JDK I write a piece of native code to detect it, something like typedef int (*GETENTROPY_FN)(char* buffer, int len); getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if (getentropy) { return 1; } On Mac, it returns non-NULL, but a later call to (*getentropy)(cbuffer, length) shows # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 ... # Problematic frame: # C [libj2rand.dylib+0x1030] getentropy+0x0 However, "man getentropy" does not show anything, and the following simple program also prints out 0x0 #include #include main() { void* g = dlsym(RTLD_DEFAULT, "getentropy"); printf("%p\n", g); } What does this mean? Is the JDK code loading another getentropy() somewhere else? How do I detect it and what shall I do to avoid it? Thanks Max [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 From weijun.wang at oracle.com Sat Nov 7 08:02:31 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 7 Nov 2015 16:02:31 +0800 Subject: review request for CCC 8004078 [docs] Create Standard Names for SHA-3 algorithms. In-Reply-To: <563D535C.8040209@oracle.com> References: <563D535C.8040209@oracle.com> Message-ID: Should the CCC include the description column for the new algorithm names? FIPS 202 also mentioned HMAC on the new algorithms. Shall we also add them? What is an extendable-output function (XOFs, SHAKE128/SHAKE256)? Are we going to support it? Does it need a new API? (Seems it looks like a hash with an integer parameter). Shall we add a link to the NIST doc? Thanks Max > On Nov 7, 2015, at 9:26 AM, Valerie Peng wrote: > > Sean, > > I have created a CCC for 8004078 [docs] Create Standard Names for SHA-3 algorithms. > > http://ccc.us.oracle.com/8004078 > > This is for documenting SHA-3 in the Standard Name Documentation. The actual doc change will be handled by the doc team. > Can you please review it before I fast-track? > > Thanks, > Valerie From dmitry.samersoff at oracle.com Sat Nov 7 20:29:31 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 7 Nov 2015 23:29:31 +0300 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> Message-ID: <563E5F2B.7060808@oracle.com> Wang Weijun, 1. RTLD_DEFAUL call is expensive and dangerous because it cause symbol search across all loaded images. So it can pick up something absolutely irrelevant to your expectations at any time. If you decide to play to this game, you have to use dladdr to check the origin of a symbol and try to guess whether it is what you are looking for or not. Please dlopen(libSystem.dylib, RTLD_NOW) and search through it only. 2. You shouldn't rely on return value of dlopen() or dlsym(). Call dlerror() and check whether it returns error or NULL. PS: What is the goal of using a getentropy ? -Dmitry On 2015-11-07 05:51, Wang Weijun wrote: > I find something strange. > > Background: a new method getentropy() is available on OpenBSD [1] and Solaris and people are also proposing it on other OSes. > > Therefore inside JDK I write a piece of native code to detect it, something like > > typedef int (*GETENTROPY_FN)(char* buffer, int len); > > getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); > if (getentropy) { > return 1; > } > > On Mac, it returns non-NULL, but a later call to (*getentropy)(cbuffer, length) shows > > # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 > ... > # Problematic frame: > # C [libj2rand.dylib+0x1030] getentropy+0x0 > > However, "man getentropy" does not show anything, and the following simple program also prints out 0x0 > > #include > #include > > main() { > void* g = dlsym(RTLD_DEFAULT, "getentropy"); > printf("%p\n", g); > } > > What does this mean? Is the JDK code loading another getentropy() somewhere else? How do I detect it and what shall I do to avoid it? > > Thanks > Max > > [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From weijun.wang at oracle.com Sun Nov 8 00:37:16 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 8 Nov 2015 08:37:16 +0800 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <563E5F2B.7060808@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> Message-ID: <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> > On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff wrote: > > Wang Weijun, > > 1. RTLD_DEFAUL call is expensive and dangerous because it cause symbol > search across all loaded images. So it can pick up something absolutely > irrelevant to your expectations at any time. > > If you decide to play to this game, you have to use dladdr to check the > origin of a symbol and try to guess whether it is what you are looking > for or not. > > Please dlopen(libSystem.dylib, RTLD_NOW) and search through it only. > > 2. You shouldn't rely on return value of dlopen() or dlsym(). Call > dlerror() and check whether it returns error or NULL. I'll try. > > PS: > What is the goal of using a get entropy ? The function is rather new in the latest Solaris beta [1] and it's preferred to reading from /dev/random. There are already people suggest adding it to Linux. If I use simply using dlsym then it will automatically work on all current and future platforms. In fact, I was planning to write getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if (getentropy) { return 1; } else { getrandom = (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) { return 2; } else { return -1; // will read /dev/random } } Thanks Max [1] https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy > > -Dmitry > > On 2015-11-07 05:51, Wang Weijun wrote: >> I find something strange. >> >> Background: a new method getentropy() is available on OpenBSD [1] and Solaris and people are also proposing it on other OSes. >> >> Therefore inside JDK I write a piece of native code to detect it, something like >> >> typedef int (*GETENTROPY_FN)(char* buffer, int len); >> >> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); >> if (getentropy) { >> return 1; >> } >> >> On Mac, it returns non-NULL, but a later call to (*getentropy)(cbuffer, length) shows >> >> # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 >> ... >> # Problematic frame: >> # C [libj2rand.dylib+0x1030] getentropy+0x0 >> >> However, "man getentropy" does not show anything, and the following simple program also prints out 0x0 >> >> #include >> #include >> >> main() { >> void* g = dlsym(RTLD_DEFAULT, "getentropy"); >> printf("%p\n", g); >> } >> >> What does this mean? Is the JDK code loading another getentropy() somewhere else? How do I detect it and what shall I do to avoid it? >> >> Thanks >> Max >> >> [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Sun Nov 8 11:18:29 2015 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sun, 8 Nov 2015 14:18:29 +0300 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> Message-ID: <563F2F85.50706@oracle.com> Wang Weijun, > The function is rather new in the latest Solaris beta [1] and it's > preferred to reading from /dev/random. There are already people > suggest adding it to Linux. If I use simply using dlsym then it will > automatically work on all current and future platforms. In fact, I > was planning to write 1. Please, check libc only not entire process image. 2. OS X random system is a different story: /dev/random never blocks and returns the output of Yarrow PRNG. Also OS X uses SecurityServer process to feed entropy pool. So IMHO, it's better to don't attempt to use other functions on OS X until it appears officially. 3. Please notice that: /dev/random will block if you request more bits than entropy pool can provide. but (according to manual page) getentropy will return immediately with error if less that requested bytes of entropy is available and you can't request more than 256 bytes of entropy at once. it might require changes in uplevel logic. -Dmitry On 2015-11-08 03:37, Wang Weijun wrote: > >> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff >> wrote: >> >> Wang Weijun, >> >> 1. RTLD_DEFAUL call is expensive and dangerous because it cause >> symbol search across all loaded images. So it can pick up something >> absolutely irrelevant to your expectations at any time. >> >> If you decide to play to this game, you have to use dladdr to check >> the origin of a symbol and try to guess whether it is what you are >> looking for or not. >> >> Please dlopen(libSystem.dylib, RTLD_NOW) and search through it >> only. >> >> 2. You shouldn't rely on return value of dlopen() or dlsym(). Call >> dlerror() and check whether it returns error or NULL. > > I'll try. > >> >> PS: What is the goal of using a get entropy ? > > The function is rather new in the latest Solaris beta [1] and it's > preferred to reading from /dev/random. There are already people > suggest adding it to Linux. If I use simply using dlsym then it will > automatically work on all current and future platforms. In fact, I > was planning to write > > getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if > (getentropy) { return 1; } else { getrandom = > (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) { > return 2; } else { return -1; // will read /dev/random } } > > Thanks Max > > [1] > https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy > > >> >> -Dmitry >> >> On 2015-11-07 05:51, Wang Weijun wrote: >>> I find something strange. >>> >>> Background: a new method getentropy() is available on OpenBSD [1] >>> and Solaris and people are also proposing it on other OSes. >>> >>> Therefore inside JDK I write a piece of native code to detect it, >>> something like >>> >>> typedef int (*GETENTROPY_FN)(char* buffer, int len); >>> >>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>> (getentropy) { return 1; } >>> >>> On Mac, it returns non-NULL, but a later call to >>> (*getentropy)(cbuffer, length) shows >>> >>> # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 >>> ... # Problematic frame: # C [libj2rand.dylib+0x1030] >>> getentropy+0x0 >>> >>> However, "man getentropy" does not show anything, and the >>> following simple program also prints out 0x0 >>> >>> #include #include >>> >>> main() { void* g = dlsym(RTLD_DEFAULT, "getentropy"); >>> printf("%p\n", g); } >>> >>> What does this mean? Is the JDK code loading another getentropy() >>> somewhere else? How do I detect it and what shall I do to avoid >>> it? >>> >>> Thanks Max >>> >>> [1] >>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 >>> >> >> >> >>> -- >> Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me >> the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mstjohns at comcast.net Sun Nov 8 21:45:22 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Sun, 8 Nov 2015 16:45:22 -0500 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <563F2F85.50706@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> <563F2F85.50706@oracle.com> Message-ID: <563FC272.3030309@comcast.net> Hi Max et al - In general, I'm not a big fan of silent failover in security stuff. There ought to be a way - perhaps a system property - to signal that if you don't get the originally desired entropy source, you'll throw an error. Also, have you considered: * https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide?language=fr *If you're going into the raw libraries, it might actually be a better idea to go straight to the chipset if RDSEED is available. (Hmm... also http://stackoverflow.com/questions/29372893/rdrand-and-rdseed-intrinsics-gcc-and-intel-c) Mike On 11/8/2015 6:18 AM, Dmitry Samersoff wrote: > Wang Weijun, > >> The function is rather new in the latest Solaris beta [1] and it's >> preferred to reading from /dev/random. There are already people >> suggest adding it to Linux. If I use simply using dlsym then it will >> automatically work on all current and future platforms. In fact, I >> was planning to write > 1. Please, check libc only not entire process image. > > 2. OS X random system is a different story: /dev/random never blocks and > returns the output of Yarrow PRNG. Also OS X uses SecurityServer > process to feed entropy pool. > > So IMHO, it's better to don't attempt to use other functions on OS X > until it appears officially. > > 3. Please notice that: > > /dev/random will block if you request more bits than entropy pool can > provide. > > but (according to manual page) getentropy will return immediately > with error if less that requested bytes of entropy is available and you > can't request more than 256 bytes of entropy at once. > > it might require changes in uplevel logic. > > -Dmitry > > > On 2015-11-08 03:37, Wang Weijun wrote: >>> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff >>> wrote: >>> >>> Wang Weijun, >>> >>> 1. RTLD_DEFAUL call is expensive and dangerous because it cause >>> symbol search across all loaded images. So it can pick up something >>> absolutely irrelevant to your expectations at any time. >>> >>> If you decide to play to this game, you have to use dladdr to check >>> the origin of a symbol and try to guess whether it is what you are >>> looking for or not. >>> >>> Please dlopen(libSystem.dylib, RTLD_NOW) and search through it >>> only. >>> >>> 2. You shouldn't rely on return value of dlopen() or dlsym(). Call >>> dlerror() and check whether it returns error or NULL. >> I'll try. >> >>> PS: What is the goal of using a get entropy ? >> The function is rather new in the latest Solaris beta [1] and it's >> preferred to reading from /dev/random. There are already people >> suggest adding it to Linux. If I use simply using dlsym then it will >> automatically work on all current and future platforms. In fact, I >> was planning to write >> >> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >> (getentropy) { return 1; } else { getrandom = >> (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) { >> return 2; } else { return -1; // will read /dev/random } } >> >> Thanks Max >> >> [1] >> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy >> >> >>> -Dmitry >>> >>> On 2015-11-07 05:51, Wang Weijun wrote: >>>> I find something strange. >>>> >>>> Background: a new method getentropy() is available on OpenBSD [1] >>>> and Solaris and people are also proposing it on other OSes. >>>> >>>> Therefore inside JDK I write a piece of native code to detect it, >>>> something like >>>> >>>> typedef int (*GETENTROPY_FN)(char* buffer, int len); >>>> >>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>>> (getentropy) { return 1; } >>>> >>>> On Mac, it returns non-NULL, but a later call to >>>> (*getentropy)(cbuffer, length) shows >>>> >>>> # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 >>>> ... # Problematic frame: # C [libj2rand.dylib+0x1030] >>>> getentropy+0x0 >>>> >>>> However, "man getentropy" does not show anything, and the >>>> following simple program also prints out 0x0 >>>> >>>> #include #include >>>> >>>> main() { void* g = dlsym(RTLD_DEFAULT, "getentropy"); >>>> printf("%p\n", g); } >>>> >>>> What does this mean? Is the JDK code loading another getentropy() >>>> somewhere else? How do I detect it and what shall I do to avoid >>>> it? >>>> >>>> Thanks Max >>>> >>>> [1] >>>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 >>>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Nov 9 01:40:32 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Nov 2015 09:40:32 +0800 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <563FC272.3030309@comcast.net> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> <563F2F85.50706@oracle.com> <563FC272.3030309@comcast.net> Message-ID: <7FD0F4AD-2256-4AE8-B494-6A35DF7BF50D@oracle.com> > On Nov 9, 2015, at 5:45 AM, Mike StJohns wrote: > > Hi Max et al - > > In general, I'm not a big fan of silent failover in security stuff. There ought to be a way - perhaps a system property - to signal that if you don't get the originally desired entropy source, you'll throw an error. Agreed. I can use securerandom.source inside java.security. > > Also, have you considered: > > https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide?language=fr > > If you're going into the raw libraries, it might actually be a better idea to go straight to the chipset if RDSEED is available. > > (Hmm... also http://stackoverflow.com/questions/29372893/rdrand-and-rdseed-intrinsics-gcc-and-intel-c) Thanks for the links. That will be a nice enhancement. BTW, I'll file separate bugs for EntropyInput implementations. These are non-goals for the DRBG feature itself. Thanks Max > > Mike > > > On 11/8/2015 6:18 AM, Dmitry Samersoff wrote: >> Wang Weijun, >> >> >>> The function is rather new in the latest Solaris beta [1] and it's >>> preferred to reading from /dev/random. There are already people >>> suggest adding it to Linux. If I use simply using dlsym then it will >>> automatically work on all current and future platforms. In fact, I >>> was planning to write >>> >> 1. Please, check libc only not entire process image. >> >> 2. OS X random system is a different story: /dev/random never blocks and >> returns the output of Yarrow PRNG. Also OS X uses SecurityServer >> process to feed entropy pool. >> >> So IMHO, it's better to don't attempt to use other functions on OS X >> until it appears officially. >> >> 3. Please notice that: >> >> /dev/random will block if you request more bits than entropy pool can >> provide. >> >> but (according to manual page) getentropy will return immediately >> with error if less that requested bytes of entropy is available and you >> can't request more than 256 bytes of entropy at once. >> >> it might require changes in uplevel logic. >> >> -Dmitry >> >> >> On 2015-11-08 03:37, Wang Weijun wrote: >> >>>> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff >>>> >>>> >>>> wrote: >>>> >>>> Wang Weijun, >>>> >>>> 1. RTLD_DEFAUL call is expensive and dangerous because it cause >>>> symbol search across all loaded images. So it can pick up something >>>> absolutely irrelevant to your expectations at any time. >>>> >>>> If you decide to play to this game, you have to use dladdr to check >>>> the origin of a symbol and try to guess whether it is what you are >>>> looking for or not. >>>> >>>> Please dlopen(libSystem.dylib, RTLD_NOW) and search through it >>>> only. >>>> >>>> 2. You shouldn't rely on return value of dlopen() or dlsym(). Call >>>> dlerror() and check whether it returns error or NULL. >>>> >>> I'll try. >>> >>> >>>> PS: What is the goal of using a get entropy ? >>>> >>> The function is rather new in the latest Solaris beta [1] and it's >>> preferred to reading from /dev/random. There are already people >>> suggest adding it to Linux. If I use simply using dlsym then it will >>> automatically work on all current and future platforms. In fact, I >>> was planning to write >>> >>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>> (getentropy) { return 1; } else { getrandom = >>> (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) { >>> return 2; } else { return -1; // will read /dev/random } } >>> >>> Thanks Max >>> >>> [1] >>> >>> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy >>> >>> >>> >>> >>>> -Dmitry >>>> >>>> On 2015-11-07 05:51, Wang Weijun wrote: >>>> >>>>> I find something strange. >>>>> >>>>> Background: a new method getentropy() is available on OpenBSD [1] >>>>> and Solaris and people are also proposing it on other OSes. >>>>> >>>>> Therefore inside JDK I write a piece of native code to detect it, >>>>> something like >>>>> >>>>> typedef int (*GETENTROPY_FN)(char* buffer, int len); >>>>> >>>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>>>> (getentropy) { return 1; } >>>>> >>>>> On Mac, it returns non-NULL, but a later call to >>>>> (*getentropy)(cbuffer, length) shows >>>>> >>>>> # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 >>>>> ... # Problematic frame: # C [libj2rand.dylib+0x1030] >>>>> getentropy+0x0 >>>>> >>>>> However, "man getentropy" does not show anything, and the >>>>> following simple program also prints out 0x0 >>>>> >>>>> #include #include >>>>> >>>>> main() { void* g = dlsym(RTLD_DEFAULT, "getentropy"); >>>>> printf("%p\n", g); } >>>>> >>>>> What does this mean? Is the JDK code loading another getentropy() >>>>> somewhere else? How do I detect it and what shall I do to avoid >>>>> it? >>>>> >>>>> Thanks Max >>>>> >>>>> [1] >>>>> >>>>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 >>>>> >>>>> >>>>> >>>> >>>> >>>> > From mstjohns at comcast.net Mon Nov 9 02:36:37 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Sun, 8 Nov 2015 21:36:37 -0500 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <7FD0F4AD-2256-4AE8-B494-6A35DF7BF50D@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> <563F2F85.50706@oracle.com> <563FC272.3030309@comcast.net> <7FD0F4AD-2256-4AE8-B494-6A35DF7BF50D@oracle.com> Message-ID: <564006B5.8030702@comcast.net> On 11/8/2015 8:40 PM, Wang Weijun wrote: >> On Nov 9, 2015, at 5:45 AM, Mike StJohns wrote: >> >> Hi Max et al - >> >> In general, I'm not a big fan of silent failover in security stuff. There ought to be a way - perhaps a system property - to signal that if you don't get the originally desired entropy source, you'll throw an error. > Agreed. I can use securerandom.source inside java.security. securerandom.entropy.source? > >> Also, have you considered: >> >> https://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide?language=fr >> >> If you're going into the raw libraries, it might actually be a better idea to go straight to the chipset if RDSEED is available. >> >> (Hmm... also http://stackoverflow.com/questions/29372893/rdrand-and-rdseed-intrinsics-gcc-and-intel-c) > Thanks for the links. That will be a nice enhancement. > > BTW, I'll file separate bugs for EntropyInput implementations. These are non-goals for the DRBG feature itself. Yup - Mike > > Thanks > Max > >> Mike >> >> >> On 11/8/2015 6:18 AM, Dmitry Samersoff wrote: >>> Wang Weijun, >>> >>> >>>> The function is rather new in the latest Solaris beta [1] and it's >>>> preferred to reading from /dev/random. There are already people >>>> suggest adding it to Linux. If I use simply using dlsym then it will >>>> automatically work on all current and future platforms. In fact, I >>>> was planning to write >>>> >>> 1. Please, check libc only not entire process image. >>> >>> 2. OS X random system is a different story: /dev/random never blocks and >>> returns the output of Yarrow PRNG. Also OS X uses SecurityServer >>> process to feed entropy pool. >>> >>> So IMHO, it's better to don't attempt to use other functions on OS X >>> until it appears officially. >>> >>> 3. Please notice that: >>> >>> /dev/random will block if you request more bits than entropy pool can >>> provide. >>> >>> but (according to manual page) getentropy will return immediately >>> with error if less that requested bytes of entropy is available and you >>> can't request more than 256 bytes of entropy at once. >>> >>> it might require changes in uplevel logic. >>> >>> -Dmitry >>> >>> >>> On 2015-11-08 03:37, Wang Weijun wrote: >>> >>>>> On Nov 8, 2015, at 4:29 AM, Dmitry Samersoff >>>>> >>>>> >>>>> wrote: >>>>> >>>>> Wang Weijun, >>>>> >>>>> 1. RTLD_DEFAUL call is expensive and dangerous because it cause >>>>> symbol search across all loaded images. So it can pick up something >>>>> absolutely irrelevant to your expectations at any time. >>>>> >>>>> If you decide to play to this game, you have to use dladdr to check >>>>> the origin of a symbol and try to guess whether it is what you are >>>>> looking for or not. >>>>> >>>>> Please dlopen(libSystem.dylib, RTLD_NOW) and search through it >>>>> only. >>>>> >>>>> 2. You shouldn't rely on return value of dlopen() or dlsym(). Call >>>>> dlerror() and check whether it returns error or NULL. >>>>> >>>> I'll try. >>>> >>>> >>>>> PS: What is the goal of using a get entropy ? >>>>> >>>> The function is rather new in the latest Solaris beta [1] and it's >>>> preferred to reading from /dev/random. There are already people >>>> suggest adding it to Linux. If I use simply using dlsym then it will >>>> automatically work on all current and future platforms. In fact, I >>>> was planning to write >>>> >>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>>> (getentropy) { return 1; } else { getrandom = >>>> (GETRANDOM_FN)dlsym(RTLD_DEFAULT, "getrandom"); if (getrandom) { >>>> return 2; } else { return -1; // will read /dev/random } } >>>> >>>> Thanks Max >>>> >>>> [1] >>>> >>>> https://blogs.oracle.com/darren/entry/solaris_new_system_calls_getentropy >>>> >>>> >>>> >>>> >>>>> -Dmitry >>>>> >>>>> On 2015-11-07 05:51, Wang Weijun wrote: >>>>> >>>>>> I find something strange. >>>>>> >>>>>> Background: a new method getentropy() is available on OpenBSD [1] >>>>>> and Solaris and people are also proposing it on other OSes. >>>>>> >>>>>> Therefore inside JDK I write a piece of native code to detect it, >>>>>> something like >>>>>> >>>>>> typedef int (*GETENTROPY_FN)(char* buffer, int len); >>>>>> >>>>>> getentropy = (GETENTROPY_FN)dlsym(RTLD_DEFAULT, "getentropy"); if >>>>>> (getentropy) { return 1; } >>>>>> >>>>>> On Mac, it returns non-NULL, but a later call to >>>>>> (*getentropy)(cbuffer, length) shows >>>>>> >>>>>> # SIGBUS (0xa) at pc=0x0000000103bfa030, pid=22434, tid=5891 >>>>>> ... # Problematic frame: # C [libj2rand.dylib+0x1030] >>>>>> getentropy+0x0 >>>>>> >>>>>> However, "man getentropy" does not show anything, and the >>>>>> following simple program also prints out 0x0 >>>>>> >>>>>> #include #include >>>>>> >>>>>> main() { void* g = dlsym(RTLD_DEFAULT, "getentropy"); >>>>>> printf("%p\n", g); } >>>>>> >>>>>> What does this mean? Is the JDK code loading another getentropy() >>>>>> somewhere else? How do I detect it and what shall I do to avoid >>>>>> it? >>>>>> >>>>>> Thanks Max >>>>>> >>>>>> [1] >>>>>> >>>>>> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2 >>>>>> >>>>>> >>>>>> >>>>> >>>>> > From weijun.wang at oracle.com Mon Nov 9 03:35:33 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Nov 2015 11:35:33 +0800 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <563F2F85.50706@oracle.com> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> <563F2F85.50706@oracle.com> Message-ID: > On Nov 8, 2015, at 7:18 PM, Dmitry Samersoff wrote: > > Wang Weijun, > >> The function is rather new in the latest Solaris beta [1] and it's >> preferred to reading from /dev/random. There are already people >> suggest adding it to Linux. If I use simply using dlsym then it will >> automatically work on all current and future platforms. In fact, I >> was planning to write > > 1. Please, check libc only not entire process image. dlopen("libc.so", RTLD_LAZY)? This works on Solaris but on Linux seems I have to use "libc.so.6". > > > 2. OS X random system is a different story: /dev/random never blocks and > returns the output of Yarrow PRNG. Also OS X uses SecurityServer > process to feed entropy pool. > > So IMHO, it's better to don't attempt to use other functions on OS X > until it appears officially. OK. > > 3. Please notice that: > > /dev/random will block if you request more bits than entropy pool can > provide. > > but (according to manual page) getentropy will return immediately > with error if less that requested bytes of entropy is available and you > can't request more than 256 bytes of entropy at once. > > it might require changes in uplevel logic. Not much. I won't need much entropy. Thanks Max > > -Dmitry From weijun.wang at oracle.com Mon Nov 9 03:45:49 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Nov 2015 11:45:49 +0800 Subject: dlsym(RTLD_DEFAULT, "getentropy") return non-NULL on Mac In-Reply-To: <564006B5.8030702@comcast.net> References: <6A6DCBA6-677D-40A0-9B56-40F10E32F8A6@oracle.com> <563E5F2B.7060808@oracle.com> <19EF8342-E16E-4699-ACD8-5B0F4611947B@oracle.com> <563F2F85.50706@oracle.com> <563FC272.3030309@comcast.net> <7FD0F4AD-2256-4AE8-B494-6A35DF7BF50D@oracle.com> <564006B5.8030702@comcast.net> Message-ID: <99D93253-2B2B-4962-A82F-0599B3C2AEF2@oracle.com> > On Nov 9, 2015, at 10:36 AM, Mike StJohns wrote: > >> Agreed. I can use securerandom.source inside java.security. > > securerandom.entropy.source? I would like to reuse the existing securerandom.source. Will investigate if there is any unexpected behavior. --Max From weijun.wang at oracle.com Mon Nov 9 07:35:42 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Nov 2015 15:35:42 +0800 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete Message-ID: Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ JDK-8133151 added support for "#ifdef solaris-sparc" but not "#ifndef solaris-spare". This is fixed and I also added "#else". How do I test the change? Thanks Max From weijun.wang at oracle.com Mon Nov 9 14:54:37 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 9 Nov 2015 22:54:37 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations Message-ID: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> Hi All The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at https://bugs.openjdk.java.net/browse/JDK-8051408 Some notes before the text: 1. Mainly, new methods are added to SecureRandom to match DRBG functions: - configure: choosing the algorithms and parameters - reseed: reseed using configured entropy. This is not same as existing setSeed() which reseeds using a caller-provided seed - nextBytes: random bits generation, with support for additional input Like the existing ones, DRBGs will still be initiated automatically when nextBytes() is called. SecureRandomSpi is also updated with related engine methods. 2. The new APIs will apply to all existing SecureRandom implementations, although some is just a no-op. We believe the concepts apply to all. 3. An EntropyInput interface is introduced to model source of entropy input. We will provide some internal implementations so these DRBGs work out of box. However, we won't expose any implementation that an application can use directly. If you have a special entropy source, just implement the interface yourself. Also note the interface is super simple now. New methods (or getInstance() methods) might be added in the future. 4. Three new SecureRandom algorithms are provided by the SUN provider - HashDRBG, HmacDRBH, and CTRDRBG. Here is an example: SecureRandom sr = SecureRandom.getInstance("HashDRBG"); hd.configure(new DrbgSpec("SHA-512", -1, true, false, nonce, person), new MyEntropyInput()); hg.nextBytes(output, additional); hg.reseed(additional2); Any suggestion is welcome. Thanks Max -----API START----- package java.security; /** * * .... * *

Some SecureRandom implementations can be further configured by * calling {@link #configure}. For example, a DRBG mechanism can be configured * by a {@link DrbgSpec} object. * * .... * *

A SecureRandom can be reseeded by itself by calling {@link #reseed}. * A caller can also reseed it a user-provided seed by calling * {@link #setSeed(byte[])}. * * .... * *

Except for one created by {@link #SecureRandom(byte[])}, * a newly created SecureRandom object is usually not seeded. To seed the * returned object, call the {@code setSeed} method. * If {@code setSeed} is not called, the first call to * {@code nextBytes} or {@code reseed} will force the SecureRandom * object to seed itself. This self-seeding will not occur * if {@code setSeed} was previously called. * *

* Note: Depending on the implementation, the {@code generateSeed}, * {@code reseed} and {@code nextBytes} methods may block as entropy is being * gathered, for example, if they need to read from /dev/random on various * Unix-like operating systems. */ public class SecureRandom { .... /** * Configure this {@code SecureRandom} with an {@link AlgorithmParameterSpec} * object and a source of entropy input. * * @implNote The actual type of {@code spec} must match the algorithm of this * {@code SecureRandom} object. Fo example, a DRBG must be configured by * a {@link DrbgSpec}. Otherwise, an {@link IllegalArgumentException} * should be thrown. *

* If {@code ei} is null, a default EntropyInput will be chosen. If not * null, the caller needs to make sure the EntropyInput matches the * {@code SecureRandom} to be configured with enough security strength, * live entropy, and other features. * * @param spec the {@link AlgorithmParameterSpec} object. Null if not needed. * @param ei the source of entropy input. Null if not user-chosen. * @throws IllegalArgumentException if {@code spec} is not recognized by * this {@code SecureRandom} object. * @since 1.9 */ public void configure(AlgorithmParameterSpec spec, EntropyInput ei); /** * Generates a user-specified number of random bytes with an optional * additional input argument. * * @param bytes the array to be filled in with random bytes. * @param additionalInput an optional additional input argument. * @since 1.9 */ public void nextBytes(byte[] bytes, byte[] additionalInput); /** * Reseeds this {@code SecureRandom} with entropy read from its * {@code EntropyInput} and an optional additional data. *

* Note that the entropy is obtained from {@code EntropyInput}. While * {@code additional} may contain entropy but its main usage is to * provide diversity. * * @param additionalInput an optional additional input argument. * @since 1.9 */ public void reseed(byte[] additionalInput); .... } public abstract class SecureRandomSpi { /** * Configure this random object. * * @param spec the {@link AlgorithmParameterSpec} object. Null if not needed. * @param ei the source of entropy input. Null if not user-chosen. * @throws IllegalArgumentException if this random object does not need * to be configured or it does not recongize {@code spec}. * @since 1.9 */ protected void engineConfigure(AlgorithmParameterSpec spec, EntropyInput ei); /** * Generates random bits. * * @param bytes output. * @param additionalInput optional additional input. * @since 1.9 */ public void engineGenerate(byte[] bytes, byte[] additionalInput); /** * Reseeds this random object with entropy read from its * {@code EntropyInput} and an optional additional data. * * @param additional optional additional string. * @since 1.9 */ protected void engineReseed(byte[] additional); } /** * An interface of a source of entropy input. * * @since 1.9 */ public interface EntropyInput { /** * Fills a byte array with full entropy. * *

This method might block and/or fail. * * @param entropy the byte array with filled entropy. * @throws EntropyNotAvailableException if not enough entropy is available. */ public void getFullEntropy(byte[] entropy); } /** * A RuntimeException thrown when not enough entropy is available. * * @since 1.9 */ public class EntropyNotAvailableException extends RuntimeException { private static final long serialVersionUID = 9L; /** * Creates one * @param msg the message */ public EntropyNotAvailableException(String msg); } /** * This class specifies the configuration of a DRBG. *

* DRBG (deterministic random bits generator) is defined in * * NIST Special Publication 800-90A Revision 1, Recommendation for Random * Number Generation Using Deterministic Random Bit Generators. * A DRBG mechanism should extend this class. *

* The following {@link SecureRandom} methods match to DRBG functions: *

    *
  • {@link SecureRandom#configure} to configure. *
  • A DRBG will be automatically instantiated. *
  • {@link SecureRandom#nextBytes(byte[], byte[])} to generate. *
  • {@link SecureRandom#reseed} to reseed. *
*

* Calling {@link SecureRandom#generateSeed} is equivalent to calling * {@link EntropyInput#getFullEntropy} on its entropy source. *

* A DRBG {@code SecureRandom} can be configured before generating random * bits or reseeding. Otherwise, it will be configured with default values * defined by the DRBG mechanism at the first call of * {@link SecureRandom#nextBytes} or {@link SecureRandom#reseed}. *

* If {@link SecureRandom#setSeed} is the first call on a DRBG, the DRBG * will be configured by default but instantiated with the argument of this * method, therefore will not block. Callers should make sure the argument * must contain enough entropy to ensure the security of this DRBG. *

* A DRBG will be reseeded aotomatically if the seed period is bigger * than the maximum seedlife defined by the DRBG mechanism. *

* A Source of Entropy Input (SEI) can be provided at configure time, * otherwise, a default SEI defined by the DRBG mechanism will be chosen. * * @see SecureRandom#configure * @since 1.9 */ public class DrbgSpec implements AlgorithmParameterSpec { /** * Return the nonce used by this DRBG * * @return the nonce. */ public byte[] getNonce(); /** * Return the personalization string used by this DRBG * * @return the personalization string. */ public byte[] getPersonal(); /** * Return the source of entropy input used by this DRBG * * @return the source of entropy input. */ public EntropyInput getEntropyInput(); /** * Return the algorithm used by this DRBG. * * @return the algorithm. */ public String getAlgorithm(); /** * Returns the strength used by this DRBG. * * @return the strength. */ public int getStrength(); /** * Returns whether a derivation function is used by this DRBG * * @return whether a derivation function is used. */ public boolean isUsedf(); /** * Returns whether prediction resistance is provided by this DRBG. * * @return whether prediction resistance is provided. */ public boolean isPr(); /** * Creates a {@code DrbgSpec}. * * @param algorithm the algorithm used by the DRBG mechanism. For example, * "SHA-256" for HashDRBG, or "AES-256" for CtrDRBG. If null, * the algorithm will be determined by the requested strength. * @param strength the requested strength, ignored if algorithm is null, * -1 means a strength automatically chosen. * @param pr if prediction resistance is requested. * @param usedf if a derivation function will be used. * @param nonce the nonce used. * @param personal an optional personalization string. */ public DrbgSpec(String algorithm, int strength, boolean pr, boolean usedf, byte[] nonce, byte[] personal); } -----API END----- From bradford.wetmore at oracle.com Mon Nov 9 21:54:15 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 9 Nov 2015 13:54:15 -0800 Subject: [9] RFR: 8048356: SecureRandom default provider tests In-Reply-To: <55EA028C.9030607@oracle.com> References: <55EA028C.9030607@oracle.com> Message-ID: <56411607.60401@oracle.com> On 9/4/2015 1:43 PM, Rajan Halade wrote: > Please help with your review of this new test to check default provider > used with SecureRandom. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8048356 > Webrev: http://cr.openjdk.java.net/~rhalade/8048356/webrev.00/ 51: Minor nit, you might reverse the order to match line 47. ... if (!provider.equals("SUN"))... I would suggest also doing a test with the specified provider. SecureRandom instance = SecureRandom.getInstance(algorithm, provider); 70: For readability, you might also reset provider here, or at least provide a comment. Otherwise, looks ok. Brad From rajan.halade at oracle.com Mon Nov 9 22:13:09 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Mon, 9 Nov 2015 14:13:09 -0800 Subject: [9] RFR: 8048356: SecureRandom default provider tests In-Reply-To: <56411607.60401@oracle.com> References: <55EA028C.9030607@oracle.com> <56411607.60401@oracle.com> Message-ID: <56411A75.6060308@oracle.com> Thanks for the comments, Brad. I have addressed those here - http://cr.openjdk.java.net/~rhalade/8048356/webrev.01/ I plan to have this test to check for default provider only so SecureRandom.getInstance(algorithm, provider) API is not good fit here. I think there are other tests which use this API and provide sufficient coverage. Thanks, Rajan On 11/9/15 1:54 PM, Bradford Wetmore wrote: > > > On 9/4/2015 1:43 PM, Rajan Halade wrote: >> Please help with your review of this new test to check default provider >> used with SecureRandom. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8048356 >> Webrev: http://cr.openjdk.java.net/~rhalade/8048356/webrev.00/ > > 51: Minor nit, you might reverse the order to match line 47. > > ... if (!provider.equals("SUN"))... > > I would suggest also doing a test with the specified provider. > > SecureRandom instance = > SecureRandom.getInstance(algorithm, provider); > > 70: For readability, you might also reset provider here, or at least > provide a comment. > > Otherwise, looks ok. > > Brad From bradford.wetmore at oracle.com Mon Nov 9 22:29:03 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 9 Nov 2015 14:29:03 -0800 Subject: [9] RFR: 8048356: SecureRandom default provider tests In-Reply-To: <56411A75.6060308@oracle.com> References: <55EA028C.9030607@oracle.com> <56411607.60401@oracle.com> <56411A75.6060308@oracle.com> Message-ID: <56411E2F.3050105@oracle.com> Ok, thanks. Looks fine. brad On 11/9/2015 2:13 PM, Rajan Halade wrote: > Thanks for the comments, Brad. I have addressed those here - > > http://cr.openjdk.java.net/~rhalade/8048356/webrev.01/ > > I plan to have this test to check for default provider only so > SecureRandom.getInstance(algorithm, provider) API is not good fit here. > I think there are other tests which use this API and provide sufficient > coverage. > > Thanks, > Rajan > On 11/9/15 1:54 PM, Bradford Wetmore wrote: >> >> >> On 9/4/2015 1:43 PM, Rajan Halade wrote: >>> Please help with your review of this new test to check default provider >>> used with SecureRandom. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048356 >>> Webrev: http://cr.openjdk.java.net/~rhalade/8048356/webrev.00/ >> >> 51: Minor nit, you might reverse the order to match line 47. >> >> ... if (!provider.equals("SUN"))... >> >> I would suggest also doing a test with the specified provider. >> >> SecureRandom instance = >> SecureRandom.getInstance(algorithm, provider); >> >> 70: For readability, you might also reset provider here, or at least >> provide a comment. >> >> Otherwise, looks ok. >> >> Brad > From sean.mullan at oracle.com Tue Nov 10 00:18:52 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 9 Nov 2015 19:18:52 -0500 Subject: FYI.... Fwd: Re: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <56411124.9010203@oracle.com> References: <563BA93E.5050602@oracle.com> <563BE2E2.2000804@oracle.com> <564110AE.4040705@oracle.com> <56411124.9010203@oracle.com> Message-ID: <564137EC.4030105@oracle.com> Couple of comments: - SolarisProviderTest is too generic for me. I would call this "PreferredProviderTest". Also, that way it can be enhanced over time if we add preferred providers for other OSes. - In the error messages: s/Get/Got/ s/Return/Returned/ - Similarly, "SecurityPropertyNegativeTest" is too generic, suggest renaming to "PreferredProviderNegativeTest". s/negativeProvier/negativeProvider --Sean >>> The changes look good to me. I assume these tests pass? >>> >>> thanks >>> >>> Tony >>> >>> On 11/05/2015 12:22 AM, Tim Du wrote: >>>> Hi Tony: >>>> >>>> Thanks for reviewing the codes. >>>> Updated them follow your suggestion here: >>>> http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please >>>> help to >>>> review again. >>>> >>>> Regards >>>> Tim >>>> On 11/5/2015 6:19 AM, Anthony Scarpino wrote: >>>>> On 11/03/2015 05:55 PM, Tim Du wrote: >>>>>> Hi All: >>>>>> >>>>>> Please help to review testing Preferred provider configuration >>>>>> feature >>>>>> for JCE . >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8133151 >>>>>> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >>>>>> >>>>>> Thank you very much. >>>>>> >>>>>> Regards >>>>>> Tim >>>>> >>>>> Thanks for the work Tim, your tests cover pretty much everything.. >>>>> I've got a few comments, mostly just add-ons or clarifications. >>>>> >>>>> >>>>> 1) I think the best directory for these tests would be >>>>> test/sun/security/jca/. The jca directory doesn't exist yet, so these >>>>> would be the first tests. My main code change was in >>>>> ProviderList.java which is under the java.base module in >>>>> sun/security/jca/. >>>>> >>>>> >>>>> 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I understand >>>>> the comment and code correctly, I think you want the comment to say: >>>>> /* Test that the setting of the security property after >>>>> Cipher.getInstance() does not influence previously >>>>> loaded instances */ >>>>> >>>>> >>>>> 3) I think it is valuable to have the failures exceptions to print the >>>>> expected provider and the provider that was returned. For example: >>>>> >>>>> Test Failed: Get wrong provider from Solaris sparcv9 platform >>>>> Expected provider: SunJCE, Returned provider: OracleUcrypto. >>>>> >>>>> >>>>> 4) In SolarisProviderTest.java, could you add an algorithm test after >>>>> line 93? I think it is useful to verify an algorithm that is not in >>>>> the preferred list is not being redirected. For example: >>>>> >>>>> MessageDigest md = MessageDigest.getInstance("MD5"); >>>>> if (!md.getProvider().getName().equals("OracleUcrypto")) { >>>>> throw new RuntimeException(...); >>>>> } >>>>> >>>>> >>>>> thanks >>>>> >>>>> Tony >>>>> >>>> >>> >>> >>> >> > From ecki at zusammenkunft.net Tue Nov 10 02:13:09 2015 From: ecki at zusammenkunft.net (Bernd) Date: Tue, 10 Nov 2015 02:13:09 +0000 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> Message-ID: Hello, The JEP does not specifically talk about getInstanceStrong(). Will it be possible to configure one of the new algorithms with the existing security parameter mechanism (and will the default change given that ShA1 has a pretty narrow state space to generate larger crypto keys. Typo in DrbgSpec: A DRBG will be reseeded aotomatically BTW: some places specify "optional" should this be defined as "empty byte array or null"? Gruss Bernd Wang Weijun schrieb am Mo., 9. Nov. 2015 21:04: > Hi All > > The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at > > https://bugs.openjdk.java.net/browse/JDK-8051408 > > Some notes before the text: > > 1. Mainly, new methods are added to SecureRandom to match DRBG functions: > > - configure: choosing the algorithms and parameters > - reseed: reseed using configured entropy. This is not same as existing > setSeed() which reseeds using a caller-provided seed > - nextBytes: random bits generation, with support for additional input > > Like the existing ones, DRBGs will still be initiated automatically when > nextBytes() is called. > > SecureRandomSpi is also updated with related engine methods. > > 2. The new APIs will apply to all existing SecureRandom implementations, > although some is just a no-op. We believe the concepts apply to all. > > 3. An EntropyInput interface is introduced to model source of entropy > input. We will provide some internal implementations so these DRBGs work > out of box. However, we won't expose any implementation that an application > can use directly. If you have a special entropy source, just implement the > interface yourself. Also note the interface is super simple now. New > methods (or getInstance() methods) might be added in the future. > > 4. Three new SecureRandom algorithms are provided by the SUN provider - > HashDRBG, HmacDRBH, and CTRDRBG. > > > Here is an example: > > SecureRandom sr = SecureRandom.getInstance("HashDRBG"); > hd.configure(new DrbgSpec("SHA-512", -1, true, false, > nonce, person), new MyEntropyInput()); > hg.nextBytes(output, additional); > hg.reseed(additional2); > > > Any suggestion is welcome. > > Thanks > Max > > -----API START----- > package java.security; > > > /** > * > * .... > * > *

Some SecureRandom implementations can be further configured by > * calling {@link #configure}. For example, a DRBG mechanism can be > configured > * by a {@link DrbgSpec} object. > * > * .... > * > *

A SecureRandom can be reseeded by itself by calling {@link #reseed}. > * A caller can also reseed it a user-provided seed by calling > * {@link #setSeed(byte[])}. > * > * .... > * > *

Except for one created by {@link #SecureRandom(byte[])}, > * a newly created SecureRandom object is usually not seeded. To seed the > * returned object, call the {@code setSeed} method. > * If {@code setSeed} is not called, the first call to > * {@code nextBytes} or {@code reseed} will force the SecureRandom > * object to seed itself. This self-seeding will not occur > * if {@code setSeed} was previously called. > * > *

> * Note: Depending on the implementation, the {@code generateSeed}, > * {@code reseed} and {@code nextBytes} methods may block as entropy is > being > * gathered, for example, if they need to read from /dev/random on various > * Unix-like operating systems. > */ > public class SecureRandom { > > .... > > /** > * Configure this {@code SecureRandom} with an {@link > AlgorithmParameterSpec} > * object and a source of entropy input. > * > * @implNote The actual type of {@code spec} must match the algorithm > of this > * {@code SecureRandom} object. Fo example, a DRBG must be configured > by > * a {@link DrbgSpec}. Otherwise, an {@link IllegalArgumentException} > * should be thrown. > *

> * If {@code ei} is null, a default EntropyInput will be chosen. If not > * null, the caller needs to make sure the EntropyInput matches the > * {@code SecureRandom} to be configured with enough security strength, > * live entropy, and other features. > * > * @param spec the {@link AlgorithmParameterSpec} object. Null if not > needed. > * @param ei the source of entropy input. Null if not user-chosen. > * @throws IllegalArgumentException if {@code spec} is not recognized > by > * this {@code SecureRandom} object. > * @since 1.9 > */ > public void configure(AlgorithmParameterSpec spec, EntropyInput ei); > > /** > * Generates a user-specified number of random bytes with an optional > * additional input argument. > * > * @param bytes the array to be filled in with random bytes. > * @param additionalInput an optional additional input argument. > * @since 1.9 > */ > public void nextBytes(byte[] bytes, byte[] additionalInput); > > /** > * Reseeds this {@code SecureRandom} with entropy read from its > * {@code EntropyInput} and an optional additional data. > *

> * Note that the entropy is obtained from {@code EntropyInput}. While > * {@code additional} may contain entropy but its main usage is to > * provide diversity. > * > * @param additionalInput an optional additional input argument. > * @since 1.9 > */ > public void reseed(byte[] additionalInput); > > .... > } > > public abstract class SecureRandomSpi { > > /** > * Configure this random object. > * > * @param spec the {@link AlgorithmParameterSpec} object. Null if not > needed. > * @param ei the source of entropy input. Null if not user-chosen. > * @throws IllegalArgumentException if this random object does not need > * to be configured or it does not recongize {@code spec}. > * @since 1.9 > */ > protected void engineConfigure(AlgorithmParameterSpec spec, > EntropyInput ei); > > /** > * Generates random bits. > * > * @param bytes output. > * @param additionalInput optional additional input. > * @since 1.9 > */ > public void engineGenerate(byte[] bytes, byte[] additionalInput); > > /** > * Reseeds this random object with entropy read from its > * {@code EntropyInput} and an optional additional data. > * > * @param additional optional additional string. > * @since 1.9 > */ > protected void engineReseed(byte[] additional); > } > > /** > * An interface of a source of entropy input. > * > * @since 1.9 > */ > public interface EntropyInput { > > /** > * Fills a byte array with full entropy. > * > *

This method might block and/or fail. > * > * @param entropy the byte array with filled entropy. > * @throws EntropyNotAvailableException if not enough entropy is > available. > */ > public void getFullEntropy(byte[] entropy); > } > > > /** > * A RuntimeException thrown when not enough entropy is available. > * > * @since 1.9 > */ > public class EntropyNotAvailableException extends RuntimeException { > > private static final long serialVersionUID = 9L; > > /** > * Creates one > * @param msg the message > */ > public EntropyNotAvailableException(String msg); > } > > > /** > * This class specifies the configuration of a DRBG. > *

> * DRBG (deterministic random bits generator) is defined in > * > * NIST Special Publication 800-90A Revision 1, Recommendation for Random > * Number Generation Using Deterministic Random Bit Generators. > * A DRBG mechanism should extend this class. > *

> * The following {@link SecureRandom} methods match to DRBG functions: > *

    > *
  • {@link SecureRandom#configure} to configure. > *
  • A DRBG will be automatically instantiated. > *
  • {@link SecureRandom#nextBytes(byte[], byte[])} to generate. > *
  • {@link SecureRandom#reseed} to reseed. > *
> *

> * Calling {@link SecureRandom#generateSeed} is equivalent to calling > * {@link EntropyInput#getFullEntropy} on its entropy source. > *

> * A DRBG {@code SecureRandom} can be configured before generating random > * bits or reseeding. Otherwise, it will be configured with default values > * defined by the DRBG mechanism at the first call of > * {@link SecureRandom#nextBytes} or {@link SecureRandom#reseed}. > *

> * If {@link SecureRandom#setSeed} is the first call on a DRBG, the DRBG > * will be configured by default but instantiated with the argument of this > * method, therefore will not block. Callers should make sure the argument > * must contain enough entropy to ensure the security of this DRBG. > *

> * A DRBG will be reseeded aotomatically if the seed period is bigger > * than the maximum seedlife defined by the DRBG mechanism. > *

> * A Source of Entropy Input (SEI) can be provided at configure time, > * otherwise, a default SEI defined by the DRBG mechanism will be chosen. > * > * @see SecureRandom#configure > * @since 1.9 > */ > public class DrbgSpec implements AlgorithmParameterSpec { > > /** > * Return the nonce used by this DRBG > * > * @return the nonce. > */ > public byte[] getNonce(); > > /** > * Return the personalization string used by this DRBG > * > * @return the personalization string. > */ > public byte[] getPersonal(); > > /** > * Return the source of entropy input used by this DRBG > * > * @return the source of entropy input. > */ > public EntropyInput getEntropyInput(); > > /** > * Return the algorithm used by this DRBG. > * > * @return the algorithm. > */ > public String getAlgorithm(); > > /** > * Returns the strength used by this DRBG. > * > * @return the strength. > */ > public int getStrength(); > > /** > * Returns whether a derivation function is used by this DRBG > * > * @return whether a derivation function is used. > */ > public boolean isUsedf(); > > /** > * Returns whether prediction resistance is provided by this DRBG. > * > * @return whether prediction resistance is provided. > */ > public boolean isPr(); > > /** > * Creates a {@code DrbgSpec}. > * > * @param algorithm the algorithm used by the DRBG mechanism. For > example, > * "SHA-256" for HashDRBG, or "AES-256" for CtrDRBG. If null, > * the algorithm will be determined by the requested strength. > * @param strength the requested strength, ignored if algorithm is > null, > * -1 means a strength automatically chosen. > * @param pr if prediction resistance is requested. > * @param usedf if a derivation function will be used. > * @param nonce the nonce used. > * @param personal an optional personalization string. > */ > public DrbgSpec(String algorithm, int strength, boolean pr, > boolean usedf, byte[] nonce, byte[] personal); > } > > -----API END----- -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 10 02:22:36 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 10 Nov 2015 10:22:36 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> Message-ID: <09FA899B-18BA-4CA4-BA21-A93474054A84@oracle.com> > On Nov 10, 2015, at 10:13 AM, Bernd wrote: > > Hello, > > The JEP does not specifically talk about getInstanceStrong(). Will it be possible to configure one of the new algorithms with the existing security parameter mechanism (and will the default change given that ShA1 has a pretty narrow state space to generate larger crypto keys. The JEP includes this line: Open Issues ? Choose the new default SecureRandom provider on all platforms. When I say default, it should cover both getInstance() and getInstanceStrong(). Also, this is just my initial design and my team has not reviewed it yet. As for getInstanceStrong(), it's a SecureRandom static method that does not take any parameter. So it's not possible to use it to choose between a SHA-1 based HashDRBG and a SHA-512-based one. Currently JDK still prefers NativePRNG to SHA1PRNG, and this JEP might not change it. What I can be sure if that if you choose getInstance("HashDRBG") without configure I will try my best to choose an adequate strength. Is that OK? > > Typo in DrbgSpec: A DRBG will be reseeded automatically Updated in my local code. > BTW: some places specify "optional" should this be defined as "empty byte array or null"? I will be more precise on these in @param later. I will also add words like "if not null, will be cloned". Thanks Max > > Gruss > Bernd > > > Wang Weijun schrieb am Mo., 9. Nov. 2015 21:04: > Hi All > > The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at > > https://bugs.openjdk.java.net/browse/JDK-8051408 > > Some notes before the text: > > 1. Mainly, new methods are added to SecureRandom to match DRBG functions: > > - configure: choosing the algorithms and parameters > - reseed: reseed using configured entropy. This is not same as existing setSeed() which reseeds using a caller-provided seed > - nextBytes: random bits generation, with support for additional input > > Like the existing ones, DRBGs will still be initiated automatically when nextBytes() is called. > > SecureRandomSpi is also updated with related engine methods. > > 2. The new APIs will apply to all existing SecureRandom implementations, although some is just a no-op. We believe the concepts apply to all. > > 3. An EntropyInput interface is introduced to model source of entropy input. We will provide some internal implementations so these DRBGs work out of box. However, we won't expose any implementation that an application can use directly. If you have a special entropy source, just implement the interface yourself. Also note the interface is super simple now. New methods (or getInstance() methods) might be added in the future. > > 4. Three new SecureRandom algorithms are provided by the SUN provider - HashDRBG, HmacDRBH, and CTRDRBG. > > > Here is an example: > > SecureRandom sr = SecureRandom.getInstance("HashDRBG"); > hd.configure(new DrbgSpec("SHA-512", -1, true, false, > nonce, person), new MyEntropyInput()); > hg.nextBytes(output, additional); > hg.reseed(additional2); > > > Any suggestion is welcome. > > Thanks > Max > > -----API START----- > package java.security; > > > /** > * > * .... > * > *

Some SecureRandom implementations can be further configured by > * calling {@link #configure}. For example, a DRBG mechanism can be configured > * by a {@link DrbgSpec} object. > * > * .... > * > *

A SecureRandom can be reseeded by itself by calling {@link #reseed}. > * A caller can also reseed it a user-provided seed by calling > * {@link #setSeed(byte[])}. > * > * .... > * > *

Except for one created by {@link #SecureRandom(byte[])}, > * a newly created SecureRandom object is usually not seeded. To seed the > * returned object, call the {@code setSeed} method. > * If {@code setSeed} is not called, the first call to > * {@code nextBytes} or {@code reseed} will force the SecureRandom > * object to seed itself. This self-seeding will not occur > * if {@code setSeed} was previously called. > * > *

> * Note: Depending on the implementation, the {@code generateSeed}, > * {@code reseed} and {@code nextBytes} methods may block as entropy is being > * gathered, for example, if they need to read from /dev/random on various > * Unix-like operating systems. > */ > public class SecureRandom { > > .... > > /** > * Configure this {@code SecureRandom} with an {@link AlgorithmParameterSpec} > * object and a source of entropy input. > * > * @implNote The actual type of {@code spec} must match the algorithm of this > * {@code SecureRandom} object. Fo example, a DRBG must be configured by > * a {@link DrbgSpec}. Otherwise, an {@link IllegalArgumentException} > * should be thrown. > *

> * If {@code ei} is null, a default EntropyInput will be chosen. If not > * null, the caller needs to make sure the EntropyInput matches the > * {@code SecureRandom} to be configured with enough security strength, > * live entropy, and other features. > * > * @param spec the {@link AlgorithmParameterSpec} object. Null if not needed. > * @param ei the source of entropy input. Null if not user-chosen. > * @throws IllegalArgumentException if {@code spec} is not recognized by > * this {@code SecureRandom} object. > * @since 1.9 > */ > public void configure(AlgorithmParameterSpec spec, EntropyInput ei); > > /** > * Generates a user-specified number of random bytes with an optional > * additional input argument. > * > * @param bytes the array to be filled in with random bytes. > * @param additionalInput an optional additional input argument. > * @since 1.9 > */ > public void nextBytes(byte[] bytes, byte[] additionalInput); > > /** > * Reseeds this {@code SecureRandom} with entropy read from its > * {@code EntropyInput} and an optional additional data. > *

> * Note that the entropy is obtained from {@code EntropyInput}. While > * {@code additional} may contain entropy but its main usage is to > * provide diversity. > * > * @param additionalInput an optional additional input argument. > * @since 1.9 > */ > public void reseed(byte[] additionalInput); > > .... > } > > public abstract class SecureRandomSpi { > > /** > * Configure this random object. > * > * @param spec the {@link AlgorithmParameterSpec} object. Null if not needed. > * @param ei the source of entropy input. Null if not user-chosen. > * @throws IllegalArgumentException if this random object does not need > * to be configured or it does not recongize {@code spec}. > * @since 1.9 > */ > protected void engineConfigure(AlgorithmParameterSpec spec, EntropyInput ei); > > /** > * Generates random bits. > * > * @param bytes output. > * @param additionalInput optional additional input. > * @since 1.9 > */ > public void engineGenerate(byte[] bytes, byte[] additionalInput); > > /** > * Reseeds this random object with entropy read from its > * {@code EntropyInput} and an optional additional data. > * > * @param additional optional additional string. > * @since 1.9 > */ > protected void engineReseed(byte[] additional); > } > > /** > * An interface of a source of entropy input. > * > * @since 1.9 > */ > public interface EntropyInput { > > /** > * Fills a byte array with full entropy. > * > *

This method might block and/or fail. > * > * @param entropy the byte array with filled entropy. > * @throws EntropyNotAvailableException if not enough entropy is available. > */ > public void getFullEntropy(byte[] entropy); > } > > > /** > * A RuntimeException thrown when not enough entropy is available. > * > * @since 1.9 > */ > public class EntropyNotAvailableException extends RuntimeException { > > private static final long serialVersionUID = 9L; > > /** > * Creates one > * @param msg the message > */ > public EntropyNotAvailableException(String msg); > } > > > /** > * This class specifies the configuration of a DRBG. > *

> * DRBG (deterministic random bits generator) is defined in > * > * NIST Special Publication 800-90A Revision 1, Recommendation for Random > * Number Generation Using Deterministic Random Bit Generators. > * A DRBG mechanism should extend this class. > *

> * The following {@link SecureRandom} methods match to DRBG functions: > *

    > *
  • {@link SecureRandom#configure} to configure. > *
  • A DRBG will be automatically instantiated. > *
  • {@link SecureRandom#nextBytes(byte[], byte[])} to generate. > *
  • {@link SecureRandom#reseed} to reseed. > *
> *

> * Calling {@link SecureRandom#generateSeed} is equivalent to calling > * {@link EntropyInput#getFullEntropy} on its entropy source. > *

> * A DRBG {@code SecureRandom} can be configured before generating random > * bits or reseeding. Otherwise, it will be configured with default values > * defined by the DRBG mechanism at the first call of > * {@link SecureRandom#nextBytes} or {@link SecureRandom#reseed}. > *

> * If {@link SecureRandom#setSeed} is the first call on a DRBG, the DRBG > * will be configured by default but instantiated with the argument of this > * method, therefore will not block. Callers should make sure the argument > * must contain enough entropy to ensure the security of this DRBG. > *

> * A DRBG will be reseeded aotomatically if the seed period is bigger > * than the maximum seedlife defined by the DRBG mechanism. > *

> * A Source of Entropy Input (SEI) can be provided at configure time, > * otherwise, a default SEI defined by the DRBG mechanism will be chosen. > * > * @see SecureRandom#configure > * @since 1.9 > */ > public class DrbgSpec implements AlgorithmParameterSpec { > > /** > * Return the nonce used by this DRBG > * > * @return the nonce. > */ > public byte[] getNonce(); > > /** > * Return the personalization string used by this DRBG > * > * @return the personalization string. > */ > public byte[] getPersonal(); > > /** > * Return the source of entropy input used by this DRBG > * > * @return the source of entropy input. > */ > public EntropyInput getEntropyInput(); > > /** > * Return the algorithm used by this DRBG. > * > * @return the algorithm. > */ > public String getAlgorithm(); > > /** > * Returns the strength used by this DRBG. > * > * @return the strength. > */ > public int getStrength(); > > /** > * Returns whether a derivation function is used by this DRBG > * > * @return whether a derivation function is used. > */ > public boolean isUsedf(); > > /** > * Returns whether prediction resistance is provided by this DRBG. > * > * @return whether prediction resistance is provided. > */ > public boolean isPr(); > > /** > * Creates a {@code DrbgSpec}. > * > * @param algorithm the algorithm used by the DRBG mechanism. For example, > * "SHA-256" for HashDRBG, or "AES-256" for CtrDRBG. If null, > * the algorithm will be determined by the requested strength. > * @param strength the requested strength, ignored if algorithm is null, > * -1 means a strength automatically chosen. > * @param pr if prediction resistance is requested. > * @param usedf if a derivation function will be used. > * @param nonce the nonce used. > * @param personal an optional personalization string. > */ > public DrbgSpec(String algorithm, int strength, boolean pr, > boolean usedf, byte[] nonce, byte[] personal); > } > > -----API END----- From tiantian.du at oracle.com Tue Nov 10 08:36:32 2015 From: tiantian.du at oracle.com (Tim Du) Date: Tue, 10 Nov 2015 16:36:32 +0800 Subject: FYI.... Fwd: Re: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <564137EC.4030105@oracle.com> References: <563BA93E.5050602@oracle.com> <563BE2E2.2000804@oracle.com> <564110AE.4040705@oracle.com> <56411124.9010203@oracle.com> <564137EC.4030105@oracle.com> Message-ID: <5641AC90.1020304@oracle.com> Hi Sean: Thanks for reviewing the codes. Updated them follow your comments, see http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.02/ ,please help to review them again. Regards Tim On 11/10/2015 8:18 AM, Sean Mullan wrote: > Couple of comments: > > - SolarisProviderTest is too generic for me. I would call this > "PreferredProviderTest". Also, that way it can be enhanced over time > if we add preferred providers for other OSes. > > - In the error messages: > > s/Get/Got/ > s/Return/Returned/ > > - Similarly, "SecurityPropertyNegativeTest" is too generic, suggest > renaming to "PreferredProviderNegativeTest". > > s/negativeProvier/negativeProvider > > --Sean > > >>>> The changes look good to me. I assume these tests pass? >>>> >>>> thanks >>>> >>>> Tony >>>> >>>> On 11/05/2015 12:22 AM, Tim Du wrote: >>>>> Hi Tony: >>>>> >>>>> Thanks for reviewing the codes. >>>>> Updated them follow your suggestion here: >>>>> http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please >>>>> help to >>>>> review again. >>>>> >>>>> Regards >>>>> Tim >>>>> On 11/5/2015 6:19 AM, Anthony Scarpino wrote: >>>>>> On 11/03/2015 05:55 PM, Tim Du wrote: >>>>>>> Hi All: >>>>>>> >>>>>>> Please help to review testing Preferred provider configuration >>>>>>> feature >>>>>>> for JCE . >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8133151 >>>>>>> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>>> Regards >>>>>>> Tim >>>>>> >>>>>> Thanks for the work Tim, your tests cover pretty much everything.. >>>>>> I've got a few comments, mostly just add-ons or clarifications. >>>>>> >>>>>> >>>>>> 1) I think the best directory for these tests would be >>>>>> test/sun/security/jca/. The jca directory doesn't exist yet, so >>>>>> these >>>>>> would be the first tests. My main code change was in >>>>>> ProviderList.java which is under the java.base module in >>>>>> sun/security/jca/. >>>>>> >>>>>> >>>>>> 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I >>>>>> understand >>>>>> the comment and code correctly, I think you want the comment to say: >>>>>> /* Test that the setting of the security property after >>>>>> Cipher.getInstance() does not influence previously >>>>>> loaded instances */ >>>>>> >>>>>> >>>>>> 3) I think it is valuable to have the failures exceptions to >>>>>> print the >>>>>> expected provider and the provider that was returned. For example: >>>>>> >>>>>> Test Failed: Get wrong provider from Solaris sparcv9 platform >>>>>> Expected provider: SunJCE, Returned provider: OracleUcrypto. >>>>>> >>>>>> >>>>>> 4) In SolarisProviderTest.java, could you add an algorithm test >>>>>> after >>>>>> line 93? I think it is useful to verify an algorithm that is not in >>>>>> the preferred list is not being redirected. For example: >>>>>> >>>>>> MessageDigest md = MessageDigest.getInstance("MD5"); >>>>>> if (!md.getProvider().getName().equals("OracleUcrypto")) { >>>>>> throw new RuntimeException(...); >>>>>> } >>>>>> >>>>>> >>>>>> thanks >>>>>> >>>>>> Tony >>>>>> >>>>> >>>> >>>> >>>> >>> >> From sean.mullan at oracle.com Tue Nov 10 14:57:49 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Nov 2015 09:57:49 -0500 Subject: RFR: [JDK-8072463] Remove requirement that AKID and SKID have to match when building certificate chain Message-ID: <564205ED.6030405@oracle.com> Please review this fix for a regression that removes the requirement that a certificate's Authority Key Identifier must match the issuing certificate's Subject Key Identifier when building a certificate chain. The certificate chain validation algorithm in RFC 5280 does not require that the AKID/SKID match. I have moved the AKID/SKID match into the sorting criteria for building paths. If they match, it will try that certificate first, but it will also fallback and search other paths. A new test has been added to the closed area since it depends on certificates contributed by the submitter. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072463/webrev.00/ --Sean From sean.mullan at oracle.com Tue Nov 10 20:20:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 10 Nov 2015 15:20:35 -0500 Subject: FYI.... Fwd: Re: [9] RFR:JDK-8076359:Test Task: Develop new tests for Leverage CPU Instructions for GHASH and RSA In-Reply-To: <5641AC90.1020304@oracle.com> References: <563BA93E.5050602@oracle.com> <563BE2E2.2000804@oracle.com> <564110AE.4040705@oracle.com> <56411124.9010203@oracle.com> <564137EC.4030105@oracle.com> <5641AC90.1020304@oracle.com> Message-ID: <56425193.1090907@oracle.com> Looks good. Thanks, Sean On 11/10/2015 03:36 AM, Tim Du wrote: > Hi Sean: > > Thanks for reviewing the codes. Updated them follow your comments, see > http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.02/ ,please help to > review them again. > > Regards > Tim > On 11/10/2015 8:18 AM, Sean Mullan wrote: >> Couple of comments: >> >> - SolarisProviderTest is too generic for me. I would call this >> "PreferredProviderTest". Also, that way it can be enhanced over time >> if we add preferred providers for other OSes. >> >> - In the error messages: >> >> s/Get/Got/ >> s/Return/Returned/ >> >> - Similarly, "SecurityPropertyNegativeTest" is too generic, suggest >> renaming to "PreferredProviderNegativeTest". >> >> s/negativeProvier/negativeProvider >> >> --Sean >> >> >>>>> The changes look good to me. I assume these tests pass? >>>>> >>>>> thanks >>>>> >>>>> Tony >>>>> >>>>> On 11/05/2015 12:22 AM, Tim Du wrote: >>>>>> Hi Tony: >>>>>> >>>>>> Thanks for reviewing the codes. >>>>>> Updated them follow your suggestion here: >>>>>> http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.01/ ,please >>>>>> help to >>>>>> review again. >>>>>> >>>>>> Regards >>>>>> Tim >>>>>> On 11/5/2015 6:19 AM, Anthony Scarpino wrote: >>>>>>> On 11/03/2015 05:55 PM, Tim Du wrote: >>>>>>>> Hi All: >>>>>>>> >>>>>>>> Please help to review testing Preferred provider configuration >>>>>>>> feature >>>>>>>> for JCE . >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8076359 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8133151 >>>>>>>> webrev: http://cr.openjdk.java.net/~fyuan/tim/8076359/webrev.00/ >>>>>>>> >>>>>>>> Thank you very much. >>>>>>>> >>>>>>>> Regards >>>>>>>> Tim >>>>>>> >>>>>>> Thanks for the work Tim, your tests cover pretty much everything.. >>>>>>> I've got a few comments, mostly just add-ons or clarifications. >>>>>>> >>>>>>> >>>>>>> 1) I think the best directory for these tests would be >>>>>>> test/sun/security/jca/. The jca directory doesn't exist yet, so >>>>>>> these >>>>>>> would be the first tests. My main code change was in >>>>>>> ProviderList.java which is under the java.base module in >>>>>>> sun/security/jca/. >>>>>>> >>>>>>> >>>>>>> 2) In SecurityPropertyNegativeTest.java:afterJCESet(), if I >>>>>>> understand >>>>>>> the comment and code correctly, I think you want the comment to say: >>>>>>> /* Test that the setting of the security property after >>>>>>> Cipher.getInstance() does not influence previously >>>>>>> loaded instances */ >>>>>>> >>>>>>> >>>>>>> 3) I think it is valuable to have the failures exceptions to >>>>>>> print the >>>>>>> expected provider and the provider that was returned. For example: >>>>>>> >>>>>>> Test Failed: Get wrong provider from Solaris sparcv9 platform >>>>>>> Expected provider: SunJCE, Returned provider: OracleUcrypto. >>>>>>> >>>>>>> >>>>>>> 4) In SolarisProviderTest.java, could you add an algorithm test >>>>>>> after >>>>>>> line 93? I think it is useful to verify an algorithm that is not in >>>>>>> the preferred list is not being redirected. For example: >>>>>>> >>>>>>> MessageDigest md = MessageDigest.getInstance("MD5"); >>>>>>> if (!md.getProvider().getName().equals("OracleUcrypto")) { >>>>>>> throw new RuntimeException(...); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> > From christoph.langer at sap.com Tue Nov 10 21:12:47 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 Nov 2015 21:12:47 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> Hi folks, is there any feedback/review for this change? Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. November 2015 12:11 To: 'Michael StJohns' Cc: security-dev at openjdk.java.net Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi Mike, eventually I?ve made a new webrev implementing your suggestion for a simpler patch: http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? Thanks Christoph From: Michael StJohns [mailto:mstjohns at comcast.net] Sent: Donnerstag, 15. Oktober 2015 02:09 To: Langer, Christoph > Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here: http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Tue Nov 10 22:39:48 2015 From: mstjohns at comcast.net (Mike StJohns) Date: Tue, 10 Nov 2015 17:39:48 -0500 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> Message-ID: <56427234.3070502@comcast.net> On 11/10/2015 4:12 PM, Langer, Christoph wrote: > > Hi folks, > > is there any feedback/review for this change? > I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. Mike > Thanks > > Christoph > > *From:*Langer, Christoph > *Sent:* Mittwoch, 4. November 2015 12:11 > *To:* 'Michael StJohns' > *Cc:* security-dev at openjdk.java.net > *Subject:* RE: RFR 8139436: sun.security.mscapi.KeyStore might load > incomplete data > > Hi Mike, > > eventually I?ve made a new webrev implementing your suggestion for a > simpler patch: > > http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ > > > @All: Is that a valid fix for this issue? Would anyone mind to > review/sponsor this? > > Thanks > > Christoph > > *From:*Michael StJohns [mailto:mstjohns at comcast.net] > *Sent:* Donnerstag, 15. Oktober 2015 02:09 > *To:* Langer, Christoph > > *Cc:* security-dev at openjdk.java.net > *Subject:* Re: RFR 8139436: sun.security.mscapi.KeyStore might load > incomplete data > > Sorry for the top post, I'm wring this on an iPad on a plane. > > It's perfectly acceptable for a provider to prefer its version of > stuff over even something early in the provider list. Usually, that > has more to do with key material ( for example pkcs11 instantiations), > but there's no reason why it shouldn't apply to certificates. > > Mike > > > Sent from my iPad > > > On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: > > Hi Mike, > > thanks for your comments on this. > > I agree that the change is quite critical and my approach might > not be good. However, as for your suggestion to specify the sun > provider for the certificate factory, I?d say this is not quite > right, too. Because, if you have loaded a different provider on > top of the providers list, you?ll intend to use its facilities by > default. Maybe the idea would be to use the sun provider as > fallback in case of an exception? > > The other suggestion to check for certChain.length in > KeyStore.getCertificate and return null would be an improvement > compared to throwing an ArrayIndexOutOfBoundsException ? however, > it would still be difficult to find the root cause why a > certificate could not be loaded. > > What do you think? > > @all: Are there other opinions? > > Thanks and best regards > > Christoph > > *From:*security-dev [mailto:security-dev-bounces at openjdk.java.net] > *On Behalf Of *Mike StJohns > *Sent:* Mittwoch, 14. Oktober 2015 02:17 > *To:* security-dev at openjdk.java.net > > *Subject:* Re: RFR 8139436: sun.security.mscapi.KeyStore might > load incomplete data > > Hi - > > I took a look and this probably isn't the correct way to fix this. > > A simpler change might be to specify the sun provider when > requesting the certificate factory. I hesitate to say that > definitively as modularization guidance may restrict that approach? > > The belt and suspenders approach is to catch the bad certificate > exception and return null. That appears to be the correct > contract for KeyStore.getCertificate(String alias). (e.g. "if > (certChain.length == 0) return null;") > > Mike > > > On 10/12/2015 5:04 PM, Langer, Christoph wrote: > > Hi, > > please review a change proposal regarding an issue in the > Microsoft Security API (mscapi). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ > > > I stumbled over the issue when using an old IAIK security > provider. It would throw > java.security.cert.CertificateException upon parsing ECC based > certificates when generating Certificate objects. The way it > is right now, such exceptions are silently caught and the > Windows Keystore is created with incomplete data. Upon > accessing such ECC certificates from the Keystore object, e.g. > when iterating over it, you?ll get exceptions like: > > Exception in thread "main" > java.lang.ArrayIndexOutOfBoundsException: 0 > > at > sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) > > at > sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) > > at > java.security.KeyStore.getCertificate(KeyStore.java:1095) > > At that point it is not obvious what the real root cause for > that is. > > With my change, loading of the keystore would already throw > like this: > > java.io.IOException: java.security.KeyStoreException: > Exception occurred generating certificate object for alias > DigiCert Assured ID Root G3 > > at > sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) > > at > sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) > > at java.security.KeyStore.load(KeyStore.java:1459) > > at > WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) > > Caused by: java.security.KeyStoreException: Exception occurred > generating certificate object for alias DigiCert Assured ID > Root G3 > > at > sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) > > at > sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) > > ... 3 more > > Caused by: java.security.cert.CertificateException: Error > parsing certificates! iaik.asn1.DerInputException: Next ASN.1 > object is no OBJECT IDENTIFIER! > > at > iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) > > at > java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) > > at > sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) > > ... 5 more > > This is more obvious when it comes to analyzing such an issue. > > Also, I added a property > ?sun.security.mscapi.ignoreFailingCertificates? which, when > set to true, will cause skipping of certificates that failed > with Exception. That might be a nice workaround option if one > is not particularly interested in a failing certificate. > > You can reproduce all this with the test coding in the OpenJDK > Bug, the IAIK provider 3.15 which is downloadable here: > http://jcewww.iaik.tu-graz.ac.at/sic/Download > (educational/research version, needs registration) and ECC > certificates in the Windows Root certificate store. > > Would you think this change is reasonable and worthwile? > > Thanks & Best regards > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Wed Nov 11 07:46:23 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 11 Nov 2015 07:46:23 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <56427234.3070502@comcast.net> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> Message-ID: <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module depend on the java.base module. And that?s OK. I can sponsor this changeset. > On 10 Nov 2015, at 22:39, Mike StJohns wrote: > > On 11/10/2015 4:12 PM, Langer, Christoph wrote: >> Hi folks, >> >> is there any feedback/review for this change? > > I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. > > Mike > >> >> Thanks >> Christoph >> >> From: Langer, Christoph >> Sent: Mittwoch, 4. November 2015 12:11 >> To: 'Michael StJohns' >> Cc: security-dev at openjdk.java.net >> Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data >> >> Hi Mike, >> >> eventually I?ve made a new webrev implementing your suggestion for a simpler patch: >> >> http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ >> >> @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? >> >> Thanks >> Christoph >> >> >> From: Michael StJohns [mailto:mstjohns at comcast.net ] >> Sent: Donnerstag, 15. Oktober 2015 02:09 >> To: Langer, Christoph < christoph.langer at sap.com > >> Cc: security-dev at openjdk.java.net >> Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data >> >> Sorry for the top post, I'm wring this on an iPad on a plane. >> >> >> It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. >> >> Mike >> >> >> >> Sent from my iPad >> >> On Oct 14, 2015, at 18:35, Langer, Christoph < christoph.langer at sap.com > wrote: >> >> Hi Mike, >> >> thanks for your comments on this. >> >> I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? >> >> The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. >> >> What do you think? >> >> @all: Are there other opinions? >> >> Thanks and best regards >> Christoph >> >> From: security-dev [ mailto:security-dev-bounces at openjdk.java.net ] On Behalf Of Mike StJohns >> Sent: Mittwoch, 14. Oktober 2015 02:17 >> To: security-dev at openjdk.java.net >> Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data >> >> Hi - >> >> I took a look and this probably isn't the correct way to fix this. >> >> A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? >> >> The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") >> >> Mike >> >> >> On 10/12/2015 5:04 PM, Langer, Christoph wrote: >> Hi, >> >> please review a change proposal regarding an issue in the Microsoft Security API (mscapi). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ >> >> I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: >> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 >> at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) >> at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) >> at java.security.KeyStore.getCertificate(KeyStore.java:1095) >> At that point it is not obvious what the real root cause for that is. >> >> With my change, loading of the keystore would already throw like this: >> java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 >> at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) >> at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) >> at java.security.KeyStore.load(KeyStore.java:1459) >> at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) >> Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 >> at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) >> at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) >> ... 3 more >> Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! >> at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) >> at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) >> at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) >> ... 5 more >> This is more obvious when it comes to analyzing such an issue. >> >> Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. >> >> You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. >> >> Would you think this change is reasonable and worthwile? >> >> Thanks & Best regards >> Christoph >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Nov 11 07:50:38 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Nov 2015 07:50:38 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F4F5A0@DEWDFEMB12B.global.corp.sap> Hi Vincent, thanks for your comments and sponsoring this. I just saw that I introduced an unnecessary space ? will update my webrev with the final version later today. Best regards Christoph From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Mittwoch, 11. November 2015 08:46 To: Mike StJohns ; Langer, Christoph Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module depend on the java.base module. And that?s OK. I can sponsor this changeset. On 10 Nov 2015, at 22:39, Mike StJohns > wrote: On 11/10/2015 4:12 PM, Langer, Christoph wrote: Hi folks, is there any feedback/review for this change? I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. Mike Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. November 2015 12:11 To: 'Michael StJohns' Cc: security-dev at openjdk.java.net Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi Mike, eventually I?ve made a new webrev implementing your suggestion for a simpler patch: http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? Thanks Christoph From: Michael StJohns [mailto:mstjohns at comcast.net] Sent: Donnerstag, 15. Oktober 2015 02:09 To: Langer, Christoph > Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Nov 11 12:08:01 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 11 Nov 2015 12:08:01 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> Hi Vincent, so this is the final version which should be pushed: http://cr.openjdk.java.net/~clanger/webrevs/8139436.2/ I removed an unnecessary blank in a method call and updated the copyright information. I also ran another build and verified with my test case. Thanks in advance for taking care. Christoph From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Mittwoch, 11. November 2015 08:46 To: Mike StJohns ; Langer, Christoph Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module depend on the java.base module. And that?s OK. I can sponsor this changeset. On 10 Nov 2015, at 22:39, Mike StJohns > wrote: On 11/10/2015 4:12 PM, Langer, Christoph wrote: Hi folks, is there any feedback/review for this change? I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. Mike Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. November 2015 12:11 To: 'Michael StJohns' Cc: security-dev at openjdk.java.net Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi Mike, eventually I?ve made a new webrev implementing your suggestion for a simpler patch: http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? Thanks Christoph From: Michael StJohns [mailto:mstjohns at comcast.net] Sent: Donnerstag, 15. Oktober 2015 02:09 To: Langer, Christoph > Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.x.ryan at oracle.com Wed Nov 11 12:10:23 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 11 Nov 2015 12:10:23 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> Message-ID: <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> I don?t see your testcase in the webrev can you add it in and re-generate. Thanks. > On 11 Nov 2015, at 12:08, Langer, Christoph wrote: > > Hi Vincent, > > so this is the final version which should be pushed: > http://cr.openjdk.java.net/~clanger/webrevs/8139436.2/ > > I removed an unnecessary blank in a method call and updated the copyright information. I also ran another build and verified with my test case. > > Thanks in advance for taking care. > Christoph > > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com ] > Sent: Mittwoch, 11. November 2015 08:46 > To: Mike StJohns >; Langer, Christoph > > Cc: security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module depend on the java.base module. > And that?s OK. > > I can sponsor this changeset. > > > On 10 Nov 2015, at 22:39, Mike StJohns > wrote: > > On 11/10/2015 4:12 PM, Langer, Christoph wrote: > Hi folks, > > is there any feedback/review for this change? > > I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. > > Mike > > > > Thanks > Christoph > > From: Langer, Christoph > Sent: Mittwoch, 4. November 2015 12:11 > To: 'Michael StJohns' > Cc: security-dev at openjdk.java.net > Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > Hi Mike, > > eventually I?ve made a new webrev implementing your suggestion for a simpler patch: > > http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ > > @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? > > Thanks > Christoph > > > From: Michael StJohns [mailto:mstjohns at comcast.net ] > Sent: Donnerstag, 15. Oktober 2015 02:09 > To: Langer, Christoph > > Cc: security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > Sorry for the top post, I'm wring this on an iPad on a plane. > > > It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. > > Mike > > > > Sent from my iPad > > On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: > > Hi Mike, > > thanks for your comments on this. > > I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? > > The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. > > What do you think? > > @all: Are there other opinions? > > Thanks and best regards > Christoph > > From: security-dev [mailto:security-dev-bounces at openjdk.java.net ] On Behalf Of Mike StJohns > Sent: Mittwoch, 14. Oktober 2015 02:17 > To: security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > Hi - > > I took a look and this probably isn't the correct way to fix this. > > A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? > > The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") > > Mike > > > On 10/12/2015 5:04 PM, Langer, Christoph wrote: > Hi, > > please review a change proposal regarding an issue in the Microsoft Security API (mscapi). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ > > I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: > Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 > at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) > at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) > at java.security.KeyStore.getCertificate(KeyStore.java:1095) > At that point it is not obvious what the real root cause for that is. > > With my change, loading of the keystore would already throw like this: > java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) > at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) > at java.security.KeyStore.load(KeyStore.java:1459) > at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) > Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 > at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) > at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) > ... 3 more > Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! > at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) > at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) > at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) > ... 5 more > This is more obvious when it comes to analyzing such an issue. > > Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. > > You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. > > Would you think this change is reasonable and worthwile? > > Thanks & Best regards > Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xuelei.Fan at Oracle.COM Thu Nov 12 12:35:44 2015 From: Xuelei.Fan at Oracle.COM (Xuelei Fan) Date: Thu, 12 Nov 2015 20:35:44 +0800 Subject: RFR: [JDK-8072463] Remove requirement that AKID and SKID have to match when building certificate chain In-Reply-To: <564205ED.6030405@oracle.com> References: <564205ED.6030405@oracle.com> Message-ID: <564487A0.7080000@Oracle.COM> Looks fine to me. Xuelei On 11/10/2015 10:57 PM, Sean Mullan wrote: > Please review this fix for a regression that removes the requirement > that a certificate's Authority Key Identifier must match the issuing > certificate's Subject Key Identifier when building a certificate chain. > > The certificate chain validation algorithm in RFC 5280 does not require > that the AKID/SKID match. > > I have moved the AKID/SKID match into the sorting criteria for building > paths. If they match, it will try that certificate first, but it will > also fallback and search other paths. > > A new test has been added to the closed area since it depends on > certificates contributed by the submitter. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8072463/webrev.00/ > > --Sean From sean.mullan at oracle.com Thu Nov 12 15:23:47 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 12 Nov 2015 10:23:47 -0500 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> Message-ID: <5644AF03.5010704@oracle.com> Hi Max, Still reviewing, but a couple of initial comments .. On 11/09/2015 09:54 AM, Wang Weijun wrote: > Hi All > > The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at > > https://bugs.openjdk.java.net/browse/JDK-8051408 > > Some notes before the text: > > 1. Mainly, new methods are added to SecureRandom to match DRBG functions: > > - configure: choosing the algorithms and parameters What happens if configure is called more than once, or simultaneously by more than one thread? Instead of a configure method, I would suggest adding new getInstance methods that take an AlgorithmParameterSpec. This should simplify the implementation. I also think it might be cleaner and simpler to make EntropyInput an input parameter of DrbgSpec so that you could have a single AlgorithmParameterSpec parameter (instead of an AlgParamSpec and EntropyInput) for the getInstance method. --Sean From mark.sheppard at oracle.com Thu Nov 12 16:46:35 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Thu, 12 Nov 2015 16:46:35 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <562D6679.9090509@oracle.com> References: <562D6679.9090509@oracle.com> Message-ID: <5644C26B.2030007@oracle.com> Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ regards Mark On 25/10/2015 23:32, Mark Sheppard wrote: > Hi, > please oblige and review the following changes > http://cr.openjdk.java.net/~msheppar/8134577/webrev/ > > which address the issue raised in > https://bugs.openjdk.java.net/browse/JDK-8134577 > > the operative word has been "eliminate". > As such, the interface and service descriptor > sun.net.spi.nameservice.NameService > sun.net.spi.nameservice.NameServiceDescriptor* > *together with its implementation (sun.net.nameservice.dns.DNSNameService) > has been remove from the JDK libraries. > > The immediate impact is seen in the JDK testing framework. > > To facilitate testing activity, and provide a replacement for the > customized NameService implementations in the > JDK tests, the default NameService has been extended to support > the retrieval of host to IP address mappings from a file. > The file path is specified with a system property " jdk.internal.hosts". > > Previously a nameservice provider was specified by setting the system > property > "sun.net.spi.nameservice.provider.", as per the documentation > http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html > > InetAddress now tests to determine if this property is set and will > throw a ServiceConfigurationError > indicating that this functionality is no longer supported. The choice > of ServideConfigurationError may cause > some debate, or disagreement. The rationale was that InternalError, > is documented to relate to a JVM error, > and javax.naming.NamingException has a context of DirContext. > A possible alternative candidate could be > javax.naming.ServiceUnavailableException. > As such, the setting of the property > "sun.net.spi.nameservice.provider." was used, previously, as a > configuration > parameter for the loading of a NamerService service provider, and as > this is now (considered) an error, ServiceConfigurationError, > seemed a best fit! > > These changes impacted a number of jdk security tests, also. The > affected tetsts have been amended to adopt the > changes, with the exception of > test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java > which will require some rewrite. > > regards > Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Nov 12 23:12:55 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Nov 2015 23:12:55 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> Hi Vincent, I just updated the changeset with a testcase: http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ The testcase would run through with or without my patch, unless you specify the IAIK provider as explained in the test description. Can the fix be pushed now? Thanks Christoph From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Mittwoch, 11. November 2015 13:18 To: Langer, Christoph Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Unfortunately I cannot push a changeset without a jtreg test. Can you validate the fix another way - without using the IAIK provider? On 11 Nov 2015, at 12:13, Langer, Christoph > wrote: Well, the test coding is available in the description of the Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 As reproduction of the issue would involve an older IAIK jce provider and a Windows certificate store containing EC certificates, I think it is not a feasible candidate for creating a jtreg test. Best regards Christoph From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Mittwoch, 11. November 2015 13:10 To: Langer, Christoph > Cc: security-dev at openjdk.java.net; Mike StJohns > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data I don?t see your testcase in the webrev can you add it in and re-generate. Thanks. On 11 Nov 2015, at 12:08, Langer, Christoph > wrote: Hi Vincent, so this is the final version which should be pushed: http://cr.openjdk.java.net/~clanger/webrevs/8139436.2/ I removed an unnecessary blank in a method call and updated the copyright information. I also ran another build and verified with my test case. Thanks in advance for taking care. Christoph From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Mittwoch, 11. November 2015 08:46 To: Mike StJohns >; Langer, Christoph > Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Explicitly referencing the Sun JCE provider makes the jdk.crypto.mscapi module depend on the java.base module. And that?s OK. I can sponsor this changeset. On 10 Nov 2015, at 22:39, Mike StJohns > wrote: On 11/10/2015 4:12 PM, Langer, Christoph wrote: Hi folks, is there any feedback/review for this change? I missed the 4 Nov message when it came past. No further objections. But still unclear if modularization will permit this. Mike Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. November 2015 12:11 To: 'Michael StJohns' Cc: security-dev at openjdk.java.net Subject: RE: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi Mike, eventually I?ve made a new webrev implementing your suggestion for a simpler patch: http://cr.openjdk.java.net/~clanger/webrevs/8139436.1/ @All: Is that a valid fix for this issue? Would anyone mind to review/sponsor this? Thanks Christoph From: Michael StJohns [mailto:mstjohns at comcast.net] Sent: Donnerstag, 15. Oktober 2015 02:09 To: Langer, Christoph > Cc: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Sorry for the top post, I'm wring this on an iPad on a plane. It's perfectly acceptable for a provider to prefer its version of stuff over even something early in the provider list. Usually, that has more to do with key material ( for example pkcs11 instantiations), but there's no reason why it shouldn't apply to certificates. Mike Sent from my iPad On Oct 14, 2015, at 18:35, Langer, Christoph > wrote: Hi Mike, thanks for your comments on this. I agree that the change is quite critical and my approach might not be good. However, as for your suggestion to specify the sun provider for the certificate factory, I?d say this is not quite right, too. Because, if you have loaded a different provider on top of the providers list, you?ll intend to use its facilities by default. Maybe the idea would be to use the sun provider as fallback in case of an exception? The other suggestion to check for certChain.length in KeyStore.getCertificate and return null would be an improvement compared to throwing an ArrayIndexOutOfBoundsException ? however, it would still be difficult to find the root cause why a certificate could not be loaded. What do you think? @all: Are there other opinions? Thanks and best regards Christoph From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Mike StJohns Sent: Mittwoch, 14. Oktober 2015 02:17 To: security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi - I took a look and this probably isn't the correct way to fix this. A simpler change might be to specify the sun provider when requesting the certificate factory. I hesitate to say that definitively as modularization guidance may restrict that approach? The belt and suspenders approach is to catch the bad certificate exception and return null. That appears to be the correct contract for KeyStore.getCertificate(String alias). (e.g. "if (certChain.length == 0) return null;") Mike On 10/12/2015 5:04 PM, Langer, Christoph wrote: Hi, please review a change proposal regarding an issue in the Microsoft Security API (mscapi). Bug: https://bugs.openjdk.java.net/browse/JDK-8139436 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.0/ I stumbled over the issue when using an old IAIK security provider. It would throw java.security.cert.CertificateException upon parsing ECC based certificates when generating Certificate objects. The way it is right now, such exceptions are silently caught and the Windows Keystore is created with incomplete data. Upon accessing such ECC certificates from the Keystore object, e.g. when iterating over it, you?ll get exceptions like: Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0 at sun.security.mscapi.KeyStore.engineGetCertificate(KeyStore.java:313) at sun.security.mscapi.KeyStore$ROOT.engineGetCertificate(KeyStore.java:60) at java.security.KeyStore.getCertificate(KeyStore.java:1095) At that point it is not obvious what the real root cause for that is. With my change, loading of the keystore would already throw like this: java.io.IOException: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:780) at sun.security.mscapi.KeyStore$ROOT.engineLoad(KeyStore.java:60) at java.security.KeyStore.load(KeyStore.java:1459) at WindowsCertificateReaderTest.main(WindowsCertificateReaderTest.java:18) Caused by: java.security.KeyStoreException: Exception occurred generating certificate object for alias DigiCert Assured ID Root G3 at sun.security.mscapi.KeyStore.loadKeysOrCertificateChains(Native Method) at sun.security.mscapi.KeyStore.engineLoad(KeyStore.java:777) ... 3 more Caused by: java.security.cert.CertificateException: Error parsing certificates! iaik.asn1.DerInputException: Next ASN.1 object is no OBJECT IDENTIFIER! at iaik.x509.CertificateFactory.engineGenerateCertificates(Unknown Source) at java.security.cert.CertificateFactory.generateCertificates(CertificateFactory.java:462) at sun.security.mscapi.KeyStore.generateCertificate(KeyStore.java:869) ... 5 more This is more obvious when it comes to analyzing such an issue. Also, I added a property ?sun.security.mscapi.ignoreFailingCertificates? which, when set to true, will cause skipping of certificates that failed with Exception. That might be a nice workaround option if one is not particularly interested in a failing certificate. You can reproduce all this with the test coding in the OpenJDK Bug, the IAIK provider 3.15 which is downloadable here:http://jcewww.iaik.tu-graz.ac.at/sic/Download (educational/research version, needs registration) and ECC certificates in the Windows Root certificate store. Would you think this change is reasonable and worthwile? Thanks & Best regards Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Nov 13 00:58:37 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 13 Nov 2015 08:58:37 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5644AF03.5010704@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> Message-ID: <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> > On Nov 12, 2015, at 11:23 PM, Sean Mullan wrote: > > Hi Max, > > Still reviewing, but a couple of initial comments .. > > On 11/09/2015 09:54 AM, Wang Weijun wrote: >> Hi All >> >> The following is API/SPI to support NIST 800-90A DRBGs. The JEP is at >> >> https://bugs.openjdk.java.net/browse/JDK-8051408 >> >> Some notes before the text: >> >> 1. Mainly, new methods are added to SecureRandom to match DRBG functions: >> >> - configure: choosing the algorithms and parameters > > What happens if configure is called more than once, or simultaneously by more than one thread? The state is reset. The last one rules. The implementation can be made synchronized. * This method can be called multiple times. After each call, this * {@code SecureRandom} object must be reseeded. > > Instead of a configure method, I would suggest adding new getInstance methods that take an AlgorithmParameterSpec. This should simplify the implementation. getInstance() has 3 flavors, (), (String) and (Provider). Too many new methods to add. > > I also think it might be cleaner and simpler to make EntropyInput an input parameter of DrbgSpec so that you could have a single AlgorithmParameterSpec parameter (instead of an AlgParamSpec and EntropyInput) for the getInstance method. EntropyInput as a separated parameter means it applies to other SecureRandom implementations and not only DRBG. For example, SHA1PRNG can also have a specified entropy source. It is also useful to describe what reSeed() means. Thanks Max > > --Sean From weijun.wang at oracle.com Fri Nov 13 01:08:20 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 13 Nov 2015 09:08:20 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> Message-ID: <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> > On Nov 13, 2015, at 7:12 AM, Langer, Christoph wrote: > > Hi Vincent, > > I just updated the changeset with a testcase:http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ > > The testcase would run through with or without my patch, unless you specify the IAIK provider as explained in the test description. Maybe you can add a simple provider inside the test that mimics the behavior of IAIK's certificate factory? Or just fail immediately? Otherwise few people will run the test like you described, it becomes practically @manual. --Max > > Can the fix be pushed now? > > Thanks > Christoph From weijun.wang at oracle.com Fri Nov 13 01:14:27 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 13 Nov 2015 09:14:27 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> Message-ID: <3FF756DC-60C2-4472-8E6A-1A0A8BC5015E@oracle.com> Also there is a standard way to check if it's windows: http://openjdk.java.net/jtreg/tag-spec.html#requires_names os.family should be the one to use. --Max > >> I just updated the changeset with a testcase:http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ >> From amanda.jiang at oracle.com Fri Nov 13 08:57:28 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Fri, 13 Nov 2015 00:57:28 -0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <55D6CF87.807@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> Message-ID: <5645A5F7.1070109@oracle.com> Hi Max, Please check the updated webrev which address your comments, please let me know if you have any other suggestions. http://cr.openjdk.java.net/~amjiang/8048357/webrev.02/ Thanks, Amanda On 15/8/21 ??12:13, Weijun Wang wrote: > PKCS10AttrOrder.java: > > - Why not inline revAttributes(), prov() and constructMap()? They are > only used once. Putting the content into the main method is more clear. > > - You can create separate method for the while look checks. The 2 look > identical. > > PKCS10AttributeReader.java: > > - Is it OK to indent the data in the comment to multiple levels? > > - Again, initMap() not necessary. > > PKCS7VerifyTest.java: > > - Not sure what this is for. The 1st and 2nd argument of the @run line > are the same? those 3 arguments are actually for two different test cases, I use two @run tags in updated webrev and add some comments in test to make it clear. > > SignerOrder.java: > > - Comment on what derString1 and derString1 are. > > - What do you expect verifs1.length and verifs2.length to be? Will you > also check it? Yes I do check verifs1.length and verifs2.length should be same. 121 if (verifs1.length != verifs2.length) { 122 throw new RuntimeException("Length or Original vs read-in " 123 + "should be same"); 124 } > > PKCS8Test.java: > > - Typo: s/recieved/received/g > > Thanks > Max > > On 08/21/2015 07:11 AM, Amanda Jiang wrote: >> Hi All, >> >> Please be free to review new tests for conformance testing of PKCS. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8048357 >> webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ >> >> Thanks, >> Amanda >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Fri Nov 13 12:33:15 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Nov 2015 12:33:15 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> Hi Max, thanks for your hint. I now implemented a dummy provider that would recreate the issue. Also thanks for the hint regarding the @requires tag. I implemented that and I also reworked all the other testcases for sunmscapi to make use of @requires and threw out unnecessary checks for MSCAPI availability. Is that ok now? Best regards Christoph -----Original Message----- From: Wang Weijun [mailto:weijun.wang at oracle.com] Sent: Freitag, 13. November 2015 02:08 To: Langer, Christoph Cc: Vincent Ryan ; security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > On Nov 13, 2015, at 7:12 AM, Langer, Christoph wrote: > > Hi Vincent, > > I just updated the changeset with a testcase:http://cr.openjdk.java.net/~clanger/webrevs/8139436.3/ > > The testcase would run through with or without my patch, unless you specify the IAIK provider as explained in the test description. Maybe you can add a simple provider inside the test that mimics the behavior of IAIK's certificate factory? Or just fail immediately? Otherwise few people will run the test like you described, it becomes practically @manual. --Max > > Can the fix be pushed now? > > Thanks > Christoph From mark.sheppard at oracle.com Fri Nov 13 12:44:49 2015 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Fri, 13 Nov 2015 12:44:49 +0000 Subject: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor In-Reply-To: <5644C26B.2030007@oracle.com> References: <562D6679.9090509@oracle.com> <5644C26B.2030007@oracle.com> Message-ID: <5645DB41.8000704@oracle.com> Hi, to summarize the amendments below: ServiceConfigurationError removed - the code no longer reads the nameservice provider property, it silently ignored try-with-resources statement added in getHostByAddr and lookupAllHostAddr methods of NameService, and duplicate statements removed hosts file name in tests changed to TestHosts to avoid any potential confusion with /etc/hosts regards Mark On 12/11/2015 16:46, Mark Sheppard wrote: > Hi, > based on feedback from first review the updates have been amended > please oblige and review the current set of changes as per > > http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ > > regards > Mark > > On 25/10/2015 23:32, Mark Sheppard wrote: >> Hi, >> please oblige and review the following changes >> http://cr.openjdk.java.net/~msheppar/8134577/webrev/ >> >> which address the issue raised in >> https://bugs.openjdk.java.net/browse/JDK-8134577 >> >> the operative word has been "eliminate". >> As such, the interface and service descriptor >> sun.net.spi.nameservice.NameService >> sun.net.spi.nameservice.NameServiceDescriptor* >> *together with its implementation >> (sun.net.nameservice.dns.DNSNameService) >> has been remove from the JDK libraries. >> >> The immediate impact is seen in the JDK testing framework. >> >> To facilitate testing activity, and provide a replacement for the >> customized NameService implementations in the >> JDK tests, the default NameService has been extended to support >> the retrieval of host to IP address mappings from a file. >> The file path is specified with a system property " jdk.internal.hosts". >> >> Previously a nameservice provider was specified by setting the system >> property >> "sun.net.spi.nameservice.provider.", as per the documentation >> http://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html >> >> InetAddress now tests to determine if this property is set and will >> throw a ServiceConfigurationError >> indicating that this functionality is no longer supported. The choice >> of ServideConfigurationError may cause >> some debate, or disagreement. The rationale was that InternalError, >> is documented to relate to a JVM error, >> and javax.naming.NamingException has a context of DirContext. >> A possible alternative candidate could be >> javax.naming.ServiceUnavailableException. >> As such, the setting of the property >> "sun.net.spi.nameservice.provider." was used, previously, as a >> configuration >> parameter for the loading of a NamerService service provider, and as >> this is now (considered) an error, ServiceConfigurationError, >> seemed a best fit! >> >> These changes impacted a number of jdk security tests, also. The >> affected tetsts have been amended to adopt the >> changes, with the exception of >> test/sun/security/x509/URICertStore/ExtensionsWithLDAP.java >> which will require some rewrite. >> >> regards >> Mark >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Fri Nov 13 16:07:53 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 14 Nov 2015 00:07:53 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> Message-ID: <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> It is my understanding that if you write multiple files for a single test, they should be put inside a sub-directory. But in this case you can combine them into a single class by putting the provider-related codes into static inner classes. --Max P. S. Sent from my iPhone so I haven't read all the changes. > ? 2015?11?13??20:33?Langer, Christoph ??? > > Is that ok now? From sean.mullan at oracle.com Fri Nov 13 17:56:06 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 13 Nov 2015 12:56:06 -0500 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> Message-ID: <56462436.1050602@oracle.com> On 11/12/2015 07:58 PM, Wang Weijun wrote: >> What happens if configure is called more than once, or >> simultaneously by more than one thread? > The state is reset. The last one rules. The implementation can be > made synchronized. > > * This method can be called multiple times. After each call, this * > {@code SecureRandom} object must be reseeded. > >>> >>> Instead of a configure method, I would suggest adding new >>> getInstance methods that take an AlgorithmParameterSpec. This >>> should simplify the implementation. > getInstance() has 3 flavors, (), (String) and (Provider). Too many > new methods to add. Only 3 more. It would seem to make the implementation simpler, less state and synchronization to worry about. >>> I also think it might be cleaner and simpler to make EntropyInput >>> an input parameter of DrbgSpec so that you could have a single >>> AlgorithmParameterSpec parameter (instead of an AlgParamSpec and >>> EntropyInput) for the getInstance method. > EntropyInput as a separated parameter means it applies to other > SecureRandom implementations and not only DRBG. For example, SHA1PRNG > can also have a specified entropy source. It is also useful to > describe what reSeed() means. Ok but it's really just an input parameter, right? Maybe, you want something like: public interface SecureRandomSpec extends AlgorithmParameterSpec { EntropyInput getEntropyInput(); } public class DrbgSpec implements SecureRandomSpec { } --Sean From christoph.langer at sap.com Fri Nov 13 23:54:47 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Nov 2015 23:54:47 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> Hi Max, I followed your suggestion to use a sub-directory. I found no way to make the dummy JCE provider work with inner classes. Please see this (hopefully final) webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.5/ Best regards Christoph -----Original Message----- From: Wang Weijun [mailto:weijun.wang at oracle.com] Sent: Freitag, 13. November 2015 17:08 To: Langer, Christoph Cc: Vincent Ryan ; security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data It is my understanding that if you write multiple files for a single test, they should be put inside a sub-directory. But in this case you can combine them into a single class by putting the provider-related codes into static inner classes. --Max P. S. Sent from my iPhone so I haven't read all the changes. > ? 2015?11?13??20:33?Langer, Christoph ??? > > Is that ok now? From weijun.wang at oracle.com Sat Nov 14 01:43:33 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 14 Nov 2015 09:43:33 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <56462436.1050602@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> Message-ID: <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> > On 2015?11?14?, at ??1:56, Sean Mullan wrote: > > On 11/12/2015 07:58 PM, Wang Weijun wrote: >>> What happens if configure is called more than once, or >>> simultaneously by more than one thread? >> The state is reset. The last one rules. The implementation can be >> made synchronized. >> >> * This method can be called multiple times. After each call, this * >> {@code SecureRandom} object must be reseeded. >> >>>> >>>> Instead of a configure method, I would suggest adding new >>>> getInstance methods that take an AlgorithmParameterSpec. This >>>> should simplify the implementation. >> getInstance() has 3 flavors, (), (String) and (Provider). Too many >> new methods to add. > > Only 3 more. It would seem to make the implementation simpler, less state and synchronization to worry about. OK. > >>>> I also think it might be cleaner and simpler to make EntropyInput >>>> an input parameter of DrbgSpec so that you could have a single >>>> AlgorithmParameterSpec parameter (instead of an AlgParamSpec and >>>> EntropyInput) for the getInstance method. >> EntropyInput as a separated parameter means it applies to other >> SecureRandom implementations and not only DRBG. For example, SHA1PRNG >> can also have a specified entropy source. It is also useful to >> describe what reSeed() means. > > Ok but it's really just an input parameter, right? > > Maybe, you want something like: > > public interface SecureRandomSpec extends AlgorithmParameterSpec { > > EntropyInput getEntropyInput(); > } > > public class DrbgSpec implements SecureRandomSpec { > > } Sound good. I'll update the APIs. Thanks Max > > --Sean From weijun.wang at oracle.com Sat Nov 14 02:31:51 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 14 Nov 2015 10:31:51 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> Message-ID: Hi Christoph I tried updating the entry line in TestProvider and it starts working. this.put("CertificateFactory.X.509", "IterateWindowsRootStore$TestFactory"); PrngSlow.java: Do you still need the "// Not supported here, maybe not a Win32" block? Is there other exception you want to ignore? I also notice @required is not used everywhere (For example, SignUsingNONEwithRSA.sh). I'm not a fan of fixing existing tests but since you started we can be more consistent. Thanks Max > On 2015?11?14?, at ??7:54, Langer, Christoph wrote: > > Hi Max, > > I followed your suggestion to use a sub-directory. I found no way to make the dummy JCE provider work with inner classes. > > Please see this (hopefully final) webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.5/ > > Best regards > Christoph > > -----Original Message----- > From: Wang Weijun [mailto:weijun.wang at oracle.com] > Sent: Freitag, 13. November 2015 17:08 > To: Langer, Christoph > Cc: Vincent Ryan ; security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > It is my understanding that if you write multiple files for a single test, they should be put inside a sub-directory. > > But in this case you can combine them into a single class by putting the provider-related codes into static inner classes. > > --Max > > P. S. Sent from my iPhone so I haven't read all the changes. > >> ? 2015?11?13??20:33?Langer, Christoph ??? >> >> Is that ok now? From christoph.langer at sap.com Sun Nov 15 23:27:07 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 15 Nov 2015 23:27:07 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> Hi Max, thanks for that hint about correctly referencing the inner class. Now I could do it. As for PrngSlow.java: By having a closer look, I discovered that the test was always running into an exception, as the algorithm name "PRNG" is not available for MSCAPI. I renamed it to the correct value of "Windows-PRNG" and now the test would run. I also cleaned the class and removed the exception handler so real exceptions should pop up now. Also, I completed adding the @requires tag for each test. This is the result: http://cr.openjdk.java.net/~clanger/webrevs/8139436.6/ Best regards Christoph -----Original Message----- From: Wang Weijun [mailto:weijun.wang at oracle.com] Sent: Samstag, 14. November 2015 03:32 To: Langer, Christoph Cc: Vincent Ryan ; security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Hi Christoph I tried updating the entry line in TestProvider and it starts working. this.put("CertificateFactory.X.509", "IterateWindowsRootStore$TestFactory"); PrngSlow.java: Do you still need the "// Not supported here, maybe not a Win32" block? Is there other exception you want to ignore? I also notice @required is not used everywhere (For example, SignUsingNONEwithRSA.sh). I'm not a fan of fixing existing tests but since you started we can be more consistent. Thanks Max > On 2015?11?14?, at ??7:54, Langer, Christoph wrote: > > Hi Max, > > I followed your suggestion to use a sub-directory. I found no way to make the dummy JCE provider work with inner classes. > > Please see this (hopefully final) webrev: http://cr.openjdk.java.net/~clanger/webrevs/8139436.5/ > > Best regards > Christoph > > -----Original Message----- > From: Wang Weijun [mailto:weijun.wang at oracle.com] > Sent: Freitag, 13. November 2015 17:08 > To: Langer, Christoph > Cc: Vincent Ryan ; security-dev at openjdk.java.net > Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > > It is my understanding that if you write multiple files for a single test, they should be put inside a sub-directory. > > But in this case you can combine them into a single class by putting the provider-related codes into static inner classes. > > --Max > > P. S. Sent from my iPhone so I haven't read all the changes. > >> ? 2015?11?13??20:33?Langer, Christoph ??? >> >> Is that ok now? From weijun.wang at oracle.com Mon Nov 16 00:32:35 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Nov 2015 08:32:35 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> Message-ID: <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> All tests look fine. I suppose Vincent already agreed with the src change. Right? For safety, I am running all related tests on windows-i586 and windows-x64 now. Thanks Max > On 2015?11?16?, at ??7:27, Langer, Christoph wrote: > > Hi Max, > > thanks for that hint about correctly referencing the inner class. Now I could do it. > > As for PrngSlow.java: By having a closer look, I discovered that the test was always running into an exception, as the algorithm name "PRNG" is not available for MSCAPI. I renamed it to the correct value of "Windows-PRNG" and now the test would run. I also cleaned the class and removed the exception handler so real exceptions should pop up now. > > Also, I completed adding the @requires tag for each test. > > This is the result: http://cr.openjdk.java.net/~clanger/webrevs/8139436.6/ > > Best regards > Christoph From vincent.x.ryan at oracle.com Mon Nov 16 07:19:54 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 16 Nov 2015 07:19:54 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> Message-ID: <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> Yes the source changes look fine. Last week I ran the tests using webrev.4 and all passed. Thanks Christoph for the comprehensive fix. > On 16 Nov 2015, at 00:32, Wang Weijun wrote: > > All tests look fine. > > I suppose Vincent already agreed with the src change. Right? > > For safety, I am running all related tests on windows-i586 and windows-x64 now. > > Thanks > Max > >> On 2015?11?16?, at ??7:27, Langer, Christoph wrote: >> >> Hi Max, >> >> thanks for that hint about correctly referencing the inner class. Now I could do it. >> >> As for PrngSlow.java: By having a closer look, I discovered that the test was always running into an exception, as the algorithm name "PRNG" is not available for MSCAPI. I renamed it to the correct value of "Windows-PRNG" and now the test would run. I also cleaned the class and removed the exception handler so real exceptions should pop up now. >> >> Also, I completed adding the @requires tag for each test. >> >> This is the result: http://cr.openjdk.java.net/~clanger/webrevs/8139436.6/ >> >> Best regards >> Christoph > From christoph.langer at sap.com Mon Nov 16 07:30:04 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Nov 2015 07:30:04 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F539DF@DEWDFEMB12B.global.corp.sap> OK, thanks for reviewing. Please push the fix at your convenience. Any objections against downporting to JDK 8? -----Original Message----- From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] Sent: Montag, 16. November 2015 08:20 To: Wang Weijun Cc: Langer, Christoph ; security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data Yes the source changes look fine. Last week I ran the tests using webrev.4 and all passed. Thanks Christoph for the comprehensive fix. > On 16 Nov 2015, at 00:32, Wang Weijun wrote: > > All tests look fine. > > I suppose Vincent already agreed with the src change. Right? > > For safety, I am running all related tests on windows-i586 and windows-x64 now. > > Thanks > Max > >> On 2015?11?16?, at ??7:27, Langer, Christoph wrote: >> >> Hi Max, >> >> thanks for that hint about correctly referencing the inner class. Now I could do it. >> >> As for PrngSlow.java: By having a closer look, I discovered that the test was always running into an exception, as the algorithm name "PRNG" is not available for MSCAPI. I renamed it to the correct value of "Windows-PRNG" and now the test would run. I also cleaned the class and removed the exception handler so real exceptions should pop up now. >> >> Also, I completed adding the @requires tag for each test. >> >> This is the result: http://cr.openjdk.java.net/~clanger/webrevs/8139436.6/ >> >> Best regards >> Christoph > From weijun.wang at oracle.com Mon Nov 16 07:32:01 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Nov 2015 15:32:01 +0800 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> Message-ID: <266F3E24-7DBB-4A65-A7D4-26251234F2F0@oracle.com> > On Nov 16, 2015, at 3:19 PM, Vincent Ryan wrote: > > Yes the source changes look fine. > Last week I ran the tests using webrev.4 and all passed. FYI: webrev.6 also pass. --Max > > Thanks Christoph for the comprehensive fix. From weijun.wang at oracle.com Mon Nov 16 07:41:29 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 16 Nov 2015 15:41:29 +0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <5645A5F7.1070109@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> Message-ID: <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> Why "othervm" for all these tests? PKCS10AttrOrder.java: - Is sun.security.provider and sun.misc used anywhere? You have them in @modules. - sun.security.pkcs.PKCS9Attribute contains public constants like CONTENT_TYPE_OID, SIGNING_TIME_OID, CHALLENGE_PASSWORD_OID. You can directly use them. Same as PKCS10AttributeReader.java. - What does "order" mean in the test name? PKCS10 Attributes is a Set, therefore there is no order. - You print out "List of attributes in constructed PKCS10 request: " but I see no content. - checkAttributes() ensures every attribute in the encoded PKCS10 has the correct value. But you haven't checked if all entries in constructedMap are encoded. Maybe compare the size? PKCS10AttributeReader.java: - sun.misc in @modules? - Line 45: .asn1 -> asn.1 - Please also compare the size of RequestStander and eReq. PKCS8Test.java: - sun.security.x509 in @modules? - Line 206: Dump encodedKey here? Seems too late. Why not do it before the check or at least before raiseException? Same with the other 4 debug outputs after raiseException. - EXPECTED_ALG_ID_CHRS can be just a String with \n and \t inside. pkcs7/*.java: Please take a look at Bernd Eckenfels's comments on Aug 21. I fully agree with him. Thanks Max ---- > On Nov 13, 2015, at 4:57 PM, Amanda Jiang wrote: > > Hi Max, > > Please check the updated webrev which address your comments, please let me know if you have any other suggestions. > http://cr.openjdk.java.net/~amjiang/8048357/webrev.02/ > > Thanks, > Amanda > > On 15/8/21 ??12:13, Weijun Wang wrote: >> PKCS10AttrOrder.java: >> >> - Why not inline revAttributes(), prov() and constructMap()? They are only used once. Putting the content into the main method is more clear. >> >> - You can create separate method for the while look checks. The 2 look identical. >> >> PKCS10AttributeReader.java: >> >> - Is it OK to indent the data in the comment to multiple levels? >> >> - Again, initMap() not necessary. >> >> PKCS7VerifyTest.java: >> >> - Not sure what this is for. The 1st and 2nd argument of the @run line are the same? > those 3 arguments are actually for two different test cases, I use two @run tags in updated webrev and add some comments in test to make it clear. >> >> SignerOrder.java: >> >> - Comment on what derString1 and derString1 are. >> >> - What do you expect verifs1.length and verifs2.length to be? Will you also check it? > Yes I do check verifs1.length and verifs2.length should be same. > 121 if (verifs1.length != verifs2.length) { > 122 throw new RuntimeException("Length or Original vs read-in " > 123 + "should be same"); > 124 } > > > >> >> PKCS8Test.java: >> >> - Typo: s/recieved/received/g >> >> Thanks >> Max >> >> On 08/21/2015 07:11 AM, Amanda Jiang wrote: >>> Hi All, >>> >>> Please be free to review new tests for conformance testing of PKCS. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8048357 >>> webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ >>> >>> Thanks, >>> Amanda >>> > From chris.hegarty at oracle.com Mon Nov 16 15:21:19 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Nov 2015 15:21:19 +0000 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> Message-ID: <5649F46F.6070902@oracle.com> Including the security-dev mailing list. -Chris. On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: > In the Devoxx presentation "Prepare for JDK9", the strategy for > encapsulating "sun.* " packages is discussed. > The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of > JDK-internal APIs"), but as the rest of sun.security.* is listed as > "Non-critical, no replacement planned", will this also be case for > SunPKCS11? > As far as I know there is no alternative security Provider for > integrating with PKCS11 aside from rolling your own jni code or using > vendor-specific apis. > > We rely on SunPKCS for interfacing with an HSM and belgian e-id > smartcard. And even though we are aware that touching sun.* is frowned > upon, first search hit on "java pkcs11" gives following page: > https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html > . With such elaborate documentation, you can't really blame devs to > actually use this functionality :) . > > Is there an alternative to SunPKCS11 or am I overlooking something? > > Thanks for your response, > Glen Vermeylen From vincent.x.ryan at oracle.com Mon Nov 16 15:30:00 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 16 Nov 2015 15:30:00 +0000 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649F46F.6070902@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> Message-ID: <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> Hello Glen, JCE providers are always accessed via the Java SE public APIs and not directly via sun.* implementation classes. In JDK 9, the SunPKCS11 provider continues to be accessible via those APIs. It?s implementation classes are present in the jdk.crypto.pkcs11 module. Thanks. > On 16 Nov 2015, at 15:21, Chris Hegarty wrote: > > Including the security-dev mailing list. > > -Chris. > > On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: >> In the Devoxx presentation "Prepare for JDK9", the strategy for >> encapsulating "sun.* " packages is discussed. >> The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of >> JDK-internal APIs"), but as the rest of sun.security.* is listed as >> "Non-critical, no replacement planned", will this also be case for >> SunPKCS11? >> As far as I know there is no alternative security Provider for >> integrating with PKCS11 aside from rolling your own jni code or using >> vendor-specific apis. >> >> We rely on SunPKCS for interfacing with an HSM and belgian e-id >> smartcard. And even though we are aware that touching sun.* is frowned >> upon, first search hit on "java pkcs11" gives following page: >> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html >> . With such elaborate documentation, you can't really blame devs to >> actually use this functionality :) . >> >> Is there an alternative to SunPKCS11 or am I overlooking something? >> >> Thanks for your response, >> Glen Vermeylen From sean.mullan at oracle.com Mon Nov 16 15:46:16 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Nov 2015 10:46:16 -0500 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> Message-ID: <5649FA48.1060202@oracle.com> Additionally, in JDK 9 we have added a new configure method to the java.security.Provider class that allows you to configure an underlying provider with an additional argument. The SunPKCS11 implementation has been enhanced to support this method. So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 constructor to pass in a configuration file, you can now do the following: Provider p = Security.getProvider("SunPKCS11"); p.configure("/opt/bar/cfg/pkcs11.cfg"); We will update section 2.2 of the PKCS11 guide for JDK 9 to note this new usage. I believe that is the only section of the guide that discusses using an internal class directly. Are there any other internal PKCS11 classes you are using directly, and if so why? --Sean On 11/16/2015 10:30 AM, Vincent Ryan wrote: > Hello Glen, > > JCE providers are always accessed via the Java SE public APIs and not directly via sun.* implementation classes. > In JDK 9, the SunPKCS11 provider continues to be accessible via those APIs. It?s implementation classes are present > in the jdk.crypto.pkcs11 module. > > Thanks. > > >> On 16 Nov 2015, at 15:21, Chris Hegarty wrote: >> >> Including the security-dev mailing list. >> >> -Chris. >> >> On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: >>> In the Devoxx presentation "Prepare for JDK9", the strategy for >>> encapsulating "sun.* " packages is discussed. >>> The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of >>> JDK-internal APIs"), but as the rest of sun.security.* is listed as >>> "Non-critical, no replacement planned", will this also be case for >>> SunPKCS11? >>> As far as I know there is no alternative security Provider for >>> integrating with PKCS11 aside from rolling your own jni code or using >>> vendor-specific apis. >>> >>> We rely on SunPKCS for interfacing with an HSM and belgian e-id >>> smartcard. And even though we are aware that touching sun.* is frowned >>> upon, first search hit on "java pkcs11" gives following page: >>> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html >>> . With such elaborate documentation, you can't really blame devs to >>> actually use this functionality :) . >>> >>> Is there an alternative to SunPKCS11 or am I overlooking something? >>> >>> Thanks for your response, >>> Glen Vermeylen > From omajid at redhat.com Mon Nov 16 18:24:30 2015 From: omajid at redhat.com (Omair Majid) Date: Mon, 16 Nov 2015 13:24:30 -0500 Subject: Handling SNI alerts in OpenJDK Message-ID: <20151116182428.GC3979@redhat.com> Hi, There's an issue with using SNI (Server Name Indication) with OpenJDK. It will abort SSL/TLS connections to a server, when the server gives a "unrecognized name" alert in the ssl handshake. This alert always results in a java exception: Exception in thread "main" javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name RFC 5246 specifies that there are two alert levels: "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection" "If an alert with a level of warning is sent and received, generally the connection can continue normally" RFC 3546 (TLS Extensions) says: "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." So, with an urecognized_name alert that's not fatal, it is up to the client to continue if it wants to. Most SSL implementations will continue normally after receiving an "unrecognized name" alert with the level "warning". Java, however, does not. Probably because of issues like this, RFC 6066 (TLS Extensions: Extension Definitions) says: "It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable." It would be much better if OpenJDK followed what most other implementations do to remove ambiguity. There are two ways currently available to work around this issue. The first suggested workaround is using "jsse.enableSNIExtension=false". Unfortunately, this is often not a possible solution. This is because TLS needs SNI. RFC 7525 says: "TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy." And disabling SNI breaks connection to many webservers that rely on TLS. Anything that has to connect to an unknown number of servers needs SNI enabled. The second workaround is to fix the server. Practically speaking, a server administrator will often not define all the virtual hosts if they are supposed to use the default page. And this works with many implementations (including Chrome/Firefox/Internet Explorer) that they test. Unfortunately, this does not work with OpenJDK. So something that "works" for most other clients doesn't work with OpenJDK and it's not obvious that the server needs to be fixed. But perhaps more importantly, if you are just writing a client in Java, you may not have access to fix any misconfigured servers. So, neither of the current suggested workarounds works for all cases. I think we should fix OpenJDK to improve compatibility so that it works - similar to other TLS client implementations - with more servers by treating fatal and warning alerts differently. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From ecki at zusammenkunft.net Mon Nov 16 20:17:12 2015 From: ecki at zusammenkunft.net (ecki at zusammenkunft.net) Date: Mon, 16 Nov 2015 21:17:12 +0100 Subject: Handling SNI alerts in OpenJDK In-Reply-To: <20151116182428.GC3979@redhat.com> References: <20151116182428.GC3979@redhat.com> Message-ID: <40d864c1-b0b9-4983-9a22-61c46e92bfd8.maildroid@localhost> Hello Omair, I brought this up before, and agree with you that it is a good idea: if the server sends the alert and treats it fatal there is no problem in at least trying to continue. It is also not a security problem because the certificate will be validated (and if it is indeed the wrong server it will be noticed). http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374 I am not sure why it was rejected, most likely because of the unclear warning semantics. However I thi k there is no problem in continuing, either the server cooperates or not, the client will notice. Other implementations handle this less picky and still work. Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Omair Majid To: security-dev at openjdk.java.net Sent: Mo., 16 Nov. 2015 20:55 Subject: Handling SNI alerts in OpenJDK Hi, There's an issue with using SNI (Server Name Indication) with OpenJDK. It will abort SSL/TLS connections to a server, when the server gives a "unrecognized name" alert in the ssl handshake. This alert always results in a java exception: Exception in thread "main" javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name RFC 5246 specifies that there are two alert levels: "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection" "If an alert with a level of warning is sent and received, generally the connection can continue normally" RFC 3546 (TLS Extensions) says: "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." So, with an urecognized_name alert that's not fatal, it is up to the client to continue if it wants to. Most SSL implementations will continue normally after receiving an "unrecognized name" alert with the level "warning". Java, however, does not. Probably because of issues like this, RFC 6066 (TLS Extensions: Extension Definitions) says: "It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable." It would be much better if OpenJDK followed what most other implementations do to remove ambiguity. There are two ways currently available to work around this issue. The first suggested workaround is using "jsse.enableSNIExtension=false". Unfortunately, this is often not a possible solution. This is because TLS needs SNI. RFC 7525 says: "TLS implementations MUST support the Server Name Indication (SNI) extension defined in Section 3 of [RFC6066] for those higher-level protocols that would benefit from it, including HTTPS. However, the actual use of SNI in particular circumstances is a matter of local policy." And disabling SNI breaks connection to many webservers that rely on TLS. Anything that has to connect to an unknown number of servers needs SNI enabled. The second workaround is to fix the server. Practically speaking, a server administrator will often not define all the virtual hosts if they are supposed to use the default page. And this works with many implementations (including Chrome/Firefox/Internet Explorer) that they test. Unfortunately, this does not work with OpenJDK. So something that "works" for most other clients doesn't work with OpenJDK and it's not obvious that the server needs to be fixed. But perhaps more importantly, if you are just writing a client in Java, you may not have access to fix any misconfigured servers. So, neither of the current suggested workarounds works for all cases. I think we should fix OpenJDK to improve compatibility so that it works - similar to other TLS client implementations - with more servers by treating fatal and warning alerts differently. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From omajid at redhat.com Mon Nov 16 20:55:48 2015 From: omajid at redhat.com (Omair Majid) Date: Mon, 16 Nov 2015 15:55:48 -0500 Subject: Handling SNI alerts in OpenJDK In-Reply-To: <40d864c1-b0b9-4983-9a22-61c46e92bfd8.maildroid@localhost> References: <20151116182428.GC3979@redhat.com> <40d864c1-b0b9-4983-9a22-61c46e92bfd8.maildroid@localhost> Message-ID: <20151116205548.GE3979@redhat.com> Hi Bernd, * ecki at zusammenkunft.net [2015-11-16 15:17]: > I brought this up before, and agree with you that it is a good idea: > if the server sends the alert and treats it fatal there is no problem > in at least trying to continue. It is also not a security problem > because the certificate will be validated (and if it is indeed the > wrong server it will be noticed). > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374 > > I am not sure why it was rejected, most likely because of the unclear > warning semantics. However I thi k there is no problem in continuing, > either the server cooperates or not, the client will notice. Other > implementations handle this less picky and still work. I just wanted to clarify that this is slightly different from my proposal. This bug suggests that if the server sends a *fatal* alert the client should continue. This goes against the specification. RFC 5246 says: "Upon transmission or receipt of a fatal alert message, both parties immediately close the connection." So, I am not sure if not following the RFC is a good idea or not. Maybe it will be better, I am not sure. I haven't really looked into it. Do you know how browsers or other SSL/TLS clients handle this? What I am asking for is for a slightly different case: *warning* (not fatal) alerts to be treated differently. RFC 5246 states: "If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection." It is this case where the specification allows OpenJDK a choice. OpenJDK can either treat a unrecognized_name warning alert as fatal (and abort) or non-fatal (and continue). Many other clients (including browsers such as Firefox and Chrome) continue normally in the presence of a unrecognized_name warning alert. From that point of view OpenJDK should too. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From sean.mullan at oracle.com Mon Nov 16 21:52:13 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 16 Nov 2015 16:52:13 -0500 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <564A3251.8080006@telenet.be> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> <564A3251.8080006@telenet.be> Message-ID: <564A500D.3060504@oracle.com> On 11/16/2015 02:45 PM, Glen Vermeylen wrote: > Thank you all very much for your comments, > > No, SunPKCS11 is the only class we touch directly. > For your information, we store the pkcs.cfg contents in an xml > configuration, so we call the constructor SunPKCS11(Inputstream). I > assume in the example below p.configure(InputStream) would also work? No, currently it only takes a String, which is the filename in this case. How did your xml configuration work? The SunPKCS11 provider only understands the format as specified in http://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html#Config > If I understand correctly, we cannot really anticipate the > sun.x-encapsulation in jdk9? For the moment we just need to keep using > SunPKCS11 and migrate to the code below when releasing for java 9? Correct. --Sean > > Many thanks, > Glen > > Op 16/11/2015 om 16:46 schreef Sean Mullan: >> Additionally, in JDK 9 we have added a new configure method to the >> java.security.Provider class that allows you to configure an underlying >> provider with an additional argument. The SunPKCS11 implementation has >> been enhanced to support this method. >> >> So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 >> constructor to pass in a configuration file, you can now do the >> following: >> >> Provider p = Security.getProvider("SunPKCS11"); >> p.configure("/opt/bar/cfg/pkcs11.cfg"); >> >> We will update section 2.2 of the PKCS11 guide for JDK 9 to note this >> new usage. I believe that is the only section of the guide that >> discusses using an internal class directly. >> >> Are there any other internal PKCS11 classes you are using directly, and >> if so why? >> >> --Sean >> >> On 11/16/2015 10:30 AM, Vincent Ryan wrote: >>> Hello Glen, >>> >>> JCE providers are always accessed via the Java SE public APIs and not >>> directly via sun.* implementation classes. >>> In JDK 9, the SunPKCS11 provider continues to be accessible via those >>> APIs. It?s implementation classes are present >>> in the jdk.crypto.pkcs11 module. >>> >>> Thanks. >>> >>> >>>> On 16 Nov 2015, at 15:21, Chris Hegarty >>>> wrote: >>>> >>>> Including the security-dev mailing list. >>>> >>>> -Chris. >>>> >>>> On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: >>>>> In the Devoxx presentation "Prepare for JDK9", the strategy for >>>>> encapsulating "sun.* " packages is discussed. >>>>> The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of >>>>> JDK-internal APIs"), but as the rest of sun.security.* is listed as >>>>> "Non-critical, no replacement planned", will this also be case for >>>>> SunPKCS11? >>>>> As far as I know there is no alternative security Provider for >>>>> integrating with PKCS11 aside from rolling your own jni code or using >>>>> vendor-specific apis. >>>>> >>>>> We rely on SunPKCS for interfacing with an HSM and belgian e-id >>>>> smartcard. And even though we are aware that touching sun.* is frowned >>>>> upon, first search hit on "java pkcs11" gives following page: >>>>> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html >>>>> >>>>> >>>>> . With such elaborate documentation, you can't really blame devs to >>>>> actually use this functionality :) . >>>>> >>>>> Is there an alternative to SunPKCS11 or am I overlooking something? >>>>> >>>>> Thanks for your response, >>>>> Glen Vermeylen >>> > From glen.vermeylen at telenet.be Mon Nov 16 19:45:21 2015 From: glen.vermeylen at telenet.be (Glen Vermeylen) Date: Mon, 16 Nov 2015 20:45:21 +0100 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649FA48.1060202@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> Message-ID: <564A3251.8080006@telenet.be> Thank you all very much for your comments, No, SunPKCS11 is the only class we touch directly. For your information, we store the pkcs.cfg contents in an xml configuration, so we call the constructor SunPKCS11(Inputstream). I assume in the example below p.configure(InputStream) would also work? If I understand correctly, we cannot really anticipate the sun.x-encapsulation in jdk9? For the moment we just need to keep using SunPKCS11 and migrate to the code below when releasing for java 9? Many thanks, Glen Op 16/11/2015 om 16:46 schreef Sean Mullan: > Additionally, in JDK 9 we have added a new configure method to the > java.security.Provider class that allows you to configure an underlying > provider with an additional argument. The SunPKCS11 implementation has > been enhanced to support this method. > > So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 > constructor to pass in a configuration file, you can now do the following: > > Provider p = Security.getProvider("SunPKCS11"); > p.configure("/opt/bar/cfg/pkcs11.cfg"); > > We will update section 2.2 of the PKCS11 guide for JDK 9 to note this > new usage. I believe that is the only section of the guide that > discusses using an internal class directly. > > Are there any other internal PKCS11 classes you are using directly, and > if so why? > > --Sean > > On 11/16/2015 10:30 AM, Vincent Ryan wrote: >> Hello Glen, >> >> JCE providers are always accessed via the Java SE public APIs and not >> directly via sun.* implementation classes. >> In JDK 9, the SunPKCS11 provider continues to be accessible via those >> APIs. It?s implementation classes are present >> in the jdk.crypto.pkcs11 module. >> >> Thanks. >> >> >>> On 16 Nov 2015, at 15:21, Chris Hegarty >>> wrote: >>> >>> Including the security-dev mailing list. >>> >>> -Chris. >>> >>> On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: >>>> In the Devoxx presentation "Prepare for JDK9", the strategy for >>>> encapsulating "sun.* " packages is discussed. >>>> The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of >>>> JDK-internal APIs"), but as the rest of sun.security.* is listed as >>>> "Non-critical, no replacement planned", will this also be case for >>>> SunPKCS11? >>>> As far as I know there is no alternative security Provider for >>>> integrating with PKCS11 aside from rolling your own jni code or using >>>> vendor-specific apis. >>>> >>>> We rely on SunPKCS for interfacing with an HSM and belgian e-id >>>> smartcard. And even though we are aware that touching sun.* is frowned >>>> upon, first search hit on "java pkcs11" gives following page: >>>> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html >>>> >>>> . With such elaborate documentation, you can't really blame devs to >>>> actually use this functionality :) . >>>> >>>> Is there an alternative to SunPKCS11 or am I overlooking something? >>>> >>>> Thanks for your response, >>>> Glen Vermeylen >> -- Glen Vermeylen Schavotstraat 42 3130 Begijnendijk gsm: 0496521981 From weijun.wang at oracle.com Tue Nov 17 01:00:07 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 Nov 2015 09:00:07 +0800 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <5649FA48.1060202@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> Message-ID: <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> > On Nov 16, 2015, at 11:46 PM, Sean Mullan wrote: > > Provider p = Security.getProvider("SunPKCS11"); > p.configure("/opt/bar/cfg/pkcs11.cfg"); p = p.configure("/opt/bar/cfg/pkcs11.cfg"); The spec for the method says: * Apply the supplied configuration argument to this provider instance * and return the configured provider. Note that if this provider cannot * be configured in-place, a new provider will be created and returned. * Therefore, callers should always use the returned provider. --Max From amanda.jiang at oracle.com Tue Nov 17 07:03:36 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Mon, 16 Nov 2015 23:03:36 -0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> Message-ID: <564AD148.4050401@oracle.com> Hi Max, Thanks for reviewing the webrev, below is another updated webrev which contains fixes for all your comments, please let me know if you have any other suggestions. http://cr.openjdk.java.net/~amjiang/8048357/webrev.03/ Thanks, Amanda On 15/11/15 ??11:41, Wang Weijun wrote: > Why "othervm" for all these tests? > > PKCS10AttrOrder.java: > > - Is sun.security.provider and sun.misc used anywhere? You have them in @modules. > > - sun.security.pkcs.PKCS9Attribute contains public constants like CONTENT_TYPE_OID, SIGNING_TIME_OID, CHALLENGE_PASSWORD_OID. You can directly use them. Same as PKCS10AttributeReader.java. > > - What does "order" mean in the test name? PKCS10 Attributes is a Set, therefore there is no order. > > - You print out "List of attributes in constructed PKCS10 request: " but I see no content. > > - checkAttributes() ensures every attribute in the encoded PKCS10 has the correct value. But you haven't checked if all entries in constructedMap are encoded. Maybe compare the size? > > PKCS10AttributeReader.java: > > - sun.misc in @modules? > > - Line 45: .asn1 -> asn.1 > > - Please also compare the size of RequestStander and eReq. > > PKCS8Test.java: > > - sun.security.x509 in @modules? This test uses "sun.misc.HexDumpEncoder", so that's why security.x509 is in @modules. > > - Line 206: Dump encodedKey here? Seems too late. Why not do it before the check or at least before raiseException? Same with the other 4 debug outputs after raiseException. > > - EXPECTED_ALG_ID_CHRS can be just a String with \n and \t inside. > > pkcs7/*.java: > > Please take a look at Bernd Eckenfels's comments on Aug 21. I fully agree with him. > > Thanks > Max > > ---- > >> On Nov 13, 2015, at 4:57 PM, Amanda Jiang wrote: >> >> Hi Max, >> >> Please check the updated webrev which address your comments, please let me know if you have any other suggestions. >> http://cr.openjdk.java.net/~amjiang/8048357/webrev.02/ >> >> Thanks, >> Amanda >> >> On 15/8/21 ??12:13, Weijun Wang wrote: >>> PKCS10AttrOrder.java: >>> >>> - Why not inline revAttributes(), prov() and constructMap()? They are only used once. Putting the content into the main method is more clear. >>> >>> - You can create separate method for the while look checks. The 2 look identical. >>> >>> PKCS10AttributeReader.java: >>> >>> - Is it OK to indent the data in the comment to multiple levels? >>> >>> - Again, initMap() not necessary. >>> >>> PKCS7VerifyTest.java: >>> >>> - Not sure what this is for. The 1st and 2nd argument of the @run line are the same? >> those 3 arguments are actually for two different test cases, I use two @run tags in updated webrev and add some comments in test to make it clear. >>> SignerOrder.java: >>> >>> - Comment on what derString1 and derString1 are. >>> >>> - What do you expect verifs1.length and verifs2.length to be? Will you also check it? >> Yes I do check verifs1.length and verifs2.length should be same. >> 121 if (verifs1.length != verifs2.length) { >> 122 throw new RuntimeException("Length or Original vs read-in " >> 123 + "should be same"); >> 124 } >> >> >> >>> PKCS8Test.java: >>> >>> - Typo: s/recieved/received/g >>> >>> Thanks >>> Max >>> >>> On 08/21/2015 07:11 AM, Amanda Jiang wrote: >>>> Hi All, >>>> >>>> Please be free to review new tests for conformance testing of PKCS. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8048357 >>>> webrev: http://cr.openjdk.java.net/~amjiang/8048357/webrev.01/ >>>> >>>> Thanks, >>>> Amanda >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue Nov 17 07:55:43 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Nov 2015 15:55:43 +0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <564AD148.4050401@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> <564AD148.4050401@oracle.com> Message-ID: <564ADD7F.1040806@oracle.com> Hi Amanda On 11/17/2015 15:03, Amanda Jiang wrote: > http://cr.openjdk.java.net/~amjiang/8048357/webrev.03/ > >> Why "othervm" for all these tests? The pkcs10 and pkcs8 tests still uses othervm. Is that necessary? I see no VM static change made by these tests. >> PKCS8Test.java: >> >> - sun.security.x509 in @modules? > This test uses "sun.misc.HexDumpEncoder", so that's why security.x509 is > in @modules. I was asking about sun.security.x509, not sun.misc. >> >> pkcs7/*.java: >> >> Please take a look at Bernd Eckenfels's comments on Aug 21. I fully agree with him. In PKCS7VerifyTest.java, you are still using is.available() to get the size of FILEPATH + args[1]. In SignerOrder.java, can you explain what the contents of derString1 and derString2 means? You seem to be choosing some specially crafted DER-encoded bytes but I don't know the reason. The names and the contents just keep me guessing what they are. Everything else is fine. Thanks Max From sean.mullan at oracle.com Tue Nov 17 14:15:22 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Nov 2015 09:15:22 -0500 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> <6AD76F3D-A16A-464C-9A03-35A1046C3301@oracle.com> Message-ID: <564B367A.4010908@oracle.com> On 11/16/2015 08:00 PM, Wang Weijun wrote: > >> On Nov 16, 2015, at 11:46 PM, Sean Mullan wrote: >> >> Provider p = Security.getProvider("SunPKCS11"); >> p.configure("/opt/bar/cfg/pkcs11.cfg"); > > p = p.configure("/opt/bar/cfg/pkcs11.cfg"); > > The spec for the method says: > > * Apply the supplied configuration argument to this provider instance > * and return the configured provider. Note that if this provider cannot > * be configured in-place, a new provider will be created and returned. > * Therefore, callers should always use the returned provider. Yes, thanks for the correction. --Sean From weijun.wang at oracle.com Tue Nov 17 14:10:40 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 17 Nov 2015 22:10:40 +0800 Subject: RFR 8143138: Move sun/security/pkcs11/Secmod/LoadKeystore.java to problem list Message-ID: Hi All The test has failed a lot recently. Please review the change: diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -234,6 +234,7 @@ sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java generic-all # 8077138: Some PKCS11 tests fail because NSS library is not initialized +# 8023434: NSS initialization failed sun/security/pkcs11/Cipher/ReinitCipher.java windows-all sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java windows-all sun/security/pkcs11/Cipher/TestRSACipher.java windows-all @@ -263,6 +264,7 @@ sun/security/pkcs11/Secmod/Crypto.java windows-all sun/security/pkcs11/Secmod/GetPrivateKey.java windows-all sun/security/pkcs11/Secmod/JksSetPrivateKey.java windows-all +sun/security/pkcs11/Secmod/LoadKeystore.java windows-all sun/security/pkcs11/SecureRandom/Basic.java windows-all sun/security/pkcs11/SecureRandom/TestDeserialization.java windows-all sun/security/pkcs11/Serialize/SerializeProvider.java windows-all As you can see, there are already a lot of similar tests there. They are probably related and we should investigate them together. Thanks Max From sean.mullan at oracle.com Tue Nov 17 14:20:09 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 17 Nov 2015 09:20:09 -0500 Subject: RFR 8143138: Move sun/security/pkcs11/Secmod/LoadKeystore.java to problem list In-Reply-To: References: Message-ID: <564B3799.7070707@oracle.com> On 11/17/2015 09:10 AM, Wang Weijun wrote: > Hi All > > The test has failed a lot recently. Please review the change: > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -234,6 +234,7 @@ > sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java generic-all > > # 8077138: Some PKCS11 tests fail because NSS library is not initialized > +# 8023434: NSS initialization failed > sun/security/pkcs11/Cipher/ReinitCipher.java windows-all > sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java windows-all > sun/security/pkcs11/Cipher/TestRSACipher.java windows-all > @@ -263,6 +264,7 @@ > sun/security/pkcs11/Secmod/Crypto.java windows-all > sun/security/pkcs11/Secmod/GetPrivateKey.java windows-all > sun/security/pkcs11/Secmod/JksSetPrivateKey.java windows-all > +sun/security/pkcs11/Secmod/LoadKeystore.java windows-all > sun/security/pkcs11/SecureRandom/Basic.java windows-all > sun/security/pkcs11/SecureRandom/TestDeserialization.java windows-all > sun/security/pkcs11/Serialize/SerializeProvider.java windows-all > > As you can see, there are already a lot of similar tests there. They are probably related and we should investigate them together. Looks good. Can you add a noreg label to the bug? --Sean From christoph.langer at sap.com Tue Nov 17 16:47:54 2015 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Nov 2015 16:47:54 +0000 Subject: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data In-Reply-To: <266F3E24-7DBB-4A65-A7D4-26251234F2F0@oracle.com> References: <0DFD2E72402C9243A8630A7759B27E4338F21D7B@DEWDFEMB12B.global.corp.sap> <561D9EDE.1020408@comcast.net> <0DFD2E72402C9243A8630A7759B27E4338F2429F@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F4F0E6@DEWDFEMB12B.global.corp.sap> <56427234.3070502@comcast.net> <8CB85EC2-4C79-4B0B-8DD5-5BE8B947718C@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FB5E@DEWDFEMB12B.global.corp.sap> <03CC87D1-B8E3-49E0-B7F1-FC3D4332BC49@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F4FBA9@DEWDFEMB12B.global.corp.sap> <4A31C2CA-26A7-48E0-B6A8-20C8BA113C58@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F51B1E@DEWDFEMB12B.global.corp.sap> <516C08BE-ED9C-4CC7-82CF-F32F49649F16@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F522A6@DEWDFEMB12B.global.corp.sap> <19A6F0B2-80F3-4F71-B53C-31A67309D0C4@oracle.com> <0DFD2E72402C9243A8630A7759B27E4338F52ADD@DEWDFEMB12B.global.corp.sap> <0DFD2E72402C9243A8630A7759B27E4338F53767@DEWDFEMB12B.global.corp.sap> <6C06A60E-9186-47AC-9477-2BC55D3173EF@oracle.com> <646F8B0E-8D6A-405A-A22C-F2FCD9EE2EB3@oracle.com> <266F3E24-7DBB-4A65-A7D4-26251234F2F0@oracle.com> Message-ID: <0DFD2E72402C9243A8630A7759B27E4338F55A1F@DEWDFEMB12B.global.corp.sap> Vincent, Max, can you push the change now? Just don't want that it gets forgotten... Thanks Christoph -----Original Message----- From: Wang Weijun [mailto:weijun.wang at oracle.com] Sent: Montag, 16. November 2015 08:32 To: Vincent Ryan Cc: Langer, Christoph ; security-dev at openjdk.java.net Subject: Re: RFR 8139436: sun.security.mscapi.KeyStore might load incomplete data > On Nov 16, 2015, at 3:19 PM, Vincent Ryan wrote: > > Yes the source changes look fine. > Last week I ran the tests using webrev.4 and all passed. FYI: webrev.6 also pass. --Max > > Thanks Christoph for the comprehensive fix. From weijun.wang at oracle.com Wed Nov 18 06:23:29 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 Nov 2015 14:23:29 +0800 Subject: RFR 8130132: jarsigner should emit warning if weak algorithms or keysizes are used Message-ID: <2D1CF9E3-7E69-4577-84F8-9CCEE1DB207D@oracle.com> Hi All Please take a look at http://cr.openjdk.java.net/~weijun/8130132/webrev.00/ These new warnings will be added to jarsigner: The signer's certificate is self-signed. This jar contains entries whose signer certificate is self-signed. The %1$s algorithm used as %2$s is considered a security risk. For the last one, %1#s is the algorithm name (For example, MD5), %2#s is the option name which is one of "-digestalg", "-sigalg", and "-tsadigestalg". Also, two existing warning messages The signer's certificate chain is not validated. This jar contains entries whose certificate chain is not validated. will be updated to The signer's certificate chain is not validated. Reason: %s This jar contains entries whose certificate chain is not validated. Reason: %s where %s will be the getLocalizedMessage() value of the exception caught in certificate chain validation. Thanks Max From weijun.wang at oracle.com Wed Nov 18 06:53:49 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 18 Nov 2015 14:53:49 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <560A7FCF.1070502@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <560A7FCF.1070502@oracle.com> Message-ID: Hi All An updated webrev is available at http://cr.openjdk.java.net/~weijun/8056174/webrev.06/ Compared with webrev.05, these changes are made: 1. In AlgorithmId.java, getDefaultSigAlgForKey() looks at the key size and returns signature algorithms with different digest part. Thanks, Mike! 2. In JarSigner.java: - method names are longer, sigAlg() is now signatureAlgorithm(). Thanks, Mandy! - a new eventHandler() setter, so caller can show the progress of signing - value in setProperty(key, value) is only String now. No need to care about cloning The change in the root idk repo is still diff --git a/modules.xml b/modules.xml --- a/modules.xml +++ b/modules.xml @@ -1704,12 +1704,15 @@ jdk.jartool java.base com.sun.jarsigner + + jdk.security.jarsigner + Thanks Max From sean.mullan at oracle.com Wed Nov 18 13:32:12 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Nov 2015 08:32:12 -0500 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> Message-ID: <564C7DDC.6000902@oracle.com> A few more comments - The name of the new interface should be SecureRandomParameterSpec instead of SecureRandomSpec. The getInstance methods can now take a SecureRandomParameterSpec object (rather than an AlgorithmParameterSpec). They should throw InvalidAlgorithmParameterException (not IllegalArgumentException) if the parameters are null or not the right type to be consistent with other Spi classes. You will also need to add a protected (or public?) constructor to SecureRandomSpi that takes a SecureRandomParameterSpec parameter. CertStoreSpi is a good example to follow. DrbgSpec should really be named DrbgParameterSpec to be consistent with other AlgorithmParameterSpec subclasses. nextBytes should throw NPE if bytes is null. I also think it should not allow additionalInput to be null (should throw NPE), because this is an overloaded method. If the caller doesn't want to specify additionalInput, then it should call nextBytes(byte[]). I would prefer 2 reseed methods, one that didn't take any arguments, and one that takes an additionalInput (and throws NPE if it is null): public void reseed() public void reseed(byte[] additionalInput) This avoids code having to always do this in the (likely) common case where additionalInput is not specified: sr.reseed(null); In SecureRandomSpi, I think there is a typo: engineGenerate should be named engineNextBytes, and it should be protected (not public). I think the new methods in SecureRandomSpi need a default impl and it should be specified. They should probably throw UnsupportedOperationExc by default. If so, this should be added in @throws clause and default behavior documented in an @implSpec. I still need to review the EntropyInput and DrbgSpec classes ... Thanks, Sean On 11/13/2015 08:43 PM, Wang Weijun wrote: > >> On 2015?11?14?, at ??1:56, Sean Mullan wrote: >> >> On 11/12/2015 07:58 PM, Wang Weijun wrote: >>>> What happens if configure is called more than once, or >>>> simultaneously by more than one thread? >>> The state is reset. The last one rules. The implementation can be >>> made synchronized. >>> >>> * This method can be called multiple times. After each call, this * >>> {@code SecureRandom} object must be reseeded. >>> >>>>> >>>>> Instead of a configure method, I would suggest adding new >>>>> getInstance methods that take an AlgorithmParameterSpec. This >>>>> should simplify the implementation. >>> getInstance() has 3 flavors, (), (String) and (Provider). Too many >>> new methods to add. >> >> Only 3 more. It would seem to make the implementation simpler, less state and synchronization to worry about. > > OK. > >> >>>>> I also think it might be cleaner and simpler to make EntropyInput >>>>> an input parameter of DrbgSpec so that you could have a single >>>>> AlgorithmParameterSpec parameter (instead of an AlgParamSpec and >>>>> EntropyInput) for the getInstance method. >>> EntropyInput as a separated parameter means it applies to other >>> SecureRandom implementations and not only DRBG. For example, SHA1PRNG >>> can also have a specified entropy source. It is also useful to >>> describe what reSeed() means. >> >> Ok but it's really just an input parameter, right? >> >> Maybe, you want something like: >> >> public interface SecureRandomSpec extends AlgorithmParameterSpec { >> >> EntropyInput getEntropyInput(); >> } >> >> public class DrbgSpec implements SecureRandomSpec { >> >> } > > Sound good. > > I'll update the APIs. > > Thanks > Max > >> >> --Sean > From sean.mullan at oracle.com Wed Nov 18 18:40:28 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 18 Nov 2015 13:40:28 -0500 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <560A7FCF.1070502@oracle.com> Message-ID: <564CC61C.80500@oracle.com> Looks good, just a couple of minor comments: In JarSigner.Builder.getDefaultSignatureAlgorithm, change the word "bigger" to "greater than". In AlgorithmId.getDefaultSigAlgForKey, I think you can remove the last sentence ("Remember ...") - this seems like a ToDo note to yourself which has been done. --Sean On 11/18/2015 01:53 AM, Wang Weijun wrote: > Hi All > > An updated webrev is available at > > http://cr.openjdk.java.net/~weijun/8056174/webrev.06/ > > Compared with webrev.05, these changes are made: > > 1. In AlgorithmId.java, getDefaultSigAlgForKey() looks at the key size and returns signature algorithms with different digest part. Thanks, Mike! > > 2. In JarSigner.java: > > - method names are longer, sigAlg() is now signatureAlgorithm(). Thanks, Mandy! > > - a new eventHandler() setter, so caller can show the progress of signing > > - value in setProperty(key, value) is only String now. No need to care about cloning > > The change in the root idk repo is still > > diff --git a/modules.xml b/modules.xml > --- a/modules.xml > +++ b/modules.xml > @@ -1704,12 +1704,15 @@ > > jdk.jartool > java.base > > com.sun.jarsigner > > + > + jdk.security.jarsigner > + > > > Thanks > Max > From weijun.wang at oracle.com Thu Nov 19 02:54:26 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Nov 2015 10:54:26 +0800 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: <564CC61C.80500@oracle.com> References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <560A7FCF.1070502@oracle.com> <564CC61C.80500@oracle.com> Message-ID: > On Nov 19, 2015, at 2:40 AM, Sean Mullan wrote: > > Looks good, just a couple of minor comments: > > In JarSigner.Builder.getDefaultSignatureAlgorithm, change the word "bigger" to "greater than". Updated. > > In AlgorithmId.getDefaultSigAlgForKey, I think you can remove the last sentence ("Remember ...") - this seems like a ToDo note to yourself which has been done. It's a reminder if we update it again in the future. It makes me feel a little uncomfortable that the rule is coded inside java.base but the spec is in jdk.jartool, although most likely we don't suggest users mixing modules from different releases. --Max > > --Sean > > On 11/18/2015 01:53 AM, Wang Weijun wrote: >> Hi All >> >> An updated webrev is available at >> >> http://cr.openjdk.java.net/~weijun/8056174/webrev.06/ >> >> Compared with webrev.05, these changes are made: >> >> 1. In AlgorithmId.java, getDefaultSigAlgForKey() looks at the key size and returns signature algorithms with different digest part. Thanks, Mike! >> >> 2. In JarSigner.java: >> >> - method names are longer, sigAlg() is now signatureAlgorithm(). Thanks, Mandy! >> >> - a new eventHandler() setter, so caller can show the progress of signing >> >> - value in setProperty(key, value) is only String now. No need to care about cloning >> >> The change in the root idk repo is still >> >> diff --git a/modules.xml b/modules.xml >> --- a/modules.xml >> +++ b/modules.xml >> @@ -1704,12 +1704,15 @@ >> >> jdk.jartool >> java.base >> >> com.sun.jarsigner >> >> + >> + jdk.security.jarsigner >> + >> >> >> Thanks >> Max >> From sean.mullan at oracle.com Thu Nov 19 12:58:35 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Nov 2015 07:58:35 -0500 Subject: RFR 8056174: New APIs for jar signing In-Reply-To: References: <55DB22A9.40704@oracle.com> <55E54ACC.6020004@oracle.com> <55E8B010.70905@oracle.com> <5600AAE5.3010009@oracle.com> <5600CE49.1020604@oracle.com> <56099499.1020604@oracle.com> <5609CE8F.2020805@oracle.com> <560A7FCF.1070502@oracle.com> <564CC61C.80500@oracle.com> Message-ID: <564DC77B.90604@oracle.com> On 11/18/2015 09:54 PM, Wang Weijun wrote: >> In AlgorithmId.getDefaultSigAlgForKey, I think you can remove the >> last sentence ("Remember ...") - this seems like a ToDo note to >> yourself which has been done. > It's a reminder if we update it again in the future. Ok. > It makes me feel a little uncomfortable that the rule is coded inside > java.base but the spec is in jdk.jartool, although most likely we > don't suggest users mixing modules from different releases. I think it's ok, since the base module must always be present. --Sean From weijun.wang at oracle.com Thu Nov 19 13:41:41 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 19 Nov 2015 21:41:41 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <564C7DDC.6000902@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> Message-ID: > On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote: > > The getInstance methods can now take a SecureRandomParameterSpec object (rather than an AlgorithmParameterSpec). They should throw InvalidAlgorithmParameterException (not IllegalArgumentException) if the parameters are null or not the right type to be consistent with other Spi classes. > > You will also need to add a protected (or public?) constructor to SecureRandomSpi that takes a SecureRandomParameterSpec parameter. CertStoreSpi is a good example to follow. Cool. This is what a JCA engine should look like. So I create a new method like this public static SecureRandom getInstance( String algorithm, SecureRandomParameterSpec spec) throws NoSuchAlgorithmException, InvalidParameterSpecException { Instance instance = GetInstance.getInstance("SecureRandom", SecureRandomSpi.class, algorithm, spec); SecureRandomSpi spi = (SecureRandomSpi)instance.impl; SecureRandom r = new SecureRandom(spi, instance.provider, algorithm); return r; } However, I cannot get it working, and I found difficulties understanding the EngineDescription inner class inside Provider.java. 1. For each engine that can take an extra parameter (not provider) in getInstance(), it is always named XyzParameters, not an AlgorithmParameterSpec. 2. For each of these, if you have getInstance(alg, params), there is no getInstance(alg). Obviously, for SecureRandom we need to have both. 3. Not sure what EngineDescription.supportsParameter means. Seems only useful for those needing a key. So, it seems I'll have to write the method like public static SecureRandom getInstance( String algorithm, SecureRandomParameterSpec spec) throws NoSuchAlgorithmException, InvalidParameterSpecException { Instance instance = GetInstance.getInstance("SecureRandom", SecureRandomSpi.class, algorithm); SecureRandomSpi spi = (SecureRandomSpi)instance.iml; spi.engineConfigure(spec); SecureRandom r = new SecureRandom(spi, instance.provider, algorithm); return r; } which means although configure() is not in SecureRandom, it still must be in SecureRandomSpi, and there won't be a SecureRandomSpi constructor that takes a SecureRandomParameterSpec parameter. Am I doing something wrong? Thanks Max From sean.mullan at oracle.com Thu Nov 19 17:11:04 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 19 Nov 2015 12:11:04 -0500 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> Message-ID: <564E02A8.5060402@oracle.com> On 11/19/2015 08:41 AM, Wang Weijun wrote: > >> On Nov 18, 2015, at 9:32 PM, Sean Mullan wrote: >> >> The getInstance methods can now take a SecureRandomParameterSpec object (rather than an AlgorithmParameterSpec). They should throw InvalidAlgorithmParameterException (not IllegalArgumentException) if the parameters are null or not the right type to be consistent with other Spi classes. >> >> You will also need to add a protected (or public?) constructor to SecureRandomSpi that takes a SecureRandomParameterSpec parameter. CertStoreSpi is a good example to follow. > > Cool. This is what a JCA engine should look like. > > So I create a new method like this > > public static SecureRandom getInstance( > String algorithm, SecureRandomParameterSpec spec) > throws NoSuchAlgorithmException, InvalidParameterSpecException { > Instance instance = GetInstance.getInstance("SecureRandom", > SecureRandomSpi.class, algorithm, spec); > SecureRandomSpi spi = (SecureRandomSpi)instance.impl; > SecureRandom r = new SecureRandom(spi, instance.provider, algorithm); > return r; > } The above looks ok. > > However, I cannot get it working, and I found difficulties understanding the EngineDescription inner class inside Provider.java. > > 1. For each engine that can take an extra parameter (not provider) in getInstance(), it is always named XyzParameters, not an AlgorithmParameterSpec. > 2. For each of these, if you have getInstance(alg, params), there is no getInstance(alg). Obviously, for SecureRandom we need to have both. Right, this is the first case where we have both variants of getInstance. > 3. Not sure what EngineDescription.supportsParameter means. Seems only useful for those needing a key. > > So, it seems I'll have to write the method like > > public static SecureRandom getInstance( > String algorithm, SecureRandomParameterSpec spec) > throws NoSuchAlgorithmException, InvalidParameterSpecException { > Instance instance = GetInstance.getInstance("SecureRandom", > SecureRandomSpi.class, algorithm); > SecureRandomSpi spi = (SecureRandomSpi)instance.iml; > spi.engineConfigure(spec); > SecureRandom r = new SecureRandom(spi, instance.provider, algorithm); > return r; > } > > which means although configure() is not in SecureRandom, it still must be in SecureRandomSpi, and there won't be a SecureRandomSpi constructor that takes a SecureRandomParameterSpec parameter. > > Am I doing something wrong? Just looking through the code, it looks like you can change Provider.Service.newInstance() to call the appropriate constructor depending on whether the constructorParameter is null or not. Can you try that? --Sean From amanda.jiang at oracle.com Thu Nov 19 17:55:53 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 19 Nov 2015 09:55:53 -0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <564ADD7F.1040806@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> <564AD148.4050401@oracle.com> <564ADD7F.1040806@oracle.com> Message-ID: <564E0D29.3070205@oracle.com> Hi Max, Please check the webrev below which includes fixes for you previous comments: http://cr.openjdk.java.net/~amjiang/8048357/webrev.05/ Thanks, Amanda On 15/11/16 ??11:55, Weijun Wang wrote: > Hi Amanda > > On 11/17/2015 15:03, Amanda Jiang wrote: >> http://cr.openjdk.java.net/~amjiang/8048357/webrev.03/ >> >>> Why "othervm" for all these tests? > > The pkcs10 and pkcs8 tests still uses othervm. Is that necessary? I > see no VM static change made by these tests. > >>> PKCS8Test.java: >>> >>> - sun.security.x509 in @modules? >> This test uses "sun.misc.HexDumpEncoder", so that's why security.x509 is >> in @modules. > > I was asking about sun.security.x509, not sun.misc. > >>> >>> pkcs7/*.java: >>> >>> Please take a look at Bernd Eckenfels's comments on Aug 21. I fully >>> agree with him. > > In PKCS7VerifyTest.java, you are still using is.available() to get the > size of FILEPATH + args[1]. > > In SignerOrder.java, can you explain what the contents of derString1 > and derString2 means? You seem to be choosing some specially crafted > DER-encoded bytes but I don't know the reason. The names and the > contents just keep me guessing what they are. > > Everything else is fine. > > Thanks > Max From weijun.wang at oracle.com Fri Nov 20 00:23:47 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 08:23:47 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <564E02A8.5060402@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> Message-ID: <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> > On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote: >> >> However, I cannot get it working, and I found difficulties understanding the EngineDescription inner class inside Provider.java. >> >> 1. For each engine that can take an extra parameter (not provider) in getInstance(), it is always named XyzParameters, not an AlgorithmParameterSpec. Shall we also use SecureRandomParameters? > >> 2. For each of these, if you have getInstance(alg, params), there is no getInstance(alg). Obviously, for SecureRandom we need to have both. > > Right, this is the first case where we have both variants of getInstance. > > Just looking through the code, it looks like you can change Provider.Service.newInstance() to call the appropriate constructor depending on whether the constructorParameter is null or not. Can you try that? Good. I'll try. Thanks Max From weijun.wang at oracle.com Fri Nov 20 00:32:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 08:32:50 +0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <564E0D29.3070205@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> <564AD148.4050401@oracle.com> <564ADD7F.1040806@oracle.com> <564E0D29.3070205@oracle.com> Message-ID: <0EDF3FB0-E762-4FF5-B138-3FCD476509BE@oracle.com> Looks fine, but there are TAB characters. Have you run jcheck? remote: test/sun/security/pkcs/pkcs10/PKCS10AttrEncoding.java:29: Tab character remote: test/sun/security/pkcs/pkcs10/PKCS10AttributeReader.java:52: Tab character remote: test/sun/security/pkcs/pkcs7/PKCS7VerifyTest.java:48: Tab character remote: test/sun/security/pkcs/pkcs7/SignerOrder.java:153: Tab character remote: test/sun/security/pkcs/pkcs8/PKCS8Test.java:51: Tab character --Max > On Nov 20, 2015, at 1:55 AM, Amanda Jiang wrote: > > Hi Max, > > Please check the webrev below which includes fixes for you previous comments: > http://cr.openjdk.java.net/~amjiang/8048357/webrev.05/ > > Thanks, > Amanda > > On 15/11/16 ??11:55, Weijun Wang wrote: >> Hi Amanda >> >> On 11/17/2015 15:03, Amanda Jiang wrote: >>> http://cr.openjdk.java.net/~amjiang/8048357/webrev.03/ >>> >>>> Why "othervm" for all these tests? >> >> The pkcs10 and pkcs8 tests still uses othervm. Is that necessary? I see no VM static change made by these tests. >> >>>> PKCS8Test.java: >>>> >>>> - sun.security.x509 in @modules? >>> This test uses "sun.misc.HexDumpEncoder", so that's why security.x509 is >>> in @modules. >> >> I was asking about sun.security.x509, not sun.misc. >> >>>> >>>> pkcs7/*.java: >>>> >>>> Please take a look at Bernd Eckenfels's comments on Aug 21. I fully agree with him. >> >> In PKCS7VerifyTest.java, you are still using is.available() to get the size of FILEPATH + args[1]. >> >> In SignerOrder.java, can you explain what the contents of derString1 and derString2 means? You seem to be choosing some specially crafted DER-encoded bytes but I don't know the reason. The names and the contents just keep me guessing what they are. >> >> Everything else is fine. >> >> Thanks >> Max > From weijun.wang at oracle.com Fri Nov 20 01:12:04 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 09:12:04 +0800 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete In-Reply-To: References: Message-ID: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> Ding dong. > On Nov 9, 2015, at 3:35 PM, Wang Weijun wrote: > > Hi All > > Please review the code change at > > http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ > > JDK-8133151 added support for "#ifdef solaris-sparc" but not "#ifndef solaris-spare". This is fixed and I also added "#else". > > How do I test the change? > > Thanks > Max > From amanda.jiang at oracle.com Fri Nov 20 03:00:27 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Thu, 19 Nov 2015 19:00:27 -0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <0EDF3FB0-E762-4FF5-B138-3FCD476509BE@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> <564AD148.4050401@oracle.com> <564ADD7F.1040806@oracle.com> <564E0D29.3070205@oracle.com> <0EDF3FB0-E762-4FF5-B138-3FCD476509BE@oracle.com> Message-ID: <564E8CCB.3090209@oracle.com> Hi Max, Sorry for the formatting issue, I have removed all TAB characters and ran jcheck on the changeset below, could you please sponsor it? http://cr.openjdk.java.net/~amjiang/8048357/webrev.06/ Thanks, Amanda On 15/11/19 ??4:32, Wang Weijun wrote: > Looks fine, but there are TAB characters. Have you run jcheck? > > remote: test/sun/security/pkcs/pkcs10/PKCS10AttrEncoding.java:29: Tab character > remote: test/sun/security/pkcs/pkcs10/PKCS10AttributeReader.java:52: Tab character > remote: test/sun/security/pkcs/pkcs7/PKCS7VerifyTest.java:48: Tab character > remote: test/sun/security/pkcs/pkcs7/SignerOrder.java:153: Tab character > remote: test/sun/security/pkcs/pkcs8/PKCS8Test.java:51: Tab character > > --Max > >> On Nov 20, 2015, at 1:55 AM, Amanda Jiang wrote: >> >> Hi Max, >> >> Please check the webrev below which includes fixes for you previous comments: >> http://cr.openjdk.java.net/~amjiang/8048357/webrev.05/ >> >> Thanks, >> Amanda >> >> On 15/11/16 ??11:55, Weijun Wang wrote: >>> Hi Amanda >>> >>> On 11/17/2015 15:03, Amanda Jiang wrote: >>>> http://cr.openjdk.java.net/~amjiang/8048357/webrev.03/ >>>> >>>>> Why "othervm" for all these tests? >>> The pkcs10 and pkcs8 tests still uses othervm. Is that necessary? I see no VM static change made by these tests. >>> >>>>> PKCS8Test.java: >>>>> >>>>> - sun.security.x509 in @modules? >>>> This test uses "sun.misc.HexDumpEncoder", so that's why security.x509 is >>>> in @modules. >>> I was asking about sun.security.x509, not sun.misc. >>> >>>>> pkcs7/*.java: >>>>> >>>>> Please take a look at Bernd Eckenfels's comments on Aug 21. I fully agree with him. >>> In PKCS7VerifyTest.java, you are still using is.available() to get the size of FILEPATH + args[1]. >>> >>> In SignerOrder.java, can you explain what the contents of derString1 and derString2 means? You seem to be choosing some specially crafted DER-encoded bytes but I don't know the reason. The names and the contents just keep me guessing what they are. >>> >>> Everything else is fine. >>> >>> Thanks >>> Max From weijun.wang at oracle.com Fri Nov 20 03:47:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Nov 2015 11:47:50 +0800 Subject: RFR 8048357: PKCS basic tests In-Reply-To: <564E8CCB.3090209@oracle.com> References: <55D65EA4.60905@oracle.com> <55D6CF87.807@oracle.com> <5645A5F7.1070109@oracle.com> <1EDF0974-5372-4F24-A8E0-3A036D146F09@oracle.com> <564AD148.4050401@oracle.com> <564ADD7F.1040806@oracle.com> <564E0D29.3070205@oracle.com> <0EDF3FB0-E762-4FF5-B138-3FCD476509BE@oracle.com> <564E8CCB.3090209@oracle.com> Message-ID: <1B0DC786-A21C-4227-8146-D1B97A5DB2E2@oracle.com> Done at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c071ebc7f3bf Thanks Max > On Nov 20, 2015, at 11:00 AM, Amanda Jiang wrote: > > Hi Max, > > Sorry for the formatting issue, I have removed all TAB characters and ran jcheck on the changeset below, could you please sponsor it? > http://cr.openjdk.java.net/~amjiang/8048357/webrev.06/ > > Thanks, > Amanda From sean.mullan at oracle.com Fri Nov 20 15:26:29 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Nov 2015 10:26:29 -0500 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> Message-ID: <564F3BA5.7020103@oracle.com> On 11/19/2015 07:23 PM, Wang Weijun wrote: >> On Nov 20, 2015, at 1:11 AM, Sean Mullan wrote: >>> >> >>> >>However, I cannot get it working, and I found difficulties understanding the EngineDescription inner class inside Provider.java. >>> >> >>> >>1. For each engine that can take an extra parameter (not provider) in getInstance(), it is always named XyzParameters, not an AlgorithmParameterSpec. > Shall we also use SecureRandomParameters? If we leave it as a subinterface of AlgorithmParameterSpec, then it should be named SecureRandomParameterSpec to align with the naming convention of the current subclasses. That said, is there any critical reason it needs to be an AlgorithmParameterSpec? If not, then we could just create a standalone SecureRandomParameters interface. --Sean From glen.vermeylen at telenet.be Tue Nov 17 05:20:15 2015 From: glen.vermeylen at telenet.be (Glen Vermeylen) Date: Tue, 17 Nov 2015 06:20:15 +0100 Subject: JEP260 -- Impact on SunPKCS11? In-Reply-To: <564A500D.3060504@oracle.com> References: <1186702340.221364065.1447675995947.JavaMail.root@telenet.be> <5649F46F.6070902@oracle.com> <530E5C8A-F233-4C59-A212-AB107F6C69C5@oracle.com> <5649FA48.1060202@oracle.com> <564A3251.8080006@telenet.be> <564A500D.3060504@oracle.com> Message-ID: <564AB90F.3080807@telenet.be> The xml just contains the literal contents of the .cfg file, we then pass this string through a ByteArrayInputstream to the constructor, like following sample code: final String pkcs11Config = "name=eIDCard\nlibrary=C:/Windows/System32/beidpkcs11.dll" + "\nslotListIndex=0" + "\nshowInfo=true"; final SunPKCS11 eidPkcs = new SunPKCS11(new ByteArrayInputStream(pkcs11Config.getBytes())); regards, Op 16/11/2015 om 22:52 schreef Sean Mullan: > On 11/16/2015 02:45 PM, Glen Vermeylen wrote: >> Thank you all very much for your comments, >> >> No, SunPKCS11 is the only class we touch directly. >> For your information, we store the pkcs.cfg contents in an xml >> configuration, so we call the constructor SunPKCS11(Inputstream). I >> assume in the example below p.configure(InputStream) would also work? > > No, currently it only takes a String, which is the filename in this case. > > How did your xml configuration work? The SunPKCS11 provider only > understands the format as specified in > http://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html#Config > > >> If I understand correctly, we cannot really anticipate the >> sun.x-encapsulation in jdk9? For the moment we just need to keep using >> SunPKCS11 and migrate to the code below when releasing for java 9? > > Correct. > > --Sean > >> >> Many thanks, >> Glen >> >> Op 16/11/2015 om 16:46 schreef Sean Mullan: >>> Additionally, in JDK 9 we have added a new configure method to the >>> java.security.Provider class that allows you to configure an underlying >>> provider with an additional argument. The SunPKCS11 implementation has >>> been enhanced to support this method. >>> >>> So, instead of depending on the internal sun.security.pkcs11.SunPKCS11 >>> constructor to pass in a configuration file, you can now do the >>> following: >>> >>> Provider p = Security.getProvider("SunPKCS11"); >>> p.configure("/opt/bar/cfg/pkcs11.cfg"); >>> >>> We will update section 2.2 of the PKCS11 guide for JDK 9 to note this >>> new usage. I believe that is the only section of the guide that >>> discusses using an internal class directly. >>> >>> Are there any other internal PKCS11 classes you are using directly, and >>> if so why? >>> >>> --Sean >>> >>> On 11/16/2015 10:30 AM, Vincent Ryan wrote: >>>> Hello Glen, >>>> >>>> JCE providers are always accessed via the Java SE public APIs and not >>>> directly via sun.* implementation classes. >>>> In JDK 9, the SunPKCS11 provider continues to be accessible via those >>>> APIs. It?s implementation classes are present >>>> in the jdk.crypto.pkcs11 module. >>>> >>>> Thanks. >>>> >>>> >>>>> On 16 Nov 2015, at 15:21, Chris Hegarty >>>>> wrote: >>>>> >>>>> Including the security-dev mailing list. >>>>> >>>>> -Chris. >>>>> >>>>> On 16/11/15 12:13, glen.vermeylen at telenet.be wrote: >>>>>> In the Devoxx presentation "Prepare for JDK9", the strategy for >>>>>> encapsulating "sun.* " packages is discussed. >>>>>> The class sun.security.SunPkcs11 is not listed on slide 16 ("Uses of >>>>>> JDK-internal APIs"), but as the rest of sun.security.* is listed as >>>>>> "Non-critical, no replacement planned", will this also be case for >>>>>> SunPKCS11? >>>>>> As far as I know there is no alternative security Provider for >>>>>> integrating with PKCS11 aside from rolling your own jni code or using >>>>>> vendor-specific apis. >>>>>> >>>>>> We rely on SunPKCS for interfacing with an HSM and belgian e-id >>>>>> smartcard. And even though we are aware that touching sun.* is >>>>>> frowned >>>>>> upon, first search hit on "java pkcs11" gives following page: >>>>>> https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html >>>>>> >>>>>> >>>>>> >>>>>> . With such elaborate documentation, you can't really blame devs to >>>>>> actually use this functionality :) . >>>>>> >>>>>> Is there an alternative to SunPKCS11 or am I overlooking something? >>>>>> >>>>>> Thanks for your response, >>>>>> Glen Vermeylen >>>> >> -- Glen Vermeylen Schavotstraat 42 3130 Begijnendijk gsm: 0496521981 From basab.misra at gmail.com Thu Nov 19 09:53:13 2015 From: basab.misra at gmail.com (Basabendra Misra) Date: Thu, 19 Nov 2015 15:23:13 +0530 Subject: openjdk 8 & 2048 bit DSA xml signing Message-ID: Hi, It seems there is a fix to support 2048 bit DSA signing in upcoming openjdk 9 release. However , could anyone please guide me what would be the safest way to incorporate the same in openjdk 8? Would really appreciate any help. We're stuck because some CA not offering 1024 bit DSA keys anymore. Thanks & regards, Basabendra Misra +91-9830527802 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Nov 20 21:29:45 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 20 Nov 2015 16:29:45 -0500 Subject: RFR 8130132: jarsigner should emit warning if weak algorithms or keysizes are used In-Reply-To: <2D1CF9E3-7E69-4577-84F8-9CCEE1DB207D@oracle.com> References: <2D1CF9E3-7E69-4577-84F8-9CCEE1DB207D@oracle.com> Message-ID: <564F90C9.4050304@oracle.com> This looks good, just a few comments: KeyStoreUtil: 79 if (!ca.getSubjectDN().equals(end.getIssuerDN())) { Use getSubjectX500Principal instead of getSubjectDN as the DN matching algorithm is more precise. Resources: 246 "The %1$s algorithm used as %2$s is considered a security risk."}, I would add a few more words to this: "The %1$s algorithm specified for the %2$s option is considered a security risk." We should also enhance the jarsigner doc to include these warnings. --Sean On 11/18/2015 01:23 AM, Wang Weijun wrote: > Hi All > > Please take a look at > > http://cr.openjdk.java.net/~weijun/8130132/webrev.00/ > > These new warnings will be added to jarsigner: > > The signer's certificate is self-signed. > This jar contains entries whose signer certificate is self-signed. > The %1$s algorithm used as %2$s is considered a security risk. > > For the last one, %1#s is the algorithm name (For example, MD5), %2#s is the option name which is one of "-digestalg", "-sigalg", and "-tsadigestalg". > > Also, two existing warning messages > > The signer's certificate chain is not validated. > This jar contains entries whose certificate chain is not validated. > > will be updated to > > The signer's certificate chain is not validated. Reason: %s > This jar contains entries whose certificate chain is not validated. Reason: %s > > where %s will be the getLocalizedMessage() value of the exception caught in certificate chain validation. > > Thanks > Max > From anthony.scarpino at oracle.com Fri Nov 20 22:46:57 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 Nov 2015 14:46:57 -0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <564C7DDC.6000902@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> Message-ID: <564FA2E1.8010808@oracle.com> On 11/18/2015 05:32 AM, Sean Mullan wrote: > The getInstance methods can now take a SecureRandomParameterSpec object > (rather than an AlgorithmParameterSpec). They should throw > InvalidAlgorithmParameterException (not IllegalArgumentException) if the > parameters are null or not the right type to be consistent with other > Spi classes. Sorry for backtracking a bit, but when I look at the original proposal by Max, SecureRandom sr = SecureRandom.getInstance("HashDRBG"); hd.configure(new DrbgSpec("SHA-512", -1, true, false, nonce, person), new MyEntropyInput()); I seem something like Cipher, where getInstance is getting the transformation and configure is like Cipher.init(). The contents of DrbgSpec do look like AlgorithmParameters, but in the context during the init. I'm not sure moving all of this into getInstance is consistent with something like Cipher. I'm not sure such things like the algorithm, strength, nonce, etc are right to be set via getInstance(). If it's possible to have limitations in support of a particular DRBG, where it only supported SHA256 but not SHA512 (for example, I don't know the spec), then maybe it does make sense to be a getInstance. In the original design with configure(), was it possible to reconfigure? Or was one to just throw away the instance and get a new one or reset()? > nextBytes should throw NPE if bytes is null. I also think it should > not allow additionalInput to be null (should throw NPE), because this > is an overloaded method. If the caller doesn't want to specify > additionalInput, then it should call nextBytes(byte[]). I don't think there should be a nextBytes(byte[] bytes, byte[] additionalInput). If the user wants to have additionalInput they should use reseed(byte[]) only like you specified below. I think having nextBytes() also doing reseeding is confusing. > I would prefer 2 reseed methods, one that didn't take any arguments, > and one that takes an additionalInput (and throws NPE if it is null): > > public void reseed() > public void reseed(byte[] additionalInput) I agreed. Tony From weijun.wang at oracle.com Sat Nov 21 00:59:01 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 21 Nov 2015 08:59:01 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <564FA2E1.8010808@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564FA2E1.8010808@oracle.com> Message-ID: <222C1002-F6B2-4E01-B045-009C834DC4FD@oracle.com> > On Nov 21, 2015, at 6:46 AM, Anthony Scarpino wrote: > > On 11/18/2015 05:32 AM, Sean Mullan wrote: >> The getInstance methods can now take a SecureRandomParameterSpec object >> (rather than an AlgorithmParameterSpec). They should throw >> InvalidAlgorithmParameterException (not IllegalArgumentException) if the >> parameters are null or not the right type to be consistent with other >> Spi classes. > > Sorry for backtracking a bit, but when I look at the original proposal by Max, > > SecureRandom sr = SecureRandom.getInstance("HashDRBG"); > hd.configure(new DrbgSpec("SHA-512", -1, true, false, > nonce, person), new MyEntropyInput()); > > I seem something like Cipher, where getInstance is getting the transformation and configure is like Cipher.init(). The contents of DrbgSpec do look like AlgorithmParameters, but in the context during the init. I'm not sure moving all of this into getInstance is consistent with something like Cipher. > > I'm not sure such things like the algorithm, strength, nonce, etc are right to be set via getInstance(). If it's possible to have limitations in support of a particular DRBG, where it only supported SHA256 but not SHA512 (for example, I don't know the spec), then maybe it does make sense to be a getInstance. DrbgSpec (or whatever it will be called) is different for different DRBG algorithms. For example, for HashDRBG you specify a hash algorithm like SHA-256, for CtrDRBG, you specific a cipher like AES-256. > > In the original design with configure(), was it possible to reconfigure? Or was one to just throw away the instance and get a new one or reset()? A reconfigure is like a reset because all internal states need to be reconstructed. > > > nextBytes should throw NPE if bytes is null. I also think it should > > not allow additionalInput to be null (should throw NPE), because this > > is an overloaded method. If the caller doesn't want to specify > > additionalInput, then it should call nextBytes(byte[]). > > I don't think there should be a nextBytes(byte[] bytes, byte[] additionalInput). If the user wants to have additionalInput they should use reseed(byte[]) only like you specified below. I think having nextBytes() also doing reseeding is confusing. According to SP 800-90A, this additional input is not about entropy. People might not find this method extra useful but at least it is needed to test the correctness of implementation. CAVP tests include cases for it. That said, I re-read SP 800-90A again and seems there is a feature I haven't supported yet. The full generate function is Generate_function (state_handle, requested_number_of_bits, requested_security_strength, prediction_resistance_request, additional_input): So requested_security_strength and prediction_resistance_request can be specified for each generate call. I think this is useful if people want to use a single SecureRandom object to generate different purposes of random bits. CAVP does not include this case so I haven't noticed this at the beginning. Looks like a nextBytes(bytes, DrbgSpec) can fulfill this purpose. This will also cover the nextBytes(bytes, additionalInput) case. > > > I would prefer 2 reseed methods, one that didn't take any arguments, > > and one that takes an additionalInput (and throws NPE if it is null): > > > > public void reseed() > > public void reseed(byte[] additionalInput) > > I agreed. Thanks Max > > Tony > > From weijun.wang at oracle.com Sat Nov 21 14:00:50 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 21 Nov 2015 22:00:50 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <222C1002-F6B2-4E01-B045-009C834DC4FD@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564FA2E1.8010808@oracle.com> <222C1002-F6B2-4E01-B045-009C834DC4FD@oracle.com> Message-ID: > On Nov 21, 2015, at 8:59 AM, Wang Weijun wrote: > > That said, I re-read SP 800-90A again and seems there is a feature I haven't supported yet. The full generate function is > > Generate_function (state_handle, requested_number_of_bits, requested_security_strength, > prediction_resistance_request, additional_input): > > So requested_security_strength and prediction_resistance_request can be specified for each generate call. I think this is useful if people want to use a single SecureRandom object to generate different purposes of random bits. CAVP does not include this case so I haven't noticed this at the beginning. Read again. For requested_security_strength, the function only needs to check if it is greater than the strength requested at getInstance() (or configure). If yes, fail with "I cannot do that", otherwise, the output will not be downgraded into a lower security strength. For prediction_resistance_request, if it's true, the call is equivalent to reseed(additional_input) plus nextBytes(bytes). Therefore even if a DRBG is created without prediction_resistance, the caller can just call reseed+nextBytes itself. There is no need to add a new nextBytes(bytes,params) method. Thanks Max From weijun.wang at oracle.com Sat Nov 21 14:40:13 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 21 Nov 2015 22:40:13 +0800 Subject: Design review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> Message-ID: > On Nov 20, 2015, at 8:23 AM, Wang Weijun wrote: > >>> 2. For each of these, if you have getInstance(alg, params), there is no getInstance(alg). Obviously, for SecureRandom we need to have both. >> >> Right, this is the first case where we have both variants of getInstance. >> >> Just looking through the code, it looks like you can change Provider.Service.newInstance() to call the appropriate constructor depending on whether the constructorParameter is null or not. Can you try that? > > Good. I'll try. I first made this change - addEngine("SecureRandom", false, null); + addEngine("SecureRandom", false, + "java.security.SecureRandomParameters"); and then update this method private static Object newInstanceUtil(final Class clazz, final Class ctrParamClz, final Object ctorParamObj) throws Exception { if (ctrParamClz == null) { Constructor con = clazz.getConstructor(); return con.newInstance(); } else { - Constructor con = clazz.getConstructor(ctrParamClz); - return con.newInstance(ctorParamObj); + try { + Constructor con = clazz.getConstructor(ctrParamClz); + return con.newInstance(ctorParamObj); + } catch (NoSuchMethodException nsme) { + if (ctorParamObj == null) { + Constructor con = clazz.getConstructor(); + return con.newInstance(); + } else { + throw nsme; + } + } } } For an existing implementation without (SecureRandomParameters), () will be called instead. Thanks Max From weijun.wang at oracle.com Mon Nov 23 07:03:28 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 23 Nov 2015 15:03:28 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> Message-ID: spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/ - No more configure(), it's getInstance(alg, SecureRandomParameters) now. - The *Spec class names are now *Parameters. - Overloaded reseed() and reseed(additionalInput). TBD: Should nextBytes(bytes,additionalInput) throw an UnsupportedOperationException for old implementations? Thanks Max From sibabrata.sahoo at oracle.com Mon Nov 23 13:14:47 2015 From: sibabrata.sahoo at oracle.com (Siba Sahoo) Date: Mon, 23 Nov 2015 05:14:47 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net From: Siba Sahoo Sent: Monday, November 23, 2015 4:56 PM To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Hi, Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ Description Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Mon Nov 23 15:57:53 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 23 Nov 2015 07:57:53 -0800 Subject: JDK 9 RFR of JDK-8143813: Problem list PKCS8Test.java Message-ID: <56533781.7000604@oracle.com> Hello, Please review the patch below to problem list sun/security/pkcs/pkcs8/PKCS8Test.java on Solaris until the underlying issues (JDK-8143377) are addressed. Thanks, -Joe diff -r aa0621638103 test/ProblemList.txt --- a/test/ProblemList.txt Thu Nov 12 16:04:07 2015 -0800 +++ b/test/ProblemList.txt Mon Nov 23 07:57:20 2015 -0800 @@ -217,6 +217,9 @@ # jdk_security +# 8143377 +sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all + # 7157786 sun/security/pkcs11/ec/TestKeyFactory.java generic-all From sean.mullan at oracle.com Mon Nov 23 16:06:48 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 23 Nov 2015 11:06:48 -0500 Subject: JDK 9 RFR of JDK-8143813: Problem list PKCS8Test.java In-Reply-To: <56533781.7000604@oracle.com> References: <56533781.7000604@oracle.com> Message-ID: <56533998.1000304@oracle.com> Looks fine to me. --Sean On 11/23/2015 10:57 AM, joe darcy wrote: > Hello, > > Please review the patch below to problem list > > sun/security/pkcs/pkcs8/PKCS8Test.java > > on Solaris until the underlying issues (JDK-8143377) are addressed. > > Thanks, > > -Joe > > diff -r aa0621638103 test/ProblemList.txt > --- a/test/ProblemList.txt Thu Nov 12 16:04:07 2015 -0800 > +++ b/test/ProblemList.txt Mon Nov 23 07:57:20 2015 -0800 > @@ -217,6 +217,9 @@ > > # jdk_security > > +# 8143377 > +sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all > + > # 7157786 > sun/security/pkcs11/ec/TestKeyFactory.java generic-all > > From weijun.wang at oracle.com Tue Nov 24 01:00:17 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Nov 2015 09:00:17 +0800 Subject: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256 Message-ID: Hi All Please review a code change at http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list. No new regression test, I consider the change trivial. If you think one is better, I'll add it. Thanks Max From magnus.ihse.bursie at oracle.com Tue Nov 24 11:10:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 24 Nov 2015 12:10:05 +0100 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete In-Reply-To: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> References: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> Message-ID: <5654458D.1080705@oracle.com> On 2015-11-20 02:12, Wang Weijun wrote: > Ding dong. Even though this code resides in the make directory, it is not really build code, so I cannot comment on it. /Magnus > >> On Nov 9, 2015, at 3:35 PM, Wang Weijun wrote: >> >> Hi All >> >> Please review the code change at >> >> http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ >> >> JDK-8133151 added support for "#ifdef solaris-sparc" but not "#ifndef solaris-spare". This is fixed and I also added "#else". >> >> How do I test the change? >> >> Thanks >> Max >> From sean.mullan at oracle.com Tue Nov 24 12:15:15 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 24 Nov 2015 07:15:15 -0500 Subject: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256 In-Reply-To: References: Message-ID: <565454D3.4050007@oracle.com> Looks good - although you could replace the MD5 fingerprints with the SHA256 fingerprints in the test files for some additional testing. --Sean On 11/23/2015 08:00 PM, Wang Weijun wrote: > Hi All > > Please review a code change at > > http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ > > SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list. > > No new regression test, I consider the change trivial. If you think one is better, I'll add it. > > Thanks > Max > From weijun.wang at oracle.com Tue Nov 24 14:32:16 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 24 Nov 2015 22:32:16 +0800 Subject: RFR 8143913: MSCAPI keystore should accept Certificate[] in setEntry() Message-ID: <565474F0.9090000@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8143913/webrev.00/ Not everyone passes a X509Certificate[] into KeyStore::setEntry(). Thanks Max From vincent.x.ryan at oracle.com Tue Nov 24 15:48:36 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 24 Nov 2015 15:48:36 +0000 Subject: RFR 8143913: MSCAPI keystore should accept Certificate[] in setEntry() In-Reply-To: <565474F0.9090000@oracle.com> References: <565474F0.9090000@oracle.com> Message-ID: Your fix looks good. Thanks. > On 24 Nov 2015, at 14:32, Weijun Wang wrote: > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8143913/webrev.00/ > > Not everyone passes a X509Certificate[] into KeyStore::setEntry(). > > Thanks > Max From amanda.jiang at oracle.com Tue Nov 24 22:05:43 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 24 Nov 2015 14:05:43 -0800 Subject: RFR 8143377: Test PKCS8Test.java fails Message-ID: <5654DF37.6040608@oracle.com> Hi Max, Could you please review the fixes below for a test bug? Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ Thanks, Amanda From rajan.halade at oracle.com Tue Nov 24 23:13:22 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 24 Nov 2015 15:13:22 -0800 Subject: RFR 8143377: Test PKCS8Test.java fails In-Reply-To: <5654DF37.6040608@oracle.com> References: <5654DF37.6040608@oracle.com> Message-ID: <5654EF12.1050308@oracle.com> Hi Amanda, If you want skip test on solaris, please use - @requires (os.family != "solaris") http://openjdk.java.net/jtreg/tag-spec.html#requires_names Note: I am not a official OpenJDK reviewer. Thanks, Rajan On 11/24/15 2:05 PM, Amanda Jiang wrote: > Hi Max, > > Could you please review the fixes below for a test bug? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 > Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ > > Thanks, > Amanda From rajan.halade at oracle.com Tue Nov 24 23:26:36 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 24 Nov 2015 15:26:36 -0800 Subject: RFR 8143377: Test PKCS8Test.java fails In-Reply-To: <5654EF12.1050308@oracle.com> References: <5654DF37.6040608@oracle.com> <5654EF12.1050308@oracle.com> Message-ID: <5654F22C.4000402@oracle.com> This test was added to ProblemList.txt, please update it to remove the test. - sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all Thanks, Rajan On 11/24/15 3:13 PM, Rajan Halade wrote: > Hi Amanda, > > If you want skip test on solaris, please use - > > @requires (os.family != "solaris") > > http://openjdk.java.net/jtreg/tag-spec.html#requires_names > > Note: I am not a official OpenJDK reviewer. > > Thanks, > Rajan > > On 11/24/15 2:05 PM, Amanda Jiang wrote: >> Hi Max, >> >> Could you please review the fixes below for a test bug? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 >> Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ >> >> Thanks, >> Amanda > From amanda.jiang at oracle.com Tue Nov 24 23:36:38 2015 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 24 Nov 2015 15:36:38 -0800 Subject: RFR 8143377: Test PKCS8Test.java fails In-Reply-To: <5654F22C.4000402@oracle.com> References: <5654DF37.6040608@oracle.com> <5654EF12.1050308@oracle.com> <5654F22C.4000402@oracle.com> Message-ID: <5654F486.7070002@oracle.com> Hi Rajan, Thanks for reviewing, please check the updated changeset: http://cr.openjdk.java.net/~amjiang/8143377/webrev.01/ Thanks, Amanda On 15/11/24 ??3:26, Rajan Halade wrote: > This test was added to ProblemList.txt, please update it to remove the > test. > > - sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all > > Thanks, > Rajan > > On 11/24/15 3:13 PM, Rajan Halade wrote: >> Hi Amanda, >> >> If you want skip test on solaris, please use - >> >> @requires (os.family != "solaris") >> >> http://openjdk.java.net/jtreg/tag-spec.html#requires_names >> >> Note: I am not a official OpenJDK reviewer. >> >> Thanks, >> Rajan >> >> On 11/24/15 2:05 PM, Amanda Jiang wrote: >>> Hi Max, >>> >>> Could you please review the fixes below for a test bug? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 >>> Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ >>> >>> Thanks, >>> Amanda >> > From rajan.halade at oracle.com Tue Nov 24 23:42:24 2015 From: rajan.halade at oracle.com (Rajan Halade) Date: Tue, 24 Nov 2015 15:42:24 -0800 Subject: RFR 8143377: Test PKCS8Test.java fails In-Reply-To: <5654F486.7070002@oracle.com> References: <5654DF37.6040608@oracle.com> <5654EF12.1050308@oracle.com> <5654F22C.4000402@oracle.com> <5654F486.7070002@oracle.com> Message-ID: <5654F5E0.902@oracle.com> Looks good to me, thanks for the updates! Please wait for one official reviewer before you commit. Thanks, Rajan On 11/24/15 3:36 PM, Amanda Jiang wrote: > Hi Rajan, > > Thanks for reviewing, please check the updated changeset: > > http://cr.openjdk.java.net/~amjiang/8143377/webrev.01/ > > > Thanks, > Amanda > > On 15/11/24 ??3:26, Rajan Halade wrote: >> This test was added to ProblemList.txt, please update it to remove >> the test. >> >> - sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all >> >> Thanks, >> Rajan >> >> On 11/24/15 3:13 PM, Rajan Halade wrote: >>> Hi Amanda, >>> >>> If you want skip test on solaris, please use - >>> >>> @requires (os.family != "solaris") >>> >>> http://openjdk.java.net/jtreg/tag-spec.html#requires_names >>> >>> Note: I am not a official OpenJDK reviewer. >>> >>> Thanks, >>> Rajan >>> >>> On 11/24/15 2:05 PM, Amanda Jiang wrote: >>>> Hi Max, >>>> >>>> Could you please review the fixes below for a test bug? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 >>>> Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ >>>> >>>> Thanks, >>>> Amanda >>> >> > From weijun.wang at oracle.com Wed Nov 25 01:44:00 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 25 Nov 2015 09:44:00 +0800 Subject: RFR 8143377: Test PKCS8Test.java fails In-Reply-To: <5654F5E0.902@oracle.com> References: <5654DF37.6040608@oracle.com> <5654EF12.1050308@oracle.com> <5654F22C.4000402@oracle.com> <5654F486.7070002@oracle.com> <5654F5E0.902@oracle.com> Message-ID: <7B47A2CF-735D-4E51-AA1C-704A0E438687@oracle.com> Done. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/33fd40487d6d Thanks Max > On Nov 25, 2015, at 7:42 AM, Rajan Halade wrote: > > Looks good to me, thanks for the updates! > > Please wait for one official reviewer before you commit. > > Thanks, > Rajan > On 11/24/15 3:36 PM, Amanda Jiang wrote: >> Hi Rajan, >> >> Thanks for reviewing, please check the updated changeset: >> >> http://cr.openjdk.java.net/~amjiang/8143377/webrev.01/ >> >> >> Thanks, >> Amanda >> >> On 15/11/24 ??3:26, Rajan Halade wrote: >>> This test was added to ProblemList.txt, please update it to remove the test. >>> >>> - sun/security/pkcs/pkcs8/PKCS8Test.java solaris-all >>> >>> Thanks, >>> Rajan >>> >>> On 11/24/15 3:13 PM, Rajan Halade wrote: >>>> Hi Amanda, >>>> >>>> If you want skip test on solaris, please use - >>>> >>>> @requires (os.family != "solaris") >>>> >>>> http://openjdk.java.net/jtreg/tag-spec.html#requires_names >>>> >>>> Note: I am not a official OpenJDK reviewer. >>>> >>>> Thanks, >>>> Rajan >>>> >>>> On 11/24/15 2:05 PM, Amanda Jiang wrote: >>>>> Hi Max, >>>>> >>>>> Could you please review the fixes below for a test bug? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8143377 >>>>> Webrev: http://cr.openjdk.java.net/~amjiang/8143377/webrev/ >>>>> >>>>> Thanks, >>>>> Amanda >>>> >>> >> > From sean.mullan at oracle.com Wed Nov 25 15:04:36 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 25 Nov 2015 10:04:36 -0500 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete In-Reply-To: <5654458D.1080705@oracle.com> References: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> <5654458D.1080705@oracle.com> Message-ID: <5655CE04.2000004@oracle.com> The fix looks fine to me. For testing, can you create a test that uses a custom java.security file with "#ifndef solaris-sparc" in it, and check whether the property is used or not depending on what system is being tested? --Sean On 11/24/2015 06:10 AM, Magnus Ihse Bursie wrote: > On 2015-11-20 02:12, Wang Weijun wrote: >> Ding dong. > Even though this code resides in the make directory, it is not really > build code, so I cannot comment on it. > > /Magnus > >> >>> On Nov 9, 2015, at 3:35 PM, Wang Weijun wrote: >>> >>> Hi All >>> >>> Please review the code change at >>> >>> http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ >>> >>> JDK-8133151 added support for "#ifdef solaris-sparc" but not "#ifndef >>> solaris-spare". This is fixed and I also added "#else". >>> >>> How do I test the change? >>> >>> Thanks >>> Max >>> > From bradford.wetmore at oracle.com Thu Nov 26 01:18:24 2015 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 25 Nov 2015 17:18:24 -0800 Subject: TLS ALPN Update In-Reply-To: <5613DDBB.9020707@redhat.com> References: <55ED0A6A.3050806@oracle.com> <56053AFA.4000100@redhat.com> <5605421F.8010105@redhat.com> <560557F6.6090107@oracle.com> <56055EBC.9040202@redhat.com> <560566DB.20805@redhat.com> <56057B25.4070103@redhat.com> <560582F4.9000906@redhat.com> <560! 5AD08.9070806@redhat.com> <7CC07DE5-778C-428E-9E02-19E7A883CB23@redhat.com> <5609EBF6.7080306@oracle.com> <560AA924.1050706@redhat.com> <560DD7FE.2060806@oracle.com> <560DED86.5070702@oracle.com> <560F1EF4.4060405@oracle.com> <5613DDBB.9020707@redhat.com> Message-ID: <56565DE0.3060703@oracle.com> On 10/6/2015 7:42 AM, David M. Lloyd wrote: > I didn't reply on this last week, but this looks workable to me. Thanks! Thanks to you guys for all the discussion! During the architectural review, it was pointed out that the SSLParameters.setApplicationProtocols() API proposal with the server-side single array element restriction (i.e. a pre-chosen ALPN value) was unnecessarily limiting, and that we could achieve exactly the same result by removing the single element restriction. For the advanced application cases like those that David/Simone/H2 are concerned about, you still have full control over your environment configuration and eventual ALPN selection. Nothing has changed from earlier: 1. "SSLExplore" the ClientHello 2. obtain specialized SSLContext (if desired) 3. set the enabled protocols, enable/order the ciphersuites, etc. 4. select/set the *single* ALPN value 5. start the handshake 6. X509KeyManagers can look at the selected ALPN value mid-handshake using SSLSocket/SSLEngine.getHandshakeApplicationProtocol(). However, for less-restrictive situations or cases that don't require any connection setup, we follow the ordering language in RFC 7301/3.2: It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol that it supports and that is also advertised by the client. The JSSE implementation is just a simple loop in the server side to select the ALPN value if both sides have values set. Meaning: select TLS protocol select alpn value (loop using server's order) select ciphersuite Changes to the APIs: SSLParameters.setApplicationProtocols(): Removed "no_application_protocol" as a reserved string, and removed the first element restriction. Updated ServerHandshaker as per above. Return value on SSLSocket/SSLEngine.getApplicationProtocol()/getHandshakeApplicationProtocol() is a tri-state: null (not set yet), empty string ("" if no ALPN value is set), or non-empty string (if ALPN was negotiated). wordsmithing/cleanups We have done successful testing with our primary internal consumer: https://bugs.openjdk.java.net/browse/JDK-8042950 JEP 110: HTTP/2. Vinnie will be publishing a full webrev of the API and implementation in the next day or so. Thanks again for everyone's comments and feedback during this process. Except for any bugs found in this webrev, this is what we expect for the initial JEP integration for Feature Complete next week. Cheers, Brad From weijun.wang at oracle.com Thu Nov 26 02:36:09 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 26 Nov 2015 10:36:09 +0800 Subject: RFR 8141690: JDK-8133151 change to MakeJavaSecurity.java is not complete In-Reply-To: <5655CE04.2000004@oracle.com> References: <58FCE11C-3FCF-4CF9-BD85-4A1DF4B724F9@oracle.com> <5654458D.1080705@oracle.com> <5655CE04.2000004@oracle.com> Message-ID: <4D579A3C-316E-4C5F-A45E-6B209AE1D564@oracle.com> > On Nov 25, 2015, at 11:04 PM, Sean Mullan wrote: > > The fix looks fine to me. For testing, can you create a test that uses a custom java.security file with "#ifndef solaris-sparc" in it, and check whether the property is used or not depending on what system is being tested? The tool is inside another repo. I can still write one though. Please take a look at the updated webrev: http://cr.openjdk.java.net/~weijun/8141690/webrev.01/ I also fixed a bug inside MakeJavaSecurity.java. If package.access or package.definition happens to be the last property, an NPE will be thrown. Thanks Max > > --Sean >>>> >>>> http://cr.openjdk.java.net/~weijun/8141690/webrev.00/ >>>> From weijun.wang at oracle.com Thu Nov 26 02:39:55 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 26 Nov 2015 10:39:55 +0800 Subject: RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256 In-Reply-To: <565454D3.4050007@oracle.com> References: <565454D3.4050007@oracle.com> Message-ID: Updated at http://cr.openjdk.java.net/~weijun/8141457/webrev.01/. I was lazy last time. --Max > On Nov 24, 2015, at 8:15 PM, Sean Mullan wrote: > > Looks good - although you could replace the MD5 fingerprints with the SHA256 fingerprints in the test files for some additional testing. > > --Sean > > On 11/23/2015 08:00 PM, Wang Weijun wrote: >> Hi All >> >> Please review a code change at >> >> http://cr.openjdk.java.net/~weijun/8141457/webrev.00/ >> >> SHA-256 is now the default fingerprint algorithm, and MD5 is removed in the full list. >> >> No new regression test, I consider the change trivial. If you think one is better, I'll add it. >> >> Thanks >> Max >> From weijun.wang at oracle.com Thu Nov 26 07:12:21 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 26 Nov 2015 15:12:21 +0800 Subject: RFR 8144107: jdk/security tests not included Message-ID: <466E206F-313F-4395-B9BD-69EC5D240A1B@oracle.com> Please review the fix at http://cr.openjdk.java.net/~weijun/8144107/webrev.00/ The recent JarSigner API changeset includes some tests in jdk/security but the directory is not included in any test group. This fix adds it into jdk_security3. Thanks Max From ecki at zusammenkunft.net Sat Nov 28 19:32:25 2015 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 28 Nov 2015 20:32:25 +0100 Subject: Possible HMAC (PBKDF2) optimization Message-ID: <20151128203225.0000324f.ecki@zusammenkunft.net> Hello, triggered by a talk at Passwordconf'15 by Joseph Birr-Pixton about slow PBKDF2 implementations (where Java was particular bad) https://www.youtube.com/watch?v=k_szwKBuNBw https://bsideslv2015.sched.org/event/3uke/pbkdf2-performance-matters I had a look at the source because I remembered that PBKDF implementation does re-use a initialized HMAC and that HMAC does pre-compute the init vectors. As it turns out, however the HMAC implementation does only pre-compute the padded keys, not the result of the first compression function. This is rather unfortunate not only for performance reasons, but also because it needs to store the key-xors which is added security risk. So what I would recommend is to add the compressions to the initialisation. (In this case pre-compute the state of inner and outer digest) The problem with this is however, the official interface to get a pre-calculated digest state would use clone(). And this would increase the memory pressure. So what really would help is to have a private method of getting and setting the state. Here is the clone based implementation with comments hinting in the direction of state extraction. engineInit(..) { ... md.update(k_opad); mdOuter = md.clone(); // md.getState(); md.reset(); md.update(k_ipad); mdInner = md.clone(); //md.getState(); null(k_opad, k_ipad); // goooood! engineReset() } engineReset() { md = mdInner.clone(); // md.setState(mdInnerState); } This has the big advantage that you can also remove the "first" flag from the update() methods: engineUpdate() { md.update(bytes); } and the final looks like engineDoFinal() { ... byte[] tmp = md.digest(); md = mdOuter.clone(); //// md.setState(mdOuterState); md.update(tmp); md.digest(tmp, 0, tmp.length); return tmp; } Without the state construct we would have a few Digest clones per iteration which might be quite bad, but this can be avoided with the state access. An alternative would be to code HMac without reering to a full fleged hash primitive (only the compression function), but I guess that would make validation of the construct harder. For a PBKDF2 construct this would nearly double the speed, which is important to give attackers not too much headstart, but it might also speed up other repeating usages of HMACs. What do you think? (btw: I had before asked about access to the state, so maybe it is really a good idea to have an interface for this? Gruss Bernd From weijun.wang at oracle.com Sun Nov 29 09:23:45 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Sun, 29 Nov 2015 17:23:45 +0800 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: Some comments: 1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner? 2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security. Thanks Max > On Nov 23, 2015, at 9:14 PM, Siba Sahoo wrote: > > +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net > > > > From: Siba Sahoo > Sent: Monday, November 23, 2015 4:56 PM > To: jigsaw-dev at openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan > Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > > > Hi, > > > > Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, > > > > Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ > > > > Description > > Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: > > > > (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) > > > > Thanks, > > Siba > > From xuelei.fan at oracle.com Sun Nov 29 13:55:11 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 29 Nov 2015 21:55:11 +0800 Subject: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites Message-ID: <565B03BF.5030402@oracle.com> Hi, Please review the fix for JDK-8136442: http://cr.openjdk.java.net/~xuelei/8136442/webrev.00/ This update is proposing to remove the certificate signature algorithms restrictions on cipher suites. Per TLS ECC spec [section 5.3, RFC 4492], ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. It MUST be signed with ECDSA. RSA signed EC-key certs cannot be used for ECDHE_ECDSA cipher suites. That's the current implementation. However, the restrictions on the algorithm used to sign certificates are relaxed in TLS 1.2 [RFC 5246]. Certificate signature algorithms are no longer tied to cipher suites. But we have not removed the restrictions in our implementation yet. As this is a straightforward and simple fix, no new test case is planed. Thanks, Xuelei From vincent.x.ryan at oracle.com Mon Nov 30 00:08:03 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 30 Nov 2015 00:08:03 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension Message-ID: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Hello, Following on from Brad?s recent email, here is the full webrev of the API and the implementation classes for ALPN: http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ In adds the implementation classes (sun/security/ssl) to the public API classes (javax/net/ssl) which have already been agreed. Some basic tests (test/javax/net/ssl) are also included. Please send any code review comments by close-of-business on Tuesday 1 December. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Mon Nov 30 06:30:11 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 30 Nov 2015 14:30:11 +0800 Subject: Design and impl review: JEP 273: DRBG-Based SecureRandom Implementations In-Reply-To: References: <3089B0AC-837D-4E79-BB25-6E6A9EA24318@oracle.com> <5644AF03.5010704@oracle.com> <391452A7-87B2-43FB-86DE-23A07A4E408F@oracle.com> <56462436.1050602@oracle.com> <5A81B95C-3AA6-4051-86AD-416FC21C693F@oracle.com> <564C7DDC.6000902@oracle.com> <564E02A8.5060402@oracle.com> <5D25E347-4D75-41FE-9766-3587FCA4189A@oracle.com> Message-ID: Minor updates: spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/specdiff/java/security/package-summary.html impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.01/ http://javaweb.us.oracle.com/~weijwan/webrev/8051408/webrev/ <<- test/closed Mostly spec. reseed() has no default implementation now (aka throws UnsupportedOperationException). Integration date is now Dec 4. Won't catch it. --Max > On Nov 23, 2015, at 3:03 PM, Wang Weijun wrote: > > spec: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/specdiff/java/security/package-summary.html > impl: http://cr.openjdk.java.net/~weijun/8051408/webrev.00/ > > - No more configure(), it's getInstance(alg, SecureRandomParameters) now. > > - The *Spec class names are now *Parameters. > > - Overloaded reseed() and reseed(additionalInput). > > TBD: Should nextBytes(bytes,additionalInput) throw an UnsupportedOperationException for old implementations? > > Thanks > Max > From xuelei.fan at oracle.com Mon Nov 30 06:30:48 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Nov 2015 14:30:48 +0800 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Message-ID: <565BED18.70202@oracle.com> Looks fine to me. Just a few minor comments. ServerHandshaker.java ===================== There is a typo of the first line. - /* Copyright (c) 1996, 2015, ... + /* + * Copyright (c) 1996, 2015 ... line 538-546 ------------ String negotiatedValue = null; List protocols = clientHelloALPN.getPeerAPs(); for (String ap : localApl) { if (protocols.contains(ap)) { negotiatedValue = ap; break; } } I think the above order prefer the server preference order of application protocols. It's OK per Section 3.2 of RFC 7301. However RFC 7301 also defines the client preference order. Looks like the client preference order is not necessary. It's a little bit confusing, and may result in different behaviors for different TLS vendors. Maybe, we can add an option to honor server preference order in the future. ALPNExtension.java ================== 96 listLength = s.getInt16(); // list length The code would throws SSLException if the remaining input is not sufficient. I was wondering, SSLProtocolException may be more suitable here. May be nice to check the "len" argument value if sufficient for the list length. Otherwise, a SSLProtocolException would be thrown. if (len >= 2) { listLength = s.getInt16(); // list length ... } else { throw new SSLProtocolException(...); } ----------- 104 byte[] bytes = s.getBytes8(); 105 String p = 106 new String(bytes, StandardCharsets.UTF_8); // app protocol Do you want to check that the app protocol cannot be empty? // opaque ProtocolName<1..2^8-1>; // RFC 7301 byte[] bytes = s.getBytes8(); + if (bytes.length == 0) { + throw new SSLProtocolException("Empty ..."); + } --------- Personally, I would prefer to use unmodifiableList for the protocolNames variable. HelloExtensions.java ==================== line 34-37: * This file contains all the classes relevant to TLS Extensions for the * ClientHello and ServerHello messages. The extension mechanism and * several extensions are defined in RFC 3546. Additional extensions are * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301. I may put the "Additional extensions ..." at the end. BTW, as you are here already, would you mind update RFC 3546 to RFC 6066? RFC 6066 is the newest revision of RFC 3546. * This file contains all the classes relevant to TLS Extensions for the * ClientHello and ServerHello messages. The extension mechanism and * several extensions are defined in RFC 6066. The ALPN extension is * defined in RFC 7301. Additional extensions are defined in the ECC * RFC 4492. SSLEngineImpl.java ================== line 1411-1412: private Ciphertext writeRecord(ByteBuffer[] appData, int offset, int length, ByteBuffer netData) throws IOException { ... if (...) { ... // set connection ALPN value applicationProtocol = handshaker.getHandshakeApplicationProtocol(); ... } } Is it redundant to set applicationProtocol here. I was wondering, the value should set in the processInputRecord() method. Cheers, Xuelei On 11/30/2015 8:08 AM, Vincent Ryan wrote: > Hello, > > Following on from Brad?s recent email, here is the full webrev of the > API and the implementation classes for ALPN: > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > In adds the implementation classes (sun/security/ssl) to the public API > classes (javax/net/ssl) which have already been agreed. > Some basic tests (test/javax/net/ssl) are also included. > > Please send any code review comments by close-of-business on Tuesday 1 > December. > Thanks. From xuelei.fan at oracle.com Mon Nov 30 09:23:07 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 30 Nov 2015 17:23:07 +0800 Subject: Handling SNI alerts in OpenJDK In-Reply-To: <20151116182428.GC3979@redhat.com> References: <20151116182428.GC3979@redhat.com> Message-ID: <565C157B.8060207@oracle.com> Can I get the full exception stacks? Thanks, Xuelei On 11/17/2015 2:24 AM, Omair Majid wrote: > Hi, > > There's an issue with using SNI (Server Name Indication) with OpenJDK. > It will abort SSL/TLS connections to a server, when the server gives a > "unrecognized name" alert in the ssl handshake. This alert always > results in a java exception: > > Exception in thread "main" javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name > > RFC 5246 specifies that there are two alert levels: > > "Upon transmission or receipt of a fatal alert message, both parties > immediately close the connection" > > "If an alert with a level of warning is sent and received, generally > the connection can continue normally" > > RFC 3546 (TLS Extensions) says: > > "If the server understood the client hello extension but does not > recognize the server name, it SHOULD send an "unrecognized_name" alert > (which MAY be fatal)." > > So, with an urecognized_name alert that's not fatal, it is up to the > client to continue if it wants to. Most SSL implementations will > continue normally after receiving an "unrecognized name" alert with > the level "warning". Java, however, does not. > > Probably because of issues like this, RFC 6066 (TLS Extensions: > Extension Definitions) says: > > "It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) > alert, because the client's behavior in response to warning-level > alerts is unpredictable." > > It would be much better if OpenJDK followed what most other > implementations do to remove ambiguity. > > There are two ways currently available to work around this issue. > > The first suggested workaround is using > "jsse.enableSNIExtension=false". Unfortunately, this is often not a > possible solution. This is because TLS needs SNI. > > RFC 7525 says: > > "TLS implementations MUST support the Server Name Indication (SNI) > extension defined in Section 3 of [RFC6066] for those higher-level > protocols that would benefit from it, including HTTPS. However, the > actual use of SNI in particular circumstances is a matter of local > policy." > > And disabling SNI breaks connection to many webservers that rely on > TLS. Anything that has to connect to an unknown number of servers > needs SNI enabled. > > The second workaround is to fix the server. > > Practically speaking, a server administrator will often not define all > the virtual hosts if they are supposed to use the default page. And > this works with many implementations (including > Chrome/Firefox/Internet Explorer) that they test. Unfortunately, this > does not work with OpenJDK. So something that "works" for most other > clients doesn't work with OpenJDK and it's not obvious that the server > needs to be fixed. > > But perhaps more importantly, if you are just writing a client in > Java, you may not have access to fix any misconfigured servers. > > So, neither of the current suggested workarounds works for all cases. > I think we should fix OpenJDK to improve compatibility so that it > works - similar to other TLS client implementations - with more > servers by treating fatal and warning alerts differently. > > Thanks, > Omair > From sibabrata.sahoo at oracle.com Mon Nov 30 11:13:11 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 30 Nov 2015 03:13:11 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ I have one question: What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. Thanks, Siba -----Original Message----- From: Wang Weijun Sent: Sunday, November 29, 2015 2:54 PM To: Siba Sahoo Cc: security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net; Sean Mullan Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs Some comments: 1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner? 2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security. Thanks Max > On Nov 23, 2015, at 9:14 PM, Siba Sahoo wrote: > > +HYPERLINK "mailto:security-dev at openjdk.java.net"security-dev at openjdk.java.net > > > > From: Siba Sahoo > Sent: Monday, November 23, 2015 4:56 PM > To: jigsaw-dev at openjdk.java.net; Sean Mullan > Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs > > > > Hi, > > > > Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, > > > > Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ > > > > Description > > Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The test code checks the modular behavior with different combination of separate client & security provider, when available as modular(signed/unsigned) jar. It address total of 72 test cases with the following criteria: > > > > (Signed/Unsigned Jar) X (ClassLoader/ServiceLoader) X (combination of EXPLICIT/AUTO/UNAMED modules) X (With/Without Service descriptor) > > > > Thanks, > > Siba > > From Alan.Bateman at oracle.com Mon Nov 30 11:24:26 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 30 Nov 2015 11:24:26 +0000 Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> Message-ID: <565C31EA.4050709@oracle.com> On 30/11/2015 11:13, Sibabrata Sahoo wrote: > Here is the updated webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ > > I have one question: > What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? > > Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. > The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider. properties in the java.security file. I'm sure Valerie can say more about this. -Alan From sean.mullan at oracle.com Mon Nov 30 12:45:10 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Nov 2015 07:45:10 -0500 Subject: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites In-Reply-To: <565B03BF.5030402@oracle.com> References: <565B03BF.5030402@oracle.com> Message-ID: <565C44D6.5060304@oracle.com> You should change the comment above the calls to setupPrivateKeyAndChain as it still reflects the previous behavior. Also, should this change only be applicable to TLS 1.2? --Sean On 11/29/2015 08:55 AM, Xuelei Fan wrote: > Hi, > > Please review the fix for JDK-8136442: > > http://cr.openjdk.java.net/~xuelei/8136442/webrev.00/ > > This update is proposing to remove the certificate signature algorithms > restrictions on cipher suites. > > Per TLS ECC spec [section 5.3, RFC 4492], > > ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. > It MUST be signed with ECDSA. > > RSA signed EC-key certs cannot be used for ECDHE_ECDSA cipher suites. > That's the current implementation. > > However, the restrictions on the algorithm used to sign certificates are > relaxed in TLS 1.2 [RFC 5246]. Certificate signature algorithms are no > longer tied to cipher suites. But we have not removed the restrictions > in our implementation yet. > > As this is a straightforward and simple fix, no new test case is planed. > > Thanks, > Xuelei > From sean.mullan at oracle.com Mon Nov 30 14:36:13 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Nov 2015 09:36:13 -0500 Subject: RFR 8144107: jdk/security tests not included In-Reply-To: <466E206F-313F-4395-B9BD-69EC5D240A1B@oracle.com> References: <466E206F-313F-4395-B9BD-69EC5D240A1B@oracle.com> Message-ID: <565C5EDD.30905@oracle.com> Looks good. --Sean On 11/26/2015 02:12 AM, Wang Weijun wrote: > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8144107/webrev.00/ > > The recent JarSigner API changeset includes some tests in jdk/security but the directory is not included in any test group. This fix adds it into jdk_security3. > > Thanks > Max > From sibabrata.sahoo at oracle.com Mon Nov 30 14:47:53 2015 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 30 Nov 2015 06:47:53 -0800 (PST) Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs In-Reply-To: <565C31EA.4050709@oracle.com> References: <367c763e-d25e-4f12-a80c-c79611f67dc0@default> <565C31EA.4050709@oracle.com> Message-ID: <0bea66aa-c1ab-486c-88f1-1791719c2c54@default> I would like to know more about this. As far, I can see the "java.security" provider configuration available with JDK9, it holds provider names instead of provider class names. In that case how it resolve the fall back? Thanks, Siba -----Original Message----- From: Alan Bateman Sent: Monday, November 30, 2015 4:54 PM To: Sibabrata Sahoo; security-dev at openjdk.java.net; jigsaw-dev at openjdk.java.net Subject: Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs On 30/11/2015 11:13, Sibabrata Sahoo wrote: > Here is the updated webrev: > http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.02/ > > I have one question: > What should be the behavior when the older version of 3rd party JCE provider jar file(without service descriptor "META-INF/services/*" & working with <= JDK8) configured by "java.security" file, will be place in CLASS_PATH, running through JDK9 and the client is using Security.getProvider() to look for the provider? > > Currently the scenario fails to find the JCE provider. Is this right behavior? If it is, then jdk9 is not backward compatible to find the security provider provided through older jar files from CLASS_PATH. > The JCE work in JDK 9 (via JDK-7191662) was meant to address this point by falling back and attempting to load the class name specified via the security.provider. properties in the java.security file. I'm sure Valerie can say more about this. -Alan From marc.boorshtein at tremolosecurity.com Mon Nov 30 15:44:23 2015 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Mon, 30 Nov 2015 10:44:23 -0500 Subject: S4U2Self and OpenJDK 8 Message-ID: All, I'm trying to get Java's OpenJDK 8 support for s4u2self and s4u2proxy working. The client is openjdk 1.8.0_65 on both OSX El Capitan and CentOS 7. The server is RedHat's FreeIPA 4.1 using MIT kerberos krb5-server-1.12.2-14.el7.x86_64. I'm using the example from https://github.com/ymartin59/java-kerberos-sfudemo. When I attempt to get a TGT and a generic SGT it works great. But when I try to get a s4u2self ticket I get the following Exception: > KrbKdcRep.check: at #1. request for true, received false GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) at test24u2.KerberosDemo.main(KerberosDemo.java:215) Caused by: KrbException: Message stream modified (41) at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:73) at sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:87) at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259) at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:270) at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:67) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 9 more (I will have a full output of the kerberos debug statements and a packet trace at the end of the email). Looking at the kerberos logs I see: Nov 30 10:30:31 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 etypes {17 23 16}) 192.168.2.102: NEEDED_PREAUTH: HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN, Additional pre-authentication required Nov 30 10:30:31 freeipa.rhelent.lan krb5kdc[7507](info): AS_REQ (3 etypes {17 23 16}) 192.168.2.102: ISSUE: authtime 1448897431, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for krbtgt/RHELENT.LAN at RHELENT.LAN Nov 30 10:30:31 freeipa.rhelent.lan krb5kdc[7507](info): TGS_REQ (3 etypes {17 23 16}) 192.168.2.102: ISSUE: authtime 1448897431, etypes {rep=17 tkt=18 ses=17}, HTTP/s4u.rhelent.lan at RHELENT.LAN for HTTP/s4u.rhelent.lan at RHELENT.LAN Nov 30 10:30:31 freeipa.rhelent.lan krb5kdc[7507](info): ... PROTOCOL-TRANSITION s4u-client=mmosley at RHELENT.LAN Indicating that MIT generated a successful response. Looking at the exception code it appears that Java is rejecting the response because it doesn't have the same flags in it as the request. I asked the FreeIPA list and they indicated that the issue is on Java's side, not on MIT Kerberos'. Here's a link to the PCAP of the test run: https://s3.amazonaws.com/ts-public-downloads/captures/java8-s4u2self.pcapng Here's the debug output from Java: >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 83; type: 18 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 17 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 75; type: 16 >>> KeyTabInputStream, readName(): RHELENT.LAN >>> KeyTabInputStream, readName(): HTTP >>> KeyTabInputStream, readName(): s4u.rhelent.lan >>> KeyTab: load() entry length: 67; type: 23 Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Java config name: null Native config name: /etc/krb5.conf Loaded from native config Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> KdcAccessibility: reset Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=156 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=156 >>> KrbKdcReq send: #bytes read=327 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> KDCRep: init() encoding tag is 126 req type is 11 >>>KRBError: cTime is Sun Apr 01 00:21:10 EDT 2029 1869711670000 sTime is Mon Nov 30 10:36:58 EST 2015 1448897818000 suSec is 993036 error code is 25 error Message is Additional pre-authentication required cname is HTTP/s4u.rhelent.lan at RHELENT.LAN sname is krbtgt/RHELENT.LAN at RHELENT.LAN eData provided. msgType is 30 >>>Pre-Authentication Data: PA-DATA type = 136 >>>Pre-Authentication Data: PA-DATA type = 19 PA-ETYPE-INFO2 etype = 17, salt = 4k at PqWo9iUZZ$[r", s2kparams = null PA-ETYPE-INFO2 etype = 16, salt = KaQ|KB9)&A{.`Y;1k, s2kparams = null >>>Pre-Authentication Data: PA-DATA type = 2 PA-ENC-TIMESTAMP >>>Pre-Authentication Data: PA-DATA type = 133 KRBError received: NEEDED_PREAUTH KrbAsReqBuilder: PREAUTH FAILED/REQ, re-send AS-REQ default etypes for default_tkt_enctypes: 17 23 16. Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN default etypes for default_tkt_enctypes: 17 23 16. >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsReq creating message >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=243 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=243 >>> KrbKdcReq send: #bytes read=650 >>> KdcAccessibility: remove freeipa.rhelent.lan Looking for keys for: HTTP/s4u.rhelent.lan at RHELENT.LAN Added key: 23version: 1 Added key: 16version: 1 Added key: 17version: 1 Found unsupported keytype (18) for HTTP/s4u.rhelent.lan at RHELENT.LAN >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbAsRep cons in KrbAsReq.getReply HTTP/s4u.rhelent.lan Service subject: Subject: Principal: HTTP/s4u.rhelent.lan at RHELENT.LAN Private Credential: Ticket (hex) = 0000: 61 82 01 3B 30 82 01 37 A0 03 02 01 05 A1 0D 1B a..;0..7........ 0010: 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A2 20 30 1E .RHELENT.LAN. 0. 0020: A0 03 02 01 02 A1 17 30 15 1B 06 6B 72 62 74 67 .......0...krbtg 0030: 74 1B 0B 52 48 45 4C 45 4E 54 2E 4C 41 4E A3 81 t..RHELENT.LAN.. 0040: FE 30 81 FB A0 03 02 01 12 A1 03 02 01 01 A2 81 .0.............. 0050: EE 04 81 EB 90 76 AA 05 9D 70 B7 39 CD 33 3F 58 .....v...p.9.3?X 0060: F3 66 79 36 AC 30 52 90 76 61 51 A2 1D 36 01 6F .fy6.0R.vaQ..6.o 0070: 2E FA 41 40 5C C4 EE 30 FB E5 BD AC C1 B9 8A 9E ..A@\..0........ 0080: EC E3 00 9B 75 BC A8 09 D3 92 CD 6E 5F 79 42 A2 ....u......n_yB. 0090: 3C BD 11 0D 4C 57 EC 37 C2 81 DA F3 7C C4 0F F4 <...LW.7........ 00A0: D6 A9 D7 3B A4 7F 26 18 B7 5B AC CC 2B C5 92 97 ...;..&..[..+... 00B0: BB 26 19 12 65 AF 65 7B 8E 25 09 F4 C4 33 86 14 .&..e.e..%...3.. 00C0: 83 26 71 00 B6 7B 12 4B DF AB 76 94 7E 70 34 99 .&q....K..v..p4. 00D0: 75 FF 9A 4F 8D 8C 32 0E E5 87 1B 7F 3A C2 A1 40 u..O..2.....:..@ 00E0: 78 1D BC D1 80 F4 B0 A7 B5 F0 62 2E 84 D8 45 18 x.........b...E. 00F0: FA 3C F5 0F BB C6 D5 10 BD 48 DC CB 63 28 B1 17 .<.......H..c(.. 0100: 23 63 AD 0D 47 91 7B F3 FA 40 D0 3A BF 0A C9 27 #c..G.... at .:...' 0110: E9 31 C7 AE 47 0E EA E7 CF 3F 8E E1 08 09 52 30 .1..G....?....R0 0120: 32 42 90 4A 7B 9A A0 32 70 BB 10 C9 94 0B E9 B0 2B.J...2p....... 0130: 16 C6 F4 50 44 8B 61 30 53 6C 65 86 47 AD C8 ...PD.a0Sle.G.. Client Principal = HTTP/s4u.rhelent.lan at RHELENT.LAN Server Principal = krbtgt/RHELENT.LAN at RHELENT.LAN Session Key = EncryptionKey: keyType=17 keyBytes (hex dump)= 0000: C5 D0 1F 70 ED 7E A5 DE D6 67 CC DE EC 1B C1 AF ...p.....g...... Forwardable Ticket true Forwarded Ticket false Proxiable Ticket false Proxy Ticket false Postdated Ticket false Renewable Ticket false Initial Ticket false Auth Time = Mon Nov 30 10:36:59 EST 2015 Start Time = Mon Nov 30 10:36:59 EST 2015 End Time = Tue Dec 01 10:36:59 EST 2015 Renew Till = null Client Addresses Null Private Credential: /Users/mlb/Documents/localdev.keytab for HTTP/s4u.rhelent.lan at RHELENT.LAN Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 10:36:59 EST 2015 Search Subject for SPNEGO INIT cred (<>, sun.security.jgss.spnego.SpNegoCredElement) Search Subject for Kerberos V5 INIT cred (<>, sun.security.jgss.krb5.Krb5InitCredential) Found ticket for HTTP/s4u.rhelent.lan at RHELENT.LAN to go to krbtgt/RHELENT.LAN at RHELENT.LAN expiring on Tue Dec 01 10:36:59 EST 2015 >>> CksumType: sun.security.krb5.internal.crypto.HmacMd5ArcFourCksumType default etypes for default_tgs_enctypes: 17 23 16. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType >>> KrbKdcReq send: kdc=freeipa.rhelent.lan UDP:88, timeout=30000, number of retries =3, #bytes=750 >>> KDCCommunication: kdc=freeipa.rhelent.lan UDP:88, timeout=30000,Attempt =1, #bytes=750 >>> KrbKdcReq send: #bytes read=582 >>> KdcAccessibility: remove freeipa.rhelent.lan >>> EType: sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType > KrbKdcRep.check: at #1. request for true, received false GSSException: Failure unspecified at GSS-API level (Mechanism level: Attempt to obtain S4U2self credentials failed!) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:357) at sun.security.jgss.spnego.SpNegoCredElement.impersonate(SpNegoCredElement.java:94) at sun.security.jgss.GSSCredentialImpl.impersonate(GSSCredentialImpl.java:141) at test24u2.KerberosDemo$1.run(KerberosDemo.java:128) at test24u2.KerberosDemo$1.run(KerberosDemo.java:1) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at test24u2.KerberosDemo.impersonate(KerberosDemo.java:121) at test24u2.KerberosDemo.generateToken(KerberosDemo.java:179) at test24u2.KerberosDemo.main(KerberosDemo.java:215) Caused by: KrbException: Message stream modified (41) at sun.security.krb5.KrbKdcRep.check(KrbKdcRep.java:73) at sun.security.krb5.KrbTgsRep.(KrbTgsRep.java:87) at sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:259) at sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:270) at sun.security.krb5.internal.CredentialsUtil.acquireS4U2selfCreds(CredentialsUtil.java:67) at sun.security.krb5.Credentials.acquireS4U2selfCreds(Credentials.java:463) at sun.security.jgss.krb5.Krb5InitCredential.impersonate(Krb5InitCredential.java:353) ... 9 more Thanks Marc Boorshtein CTO Tremolo Security marc.boorshtein at tremolosecurity.com From xuelei.fan at oracle.com Mon Nov 30 16:13:29 2015 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 1 Dec 2015 00:13:29 +0800 Subject: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites In-Reply-To: <565C44D6.5060304@oracle.com> References: <565B03BF.5030402@oracle.com> <565C44D6.5060304@oracle.com> Message-ID: <565C75A9.7050707@oracle.com> On 11/30/2015 8:45 PM, Sean Mullan wrote: > You should change the comment above the calls to setupPrivateKeyAndChain > as it still reflects the previous behavior. Oops, forgot the update the comment. Updated: http://cr.openjdk.java.net/~xuelei/8136442/webrev.01/ > Also, should this change only be applicable to TLS 1.2? > TLS 1.2 updates the spec (RFC 4279). The update can be applied to TLS 1.0 and 1.1, too. Thanks, Xuelei > --Sean > > On 11/29/2015 08:55 AM, Xuelei Fan wrote: >> Hi, >> >> Please review the fix for JDK-8136442: >> >> http://cr.openjdk.java.net/~xuelei/8136442/webrev.00/ >> >> This update is proposing to remove the certificate signature algorithms >> restrictions on cipher suites. >> >> Per TLS ECC spec [section 5.3, RFC 4492], >> >> ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. >> It MUST be signed with ECDSA. >> >> RSA signed EC-key certs cannot be used for ECDHE_ECDSA cipher suites. >> That's the current implementation. >> >> However, the restrictions on the algorithm used to sign certificates are >> relaxed in TLS 1.2 [RFC 5246]. Certificate signature algorithms are no >> longer tied to cipher suites. But we have not removed the restrictions >> in our implementation yet. >> >> As this is a straightforward and simple fix, no new test case is planed. >> >> Thanks, >> Xuelei >> From sean.mullan at oracle.com Mon Nov 30 16:59:24 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Nov 2015 11:59:24 -0500 Subject: Code Review Request, 8136442 Don't tie Certificate signature algorithms to ciphersuites In-Reply-To: <565C75A9.7050707@oracle.com> References: <565B03BF.5030402@oracle.com> <565C44D6.5060304@oracle.com> <565C75A9.7050707@oracle.com> Message-ID: <565C806C.2000606@oracle.com> On 11/30/2015 11:13 AM, Xuelei Fan wrote: >> You should change the comment above the calls to setupPrivateKeyAndChain >> >as it still reflects the previous behavior. > Oops, forgot the update the comment. > > Updated: > http://cr.openjdk.java.net/~xuelei/8136442/webrev.01/ Looks good. > >> >Also, should this change only be applicable to TLS 1.2? >> > > TLS 1.2 updates the spec (RFC 4279). The update can be applied to TLS > 1.0 and 1.1, too. Ok. --Sean From sean.mullan at oracle.com Mon Nov 30 21:10:44 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 30 Nov 2015 16:10:44 -0500 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> Message-ID: <565CBB54.4000402@oracle.com> SSLParameters.java 649 applicationProtocols = protocols.clone(); You should clone the parameters before checking if they are valid. Move this to line 642, and check the validity of the cloned array. Also, use a temporary variable for the clone, so as not to pollute the applicationProtocols field until you confirm the values are valid, and then assign it to applicationProtocols. ExtensionType.java 47 new ArrayList(15); nit - you can use diamond operator above --Sean On 11/29/2015 07:08 PM, Vincent Ryan wrote: > Hello, > > Following on from Brad?s recent email, here is the full webrev of the > API and the implementation classes for ALPN: > http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ > > In adds the implementation classes (sun/security/ssl) to the public API > classes (javax/net/ssl) which have already been agreed. > Some basic tests (test/javax/net/ssl) are also included. > > Please send any code review comments by close-of-business on Tuesday 1 > December. > Thanks. From vincent.x.ryan at oracle.com Mon Nov 30 23:08:48 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 30 Nov 2015 23:08:48 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565BED18.70202@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565BED18.70202@oracle.com> Message-ID: Thanks for your review. Comments in-line. > On 30 Nov 2015, at 06:30, Xuelei Fan wrote: > > Looks fine to me. Just a few minor comments. > > ServerHandshaker.java > ===================== > There is a typo of the first line. > - /* Copyright (c) 1996, 2015, ... > + /* > + * Copyright (c) 1996, 2015 ? > Done. > > line 538-546 > ------------ > String negotiatedValue = null; > List protocols = clientHelloALPN.getPeerAPs(); > > for (String ap : localApl) { > if (protocols.contains(ap)) { > negotiatedValue = ap; > break; > } > } > > I think the above order prefer the server preference order of > application protocols. It's OK per Section 3.2 of RFC 7301. > > However RFC 7301 also defines the client preference order. Looks like > the client preference order is not necessary. It's a little bit > confusing, and may result in different behaviors for different TLS vendors. > > Maybe, we can add an option to honor server preference order in the future. I added a comment to show that server-preference is used. If necessary I think we can add support for controlling this via a property, later. > > ALPNExtension.java > ================== > 96 listLength = s.getInt16(); // list length > > The code would throws SSLException if the remaining input is not > sufficient. I was wondering, SSLProtocolException may be more suitable > here. May be nice to check the "len" argument value if sufficient for > the list length. Otherwise, a SSLProtocolException would be thrown. > > if (len >= 2) { > listLength = s.getInt16(); // list length > ... > } else { > throw new SSLProtocolException(...); > } I added the exception and more detailed message. > > ----------- > 104 byte[] bytes = s.getBytes8(); > 105 String p = > 106 new String(bytes, StandardCharsets.UTF_8); // app protocol > > Do you want to check that the app protocol cannot be empty? > > // opaque ProtocolName<1..2^8-1>; // RFC 7301 > byte[] bytes = s.getBytes8(); > + if (bytes.length == 0) { > + throw new SSLProtocolException("Empty ..."); > + } Done. > > --------- > Personally, I would prefer to use unmodifiableList for the protocolNames > variable. It is accessible only to classes in this package. > > > HelloExtensions.java > ==================== > line 34-37: > * This file contains all the classes relevant to TLS Extensions for the > * ClientHello and ServerHello messages. The extension mechanism and > * several extensions are defined in RFC 3546. Additional extensions are > * defined in the ECC RFC 4492.The ALPN extension is defined in RFC7301. > > I may put the "Additional extensions ..." at the end. BTW, as you are > here already, would you mind update RFC 3546 to RFC 6066? RFC 6066 is > the newest revision of RFC 3546. I concatenated the final sentence. > > * This file contains all the classes relevant to TLS Extensions for the > * ClientHello and ServerHello messages. The extension mechanism and > * several extensions are defined in RFC 6066. The ALPN extension is > * defined in RFC 7301. Additional extensions are defined in the ECC > * RFC 4492. > > SSLEngineImpl.java > ================== > > line 1411-1412: > private Ciphertext writeRecord(ByteBuffer[] appData, > int offset, int length, ByteBuffer netData) throws IOException { > ... > if (...) { > ... > // set connection ALPN value > applicationProtocol = > handshaker.getHandshakeApplicationProtocol(); > ... > } > } > > Is it redundant to set applicationProtocol here. I was wondering, the > value should set in the processInputRecord() method. My understanding is the the wrapping is performed here and the unwrapping performed in processInputRecord(). Isn?t the assignment required in both places? > > Cheers, > Xuelei > > On 11/30/2015 8:08 AM, Vincent Ryan wrote: >> Hello, >> >> Following on from Brad?s recent email, here is the full webrev of the >> API and the implementation classes for ALPN: >> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ >> >> In adds the implementation classes (sun/security/ssl) to the public API >> classes (javax/net/ssl) which have already been agreed. >> Some basic tests (test/javax/net/ssl) are also included. >> >> Please send any code review comments by close-of-business on Tuesday 1 >> December. >> Thanks. > From vincent.x.ryan at oracle.com Mon Nov 30 23:24:30 2015 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 30 Nov 2015 23:24:30 +0000 Subject: Request for review: 8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension In-Reply-To: <565CBB54.4000402@oracle.com> References: <304F64D2-9980-4293-9B1B-7954FEAE58B4@oracle.com> <565CBB54.4000402@oracle.com> Message-ID: Thanks for the review. I?ve incorporated your comments and Xuelei?s comments in a revised webrev: http://cr.openjdk.java.net/~vinnie/8144093/webrev.01/ > On 30 Nov 2015, at 21:10, Sean Mullan wrote: > > SSLParameters.java > > 649 applicationProtocols = protocols.clone(); > > You should clone the parameters before checking if they are valid. Move this to line 642, and check the validity of the cloned array. Also, use a temporary variable for the clone, so as not to pollute the applicationProtocols field until you confirm the values are valid, and then assign it to applicationProtocols. > > ExtensionType.java > > 47 new ArrayList(15); > > nit - you can use diamond operator above > > --Sean > > On 11/29/2015 07:08 PM, Vincent Ryan wrote: >> Hello, >> >> Following on from Brad?s recent email, here is the full webrev of the >> API and the implementation classes for ALPN: >> http://cr.openjdk.java.net/~vinnie/8144093/webrev.00/ >> >> In adds the implementation classes (sun/security/ssl) to the public API >> classes (javax/net/ssl) which have already been agreed. >> Some basic tests (test/javax/net/ssl) are also included. >> >> Please send any code review comments by close-of-business on Tuesday 1 >> December. >> Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: