From npathak2 at ncsu.edu Wed Aug 2 04:21:29 2017 From: npathak2 at ncsu.edu (Neetish Pathak) Date: Tue, 1 Aug 2017 21:21:29 -0700 Subject: TLS 1.3 support in JDK Message-ID: Hello all, I am new to JDK development mailing list. 21 drafts fro TLS 1.3 have come out so far. Is there any ongoing work on including TLS 1.3 in JDK. If so, please refer. TLS 1.3 has been implemented in OpenSSL. Is there any way to use OpenSSL in java in place of in-built SSL library. Thanks Best Regards, Neetish -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed Aug 2 10:22:52 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 2 Aug 2017 18:22:52 +0800 Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better In-Reply-To: <89402164-f4b1-4e36-b894-2ad997efd409@default> References: <89402164-f4b1-4e36-b894-2ad997efd409@default> Message-ID: <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments: 38: This ProcessTools is deprecated. Is it possible to use the one in root repo? 53: Why make it public? 98-99: What localized strings are you trying to avoid? 103-104: Why do these 2 variables contain the option name? I mean in the following expression String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE) you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE) Or just simply String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE) 128: This loop looks a little strange. I'd rather just write the content twice. 136: This is the only usage of service parameter? If so, why not just move the line into constructor? 140: Why is there a "-" after "Case:"? 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value? 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new? 212-245: Please add an empty line before every new mBuilder assignment. 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one? I'll read the other two tests and hopefully they have similar structures. Thanks Max > On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo wrote: > > Hi, > > Please review the patch for the following, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8183310 > Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/ > > Change description: > The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?. > > SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up. > JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination. > JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file. > > Thanks, > Siba From xuelei.fan at oracle.com Wed Aug 2 22:18:44 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Aug 2017 15:18:44 -0700 Subject: Code Review Request, JDK-8180643 Illegal handshake message Message-ID: Hi, Please review the update: http://cr.openjdk.java.net/~xuelei/8180643/webrev.00/ This update is trying to detect unknown or unsupported handshake messages sooner rather later. Thanks, Xuelei From weijun.wang at oracle.com Wed Aug 2 22:29:26 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 3 Aug 2017 06:29:26 +0800 Subject: Code Review Request, JDK-8180643 Illegal handshake message In-Reply-To: References: Message-ID: <73C79806-B7A1-45AC-9A89-350792E197D2@oracle.com> Looks fine. Maybe you can add a comment near the definition of these constants that when a new one is added it should be listed in the isUnsupported() method. Thanks Max > On Aug 3, 2017, at 6:18 AM, Xuelei Fan wrote: > > Hi, > > Please review the update: > http://cr.openjdk.java.net/~xuelei/8180643/webrev.00/ > > This update is trying to detect unknown or unsupported handshake messages sooner rather later. > > Thanks, > Xuelei From xuelei.fan at oracle.com Wed Aug 2 22:30:55 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 2 Aug 2017 15:30:55 -0700 Subject: Code Review Request, JDK-8180643 Illegal handshake message In-Reply-To: <73C79806-B7A1-45AC-9A89-350792E197D2@oracle.com> References: <73C79806-B7A1-45AC-9A89-350792E197D2@oracle.com> Message-ID: <978c3d29-507a-2e5f-08e2-db5c1b5d9231@oracle.com> On 8/2/2017 3:29 PM, Weijun Wang wrote: > Looks fine. > > Maybe you can add a comment near the definition of these constants that when a new one is added it should be listed in the isUnsupported() method. > Good suggestion! It's a concern of mine, too. Thanks, Xuelei > Thanks > Max > >> On Aug 3, 2017, at 6:18 AM, Xuelei Fan wrote: >> >> Hi, >> >> Please review the update: >> http://cr.openjdk.java.net/~xuelei/8180643/webrev.00/ >> >> This update is trying to detect unknown or unsupported handshake messages sooner rather later. >> >> Thanks, >> Xuelei > From mandy.chung at oracle.com Thu Aug 3 00:49:02 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Aug 2017 17:49:02 -0700 Subject: RFR: JDK-8185758: jdk.smartcardio has broken docs for exceptions In-Reply-To: <59825E6F.5080709@oracle.com> References: <59825E6F.5080709@oracle.com> Message-ID: <870D7BF7-7247-4872-AF13-A92BA3AD90FE@oracle.com> > On Aug 2, 2017, at 4:21 PM, Jonathan Gibbons wrote: > > (I'm not sure if there is a better list for this request, but the request is so simple, I'm hoping it will be sufficient. > > Please review this very simple fix to replace two uses of ... with {@code...}. > > The underlying problem being fixed is incorrect handling of the first sentence in a couple of cases, due to the presence of a '?' in the code expression. The doclet was treating the ? as terminating the first sentence, leading to confusing output, and incorrect HTML being generated. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185758 > Webrev: http://cr.openjdk.java.net/~jjg/8185758/webrev.00/ Looks good. Mandy From weijun.wang at oracle.com Thu Aug 3 01:46:02 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 3 Aug 2017 09:46:02 +0800 Subject: [10] RFR 8166222: Don't treat signed jars with invalid timestamps as unsigned In-Reply-To: References: <99291a07-a462-50f0-5b62-7e6907b081f5@oracle.com> <10e34c58-0b55-0b75-8500-64ba2cc7386b@oracle.com> <652181dc-a523-3316-55f5-2ca995d7b967@oracle.com> Message-ID: Webrev updated: - http://cr.openjdk.java.net/~weijun/8166222/root/webrev.01 Move the change for JarUtils.java here. - http://cr.openjdk.java.net/~weijun/8166222/webrev.02/ Update multiple "is not validated" strings to "is invalid" in Resources.java. Several tests that grep these words are also updated. No functional change. Thanks Max > On Jul 14, 2017, at 11:22 PM, Weijun Wang wrote: > > All comments accepted. I?ll update my webrev next month. :-) > > No comment on real code change? > > --Max > >> On Jul 14, 2017, at 11:20 PM, Sean Mullan wrote: >> >> Finally getting back to reviewing this update. A few comments: >> >> SignatureFileVerifier.java: >> >> 729 debug.println("getTimeStamp caught: "+e); >> >> Can you add a more descriptive message here, like: "Exception processing timestamp, code will be treated as signed, but not timestamped: ". >> >> Resources.java: >> >> 209 {".CertPath.not.validated.", "[CertPath not validated: "}, >> 210 {".TSA.CertPath.not.validated.", "[TSA CertPath not validated: "}, >> >> I think it would be more clear to say "Invalid CertPath". "not validated" sounds like keytool didn't even try to validate the path. >> >> Also, I think you should say "certificate chain" instead of "CertPath" because that is the term that is used in all the other certificate chain messages emitted by keytool. >> >> 265 {"The.tsa.certificate.chain.is.not.validated.reason.1", >> 266 "The TSA certificate chain is not validated. Reason: %s"}, >> >> s/not validated/invalid/ >> >> 275 {"This.jar.contains.entries.whose.tsa.certificate.chain.is.not.validated.reason.1", >> 276 "This jar contains entries whose TSA certificate chain is not validated. Reason: %s"}, >> >> s/not/validated/invalid/ >> >> 281 {"bad.timestamp.verifying", >> 282 "This jar contains signatures that include an invalid timestamp. Without a valid timestamp, users may not be able to validate this jar after any of the signer certificates expire (as early as %1$tY-%1$tm-%1$td)."}, >> >> Can you also include information how to debug this, i.e. "Rerun jarsigner with -J-Djava.security.debug=jar for more information." >> >> --Sean >> >> On 5/22/17 11:43 AM, Weijun Wang wrote: >>> An updated webrev at >>> http://cr.openjdk.java.net/~weijun/8166222/webrev.01/ >>> Some more changes: >>> - TSA cert chain validation is performed in both verification and signing. The exit code for validation failure when -strict is specified is 64. >>> - printCert() and validateCertChain() know about they are dealing with TSA cert chain and do not touch any flag except for tsaChainNotValidated. Code being a little ugly. >>> - TSA certs lines added to -verbose -certs. >>> BTW, the code change also fixed https://bugs.openjdk.java.net/browse/JDK-8180289. >>> Here is an example: >>> $ jarsigner -verify -strict ts2.jar -verbose -certs >>> s k 75 Mon May 22 22:49:06 CST 2017 META-INF/MANIFEST.MF >>> [entry was signed on 5/22/17, 10:49 PM] >>>>>> Signer >>> X.509, CN=signer (signer) >>> [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] >>> X.509, CN=CA (ca) >>> [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM] >>>>>> TSA >>> X.509, CN=ts >>> [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] >>> [ExtendedKeyUsage extension does not support timestamping] >>> [TSA CertPath not validated: Extended key usage does not permit use for TSA server] >>> 305 Mon May 22 22:49:08 CST 2017 META-INF/SIGNER.SF >>> 3096 Mon May 22 22:51:06 CST 2017 META-INF/SIGNER.RSA >>> smk 1 Mon May 22 22:48:56 CST 2017 A >>> [entry was signed on 5/22/17, 10:49 PM] >>>>>> Signer >>> X.509, CN=signer (signer) >>> [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] >>> X.509, CN=CA (ca) >>> [certificate is valid from 4/12/17, 10:49 PM to 10/29/17, 10:49 PM] >>>>>> TSA >>> X.509, CN=ts >>> [certificate is valid from 5/22/17, 10:49 PM to 12/8/17, 10:49 PM] >>> [TSA CertPath not validated: Extended key usage does not permit use for TSA server] >>> s = signature was verified >>> m = entry is listed in manifest >>> k = at least one certificate was found in keystore >>> - Signed by "CN=signer" >>> Digest algorithm: SHA-256 >>> Signature algorithm: SHA256withRSA, 2048-bit key >>> Timestamped by "CN=ts" on Mon May 22 14:49:08 UTC 2017 >>> Timestamp digest algorithm: SHA-256 >>> Timestamp signature algorithm: SHA1withRSA, 2048-bit key >>> jar verified, with signer errors. >>> Error: >>> This jar contains entries whose TSA certificate chain is not validated. Reason: Extended key usage does not permit use for TSA server >>> Thanks >>> Max >>> On 04/12/2017 11:52 PM, Weijun Wang wrote: >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8166222/webrev.00/ >>>> >>>> The major code change is inside SignatureFileVerifier.java. Now if the timestamp on a signed jar is invalid (For example, using a weak algorithm now disabled), the jar file will be treated as a signed jar without a timestamp. Before this change, it was treated unsigned. >>>> >>>> In jarsigner/Main.java, I also add a line to validate the TSA cert chain. If not validated, a warning will be shown which is similar to the one when signer cert chain is not validated. If -strict is on, exit code will change too. >>>> >>>> I also make a small change at >>>> >>>> http://cr.openjdk.java.net/~weijun/8166222/root/webrev.00/ >>>> >>>> The executeCommand() method shows more info (mainly stdout and stderr outputs) than executeProcess(). >>>> >>>> Because of the behavior change and new warnings, this change will need a Compatibility and Specification Review (CSR). At the moment, please review the code change first. >>>> >>>> Thanks >>>> Max > From Roger.Riggs at Oracle.com Thu Aug 3 13:58:53 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 3 Aug 2017 09:58:53 -0400 Subject: RFR 8184744 : Replace finalizer in crypto classes with Cleaner Message-ID: <12a249f3-b480-cb47-7099-abb6f1322e0f@Oracle.com> Please review replacing finalize with java.lang.ref.Cleaner in a few simple cases. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ Thanks, Roger From anish_8617 at rediffmail.com Thu Aug 3 16:48:36 2017 From: anish_8617 at rediffmail.com (Anish kumar) Date: 3 Aug 2017 16:48:36 -0000 Subject: =?utf-8?B?SmF2YSBzZWN1cml0eSBzb2NrZXQgcGVybWlzc2lvbg==?= Message-ID: <20170803164836.25871.qmail@f4mail-235-247.rediffmail.com> Hi,Greeting!I'm working on the Java security and enabled security manager with the custom grant policy file.I'm facing issue related to socket permission. My application is listening to localhost on the port '3333', for which listen socket permission is granted in the policy file. For this port I created ServerSocket by giving argument Inet4Address.getLocalHost(). But when my client running on different node trying to send packets to my application on the port '3333' it throws connection reset exception.And the server side when it's trying to accept on the socket throws security check exception capturing client IP with the port and the action is (connect, resolve).java.security.AccessControlException: access denied ("java.net.SocketPermission" "XX.XXX.XXX.10:52610" "accept,resolve")Server IP - XX.XXX.XXX.11Client IP - XX.XXX.XXX.10I can't add client IP and port in the grant policy file at the server side because the port range varies and also may be some other client can try to send packet to the server on the port '3333'.Could please provide me some inputs on the same, also how it can be handled in the case of web server i.e. Tomact.Thanks & Regards,Anish Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at Oracle.com Thu Aug 3 20:01:55 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 3 Aug 2017 16:01:55 -0400 Subject: RFR 8184744 : Replace finalizer in crypto classes with Cleaner In-Reply-To: <12a249f3-b480-cb47-7099-abb6f1322e0f@Oracle.com> References: <12a249f3-b480-cb47-7099-abb6f1322e0f@Oracle.com> Message-ID: <9702aa8e-fa8d-e9c7-68e6-e50a0cceb965@Oracle.com> Found a race in the tests between the Cleaner clearing the arrays and the test waiting for the key to be freed. Revised to continuously check the arrays and exit when they are cleared. If not cleared the test will timeout. Updated the webrev: http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ Thanks, Roger On 8/3/2017 9:58 AM, Roger Riggs wrote: > Please review replacing finalize with java.lang.ref.Cleaner in a few > simple cases. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ > > Thanks, Roger > > From mandy.chung at oracle.com Thu Aug 3 20:13:18 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Aug 2017 13:13:18 -0700 Subject: RFR 8184744 : Replace finalizer in crypto classes with Cleaner In-Reply-To: <9702aa8e-fa8d-e9c7-68e6-e50a0cceb965@Oracle.com> References: <12a249f3-b480-cb47-7099-abb6f1322e0f@Oracle.com> <9702aa8e-fa8d-e9c7-68e6-e50a0cceb965@Oracle.com> Message-ID: <2B758FD9-3203-4740-80D1-1805832ACF2C@oracle.com> Thanks for doing this. It?s good to see JDK finalizes being replaced. It looks good to me. I wonder if there is any existing security utility class that may be a good place for this zero-ing byte array method to share. Sean and other may have opinion. Mandy > On Aug 3, 2017, at 1:01 PM, Roger Riggs wrote: > > Found a race in the tests between the Cleaner clearing the arrays and the test waiting for the key to be freed. > Revised to continuously check the arrays and exit when they are cleared. If not cleared the test will timeout. > > Updated the webrev: > http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ > > Thanks, Roger > > On 8/3/2017 9:58 AM, Roger Riggs wrote: >> Please review replacing finalize with java.lang.ref.Cleaner in a few simple cases. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ >> >> Thanks, Roger >> >> > From mbalao at redhat.com Fri Aug 4 13:18:15 2017 From: mbalao at redhat.com (Martin Balao) Date: Fri, 4 Aug 2017 10:18:15 -0300 Subject: Code Review Request: JDK-8148421 (Extended Master Secret TLS extension) Message-ID: Hi, This is my proposal for JDK-8148421 (Support Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension) [1]: * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.01/ (browse online) * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.01/8148421.webrev.01.zip (download) Notes: * There is no PKCS#11 support for Extended Master Secret key derivation at this moment. NSS supports it through a vendor-specific type definition (CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE and CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE_DH in pkcs11n.h file). Thus, P11TlsMasterSecretGenerator uses the legacy Master Key Derivation method only. Thanks in advanced, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8148421 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Aug 4 15:12:44 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 Aug 2017 08:12:44 -0700 Subject: some config files out of conf directory In-Reply-To: References: Message-ID: <25869479-9e28-feaf-2c86-34fd92a41818@oracle.com> On 04/08/2017 07:59, Jiri Vanek wrote: > Hello! > > I'm packaging openjdk9 for Fedora, and following files: > jdk/lib/security/blacklisted.certs > jdk/lib/security/default.policy > > Seems to be config files. Still, they are in lib/security, whether all > other config files were (finally! Thank you!) moved to > jdk/conf/ > and its subdirectories. Is it intentional? Why so? Are there plans to > change it? cc'ing security-dev in case there is more needed on this but in summary, these are not intended to be edited so this is why they are in the `lib` rather than `conf` directory. -Alan From sean.mullan at oracle.com Fri Aug 4 18:40:58 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Aug 2017 14:40:58 -0400 Subject: some config files out of conf directory In-Reply-To: <25869479-9e28-feaf-2c86-34fd92a41818@oracle.com> References: <25869479-9e28-feaf-2c86-34fd92a41818@oracle.com> Message-ID: <8258a209-e968-0f0e-9b2e-87aac1295929@oracle.com> On 8/4/17 11:12 AM, Alan Bateman wrote: > On 04/08/2017 07:59, Jiri Vanek wrote: >> Hello! >> >> I'm packaging openjdk9 for Fedora, and following files: >> jdk/lib/security/blacklisted.certs >> jdk/lib/security/default.policy >> >> Seems to be config files. Still, they are in lib/security, whether all >> other config files were (finally! Thank you!) moved to >> jdk/conf/ >> and its subdirectories. Is it intentional? Why so? Are there plans to >> change it? > cc'ing security-dev in case there is more needed on this but in summary, > these are not intended to be edited so this is why they are in the `lib` > rather than `conf` directory. Yes, Alan is correct. The default.policy file contains the permissions granted by default to the modules included in the JDK (that are loaded by the platform loader) and blacklisted.certs contains a system-wide list of certificates that are distrusted by the CertPath implementation in the JDK. They are not configuration files, they are generally meant to be files that typically never need to be modified. Thanks, Sean From Roger.Riggs at Oracle.com Fri Aug 4 18:43:18 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 4 Aug 2017 14:43:18 -0400 Subject: RFR 8184744 : Replace finalizer in crypto classes with Cleaner In-Reply-To: <2B758FD9-3203-4740-80D1-1805832ACF2C@oracle.com> References: <12a249f3-b480-cb47-7099-abb6f1322e0f@Oracle.com> <9702aa8e-fa8d-e9c7-68e6-e50a0cceb965@Oracle.com> <2B758FD9-3203-4740-80D1-1805832ACF2C@oracle.com> Message-ID: <2ad622d6-1549-b6fd-5a06-6642c851535c@Oracle.com> Hi Mandy, On 8/3/2017 4:13 PM, Mandy Chung wrote: > Thanks for doing this. It?s good to see JDK finalizes being replaced. > > It looks good to me. I wonder if there is any existing security utility class that may be a good place for this zero-ing byte array method to share. Sean and other may have opinion. There are very few of these cases and I think it is better to keep the code close to the use. If there's good place to put a method for this purpose, let me know. Thanks, Roger > > Mandy > >> On Aug 3, 2017, at 1:01 PM, Roger Riggs wrote: >> >> Found a race in the tests between the Cleaner clearing the arrays and the test waiting for the key to be freed. >> Revised to continuously check the arrays and exit when they are cleared. If not cleared the test will timeout. >> >> Updated the webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ >> >> Thanks, Roger >> >> On 8/3/2017 9:58 AM, Roger Riggs wrote: >>> Please review replacing finalize with java.lang.ref.Cleaner in a few simple cases. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-crypt-finalize-8184744/ >>> >>> Thanks, Roger >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.rundgren.net at gmail.com Fri Aug 4 19:05:20 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 4 Aug 2017 21:05:20 +0200 Subject: PKCS #11 TC looks into OKP versus EC for CFRG support In-Reply-To: References: Message-ID: <0c075fc9-9038-2fb5-e23b-f1ca6483e013@gmail.com> https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-) Yeah, I know that open source <> open ideas but the world needs a direction. Feel completely free dismissing OKP, it is the silence that's killing us. Cheers, Anders https://github.com/cyberphone/java-cfrg-spec From mstjohns at comcast.net Fri Aug 4 19:33:13 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 4 Aug 2017 15:33:13 -0400 Subject: PKCS #11 TC looks into OKP versus EC for CFRG support In-Reply-To: <0c075fc9-9038-2fb5-e23b-f1ca6483e013@gmail.com> References: <0c075fc9-9038-2fb5-e23b-f1ca6483e013@gmail.com> Message-ID: On 8/4/2017 3:05 PM, Anders Rundgren wrote: > https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html > > C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-) > Yeah, I know that open source <> open ideas but the world needs a > direction. > > Feel completely free dismissing OKP, it is the silence that's killing us. > > Cheers, > Anders > https://github.com/cyberphone/java-cfrg-spec > Anders asked me to take a look at this a while back and I haven't actually had much time. However, I think the approach he's crafted for OKP is probably wrong for Java. What I think I would do instead is create java.security.spec.ECFieldMontgomery and java.security.spec.ECFieldEdwards. I'd place the indication of whether the curves are for Signature or Key Agreement at the field level - maybe as a sub interface or marker interface. For the ECPoint data I'd leave Y as a NULL - Y does exists and can be calculated, but all of these appear to use a compressed encoding. I'd encode the public and private data as BigIntegers - this would mean converting from little endian to big endian and back again when doing the PKCS8 encoding stuff, but a lot easier than adding a whole new class of top level interfaces. As far as I can tell, it should be possible to represent the four curves using the current API (minus the field info) and I'd suggest doing exactly that. Tagging the ECField differently will isolate the changes without breaking previous implementations. I think this is then also extensible as other curves come along. My thoughts - Mike From anders.rundgren.net at gmail.com Fri Aug 4 20:59:37 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Fri, 4 Aug 2017 22:59:37 +0200 Subject: PKCS #11 TC looks into OKP versus EC for CFRG support In-Reply-To: References: <0c075fc9-9038-2fb5-e23b-f1ca6483e013@gmail.com> Message-ID: On 2017-08-04 21:33, Michael StJohns wrote: > On 8/4/2017 3:05 PM, Anders Rundgren wrote: >> https://lists.oasis-open.org/archives/pkcs11/201708/msg00006.html >> >> C'mon (Oracle) Guys, what's *your* plan; is JDK open source or not? :-) >> Yeah, I know that open source <> open ideas but the world needs a >> direction. >> >> Feel completely free dismissing OKP, it is the silence that's killing us. >> >> Cheers, >> Anders >> https://github.com/cyberphone/java-cfrg-spec >> > > Anders asked me to take a look at this a while back and I haven't > actually had much time. However, I think the approach he's crafted for > OKP is probably wrong for Java. "Wrong" is hardly the right word here; the proposals simply have quite different objectives. I (FWIW) didn't give internal operations and structures much considerations; the emphasis was on clarity and conformance with other related specs. Your proposal focuses on reuse by finding similar patterns which of course isn't "wrong" either. In terms of code size I believe the difference will turn out to be insignificant but that's of course at this stage just a guess. However, documentation- and support-wise OKP has a clear advantage. Maybe Oracle should start there and see where it leads... Anders > > What I think I would do instead is create > java.security.spec.ECFieldMontgomery and > java.security.spec.ECFieldEdwards. I'd place the indication of whether > the curves are for Signature or Key Agreement at the field level - maybe > as a sub interface or marker interface. > > For the ECPoint data I'd leave Y as a NULL - Y does exists and can be > calculated, but all of these appear to use a compressed encoding. I'd > encode the public and private data as BigIntegers - this would mean > converting from little endian to big endian and back again when doing > the PKCS8 encoding stuff, but a lot easier than adding a whole new class > of top level interfaces. > > As far as I can tell, it should be possible to represent the four curves > using the current API (minus the field info) and I'd suggest doing > exactly that. Tagging the ECField differently will isolate the changes > without breaking previous implementations. I think this is then also > extensible as other curves come along. > > My thoughts - Mike > > From bradford.wetmore at oracle.com Fri Aug 4 23:13:59 2017 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 4 Aug 2017 16:13:59 -0700 Subject: TLS 1.3 support in JDK In-Reply-To: References: Message-ID: <2d69ecf3-a00a-9b0f-1d04-cb7840e59784@oracle.com> Hi Neetish, > I am new to JDK development mailing list. 21 drafts fro TLS 1.3 have > come out so far. Is there any ongoing work on including TLS 1.3 in > JDK. If so, please refer. We are definitely monitoring the progress of the TLS 1.3 drafts as they make their way through the IETF standards process. Each draft has had fairly significant changes, making any intermediate draft implementation ephemeral and interoperability difficult. When the IETF TLS WG settles on a draft, and our plans become more concrete, we will definitely be sharing our thoughts on APIs and implementations on this list for review. > TLS 1.3 has been implemented in OpenSSL. Is there any way to use > OpenSSL in java in place of in-built SSL library. If you do a web search, you'll find prior efforts in this space, but we have not evaluated nor can we make any recommendations, especially as to whether any of these are current enough to suit your needs (e.g. 1.3draft-XX support). Thanks, Brad On 8/1/2017 9:21 PM, Neetish Pathak wrote: > Hello all, > I am new to JDK development mailing list. 21 drafts fro TLS 1.3 have > come out so far. Is there any ongoing work on including TLS 1.3 in JDK. > If so, please refer. > > TLS 1.3 has been implemented in OpenSSL. Is there any way to use OpenSSL > in java in place of in-built SSL library. > > Thanks > Best Regards, > Neetish From anders.rundgren.net at gmail.com Sat Aug 5 05:42:45 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Sat, 5 Aug 2017 07:42:45 +0200 Subject: Request - JavaScript Compatible Number Canonicalization Message-ID: <41fb5998-031d-0906-8acd-5f16f2c0c55f@gmail.com> This may not sound like a security related issue but it actually is... Although entirely uncoordinated, there are several "standards" in the workings based on creating JSON-based clear text alternatives to IETF's JWS signature scheme (which encodes data in Base64Url). All of these schemes share a common and quite intricate interoperability issue, namely serialization of the JSON "Number" type. Fortunately, ECMA who defines JavaScript have defined a strict format which is already implemented in Node.js (V8), Chrome, Firefox, and Safari. I would therefore propose that the Double object (Number are always stored as double) is augmented with an additional method like toJsonNotation(). I'm currently relying on code that was featured in a previous version of JDK (Rhino): https://github.com/cyberphone/openkeystore/blob/master/library/src/org/webpki/json/JSONObjectWriter.java#L188 Newer versions of JDK use another JS engine which produces non-compliant strings :-( WDYT? Anders https://cyberphone.github.io/doc/security/jsonsignatures.html From sha.jiang at oracle.com Mon Aug 7 05:03:00 2017 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 7 Aug 2017 13:03:00 +0800 Subject: RFR[10] 8185620: MSCAPI test leaves too many entries in keystore Message-ID: Hi, Test sun/security/mscapi/SmallPrimeExponentP.java adds some entries into Windows-MY keystore, but it doesn't delete them before exit. Please review this patch for the above issue. Webrev: http://cr.openjdk.java.net/~jjiang/8185620/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8185620 Best regards, John Jiang From adam.petcher at oracle.com Mon Aug 7 20:37:13 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Mon, 7 Aug 2017 16:37:13 -0400 Subject: JCA design for RFC 7748 Message-ID: I'm working on the Java implementation of RFC 7748 (Diffie-Hellman with X25519 and X448). I know some of you have been anxious to talk about how this would fit into JCA, and I appreciate your patience while I learned enough about JCA and existing crypto implementations to develop this API proposal. This API/design proposal is for RFC 7748 only, and it does not include the API for RFC 8032 (EdDSA). Of course, I expect many of the decisions that we make for RFC 7748 will also impact RFC 8032. First off, I think it is important to separate RFC 7748 from the existing ECDH API and implementation. RFC 7748 is a different standard, it uses different encodings and algorithms, and it has different properties. Further, this separation will reduce the probability of programming errors (e.g. accidentally interpreting a Weierstrass point as an RFC 7748 point). So I propose that we use distinct algorithm names for RFC 7748, and that we don't use any of the existing EC classes like EllipticCurve and ECPoint with RFC 7748. We can achieve this separation without duplicating a lot of code if we start with some simplifying assumptions. My goal is to remove functionality that nobody needs in order to simplify the design and API. If I am simplifying away something that you think you will need, please let me know. A) We don't need to expose actual curve parameters over the API. Curves can be specified using names (e.g. "X25519") or OIDs. The underlying implementation will likely support arbitrary Montgomery curves, but the JCA application will only be able to use the supported named curves. B) We don't need direct interoperability between different providers using opaque key representations. We can communicate with other providers using X509/PKCS8 encoding, or by using KeyFactory and key specs. These two assumptions greatly simplify the API. We won't need classes that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, ECPublicKey, etc. for X25519/X448. Now that the motivation and assumptions are out of the way, here is a description of the proposed JCA API: 1) The string "XDH" will be used in getInstance() to refer to all services related to RFC 7748 (KeyAgreement, KeyFactory, KeyPairGenerator, etc). This is a departure from the ECDH API that used "EC" for key generation (shared with ECDSA) and "ECDH" for KeyAgreement, and makes the RFC 7748 API more like "DiffieHellman" and other algorithms that use the same name for all services. 2) The new class java.security.spec.NamedParameterSpec (which implements AlgorithmParameterSpec) will be used to specify curves for RFC 7748. This class has a single String member which holds the name of the curve ("X25519" or "X448"). This parameter spec class can be reused by other crypto algorithms that similarly identify parameter sets using names (e.g. FFDHE3072 in DiffieHellman). This new class can be inserted into the hierarchy above ECGenParameterSpec. 3) There will be no classes in java.security.spec for EC public keys and private keys. An RFC 7748 implementation can use the existing classes X509EncodedKeySpec and PKCS8EncodedKeySpec for public and private key specs, respectively. 4) There will be no interfaces in java.security.interfaces for RFC 7748 public/private keys. Public/private key implementation classes will implement java.security.PublicKey and java.security.PrivateKey, which allows access to their encoded representations. Here is how the API will be implemented in the SunEC provider: 1) The public key and private key implementation classes will extend sun.security.ec.X509Key and sun.security.ec.PKCS8Key, respectively. This is similar to ECPublicKeyImpl and ECPrivateKeyImpl. 2) The KeyFactory for RFC 7748 will support translation to/from opaque keys and X509EncodedKeySpec/PKCS8EncodedKeySpec. Example code: KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH"); NamedParameterSpec paramSpec = new NamedParameterSpec("X25519"); kpg.initialize(paramSpec); // equivalent to kpg.initialize(255) KeyPair kp = kpg.generateKeyPair(); KeyFactory kf = KeyFactory.getInstance("XDH"); X509EncodedKeySpec pubSpec = ... PublicKey pubKey = kf.generatePublic(pubSpec); KeyAgreement ka = KeyAgreement.getInstance("XDH"); ka.init(kp.getPrivate()); ka.doPhase(pubKey, true); byte[] secret = ka.generateSecret(); One thing that is missing from the "core" API proposal is a way to easily produce a public/private key from an encoded numeric value. Of course, it's possible to put this value into a complete encoded X509/PKCS8 key, but that is not very convenient. Perhaps we can add another key spec class (that holds e.g. an AlgorithmParameterSpec and a byte array) to make this easier, but I don't know how valuable this would be. I appreciate any feedback the experts on the mailing list may have for me. Please let me know what you think. From mstjohns at comcast.net Mon Aug 7 21:52:28 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 7 Aug 2017 17:52:28 -0400 Subject: JCA design for RFC 7748 In-Reply-To: References: Message-ID: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> On 8/7/2017 4:37 PM, Adam Petcher wrote: > I'm working on the Java implementation of RFC 7748 (Diffie-Hellman > with X25519 and X448). I know some of you have been anxious to talk > about how this would fit into JCA, and I appreciate your patience > while I learned enough about JCA and existing crypto implementations > to develop this API proposal. This API/design proposal is for RFC 7748 > only, and it does not include the API for RFC 8032 (EdDSA). So you're expecting yet another set of APIs to cover those as well? Rather than one API to cover all of the new curves? Seems to be a bit short sighted. > Of course, I expect many of the decisions that we make for RFC 7748 > will also impact RFC 8032. > > First off, I think it is important to separate RFC 7748 from the > existing ECDH API and implementation. RFC 7748 is a different standard, It's still an elliptic curve. Note that there is already a worked example here - F2m vs Fp curves. > it uses different encodings and algorithms, From a JCA point of view, the public key gets encoded as an SubjectPublicKeyInfo and the private key gets encoded as a PKCS8 - that's for lots and lots of compatibility reasons. The public point of the public key might be encoded (inside the SPKI) as little endian OCTET STRING array vs a big endian ASN1 INTEGER, but its still just an integer internally. The algorithms are Key Agreement and Signature - those are at least what JCA will see them as. The actual KeyAgreement.getInstance("name") is of course going to be different than KeyAgreement.getInstance("ECDH") for example. > and it has different properties. Details please? Or do you mean that you can't use a given type of key for both key agreement and signature? > Further, this separation will reduce the probability of programming > errors (e.g. accidentally interpreting a Weierstrass point as an RFC > 7748 point). Um. What? It actually won't. > So I propose that we use distinct algorithm names for RFC 7748, Yes. > and that we don't use any of the existing EC classes like > EllipticCurve and ECPoint with RFC 7748. No. (My opinion but...) It's *hard* to add new meta classes for keys. Just considering the EC stuff you have ECKey, ECPublicKey, ECPrivateKey, EllipticCurve, ECPublicKeySpec, ECPrivateKeySpec, ECPoint, ECParameterSpec, ECGenParameterSpec, EllipticCurve and ECField (with ECFieldF2M and ECFieldF2P being the differentiator for all of the various keys within this space). > > We can achieve this separation without duplicating a lot of code if we > start with some simplifying assumptions. My goal is to remove > functionality that nobody needs in order to simplify the design and > API. If I am simplifying away something that you think you will need, > please let me know. There's a difference with what you do with the public API vs what you do with the plugin provider. Throwing away all of the "functionality that nobody needs" will probably come back to bite those who come later with something that looks *almost* like what you did, but needs just one more parameter than you were kind enough to leave behind. > > A) We don't need to expose actual curve parameters over the API. > Curves can be specified using names (e.g. "X25519") or OIDs. The > underlying implementation will likely support arbitrary Montgomery > curves, but the JCA application will only be able to use the supported > named curves. Strangely, this hasn't turned out all that well. There needs to be a name, OID in the public space (primarily for the encodings and PKIX stuff) and to be honest - you really want the parameters in public space as well (the ECParameterSpec and its ilk) so that a given key can be used with different providers or even to play around internally with new curves before giving them a name. > B) We don't need direct interoperability between different providers > using opaque key representations. We can communicate with other > providers using X509/PKCS8 encoding, or by using KeyFactory and key > specs. I don't actually understand that statement. Keys of different providers generally don't interoperate anyways, but you can mostly take an "encoded" one and create a new one in a new provider via the Keyfactory. KeySpecs provide you with a way of manually building a key - and that turns out to be VERY necessary, especially when you're dealing with adapting hardware modules to the JCA. > > These two assumptions greatly simplify the API. We won't need classes > that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, > ECPublicKey, etc. for X25519/X448. That assumption holds only if your various other assumptions hold. My opinion is that they probably don't. (BTW - I'm pretty sure, given that every single asymmetric JCA crypto api takes a PublicKey or PrivateKey you're going to need to mirror those classes at least; you'll also need a ParameterSpec and a GenParameterSpec class with whatever underlying supporting classes are required to deal with KeyFactory's) > > Now that the motivation and assumptions are out of the way, here is a > description of the proposed JCA API: I'd suggest getting agreement on the above before proceeding. Later, Mike From weijun.wang at oracle.com Tue Aug 8 05:49:52 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 8 Aug 2017 13:49:52 +0800 Subject: [10] RFR 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" Message-ID: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> Please review this trivial fix at http://cr.openjdk.java.net/~weijun/8185934/webrev.00/ KeyUtil.getSize() are also called elsewhere when they key is weak, where key length is not -1. Noreg-trivial. Thanks Max From anders.rundgren.net at gmail.com Tue Aug 8 06:31:10 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 8 Aug 2017 08:31:10 +0200 Subject: JCA design for RFC 7748 In-Reply-To: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> Message-ID: On 2017-08-07 23:52, Michael StJohns wrote: > On 8/7/2017 4:37 PM, Adam Petcher wrote: >> These two assumptions greatly simplify the API. We won't need classes >> that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, >> ECPublicKey, etc. for X25519/X448. > > That assumption holds only if your various other assumptions hold. My > opinion is that they probably don't. (BTW - I'm pretty sure, given that > every single asymmetric JCA crypto api takes a PublicKey or PrivateKey > you're going to need to mirror those classes at least; you'll also need > a ParameterSpec and a GenParameterSpec class with whatever underlying > supporting classes are required to deal with KeyFactory's) +1 There are virtually tons of third-party encryption libraries out there using a PublicKey as input argument but internally do things differently depending on if it is an RSAKey or ECKey. This is also needed for JSON (JWK) serialization. Anders https://github.com/cyberphone/java-cfrg-spec From sean.mullan at oracle.com Tue Aug 8 12:22:26 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Aug 2017 08:22:26 -0400 Subject: [10] RFR 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> References: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> Message-ID: <380ba09c-5611-6ebb-2231-cfb677925277@oracle.com> I don't think we should warn at all if the keysize cannot be determined or is inaccessible. The corresponding algorithm constraints checks don't restrict keys whose size cannot be determined, so keytool and jarsigner should be consistent. --Sean On 8/8/17 1:49 AM, Weijun Wang wrote: > Please review this trivial fix at > > http://cr.openjdk.java.net/~weijun/8185934/webrev.00/ > > KeyUtil.getSize() are also called elsewhere when they key is weak, where key length is not -1. > > Noreg-trivial. > > Thanks > Max > From weijun.wang at oracle.com Tue Aug 8 13:00:51 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 8 Aug 2017 21:00:51 +0800 Subject: [10] RFR 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <380ba09c-5611-6ebb-2231-cfb677925277@oracle.com> References: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> <380ba09c-5611-6ebb-2231-cfb677925277@oracle.com> Message-ID: <3F6ED926-FB63-4DA8-8B2D-D1F46FF0A04D@oracle.com> An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Tue Aug 8 13:17:35 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Aug 2017 09:17:35 -0400 Subject: [10] RFR 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <3F6ED926-FB63-4DA8-8B2D-D1F46FF0A04D@oracle.com> References: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> <380ba09c-5611-6ebb-2231-cfb677925277@oracle.com> <3F6ED926-FB63-4DA8-8B2D-D1F46FF0A04D@oracle.com> Message-ID: <160dd45e-48ba-a2ac-33aa-a4e9ae13a994@oracle.com> Ok, I got it now. The method name "withWeak" threw me off a bit. Fix looks good to me. --Sean On 8/8/17 9:00 AM, Weijun Wang wrote: > >> On Aug 8, 2017, at 8:22 PM, Sean Mullan wrote: >> >> I don't think we should warn at all if the keysize cannot be >> determined or is inaccessible. The corresponding algorithm constraints >> checks don't restrict keys whose size cannot be determined, so keytool >> and jarsigner should be consistent. > > This code change is not related to weak warnings. For jarsigner, it's > the signing history: > >> - Signed by "CN=a" >> Digest algorithm: SHA-256 >> Signature algorithm: SHA256withECDSA, -1-bit key > > For keytool, it's the keytool -list -v output: > >> Alias name: a >> ... >> Signature algorithm name: SHA256withECDSA >> Subject Public Key Algorithm: -1-bit EC key >> Version: 3 > > In fact, whenever the key size appears in a weak warning, as you said, > it's always a positive value that fails a constraint check. This is why > I said I haven't touched those KeyUtil.getSize() outputs. > > --Max > >> >> --Sean >> >> On 8/8/17 1:49 AM, Weijun Wang wrote: >>> Please review this trivial fix at >>> http://cr.openjdk.java.net/~weijun/8185934/webrev.00/ >>> KeyUtil.getSize() are also called elsewhere when they key is weak, >>> where key length is not -1. >>> Noreg-trivial. >>> Thanks >>> Max > From weijun.wang at oracle.com Tue Aug 8 13:36:15 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 8 Aug 2017 21:36:15 +0800 Subject: [10] RFR 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <160dd45e-48ba-a2ac-33aa-a4e9ae13a994@oracle.com> References: <98941350-CE67-474E-8BA3-2FCED23B01BD@oracle.com> <380ba09c-5611-6ebb-2231-cfb677925277@oracle.com> <3F6ED926-FB63-4DA8-8B2D-D1F46FF0A04D@oracle.com> <160dd45e-48ba-a2ac-33aa-a4e9ae13a994@oracle.com> Message-ID: <315EE076-8052-41F8-8FEE-76AD957D3D6F@oracle.com> > On Aug 8, 2017, at 9:17 PM, Sean Mullan wrote: > > Ok, I got it now. The method name "withWeak" threw me off a bit. Maybe it should be toStringWithPerhapsWeakLabel. --Max From adam.petcher at oracle.com Tue Aug 8 15:25:15 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 8 Aug 2017 11:25:15 -0400 Subject: JCA design for RFC 7748 In-Reply-To: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> Message-ID: <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Thanks for the feedback. See below for my responses. On 8/7/2017 5:52 PM, Michael StJohns wrote: > On 8/7/2017 4:37 PM, Adam Petcher wrote: >> I'm working on the Java implementation of RFC 7748 (Diffie-Hellman >> with X25519 and X448). I know some of you have been anxious to talk >> about how this would fit into JCA, and I appreciate your patience >> while I learned enough about JCA and existing crypto implementations >> to develop this API proposal. This API/design proposal is for RFC >> 7748 only, and it does not include the API for RFC 8032 (EdDSA). > > So you're expecting yet another set of APIs to cover those as well? > Rather than one API to cover all of the new curves? Seems to be a bit > short sighted. I'm expecting that we don't need to expose curve parameters/points in the API, so we won't need any new API for EdDSA, other than the algorithm name. If we decide we need to expose curve parameters, then we may want to back up and consider how EdDSA fits into this. > >> Of course, I expect many of the decisions that we make for RFC 7748 >> will also impact RFC 8032. >> >> First off, I think it is important to separate RFC 7748 from the >> existing ECDH API and implementation. RFC 7748 is a different standard, > > It's still an elliptic curve. Note that there is already a worked > example here - F2m vs Fp curves. > >> it uses different encodings and algorithms, > > From a JCA point of view, the public key gets encoded as an > SubjectPublicKeyInfo and the private key gets encoded as a PKCS8 - > that's for lots and lots of compatibility reasons. The public point > of the public key might be encoded (inside the SPKI) as little endian > OCTET STRING array vs a big endian ASN1 INTEGER, but its still just > an integer internally. > > The algorithms are Key Agreement and Signature - those are at least > what JCA will see them as. The actual > KeyAgreement.getInstance("name") is of course going to be different > than KeyAgreement.getInstance("ECDH") for example. > > >> and it has different properties. > > Details please? Or do you mean that you can't use a given type of key > for both key agreement and signature? Specifically, RFC 7748 resists (some) side-channel attacks and invalid-point attacks. The "ECDH" algorithm in JCA (PKCS#3) does not have these properties, so I want to make sure programmers don't get them confused. This difference in security properties partially motivates the use of a new algorithm name, rather than reusing "ECDH" for RFC 7748. > >> Further, this separation will reduce the probability of programming >> errors (e.g. accidentally interpreting a Weierstrass point as an RFC >> 7748 point). > > Um. What? It actually won't. This is the sort of problem I want to avoid: KeyPairGenerator kpg = KeyPairGenerator.getInstance("ECDH"); KeyPair kp = kpg.generateKeyPair(); KeyFactory eckf = KeyFactory.getInstance("ECDH"); ECPrivateKeySpec priSpec = eckf.getKeySpec(kf.getPrivate(), ECPrivateKeySpec.class); KeyFactory xdhkf = KeyFactory.getInstance("XDH"); PrivateKey xdhPrivate = xdhkf.generatePrivate(priSpec); // Now use xdhPrivate for key agreement, which uses the wrong algorithm and curve, and may leak information about the private key This sort of thing can happen if we use the existing EC spec classes for RFC 7748 (e.g. redefining what "a" and "b" mean in EllipticCurve when used with a Montgomery curve, leaving "y" null in ECPoint). Of course, we can prevent it by tagging these objects and checking the tags to make sure they are used with the correct algorithms, but I would prefer to use separate classes (if necessary) and let the type checker do this. My intention is that errors like the one above are impossible in my proposed design. We should be able to accomplish this by only using encoded key specs (which already have checking based on OID), or by using new classes, if this is necessary (and I hope it is not). > >> So I propose that we use distinct algorithm names for RFC 7748, > Yes. > >> and that we don't use any of the existing EC classes like >> EllipticCurve and ECPoint with RFC 7748. > No. (My opinion but...) It's *hard* to add new meta classes for > keys. Just considering the EC stuff you have ECKey, ECPublicKey, > ECPrivateKey, EllipticCurve, ECPublicKeySpec, ECPrivateKeySpec, > ECPoint, ECParameterSpec, ECGenParameterSpec, EllipticCurve and > ECField (with ECFieldF2M and ECFieldF2P being the differentiator for > all of the various keys within this space). > >> >> We can achieve this separation without duplicating a lot of code if >> we start with some simplifying assumptions. My goal is to remove >> functionality that nobody needs in order to simplify the design and >> API. If I am simplifying away something that you think you will need, >> please let me know. > > There's a difference with what you do with the public API vs what you > do with the plugin provider. Throwing away all of the > "functionality that nobody needs" will probably come back to bite > those who come later with something that looks *almost* like what you > did, but needs just one more parameter than you were kind enough to > leave behind. I agree, but we have to draw the line somewhere, and I think that line should be determined by the most common use cases. I would prefer to put in too little, and add more to the API later when people ask for it. Adding things to the API isn't trivial, but it is much easier than removing things that we don't need that are complicating the API and causing problems. > >> >> A) We don't need to expose actual curve parameters over the API. >> Curves can be specified using names (e.g. "X25519") or OIDs. The >> underlying implementation will likely support arbitrary Montgomery >> curves, but the JCA application will only be able to use the >> supported named curves. > > Strangely, this hasn't turned out all that well. There needs to be a > name, OID in the public space (primarily for the encodings and PKIX > stuff) and to be honest - you really want the parameters in public > space as well (the ECParameterSpec and its ilk) so that a given key > can be used with different providers or even to play around internally > with new curves before giving them a name. I don't understand why we need public curve parameters to allow keys to be used with different providers. It seems like this should work as long as the providers all understand the OIDs or curve names. Can you explain this part a bit more? Related to tinkering with new curves that don't have a name: I don't think that this is a feature that JCA needs to have. In the common use case, the programmer wants to only use standard algorithms and curves, and I think we should focus on that use case. > >> B) We don't need direct interoperability between different providers >> using opaque key representations. We can communicate with other >> providers using X509/PKCS8 encoding, or by using KeyFactory and key >> specs. > I don't actually understand that statement. Keys of different > providers generally don't interoperate anyways, but you can mostly > take an "encoded" one and create a new one in a new provider via the > Keyfactory. KeySpecs provide you with a way of manually building a > key - and that turns out to be VERY necessary, especially when you're > dealing with adapting hardware modules to the JCA. I'll admit that it is a strange statement. The only reason why I stated this assumption is that ECPublicKey and ECPrivateKey expose a lot of information that allows direct interoperability with opaque key objects (that implement these interfaces). I don't know if this is necessary/valuable, and I don't have any particular desire to allow the same thing with RFC 7748 keys. > >> >> These two assumptions greatly simplify the API. We won't need classes >> that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, >> ECPublicKey, etc. for X25519/X448. > > That assumption holds only if your various other assumptions hold. My > opinion is that they probably don't. (BTW - I'm pretty sure, given > that every single asymmetric JCA crypto api takes a PublicKey or > PrivateKey you're going to need to mirror those classes at least; > you'll also need a ParameterSpec and a GenParameterSpec class with > whatever underlying supporting classes are required to deal with > KeyFactory's) I agree with the second part of your parenthetical statement, but I need more information about the first. It sounds like what you are saying is that I will need something like XDHPublicKey and XDHPrivateKey in java.security.interfaces. Can you tell me why? What is it that we can't do without these interfaces? > >> >> Now that the motivation and assumptions are out of the way, here is a >> description of the proposed JCA API: > > I'd suggest getting agreement on the above before proceeding. > > Later, Mike > From anders.rundgren.net at gmail.com Tue Aug 8 15:45:59 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 8 Aug 2017 17:45:59 +0200 Subject: JCA design for RFC 7748 In-Reply-To: <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: On 2017-08-08 17:25, Adam Petcher wrote: > It sounds like what you are saying is > that I will need something like XDHPublicKey and XDHPrivateKey in > java.security.interfaces. Can you tell me why? What is it that we can't > do without these interfaces? Every JOSE Java library I have seen constructs and deconstructs RSA and EC keys based on JWK definitions. Maybe we don't need XDH keys but it would be nice to hear what the solution would be without such. Then there's lot of stuff out there like this which also needs some explanations on how to enhance with RFC7748 on board: Object myOwnEncrypt(PublicKey publicKey) throws SecurityException { if (publicKey instanceof RSAKey) { // RSA } else { // It should be EC } } CC:ing the creator of OKP keys. https://tools.ietf.org/html/rfc8037#section-2 Anders From mstjohns at comcast.net Tue Aug 8 16:50:32 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 8 Aug 2017 12:50:32 -0400 Subject: JCA design for RFC 7748 In-Reply-To: <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: On 8/8/2017 11:25 AM, Adam Petcher wrote: > Thanks for the feedback. See below for my responses. > > On 8/7/2017 5:52 PM, Michael StJohns wrote: >> On 8/7/2017 4:37 PM, Adam Petcher wrote: >>> I'm working on the Java implementation of RFC 7748 (Diffie-Hellman >>> with X25519 and X448). I know some of you have been anxious to talk >>> about how this would fit into JCA, and I appreciate your patience >>> while I learned enough about JCA and existing crypto implementations >>> to develop this API proposal. This API/design proposal is for RFC >>> 7748 only, and it does not include the API for RFC 8032 (EdDSA). >> >> So you're expecting yet another set of APIs to cover those as well? >> Rather than one API to cover all of the new curves? Seems to be a >> bit short sighted. > > I'm expecting that we don't need to expose curve parameters/points in > the API, so we won't need any new API for EdDSA, other than the > algorithm name. If we decide we need to expose curve parameters, then > we may want to back up and consider how EdDSA fits into this. We'll leave this for later. But generally, the JCA is a general interface to a set of crypto primitives modeled on just a few key types. To go in the direction you want to go it you need to explain why its impossible to model an elliptic curve as an elliptic curve. As I noted, I think that the inclusion of extension of ECField is probably all that's necessary for representing both public and private key pairs here. >> >>> Of course, I expect many of the decisions that we make for RFC 7748 >>> will also impact RFC 8032. >>> >>> First off, I think it is important to separate RFC 7748 from the >>> existing ECDH API and implementation. RFC 7748 is a different standard, >> >> It's still an elliptic curve. Note that there is already a worked >> example here - F2m vs Fp curves. >> >>> it uses different encodings and algorithms, >> >> From a JCA point of view, the public key gets encoded as an >> SubjectPublicKeyInfo and the private key gets encoded as a PKCS8 - >> that's for lots and lots of compatibility reasons. The public point >> of the public key might be encoded (inside the SPKI) as little endian >> OCTET STRING array vs a big endian ASN1 INTEGER, but its still just >> an integer internally. >> >> The algorithms are Key Agreement and Signature - those are at least >> what JCA will see them as. The actual >> KeyAgreement.getInstance("name") is of course going to be different >> than KeyAgreement.getInstance("ECDH") for example. >> >> >>> and it has different properties. >> >> Details please? Or do you mean that you can't use a given type of >> key for both key agreement and signature? > > Specifically, RFC 7748 resists (some) side-channel attacks and > invalid-point attacks. The "ECDH" algorithm in JCA (PKCS#3) does not > have these properties, so I want to make sure programmers don't get > them confused. This difference in security properties partially > motivates the use of a new algorithm name, rather than reusing "ECDH" > for RFC 7748. There is no problem with using new names for new algorithms - especially if the math is different. Ask the java folks to register the names as Standard Names. That's what will be used in the KeyAgreement.getInstance and Signature.getInstance calls. > >> >>> Further, this separation will reduce the probability of programming >>> errors (e.g. accidentally interpreting a Weierstrass point as an RFC >>> 7748 point). >> >> Um. What? It actually won't. > > This is the sort of problem I want to avoid: > > KeyPairGenerator kpg = KeyPairGenerator.getInstance("ECDH"); > KeyPair kp = kpg.generateKeyPair(); > KeyFactory eckf = KeyFactory.getInstance("ECDH"); > ECPrivateKeySpec priSpec = eckf.getKeySpec(kf.getPrivate(), > ECPrivateKeySpec.class); > > KeyFactory xdhkf = KeyFactory.getInstance("XDH"); > PrivateKey xdhPrivate = xdhkf.generatePrivate(priSpec); > > // Now use xdhPrivate for key agreement, which uses the wrong > algorithm and curve, and may leak information about the private key This is setting up a strawman and knocking it down. It's already possible to do the above with any software based key - either directly or by pulling out the data. Creating the API as you suggest will still not prevent this as long as I can retrieve the private value from the key. If you want absolute protection from this - go to hardware based keys. > > This sort of thing can happen if we use the existing EC spec classes > for RFC 7748 (e.g. redefining what "a" and "b" mean in EllipticCurve > when used with a Montgomery curve, leaving "y" null in ECPoint). Of > course, we can prevent it by tagging these objects and checking the > tags to make sure they are used with the correct algorithms, but I > would prefer to use separate classes (if necessary) and let the type > checker do this. That's the responsibility of the plugin provider - not the public API. > > My intention is that errors like the one above are impossible in my > proposed design. Nope. See above. > We should be able to accomplish this by only using encoded key specs > (which already have checking based on OID), or by using new classes, > if this is necessary (and I hope it is not). Nope. It doesn't work that way. Key spec's mostly don't do checking... the checking is done by the factory classes. > >> >>> So I propose that we use distinct algorithm names for RFC 7748, >> Yes. >> >>> and that we don't use any of the existing EC classes like >>> EllipticCurve and ECPoint with RFC 7748. >> No. (My opinion but...) It's *hard* to add new meta classes for >> keys. Just considering the EC stuff you have ECKey, ECPublicKey, >> ECPrivateKey, EllipticCurve, ECPublicKeySpec, ECPrivateKeySpec, >> ECPoint, ECParameterSpec, ECGenParameterSpec, EllipticCurve and >> ECField (with ECFieldF2M and ECFieldF2P being the differentiator for >> all of the various keys within this space). >> >>> >>> We can achieve this separation without duplicating a lot of code if >>> we start with some simplifying assumptions. My goal is to remove >>> functionality that nobody needs in order to simplify the design and >>> API. If I am simplifying away something that you think you will >>> need, please let me know. >> >> There's a difference with what you do with the public API vs what you >> do with the plugin provider. Throwing away all of the >> "functionality that nobody needs" will probably come back to bite >> those who come later with something that looks *almost* like what you >> did, but needs just one more parameter than you were kind enough to >> leave behind. > > I agree, but we have to draw the line somewhere, and I think that line > should be determined by the most common use cases. I would prefer to > put in too little, and add more to the API later when people ask for > it. Adding things to the API isn't trivial, but it is much easier than > removing things that we don't need that are complicating the API and > causing problems. Adding MANY different new APIs because you haven't done the work to harmonize them seems to be crossing the line substantially. Not explaining how > >> >>> >>> A) We don't need to expose actual curve parameters over the API. >>> Curves can be specified using names (e.g. "X25519") or OIDs. The >>> underlying implementation will likely support arbitrary Montgomery >>> curves, but the JCA application will only be able to use the >>> supported named curves. >> >> Strangely, this hasn't turned out all that well. There needs to be a >> name, OID in the public space (primarily for the encodings and PKIX >> stuff) and to be honest - you really want the parameters in public >> space as well (the ECParameterSpec and its ilk) so that a given key >> can be used with different providers or even to play around >> internally with new curves before giving them a name. > > I don't understand why we need public curve parameters to allow keys > to be used with different providers. It seems like this should work as > long as the providers all understand the OIDs or curve names. Can you > explain this part a bit more? Because names and OIDs get assigned later than the curve parameters. There are two parts to the JCA - the general crypto part and then there's the PKIX part. For the EC stuff, they sort of overlap because of a desire not to have to have everyone remember each of the parameter sets (curves) and those sets are tagged by name(s) and OID. But its still perfectly possible to do EC math on curves that were generated elsewhere (or even with a curve where everything but the basepoint is the same with a public curve). What you need to be able to do is to pass to an "older" provider a "newer" curve - assuming the curve fits within the math already implemented. There's really no good reason to implement a whole new set of API changes just to permit a single new curve. > > Related to tinkering with new curves that don't have a name: I don't > think that this is a feature that JCA needs to have. In the common use > case, the programmer wants to only use standard algorithms and curves, > and I think we should focus on that use case. The common use case is much wider than you think it is. I find myself using the curve parameters much more than I would like - specifically because I use JCA in conjunction with PKCS11, HSMs and smart cards. So no - focusing on a software only subset of things is really not the right approach. > >> >>> B) We don't need direct interoperability between different providers >>> using opaque key representations. We can communicate with other >>> providers using X509/PKCS8 encoding, or by using KeyFactory and key >>> specs. >> I don't actually understand that statement. Keys of different >> providers generally don't interoperate anyways, but you can mostly >> take an "encoded" one and create a new one in a new provider via the >> Keyfactory. KeySpecs provide you with a way of manually building a >> key - and that turns out to be VERY necessary, especially when you're >> dealing with adapting hardware modules to the JCA. > > I'll admit that it is a strange statement. The only reason why I > stated this assumption is that ECPublicKey and ECPrivateKey expose a > lot of information that allows direct interoperability with opaque key > objects (that implement these interfaces). I don't know if this is > necessary/valuable, and I don't have any particular desire to allow > the same thing with RFC 7748 keys. *sigh* Both of those classes allow for a full representation of the key in software. But the ECPrivateKey allows for the concept of a key handle that just references a hardware key without making the sensitive data accessible. E.g. getS() returns null or an exception (I wish this were better specified, but much of this is discussed in the JCA guide). Spec's ALWAYS provide a full non-opaque representation and are a required part of the JCA for key types. Key.getEncoded() usually provides a full non-opaque representation (e.g. SPKI or PKCS8 or just a byte array for SecretKeys) > >> >>> >>> These two assumptions greatly simplify the API. We won't need >>> classes that mirror ECParameterSpec, EllipticCurve, ECPoint, >>> ECField, ECPublicKey, etc. for X25519/X448. >> >> That assumption holds only if your various other assumptions hold. My >> opinion is that they probably don't. (BTW - I'm pretty sure, given >> that every single asymmetric JCA crypto api takes a PublicKey or >> PrivateKey you're going to need to mirror those classes at least; >> you'll also need a ParameterSpec and a GenParameterSpec class with >> whatever underlying supporting classes are required to deal with >> KeyFactory's) > > I agree with the second part of your parenthetical statement, but I > need more information about the first. It sounds like what you are > saying is that I will need something like XDHPublicKey and > XDHPrivateKey in java.security.interfaces. Can you tell me why? What > is it that we can't do without these interfaces? The method signatures for Signature.initSign(PrivateKey privateKey[,SecureRandom random]), Signature.initVerify(PublicKey publicKey) should give you a clue. E.g. the calls to the JCA provider classes require that you submit either a PublicKey or a PrivateKey. So you're going to need a concrete class with a subinterface that matches the key type needed by the signature instance that is a sub interface for PublicKey or PrivateKey. KeyAgreement requires a "Key" (both the public and private keys are passed in a Key's). KeyPairGenerator.init requires an AlgorithmParameter or a key size in bits. KeyFactory requires a KeySpec. Basically, you can't sign, perform a key agreement, generate a random key pair or generate a key from an encoded value without these classes. It's scary that you asked this question because it implies perhaps a need to spend a bit more time looking at the JCA and how its structured. Later, Mike > >> >>> >>> Now that the motivation and assumptions are out of the way, here is >>> a description of the proposed JCA API: >> >> I'd suggest getting agreement on the above before proceeding. >> >> Later, Mike >> > From adam.petcher at oracle.com Tue Aug 8 17:42:19 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 8 Aug 2017 13:42:19 -0400 Subject: JCA design for RFC 7748 In-Reply-To: References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: <51b26f40-e54f-17a1-6544-c5369ad6cffe@oracle.com> On 8/8/2017 11:45 AM, Anders Rundgren wrote: > On 2017-08-08 17:25, Adam Petcher wrote: > >> It sounds like what you are saying is >> that I will need something like XDHPublicKey and XDHPrivateKey in >> java.security.interfaces. Can you tell me why? What is it that we can't >> do without these interfaces? > > Every JOSE Java library I have seen constructs and deconstructs RSA > and EC keys > based on JWK definitions. Maybe we don't need XDH keys but it would > be nice to > hear what the solution would be without such. Of course, you could get the X.509 or PKCS#8 encoding of the key, and then convert that to JWK (I think all the information you need is in the algorithm ID), but that is not a very good solution. So perhaps it would be helpful to have an interface that exposes the key array along with its associated algorithm name and parameters. This would be similar to your OKP interface, but we can make it a bit more general so that it can be reused by other algorithms. We could also add interfaces for RFC 7748 public keys and private keys, but they wouldn't have any additional information, and I still don't know if they are needed. > > Then there's lot of stuff out there like this which also needs some > explanations on how to enhance with RFC7748 on board: > > Object myOwnEncrypt(PublicKey publicKey) throws SecurityException { > if (publicKey instanceof RSAKey) { > // RSA > } else { > // It should be EC > } > } Like before, there is a (not very good) solution using X.509 encoding, and a better solution involving a new interface that provides the required information. Something like: Object myOwnEncrypt(PublicKey publicKey) throws SecurityException { if (publicKey instanceof RSAKey) { // RSA } else if (publicKey instanceof ECKey) { // EC } else if (publicKey instanceof ByteArrayKey) { ByteArrayKey baKey = (ByteArrayKey)publicKey; if(baKey.getAlgorithm().equals("XDH") { // RFC 7748 } } } The ByteArrayKey would also hold a parameter spec that can be used to determine which curve is associated with the key. Would something like this work? > > CC:ing the creator of OKP keys. > > https://tools.ietf.org/html/rfc8037#section-2 > > Anders From xuelei.fan at oracle.com Tue Aug 8 19:42:33 2017 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 8 Aug 2017 12:42:33 -0700 Subject: JCA design for RFC 7748 In-Reply-To: References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: <12de3167-11ec-25e1-fa0d-4610b43b3e3c@oracle.com> On 8/8/2017 8:45 AM, Anders Rundgren wrote: > On 2017-08-08 17:25, Adam Petcher wrote: > >> It sounds like what you are saying is >> that I will need something like XDHPublicKey and XDHPrivateKey in >> java.security.interfaces. Can you tell me why? What is it that we can't >> do without these interfaces? > > Every JOSE Java library I have seen constructs and deconstructs RSA and > EC keys > based on JWK definitions. Maybe we don't need XDH keys but it would be > nice to > hear what the solution would be without such. > > Then there's lot of stuff out there like this which also needs some > explanations on how to enhance with RFC7748 on board: > > Object myOwnEncrypt(PublicKey publicKey) throws SecurityException { > if (publicKey instanceof RSAKey) { > // RSA > } else { > // It should be EC > } > } > The code above is not reliable unless one understand the underlying JCA/JCE provider behavior exactly this way. For a certain provider, an RSA key may be not an instance of RSAKey. I would use key.getAlgorithm() instead. Xuelei > CC:ing the creator of OKP keys. > > https://tools.ietf.org/html/rfc8037#section-2 > > Anders From adam.petcher at oracle.com Tue Aug 8 19:43:52 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 8 Aug 2017 15:43:52 -0400 Subject: JCA design for RFC 7748 In-Reply-To: References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com> On 8/8/2017 12:50 PM, Michael StJohns wrote: > > We'll leave this for later. But generally, the JCA is a general > interface to a set of crypto primitives modeled on just a few key > types. To go in the direction you want to go it you need to explain > why its impossible to model an elliptic curve as an elliptic curve. > As I noted, I think that the inclusion of extension of ECField is > probably all that's necessary for representing both public and private > key pairs here. The problem with the existing EC classes (EllipticCurve, ECPoint, etc.) is that they are intended to represent curves in Weierstrass form: y^2 = x^3 + ax + b. EllipticCurve has two parameters "a" and "b" corresponding to the coefficients in the equation above. RFC 7748 uses elliptic curves in Montgomery form: y^2 = x^3 + ax^2 + x. So the parameters are different. Further complicating things: every curve in Montgomery form has an isomorphic curve in Weierstrass form (but not vice-versa). So if we reuse EllipticCurve (and related classes), we could map the parameters onto Montgomery curve coefficients. For example interpret "a" as the second-degree coefficient instead of the first-degree coefficient, and ignore "b". But we have the problem that the programmer may not know when the parameters will be interpreted as Weierstrass coefficients instead of Montgomery coefficients. I am particularly concerned about this because these parameters were always interpreted as Weierstrass coefficients in the past. So we would want a way to tag the objects and check the tags to ensure that they are not misused. You suggested making new ECField subclasses for Montgomery/Edwards curves. The field used in RFC 7748/8032 is GF(p), which corresponds to the existing class ECFieldFp. So it seems strange and surprising to use this member to identify how coefficients should be interpreted, because this has nothing to do with the field. Though I can see why this approach is appealing, because the field is the only part of EllipticCurve that was designed to be extensible. If the coefficients (and their interpretation) were similarly extensible, then we wouldn't have these problems. In short: I'm not sure that reusing the existing EC classes is a good idea, because they were intended for something else, they are not general enough, and the potential for misuse/confusion is high. From anders.rundgren.net at gmail.com Tue Aug 8 20:05:21 2017 From: anders.rundgren.net at gmail.com (Anders Rundgren) Date: Tue, 8 Aug 2017 22:05:21 +0200 Subject: JCA design for RFC 7748 In-Reply-To: <12de3167-11ec-25e1-fa0d-4610b43b3e3c@oracle.com> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> <12de3167-11ec-25e1-fa0d-4610b43b3e3c@oracle.com> Message-ID: <2a2a3186-0e3f-b560-00e9-03ef18d42e99@gmail.com> On 2017-08-08 21:42, Xuelei Fan wrote: > On 8/8/2017 8:45 AM, Anders Rundgren wrote: >> Object myOwnEncrypt(PublicKey publicKey) throws SecurityException { >> if (publicKey instanceof RSAKey) { >> // RSA >> } else { >> // It should be EC >> } >> } >> > The code above is not reliable unless one understand the underlying > JCA/JCE provider behavior exactly this way. For a certain provider, an > RSA key may be not an instance of RSAKey. I would use > key.getAlgorithm() instead. You mean that some providers do not always adhere even to RSAPublicKey (which extends RSAKey)? Well, then there's a lot of broken stuff out there. Anders > > Xuelei > >> CC:ing the creator of OKP keys. >> >> https://tools.ietf.org/html/rfc8037#section-2 >> >> Anders From adam.petcher at oracle.com Tue Aug 8 21:00:36 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Tue, 8 Aug 2017 17:00:36 -0400 Subject: JCA design for RFC 7748 In-Reply-To: References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> Message-ID: <88cdc93a-413a-00c8-3a4a-b1e12d488a7e@oracle.com> On 8/8/2017 12:50 PM, Michael StJohns wrote: >>> >>>> Further, this separation will reduce the probability of programming >>>> errors (e.g. accidentally interpreting a Weierstrass point as an >>>> RFC 7748 point). >>> >>> Um. What? It actually won't. >> >> This is the sort of problem I want to avoid: >> >> KeyPairGenerator kpg = KeyPairGenerator.getInstance("ECDH"); >> KeyPair kp = kpg.generateKeyPair(); >> KeyFactory eckf = KeyFactory.getInstance("ECDH"); >> ECPrivateKeySpec priSpec = eckf.getKeySpec(kf.getPrivate(), >> ECPrivateKeySpec.class); >> >> KeyFactory xdhkf = KeyFactory.getInstance("XDH"); >> PrivateKey xdhPrivate = xdhkf.generatePrivate(priSpec); >> >> // Now use xdhPrivate for key agreement, which uses the wrong >> algorithm and curve, and may leak information about the private key > > This is setting up a strawman and knocking it down. It's already > possible to do the above with any software based key - either directly > or by pulling out the data. Creating the API as you suggest will > still not prevent this as long as I can retrieve the private value > from the key. > > If you want absolute protection from this - go to hardware based keys. The goal is the prevention of common programming errors that lead to security issues, not absolute protection like you would get from hardware crypto. More like the kind of assurance you get from a type system. >>>> >>>> A) We don't need to expose actual curve parameters over the API. >>>> Curves can be specified using names (e.g. "X25519") or OIDs. The >>>> underlying implementation will likely support arbitrary Montgomery >>>> curves, but the JCA application will only be able to use the >>>> supported named curves. >>> >>> Strangely, this hasn't turned out all that well. There needs to be >>> a name, OID in the public space (primarily for the encodings and >>> PKIX stuff) and to be honest - you really want the parameters in >>> public space as well (the ECParameterSpec and its ilk) so that a >>> given key can be used with different providers or even to play >>> around internally with new curves before giving them a name. >> >> I don't understand why we need public curve parameters to allow keys >> to be used with different providers. It seems like this should work >> as long as the providers all understand the OIDs or curve names. Can >> you explain this part a bit more? > Because names and OIDs get assigned later than the curve parameters. > There are two parts to the JCA - the general crypto part and then > there's the PKIX part. For the EC stuff, they sort of overlap because > of a desire not to have to have everyone remember each of the > parameter sets (curves) and those sets are tagged by name(s) and OID. > But its still perfectly possible to do EC math on curves that were > generated elsewhere (or even with a curve where everything but the > basepoint is the same with a public curve). > > What you need to be able to do is to pass to an "older" provider a > "newer" curve - assuming the curve fits within the math already > implemented. There's really no good reason to implement a whole new > set of API changes just to permit a single new curve. Okay, thanks. If I am reading this right, this feature supports interoperability with providers that don't know about a specific curve name/OID, but support all curves within some family. Without a way to express the curve parameters in JCA, you would resort to using some provider-specific parameter spec, which would be unfortunate. >> >> Related to tinkering with new curves that don't have a name: I don't >> think that this is a feature that JCA needs to have. In the common >> use case, the programmer wants to only use standard algorithms and >> curves, and I think we should focus on that use case. > > The common use case is much wider than you think it is. I find myself > using the curve parameters much more than I would like - specifically > because I use JCA in conjunction with PKCS11, HSMs and smart cards. > So no - focusing on a software only subset of things is really not the > right approach. I actually would have expected hardware crypto to have *less* support for arbitrary curves, and so this issue would come up more with software implementations. Why does this come up so frequently in hardware? > >> >>> >>>> >>>> These two assumptions greatly simplify the API. We won't need >>>> classes that mirror ECParameterSpec, EllipticCurve, ECPoint, >>>> ECField, ECPublicKey, etc. for X25519/X448. >>> >>> That assumption holds only if your various other assumptions hold. >>> My opinion is that they probably don't. (BTW - I'm pretty sure, >>> given that every single asymmetric JCA crypto api takes a PublicKey >>> or PrivateKey you're going to need to mirror those classes at least; >>> you'll also need a ParameterSpec and a GenParameterSpec class with >>> whatever underlying supporting classes are required to deal with >>> KeyFactory's) >> >> I agree with the second part of your parenthetical statement, but I >> need more information about the first. It sounds like what you are >> saying is that I will need something like XDHPublicKey and >> XDHPrivateKey in java.security.interfaces. Can you tell me why? What >> is it that we can't do without these interfaces? > > The method signatures for Signature.initSign(PrivateKey > privateKey[,SecureRandom random]), Signature.initVerify(PublicKey > publicKey) should give you a clue. E.g. the calls to the JCA provider > classes require that you submit either a PublicKey or a PrivateKey. > So you're going to need a concrete class with a subinterface that > matches the key type needed by the signature instance that is a sub > interface for PublicKey or PrivateKey. Does my Signature service need to support a public subinterface of (for example) PublicKey? At a minimum, I need a concrete class that implements PublicKey. This class could be entirely internal to my provider. In Signature.initVerify(PublicKey), I can check whether the provided key is an instance of my internal concrete class, and fail otherwise. In this circumstance, my concrete key class doesn't need to implement any public subinterface of PublicKey. The above arrangement basically works, but is it okay? Of course, objects of my concrete class could not be used by other providers, because they don't know how to interpret them. Is there some requirement or expectation of interoperability with other providers that I am missing? Another option to consider is that we don't have subinterfaces for RFC 7748 public/private keys, but rather we use some common subinterface that provides enough information (e.g. the encoded number and the curve parameters). > > KeyAgreement requires a "Key" (both the public and private keys are > passed in a Key's). > > KeyPairGenerator.init requires an AlgorithmParameter or a key size in > bits. > > KeyFactory requires a KeySpec. > > Basically, you can't sign, perform a key agreement, generate a random > key pair or generate a key from an encoded value without these classes. > > > It's scary that you asked this question because it implies perhaps a > need to spend a bit more time looking at the JCA and how its structured. > > > Later, Mike > From mstjohns at comcast.net Wed Aug 9 01:55:59 2017 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 8 Aug 2017 21:55:59 -0400 Subject: JCA design for RFC 7748 In-Reply-To: <88cdc93a-413a-00c8-3a4a-b1e12d488a7e@oracle.com> References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> <88cdc93a-413a-00c8-3a4a-b1e12d488a7e@oracle.com> Message-ID: On 8/8/2017 5:00 PM, Adam Petcher wrote: > On 8/8/2017 12:50 PM, Michael StJohns wrote: > >>>> >>>>> Further, this separation will reduce the probability of >>>>> programming errors (e.g. accidentally interpreting a Weierstrass >>>>> point as an RFC 7748 point). >>>> >>>> Um. What? It actually won't. >>> >>> This is the sort of problem I want to avoid: >>> >>> KeyPairGenerator kpg = KeyPairGenerator.getInstance("ECDH"); >>> KeyPair kp = kpg.generateKeyPair(); >>> KeyFactory eckf = KeyFactory.getInstance("ECDH"); >>> ECPrivateKeySpec priSpec = eckf.getKeySpec(kf.getPrivate(), >>> ECPrivateKeySpec.class); >>> >>> KeyFactory xdhkf = KeyFactory.getInstance("XDH"); >>> PrivateKey xdhPrivate = xdhkf.generatePrivate(priSpec); >>> >>> // Now use xdhPrivate for key agreement, which uses the wrong >>> algorithm and curve, and may leak information about the private key >> >> This is setting up a strawman and knocking it down. It's already >> possible to do the above with any software based key - either >> directly or by pulling out the data. Creating the API as you suggest >> will still not prevent this as long as I can retrieve the private >> value from the key. >> >> If you want absolute protection from this - go to hardware based keys. > > The goal is the prevention of common programming errors that lead to > security issues, not absolute protection like you would get from > hardware crypto. More like the kind of assurance you get from a type > system. The engine implementation (provider plugin) is responsible for preventing the "common programming errors", not the API. The JCA really doesn't have support for a type system style assurance. > > > >>>>> >>>>> A) We don't need to expose actual curve parameters over the API. >>>>> Curves can be specified using names (e.g. "X25519") or OIDs. The >>>>> underlying implementation will likely support arbitrary Montgomery >>>>> curves, but the JCA application will only be able to use the >>>>> supported named curves. >>>> >>>> Strangely, this hasn't turned out all that well. There needs to be >>>> a name, OID in the public space (primarily for the encodings and >>>> PKIX stuff) and to be honest - you really want the parameters in >>>> public space as well (the ECParameterSpec and its ilk) so that a >>>> given key can be used with different providers or even to play >>>> around internally with new curves before giving them a name. >>> >>> I don't understand why we need public curve parameters to allow keys >>> to be used with different providers. It seems like this should work >>> as long as the providers all understand the OIDs or curve names. Can >>> you explain this part a bit more? >> Because names and OIDs get assigned later than the curve parameters. >> There are two parts to the JCA - the general crypto part and then >> there's the PKIX part. For the EC stuff, they sort of overlap >> because of a desire not to have to have everyone remember each of the >> parameter sets (curves) and those sets are tagged by name(s) and >> OID. But its still perfectly possible to do EC math on curves that >> were generated elsewhere (or even with a curve where everything but >> the basepoint is the same with a public curve). >> >> What you need to be able to do is to pass to an "older" provider a >> "newer" curve - assuming the curve fits within the math already >> implemented. There's really no good reason to implement a whole new >> set of API changes just to permit a single new curve. > > Okay, thanks. If I am reading this right, this feature supports > interoperability with providers that don't know about a specific curve > name/OID, but support all curves within some family. Without a way to > express the curve parameters in JCA, you would resort to using some > provider-specific parameter spec, which would be unfortunate. Pretty much. This is why I've been pushing back so hard on "just one more key type" style arguments. > >>> >>> Related to tinkering with new curves that don't have a name: I don't >>> think that this is a feature that JCA needs to have. In the common >>> use case, the programmer wants to only use standard algorithms and >>> curves, and I think we should focus on that use case. >> >> The common use case is much wider than you think it is. I find >> myself using the curve parameters much more than I would like - >> specifically because I use JCA in conjunction with PKCS11, HSMs and >> smart cards. So no - focusing on a software only subset of things >> is really not the right approach. > > I actually would have expected hardware crypto to have *less* support > for arbitrary curves, and so this issue would come up more with > software implementations. Why does this come up so frequently in > hardware? Because the hardware tends to work either very generally or very specifically. A PKCS11 big iron HSM for example mostly doesn't do multiple curves and requires that you just give them the curve OID, but the JCOP smart cards work over a broad set of curves - as long as you give them the entire curve data set. But the JCOP cards don't do ASN1 so I keep getting to have to convert raw EC points into formatted EC public keys. One set of programs I have has to deal with at least three different representations - all of which are appropriate at various points. As it stands, I find the JCOP smart cards more flexible than the PKCS11 HSMs, but the PKCS11 HSMs more able to deal with large amounts of calculations (and generally better at keeping things secret than the smart cards). > >> >>> >>>> >>>>> >>>>> These two assumptions greatly simplify the API. We won't need >>>>> classes that mirror ECParameterSpec, EllipticCurve, ECPoint, >>>>> ECField, ECPublicKey, etc. for X25519/X448. >>>> >>>> That assumption holds only if your various other assumptions hold. >>>> My opinion is that they probably don't. (BTW - I'm pretty sure, >>>> given that every single asymmetric JCA crypto api takes a PublicKey >>>> or PrivateKey you're going to need to mirror those classes at >>>> least; you'll also need a ParameterSpec and a GenParameterSpec >>>> class with whatever underlying supporting classes are required to >>>> deal with KeyFactory's) >>> >>> I agree with the second part of your parenthetical statement, but I >>> need more information about the first. It sounds like what you are >>> saying is that I will need something like XDHPublicKey and >>> XDHPrivateKey in java.security.interfaces. Can you tell me why? What >>> is it that we can't do without these interfaces? >> >> The method signatures for Signature.initSign(PrivateKey >> privateKey[,SecureRandom random]), Signature.initVerify(PublicKey >> publicKey) should give you a clue. E.g. the calls to the JCA >> provider classes require that you submit either a PublicKey or a >> PrivateKey. So you're going to need a concrete class with a >> subinterface that matches the key type needed by the signature >> instance that is a sub interface for PublicKey or PrivateKey. > > Does my Signature service need to support a public subinterface of > (for example) PublicKey? At a minimum, I need a concrete class that > implements PublicKey. This class could be entirely internal to my > provider. In Signature.initVerify(PublicKey), I can check whether the > provided key is an instance of my internal concrete class, and fail > otherwise. In this circumstance, my concrete key class doesn't need to > implement any public subinterface of PublicKey. I think I understand what you're asking. Signature needs a PublicKey. PublicKey is an interface so you can "implement" just that interface in your concrete class. However, you should mostly NEVER be looking at whether or not a given key is an instance of a particular internal class as this will break at some point. Any implementation should be checking for public markers - either directly as an instance of ECPublicKey or indirectly looking at the parameter set of the public key. > > The above arrangement basically works, but is it okay? Of course, > objects of my concrete class could not be used by other providers, > because they don't know how to interpret them. Is there some > requirement or expectation of interoperability with other providers > that I am missing? There's somewhat of a contract that says that public keys should be convertible. So while you might get away with hiding the class info for a private key, you really should provide a mechanism for a common representation of the public keys so that things like signature verification just work across providers. > > Another option to consider is that we don't have subinterfaces for RFC > 7748 public/private keys, but rather we use some common subinterface > that provides enough information (e.g. the encoded number and the > curve parameters). > You mean like "ECKey"? This is implemented by both public and private EC keys and mostly contains the ECParameterSpec set. Mike From adam.petcher at oracle.com Wed Aug 9 12:55:28 2017 From: adam.petcher at oracle.com (Adam Petcher) Date: Wed, 9 Aug 2017 08:55:28 -0400 Subject: JCA design for RFC 7748 In-Reply-To: References: <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net> <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com> <88cdc93a-413a-00c8-3a4a-b1e12d488a7e@oracle.com> Message-ID: On 8/8/2017 9:55 PM, Michael StJohns wrote: >> >> Another option to consider is that we don't have subinterfaces for >> RFC 7748 public/private keys, but rather we use some common >> subinterface that provides enough information (e.g. the encoded >> number and the curve parameters). >> > > You mean like "ECKey"? This is implemented by both public and private > EC keys and mostly contains the ECParameterSpec set. Sort of. I'm trying to figure out how appropriate it is to have the equivalent of ECKey without the equivalent of ECPrivateKey and ECPublicKey. In this scenario, the equivalent of ECKey contains all the information about the public/private key (in RFC 7748, it's an integer in both cases). > > Mike > From sean.mullan at oracle.com Wed Aug 9 19:15:36 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 9 Aug 2017 15:15:36 -0400 Subject: CSR Review for 8159544: Remove deprecated classes in com.sun.security.auth.** Message-ID: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com> Max, Could you please review the following CSR: https://bugs.openjdk.java.net/browse/JDK-8186047 Thanks, Sean From weijun.wang at oracle.com Thu Aug 10 00:02:17 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Aug 2017 08:02:17 +0800 Subject: CSR Review for 8159544: Remove deprecated classes in com.sun.security.auth.** In-Reply-To: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com> References: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com> Message-ID: Looks fine. Should the specification part be formatted with 
 and fixed fonts?

Thanks
Max

> On Aug 10, 2017, at 3:15 AM, Sean Mullan  wrote:
> 
> Max,
> 
> Could you please review the following CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8186047
> 
> Thanks,
> Sean



From adam.petcher at oracle.com  Thu Aug 10 13:44:53 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 10 Aug 2017 09:44:53 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
Message-ID: <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>

Anyone have any additional thoughts on this?

I think the most significant item we need to discuss is the extent to 
which JCA should allow curve parameters for RFC 7748/8032 to be 
specified over the API. Does anyone know of a particular use case (that 
we haven't discuss already) that would require a provider to support 
arbitrary curves? Any other arguments for or against this feature?


On 8/7/2017 4:37 PM, Adam Petcher wrote:
> I'm working on the Java implementation of RFC 7748 (Diffie-Hellman 
> with X25519 and X448). I know some of you have been anxious to talk 
> about how this would fit into JCA, and I appreciate your patience 
> while I learned enough about JCA and existing crypto implementations 
> to develop this API proposal. This API/design proposal is for RFC 7748 
> only, and it does not include the API for RFC 8032 (EdDSA). Of course, 
> I expect many of the decisions that we make for RFC 7748 will also 
> impact RFC 8032.
>
> First off, I think it is important to separate RFC 7748 from the 
> existing ECDH API and implementation. RFC 7748 is a different 
> standard, it uses different encodings and algorithms, and it has 
> different properties. Further, this separation will reduce the 
> probability of programming errors (e.g. accidentally interpreting a 
> Weierstrass point as an RFC 7748 point). So I propose that we use 
> distinct algorithm names for RFC 7748, and that we don't use any of 
> the existing EC classes like EllipticCurve and ECPoint with RFC 7748.
>
> We can achieve this separation without duplicating a lot of code if we 
> start with some simplifying assumptions. My goal is to remove 
> functionality that nobody needs in order to simplify the design and 
> API. If I am simplifying away something that you think you will need, 
> please let me know.
>
> A) We don't need to expose actual curve parameters over the API. 
> Curves can be specified using names (e.g. "X25519") or OIDs. The 
> underlying implementation will likely support arbitrary Montgomery 
> curves, but the JCA application will only be able to use the supported 
> named curves.
> B) We don't need direct interoperability between different providers 
> using opaque key representations. We can communicate with other 
> providers using X509/PKCS8 encoding, or by using KeyFactory and key 
> specs.
>
> These two assumptions greatly simplify the API. We won't need classes 
> that mirror ECParameterSpec, EllipticCurve, ECPoint, ECField, 
> ECPublicKey, etc. for X25519/X448.
>
> Now that the motivation and assumptions are out of the way, here is a 
> description of the proposed JCA API:
>
> 1) The string "XDH" will be used in getInstance() to refer to all 
> services related to RFC 7748 (KeyAgreement, KeyFactory, 
> KeyPairGenerator, etc). This is a departure from the ECDH API that 
> used "EC" for key generation (shared with ECDSA) and "ECDH" for 
> KeyAgreement, and makes the RFC 7748 API more like "DiffieHellman" and 
> other algorithms that use the same name for all services.
> 2) The new class java.security.spec.NamedParameterSpec (which 
> implements AlgorithmParameterSpec) will be used to specify curves for 
> RFC 7748. This class has a single String member which holds the name 
> of the curve ("X25519" or "X448"). This parameter spec class can be 
> reused by other crypto algorithms that similarly identify parameter 
> sets using names (e.g. FFDHE3072 in DiffieHellman). This new class can 
> be inserted into the hierarchy above ECGenParameterSpec.
> 3) There will be no classes in java.security.spec for EC public keys 
> and private keys. An RFC 7748 implementation can use the existing 
> classes X509EncodedKeySpec and PKCS8EncodedKeySpec for public and 
> private key specs, respectively.
> 4) There will be no interfaces in java.security.interfaces for RFC 
> 7748 public/private keys. Public/private key implementation classes 
> will implement java.security.PublicKey and java.security.PrivateKey, 
> which allows access to their encoded representations.
>
> Here is how the API will be implemented in the SunEC provider:
>
> 1) The public key and private key implementation classes will extend 
> sun.security.ec.X509Key and sun.security.ec.PKCS8Key, respectively. 
> This is similar to ECPublicKeyImpl and ECPrivateKeyImpl.
> 2) The KeyFactory for RFC 7748 will support translation to/from opaque 
> keys and X509EncodedKeySpec/PKCS8EncodedKeySpec.
>
> Example code:
>
> KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
> NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
> kpg.initialize(paramSpec); // equivalent to kpg.initialize(255)
> KeyPair kp = kpg.generateKeyPair();
>
> KeyFactory kf = KeyFactory.getInstance("XDH");
> X509EncodedKeySpec pubSpec = ...
> PublicKey pubKey = kf.generatePublic(pubSpec);
>
> KeyAgreement ka = KeyAgreement.getInstance("XDH");
> ka.init(kp.getPrivate());
> ka.doPhase(pubKey, true);
> byte[] secret = ka.generateSecret();
>
>
> One thing that is missing from the "core" API proposal is a way to 
> easily produce a public/private key from an encoded numeric value. Of 
> course, it's possible to put this value into a complete encoded 
> X509/PKCS8 key, but that is not very convenient. Perhaps we can add 
> another key spec class (that holds e.g. an AlgorithmParameterSpec and 
> a byte array) to make this easier, but I don't know how valuable this 
> would be.
>
> I appreciate any feedback the experts on the mailing list may have for 
> me. Please let me know what you think.
>
>



From sean.mullan at oracle.com  Thu Aug 10 15:36:22 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 10 Aug 2017 11:36:22 -0400
Subject: CSR Review for 8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com>
 
Message-ID: 

On 8/9/17 8:02 PM, Weijun Wang wrote:
> Looks fine. Should the specification part be formatted with 
 and fixed fonts?

Fixed. Can you add your name as Reviewer (you need to edit the CSR and 
add your name to the "Reviewed By" box).

Thanks,
Sean

> 
> Thanks
> Max
> 
>> On Aug 10, 2017, at 3:15 AM, Sean Mullan  wrote:
>>
>> Max,
>>
>> Could you please review the following CSR:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8186047
>>
>> Thanks,
>> Sean
> 


From mstjohns at comcast.net  Thu Aug 10 16:25:48 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 10 Aug 2017 12:25:48 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
References: 
 <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
Message-ID: <85196933-c980-87cf-4ac9-710fcbc44b1c@comcast.net>

On 8/10/2017 9:44 AM, Adam Petcher wrote:
> Does anyone know of a particular use case (that we haven't discuss 
> already) that would require a provider to support arbitrary curves? 
> Any other arguments for or against this feature? 

There are uses for changing out the base point.  PAKE and SPAKE use 
similar math (e.g. G^s*sharedSecret is the equivalent of a new base point).

There are uses for private curves - e.g. when you want to actually be 
sure that the curve was randomly generated (sort of the same argument 
that got us to Curve25519 in the first place).

There are the whole set of Edwards curves that are mostly not included 
in any provider (except possible Microsoft's) as of yet.

Basically, you're trying to argue that there are no better curves (for 
the 'new' math) than have already been specified and there never will 
be.  I think that's a very shortsighted argument.

Later, Mike




From xuelei.fan at oracle.com  Thu Aug 10 19:10:59 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 10 Aug 2017 12:10:59 -0700
Subject: JCA design for RFC 7748
In-Reply-To: <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
Message-ID: 

Hi,

I want to extend the comment a little bit.

1. The background
A elliptic curve is determined by either an equation of form
      y^2 = x^3 + ax + b            (1) [Weierstrass form]
or
      y^2 + xy = x^3 + ax^2 + b.    (2)

However, some other forms may also be used.  For example:
      y^2 = x(x-1)(x-r)             (3)
or
      By^2 = x^3 + Ax^2 + x         (4) [RFC 7748, Montgomery curve]
      x^2 + y^2 = 1 + dx^2y^2       (5) [RFC 7748, Edwards curve]

In general, any elliptic curve can be written in Weierstrass form (1) or 
(2).  That's, Montgomery curve and Edwards curve can be expressed in 
Weierstrass form.

2. Where we are now?
In JDK, an elliptic curve is defined in the Weierstrass form ((1)/(2)). 
See java.security.spec.EllipticCurve:

     EllipticCurve?(ECField field, BigInteger a, BigInteger b)

In theory, the existing APIs can be used for RFC 7748, by converting the 
Montgomery curve and Edwards curve to the Weierstrass form.  However, 
the conversion can be misleading and complicate the implementation 
significantly.  For example, before using a point Weierstrass form (x, 
y), the implementation need to convert it to Montgomery curve (x', -) so 
as to use the fully potential of RFC 7748.   The curves returned in 
public APIs need to use (x, y), while the implementation need to use 
(x', y').  It's very confusing and the compatibility impact could be 
significant.  For example:

     public something(ECPublicKey ecPublicKey)  {
        // Problem: If no other information, it is unclear
        // whether the ecPublicKey can be used for a particular
        // signature verification or not when the RFC 7748/8032
        // get supported.

        // Problem: an old application may use ecPublicKey for
        // the old style operation, even the ecPublicKey is supposed
        // to be x25519.  It's not easy to control the behavior in
        // legacy application code, and may introduce unexpected
        // security issues.
     }

     public KeyAgreement getKeyAgreement(AlgorithmParameterSpec aps) {
        // Problem: the code bellow should be comment in the current
        // code.  However, the ECParameterSpec may not be able to use
        // for the old style "EC" key agreement.
        //
        // JDK crypto provider can take special action to avoid this
        // issue in the JCA/JCE implementation.  But it cannot be
        // granted other provider can do this as well, and old
        // provider may run into problems as well.
        if (aps instance of ECParameterSpec) {
            return KeyAgreement.getInstance("EC");
        }
     }

What's the problem with ECPublicKey/ECPrivateKey/ECKey? It's mainly 
about the ECParameterSpec:

      ECParameterSpec ECKey.getParams?()

and ECParameterSpec is using java.security.spec.EllipticCurve.  This 
design makes it pretty confusing to use ECPublicKey/ECPrivateKey/ECKey 
for RFC 7748 (Edwards curve form and Montgomery curve form).

Can EllipticCurve be extended to support more forms? The 
java.security.spec.EllipticCurve defines two methods to get the 
coefficients of Weierstrass form.
      public BigInteger getA()
      public BigInteger getB()

The 'A' and 'B' may not exist in other forms, for example the (3)(4)(5) 
forms above.  While, the spec might be able to be updated by throwing 
UnsupportedOperationException for getA() and getB() for the (3)(4)(5) 
forms, and define new extended classes for new forms, like:
      public MCEllipticCurve extends EllipticCurve   // Montgomery curve
      public EDEllipticCurve extends EllipticCurve   // Edwards curve

However, I'm not very sure of the compatibility impact (see above).

3. Where we are not now?
Using named curves is popular.  There is a ECGenParameterSpec class 
using named curves:
      ECGenParameterSpec? ecgp =
          new ECGenParameterSpec?(secp256r1);
      KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC");
      kpg.initialize(ecpg);
      KeyPair kp = kpg.generateKeyPair?();

      ECPublicKey pubKey = (ECPublicKey)kp.getPublic();
      String keyAlgorithm = pubKey.getAlgorithm?();  // "EC"

However, it is used for key generation only.  Once the keys are 
generated, there is no public API to know the name of the curve in 
ECKey.  ECKey.getAlgorithm() will return "EC" only.  If it is required 
to known whether a key is of a named curve, the solution is not 
straightforward.

4. A general proposal
Support named curves could be a solution for #2 and #3 concerns above. 
For named curves, the parameters are defined explicitly.  So, it is 
REQUIRED to have the public APIs for named curves' parameters any more. 
It can be something hidden in the implementation layer.  The key pair 
generation may looks like:

     KeyPairGenerator kpg =
         KeyPairGenerator.getInstance("ECWithSecp256k1");
     KeyPair kp = kpg.generateKeyPair?();

     PublicKey pubKey = kp.getPublic();
     String keyAlgorithm = pubKey.getAlgorithm?();  // "ECWithSecp256k1"

As no explicit parameters is required, the EllipticCurve issue for 
Edwards curve form and Montgomery curve form in #2 is not a issue any 
more here.

The compatibility impact is limited as the name "ECWithSecp256k1" is not 
used in the past, and the Weierstrass form APIs, like 
ECKey/ECParameterSpec/EllipticCurve, are not necessarily to be used in 
this solution.

The benefits: simplify the APIs for named curves (including the 
Weierstrass form), and simplify the support of named curves for Edwards 
curve form and Montgomery curve form.

The disadvantages: no support of arbitrary curves (no surprise as this 
is a named curve solution), and new learn curve to use this new solution.

5. Can be more aggressive?
It looks amazing to support arbitrary curves for Edwards curve form and 
Montgomery curve form, as JDK did for Weierstrass form.  However, 
because of the compatibility impact (see #2), a new set of algorithms 
names, interfaces and specs may be required.  It could be overloaded if 
the requirements are not so strong in practice.  If arbitrary curves 
support is strong, it can be re-considered in the future.

Per my understanding, supporting named curves and arbitrary curves can 
be two things, and can be considered in different stages.  However, the 
design needs to take care of the potential conflicts between the two 
solutions.

Thanks,
Xuelei

On 8/8/2017 12:43 PM, Adam Petcher wrote:
> On 8/8/2017 12:50 PM, Michael StJohns wrote:
> 
>>
>> We'll leave this for later.  But generally, the JCA is a general 
>> interface to a set of crypto primitives modeled on just a few key 
>> types.  To go in the direction you want to go it you need to explain 
>> why its impossible to model an elliptic curve as an elliptic curve. As 
>> I noted, I think that the inclusion of extension of ECField is 
>> probably all that's necessary for representing both public and private 
>> key pairs here.
> 
> The problem with the existing EC classes (EllipticCurve, ECPoint, etc.) 
> is that they are intended to represent curves in Weierstrass form: y^2 = 
> x^3 + ax + b. EllipticCurve has two parameters "a" and "b" corresponding 
> to the coefficients in the equation above. RFC 7748 uses elliptic curves 
> in Montgomery form: y^2 = x^3 + ax^2 + x. So the parameters are 
> different. Further complicating things: every curve in Montgomery form 
> has an isomorphic curve in Weierstrass form (but not vice-versa).
> 
> So if we reuse EllipticCurve (and related classes), we could map the 
> parameters onto Montgomery curve coefficients. For example interpret "a" 
> as the second-degree coefficient instead of the first-degree 
> coefficient, and ignore "b". But we have the problem that the programmer 
> may not know when the parameters will be interpreted as Weierstrass 
> coefficients instead of Montgomery coefficients. I am particularly 
> concerned about this because these parameters were always interpreted as 
> Weierstrass coefficients in the past.
> 
> So we would want a way to tag the objects and check the tags to ensure 
> that they are not misused. You suggested making new ECField subclasses 
> for Montgomery/Edwards curves. The field used in RFC 7748/8032 is GF(p), 
> which corresponds to the existing class ECFieldFp. So it seems strange 
> and surprising to use this member to identify how coefficients should be 
> interpreted, because this has nothing to do with the field. Though I can 
> see why this approach is appealing, because the field is the only part 
> of EllipticCurve that was designed to be extensible. If the coefficients 
> (and their interpretation) were similarly extensible, then we wouldn't 
> have these problems.
> 
> In short: I'm not sure that reusing the existing EC classes is a good 
> idea, because they were intended for something else, they are not 
> general enough, and the potential for misuse/confusion is high.
> 
> 


From mstjohns at comcast.net  Thu Aug 10 22:20:08 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 10 Aug 2017 18:20:08 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
Message-ID: 

Hi Xuelei -

Great analysis.

Some comments in line.

On 8/10/2017 3:10 PM, Xuelei Fan wrote:
> Hi,
>
> I want to extend the comment a little bit.
>
> 1. The background
> A elliptic curve is determined by either an equation of form
>      y^2 = x^3 + ax + b            (1) [Weierstrass form]
> or
>      y^2 + xy = x^3 + ax^2 + b.    (2)
>
> However, some other forms may also be used.  For example:
>      y^2 = x(x-1)(x-r)             (3)
> or
>      By^2 = x^3 + Ax^2 + x         (4) [RFC 7748, Montgomery curve]
>      x^2 + y^2 = 1 + dx^2y^2       (5) [RFC 7748, Edwards curve]
>
> In general, any elliptic curve can be written in Weierstrass form (1) 
> or (2).  That's, Montgomery curve and Edwards curve can be expressed 
> in Weierstrass form.
>
> 2. Where we are now?
> In JDK, an elliptic curve is defined in the Weierstrass form 
> ((1)/(2)). See java.security.spec.EllipticCurve:
>
>     EllipticCurve?(ECField field, BigInteger a, BigInteger b)
>
> In theory, the existing APIs can be used for RFC 7748, by converting 
> the Montgomery curve and Edwards curve to the Weierstrass form.  
> However, the conversion can be misleading and complicate the 
> implementation significantly.  For example, before using a point 
> Weierstrass form (x, y), the implementation need to convert it to 
> Montgomery curve (x', -) so as to use the fully potential of RFC 
> 7748.   The curves returned in public APIs need to use (x, y), while 
> the implementation need to use (x', y'). It's very confusing and the 
> compatibility impact could be significant.  For example:
>
>     public something(ECPublicKey ecPublicKey)  {
>        // Problem: If no other information, it is unclear
>        // whether the ecPublicKey can be used for a particular
>        // signature verification or not when the RFC 7748/8032
>        // get supported.
>
>        // Problem: an old application may use ecPublicKey for
>        // the old style operation, even the ecPublicKey is supposed
>        // to be x25519.  It's not easy to control the behavior in
>        // legacy application code, and may introduce unexpected
>        // security issues.
>     }
>
>     public KeyAgreement getKeyAgreement(AlgorithmParameterSpec aps) {
>        // Problem: the code bellow should be comment in the current
>        // code.  However, the ECParameterSpec may not be able to use
>        // for the old style "EC" key agreement.
>        //
>        // JDK crypto provider can take special action to avoid this
>        // issue in the JCA/JCE implementation.  But it cannot be
>        // granted other provider can do this as well, and old
>        // provider may run into problems as well.
>        if (aps instance of ECParameterSpec) {
>            return KeyAgreement.getInstance("EC");
>        }
>     }
>
> What's the problem with ECPublicKey/ECPrivateKey/ECKey? It's mainly 
> about the ECParameterSpec:
>
>      ECParameterSpec ECKey.getParams?()
>
> and ECParameterSpec is using java.security.spec.EllipticCurve. This 
> design makes it pretty confusing to use ECPublicKey/ECPrivateKey/ECKey 
> for RFC 7748 (Edwards curve form and Montgomery curve form).
>
> Can EllipticCurve be extended to support more forms? The 
> java.security.spec.EllipticCurve defines two methods to get the 
> coefficients of Weierstrass form.
>      public BigInteger getA()
>      public BigInteger getB()
>
> The 'A' and 'B' may not exist in other forms, for example the 
> (3)(4)(5) forms above.  While, the spec might be able to be updated by 
> throwing UnsupportedOperationException for getA() and getB() for the 
> (3)(4)(5) forms, and define new extended classes for new forms, like:
>      public MCEllipticCurve extends EllipticCurve   // Montgomery curve
>      public EDEllipticCurve extends EllipticCurve   // Edwards curve

Instead of converting, I was thinking about mapping.  E.g. Montgomery A 
and B matches the A and B of the curve.  But the "x" of the Montgomery 
point is just the "x" of the ECPoint with the "y" left as null.  For 
Edwards, it looks like you would map "d" to A. For [3] I'd map "r" to 
A.  I'd leave B as null for both- no reason to throw an unsupported 
exception as the code generally has a clue about what types of keys 
they're dealing with (or we provide a marker so they can figure it out).

The conversion in and out for points is a conversion from little endian 
to big endian and vice versa, but that only has to be done if you're 
importing or exporting a parameter set and that's an implementation 
issue not an API issue.

Basically, all the math is BigIntegers under the hood.  The curve25519 
RFC specifies an implementation that's little endian, but the actual 
math is just math and things like the public key is really just a 
BigInteger.

Old code would just continue to work - since it would not be using the 
new curves.  New code would have to look for the curve type marker (e.g. 
the ECField) if there was the possibility of confusion.


>
> However, I'm not very sure of the compatibility impact (see above).
>
> 3. Where we are not now?
> Using named curves is popular.  There is a ECGenParameterSpec class 
> using named curves:
>      ECGenParameterSpec? ecgp =
>          new ECGenParameterSpec?(secp256r1);
>      KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC");
>      kpg.initialize(ecpg);
>      KeyPair kp = kpg.generateKeyPair?();
>
>      ECPublicKey pubKey = (ECPublicKey)kp.getPublic();
>      String keyAlgorithm = pubKey.getAlgorithm?();  // "EC"
>
> However, it is used for key generation only.  Once the keys are 
> generated, there is no public API to know the name of the curve in 
> ECKey.  ECKey.getAlgorithm() will return "EC" only.  If it is required 
> to known whether a key is of a named curve, the solution is not 
> straightforward.

This ties back to "getEncoded()" representations.  Under the hood, if 
you do a getEncoded() there's a "which name does this parameter set 
match up to" search which checks various tables for an OID and uses that 
in an X.509 SPKI output object.  On input, the table lookup has to see 
whether or not it understands the curve OID (or the key type OID - 
depending).

To deal with this without having to modify the internal parameter tables 
I currently match keys against parameter sets that have known OIDs.

>
> 4. A general proposal
> Support named curves could be a solution for #2 and #3 concerns above. 
> For named curves, the parameters are defined explicitly. So, it is 
> REQUIRED to have the public APIs for named curves' parameters any 
> more. It can be something hidden in the implementation layer.  The key 
> pair generation may looks like:
>
>     KeyPairGenerator kpg =
>         KeyPairGenerator.getInstance("ECWithSecp256k1");
>     KeyPair kp = kpg.generateKeyPair?();
>
>     PublicKey pubKey = kp.getPublic();
>     String keyAlgorithm = pubKey.getAlgorithm?();  // "ECWithSecp256k1"
>
> As no explicit parameters is required, the EllipticCurve issue for 
> Edwards curve form and Montgomery curve form in #2 is not a issue any 
> more here.
>
> The compatibility impact is limited as the name "ECWithSecp256k1" is 
> not used in the past, and the Weierstrass form APIs, like 
> ECKey/ECParameterSpec/EllipticCurve, are not necessarily to be used in 
> this solution.
>
> The benefits: simplify the APIs for named curves (including the 
> Weierstrass form), and simplify the support of named curves for 
> Edwards curve form and Montgomery curve form.
>
> The disadvantages: no support of arbitrary curves (no surprise as this 
> is a named curve solution), and new learn curve to use this new solution.

Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) and at 
least 4 major representational domains (Raw, PKIX, XML and JSON).  In 
the current situation, I can take a JCA EC Public key and convert it to 
pretty much any of the other APIs or representations. For much of the 
hardware based stuff (ie, smart cards), I go straight from JCA into raw 
and vice versa.  Assuming you left the "getEncoded()" stuff in the API 
and the encoding was PKIX, I'd have to encode to PKIX, decode the PKIX 
to extract the actual raw key or encode a PKIX blob and hope that the 
KeyFactory stuff actually worked.

It's not just support of arbitrary keys, but the ability to convert 
things without having to do multiple steps or stages.

Your solution would probably work reasonably well for TLS or IPSEC - but 
would not work well for anything else.


>
> 5. Can be more aggressive?
> It looks amazing to support arbitrary curves for Edwards curve form 
> and Montgomery curve form, as JDK did for Weierstrass form. However, 
> because of the compatibility impact (see #2), a new set of algorithms 
> names, interfaces and specs may be required.  It could be overloaded 
> if the requirements are not so strong in practice.  If arbitrary 
> curves support is strong, it can be re-considered in the future.
>
> Per my understanding, supporting named curves and arbitrary curves can 
> be two things, and can be considered in different stages. However, the 
> design needs to take care of the potential conflicts between the two 
> solutions.

As I understand it, the JEP process takes some time and right now 
proposed changes *might* make it into JDK10?     Do you really want to 
do multiple JEPs to handle multiple new Edwards and Montgomery curves?

If we can hide most of this under the current EC covers, then the 
implementations can just implement the plugin interface and do that now.

Mike



>
> Thanks,
> Xuelei



From xuelei.fan at oracle.com  Thu Aug 10 23:36:08 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 10 Aug 2017 16:36:08 -0700
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
Message-ID: <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>

Hi Michael,

Good points!  See comments inlines.

On 8/10/2017 3:20 PM, Michael StJohns wrote:
> Hi Xuelei -
> 
> Great analysis.
> 
> Some comments in line.
> 
> On 8/10/2017 3:10 PM, Xuelei Fan wrote:
>> Hi,
>>
>> I want to extend the comment a little bit.
>>
>> 1. The background
>> A elliptic curve is determined by either an equation of form
>>      y^2 = x^3 + ax + b            (1) [Weierstrass form]
>> or
>>      y^2 + xy = x^3 + ax^2 + b.    (2)
>>
>> However, some other forms may also be used.  For example:
>>      y^2 = x(x-1)(x-r)             (3)
>> or
>>      By^2 = x^3 + Ax^2 + x         (4) [RFC 7748, Montgomery curve]
>>      x^2 + y^2 = 1 + dx^2y^2       (5) [RFC 7748, Edwards curve]
>>
>> In general, any elliptic curve can be written in Weierstrass form (1) 
>> or (2).  That's, Montgomery curve and Edwards curve can be expressed 
>> in Weierstrass form.
>>
>> 2. Where we are now?
>> In JDK, an elliptic curve is defined in the Weierstrass form 
>> ((1)/(2)). See java.security.spec.EllipticCurve:
>>
>>     EllipticCurve?(ECField field, BigInteger a, BigInteger b)
>>
>> In theory, the existing APIs can be used for RFC 7748, by converting 
>> the Montgomery curve and Edwards curve to the Weierstrass form. 
>> However, the conversion can be misleading and complicate the 
>> implementation significantly.  For example, before using a point 
>> Weierstrass form (x, y), the implementation need to convert it to 
>> Montgomery curve (x', -) so as to use the fully potential of RFC 
>> 7748.   The curves returned in public APIs need to use (x, y), while 
>> the implementation need to use (x', y'). It's very confusing and the 
>> compatibility impact could be significant.  For example:
>>
>>     public something(ECPublicKey ecPublicKey)  {
>>        // Problem: If no other information, it is unclear
>>        // whether the ecPublicKey can be used for a particular
>>        // signature verification or not when the RFC 7748/8032
>>        // get supported.
>>
>>        // Problem: an old application may use ecPublicKey for
>>        // the old style operation, even the ecPublicKey is supposed
>>        // to be x25519.  It's not easy to control the behavior in
>>        // legacy application code, and may introduce unexpected
>>        // security issues.
>>     }
>>
>>     public KeyAgreement getKeyAgreement(AlgorithmParameterSpec aps) {
>>        // Problem: the code bellow should be comment in the current
>>        // code.  However, the ECParameterSpec may not be able to use
>>        // for the old style "EC" key agreement.
>>        //
>>        // JDK crypto provider can take special action to avoid this
>>        // issue in the JCA/JCE implementation.  But it cannot be
>>        // granted other provider can do this as well, and old
>>        // provider may run into problems as well.
>>        if (aps instance of ECParameterSpec) {
>>            return KeyAgreement.getInstance("EC");
>>        }
>>     }
>>
>> What's the problem with ECPublicKey/ECPrivateKey/ECKey? It's mainly 
>> about the ECParameterSpec:
>>
>>      ECParameterSpec ECKey.getParams?()
>>
>> and ECParameterSpec is using java.security.spec.EllipticCurve. This 
>> design makes it pretty confusing to use ECPublicKey/ECPrivateKey/ECKey 
>> for RFC 7748 (Edwards curve form and Montgomery curve form).
>>
>> Can EllipticCurve be extended to support more forms? The 
>> java.security.spec.EllipticCurve defines two methods to get the 
>> coefficients of Weierstrass form.
>>      public BigInteger getA()
>>      public BigInteger getB()
>>
>> The 'A' and 'B' may not exist in other forms, for example the 
>> (3)(4)(5) forms above.  While, the spec might be able to be updated by 
>> throwing UnsupportedOperationException for getA() and getB() for the 
>> (3)(4)(5) forms, and define new extended classes for new forms, like:
>>      public MCEllipticCurve extends EllipticCurve   // Montgomery curve
>>      public EDEllipticCurve extends EllipticCurve   // Edwards curve
> 
> Instead of converting, I was thinking about mapping.  E.g. Montgomery A 
> and B matches the A and B of the curve.  But the "x" of the Montgomery 
> point is just the "x" of the ECPoint with the "y" left as null.  For 
> Edwards, it looks like you would map "d" to A. For [3] I'd map "r" to 
> A.  I'd leave B as null for both- no reason to throw an unsupported 
> exception as the code generally has a clue about what types of keys 
> they're dealing with (or we provide a marker so they can figure it out).
> 
> The conversion in and out for points is a conversion from little endian 
> to big endian and vice versa, but that only has to be done if you're 
> importing or exporting a parameter set and that's an implementation 
> issue not an API issue.
> 
> Basically, all the math is BigIntegers under the hood.  The curve25519 
> RFC specifies an implementation that's little endian, but the actual 
> math is just math and things like the public key is really just a 
> BigInteger.
> 
> Old code would just continue to work - since it would not be using the 
> new curves.  New code would have to look for the curve type marker (e.g. 
> the ECField) if there was the possibility of confusion.
> 
I understand your points.  The mapping may be confusing to application 
developers, but no problem for new codes if following the new coding 
guideline.  I'm not very sure of the old code, for similar reason to use 
the converting solution.

For example, an Edwards curve form of the SubjectPublicKeyInfo field in 
a X.509 cert is parsed as X509EncodedKeySpec, and "EC" KeyFactory is 
used to generate the ECPublicKey.  The algorithm name of the ECPublicKey 
instance is "EC", and the parameter is an instance of ECParameterSpec. 
Somehow, the ECPublicKey leave the key generation environment, and the 
curve OID is unknown in the new environment.  Then the public could be 
used improperly.  In the past, it's fine as the only supported form is 
Weierstrass form, there is no need to tell the curve forms in a crypto 
implementation.  However, when a new form is introduces, identify the EC 
form of a key is an essential part for the following crypto operations. 
Old providers or codes may not be able to tell the form, as may result 
in compatibility issues.

> 
>>
>> However, I'm not very sure of the compatibility impact (see above).
>>
>> 3. Where we are not now?
>> Using named curves is popular.  There is a ECGenParameterSpec class 
>> using named curves:
>>      ECGenParameterSpec? ecgp =
>>          new ECGenParameterSpec?(secp256r1);
>>      KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC");
>>      kpg.initialize(ecpg);
>>      KeyPair kp = kpg.generateKeyPair?();
>>
>>      ECPublicKey pubKey = (ECPublicKey)kp.getPublic();
>>      String keyAlgorithm = pubKey.getAlgorithm?();  // "EC"
>>
>> However, it is used for key generation only.  Once the keys are 
>> generated, there is no public API to know the name of the curve in 
>> ECKey.  ECKey.getAlgorithm() will return "EC" only.  If it is required 
>> to known whether a key is of a named curve, the solution is not 
>> straightforward.
> 
> This ties back to "getEncoded()" representations.  Under the hood, if 
> you do a getEncoded() there's a "which name does this parameter set 
> match up to" search which checks various tables for an OID and uses that 
> in an X.509 SPKI output object.  On input, the table lookup has to see 
> whether or not it understands the curve OID (or the key type OID - 
> depending).
> 
> To deal with this without having to modify the internal parameter tables 
> I currently match keys against parameter sets that have known OIDs.
> 
I see.

>>
>> 4. A general proposal
>> Support named curves could be a solution for #2 and #3 concerns above. 
>> For named curves, the parameters are defined explicitly. So, it is 
>> REQUIRED to have the public APIs for named curves' parameters any 
>> more. It can be something hidden in the implementation layer.  The key 
>> pair generation may looks like:
>>
>>     KeyPairGenerator kpg =
>>         KeyPairGenerator.getInstance("ECWithSecp256k1");
>>     KeyPair kp = kpg.generateKeyPair?();
>>
>>     PublicKey pubKey = kp.getPublic();
>>     String keyAlgorithm = pubKey.getAlgorithm?();  // "ECWithSecp256k1"
>>
>> As no explicit parameters is required, the EllipticCurve issue for 
>> Edwards curve form and Montgomery curve form in #2 is not a issue any 
>> more here.
>>
>> The compatibility impact is limited as the name "ECWithSecp256k1" is 
>> not used in the past, and the Weierstrass form APIs, like 
>> ECKey/ECParameterSpec/EllipticCurve, are not necessarily to be used in 
>> this solution.
>>
>> The benefits: simplify the APIs for named curves (including the 
>> Weierstrass form), and simplify the support of named curves for 
>> Edwards curve form and Montgomery curve form.
>>
>> The disadvantages: no support of arbitrary curves (no surprise as this 
>> is a named curve solution), and new learn curve to use this new solution.
> 
> Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) and at 
> least 4 major representational domains (Raw, PKIX, XML and JSON).  In 
> the current situation, I can take a JCA EC Public key and convert it to 
> pretty much any of the other APIs or representations. For much of the 
> hardware based stuff (ie, smart cards), I go straight from JCA into raw 
> and vice versa.  Assuming you left the "getEncoded()" stuff in the API 
> and the encoding was PKIX, I'd have to encode to PKIX, decode the PKIX 
> to extract the actual raw key or encode a PKIX blob and hope that the 
> KeyFactory stuff actually worked.
> 
> It's not just support of arbitrary keys, but the ability to convert 
> things without having to do multiple steps or stages.
> 
Good point!  It would be nice if transaction between two formats could 
be done simply.  Using X.509 encoding is doable as you said above, but 
maybe there are spaces to get improvements.

I need more time to think about it.  Please let me know if any one have 
a solution to simplify the transaction if keeping use the proposed named 
curves solution.

> Your solution would probably work reasonably well for TLS or IPSEC - but 
> would not work well for anything else.
> 
Properly a little bit more than TLS and IPSEC, but definitely not 
everything else.

> 
>>
>> 5. Can be more aggressive?
>> It looks amazing to support arbitrary curves for Edwards curve form 
>> and Montgomery curve form, as JDK did for Weierstrass form. However, 
>> because of the compatibility impact (see #2), a new set of algorithms 
>> names, interfaces and specs may be required.  It could be overloaded 
>> if the requirements are not so strong in practice.  If arbitrary 
>> curves support is strong, it can be re-considered in the future.
>>
>> Per my understanding, supporting named curves and arbitrary curves can 
>> be two things, and can be considered in different stages. However, the 
>> design needs to take care of the potential conflicts between the two 
>> solutions.
> 
> As I understand it, the JEP process takes some time and right now 
> proposed changes *might* make it into JDK10?     Do you really want to 
> do multiple JEPs to handle multiple new Edwards and Montgomery curves?
> 
It really depends per my understanding.  If I have a good idea, I would 
do it all in one JEP.  Otherwise, I may do it step by step so that the 
high priority requirements are not delayed before I have a mature 
solution to meet more requirements.

> If we can hide most of this under the current EC covers, then the 
> implementations can just implement the plugin interface and do that now.
> 
You are right.  If everything goes smoothly, no public APIs update is 
expected.  It's a kind of a provider implementation job, although some 
external algorithm names may be defined (like "ECWithSecp256k1" or 
"XDH") for this proposal.

Thanks & Regards,
Xuelei


From weijun.wang at oracle.com  Fri Aug 11 01:38:37 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 11 Aug 2017 09:38:37 +0800
Subject: CSR Review for 8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com>
 
 
Message-ID: <53C614E5-B4C0-4F33-8403-3A6B8420F39E@oracle.com>

Done.

Thanks
Max

> On Aug 10, 2017, at 11:36 PM, Sean Mullan  wrote:
> 
> On 8/9/17 8:02 PM, Weijun Wang wrote:
>> Looks fine. Should the specification part be formatted with 
 and fixed fonts?
> 
> Fixed. Can you add your name as Reviewer (you need to edit the CSR and add your name to the "Reviewed By" box).
> 
> Thanks,
> Sean
> 
>> Thanks
>> Max
>>> On Aug 10, 2017, at 3:15 AM, Sean Mullan  wrote:
>>> 
>>> Max,
>>> 
>>> Could you please review the following CSR:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8186047
>>> 
>>> Thanks,
>>> Sean



From mstjohns at comcast.net  Fri Aug 11 01:46:44 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 10 Aug 2017 21:46:44 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
Message-ID: 

On 8/10/2017 7:36 PM, Xuelei Fan wrote:
> Hi Michael,
>
> Good points!  See comments inlines.
>
> On 8/10/2017 3:20 PM, Michael StJohns wrote:
>>
>> Instead of converting, I was thinking about mapping.  E.g. Montgomery 
>> A and B matches the A and B of the curve.  But the "x" of the 
>> Montgomery point is just the "x" of the ECPoint with the "y" left as 
>> null.  For Edwards, it looks like you would map "d" to A. For [3] I'd 
>> map "r" to A.  I'd leave B as null for both- no reason to throw an 
>> unsupported exception as the code generally has a clue about what 
>> types of keys they're dealing with (or we provide a marker so they 
>> can figure it out).
>>
>> The conversion in and out for points is a conversion from little 
>> endian to big endian and vice versa, but that only has to be done if 
>> you're importing or exporting a parameter set and that's an 
>> implementation issue not an API issue.
>>
>> Basically, all the math is BigIntegers under the hood.  The 
>> curve25519 RFC specifies an implementation that's little endian, but 
>> the actual math is just math and things like the public key is really 
>> just a BigInteger.
>>
>> Old code would just continue to work - since it would not be using 
>> the new curves.  New code would have to look for the curve type 
>> marker (e.g. the ECField) if there was the possibility of confusion.
>>
> I understand your points.  The mapping may be confusing to application 
> developers, but no problem for new codes if following the new coding 
> guideline.  I'm not very sure of the old code, for similar reason to 
> use the converting solution.
>
> For example, an Edwards curve form of the SubjectPublicKeyInfo field 
> in a X.509 cert is parsed as X509EncodedKeySpec, and "EC" KeyFactory 
> is used to generate the ECPublicKey.  The algorithm name of the 
> ECPublicKey instance is "EC", and the parameter is an instance of 
> ECParameterSpec. Somehow, the ECPublicKey leave the key generation 
> environment, and the curve OID is unknown in the new environment.  
> Then the public could be used improperly.  In the past, it's fine as 
> the only supported form is Weierstrass form, there is no need to tell 
> the curve forms in a crypto implementation.  However, when a new form 
> is introduces, identify the EC form of a key is an essential part for 
> the following crypto operations. Old providers or codes may not be 
> able to tell the form, as may result in compatibility issues.

I don't think any of this is an issue.   An X509EncodedKeySpec for 
either type of key has a id-ecPublicKey OID identifying it (embedded in 
the SubjectPublicKeyInfo encoding).  In the key body, there's the 
EcpkParameters structure which is a 'namedCurve' which consists of an 
OID.  The curve OIDs for 25519 and 447 are different than any of the 
Weiserstrass keys.   When the KeyFactory factory implementation reads 
the byte stream its going to build a JCA ECPublicKey that matches the 
OID AND that's a concrete ECPublicKey class of the key factory provider.

If the factory implementation doesn't understand the oid, then the 
provider throws an error.  I forget which one.

The concrete class for the ECPublic key is specific to the provider.  
Some providers may support the new key forms, some may not.  There's no 
guarantee (and there never has been a guarantee) that an ECPublic key 
from one provider can be used with another provider (e.g. PKCS11 
provider vs a software provider) - you have to convert the key into a 
keyspec and then run the factory method on it.

So I don't think there's anything we have to worry about here - no 
violation of the API contract as far as I can tell.

(As a more complete example - consider what happens when you have an F2M 
EC provider and an Fp EC provider both generating public keys and 
encoding them.  Neither provider can decode the other's encoded key 
because they don't have the OIDs and the parameter sets).


>
>>
>>>
>>> However, I'm not very sure of the compatibility impact (see above).
>>>
>>> 3. Where we are not now?
>>> Using named curves is popular.  There is a ECGenParameterSpec class 
>>> using named curves:
>>>      ECGenParameterSpec? ecgp =
>>>          new ECGenParameterSpec?(secp256r1);
>>>      KeyPairGenerator kpg = KeyPairGenerator.getInstance("EC");
>>>      kpg.initialize(ecpg);
>>>      KeyPair kp = kpg.generateKeyPair?();
>>>
>>>      ECPublicKey pubKey = (ECPublicKey)kp.getPublic();
>>>      String keyAlgorithm = pubKey.getAlgorithm?();  // "EC"
>>>
>>> However, it is used for key generation only.  Once the keys are 
>>> generated, there is no public API to know the name of the curve in 
>>> ECKey.  ECKey.getAlgorithm() will return "EC" only. If it is 
>>> required to known whether a key is of a named curve, the solution is 
>>> not straightforward.
>>
>> This ties back to "getEncoded()" representations.  Under the hood, if 
>> you do a getEncoded() there's a "which name does this parameter set 
>> match up to" search which checks various tables for an OID and uses 
>> that in an X.509 SPKI output object.  On input, the table lookup has 
>> to see whether or not it understands the curve OID (or the key type 
>> OID - depending).
>>
>> To deal with this without having to modify the internal parameter 
>> tables I currently match keys against parameter sets that have known 
>> OIDs.
>>
> I see.
>
>>>
>>> 4. A general proposal
>>> Support named curves could be a solution for #2 and #3 concerns 
>>> above. For named curves, the parameters are defined explicitly. So, 
>>> it is REQUIRED to have the public APIs for named curves' parameters 
>>> any more. It can be something hidden in the implementation layer.  
>>> The key pair generation may looks like:
>>>
>>>     KeyPairGenerator kpg =
>>>         KeyPairGenerator.getInstance("ECWithSecp256k1");
>>>     KeyPair kp = kpg.generateKeyPair?();
>>>
>>>     PublicKey pubKey = kp.getPublic();
>>>     String keyAlgorithm = pubKey.getAlgorithm?();  // "ECWithSecp256k1"
>>>
>>> As no explicit parameters is required, the EllipticCurve issue for 
>>> Edwards curve form and Montgomery curve form in #2 is not a issue 
>>> any more here.
>>>
>>> The compatibility impact is limited as the name "ECWithSecp256k1" is 
>>> not used in the past, and the Weierstrass form APIs, like 
>>> ECKey/ECParameterSpec/EllipticCurve, are not necessarily to be used 
>>> in this solution.
>>>
>>> The benefits: simplify the APIs for named curves (including the 
>>> Weierstrass form), and simplify the support of named curves for 
>>> Edwards curve form and Montgomery curve form.
>>>
>>> The disadvantages: no support of arbitrary curves (no surprise as 
>>> this is a named curve solution), and new learn curve to use this new 
>>> solution.
>>
>> Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) and 
>> at least 4 major representational domains (Raw, PKIX, XML and JSON).  
>> In the current situation, I can take a JCA EC Public key and convert 
>> it to pretty much any of the other APIs or representations. For much 
>> of the hardware based stuff (ie, smart cards), I go straight from JCA 
>> into raw and vice versa. Assuming you left the "getEncoded()" stuff 
>> in the API and the encoding was PKIX, I'd have to encode to PKIX, 
>> decode the PKIX to extract the actual raw key or encode a PKIX blob 
>> and hope that the KeyFactory stuff actually worked.
>>
>> It's not just support of arbitrary keys, but the ability to convert 
>> things without having to do multiple steps or stages.
>>
> Good point!  It would be nice if transaction between two formats could 
> be done simply.  Using X.509 encoding is doable as you said above, but 
> maybe there are spaces to get improvements.
>
> I need more time to think about it.  Please let me know if any one 
> have a solution to simplify the transaction if keeping use the 
> proposed named curves solution.
>
>> Your solution would probably work reasonably well for TLS or IPSEC - 
>> but would not work well for anything else.
>>
> Properly a little bit more than TLS and IPSEC, but definitely not 
> everything else.
>
>>
>>>
>>> 5. Can be more aggressive?
>>> It looks amazing to support arbitrary curves for Edwards curve form 
>>> and Montgomery curve form, as JDK did for Weierstrass form. However, 
>>> because of the compatibility impact (see #2), a new set of 
>>> algorithms names, interfaces and specs may be required.  It could be 
>>> overloaded if the requirements are not so strong in practice.  If 
>>> arbitrary curves support is strong, it can be re-considered in the 
>>> future.
>>>
>>> Per my understanding, supporting named curves and arbitrary curves 
>>> can be two things, and can be considered in different stages. 
>>> However, the design needs to take care of the potential conflicts 
>>> between the two solutions.
>>
>> As I understand it, the JEP process takes some time and right now 
>> proposed changes *might* make it into JDK10?     Do you really want 
>> to do multiple JEPs to handle multiple new Edwards and Montgomery 
>> curves?
>>
> It really depends per my understanding.  If I have a good idea, I 
> would do it all in one JEP.  Otherwise, I may do it step by step so 
> that the high priority requirements are not delayed before I have a 
> mature solution to meet more requirements.

There's doing it quickly and doing it right.  Not sure you can have both.

>
>> If we can hide most of this under the current EC covers, then the 
>> implementations can just implement the plugin interface and do that now.
>>
> You are right.  If everything goes smoothly, no public APIs update is 
> expected.  It's a kind of a provider implementation job, although some 
> external algorithm names may be defined (like "ECWithSecp256k1" or 
> "XDH") for this proposal.

Yup - but that's a registry entry rather than an implementation change.


>
> Thanks & Regards,
> Xuelei




From xuelei.fan at oracle.com  Fri Aug 11 05:01:22 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 10 Aug 2017 22:01:22 -0700
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
Message-ID: <27f50579-cd58-0800-1137-fd2d0e03ad45@oracle.com>

On 8/10/2017 6:46 PM, Michael StJohns wrote:
> On 8/10/2017 7:36 PM, Xuelei Fan wrote:
>> Hi Michael,
>>
>> Good points!  See comments inlines.
>>
>> On 8/10/2017 3:20 PM, Michael StJohns wrote:
>>>
>>> Instead of converting, I was thinking about mapping.  E.g. Montgomery 
>>> A and B matches the A and B of the curve.  But the "x" of the 
>>> Montgomery point is just the "x" of the ECPoint with the "y" left as 
>>> null.  For Edwards, it looks like you would map "d" to A. For [3] I'd 
>>> map "r" to A.  I'd leave B as null for both- no reason to throw an 
>>> unsupported exception as the code generally has a clue about what 
>>> types of keys they're dealing with (or we provide a marker so they 
>>> can figure it out).
>>>
>>> The conversion in and out for points is a conversion from little 
>>> endian to big endian and vice versa, but that only has to be done if 
>>> you're importing or exporting a parameter set and that's an 
>>> implementation issue not an API issue.
>>>
>>> Basically, all the math is BigIntegers under the hood.  The 
>>> curve25519 RFC specifies an implementation that's little endian, but 
>>> the actual math is just math and things like the public key is really 
>>> just a BigInteger.
>>>
>>> Old code would just continue to work - since it would not be using 
>>> the new curves.  New code would have to look for the curve type 
>>> marker (e.g. the ECField) if there was the possibility of confusion.
>>>
>> I understand your points.  The mapping may be confusing to application 
>> developers, but no problem for new codes if following the new coding 
>> guideline.  I'm not very sure of the old code, for similar reason to 
>> use the converting solution.
>>
>> For example, an Edwards curve form of the SubjectPublicKeyInfo field 
>> in a X.509 cert is parsed as X509EncodedKeySpec, and "EC" KeyFactory 
>> is used to generate the ECPublicKey.  The algorithm name of the 
>> ECPublicKey instance is "EC", and the parameter is an instance of 
>> ECParameterSpec. Somehow, the ECPublicKey leave the key generation 
>> environment, and the curve OID is unknown in the new environment. Then 
>> the public could be used improperly.  In the past, it's fine as the 
>> only supported form is Weierstrass form, there is no need to tell the 
>> curve forms in a crypto implementation.  However, when a new form is 
>> introduces, identify the EC form of a key is an essential part for the 
>> following crypto operations. Old providers or codes may not be able to 
>> tell the form, as may result in compatibility issues.
> 
> I don't think any of this is an issue.   An X509EncodedKeySpec for 
> either type of key has a id-ecPublicKey OID identifying it (embedded in 
> the SubjectPublicKeyInfo encoding).  In the key body, there's the 
> EcpkParameters structure which is a 'namedCurve' which consists of an 
> OID.  The curve OIDs for 25519 and 447 are different than any of the 
> Weiserstrass keys.   When the KeyFactory factory implementation reads 
> the byte stream its going to build a JCA ECPublicKey that matches the 
> OID AND that's a concrete ECPublicKey class of the key factory provider.
> 
> If the factory implementation doesn't understand the oid, then the 
> provider throws an error.  I forget which one.
> > The concrete class for the ECPublic key is specific to the provider.
> Some providers may support the new key forms, some may not.  There's no 
> guarantee (and there never has been a guarantee) that an ECPublic key 
> from one provider can be used with another provider (e.g. PKCS11 
> provider vs a software provider) - you have to convert the key into a 
> keyspec and then run the factory method on it.
> 
I'm not sure of it.  JDK is a multiple providers framework.  A key 
generated in one provider may work in another provider, as if the 
conversion of the key works.  It's not rare that the public key is 
parsed by one provider, and used in another provider.  For some cases, 
we don't have conversion problem in the past as the key spec is clear. 
But for some other cases, we do have problems.  But if a case works in 
the past, we don't want to break it; otherwise, it might be a kind of 
compatibility issues.

As we discussed, there are multiple forms of EC curves.  EC curves form 
is an essential part of a EC key for following operation.  As if the EC 
curves form is unknown, there are potential problems.  When a old 
provider try to use a new provider generated keys for a new forms, 
problems happens.  This actually can be avoid if the old provider does 
not support this algorithm.  The "EC" name is too general to accept new 
forms.

> So I don't think there's anything we have to worry about here - no 
> violation of the API contract as far as I can tell.
> 
> (As a more complete example - consider what happens when you have an F2M 
> EC provider and an Fp EC provider both generating public keys and 
> encoding them.  Neither provider can decode the other's encoded key 
> because they don't have the OIDs and the parameter sets).
> 
If we define all of the forms at the same time, a provider would follow 
the specs, and no compatibility issues.  However, if we add something 
new later, and if the old one does not compatible with the new one, 
compatibility issues come.

For example,
    // Provider A supports KeyFactory
    KeyFactory kf = KeyFactory.getInstance("EC");
    ECPublicKey pubECKey = ... // use the KF above, new form key.

    // Provider A and B support "EC" signature, but B has the priority.
    // Provider B is an old provider.
    Signature sign = Signature.getInstacne("EC");  // Use provider B.
    sign.initVerify(pubECkey);    // the verification would fail

Suppose provider A and B are all good providers, the code above runs 
into problems.  The above code works with two old providers, and works 
with two new providers, but may not work if mixing old and new 
providers.  However, it is expected to work as one of the providers 
support the required features.

Xuelei


From adam.petcher at oracle.com  Fri Aug 11 14:57:22 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 11 Aug 2017 10:57:22 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
Message-ID: <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>

On 8/10/2017 9:46 PM, Michael StJohns wrote:

> On 8/10/2017 7:36 PM, Xuelei Fan wrote:
>>> Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) 
>>> and at least 4 major representational domains (Raw, PKIX, XML and 
>>> JSON).  In the current situation, I can take a JCA EC Public key and 
>>> convert it to pretty much any of the other APIs or representations. 
>>> For much of the hardware based stuff (ie, smart cards), I go 
>>> straight from JCA into raw and vice versa. Assuming you left the 
>>> "getEncoded()" stuff in the API and the encoding was PKIX, I'd have 
>>> to encode to PKIX, decode the PKIX to extract the actual raw key or 
>>> encode a PKIX blob and hope that the KeyFactory stuff actually worked.
>>>
>>> It's not just support of arbitrary keys, but the ability to convert 
>>> things without having to do multiple steps or stages.
>>>
>> Good point!  It would be nice if transaction between two formats 
>> could be done simply.  Using X.509 encoding is doable as you said 
>> above, but maybe there are spaces to get improvements.
>>
>> I need more time to think about it.  Please let me know if any one 
>> have a solution to simplify the transaction if keeping use the 
>> proposed named curves solution.
>>

I'm also coming to the conclusion that using X.509 encoding for this 
sort of interoperability is too onerous, and we should come up with 
something better. Maybe we should add a new general-purpose interface 
that exposes some structure in an algorithm-independent way. Something 
like this:

package java.security.interfaces;
public interface ByteArrayValue {

     String getAlgorithm();
     AlgorithmParameterSpec getParams();
     byte[] getValue();
}

The actual value is encoded, but the parameters are exposed, so this 
interface would work well for any value that is generally represented 
using a single encoded value (like public/private keys in RFC 7748, and 
8032). This could be used with the new NamedParameterSpec class to 
identify the parameters by name. It could also be used with other 
parameter specs to specify curve coefficients.

Of course, you may still need to look up curve name/OID/coefficients 
based on the parameters, but at least this solution provides direct 
access to the parameters and raw value, and you wouldn't need to go 
through X.509. Though perhaps this is less appropriate for SEC1 types 
and XML/JSON, because you would need to parse the value to extract the x 
and y coordinates. So using the existing ECKey for those types may make 
more sense.






From xuelei.fan at oracle.com  Fri Aug 11 15:24:03 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 11 Aug 2017 08:24:03 -0700
Subject: Code review request: JDK-8046295 - Support Trusted CA Indication
 extension
In-Reply-To: 
References: 
 
 
 
 <619b0a8b-5be7-1d29-6d8b-acf3cdc34a8c@oracle.com>
 
 <66aaaaad-175b-89f9-ba18-254b7881b0d1@oracle.com>
 
 <4d15dae7-e1a1-93ab-6b15-e95044c8f2f2@oracle.com>
 
 
 
 
Message-ID: 

Hi Martin,

Sorry for the delay.

I'd like to wait for finalization of TLS 1.3 specification, so that we 
can get a stable specification of the Certificate Authorities extension.

For the current design, I did not see much benefit to add a new 
CertificateAuthority API.  The CertificateAuthority.implies() may not 
yet reach the threshold to be a public API.  A trust/key manager can 
easily matching the distinguished name with the target certificate.  And 
I did not see the cert matching behavior differences between different 
providers and trust/key managers.

For the specification documentation part, I may suggest reword them a 
little bit so that those developers who are not TLS specification 
experts can easily catch the purpose or benefits of the API.

Xuelei

On 7/21/2017 7:20 AM, Martin Balao wrote:
> Webrev has been uploaded to cr.openjdk.java.net 
> :
> 
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/
>   * 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8046295/webrev.03/8046295.webrev.03.zip
> 
> Kind regards,
> Martin.-
> 
> On Tue, Jul 18, 2017 at 2:12 PM, Martin Balao  > wrote:
> 
>     Hi,
> 
>     Given that 1) Trusted CA Indication TLS Extension does not appear to
>     be widely implemented today and 2) it will be replaced by
>     Certificate Authorities TLS extension in TLS 1.3, it looks more
>     beneficial to me supporting only the latter -and avoid paying the
>     cost for a larger code-base-.
> 
>     Here it is my proposal for Certificate Authorities TLS extension:
> 
>       *
>     http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03/
>     
>     (browse online)
>       *
>     http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_07_18/8046295.webrev.03.zip
>     
>     (download)
> 
>     Implementation based on TLS 1.3 - draft 20 [1]. Patch based on
>     JDK-10 (rev 76ff72bb6a4a).
> 
>     Pending / blocked (in descending priority order):
> 
>     High
> 
>       * The extension applies only to TLSv1.3+
>        * Blocked because TLSv1.3 is still not supported in JSSE.
>        * Impact: the extension cannot be used in TLS 1.2 (high impact on
>     the client-side).
>        * Action: replace "useTLS12PlusSpec" with "useTLS13PlusSpec" in
>     the patch when available.
> 
>     Medium
> 
>       * Server can send the CertificateAuthorities extension to the
>     client in a CertificateRequest message (feature)
>        * Blocked by: Server is still not able to send
>     EncryptedExtensions message in CertificateRequest
>        * Impact: feature not supported on the server side. The extension
>     can still work in production environments. (medium).
>        * Action: implement EncryptedExtensions message in
>     CertificateRequest and then implement this feature.
> 
>     Low
> 
>       * Update documentation to refer the final TLS 1.3 RFC (draft 20 is
>     currently referred)
>        * Blocked by: publication of the final TLS 1.3 RFC
>        * Impact: documentation is not accurate. (low)
>        * Action: replace
>     "https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
>     "
>     with the final link in the patch.
> 
>       * Update bug id in "CertificateAuthoritiesClientTest.java" and
>     "CertificateAuthoritiesServerTest.java"
>        * Blocked by: there is no bug id for Certificate Authorities TLS
>     extension
>        * Impact: internal tests (very low).
>        * Action: replace "@bug 8046295" with the new bug id in the
>     patch. Open a new bug id for Certificate Authorities TLS extension.
>     Look forward to your comments.
> 
>     Kind regards,
>     Martin.-
> 
>     --
>     [1] -
>     https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4
>     
> 
>     On Tue, Jun 20, 2017 at 9:33 PM, Xuelei Fan      > wrote:
> 
>         Hi Martin,
> 
>         The TLS 1.3 spec is replacing the Trusted CA Indication
>         (trusted_ca_keys) extension with a new Certificate Authorities
>         (certificate_authorities) extension.  See more details about the
>         specification in the TLS 1.3 draft:
>         https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.4 
> 
>         Both serves a similar purpose, but the trusted_ca_keys extension
>         will not be used in TLS 1.3 any more.  The "trusted_ca_keys"
>         extension will only be used for legacy protocol versions (TLS
>         1.2/1.1/1.0).
> 
>         There are two options to me:
>         1. Supports the certificate_authorities, but not trusted_ca_keys
>         extension.
>         It is acceptable to me as trusted_ca_keys is for legacy use only
>         and the certificate_authorities extension is the future.  Plus,
>         the certificate_authorities extension can also be used for TLS
>         1.2 and previous versions.
> 
>         2. Supports both the certificate_authorities and trusted_ca_keys
>         extensions.
>         As far as I know, I did not see much benefit of this option
>         unless the trusted_ca_keys extension is widely used in practice.
> 
>         If I did not miss something, the APIs you designed can still be
>         used for the certificate_authorities extension, with a little
>         bit update.
> 
>         What do you think?
> 
>         Thanks & Regards,
>         Xuelei
> 
> 
>         On 6/15/2017 12:05 PM, Martin Balao wrote:
> 
>             Hi Xuelei,
> 
>             The new webrev.02 is ready:
> 
>                *
>             http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_15/8046295.webrev.02/
>             
>             (browse online)
>                *
>             http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_15/8046295.webrev.02.zip
>             
>             (zip, download)
> 
>             The following changes have been implemented since the
>             previous webrev.01:
> 
>                * s/getUseTrustedCAIndication() methods in
>             SSLEngine/SSLSocket and in SSLEngineImpl/SSLSocketImpl
>             removed. s/getSSLParameters is now the only way to set or
>             get the use of the Trusted CA Indication extension. An
>             exception is no longer thrown if trying to disable the
>             extension for a server, but the change takes no effect as
>             the extension is mandatory for servers. X509KeyManagerImpl
>             modified to use SSLParameters to get information regarding
>             if Trusted CA Indication is enabled and should guide the
>             certificate choice.
> 
>                * TrustedAuthorityIndicator.IdentifierType has been moved
>             from enum to String, to follow JSSE conventions. I
>             understand how important is to be consistent. However, I
>             still believe that an enum is a better fit for this value
>             and does not prevent from future extension. We are choosing
>             from a closed set (strictly defined by the RFC) and that's
>             what enum allows to express. From the client point of
>             view/API, it's very handy that the type gives you
>             information regarding the allowed choices for the parameter.
>             You don't necessarily have to look for implementation
>             details or documentation but you can just leverage on the
>             strongly typed language. It's also likely that enums are
>             faster for comparisons than strings, but that's not the main
>             point here.
> 
>                * Removed X509Certificate from TrustedAuthorityIndicator
>             class (method and property). It was there for informational
>             purposes (when TrustedAuthorityIndicator was built from a
>             certificate by a client and the whole extension indicators
>             converted to String).
> 
>                * "equals" and "hashCode" methods moved from
>             TrustedAuthorityIndicator to TrustedAuthorityIndicatorImpl
>             class.
> 
>                * "getLength" method removed from
>             TrustedAuthorityIndicator class. It's possible to get the
>             encoded buffer and the length from there.
> 
>                * "getData" method renamed to "getEncoded" in
>             TrustedAuthorityIndicator class.
> 
>                * "trustedAuthorityEncodedData" renamed to "encodedData"
>             in TrustedAuthorityIndicator and
>             TrustedAuthorityIndicatorImpl classes
> 
>                * "identifier" and "encodedData" instance variables moved
>             from TrustedAuthorityIndicator to
>             TrustedAuthorityIndicatorImpl class.
> 
>                * "getEncoded" and "getIdentifier" are now abstract
>             methods in TrustedAuthorityIndicator, and their
>             implementation is in TrustedAuthorityIndicatorImpl class.
> 
>                * "getIdentifier" method renamed to "getType" in
>             TrustedAuthorityIndicator and TrustedAuthorityIndicatorImpl
>             classes ("identifier" instance variable and parameter in
>             TrustedAuthorityIndicatorImpl class renamed to "type").
> 
>                * Test cases (server and client) updated to reflect the
>             new interface (enabling the use of the extension through
>             SSLParameters)
> 
>             However, some changes are still not implemented and I have
>             some concerns:
> 
>             1) I still believe that identifier type information has to
>             be on TrustedAuthorityIndicator class somehow, and
>             implementations restricted on what they can return as part
>             of "getType" method. This is strictly specified by the RFC
>             TrustedAuthorityIndicator class represents, and I find
>             desirable that any implementation is enforced to be
>             compliant to that. If we remove all of that (including the
>             enum), TrustedAuthorityIndicator looks too generic and does
>             not reflect (in my opinion) what it really is. It'd also be
>             chaotic if different implementations call pre-agreed type as
>             "preagreed", "pre-agreed", "PRE_AGREED", etc. I prefer
>             stricter and more explicit interfaces.
> 
>             2) I agree that type mappings can be seen as part of an
>             implementation, but they were in TrustedAuthorityIndicator
>             (as protected) because every implementation is highly likely
>             to need them and we can avoid the necessity for repeated
>             code/mappings. The same for "type" and "encodedData"
>             variables or even "hashCode" and "equals" methods. That's
>             why I was thinking more of an abstract class and not an
>             interface, as it happens (in example) with SNIServerName.
> 
>             3) I think that "implies" method on
>             TrustedAuthorityIndicator should be also part of the
>             class/interface, because that's the whole point of a Trusted
>             Authority Information: to allow queries for a given
>             certificate. This is, in fact, the only thing a server wants
>             from one of these objects. My concern is that if we remove
>             this requirement for an implementation, the interface looks
>             more like a byte buffer holder.
> 
>             I'd appreciate if you can re-consider these items.
> 
>             Thanks,
>             Martin.-
> 
>             On Wed, Jun 14, 2017 at 7:17 PM, Xuelei Fan
>             
>                          >> wrote:
> 
>                  Hi Martin,
> 
>                  The big picture of the design looks pretty good to me,
>             except a few
>                  comment about the JSSE conventions.  I appreciate it
>             very much.  By
>                  the way, I need more time to look into the details of the
>                  specification and implementation.
> 
> 
>                  In order to keep the APIs simple and small,
>             SSLParameters is
>                  preferred as the only configuration port for common
>             cases.   I may
>                  suggest to remove the s/getUseTrustedCAIndication()
>             methods in
>                  SSLEngine/SSLSocket.
> 
>                  The identify type is defined as an enum
>                  TrustedAuthorityIndicator.IdentifierType.  In the
>             future, if more
>                  type is added, we need to update the specification by
>             adding a new
>                  enum item.  Enum is preferred in JDK, but for good
>             extensibility, in
>                  general JSSE does not use enum in public APIs for
>             extensible
>                  properties.  I may suggest to use String (or
>             integer/byte, I prefer
>                  to use String) as the type.  The standard trusted authority
>                  indicator algorithm (identifier) can be documented in
>             the "Java
>                  Cryptography Architecture Standard Algorithm Name
>             Documentation"[1].
> 
>                  In TrustedAuthorityIndicator class, some methods, like
>                  getIdentifierTypeFromCode(),
>             getCodeFromIdentifierType(), implies(),
>                  getLength(), equals() and hashCode() look more like
>             implementation
>                  logic.  I may suggest remove them from public APIs.
> 
>                  I did not see the benefit to have X509Certificate in the
>                  TrustedAuthorityIndicator class.  The class is mainly
>             used for
>                  server side certificate selection.  X509Certificate
>             could be unknown
>                  for a indicator.  I may suggestion remove the related
>             methods and
>                  properties.
> 
>                  After that, as there is no requirement to instantiate
>                  TrustedAuthorityIndicator class in application code,
>             looks like it
>                  may be enough to use an interface to represent a
>             trusted authorities:
>                      public interface TrustedAuthorityIndicator {
>                           // identifier type, standard algorithm name
>                           String/int/Byte getType();
> 
>                           // identifier
>                           byte[] getEncoded();
>                      }
> 
>                  What do you think?
> 
> 
>                  Thanks & Regards,
>                  Xuelei
> 
>                  [1]
>             https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html
>             
>                 
>                          >
> 
> 
>                  On 6/13/2017 3:41 PM, Martin Balao wrote:
> 
>                      Hi Xuelei,
> 
>                      The new webrev.01 is ready:
> 
>                         *
>             http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01/
>             
>                     
>                          >
>                      (browse online)
>                         *
>             http://people.redhat.com/mbalaoal/webrevs/jdk_8046295_trusted_ca/2017_06_13/8046295.webrev.01.zip
>             
>                     
>                          >
>                      (zip, download)
> 
>                      The following changes have been implemented since
>             the previous
>                      webrev.00:
> 
>                         * Pre-agreed support removed from server-side
>                          * Unnecessary overhead and minium benefits for
>             JSSE.
> 
>                         * Enabling the use of Trusted CA Indication
>             extension for
>                      clients through TrustManager objects was reverted.
>             Trusted CA
>                      Indication extension can now be enabled through: 1)
>             SSLEngine,
>                      2) SSLSocket, or 3) SSLParameters (which can be
>             applied to both
>                      SSLEngine and SSLSocket objects). Trusted CA Indication
>                      extension is mandatory for servers.
> 
>                         * SunX509KeyManagerImpl old key manager
>             ("SunX509" algorithm)
>                      is now out of scope. This key manager does not
>             support other TLS
>                      extensions as Server Name Indication (SNI), which
>             is far more
>                      relevant than Trusted CA Indication. The new
>             X509KeyManagerImpl
>                      key manager ("PKIX" algorithm) is now in scope.
> 
>                         * Client requested indications are now an
>             ExtendedSSLSession
>                      attribute. ServerHandshaker gets the information
>             from the Client
>                      Hello message (now parsed by
>             TrustedCAIndicationExtension class
>                      instead of TrustedAuthorityIndicator) and sets it
>             in the
>                      ExtendedSSLSession (SSLSessionImpl object). The key
>             manager
>                      (i.e.: X509KeyManagerImpl), when choosing a server
>             alias, may
>                      now get the information from the ExtendedSSLSession
>             object and
>                      guide the certificate selection based on it.
>                          * In order to allow multiple key managers to
>             use Trusted
>                      Authority Indicators information and to allow
>             multiple Trusted
>                      Authority Indicators implementations,
>             TrustedAuthorityIndicator
>                      has now been split in an abstract class
>                      (TrustedAuthorityIndicator, located in
>             javax.net.ssl) and an
>                      implementation class
>             (TrustedAuthorityIndicatorImpl, located in
>                      sun.security.ssl). No coupling was added between
>             javax.net.ssl
>                      and sun.security.ssl packages.
> 
>                         * Documentation extended and improved.
>                         * Test cases (server and client) updated to
>             reflect the new
>                      interface and supported key manager.
> 
>                      Look forward to your new review!
> 
>                      Kind regards,
>                      Martin.-
> 
> 
> 
>                      On Fri, Jun 9, 2017 at 6:15 PM, Xuelei Fan
>                                                 >
>                                                 >>>
>                      wrote:
> 
>                           I'm OK to use SSLParameters.  Thank you very
>             much for
>                      considering a
>                           new design.
> 
>                           Xuelei
> 
>                           On 6/9/2017 1:10 PM, Martin Balao wrote:
> 
>                               Hi Xuelei,
> 
>                               I didn't notice that some of the SSLSocket
>             contructors
>                      did not
>                               establish the connection, so SSLParameters
>             can be
>                      effective for
>                               Trusted CA Indication. This was an invalid
>             argument on
>                      my side,
>                               sorry.
> 
>                               As for the configuration to enable the
>             extension, it's
>                      probably
>                               not necessary on the Server side because
>             -as you
>                      mentioned- it
>                               is mandatory and there is no harm in
>             supporting it.
>                      However, it
>                               has to be configurable on the Client side
>             because -as we
>                               previously discussed- the client may cause
>             a handshake
>                      failure
>                               if the server does not support the
>             extension. I'd
>                      prefer the
>                               Client configuring the SSLSocket through
>             SSLParameters
>                      instead
>                               of a system-wide property -which has even
>             more impact
>                      than the
>                               TrustManager approach-. Would this work
>             for you?
> 
>                                 > In JSSE, the benefits pre_agreed
>             option can get by
>                               customizing the key/trust manager, so I
>             did not see too
>                      much
>                               benefits to support this option in JDK
> 
>                               I understand your point and will remove
>             support for
>                      "pre_agreed".
> 
> 
>                               On Fri, Jun 9, 2017 at 1:37 AM, Xuelei Fan
>                                                          >
>                                                 >>
>                                            
>                                   >
>             
>                                   >>>>
>                               wrote:
> 
> 
> 
>                                    On 6/8/2017 8:36 PM, Xuelei Fan wrote:
> 
>                                        The trusted authorities can be
>             get from client
>                      trust
>                               manager.         Server can choose the
>             best matching of
>                      server
>                               certificate of the
>                                        client requested trusted authorities.
> 
>                                    >
>                                    I missed the point that the key
>             manager need to
>                      know the client
>                                    requested trusted authorities for the
>             choosing.         So may
>                               need a new
>                                    SSLSession attribute (See similar
>             method in
>                               ExtendedSSLSession).
> 
>                                    Xuelei
> 
> 
> 
>                               Yes, an attribute on SSLSession may do the
>             job (both
>                      when Key
>                               Manager receives a SSLSocket and a SSLEngine).
> 
>                               Kind regards,
>                               Martin.-
> 
> 
> 
> 
> 


From adam.petcher at oracle.com  Fri Aug 11 19:17:08 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 11 Aug 2017 15:17:08 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <85196933-c980-87cf-4ac9-710fcbc44b1c@comcast.net>
References: 
 <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
 <85196933-c980-87cf-4ac9-710fcbc44b1c@comcast.net>
Message-ID: <626a2e26-48ba-e945-78ef-4f8ebc171b12@oracle.com>

On 8/10/2017 12:25 PM, Michael StJohns wrote:

> On 8/10/2017 9:44 AM, Adam Petcher wrote:
>> Does anyone know of a particular use case (that we haven't discuss 
>> already) that would require a provider to support arbitrary curves? 
>> Any other arguments for or against this feature? 
>
> There are uses for changing out the base point.  PAKE and SPAKE use 
> similar math (e.g. G^s*sharedSecret is the equivalent of a new base 
> point).
>
> There are uses for private curves - e.g. when you want to actually be 
> sure that the curve was randomly generated (sort of the same argument 
> that got us to Curve25519 in the first place).
>
> There are the whole set of Edwards curves that are mostly not included 
> in any provider (except possible Microsoft's) as of yet.
>
> Basically, you're trying to argue that there are no better curves (for 
> the 'new' math) than have already been specified and there never will 
> be.  I think that's a very shortsighted argument.

I expect that new curves will be developed in the future, and the API 
should absolutely be designed in such a way that that support for new 
curves can be easily added to applications and providers. What I 
attempted to argue (I apologize if this was not clear) was that we don't 
necessarily need support for arbitrary curve parameters in the initial 
API design because:

1) When new, better curves are developed, they will eventually get 
names, and then they can be used in exactly the same way as the curves 
that exist today.
2) If there is a desire to allow arbitrary curve parameters for 
Montgomery/Edwards curves over the API, then we can consider this in the 
future as a separate feature. We should ensure that the initial API 
design accommodates the addition of this API in the future.


>
> Later, Mike
>
>



From jonathan.gibbons at oracle.com  Sat Aug 12 00:01:19 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Aug 2017 17:01:19 -0700
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
Message-ID: <598E454F.5020104@oracle.com>

Please review the following small fix for some accessibility issues in 
the java.security package.

3 tables are converted to the de-facto JDK standard for row-oriented 
tables, and updated
with appropriate scope=row|col attributes to identify the header cell in 
each row or column.
You can see the appearance of the updated tables in the API link below.

This is part of the ongoing effort to clean up all such issues in the 
JDK documentation.

JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
API: http://cr.openjdk.java.net/~jjg/8186160/api.00

-- Jon



From bradford.wetmore at oracle.com  Sat Aug 12 00:14:16 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 11 Aug 2017 17:14:16 -0700
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
In-Reply-To: <598E454F.5020104@oracle.com>
References: <598E454F.5020104@oracle.com>
Message-ID: 

Changes look good to me, although I'm not an HTML expert nor an expert 
in our current documentation style.  I did compare the output, and can 
see the effects.  (Striped, scope (row vs col), style)

Brad



On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
> Please review the following small fix for some accessibility issues in 
> the java.security package.
> 
> 3 tables are converted to the de-facto JDK standard for row-oriented 
> tables, and updated
> with appropriate scope=row|col attributes to identify the header cell in 
> each row or column.
> You can see the appearance of the updated tables in the API link below.
> 
> This is part of the ongoing effort to clean up all such issues in the 
> JDK documentation.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
> Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
> API: http://cr.openjdk.java.net/~jjg/8186160/api.00
> 
> -- Jon
> 


From jonathan.gibbons at oracle.com  Sat Aug 12 00:31:30 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 11 Aug 2017 17:31:30 -0700
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
In-Reply-To: 
References: <598E454F.5020104@oracle.com>
 
Message-ID: <598E4C62.80902@oracle.com>

Brad,

Thanks. I should have noted that the issues were detected by checking tools,
and that after the edits, no such issues were reported in this package.

FWIW, there is one remaining issue to be addressed: it is a broken link 
in Provider.html.
It comes from Provider.replace(Object, Object, Object) which overrides
Properties.replace(Object, Object, Object), but for some reason, that 
method is
marked @hidden in Properties, causing a broken link in Provider. That needs
to be investigated, but I don't want to block these accessibility fixes.

-- Jon


On 08/11/2017 05:14 PM, Bradford Wetmore wrote:
> Changes look good to me, although I'm not an HTML expert nor an expert 
> in our current documentation style.  I did compare the output, and can 
> see the effects.  (Striped, scope (row vs col), style)
>
> Brad
>
>
>
> On 8/11/2017 5:01 PM, Jonathan Gibbons wrote:
>> Please review the following small fix for some accessibility issues 
>> in the java.security package.
>>
>> 3 tables are converted to the de-facto JDK standard for row-oriented 
>> tables, and updated
>> with appropriate scope=row|col attributes to identify the header cell 
>> in each row or column.
>> You can see the appearance of the updated tables in the API link below.
>>
>> This is part of the ongoing effort to clean up all such issues in the 
>> JDK documentation.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8186160
>> Webrev: http://cr.openjdk.java.net/~jjg/8186160/webrev.00
>> API: http://cr.openjdk.java.net/~jjg/8186160/api.00
>>
>> -- Jon
>>



From anders.rundgren.net at gmail.com  Sat Aug 12 05:55:19 2017
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Sat, 12 Aug 2017 07:55:19 +0200
Subject: JCA design for RFC 7748
In-Reply-To: <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
Message-ID: <0b553059-ce6e-689d-dd7e-80e8e802b2c4@gmail.com>

Hi Guys,

whatever you come up with I anticipate it comes with descriptions
of how to use it as well. I would recommend putting the JEP on GitHub
(although this may not be the usual process), since this topic have
bearings on other crypto APIs in the workings.

I really hope that the end-result will turn out better than the quite quirky
EC support provided by JDK:
http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html

Regards,
Anders



From sha.jiang at oracle.com  Mon Aug 14 02:44:49 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 14 Aug 2017 10:44:49 +0800
Subject: RFR[10] 8185620: MSCAPI test leaves too many entries in keystore
In-Reply-To: 
References: 
Message-ID: <717c7686-c11b-0631-73d8-26a193eb6d2d@oracle.com>

Please review this fix.
Thanks!

John Jiang


On 07/08/2017 13:03, sha.jiang at oracle.com wrote:
> Hi,
> Test sun/security/mscapi/SmallPrimeExponentP.java adds some entries 
> into Windows-MY keystore, but it doesn't delete them before exit.
> Please review this patch for the above issue.
>
> Webrev: http://cr.openjdk.java.net/~jjiang/8185620/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8185620
>
> Best regards,
> John Jiang
>
>



From vincent.x.ryan at oracle.com  Mon Aug 14 09:30:14 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Mon, 14 Aug 2017 10:30:14 +0100
Subject: RFR[10] 8185620: MSCAPI test leaves too many entries in keystore
In-Reply-To: <717c7686-c11b-0631-73d8-26a193eb6d2d@oracle.com>
References: 
 <717c7686-c11b-0631-73d8-26a193eb6d2d@oracle.com>
Message-ID: 

Your fix looks good to me. Thanks.

> On 14 Aug 2017, at 03:44, sha.jiang at oracle.com wrote:
> 
> Please review this fix.
> Thanks!
> 
> John Jiang
> 
> 
> On 07/08/2017 13:03, sha.jiang at oracle.com wrote:
>> Hi,
>> Test sun/security/mscapi/SmallPrimeExponentP.java adds some entries into Windows-MY keystore, but it doesn't delete them before exit.
>> Please review this patch for the above issue.
>> 
>> Webrev: http://cr.openjdk.java.net/~jjiang/8185620/webrev.00/
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8185620
>> 
>> Best regards,
>> John Jiang
>> 
>> 
> 



From weijun.wang at oracle.com  Mon Aug 14 10:36:08 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 14 Aug 2017 18:36:08 +0800
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
In-Reply-To: <598E4C62.80902@oracle.com>
References: <598E454F.5020104@oracle.com>
  <598E4C62.80902@oracle.com>
Message-ID: 

> 
> FWIW, there is one remaining issue to be addressed: it is a broken link in Provider.html.
> It comes from Provider.replace(Object, Object, Object) which overrides
> Properties.replace(Object, Object, Object), but for some reason, that method is
> marked @hidden in Properties, causing a broken link in Provider. That needs
> to be investigated, but I don't want to block these accessibility fixes.

I don't understand why there is a @hidden in Properties.java. There are many other methods nearby with a similar structure and I cannot see how this one is different.

The tag was added at

   http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349

in the fix for 

   8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java

+
+    /** @hidden */
+    @Override
+    public synchronized boolean replace(Object key, Object oldValue, Object newValue) {
+        return map.replace(key, oldValue, newValue);
+    }

*Brent*: Is this method any special?

Thanks
Max

> 
> -- Jon




From niits23 at gmail.com  Wed Aug  2 03:47:16 2017
From: niits23 at gmail.com (Neetish Pathak)
Date: Tue, 1 Aug 2017 20:47:16 -0700
Subject: Fwd: TLS 1.3 support in JDK
In-Reply-To: <77390d7b-9843-db7f-465d-5b685a389ac6@oracle.com>
References: 
 <77390d7b-9843-db7f-465d-5b685a389ac6@oracle.com>
Message-ID: 

>
> Hello all,



> I am new to JDK development mailing list. 21 drafts fro TLS 1.3 have come
> out so far. Is there any ongoing work on including TLS 1.3 in JDK. If so,
> please refer.
>
> TLS 1.3 has been implemented in OpenSSL. Is there any way to use OpenSSL in

 java in place of in-built SSL library.

Best Regards,
Neetish Pathak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brent.christian at oracle.com  Mon Aug 14 17:02:36 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 14 Aug 2017 10:02:36 -0700
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
In-Reply-To: 
References: <598E454F.5020104@oracle.com>
  <598E4C62.80902@oracle.com>
 
Message-ID: <0e089273-2b16-0e36-8d6f-9034e2357fc2@oracle.com>

Hi, Max

This tag snuck in by mistake.  Before pushing the fix for JDK-8029891, 
we looked into ways to avoid addition of JavaDoc for all the
trivial method overrides.  I tried adding @hidden tags,
but they didn't do what we wanted, so they were taken out.  Except one - 
sorry about that.

-Brent

On 8/14/17 3:36 AM, Weijun Wang wrote:
>>
>> FWIW, there is one remaining issue to be addressed: it is a broken link in Provider.html.
>> It comes from Provider.replace(Object, Object, Object) which overrides
>> Properties.replace(Object, Object, Object), but for some reason, that method is
>> marked @hidden in Properties, causing a broken link in Provider. That needs
>> to be investigated, but I don't want to block these accessibility fixes.
> 
> I don't understand why there is a @hidden in Properties.java. There are many other methods nearby with a similar structure and I cannot see how this one is different.
> 
> The tag was added at
> 
>     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349
> 
> in the fix for
> 
>     8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
> 
> +
> +    /** @hidden */
> +    @Override
> +    public synchronized boolean replace(Object key, Object oldValue, Object newValue) {
> +        return map.replace(key, oldValue, newValue);
> +    }
> 
> *Brent*: Is this method any special?
> 
> Thanks
> Max
> 
>>
>> -- Jon
> 
> 


From brent.christian at oracle.com  Mon Aug 14 20:46:12 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 14 Aug 2017 13:46:12 -0700
Subject: RFR: JDK-8186160 Fix a11y issues in java.security package
In-Reply-To: <0e089273-2b16-0e36-8d6f-9034e2357fc2@oracle.com>
References: <598E454F.5020104@oracle.com>
  <598E4C62.80902@oracle.com>
 
 <0e089273-2b16-0e36-8d6f-9034e2357fc2@oracle.com>
Message-ID: 

FYI, I plan to fix this by way of:

https://bugs.openjdk.java.net/browse/JDK-8186217

Remove erroneous @hidden JavaDoc tag from 
java.util.Properties.replace(Object, Object, Object)

-Brent

On 8/14/17 10:02 AM, Brent Christian wrote:
> Hi, Max
> 
> This tag snuck in by mistake.  Before pushing the fix for JDK-8029891, 
> we looked into ways to avoid addition of JavaDoc for all the
> trivial method overrides.  I tried adding @hidden tags,
> but they didn't do what we wanted, so they were taken out.  Except one - 
> sorry about that.
> 
> -Brent
> 
> On 8/14/17 3:36 AM, Weijun Wang wrote:
>>>
>>> FWIW, there is one remaining issue to be addressed: it is a broken 
>>> link in Provider.html.
>>> It comes from Provider.replace(Object, Object, Object) which overrides
>>> Properties.replace(Object, Object, Object), but for some reason, that 
>>> method is
>>> marked @hidden in Properties, causing a broken link in Provider. That 
>>> needs
>>> to be investigated, but I don't want to block these accessibility fixes.
>>
>> I don't understand why there is a @hidden in Properties.java. There 
>> are many other methods nearby with a similar structure and I cannot 
>> see how this one is different.
>>
>> The tag was added at
>>
>>     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/01a8615439f0#l2.349
>>
>> in the fix for
>>
>>     8029891 : Deadlock detected in 
>> java/lang/ClassLoader/deadlock/GetResource.java
>>
>> +
>> +    /** @hidden */
>> +    @Override
>> +    public synchronized boolean replace(Object key, Object oldValue, 
>> Object newValue) {
>> +        return map.replace(key, oldValue, newValue);
>> +    }
>>
>> *Brent*: Is this method any special?
>>
>> Thanks
>> Max
>>
>>>
>>> -- Jon
>>
>>


From sha.jiang at oracle.com  Tue Aug 15 03:52:06 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 15 Aug 2017 11:52:06 +0800
Subject: RFR JDK-8179614: Test for jarsigner on verifying jars that are
 signed and timestamped by other JDK releases
In-Reply-To: <6666238f-825c-629f-dcc6-4f27a4df6c98@oracle.com>
References: 
 <5b75241c-1148-fe4f-bd6e-328f5737fed4@oracle.com>
 
 <7bf702ef-5ba4-e2b4-5b88-1c6ab222534f@oracle.com>
 
 <0fbe602f-6ba7-a05c-f163-9e15aeddeab4@oracle.com>
 <14c8a086-7e48-312b-3c15-917dcdc7061c@oracle.com>
 <0f0ce594-6ec3-0315-6627-a7cbe7cde294@oracle.com>
 <02569226-c63e-52ce-0519-e88cabde8358@oracle.com>
 <85acb154-534d-daa7-d200-c3bea4607de9@oracle.com>
 
 <4dae591e-12c5-c5de-fb6b-793d1b8b3d96@oracle.com>
 <6666238f-825c-629f-dcc6-4f27a4df6c98@oracle.com>
Message-ID: 

Hi,
The webrev [1] is updated on the following points:
1. It allows TSA URL to append a set of supported digest algorithms. If 
a TSA URL doesn't append the digests parameter, it means that the TSA 
supports SHA-1, SHA-256 and SHA-512.
2. EC cases are excluded for JDK 6.
3. Certificates are generated by the signer JDKs themselves respectively.
4. jarsigner uses option "-debug".
5. Test mode "strict" is removed.

[1] http://cr.openjdk.java.net/~jjiang/8179614/webrev.11/

Best regards,
John Jiang


On 14/07/2017 15:11, sha.jiang at oracle.com wrote:
>
> Hi,
> Please review the latest webrev at: 
> http://cr.openjdk.java.net/~jjiang/8179614/webrev.09/
> This test has been updated significantly. It removes useless case 
> combinations, and generates reports in HTML. For more details, please 
> look through the test summary.
>
> Best regards,
> John Jiang
>
> On 13/06/2017 23:47, sha.jiang at oracle.com wrote:
>> Sean and Max,
>> Please review this updated webrev: 
>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.03/
>>
>> The main changes are:
>> 1. It provides two new properties, tsaList and tsaListFile, for 
>> specifying a list of TSA services.
>> And a new report column [TSA] is introduced. This column just display 
>> the TSA indices and all of TSA services are displayed at the top of 
>> the report.
>> 2. If property strict is true, the cases on failed signing are not 
>> ignored. They still be listed in the test report, and the status of 
>> verifying are NONE.
>>
>> Best regards,
>> John Jiang
>>
>> On 13/06/2017 06:51, sha.jiang at oracle.com wrote:
>>> Hi Max,
>>>
>>> On 12/06/2017 17:29, Weijun Wang wrote:
>>>> Great. Only 2 questions:
>>>>
>>>>  459     // Return key sizes according to the specified key algorithm.
>>>>  460     private static int[] keySizes(String digestAlgorithm, 
>>>> String keyAlgorithm) {
>>>>  461         if (digestAlgorithm == DEFAULT) {
>>>>  462             return new int[] { 0 };
>>>>  463         }
>>>>  464
>>>>  465         if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
>>>>  466             return new int[] { 1024, 2048 };
>>>>  467         } else if (keyAlgorithm == EC) {
>>>>  468             return new int[] { 384, 571 };
>>>>  469         }
>>>>  470
>>>>  471         return null;
>>>>  472     }
>>>>
>>>> Why is keysize dependent on digestalg? I mean, is it possible to 
>>>> always return {1024,2048,0} and {384,571,0}?
>>> Get it, thanks!
>>>>
>>>>  379     // If signing fails, the following verifying has to
>>>>  380     // be ignored.
>>>>  381     if (signingStatus == STATUS.ERROR) {
>>>>  382         continue;
>>>>  383     }
>>>>
>>>> Now that you've already checked sigalg support earlier in what 
>>>> cases it could go wrong here?
>>> Jar signing still could fail. For example, TSA service is unavailable.
>>>
>>> Best regards,
>>> John Jiang
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>> On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
>>>>> Hi Max,
>>>>> Would you like to review the updated webrev: 
>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
>>>>> It can create certificate without -sigalg and -keysize, and jar 
>>>>> signing also can use this certificate.
>>>>>
>>>>> Best regards,
>>>>> John Jiang
>>>>>
>>>>> On 09/06/2017 22:04, Weijun Wang wrote:
>>>>>>
>>>>>> On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> On 09/06/2017 20:05, Weijun Wang wrote:
>>>>>>>> The test can be more friendly with default values.
>>>>>>>>
>>>>>>>> For example, in createCertificates(), you can generate certs 
>>>>>>>> that use default sigalg and keysize (i.e. without specifying 
>>>>>>>> -siglag and -keysize), and give them aliases with "default" or 
>>>>>>>> "null" inside.
>>>>>>>>
>>>>>>>> And in jar signing when signing with one -sigalg you can also 
>>>>>>>> choose cert generated with different or default sigalgs.
>>>>>>> I supposed this test just focus on signed jar verifying, but not 
>>>>>>> certificate creating and jar signing. So, I'm not sure such 
>>>>>>> cases are necessary.
>>>>>>
>>>>>> Well sometimes a test can do many things. If you only care about 
>>>>>> jar verification, why bother creating certs with different digest 
>>>>>> algorithms?
>>>>>>
>>>>>> On the other hand, if you do care about more, then in
>>>>>>
>>>>>>  338     // If the digest algorithm is not specified, then it
>>>>>>  339     // uses certificate with SHA256 digest and 1024 key
>>>>>>  340     // size.
>>>>>>  341     if (digestAlgorithm == DEFAULT) {
>>>>>>  342         certDigest = SHA256;
>>>>>>  343         certKeySize = 1024;
>>>>>>  344     }
>>>>>>
>>>>>> it seems a little awkward to hardcode the algorithm and keysize. 
>>>>>> If signing is using a default algorithm, it seems natural to use 
>>>>>> the cert that was generated with a default algorithm. In fact, 
>>>>>> this test case is quite useful that it ensures our different 
>>>>>> tools are using the same (or at least interoperable) default 
>>>>>> algorithms.
>>>>>>
>>>>>> --Max
>>>>>>
>>>>>>>>
>>>>>>>> BTW, I remember certain pairs of -keysize and -sigalg do not 
>>>>>>>> work together. For example, 1024 bit of DSA key cannot be used 
>>>>>>>> with SHA512withDSA signature algorithm. Have you noticed it?
>>>>>>> It looks SHA512withDSA is not supported yet.
>>>>>>> I was using JDK10 build 10. When the test tried to create 
>>>>>>> certificate with -keyalg DSA -sigalg SHA512withDSA -keysize 
>>>>>>> 1024, the below error raised:
>>>>>>> keytool error: java.security.NoSuchAlgorithmException: 
>>>>>>> unrecognized algorithm name: SHA512withDSA
>>>>>>>
>>>>>>> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the error 
>>>>>>> was:
>>>>>>> keytool error: java.security.InvalidKeyException: The security 
>>>>>>> strength of SHA-1 digest algorithm is not sufficient for this 
>>>>>>> key size
>>>>>>>
>>>>>>> Again, this test focus on signed jar verifying. If some problems 
>>>>>>> are raised on certificate creating or jar signing, the 
>>>>>>> associated verifying cases will be ignored.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> John Jiang
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Max
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>>>>>>>> Hi Sean and Max,
>>>>>>>>> Thanks for your comments.
>>>>>>>>> Please review the updated webrev: 
>>>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>>>>>>>
>>>>>>>>> The test has been modified significantly. The main points are:
>>>>>>>>> 1. Adds cases on EC. Now the test supports key algorithms RSA, 
>>>>>>>>> DSA and EC.
>>>>>>>>> 2. Adds cases on SHA-512. Now the test supports digest 
>>>>>>>>> algorithms SHA-1, SHA-256 and SHA-512.
>>>>>>>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, [1024, 
>>>>>>>>> 2048] for RSA and DSA.
>>>>>>>>> 4. Adds cases on default signature algorithm. Now the test 
>>>>>>>>> report can display the default algorithmat column [Signature 
>>>>>>>>> Algorithm].
>>>>>>>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for 
>>>>>>>>> keytool and jarsigner commands.
>>>>>>>>> 6. Create a separated application, JdkUtils.java, to determine 
>>>>>>>>> the JDK build version (java.runtime.version) and check if a 
>>>>>>>>> signature algorithm is supported by a JDK.
>>>>>>>>> 7. Introduces a new property, named javaSecurityFile, for 
>>>>>>>>> allowing users to specify alternative java security properties 
>>>>>>>>> file.
>>>>>>>>> 8. Renames report column [Cert Type] to [Certificate]. This 
>>>>>>>>> column displays the certificate identifiers, which is a 
>>>>>>>>> combination of key algorithm, digest algorithm, key size and 
>>>>>>>>> expired mark (if any).
>>>>>>>>> 9. The test summary also be updated accordingly.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> John Jiang
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>>>>>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>>> Hi Sean,
>>>>>>>>>>>
>>>>>>>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>
>>>>>>>>>>>> This looks like a very useful test. I have not gone through 
>>>>>>>>>>>> all of the code, but here are a few comments for now until 
>>>>>>>>>>>> I have more time:
>>>>>>>>>>>>
>>>>>>>>>>>> - add tests for EC keys
>>>>>>>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>>>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>>>>>>>> - you can use the diamond operator <> in various places
>>>>>>>>>>>> - might be more compact if jdkList() used Files.lines() to 
>>>>>>>>>>>> parse the file into a stream then an array
>>>>>>>>>>> I did consider about the above two points. Because the test 
>>>>>>>>>>> will be backported to JDK 6, so I only used the features 
>>>>>>>>>>> those supported by JDK 6.
>>>>>>>>>>> I supposed that would make the backport easier. Does it make 
>>>>>>>>>>> sense?
>>>>>>>>>>
>>>>>>>>>> Yes, that makes sense.
>>>>>>>>>>
>>>>>>>>>> --Sean
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> John Jiang
>>>>>>>>>>>> - did you consider using the jarsigner API 
>>>>>>>>>>>> (jdk.security.jarsigner) instead of the command-line? I 
>>>>>>>>>>>> think this would be better (if possible) and it would give 
>>>>>>>>>>>> us some more tests of that API.
>>>>>>>>>>>>
>>>>>>>>>>>> --Sean
>>>>>>>>>>>>
>>>>>>>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>> Please review this manual test for checking if a jar, 
>>>>>>>>>>>>> which is signed and timestamped by a JDK build, could be 
>>>>>>>>>>>>> verified by other JDK builds.
>>>>>>>>>>>>> It also can be used to check if the default timestamp 
>>>>>>>>>>>>> digest algorithm on signing is SHA-256.
>>>>>>>>>>>>> For more details, please look through the test summary.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Tue Aug 15 07:42:43 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 Aug 2017 15:42:43 +0800
Subject: On 8186143: Subject Alternative Name doesn't Accept Wildcards for DNS
 names
In-Reply-To: <963f0cab-2ec2-25cf-7050-585b757df3ac@oracle.com>
References: <963f0cab-2ec2-25cf-7050-585b757df3ac@oracle.com>
Message-ID: <55FB25FB-4B4D-4C24-B080-4DE88AFDE17F@oracle.com>

I'll start working on this bug:

    8186143: Subject Alternative Name doesn't Accept Wildcards for DNS names
    https://bugs.openjdk.java.net/browse/JDK-8186143

The following are from https://tools.ietf.org/html/rfc5280#section-4.2.1.6:

   When the subjectAltName extension contains a domain name system
   label, the domain name MUST be stored in the dNSName (an IA5String).
   The name MUST be in the "preferred name syntax", as specified by
   Section 3.5 of [RFC1034] and as modified by Section 2.1 of
   [RFC1123]

   ...

   Finally, the semantics of subject alternative names that include
   wildcard characters (e.g., as a placeholder for a set of names) are
   not addressed by this specification.

https://tools.ietf.org/html/rfc1123#page-13 has:

   2.1  Host Names and Numbers

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

So I plan to make these changes:

1. In the constructor DNSName(String) [1], allow a digit as the first char of each label in the name.

2. Allows "*" but check its format using the same code in HostnameChecker::isMatched[2].

I'll start with a separate constructor (which allows "*") that is only used in creating a new subjectAltName, and see if it works.

Any suggestions?

Thanks
Max

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/share/classes/sun/security/x509/DNSName.java#l74
[2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/java.base/share/classes/sun/security/util/HostnameChecker.java#l285

From adam.petcher at oracle.com  Tue Aug 15 15:06:27 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Tue, 15 Aug 2017 11:06:27 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
References: 
 <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
Message-ID: <4a12f68d-7f82-59a0-c97d-34ae4792ffbf@oracle.com>

Okay, let me go back to the beginning with some slightly weaker 
assumptions, and a slightly modified design. I've attempted to 
incorporate all the feedback I've received so far, but if you feel like 
I missed something, please let me know.

Assumptions:

A) We don't need to expose curve domain parameters over the API in the 
initial design/implementation. Curves can be specified using names (e.g. 
"X25519") or OIDs. The underlying implementation will likely support 
arbitrary Montgomery curves, but the JCA application will only be able 
to use the supported named curves. Support for arbitrary curve 
parameters in the API is something that can be considered as a separate 
feature in the future.
B) We don't need specs and interfaces that are specific to RFC 7748 
public/private keys. To allow interoperability between providers, and to 
make it easy to specify key values, we can use more general purpose spec 
classes and interfaces that can be reused by multiple algorithms. In 
particular, we should be able to reuse these interfaces/classes between 
RFC 7748 and RFC 8032.

Here is a high-level description of the proposed JCA API. A more 
detailed description will be provided during the JEP review.

1) The string "XDH" will be used in getInstance() to refer to all 
services related to RFC 7748 (KeyAgreement, KeyFactory, 
KeyPairGenerator, etc). This is a departure from the ECDH API that used 
"EC" for key generation (shared with ECDSA) and "ECDH" for KeyAgreement, 
and makes the RFC 7748 API more like "DiffieHellman" and other 
algorithms that use the same name for all services.
2) The new class java.security.spec.NamedParameterSpec (which implements 
AlgorithmParameterSpec) will be used to specify curves for RFC 7748. 
This class has a single String member which holds the name of the curve 
("X25519" or "X448"). This parameter spec class can be reused by other 
crypto algorithms that similarly identify parameter sets using names 
(e.g. FFDHE3072 in DiffieHellman). This new class can be inserted into 
the hierarchy above ECGenParameterSpec.
3) There will be no classes in java.security.spec specific to RFC 7748 
public keys and private keys. A new class called ByteArrayKeySpec will 
be added to java.security.spec. This class will hold an algorithm name 
String, an AlgorithmParameterSpec, and a byte array containing the raw 
key bytes. This class is suitable for keys in RFC 7748, RFC 8032, and 
possibly other algorithms. ByteArrayKeySpec can be viewed as a 
generalization of SecretKeySpec, and it will be used in a similar 
manner. The existing classes X509EncodedKeySpec and PKCS8EncodedKeySpec 
can also be used for RFC 7748 public and private key specs, respectively.
4) There will be no interfaces in java.security.interfaces specific to 
RFC 7748 public/private keys. A new interface called ByteArrayKey will 
be added to java.security.interfaces. This interface will expose an 
AlgorithmParameterSpec and a byte array containing the raw key value. 
Implementations of keys in RFC 7748, 8032 (and possibly other 
algorithms) can implement this interface to allow other providers to 
access the required information about the keys. Implementations can also 
achieve interoperability by using encoded representations of keys.

Here is how the API will be implemented in the SunEC provider:

1) The public key and private key implementation classes will extend 
sun.security.ec.X509Key and sun.security.ec.PKCS8Key, respectively. This 
is similar to ECPublicKeyImpl and ECPrivateKeyImpl. They will also both 
implement ByteArrayKey.
2) The KeyFactory for RFC 7748 will support translation from opaque keys 
and ByteArrayKey to X509EncodedKeySpec/PKCS8EncodedKeySpec and 
ByteArrayKeySpec (and vice-versa).

Example code:

KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
kpg.initialize(paramSpec); // equivalent to kpg.initialize(255)
KeyPair kp = kpg.generateKeyPair();

KeyFactory kf = KeyFactory.getInstance("XDH");
byte[] rawKeyBytes = ...
ByteArrayKeySpec pubSpec = new ByteArrayKeySpec(
"XDH",
    new NamedParameterSpec("X25519"),
    rawKeyBytes);
PublicKey pubKey = kf.generatePublic(pubSpec);

KeyAgreement ka = KeyAgreement.getInstance("XDH");
ka.init(kp.getPrivate());
ka.doPhase(pubKey, true);
byte[] secret = ka.generateSecret();

Additional notes:
1) The ability to specify curve domain parameters over the API is a 
useful feature, and this design accommodates the addition of this 
feature in the future. Both ByteArrayKeySpec and ByteArrayKey hold an 
AlgorithmParameterSpec rather than a more concrete type. In addition to 
using NamedParameterSpec, the parameters could be specified using some 
other type that holds domain parameters.

2) Applications that need to choose their behavior based on the type of 
(for example) public key can do so for RFC 7748 keys by calling 
Key::getAlgorithm() to determine the algorithm and then using 
ByteArrayKey to extract the required information.

3) This design supports Xuelei's general EC proposal[1]. We can use 
names like "XDHWithX25519" or perhaps simply "X25519" to specify the 
"XDH" algorithm initialized with the "X25519" NamedParameterSpec.

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016194.html



From sean.mullan at oracle.com  Tue Aug 15 17:34:15 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 15 Aug 2017 13:34:15 -0400
Subject: RFR JDK-8179614: Test for jarsigner on verifying jars that are
 signed and timestamped by other JDK releases
In-Reply-To: 
References: 
 <5b75241c-1148-fe4f-bd6e-328f5737fed4@oracle.com>
 
 <7bf702ef-5ba4-e2b4-5b88-1c6ab222534f@oracle.com>
 
 <0fbe602f-6ba7-a05c-f163-9e15aeddeab4@oracle.com>
 <14c8a086-7e48-312b-3c15-917dcdc7061c@oracle.com>
 <0f0ce594-6ec3-0315-6627-a7cbe7cde294@oracle.com>
 <02569226-c63e-52ce-0519-e88cabde8358@oracle.com>
 <85acb154-534d-daa7-d200-c3bea4607de9@oracle.com>
 
 <4dae591e-12c5-c5de-fb6b-793d1b8b3d96@oracle.com>
 <6666238f-825c-629f-dcc6-4f27a4df6c98@oracle.com>
 
Message-ID: <5e192fef-6050-8ac4-f22e-1cb224ef6ec2@oracle.com>

Hi John,

You should add a copyright to the README. Otherwise, this update looks good.

--Sean

On 8/14/17 11:52 PM, sha.jiang at oracle.com wrote:
> Hi,
> The webrev [1] is updated on the following points:
> 1. It allows TSA URL to append a set of supported digest algorithms. If 
> a TSA URL doesn't append the digests parameter, it means that the TSA 
> supports SHA-1, SHA-256 and SHA-512.
> 2. EC cases are excluded for JDK 6.
> 3. Certificates are generated by the signer JDKs themselves respectively.
> 4. jarsigner uses option "-debug".
> 5. Test mode "strict" is removed.
> 
> [1] http://cr.openjdk.java.net/~jjiang/8179614/webrev.11/
> 
> Best regards,
> John Jiang
> 
> 
> On 14/07/2017 15:11, sha.jiang at oracle.com wrote:
>>
>> Hi,
>> Please review the latest webrev at: 
>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.09/
>> This test has been updated significantly. It removes useless case 
>> combinations, and generates reports in HTML. For more details, please 
>> look through the test summary.
>>
>> Best regards,
>> John Jiang
>>
>> On 13/06/2017 23:47, sha.jiang at oracle.com wrote:
>>> Sean and Max,
>>> Please review this updated webrev: 
>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.03/
>>>
>>> The main changes are:
>>> 1. It provides two new properties, tsaList and tsaListFile, for 
>>> specifying a list of TSA services.
>>> And a new report column [TSA] is introduced. This column just display 
>>> the TSA indices and all of TSA services are displayed at the top of 
>>> the report.
>>> 2. If property strict is true, the cases on failed signing are not 
>>> ignored. They still be listed in the test report, and the status of 
>>> verifying are NONE.
>>>
>>> Best regards,
>>> John Jiang
>>>
>>> On 13/06/2017 06:51, sha.jiang at oracle.com wrote:
>>>> Hi Max,
>>>>
>>>> On 12/06/2017 17:29, Weijun Wang wrote:
>>>>> Great. Only 2 questions:
>>>>>
>>>>>  459     // Return key sizes according to the specified key algorithm.
>>>>>  460     private static int[] keySizes(String digestAlgorithm, 
>>>>> String keyAlgorithm) {
>>>>>  461         if (digestAlgorithm == DEFAULT) {
>>>>>  462             return new int[] { 0 };
>>>>>  463         }
>>>>>  464
>>>>>  465         if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
>>>>>  466             return new int[] { 1024, 2048 };
>>>>>  467         } else if (keyAlgorithm == EC) {
>>>>>  468             return new int[] { 384, 571 };
>>>>>  469         }
>>>>>  470
>>>>>  471         return null;
>>>>>  472     }
>>>>>
>>>>> Why is keysize dependent on digestalg? I mean, is it possible to 
>>>>> always return {1024,2048,0} and {384,571,0}?
>>>> Get it, thanks!
>>>>>
>>>>>  379     // If signing fails, the following verifying has to
>>>>>  380     // be ignored.
>>>>>  381     if (signingStatus == STATUS.ERROR) {
>>>>>  382         continue;
>>>>>  383     }
>>>>>
>>>>> Now that you've already checked sigalg support earlier in what 
>>>>> cases it could go wrong here?
>>>> Jar signing still could fail. For example, TSA service is unavailable.
>>>>
>>>> Best regards,
>>>> John Jiang
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>> On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
>>>>>> Hi Max,
>>>>>> Would you like to review the updated webrev: 
>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
>>>>>> It can create certificate without -sigalg and -keysize, and jar 
>>>>>> signing also can use this certificate.
>>>>>>
>>>>>> Best regards,
>>>>>> John Jiang
>>>>>>
>>>>>> On 09/06/2017 22:04, Weijun Wang wrote:
>>>>>>>
>>>>>>> On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> On 09/06/2017 20:05, Weijun Wang wrote:
>>>>>>>>> The test can be more friendly with default values.
>>>>>>>>>
>>>>>>>>> For example, in createCertificates(), you can generate certs 
>>>>>>>>> that use default sigalg and keysize (i.e. without specifying 
>>>>>>>>> -siglag and -keysize), and give them aliases with "default" or 
>>>>>>>>> "null" inside.
>>>>>>>>>
>>>>>>>>> And in jar signing when signing with one -sigalg you can also 
>>>>>>>>> choose cert generated with different or default sigalgs.
>>>>>>>> I supposed this test just focus on signed jar verifying, but not 
>>>>>>>> certificate creating and jar signing. So, I'm not sure such 
>>>>>>>> cases are necessary.
>>>>>>>
>>>>>>> Well sometimes a test can do many things. If you only care about 
>>>>>>> jar verification, why bother creating certs with different digest 
>>>>>>> algorithms?
>>>>>>>
>>>>>>> On the other hand, if you do care about more, then in
>>>>>>>
>>>>>>>  338     // If the digest algorithm is not specified, then it
>>>>>>>  339     // uses certificate with SHA256 digest and 1024 key
>>>>>>>  340     // size.
>>>>>>>  341     if (digestAlgorithm == DEFAULT) {
>>>>>>>  342         certDigest = SHA256;
>>>>>>>  343         certKeySize = 1024;
>>>>>>>  344     }
>>>>>>>
>>>>>>> it seems a little awkward to hardcode the algorithm and keysize. 
>>>>>>> If signing is using a default algorithm, it seems natural to use 
>>>>>>> the cert that was generated with a default algorithm. In fact, 
>>>>>>> this test case is quite useful that it ensures our different 
>>>>>>> tools are using the same (or at least interoperable) default 
>>>>>>> algorithms.
>>>>>>>
>>>>>>> --Max
>>>>>>>
>>>>>>>>>
>>>>>>>>> BTW, I remember certain pairs of -keysize and -sigalg do not 
>>>>>>>>> work together. For example, 1024 bit of DSA key cannot be used 
>>>>>>>>> with SHA512withDSA signature algorithm. Have you noticed it?
>>>>>>>> It looks SHA512withDSA is not supported yet.
>>>>>>>> I was using JDK10 build 10. When the test tried to create 
>>>>>>>> certificate with -keyalg DSA -sigalg SHA512withDSA -keysize 
>>>>>>>> 1024, the below error raised:
>>>>>>>> keytool error: java.security.NoSuchAlgorithmException: 
>>>>>>>> unrecognized algorithm name: SHA512withDSA
>>>>>>>>
>>>>>>>> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the error 
>>>>>>>> was:
>>>>>>>> keytool error: java.security.InvalidKeyException: The security 
>>>>>>>> strength of SHA-1 digest algorithm is not sufficient for this 
>>>>>>>> key size
>>>>>>>>
>>>>>>>> Again, this test focus on signed jar verifying. If some problems 
>>>>>>>> are raised on certificate creating or jar signing, the 
>>>>>>>> associated verifying cases will be ignored.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> John Jiang
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>> Hi Sean and Max,
>>>>>>>>>> Thanks for your comments.
>>>>>>>>>> Please review the updated webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>>>>>>>>
>>>>>>>>>> The test has been modified significantly. The main points are:
>>>>>>>>>> 1. Adds cases on EC. Now the test supports key algorithms RSA, 
>>>>>>>>>> DSA and EC.
>>>>>>>>>> 2. Adds cases on SHA-512. Now the test supports digest 
>>>>>>>>>> algorithms SHA-1, SHA-256 and SHA-512.
>>>>>>>>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, [1024, 
>>>>>>>>>> 2048] for RSA and DSA.
>>>>>>>>>> 4. Adds cases on default signature algorithm. Now the test 
>>>>>>>>>> report can display the default algorithmat column [Signature 
>>>>>>>>>> Algorithm].
>>>>>>>>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for 
>>>>>>>>>> keytool and jarsigner commands.
>>>>>>>>>> 6. Create a separated application, JdkUtils.java, to determine 
>>>>>>>>>> the JDK build version (java.runtime.version) and check if a 
>>>>>>>>>> signature algorithm is supported by a JDK.
>>>>>>>>>> 7. Introduces a new property, named javaSecurityFile, for 
>>>>>>>>>> allowing users to specify alternative java security properties 
>>>>>>>>>> file.
>>>>>>>>>> 8. Renames report column [Cert Type] to [Certificate]. This 
>>>>>>>>>> column displays the certificate identifiers, which is a 
>>>>>>>>>> combination of key algorithm, digest algorithm, key size and 
>>>>>>>>>> expired mark (if any).
>>>>>>>>>> 9. The test summary also be updated accordingly.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> John Jiang
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>>>>>>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>> Hi Sean,
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>
>>>>>>>>>>>>> This looks like a very useful test. I have not gone through 
>>>>>>>>>>>>> all of the code, but here are a few comments for now until 
>>>>>>>>>>>>> I have more time:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - add tests for EC keys
>>>>>>>>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>>>>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>>>>>>>>> - you can use the diamond operator <> in various places
>>>>>>>>>>>>> - might be more compact if jdkList() used Files.lines() to 
>>>>>>>>>>>>> parse the file into a stream then an array
>>>>>>>>>>>> I did consider about the above two points. Because the test 
>>>>>>>>>>>> will be backported to JDK 6, so I only used the features 
>>>>>>>>>>>> those supported by JDK 6.
>>>>>>>>>>>> I supposed that would make the backport easier. Does it make 
>>>>>>>>>>>> sense?
>>>>>>>>>>>
>>>>>>>>>>> Yes, that makes sense.
>>>>>>>>>>>
>>>>>>>>>>> --Sean
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>> - did you consider using the jarsigner API 
>>>>>>>>>>>>> (jdk.security.jarsigner) instead of the command-line? I 
>>>>>>>>>>>>> think this would be better (if possible) and it would give 
>>>>>>>>>>>>> us some more tests of that API.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --Sean
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> Please review this manual test for checking if a jar, 
>>>>>>>>>>>>>> which is signed and timestamped by a JDK build, could be 
>>>>>>>>>>>>>> verified by other JDK builds.
>>>>>>>>>>>>>> It also can be used to check if the default timestamp 
>>>>>>>>>>>>>> digest algorithm on signing is SHA-256.
>>>>>>>>>>>>>> For more details, please look through the test summary.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
> 


From xuelei.fan at oracle.com  Tue Aug 15 17:43:40 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 15 Aug 2017 10:43:40 -0700
Subject: JCA design for RFC 7748
In-Reply-To: <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
Message-ID: <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>

On 8/11/2017 7:57 AM, Adam Petcher wrote:
> On 8/10/2017 9:46 PM, Michael StJohns wrote:
> 
>> On 8/10/2017 7:36 PM, Xuelei Fan wrote:
>>>> Right now there are 3 major APIs  (JCA, PKCS11 and Microsoft CSP) 
>>>> and at least 4 major representational domains (Raw, PKIX, XML and 
>>>> JSON).  In the current situation, I can take a JCA EC Public key and 
>>>> convert it to pretty much any of the other APIs or representations. 
>>>> For much of the hardware based stuff (ie, smart cards), I go 
>>>> straight from JCA into raw and vice versa. Assuming you left the 
>>>> "getEncoded()" stuff in the API and the encoding was PKIX, I'd have 
>>>> to encode to PKIX, decode the PKIX to extract the actual raw key or 
>>>> encode a PKIX blob and hope that the KeyFactory stuff actually worked.
>>>>
>>>> It's not just support of arbitrary keys, but the ability to convert 
>>>> things without having to do multiple steps or stages.
>>>>
>>> Good point!  It would be nice if transaction between two formats 
>>> could be done simply.  Using X.509 encoding is doable as you said 
>>> above, but maybe there are spaces to get improvements.
>>>
>>> I need more time to think about it.  Please let me know if any one 
>>> have a solution to simplify the transaction if keeping use the 
>>> proposed named curves solution.
>>>
> 
> I'm also coming to the conclusion that using X.509 encoding for this 
> sort of interoperability is too onerous, and we should come up with 
> something better. Maybe we should add a new general-purpose interface 
> that exposes some structure in an algorithm-independent way. Something 
> like this:
> 
> package java.security.interfaces;
> public interface ByteArrayValue {
> 
>      String getAlgorithm();
>      AlgorithmParameterSpec getParams();
>      byte[] getValue();
> }
> 
I'm not sure how to use the above interface in an application.

I don't worry about this issue any more.  At present, each 
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a format

The format could be "X.509", and could be "RAW" (like 
ByteArrayValue.getValue()).  I would suggest have the named curve in the 
algorithm characters, and use "RAW" as the encode format.  If X.509 
encoding is required, KeyFactory.getKeySpec?() could do it.

Xuelei

> The actual value is encoded, but the parameters are exposed, so this 
> interface would work well for any value that is generally represented 
> using a single encoded value (like public/private keys in RFC 7748, and 
> 8032). This could be used with the new NamedParameterSpec class to 
> identify the parameters by name. It could also be used with other 
> parameter specs to specify curve coefficients.
> 
> Of course, you may still need to look up curve name/OID/coefficients 
> based on the parameters, but at least this solution provides direct 
> access to the parameters and raw value, and you wouldn't need to go 
> through X.509. Though perhaps this is less appropriate for SEC1 types 
> and XML/JSON, because you would need to parse the value to extract the x 
> and y coordinates. So using the existing ECKey for those types may make 
> more sense.
> 
> 
> 
> 


From anders.rundgren.net at gmail.com  Tue Aug 15 21:29:03 2017
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Tue, 15 Aug 2017 23:29:03 +0200
Subject: JCA design for RFC 7748
In-Reply-To: <4a12f68d-7f82-59a0-c97d-34ae4792ffbf@oracle.com>
References: 
 <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
 <4a12f68d-7f82-59a0-c97d-34ae4792ffbf@oracle.com>
Message-ID: <62c4b6e0-612a-0e5f-0db7-461fed5d5fe4@gmail.com>

Does this mean that the following is correct?

EC public key:

public interface ECPublicKey
extends PublicKey, ECKey


CFRG/RFC 7748 public key:

public class TheActualImplememtationClass
extends PublicKey, ByteArrayKey


If so, it should work. Documentation seems a bit less obvious though
which is why I advocated a more direct approach.

Cheers,
Anders

On 2017-08-15 17:06, Adam Petcher wrote:
> Okay, let me go back to the beginning with some slightly weaker
> assumptions, and a slightly modified design. I've attempted to
> incorporate all the feedback I've received so far, but if you feel like
> I missed something, please let me know.
> 
> Assumptions:
> 
> A) We don't need to expose curve domain parameters over the API in the
> initial design/implementation. Curves can be specified using names (e.g.
> "X25519") or OIDs. The underlying implementation will likely support
> arbitrary Montgomery curves, but the JCA application will only be able
> to use the supported named curves. Support for arbitrary curve
> parameters in the API is something that can be considered as a separate
> feature in the future.
> B) We don't need specs and interfaces that are specific to RFC 7748
> public/private keys. To allow interoperability between providers, and to
> make it easy to specify key values, we can use more general purpose spec
> classes and interfaces that can be reused by multiple algorithms. In
> particular, we should be able to reuse these interfaces/classes between
> RFC 7748 and RFC 8032.
> 
> Here is a high-level description of the proposed JCA API. A more
> detailed description will be provided during the JEP review.
> 
> 1) The string "XDH" will be used in getInstance() to refer to all
> services related to RFC 7748 (KeyAgreement, KeyFactory,
> KeyPairGenerator, etc). This is a departure from the ECDH API that used
> "EC" for key generation (shared with ECDSA) and "ECDH" for KeyAgreement,
> and makes the RFC 7748 API more like "DiffieHellman" and other
> algorithms that use the same name for all services.
> 2) The new class java.security.spec.NamedParameterSpec (which implements
> AlgorithmParameterSpec) will be used to specify curves for RFC 7748.
> This class has a single String member which holds the name of the curve
> ("X25519" or "X448"). This parameter spec class can be reused by other
> crypto algorithms that similarly identify parameter sets using names
> (e.g. FFDHE3072 in DiffieHellman). This new class can be inserted into
> the hierarchy above ECGenParameterSpec.
> 3) There will be no classes in java.security.spec specific to RFC 7748
> public keys and private keys. A new class called ByteArrayKeySpec will
> be added to java.security.spec. This class will hold an algorithm name
> String, an AlgorithmParameterSpec, and a byte array containing the raw
> key bytes. This class is suitable for keys in RFC 7748, RFC 8032, and
> possibly other algorithms. ByteArrayKeySpec can be viewed as a
> generalization of SecretKeySpec, and it will be used in a similar
> manner. The existing classes X509EncodedKeySpec and PKCS8EncodedKeySpec
> can also be used for RFC 7748 public and private key specs, respectively.
> 4) There will be no interfaces in java.security.interfaces specific to
> RFC 7748 public/private keys. A new interface called ByteArrayKey will
> be added to java.security.interfaces. This interface will expose an
> AlgorithmParameterSpec and a byte array containing the raw key value.
> Implementations of keys in RFC 7748, 8032 (and possibly other
> algorithms) can implement this interface to allow other providers to
> access the required information about the keys. Implementations can also
> achieve interoperability by using encoded representations of keys.
> 
> Here is how the API will be implemented in the SunEC provider:
> 
> 1) The public key and private key implementation classes will extend
> sun.security.ec.X509Key and sun.security.ec.PKCS8Key, respectively. This
> is similar to ECPublicKeyImpl and ECPrivateKeyImpl. They will also both
> implement ByteArrayKey.
> 2) The KeyFactory for RFC 7748 will support translation from opaque keys
> and ByteArrayKey to X509EncodedKeySpec/PKCS8EncodedKeySpec and
> ByteArrayKeySpec (and vice-versa).
> 
> Example code:
> 
> KeyPairGenerator kpg = KeyPairGenerator.getInstance("XDH");
> NamedParameterSpec paramSpec = new NamedParameterSpec("X25519");
> kpg.initialize(paramSpec); // equivalent to kpg.initialize(255)
> KeyPair kp = kpg.generateKeyPair();
> 
> KeyFactory kf = KeyFactory.getInstance("XDH");
> byte[] rawKeyBytes = ...
> ByteArrayKeySpec pubSpec = new ByteArrayKeySpec(
> "XDH",
>      new NamedParameterSpec("X25519"),
>      rawKeyBytes);
> PublicKey pubKey = kf.generatePublic(pubSpec);
> 
> KeyAgreement ka = KeyAgreement.getInstance("XDH");
> ka.init(kp.getPrivate());
> ka.doPhase(pubKey, true);
> byte[] secret = ka.generateSecret();
> 
> Additional notes:
> 1) The ability to specify curve domain parameters over the API is a
> useful feature, and this design accommodates the addition of this
> feature in the future. Both ByteArrayKeySpec and ByteArrayKey hold an
> AlgorithmParameterSpec rather than a more concrete type. In addition to
> using NamedParameterSpec, the parameters could be specified using some
> other type that holds domain parameters.
> 
> 2) Applications that need to choose their behavior based on the type of
> (for example) public key can do so for RFC 7748 keys by calling
> Key::getAlgorithm() to determine the algorithm and then using
> ByteArrayKey to extract the required information.
> 
> 3) This design supports Xuelei's general EC proposal[1]. We can use
> names like "XDHWithX25519" or perhaps simply "X25519" to specify the
> "XDH" algorithm initialized with the "X25519" NamedParameterSpec.
> 
> [1]
> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016194.html
> 



From mstjohns at comcast.net  Tue Aug 15 23:05:13 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Tue, 15 Aug 2017 19:05:13 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
Message-ID: 

On 8/15/2017 1:43 PM, Xuelei Fan wrote:
> On 8/11/2017 7:57 AM, Adam Petcher wrote:
>> On 8/10/2017 9:46 PM, Michael StJohns wrote:
>>
>>> On 8/10/2017 7:36 PM, Xuelei Fan wrote:
>>>>> Right now there are 3 major APIs (JCA, PKCS11 and Microsoft CSP) 
>>>>> and at least 4 major representational domains (Raw, PKIX, XML and 
>>>>> JSON).  In the current situation, I can take a JCA EC Public key 
>>>>> and convert it to pretty much any of the other APIs or 
>>>>> representations. For much of the hardware based stuff (ie, smart 
>>>>> cards), I go straight from JCA into raw and vice versa. Assuming 
>>>>> you left the "getEncoded()" stuff in the API and the encoding was 
>>>>> PKIX, I'd have to encode to PKIX, decode the PKIX to extract the 
>>>>> actual raw key or encode a PKIX blob and hope that the KeyFactory 
>>>>> stuff actually worked.
>>>>>
>>>>> It's not just support of arbitrary keys, but the ability to 
>>>>> convert things without having to do multiple steps or stages.
>>>>>
>>>> Good point!  It would be nice if transaction between two formats 
>>>> could be done simply.  Using X.509 encoding is doable as you said 
>>>> above, but maybe there are spaces to get improvements.
>>>>
>>>> I need more time to think about it.  Please let me know if any one 
>>>> have a solution to simplify the transaction if keeping use the 
>>>> proposed named curves solution.
>>>>
>>
>> I'm also coming to the conclusion that using X.509 encoding for this 
>> sort of interoperability is too onerous, and we should come up with 
>> something better. Maybe we should add a new general-purpose interface 
>> that exposes some structure in an algorithm-independent way. 
>> Something like this:
>>
>> package java.security.interfaces;
>> public interface ByteArrayValue {
>>
>>      String getAlgorithm();
>>      AlgorithmParameterSpec getParams();
>>      byte[] getValue();
>> }
>>
> I'm not sure how to use the above interface in an application.

This is sort of the moral equivalent of using the TXT RR record in DNS 
and the arguments are similar.

This is a bad idea.

>
> I don't worry about this issue any more.  At present, each 
> java.security.Key has three characters (see the API Java doc):
> . an algorithm
> . an encoded form
> . a format
>
> The format could be "X.509", and could be "RAW" (like 
> ByteArrayValue.getValue()).  I would suggest have the named curve in 
> the algorithm characters, and use "RAW" as the encode format.
> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
Um... I think that doesn't make a lot of sense.  The default contract 
for public keys is X.509 and the default for private keys is PKCS#8.  
Almost all uses of the encoded formats are related to PKIX related 
functions.   (See for info the javadoc for PublicKey).

Raw formats are used pretty much exclusively for symmetric keys.

The KeyFactory.getKeySpec() requires an actual KeySpec definition which 
is different than the ByteArrayValue stuff being proposed above.

To be JCA compliant you need all of:

1) A master interface (e.g. ECKey) that's a marker interface for key 
material
2) A public key interface that extends PublicKey and the master interface
3) A private key interface that extends PrivateKey and the master interface
4) A public key specification that implements KeySpec
5) A private key specification that implements KeySpec
6) A generation parameter specification that implements 
AlgorithmParameterSpec
7) A key parameter specification (if required by the master interface)
8) A factory class that implements KeyFactoryImpl taht implements 
AlgorithmParameterSpec
9) A common encoding for each of the public and private keys
10) A transform to/from the public and private key specs


Here's what I think should happen:

1) ECPoint gets a document modification to handle compressed points.  
The X is the X value, the Y is -1, 0 or 1 depending on positive negative 
or don't care for the sign of the Y value.   (This means that the byte 
array public key gets handled as a BigInteger). Any value other than 0, 
-1 or 1 for Y indicates a normal X Y point.

2) EllipticCurve gets a document modification to describe the mappings 
for Edwards and Montgomery curves as discussed previously.

3) Two classes are added to java.security.spec: 
java.security.spec.ECFieldEdwards and 
java.security.spec.ECFieldMontgomery - both of which implement ECField.

4) The ECFieldEdwards/Montgomery classes contain an indication of 
whether the curve is signature only, key agreement only or both. They 
also contain any parameters that can't be mapped in EllipticCurve

5) Using the above, someone specifies the curve sets for the four new 
curves as ECParameterSpec's and we iterate until we're satisfied we've 
got a standard public representation that can be used for other than the 
4 curves.

6) Until the JCA is updated, a provider for the new curves can use its 
own concrete ECField classes and later make them be subclasses of the 
java.security.spec.ECFieldMontgomery etc.  It's not ideal, but it does 
let the guys who are chomping at the bit do an implementation while 
waiting for the JCA to be updated.

7) No other changes to the JCA are made.  The providers implement 
SubjectPublicKeyInfo and PKCS8 as the standard encodings  using the 
definitions in 
https://tools.ietf.org/html/draft-ietf-curdle-pkix-newcurves-00 and RFC5480.

The new keys remain tagged as ECKeys.  Old code won't notice (because 
old code is using old curves).  New code (new providers) will have to 
pay attention to EllipticCurve and ECField information if its handling 
both types of curves.  As is the case now, no provider need support 
every curve or even every field type.

Mike

>
> Xuelei
>
>> The actual value is encoded, but the parameters are exposed, so this 
>> interface would work well for any value that is generally represented 
>> using a single encoded value (like public/private keys in RFC 7748, 
>> and 8032). This could be used with the new NamedParameterSpec class 
>> to identify the parameters by name. It could also be used with other 
>> parameter specs to specify curve coefficients.
>>
>> Of course, you may still need to look up curve name/OID/coefficients 
>> based on the parameters, but at least this solution provides direct 
>> access to the parameters and raw value, and you wouldn't need to go 
>> through X.509. Though perhaps this is less appropriate for SEC1 types 
>> and XML/JSON, because you would need to parse the value to extract 
>> the x and y coordinates. So using the existing ECKey for those types 
>> may make more sense.
>>
>>
>>
>>



From sha.jiang at oracle.com  Wed Aug 16 02:32:23 2017
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Wed, 16 Aug 2017 10:32:23 +0800
Subject: RFR JDK-8179614: Test for jarsigner on verifying jars that are
 signed and timestamped by other JDK releases
In-Reply-To: <5e192fef-6050-8ac4-f22e-1cb224ef6ec2@oracle.com>
References: 
 <5b75241c-1148-fe4f-bd6e-328f5737fed4@oracle.com>
 
 <7bf702ef-5ba4-e2b4-5b88-1c6ab222534f@oracle.com>
 
 <0fbe602f-6ba7-a05c-f163-9e15aeddeab4@oracle.com>
 <14c8a086-7e48-312b-3c15-917dcdc7061c@oracle.com>
 <0f0ce594-6ec3-0315-6627-a7cbe7cde294@oracle.com>
 <02569226-c63e-52ce-0519-e88cabde8358@oracle.com>
 <85acb154-534d-daa7-d200-c3bea4607de9@oracle.com>
 
 <4dae591e-12c5-c5de-fb6b-793d1b8b3d96@oracle.com>
 <6666238f-825c-629f-dcc6-4f27a4df6c98@oracle.com>
 
 <5e192fef-6050-8ac4-f22e-1cb224ef6ec2@oracle.com>
Message-ID: <48228f2c-bd21-8bad-0e56-06cd540cd610@oracle.com>

Hi Sean,
Thanks for your review!
This patch has been pushed. And the README contains the copyright.

Best regards,
John Jiang


On 16/08/2017 01:34, Sean Mullan wrote:
> Hi John,
>
> You should add a copyright to the README. Otherwise, this update looks 
> good.
>
> --Sean
>
> On 8/14/17 11:52 PM, sha.jiang at oracle.com wrote:
>> Hi,
>> The webrev [1] is updated on the following points:
>> 1. It allows TSA URL to append a set of supported digest algorithms. 
>> If a TSA URL doesn't append the digests parameter, it means that the 
>> TSA supports SHA-1, SHA-256 and SHA-512.
>> 2. EC cases are excluded for JDK 6.
>> 3. Certificates are generated by the signer JDKs themselves 
>> respectively.
>> 4. jarsigner uses option "-debug".
>> 5. Test mode "strict" is removed.
>>
>> [1] http://cr.openjdk.java.net/~jjiang/8179614/webrev.11/
>>
>> Best regards,
>> John Jiang
>>
>>
>> On 14/07/2017 15:11, sha.jiang at oracle.com wrote:
>>>
>>> Hi,
>>> Please review the latest webrev at: 
>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.09/
>>> This test has been updated significantly. It removes useless case 
>>> combinations, and generates reports in HTML. For more details, 
>>> please look through the test summary.
>>>
>>> Best regards,
>>> John Jiang
>>>
>>> On 13/06/2017 23:47, sha.jiang at oracle.com wrote:
>>>> Sean and Max,
>>>> Please review this updated webrev: 
>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.03/
>>>>
>>>> The main changes are:
>>>> 1. It provides two new properties, tsaList and tsaListFile, for 
>>>> specifying a list of TSA services.
>>>> And a new report column [TSA] is introduced. This column just 
>>>> display the TSA indices and all of TSA services are displayed at 
>>>> the top of the report.
>>>> 2. If property strict is true, the cases on failed signing are not 
>>>> ignored. They still be listed in the test report, and the status of 
>>>> verifying are NONE.
>>>>
>>>> Best regards,
>>>> John Jiang
>>>>
>>>> On 13/06/2017 06:51, sha.jiang at oracle.com wrote:
>>>>> Hi Max,
>>>>>
>>>>> On 12/06/2017 17:29, Weijun Wang wrote:
>>>>>> Great. Only 2 questions:
>>>>>>
>>>>>>  459     // Return key sizes according to the specified key 
>>>>>> algorithm.
>>>>>>  460     private static int[] keySizes(String digestAlgorithm, 
>>>>>> String keyAlgorithm) {
>>>>>>  461         if (digestAlgorithm == DEFAULT) {
>>>>>>  462             return new int[] { 0 };
>>>>>>  463         }
>>>>>>  464
>>>>>>  465         if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
>>>>>>  466             return new int[] { 1024, 2048 };
>>>>>>  467         } else if (keyAlgorithm == EC) {
>>>>>>  468             return new int[] { 384, 571 };
>>>>>>  469         }
>>>>>>  470
>>>>>>  471         return null;
>>>>>>  472     }
>>>>>>
>>>>>> Why is keysize dependent on digestalg? I mean, is it possible to 
>>>>>> always return {1024,2048,0} and {384,571,0}?
>>>>> Get it, thanks!
>>>>>>
>>>>>>  379     // If signing fails, the following verifying has to
>>>>>>  380     // be ignored.
>>>>>>  381     if (signingStatus == STATUS.ERROR) {
>>>>>>  382         continue;
>>>>>>  383     }
>>>>>>
>>>>>> Now that you've already checked sigalg support earlier in what 
>>>>>> cases it could go wrong here?
>>>>> Jar signing still could fail. For example, TSA service is 
>>>>> unavailable.
>>>>>
>>>>> Best regards,
>>>>> John Jiang
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>> On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
>>>>>>> Hi Max,
>>>>>>> Would you like to review the updated webrev: 
>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
>>>>>>> It can create certificate without -sigalg and -keysize, and jar 
>>>>>>> signing also can use this certificate.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> John Jiang
>>>>>>>
>>>>>>> On 09/06/2017 22:04, Weijun Wang wrote:
>>>>>>>>
>>>>>>>> On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
>>>>>>>>> Hi Max,
>>>>>>>>>
>>>>>>>>> On 09/06/2017 20:05, Weijun Wang wrote:
>>>>>>>>>> The test can be more friendly with default values.
>>>>>>>>>>
>>>>>>>>>> For example, in createCertificates(), you can generate certs 
>>>>>>>>>> that use default sigalg and keysize (i.e. without specifying 
>>>>>>>>>> -siglag and -keysize), and give them aliases with "default" 
>>>>>>>>>> or "null" inside.
>>>>>>>>>>
>>>>>>>>>> And in jar signing when signing with one -sigalg you can also 
>>>>>>>>>> choose cert generated with different or default sigalgs.
>>>>>>>>> I supposed this test just focus on signed jar verifying, but 
>>>>>>>>> not certificate creating and jar signing. So, I'm not sure 
>>>>>>>>> such cases are necessary.
>>>>>>>>
>>>>>>>> Well sometimes a test can do many things. If you only care 
>>>>>>>> about jar verification, why bother creating certs with 
>>>>>>>> different digest algorithms?
>>>>>>>>
>>>>>>>> On the other hand, if you do care about more, then in
>>>>>>>>
>>>>>>>>  338     // If the digest algorithm is not specified, then it
>>>>>>>>  339     // uses certificate with SHA256 digest and 1024 key
>>>>>>>>  340     // size.
>>>>>>>>  341     if (digestAlgorithm == DEFAULT) {
>>>>>>>>  342         certDigest = SHA256;
>>>>>>>>  343         certKeySize = 1024;
>>>>>>>>  344     }
>>>>>>>>
>>>>>>>> it seems a little awkward to hardcode the algorithm and 
>>>>>>>> keysize. If signing is using a default algorithm, it seems 
>>>>>>>> natural to use the cert that was generated with a default 
>>>>>>>> algorithm. In fact, this test case is quite useful that it 
>>>>>>>> ensures our different tools are using the same (or at least 
>>>>>>>> interoperable) default algorithms.
>>>>>>>>
>>>>>>>> --Max
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> BTW, I remember certain pairs of -keysize and -sigalg do not 
>>>>>>>>>> work together. For example, 1024 bit of DSA key cannot be 
>>>>>>>>>> used with SHA512withDSA signature algorithm. Have you noticed 
>>>>>>>>>> it?
>>>>>>>>> It looks SHA512withDSA is not supported yet.
>>>>>>>>> I was using JDK10 build 10. When the test tried to create 
>>>>>>>>> certificate with -keyalg DSA -sigalg SHA512withDSA -keysize 
>>>>>>>>> 1024, the below error raised:
>>>>>>>>> keytool error: java.security.NoSuchAlgorithmException: 
>>>>>>>>> unrecognized algorithm name: SHA512withDSA
>>>>>>>>>
>>>>>>>>> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the 
>>>>>>>>> error was:
>>>>>>>>> keytool error: java.security.InvalidKeyException: The security 
>>>>>>>>> strength of SHA-1 digest algorithm is not sufficient for this 
>>>>>>>>> key size
>>>>>>>>>
>>>>>>>>> Again, this test focus on signed jar verifying. If some 
>>>>>>>>> problems are raised on certificate creating or jar signing, 
>>>>>>>>> the associated verifying cases will be ignored.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> John Jiang
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Max
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>>> Hi Sean and Max,
>>>>>>>>>>> Thanks for your comments.
>>>>>>>>>>> Please review the updated webrev: 
>>>>>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> The test has been modified significantly. The main points are:
>>>>>>>>>>> 1. Adds cases on EC. Now the test supports key algorithms 
>>>>>>>>>>> RSA, DSA and EC.
>>>>>>>>>>> 2. Adds cases on SHA-512. Now the test supports digest 
>>>>>>>>>>> algorithms SHA-1, SHA-256 and SHA-512.
>>>>>>>>>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, 
>>>>>>>>>>> [1024, 2048] for RSA and DSA.
>>>>>>>>>>> 4. Adds cases on default signature algorithm. Now the test 
>>>>>>>>>>> report can display the default algorithmat column [Signature 
>>>>>>>>>>> Algorithm].
>>>>>>>>>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for 
>>>>>>>>>>> keytool and jarsigner commands.
>>>>>>>>>>> 6. Create a separated application, JdkUtils.java, to 
>>>>>>>>>>> determine the JDK build version (java.runtime.version) and 
>>>>>>>>>>> check if a signature algorithm is supported by a JDK.
>>>>>>>>>>> 7. Introduces a new property, named javaSecurityFile, for 
>>>>>>>>>>> allowing users to specify alternative java security 
>>>>>>>>>>> properties file.
>>>>>>>>>>> 8. Renames report column [Cert Type] to [Certificate]. This 
>>>>>>>>>>> column displays the certificate identifiers, which is a 
>>>>>>>>>>> combination of key algorithm, digest algorithm, key size and 
>>>>>>>>>>> expired mark (if any).
>>>>>>>>>>> 9. The test summary also be updated accordingly.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> John Jiang
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>>>>>>>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>>> Hi Sean,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>>>>>>>>>> Hi John,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This looks like a very useful test. I have not gone 
>>>>>>>>>>>>>> through all of the code, but here are a few comments for 
>>>>>>>>>>>>>> now until I have more time:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - add tests for EC keys
>>>>>>>>>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>>>>>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>>>>>>>>>> - you can use the diamond operator <> in various places
>>>>>>>>>>>>>> - might be more compact if jdkList() used Files.lines() 
>>>>>>>>>>>>>> to parse the file into a stream then an array
>>>>>>>>>>>>> I did consider about the above two points. Because the 
>>>>>>>>>>>>> test will be backported to JDK 6, so I only used the 
>>>>>>>>>>>>> features those supported by JDK 6.
>>>>>>>>>>>>> I supposed that would make the backport easier. Does it 
>>>>>>>>>>>>> make sense?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, that makes sense.
>>>>>>>>>>>>
>>>>>>>>>>>> --Sean
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>>> - did you consider using the jarsigner API 
>>>>>>>>>>>>>> (jdk.security.jarsigner) instead of the command-line? I 
>>>>>>>>>>>>>> think this would be better (if possible) and it would 
>>>>>>>>>>>>>> give us some more tests of that API.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --Sean
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>> Please review this manual test for checking if a jar, 
>>>>>>>>>>>>>>> which is signed and timestamped by a JDK build, could be 
>>>>>>>>>>>>>>> verified by other JDK builds.
>>>>>>>>>>>>>>> It also can be used to check if the default timestamp 
>>>>>>>>>>>>>>> digest algorithm on signing is SHA-256.
>>>>>>>>>>>>>>> For more details, please look through the test summary.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>>>>>>>>>> Webrev: 
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>> John Jiang
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>



From sean.coffey at oracle.com  Wed Aug 16 12:14:11 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 16 Aug 2017 13:14:11 +0100
Subject: RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java test
 crashed due to unhandled case of cipher length value as 0
Message-ID: <3b6494f6-9bd5-bc4a-651e-1a4b6fc28ba9@oracle.com>

Looking to backport this fix to jdk8u-dev. The bug report is not public 
but the JDK 9 review thread captures the details. The fix is similar. 
Some extra intrinsics work in jdk9 wasn't applicable for the jdk8u-dev 
port.


http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044560.html 

webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u/webrev/

-- 
Regards,
Sean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From adam.petcher at oracle.com  Wed Aug 16 14:02:39 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 16 Aug 2017 10:02:39 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <62c4b6e0-612a-0e5f-0db7-461fed5d5fe4@gmail.com>
References: 
 <03fccb17-c797-c2e6-3ea3-3d236bf448c4@oracle.com>
 <4a12f68d-7f82-59a0-c97d-34ae4792ffbf@oracle.com>
 <62c4b6e0-612a-0e5f-0db7-461fed5d5fe4@gmail.com>
Message-ID: 

On 8/15/2017 5:29 PM, Anders Rundgren wrote:

> Does this mean that the following is correct?
>
> EC public key:
>
> public interface ECPublicKey
> extends PublicKey, ECKey
>
>
> CFRG/RFC 7748 public key:
>
> public class TheActualImplememtationClass
> extends PublicKey, ByteArrayKey

Basically, yes. My latest prototype has something like:
class XDHPublicKeyImpl extends X509Key implements ByteArrayKey, PublicKey

So it supports X.509 encoding through getEncoded(), and raw encoding 
through ByteArrayKey. But perhaps ByteArrayKey and X.509 encoding is not 
necessary---see Xuelei's latest suggestion on this thread related to this.

>
>
> If so, it should work. Documentation seems a bit less obvious though
> which is why I advocated a more direct approach.
>
> Cheers,
> Anders
>



From adam.petcher at oracle.com  Wed Aug 16 15:18:13 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 16 Aug 2017 11:18:13 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
Message-ID: 

On 8/15/2017 7:05 PM, Michael StJohns wrote:
> On 8/15/2017 1:43 PM, Xuelei Fan wrote:
>> On 8/11/2017 7:57 AM, Adam Petcher wrote:
>>>
>>> I'm also coming to the conclusion that using X.509 encoding for this 
>>> sort of interoperability is too onerous, and we should come up with 
>>> something better. Maybe we should add a new general-purpose 
>>> interface that exposes some structure in an algorithm-independent 
>>> way. Something like this:
>>>
>>> package java.security.interfaces;
>>> public interface ByteArrayValue {
>>>
>>>      String getAlgorithm();
>>>      AlgorithmParameterSpec getParams();
>>>      byte[] getValue();
>>> }
>>>
>> I'm not sure how to use the above interface in an application.
>
> This is sort of the moral equivalent of using the TXT RR record in DNS 
> and the arguments are similar.
>
> This is a bad idea.

I'm not a DNS expert, so I apologize in advance if I misunderstood your 
argument. What I think you are saying is that it is bad to store 
something in a string or byte array which has no semantics, and it is 
better to store information in a more structured way that has a clear 
semantics. I agree with this.

My intention with this ByteArrayValue is to only use it for information 
that has a clear semantics when represented as a byte array, and a byte 
array is a convenient and appropriate representation for the algorithms 
involved (so there isn't a lot of unnecessary conversion). This is the 
case for public/private keys in RFC 7748/8032:

1) RFC 8032: "An EdDSA private key is a b-bit string k." "The EdDSA 
public key is ENC(A)." (ENC is a function from integers to little-endian 
bit strings.
2) RFC 7748: "Alice generates 32 random bytes in a[0] to a[31] and 
transmits K_A =X25519(a, 9) to Bob..." The X25519 and X448 functions, as 
described in the RFC, take bit strings as input and produce bit strings 
as output.

So I think that a byte array is the correct representation for 
public/private keys in these two RFCs.

>
>>
>> I don't worry about this issue any more.  At present, each 
>> java.security.Key has three characters (see the API Java doc):
>> . an algorithm
>> . an encoded form
>> . a format
>>
>> The format could be "X.509", and could be "RAW" (like 
>> ByteArrayValue.getValue()).  I would suggest have the named curve in 
>> the algorithm characters, and use "RAW" as the encode format.
>> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
> Um... I think that doesn't make a lot of sense.  The default contract 
> for public keys is X.509 and the default for private keys is PKCS#8.  
> Almost all uses of the encoded formats are related to PKIX related 
> functions.   (See for info the javadoc for PublicKey).

I'm concerned about this, too. Ideally, we want PKI code to handle these 
new keys without modification. The javadoc wording makes it a little 
unclear whether public keys *must* use X.509 encoding, but using other 
encodings for public keys would probably be surprising.

>
> To be JCA compliant you need all of: 
>
Are you describing hard compliance requirements or more informal 
expectations? If it's the former, where are these requirements documented?



From xuelei.fan at oracle.com  Wed Aug 16 16:31:57 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 16 Aug 2017 09:31:57 -0700
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
Message-ID: <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>

On 8/16/2017 8:18 AM, Adam Petcher wrote:
>>>
>>> I don't worry about this issue any more.  At present, each 
>>> java.security.Key has three characters (see the API Java doc):
>>> . an algorithm
>>> . an encoded form
>>> . a format
>>>
>>> The format could be "X.509", and could be "RAW" (like 
>>> ByteArrayValue.getValue()).  I would suggest have the named curve in 
>>> the algorithm characters, and use "RAW" as the encode format.
>>> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
>> Um... I think that doesn't make a lot of sense.  The default contract 
>> for public keys is X.509 and the default for private keys is PKCS#8. 
>> Almost all uses of the encoded formats are related to PKIX related 
>> functions.   (See for info the javadoc for PublicKey).
> 
> I'm concerned about this, too. Ideally, we want PKI code to handle these 
> new keys without modification. The javadoc wording makes it a little 
> unclear whether public keys *must* use X.509 encoding, but using other 
> encodings for public keys would probably be surprising.
I have not had a conclusion, but I was wondering if almost all uses of 
the encoded formats are related to PKIX related functions, whether it is 
still a priority to support encoding other than X.509?

So far, I think our proposal works.  The concern is mainly about how to 
*simplify* the transaction between two formats (Raw, PKIX, XML and JSON) 
in applications.  I don't worry about the transaction too much as it is 
doable with our current proposal, but just not as straightforward as 
exposing the RAW public key.

If we want to simplify the transaction, I see your concerns of my 
proposal above.  We may keep using "X.509" for default, and define a new 
key spec.  The encoded form for X.509 is as:

      SubjectPublicKeyInfo ::= SEQUENCE {
          algorithm AlgorithmIdentifier,
          subjectPublicKey BIT STRING
      }

The new encoded form could be just the subjectPublicKey field in the 
SubjectPublicKeyInfo above.

However, I'm not very sure of how common the transaction is required and 
whether it is beyond the threshold to be a public API in JRE.

On 8/15/2017 4:05 PM, Michael StJohns wrote:
 > Here's what I think should happen:
 >
 > 1) ECPoint gets a document modification to handle compressed points. The
 > X is the X value, the Y is -1, 0 or 1 depending on positive negative or
 > don't care for the sign of the Y value.   (This means that the byte
 > array public key gets handled as a BigInteger). Any value other than 0,
 > -1 or 1 for Y indicates a normal X Y point.
 >
 > 2) EllipticCurve gets a document modification to describe the mappings
 > for Edwards and Montgomery curves as discussed previously.
 >
 > 3) Two classes are added to java.security.spec:
 > java.security.spec.ECFieldEdwards and
 > java.security.spec.ECFieldMontgomery - both of which implement ECField.
 >
 > 4) The ECFieldEdwards/Montgomery classes contain an indication of
 > whether the curve is signature only, key agreement only or both. They
 > also contain any parameters that can't be mapped in EllipticCurve
 >
 > 5) Using the above, someone specifies the curve sets for the four new
 > curves as ECParameterSpec's and we iterate until we're satisfied we've
 > got a standard public representation that can be used for other than
 > the 4 curves.
 >
 > 6) Until the JCA is updated, a provider for the new curves can use its
 > own concrete ECField classes and later make them be subclasses of the
 > java.security.spec.ECFieldMontgomery etc.  It's not ideal, but it does
 > let the guys who are chomping at the bit do an implementation while
 > waiting for the JCA to be updated.
 >
 > 7) No other changes to the JCA are made.  The providers implement
 > SubjectPublicKeyInfo and PKCS8 as the standard encodings  using the
 > definitions in
 > https://tools.ietf.org/html/draft-ietf-curdle-pkix-newcurves-00 and
 > RFC5480.
 >
 > The new keys remain tagged as ECKeys.  Old code won't notice (because
 > old code is using old curves).  New code (new providers) will have to
 > pay attention to EllipticCurve and ECField information if its handling
 > both types of curves.  As is the case now, no provider need support
 > every curve or even every field type.
 >
My concern is about the case to use old provider and new provider all 
together at the same time.  JDK is a multiple providers coexisting 
environment.  We cannot grant that old code only uses old curves (old 
providers) and new code only uses new curves (new providers).

There is an example in my August 10 reply:
 
http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html

Xuelei


From sean.mullan at oracle.com  Wed Aug 16 18:52:12 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 16 Aug 2017 14:52:12 -0400
Subject: CSR Review for 8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: <53C614E5-B4C0-4F33-8403-3A6B8420F39E@oracle.com>
References: <16c8c172-3fd9-28f7-17e6-40c2a6731056@oracle.com>
 
 
 <53C614E5-B4C0-4F33-8403-3A6B8420F39E@oracle.com>
Message-ID: <1524a1be-6935-ea4c-0445-579d41d2a112@oracle.com>

Thanks, can you also review the corresponding webrev:

http://cr.openjdk.java.net/~mullan/webrevs/8159544/

I'm also copying build-dev as there is one Makefile change in 
jdk.webrev.00.

--Sean


On 8/10/17 9:38 PM, Weijun Wang wrote:
> Done.
> 
> Thanks
> Max
> 
>> On Aug 10, 2017, at 11:36 PM, Sean Mullan  wrote:
>>
>> On 8/9/17 8:02 PM, Weijun Wang wrote:
>>> Looks fine. Should the specification part be formatted with 
 and fixed fonts?
>>
>> Fixed. Can you add your name as Reviewer (you need to edit the CSR and add your name to the "Reviewed By" box).
>>
>> Thanks,
>> Sean
>>
>>> Thanks
>>> Max
>>>> On Aug 10, 2017, at 3:15 AM, Sean Mullan  wrote:
>>>>
>>>> Max,
>>>>
>>>> Could you please review the following CSR:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8186047
>>>>
>>>> Thanks,
>>>> Sean
> 


From mstjohns at comcast.net  Wed Aug 16 19:17:32 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 16 Aug 2017 15:17:32 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
Message-ID: <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>

On 8/16/2017 11:18 AM, Adam Petcher wrote:
> On 8/15/2017 7:05 PM, Michael StJohns wrote:
>> On 8/15/2017 1:43 PM, Xuelei Fan wrote:
>>> On 8/11/2017 7:57 AM, Adam Petcher wrote:
>>>>
>>>> I'm also coming to the conclusion that using X.509 encoding for 
>>>> this sort of interoperability is too onerous, and we should come up 
>>>> with something better. Maybe we should add a new general-purpose 
>>>> interface that exposes some structure in an algorithm-independent 
>>>> way. Something like this:
>>>>
>>>> package java.security.interfaces;
>>>> public interface ByteArrayValue {
>>>>
>>>>      String getAlgorithm();
>>>>      AlgorithmParameterSpec getParams();
>>>>      byte[] getValue();
>>>> }
>>>>
>>> I'm not sure how to use the above interface in an application.
>>
>> This is sort of the moral equivalent of using the TXT RR record in 
>> DNS and the arguments are similar.
>>
>> This is a bad idea.
>
> I'm not a DNS expert, so I apologize in advance if I misunderstood 
> your argument. What I think you are saying is that it is bad to store 
> something in a string or byte array which has no semantics, and it is 
> better to store information in a more structured way that has a clear 
> semantics. I agree with this.


>
> My intention with this ByteArrayValue is to only use it for 
> information that has a clear semantics when represented as a byte 
> array, and a byte array is a convenient and appropriate representation 
> for the algorithms involved (so there isn't a lot of unnecessary 
> conversion). This is the case for public/private keys in RFC 7748/8032:
>
> 1) RFC 8032: "An EdDSA private key is a b-bit string k." "The EdDSA 
> public key is ENC(A)." (ENC is a function from integers to 
> little-endian bit strings.
> 2) RFC 7748: "Alice generates 32 random bytes in a[0] to a[31] and 
> transmits K_A =X25519(a, 9) to Bob..." The X25519 and X448 functions, 
> as described in the RFC, take bit strings as input and produce bit 
> strings as output.

Thanks for making my point for me.  The internal representation of the 
public point is an integer.  It's only when encoding or decoding that it 
gets externally represented as an array of bytes.  (And yes, I 
understand that the RFC defines an algorithm using little endian byte 
array representations of the integers - but that's the implementation's 
call, not the API).

With respect to the output of the KeyAgreement algorithm - your (2) 
above, the transmission representation (e.g. the encoded public key) is 
little endian byte array representation of an integer.  The internal 
representation is - wait for it - integer.

I have no problems at all with any given implementation using little 
endian math internally.  For the purposes of using JCA, stick with 
BigInteger to represent your integers.  Use your provider encoding 
methods to translate between what the math is internally and what the 
bits are externally if necessary.  Implement the conversion methods for 
the factory and for dealing with the existing EC classes.   Maybe get 
BigInteger to be extended to handle (natively) littleEndian 
representation (as well as fixed length outputs necessary for things 
like ECDH).






>
> So I think that a byte array is the correct representation for 
> public/private keys in these two RFCs.

Nope.

>
>>
>>>
>>> I don't worry about this issue any more.  At present, each 
>>> java.security.Key has three characters (see the API Java doc):
>>> . an algorithm
>>> . an encoded form
>>> . a format
>>>
>>> The format could be "X.509", and could be "RAW" (like 
>>> ByteArrayValue.getValue()).  I would suggest have the named curve in 
>>> the algorithm characters, and use "RAW" as the encode format.
>>> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
>> Um... I think that doesn't make a lot of sense.  The default contract 
>> for public keys is X.509 and the default for private keys is PKCS#8.  
>> Almost all uses of the encoded formats are related to PKIX related 
>> functions.   (See for info the javadoc for PublicKey).
>
> I'm concerned about this, too. Ideally, we want PKI code to handle 
> these new keys without modification. The javadoc wording makes it a 
> little unclear whether public keys *must* use X.509 encoding, but 
> using other encodings for public keys would probably be surprising.

There's two different things going on here - many encodings (e.g. for EC 
public keys there's the fixed length X and fixed length Y byte array big 
endian big integer as well as the X.92 representation indicating both 
compressed and uncompressed points and then the wrapping of those in 
SubjectPublicKeyInfo then there's the raw signature vs the ASN1 SEQUENCE 
OF INTEGER version.)  JCA uses the X.509 stuff quite a bit to deal with 
all of the CertificatePathValidation  and Certificate validation 
things.  But the "rawer" stuff such as DH sometimes uses bare points 
with the curve being understood by context (see for example the Javacard 
KeyAgreement classes).

In the current case, we still need a way to "sign" and "carry" the new 
public points and to be as interoperable with all of the "old" stuff.  I 
guess you could come up with a whole new set of ideas in this space, but 
you would be hated both by the implementers and the folks that actually 
had to try and use it.

If you were just going to use this for crypto protocols (TLS and IPSEC) 
I might agree that X.509 wasn't necessary - but I don't think you want 
to say that either.

>
>>
>> To be JCA compliant you need all of: 
>>
> Are you describing hard compliance requirements or more informal 
> expectations? If it's the former, where are these requirements 
> documented?
>

AFAICT this is implicit in the way the JCA is structured.  A given set 
of key classes is supposed to be able to be converted and used for all 
appropriate APIs (Signature, KeyAgreement, Cipher, KeyPair, 
KeyPairGenerator, KeyFactory etc) and all of those classes I mentioned 
appear to be necessary to ensure this is possible.

Happy to have an argument against that point of view.

Mike




From adam.petcher at oracle.com  Thu Aug 17 15:19:39 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Thu, 17 Aug 2017 11:19:39 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>
Message-ID: 

On 8/16/2017 3:17 PM, Michael StJohns wrote:

> On 8/16/2017 11:18 AM, Adam Petcher wrote:
>>
>> My intention with this ByteArrayValue is to only use it for 
>> information that has a clear semantics when represented as a byte 
>> array, and a byte array is a convenient and appropriate 
>> representation for the algorithms involved (so there isn't a lot of 
>> unnecessary conversion). This is the case for public/private keys in 
>> RFC 7748/8032:
>>
>> 1) RFC 8032: "An EdDSA private key is a b-bit string k." "The EdDSA 
>> public key is ENC(A)." (ENC is a function from integers to 
>> little-endian bit strings.

Oops, minor correction. Here A is a point, so ENC is a function from 
points to little-endian bit strings.

>> 2) RFC 7748: "Alice generates 32 random bytes in a[0] to a[31] and 
>> transmits K_A =X25519(a, 9) to Bob..." The X25519 and X448 functions, 
>> as described in the RFC, take bit strings as input and produce bit 
>> strings as output.
>
> Thanks for making my point for me.  The internal representation of the 
> public point is an integer.  It's only when encoding or decoding that 
> it gets externally represented as an array of bytes.  (And yes, I 
> understand that the RFC defines an algorithm using little endian byte 
> array representations of the integers - but that's the 
> implementation's call, not the API).
>
> With respect to the output of the KeyAgreement algorithm - your (2) 
> above, the transmission representation (e.g. the encoded public key) 
> is little endian byte array representation of an integer.  The 
> internal representation is - wait for it - integer.
>
> I have no problems at all with any given implementation using little 
> endian math internally.  For the purposes of using JCA, stick with 
> BigInteger to represent your integers.  Use your provider encoding 
> methods to translate between what the math is internally and what the 
> bits are externally if necessary. Implement the conversion methods for 
> the factory and for dealing with the existing EC classes.   Maybe get 
> BigInteger to be extended to handle (natively) littleEndian 
> representation (as well as fixed length outputs necessary for things 
> like ECDH).
>

All good points, and I think BigInteger may be a reasonable 
representation to use for public/private key values. I'm just not sure 
that it is better than byte arrays. I'll share some relevant information 
that affects this decision.

First off, one of the goals of RFC 7748 and 8032 is to address some of 
the implementation challenges related to ECC. These algorithms are 
designed to eliminate the need for checks at various stages, and to 
generally make implementation bugs less likely. These improvements are 
motivated by all the ECC implementation bugs that have emerged in the 
last ~20 years. I mention this because I think it is important that we 
choose an API and implementation that allows us to benefit from these 
improvements in the standards. That means we shouldn't necessarily 
follow all the existing ECC patterns in the API and implementation.

Specifically, these standards have properties related to byte arrays 
like: "The Curve25519 function was carefully designed to allow all 
32-byte strings as Diffie-Hellman public keys."[1] If we use 
representations other than byte strings in the API, then we should 
ensure that our representations have the same properties (e.g. every 
BigInteger is a valid public key).

It's best to talk about each type on its own. Of course, one of the 
benefits of using bit strings is that we may have the option of using 
the same class/interface in the API to hold all of these.

RFC 7748 public keys: I think we can reasonably use BigInteger to hold 
public key values. One minor issue is that we need to specify how 
implementations should handle non-canonical values (numbers that are 
less than 0 or greater than p-1). This does not seem like a huge issue, 
though, and the existing ECC API has the same issue. Another minor issue 
is that modeling this as a BigInteger may encourage implementations to 
use BigInteger in the RFC 7748 Montgomery ladder. This would be 
unfortunate because it would leak sensitive information through timing 
channels.

RFC 7748 private keys: This one is a bit more difficult. RFC 7748 
defines a "clamping" operation that ensures that the integers 
corresponding to bit strings have certain properties (e.g. they are a 
multiple of the cofactor). So if we use BigInteger for private keys in 
the API, we need to specify whether the value is clamped or unclamped. 
If an unclamped value is treated as clamped, then this can result in 
security and correctness issues. Also, the RFC treats private keys as 
bit strings---they are not used in any integer operations. So modeling 
them with byte arrays seems just as valid as modeling them with BigInteger.

RFC 8042 public keys: The analysis here is similar to RFC 7748 public 
keys, except we also need to store the (probably compressed) x 
coordinate. So if we don't use byte arrays, we would need to use 
something like ECPoint.

RFC 8032 private keys: These are definitely bit strings, and modeling 
them as integers doesn't make much sense. The only thing that is ever 
done with these private keys is that they are used as input to a hash 
function.

[1] https://cr.yp.to/ecdh.html



From mstjohns at comcast.net  Thu Aug 17 15:25:18 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 17 Aug 2017 11:25:18 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
Message-ID: <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>

On 8/16/2017 12:31 PM, Xuelei Fan wrote:
> On 8/16/2017 8:18 AM, Adam Petcher wrote:
>>>>
>>>> I don't worry about this issue any more.  At present, each 
>>>> java.security.Key has three characters (see the API Java doc):
>>>> . an algorithm
>>>> . an encoded form
>>>> . a format
>>>>
>>>> The format could be "X.509", and could be "RAW" (like 
>>>> ByteArrayValue.getValue()).  I would suggest have the named curve 
>>>> in the algorithm characters, and use "RAW" as the encode format.
>>>> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
>>> Um... I think that doesn't make a lot of sense.  The default 
>>> contract for public keys is X.509 and the default for private keys 
>>> is PKCS#8. Almost all uses of the encoded formats are related to 
>>> PKIX related functions.   (See for info the javadoc for PublicKey).
>>
>> I'm concerned about this, too. Ideally, we want PKI code to handle 
>> these new keys without modification. The javadoc wording makes it a 
>> little unclear whether public keys *must* use X.509 encoding, but 
>> using other encodings for public keys would probably be surprising.
> I have not had a conclusion, but I was wondering if almost all uses of 
> the encoded formats are related to PKIX related functions, whether it 
> is still a priority to support encoding other than X.509?
>
> So far, I think our proposal works.  The concern is mainly about how 
> to *simplify* the transaction between two formats (Raw, PKIX, XML and 
> JSON) in applications.  I don't worry about the transaction too much 
> as it is doable with our current proposal, but just not as 
> straightforward as exposing the RAW public key.
>
> If we want to simplify the transaction, I see your concerns of my 
> proposal above.  We may keep using "X.509" for default, and define a 
> new key spec.  The encoded form for X.509 is as:
>
>      SubjectPublicKeyInfo ::= SEQUENCE {
>          algorithm AlgorithmIdentifier,
>          subjectPublicKey BIT STRING
>      }
>
> The new encoded form could be just the subjectPublicKey field in the 
> SubjectPublicKeyInfo above.
>
> However, I'm not very sure of how common the transaction is required 
> and whether it is beyond the threshold to be a public API in JRE.

There's a proposed defined format for PKIX keys on the new curves - the 
IETF CURDLE working group is working through that.  JCA should use that 
and not invent something new.


>
>
> >
> > The new keys remain tagged as ECKeys.  Old code won't notice (because
> > old code is using old curves).  New code (new providers) will have to
> > pay attention to EllipticCurve and ECField information if its handling
> > both types of curves.  As is the case now, no provider need support
> > every curve or even every field type.
> >
> My concern is about the case to use old provider and new provider all 
> together at the same time.  JDK is a multiple providers coexisting 
> environment.  We cannot grant that old code only uses old curves (old 
> providers) and new code only uses new curves (new providers).

I did see this email and commented on it.  I think you're still missing 
the point that not every provider implements (or is required to 
implement) every curve.  And in fact I argued that it was somewhat 
stupid that the underlying C code in the SunEC provider was at odds with 
the code in the SunEC java side with respect to known curves and how 
they were handled. (Subject was RFR 8182999: SunEC throws 
ProviderException on invalid curves).


Consider - currently if I don't specify a provider, and there are two 
providers, and the lower priority provider implements "curveFoobar" but 
the higher priority provider does not, and I use an ECGenParameterSpec 
of "curveFoobar" to try and generate a key, I get a failure because I 
got the higher priority provider (which gets selected because JCA 
doesn't yet know that I want curveFoobar ) that doesn't do that curve.  
I need to specify the same provider throughout the entire process to 
make sure things work as expected AND I need to specify the provider 
that implements the curve I want.


This is the same for ANY current publicly known curve - different 
providers may implement all some or none of them.  So extending this 
model for the curve25519 stuff isn't going to be any different old 
provider and new provider wise than is currently the case.   If you want 
the new curves, you have to specify the new providers.  If the new and 
old providers don't implement the same curves, you may need to deal with 
two different providers simultaneously - and that's not something that 
just happens.

I don't think your concerns are valid.  I may still be missing something 
here - but would ask for a real-world example that actually shows breakage.

Treat these simply as new curves and let's move forward with very 
minimal changes to the public API.


Mike





>
> There is an example in my August 10 reply:
>
> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html 
>
>
> Xuelei




From xuelei.fan at oracle.com  Thu Aug 17 17:28:00 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 17 Aug 2017 10:28:00 -0700
Subject: JCA design for RFC 7748
In-Reply-To: <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
 <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>
Message-ID: <878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com>

On 8/17/2017 8:25 AM, Michael StJohns wrote:
> On 8/16/2017 12:31 PM, Xuelei Fan wrote:
>> On 8/16/2017 8:18 AM, Adam Petcher wrote:
>>>>>
>>>>> I don't worry about this issue any more.  At present, each 
>>>>> java.security.Key has three characters (see the API Java doc):
>>>>> . an algorithm
>>>>> . an encoded form
>>>>> . a format
>>>>>
>>>>> The format could be "X.509", and could be "RAW" (like 
>>>>> ByteArrayValue.getValue()).  I would suggest have the named curve 
>>>>> in the algorithm characters, and use "RAW" as the encode format.
>>>>> If X.509 encoding is required, KeyFactory.getKeySpec?() could do it.
>>>> Um... I think that doesn't make a lot of sense.  The default 
>>>> contract for public keys is X.509 and the default for private keys 
>>>> is PKCS#8. Almost all uses of the encoded formats are related to 
>>>> PKIX related functions.   (See for info the javadoc for PublicKey).
>>>
>>> I'm concerned about this, too. Ideally, we want PKI code to handle 
>>> these new keys without modification. The javadoc wording makes it a 
>>> little unclear whether public keys *must* use X.509 encoding, but 
>>> using other encodings for public keys would probably be surprising.
>> I have not had a conclusion, but I was wondering if almost all uses of 
>> the encoded formats are related to PKIX related functions, whether it 
>> is still a priority to support encoding other than X.509?
>>
>> So far, I think our proposal works.  The concern is mainly about how 
>> to *simplify* the transaction between two formats (Raw, PKIX, XML and 
>> JSON) in applications.  I don't worry about the transaction too much 
>> as it is doable with our current proposal, but just not as 
>> straightforward as exposing the RAW public key.
>>
>> If we want to simplify the transaction, I see your concerns of my 
>> proposal above.  We may keep using "X.509" for default, and define a 
>> new key spec.  The encoded form for X.509 is as:
>>
>>      SubjectPublicKeyInfo ::= SEQUENCE {
>>          algorithm AlgorithmIdentifier,
>>          subjectPublicKey BIT STRING
>>      }
>>
>> The new encoded form could be just the subjectPublicKey field in the 
>> SubjectPublicKeyInfo above.
>>
>> However, I'm not very sure of how common the transaction is required 
>> and whether it is beyond the threshold to be a public API in JRE.
> 
> There's a proposed defined format for PKIX keys on the new curves - the 
> IETF CURDLE working group is working through that.  JCA should use that 
> and not invent something new.
> 
> 
>>
>>
>> >
>> > The new keys remain tagged as ECKeys.  Old code won't notice (because
>> > old code is using old curves).  New code (new providers) will have to
>> > pay attention to EllipticCurve and ECField information if its handling
>> > both types of curves.  As is the case now, no provider need support
>> > every curve or even every field type.
>> >
>> My concern is about the case to use old provider and new provider all 
>> together at the same time.  JDK is a multiple providers coexisting 
>> environment.  We cannot grant that old code only uses old curves (old 
>> providers) and new code only uses new curves (new providers).
> 
> I did see this email and commented on it.  I think you're still missing 
> the point that not every provider implements (or is required to 
> implement) every curve.  And in fact I argued that it was somewhat 
> stupid that the underlying C code in the SunEC provider was at odds with 
> the code in the SunEC java side with respect to known curves and how 
> they were handled. (Subject was RFR 8182999: SunEC throws 
> ProviderException on invalid curves).
> 
> 
> Consider - currently if I don't specify a provider, and there are two 
> providers, and the lower priority provider implements "curveFoobar" but 
> the higher priority provider does not, and I use an ECGenParameterSpec 
> of "curveFoobar" to try and generate a key, I get a failure because I 
> got the higher priority provider (which gets selected because JCA 
> doesn't yet know that I want curveFoobar ) that doesn't do that curve. I 
> need to specify the same provider throughout the entire process to make 
> sure things work as expected AND I need to specify the provider that 
> implements the curve I want.
> 
> 
> This is the same for ANY current publicly known curve - different 
> providers may implement all some or none of them.  So extending this 
> model for the curve25519 stuff isn't going to be any different old 
> provider and new provider wise than is currently the case.   If you want 
> the new curves, you have to specify the new providers.  If the new and 
> old providers don't implement the same curves, you may need to deal with 
> two different providers simultaneously - and that's not something that 
> just happens.
> 
I see your points.  Not-binding to a provider cause problems; binding to 
a provider cause other problems.  There are a few complains on the 
problems, and impact the real world applications in practice.


> I don't think your concerns are valid.  I may still be missing something 
> here - but would ask for a real-world example that actually shows breakage.
> 
I happened to have a real-world example.  See
    https://bugs.openjdk.java.net/browse/JDK-8064330

This is an interesting bug.  At first it is requested to support SHA224 
in JSSE implementation. And, SHA224 is added as the supported hash 
algorithm for TLS.  However, because SunMSCAPI does not support SHA224 
signature, compatibility issues comes.  So we removed SHA224 if the 
SunMSCAPI is presented.  Later, one found the code is unusual as SHA224 
and the related signature algorithms are supported by the underlying 
providers, look like no reason to limit the use of SHA224.  So, SHA224 
is added back and then the compatibility issues come back again.  Then 
we removed SHA224 again if the SunMSCAPI is presented.  However, at the 
same time, another request is asking to support SHA224 on Windows.  The 
API design itself put me in a either-or situation.  I would try to avoid 
it if possible for new design.

> Treat these simply as new curves and let's move forward with very 
> minimal changes to the public API.
> 
I would like to treat it as two things.  One is to support new curves 
for new forms.  The other one is to support named curves [1].  For the 
support of new forms,  there are still significant problems to solve. 
For the support of named curves (including the current EC form), looks 
like we are in a not-that-bad situation right now.  Will the named 
curves solution impacts the support of new curves APIs in the future?  I 
don't see the impact yet.  I may missing something, but I see no reason 
to option out the named curves support.

Xuelei

[1]: 
http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html

> 
> Mike
> 
> 
> 
> 
> 
>>
>> There is an example in my August 10 reply:
>>
>> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html 
>>
>>
>> Xuelei
> 
> 


From mstjohns at comcast.net  Thu Aug 17 17:44:30 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 17 Aug 2017 13:44:30 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>
 
Message-ID: <5c51266e-9826-0bec-bb2c-e4dc467839b3@comcast.net>

See inline.

On 8/17/2017 11:19 AM, Adam Petcher wrote:
> On 8/16/2017 3:17 PM, Michael StJohns wrote:
>
>> On 8/16/2017 11:18 AM, Adam Petcher wrote:
>>>
>>> My intention with this ByteArrayValue is to only use it for 
>>> information that has a clear semantics when represented as a byte 
>>> array, and a byte array is a convenient and appropriate 
>>> representation for the algorithms involved (so there isn't a lot of 
>>> unnecessary conversion). This is the case for public/private keys in 
>>> RFC 7748/8032:
>>>
>>> 1) RFC 8032: "An EdDSA private key is a b-bit string k." "The EdDSA 
>>> public key is ENC(A)." (ENC is a function from integers to 
>>> little-endian bit strings.
>
> Oops, minor correction. Here A is a point, so ENC is a function from 
> points to little-endian bit strings.
>
>>> 2) RFC 7748: "Alice generates 32 random bytes in a[0] to a[31] and 
>>> transmits K_A =X25519(a, 9) to Bob..." The X25519 and X448 
>>> functions, as described in the RFC, take bit strings as input and 
>>> produce bit strings as output.
>>
>> Thanks for making my point for me.  The internal representation of 
>> the public point is an integer.  It's only when encoding or decoding 
>> that it gets externally represented as an array of bytes.  (And yes, 
>> I understand that the RFC defines an algorithm using little endian 
>> byte array representations of the integers - but that's the 
>> implementation's call, not the API).
>>
>> With respect to the output of the KeyAgreement algorithm - your (2) 
>> above, the transmission representation (e.g. the encoded public key) 
>> is little endian byte array representation of an integer.  The 
>> internal representation is - wait for it - integer.
>>
>> I have no problems at all with any given implementation using little 
>> endian math internally.  For the purposes of using JCA, stick with 
>> BigInteger to represent your integers.  Use your provider encoding 
>> methods to translate between what the math is internally and what the 
>> bits are externally if necessary. Implement the conversion methods 
>> for the factory and for dealing with the existing EC classes.   Maybe 
>> get BigInteger to be extended to handle (natively) littleEndian 
>> representation (as well as fixed length outputs necessary for things 
>> like ECDH).
>>
>
> All good points, and I think BigInteger may be a reasonable 
> representation to use for public/private key values. I'm just not sure 
> that it is better than byte arrays. I'll share some relevant 
> information that affects this decision.
>
> First off, one of the goals of RFC 7748 and 8032 is to address some of 
> the implementation challenges related to ECC. These algorithms are 
> designed to eliminate the need for checks at various stages, and to 
> generally make implementation bugs less likely. These improvements are 
> motivated by all the ECC implementation bugs that have emerged in the 
> last ~20 years. I mention this because I think it is important that we 
> choose an API and implementation that allows us to benefit from these 
> improvements in the standards. That means we shouldn't necessarily 
> follow all the existing ECC patterns in the API and implementation.

No - it means that the authors of the RFCs have a bias to have their 
code be the only code.  As I note below I don't actually think they got 
everything right.   The underlying math is really what matters, and the 
API should be able to handle any implementation that gets the math correct.

>
> Specifically, these standards have properties related to byte arrays 
> like: "The Curve25519 function was carefully designed to allow all 
> 32-byte strings as Diffie-Hellman public keys."[1]

This statement is actually a problem.  Valid keys are in the range of 1 
to p-1 for the field (with some additional pruning).   32 byte strings 
(or 256 bit integers) do not map 1-1 into that space.  E.g. there are 
some actual canonical keys where multiple (at least 2) 32 byte strings 
map to them.  (See the pruning and clamping algorithms).  The NIST 
private key generation for EC private keys mitigates this bias by either 
(a) repeatedly generating random keys until you get one in the range or 
(b) generating a key stream with extra (64) bits and reducing that mod p 
of the curve.


> If we use representations other than byte strings in the API, then we 
> should ensure that our representations have the same properties (e.g. 
> every BigInteger is a valid public key).
>
> It's best to talk about each type on its own. Of course, one of the 
> benefits of using bit strings is that we may have the option of using 
> the same class/interface in the API to hold all of these.
>
> RFC 7748 public keys: I think we can reasonably use BigInteger to hold 
> public key values. One minor issue is that we need to specify how 
> implementations should handle non-canonical values (numbers that are 
> less than 0 or greater than p-1). This does not seem like a huge 
> issue, though, and the existing ECC API has the same issue. Another 
> minor issue is that modeling this as a BigInteger may encourage 
> implementations to use BigInteger in the RFC 7748 Montgomery ladder. 
> This would be unfortunate because it would leak sensitive information 
> through timing channels.

When you do the conversion from a key spec to a key you do what you're 
supposed to do - e.g. I think its mod p to reduce it.  Either that or 
you throw an error.  That's implementation side so not a big problem 
except that the documentation should explain what is supposed to happen.

>
> RFC 7748 private keys: This one is a bit more difficult. RFC 7748 
> defines a "clamping" operation that ensures that the integers 
> corresponding to bit strings have certain properties (e.g. they are a 
> multiple of the cofactor). So if we use BigInteger for private keys in 
> the API, we need to specify whether the value is clamped or unclamped. 
> If an unclamped value is treated as clamped, then this can result in 
> security and correctness issues. Also, the RFC treats private keys as 
> bit strings---they are not used in any integer operations. So modeling 
> them with byte arrays seems just as valid as modeling them with 
> BigInteger.

Nope.  The private keys are actually integers - the first thing that is 
done to the bit string is to "decodeLittleEndian".  Any programmer worth 
their salary is going to do this once on input. The implementation stuff 
described in the RFC then does big integer math on the bytes.

I assume that the PKCS8 conventions will use the bit string - but 
internally, this is going to be an integer of some sort.  It would be 
nice if BigInteger had support for input/output of little endian values 
- but it doesn't.  I expect that anyone who implements this set of 
curves will probably extend BigInteger to make little endian support 
just work.  Externally, the BigInteger in/out stuff  (e.g. key spec's) 
would then be completely backwards compatible.

In any event - please don't confuse the suggested implementation of the 
various RFCs  and the various external representations with the actual 
underlying math.


>
> RFC 8042 public keys: The analysis here is similar to RFC 7748 public 
> keys, except we also need to store the (probably compressed) x 
> coordinate. So if we don't use byte arrays, we would need to use 
> something like ECPoint.
Yup - see my previous email on how to handle this.
>
> RFC 8032 private keys: These are definitely bit strings, and modeling 
> them as integers doesn't make much sense. The only thing that is ever 
> done with these private keys is that they are used as input to a hash 
> function.

Again - no.   The actual private key is what you get after stage 3 of 
section 5.1.5.  E.g. generate a random string of 32 bytes.  Hash it to 
help with the bad random generators (*sheesh*),  Interpret the hash 
after pruning as a little endian integer.   Any programmer worth their 
salary is going to do steps 1-3 once at generation and store the private 
key as that pruned value.   An equivalent  (and possibly stronger) 
generation function would be to randomly generate 320 bits as an 
integer, take that mod p of the curve and then do any additional 
pruning.  That reduces the bias introduced by generating only  256 bits 
from the hash and immediately throwing away the last bit (MSBit of the 
MSByte in little endian terms).


Bernstein et al hide a lot under the covers in the RFCs, but this is 
integer and point math and there's nothing special about it. Forcing the 
transmission formats to be little endian when every other public key 
system uses big endian (and trying to hide that by calling them byte and 
bit strings) seems to be short sighted, but its what we got.   But you 
shouldn't confuse the RFC defined external encodings to be the API you 
need for JCA.  Especially if yet another edwards RFC comes along 
specifying Big Endian encoding for a different curve type. (Or 
interleaved bytes or something that makes sense for a highly parallel 
processing regime but translates poorly to an on the wire representation).

These are Integers  (private scalars) and ECPoints.  The curve parameter 
set needs mapping to the JCA API - but the curves are not anything special.

Mike



>
> [1] https://cr.yp.to/ecdh.html
>



From mstjohns at comcast.net  Thu Aug 17 18:35:34 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Thu, 17 Aug 2017 14:35:34 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
 <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>
 <878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com>
Message-ID: 

On 8/17/2017 1:28 PM, Xuelei Fan wrote:
>> This is the same for ANY current publicly known curve - different 
>> providers may implement all some or none of them.  So extending this 
>> model for the curve25519 stuff isn't going to be any different old 
>> provider and new provider wise than is currently the case.   If you 
>> want the new curves, you have to specify the new providers. If the 
>> new and old providers don't implement the same curves, you may need 
>> to deal with two different providers simultaneously - and that's not 
>> something that just happens.
>>
> I see your points.  Not-binding to a provider cause problems; binding 
> to a provider cause other problems.  There are a few complains on the 
> problems, and impact the real world applications in practice.

Basically, this is a failing of imagination when the various 
getInstance() methods were defined.  Now its possible to use 
Security.getProvider(Map)  to good effect (but more work) 
to find appropriate providers for appropriate signature/key agreement 
algorithms and curves.


>
>
>> I don't think your concerns are valid.  I may still be missing 
>> something here - but would ask for a real-world example that actually 
>> shows breakage.
>>
> I happened to have a real-world example.  See
> https://bugs.openjdk.java.net/browse/JDK-8064330

I'm not sure how this applies to the current question of whether or not 
its possible to integrate new EC curves?

>
>
> This is an interesting bug.  At first it is requested to support 
> SHA224 in JSSE implementation. And, SHA224 is added as the supported 
> hash algorithm for TLS.  However, because SunMSCAPI does not support 
> SHA224 signature, compatibility issues comes.  So we removed SHA224 if 
> the SunMSCAPI is presented.  Later, one found the code is unusual as 
> SHA224 and the related signature algorithms are supported by the 
> underlying providers, look like no reason to limit the use of SHA224.  
> So, SHA224 is added back and then the compatibility issues come back 
> again.  Then we removed SHA224 again if the SunMSCAPI is presented.  
> However, at the same time, another request is asking to support SHA224 
> on Windows.  The API design itself put me in a either-or situation.  I 
> would try to avoid it if possible for new design.

This appears to be an MSCAPI issue vice a JSSE issue.  And the JCA 
specifically disclaims the guaranteed ability to use cryptographic 
objects from one provider in another provider.   Secondary users like 
the JSSE probably need to stick to a single provider for a given connection.

>
>
>> Treat these simply as new curves and let's move forward with very 
>> minimal changes to the public API.
>>
> I would like to treat it as two things.  One is to support new curves 
> for new forms.  The other one is to support named curves [1].  For the 
> support of new forms,  there are still significant problems to solve. 
> For the support of named curves (including the current EC form), looks 
> like we are in a not-that-bad situation right now.  Will the named 
> curves solution impacts the support of new curves APIs in the future?  
> I don't see the impact yet.  I may missing something, but I see no 
> reason to option out the named curves support.
>

I'm not sure why you think this (the example in [1]) can't be done?

I gave the example elsewhere, but let me expand it with my comment above 
(possibly faking the hash key names - sorry):

>         HashMap neededAlgs = new HashMap<>();
> 	neededAlgs.put("Signature.EdDSA", "");
>          neededAlgs.put("AlgorithmParameters.EC SupportedCurves", "ed25519")


> Provider[] p = Security.getProviders(neededAlgs);
> if (p == null) throw new Exception ("Oops");

> AlgorithmParameters parameters = AlgorithmParameters.getInstance("EC", p[0]);
>          parameters.init(new ECGenParameterSpec("ed25519"));
>          ECParameterSpec ecParameters = parameters.getParameterSpec(ECParameterSpec.class);
>
>          return KeyFactory.getInstance("EC", p[0]).generatePublic(new ECPublicKeySpec(new ECPoint(x, y), ecParameters));

If you're talking more generally, NamedCurves should be a form of 
ECParameterSpec so you can read the name from the key, but there's no 
support for adding names to that spec.  Maybe extend it?  E.g.:

package java.security.spec;
public class NamedECParameterSpec extends ECParameterSpec {

    private Collection names;
    private Collection oids;
    public NamedECParameterSpec (EllipticCurve curve, ECPoint g, 
BigInteger n, int h, Collection names, Collection oids) {
         super (curve, g, n, h);
         if (names != null) {
             this.names = new ArrayList(names);
         }
         if (oids != null) {
             this.oids = new ArrayList(oids);
        }
   }

    public Collection getNames() {
         if (names == null)
              return (Collection)Collections.EMPTY_LIST;
          else
             return Collections.unmodifiableList(names);
     }

     etc....

    This makes it easier to get exactly what you want from a key. 
Assuming the provider implements it.

Mike


> Xuelei
>
> [1]: 
> http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html 
>
>
>>
>> Mike
>>
>>
>>
>>
>>
>>>
>>> There is an example in my August 10 reply:
>>>
>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016199.html 
>>>
>>>
>>> Xuelei
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.mullan at oracle.com  Thu Aug 17 19:08:00 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 17 Aug 2017 15:08:00 -0400
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
Message-ID: 

Please review this JDK 10 change to remove the deprecated classes in 
com.sun.security.auth.** that have been previously marked with 
forRemoval=true in JDK 9.

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/

I have also copied Jan for reviewing a change in langtools, and also 
build-dev for a change to one of the JDK Makefiles.

Thanks,
Sean


From xuelei.fan at oracle.com  Thu Aug 17 23:01:33 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 17 Aug 2017 16:01:33 -0700
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
 <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>
 <878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com>
 
Message-ID: 

On 8/17/2017 11:35 AM, Michael StJohns wrote:
> On 8/17/2017 1:28 PM, Xuelei Fan wrote:
>>> This is the same for ANY current publicly known curve - different 
>>> providers may implement all some or none of them.  So extending this 
>>> model for the curve25519 stuff isn't going to be any different old 
>>> provider and new provider wise than is currently the case.   If you 
>>> want the new curves, you have to specify the new providers. If the 
>>> new and old providers don't implement the same curves, you may need 
>>> to deal with two different providers simultaneously - and that's not 
>>> something that just happens.
>>>
>> I see your points.  Not-binding to a provider cause problems; binding 
>> to a provider cause other problems.  There are a few complains on the 
>> problems, and impact the real world applications in practice.
> 
> Basically, this is a failing of imagination when the various 
> getInstance() methods were defined.  Now its possible to use 
> Security.getProvider(Map)  to good effect (but more work) 
> to find appropriate providers for appropriate signature/key agreement 
> algorithms and curves.
> 
I'm not sure how this applies to the compatibility impact concern.  See 
more in the example bellow.

> 
>>
>>
>>> I don't think your concerns are valid.  I may still be missing 
>>> something here - but would ask for a real-world example that actually 
>>> shows breakage.
>>>
>> I happened to have a real-world example.  See
>> https://bugs.openjdk.java.net/browse/JDK-8064330
> 
> I'm not sure how this applies to the current question of whether or not 
> its possible to integrate new EC curves?
> 
>>
>>
>> This is an interesting bug.  At first it is requested to support 
>> SHA224 in JSSE implementation. And, SHA224 is added as the supported 
>> hash algorithm for TLS.  However, because SunMSCAPI does not support 
>> SHA224 signature, compatibility issues comes.  So we removed SHA224 if 
>> the SunMSCAPI is presented.  Later, one found the code is unusual as 
>> SHA224 and the related signature algorithms are supported by the 
>> underlying providers, look like no reason to limit the use of SHA224.  
>> So, SHA224 is added back and then the compatibility issues come back 
>> again.  Then we removed SHA224 again if the SunMSCAPI is presented.  
>> However, at the same time, another request is asking to support SHA224 
>> on Windows.  The API design itself put me in a either-or situation.  I 
>> would try to avoid it if possible for new design.
> 
> This appears to be an MSCAPI issue vice a JSSE issue.
MSCAPI is fine as it does not support SHA224.  JSSE is then in a bad 
position because it cannot support SHA224 in a general way even one of 
the underlying provider supports SHA224 but another one not.

> And the JCA 
> specifically disclaims the guaranteed ability to use cryptographic 
> objects from one provider in another provider.
It's not the real problem.  The real problem is that there is a provider 
support the requested algorithms, why not use it?  We can say, the spec 
does not guarantee the behavior, but the application still has a 
problem.  We also can say, we have a design flaw, but the question is 
still there.

> Secondary users like 
> the JSSE probably need to stick to a single provider for a given connection.
> 
Stick to a single provider will open other windows for different 
problems.  JCE spec does not grant one provider could implement all 
services.

>>
>>
>>> Treat these simply as new curves and let's move forward with very 
>>> minimal changes to the public API.
>>>
>> I would like to treat it as two things.  One is to support new curves 
>> for new forms.  The other one is to support named curves [1].  For the 
>> support of new forms,  there are still significant problems to solve. 
>> For the support of named curves (including the current EC form), looks 
>> like we are in a not-that-bad situation right now.  Will the named 
>> curves solution impacts the support of new curves APIs in the future?  
>> I don't see the impact yet.  I may missing something, but I see no 
>> reason to option out the named curves support.
>>
> 
> I'm not sure why you think this (the example in [1]) can't be done?
> 
> I gave the example elsewhere, but let me expand it with my comment above 
> (possibly faking the hash key names - sorry):
> 
>>         HashMap neededAlgs = new HashMap<>();
>> 	neededAlgs.put("Signature.EdDSA", "");
>>          neededAlgs.put("AlgorithmParameters.EC SupportedCurves", "ed25519")
> 
> 
>> Provider[] p = Security.getProviders(neededAlgs);
>> if (p == null) throw new Exception ("Oops");
> 
>> AlgorithmParameters parameters = AlgorithmParameters.getInstance("EC", p[0]);
>>          parameters.init(new ECGenParameterSpec("ed25519"));
>>          ECParameterSpec ecParameters = parameters.getParameterSpec(ECParameterSpec.class);
>>
>>          return KeyFactory.getInstance("EC", p[0]).generatePublic(new ECPublicKeySpec(new ECPoint(x, y), ecParameters));
> 
Hm, good example!

But it is really too weight to use for general application development.

In the example, two crypto operations ("EC" AlgorithmParameters and "EC" 
KeyFactory) are supported in the same provider.   In practice, two 
crypto operations may be supported in different providers.

> If you're talking more generally, NamedCurves should be a form of 
> ECParameterSpec so you can read the name from the key, but there's no 
> support for adding names to that spec.  Maybe extend it?  E.g.:
> 
> package java.security.spec;
> public class NamedECParameterSpec extends ECParameterSpec {
> 
>     private Collection names;
>     private Collection oids;
>     public NamedECParameterSpec (EllipticCurve curve, ECPoint g, 
> BigInteger n, int h, Collection names, Collection oids) {
>          super (curve, g, n, h);
>          if (names != null) {
>              this.names = new ArrayList(names);
>          }
>          if (oids != null) {
>              this.oids = new ArrayList(oids);
>         }
>    }
> 
>     public Collection getNames() {
>          if (names == null)
>               return (Collection)Collections.EMPTY_LIST;
>           else
>              return Collections.unmodifiableList(names);
>      }
> 
>      etc....
> 
>     This makes it easier to get exactly what you want from a key. 
> Assuming the provider implements it.
> 
I see your points.  But my concerns are not really about it.  Except the 
confusing and possibility to map/convert Montgomery curve or Edwards 
curve or other forms [3][4] to Weierstrass form, I did not see how the 
new proposal solve the problems I described in the previous mails [1][2].

Xuelei

>> [1]: 
>> http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html 
[2]: 
http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016194.html
[3]: https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html
[4]: http://mathworld.wolfram.com/EllipticCurve.html


From weijun.wang at oracle.com  Fri Aug 18 00:16:14 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 18 Aug 2017 08:16:14 +0800
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: 
Message-ID: 

Hi Sean

Change looks fine.

And I found another 4 references in comments in jdk/src/java.base/share/classes/javax/security/auth/Policy.java.

BTW, do we have a test to show what lines in various Resources.java files are used where and if one is useless?

Thanks
Max

> On Aug 18, 2017, at 3:08 AM, Sean Mullan  wrote:
> 
> Please review this JDK 10 change to remove the deprecated classes in com.sun.security.auth.** that have been previously marked with forRemoval=true in JDK 9.
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
> 
> I have also copied Jan for reviewing a change in langtools, and also build-dev for a change to one of the JDK Makefiles.
> 
> Thanks,
> Sean



From vincent.x.ryan at oracle.com  Fri Aug 18 08:47:45 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 18 Aug 2017 09:47:45 +0100
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: 
Message-ID: 

Your changes look fine to me. Thanks.


> On 17 Aug 2017, at 20:08, Sean Mullan  wrote:
> 
> Please review this JDK 10 change to remove the deprecated classes in com.sun.security.auth.** that have been previously marked with forRemoval=true in JDK 9.
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
> 
> I have also copied Jan for reviewing a change in langtools, and also build-dev for a change to one of the JDK Makefiles.
> 
> Thanks,
> Sean



From jan.lahoda at oracle.com  Fri Aug 18 12:31:47 2017
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 18 Aug 2017 14:31:47 +0200
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: 
Message-ID: <5996DE33.7020301@oracle.com>

For the langtools change, I think we shouldn't remove the entries from 
the include.list. This list defines which packages/classes should and 
should not be available when compiling for previous versions of the 
platform using --release. The removed entries are exclude entries, so if 
removed, it would mean the classes should be available when compiling 
for previous platform versions, which is not the intent, I think.

Maybe adding a comment (or a JBS entry) that these should be cleaned up 
when --release is no longer supporting 9?

Thanks,
     Jan

On 17.8.2017 21:08, Sean Mullan wrote:
> Please review this JDK 10 change to remove the deprecated classes in
> com.sun.security.auth.** that have been previously marked with
> forRemoval=true in JDK 9.
>
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
>
> I have also copied Jan for reviewing a change in langtools, and also
> build-dev for a change to one of the JDK Makefiles.
>
> Thanks,
> Sean


From sean.coffey at oracle.com  Fri Aug 18 14:01:16 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 18 Aug 2017 15:01:16 +0100
Subject: RFR: 8170157, 8170245: Enable unlimited cryptographic policy by
 default in OracleJDK
Message-ID: <9ca65218-86b0-1209-8f11-9d0b2fd67c2b@oracle.com>

Looking to backport 8170157 to jdk8u-dev. The 8170245 test bug also gets 
pulled in for this port since some tests need cleaning up to deal with 
unlimited crypto environment.

webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8170157.8u.01/webrev/index.html

-- 
Regards,
Sean.



From sean.mullan at oracle.com  Fri Aug 18 15:29:01 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 Aug 2017 11:29:01 -0400
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: 
References: 
 
Message-ID: <1b4d864d-6119-dcee-d56b-a11ad519c9bb@oracle.com>

On 8/17/17 8:16 PM, Weijun Wang wrote:
> Hi Sean
> 
> Change looks fine.
> 
> And I found another 4 references in comments in jdk/src/java.base/share/classes/javax/security/auth/Policy.java.

Good catch. I changed SolarisPrincipal and SolarisNumericUserPrincipal 
to UnixPrincipal and UnixNumericUserPrincipal, respectively.

Updated webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8159544/jdk.webrev.01/

> BTW, do we have a test to show what lines in various Resources.java files are used where and if one is useless?

I don't know. I have copied Naoto to see if he knows.

--Sean

> 
> Thanks
> Max
> 
>> On Aug 18, 2017, at 3:08 AM, Sean Mullan  wrote:
>>
>> Please review this JDK 10 change to remove the deprecated classes in com.sun.security.auth.** that have been previously marked with forRemoval=true in JDK 9.
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
>>
>> I have also copied Jan for reviewing a change in langtools, and also build-dev for a change to one of the JDK Makefiles.
>>
>> Thanks,
>> Sean
> 


From sean.mullan at oracle.com  Fri Aug 18 15:31:19 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 Aug 2017 11:31:19 -0400
Subject: RFR: JDK-8159544: Remove deprecated classes in
 com.sun.security.auth.**
In-Reply-To: <5996DE33.7020301@oracle.com>
References: 
 <5996DE33.7020301@oracle.com>
Message-ID: <34aead44-39eb-fb1e-b6d7-4d995a1ac147@oracle.com>

On 8/18/17 8:31 AM, Jan Lahoda wrote:
> For the langtools change, I think we shouldn't remove the entries from 
> the include.list. This list defines which packages/classes should and 
> should not be available when compiling for previous versions of the 
> platform using --release. The removed entries are exclude entries, so if 
> removed, it would mean the classes should be available when compiling 
> for previous platform versions, which is not the intent, I think.

That makes sense.

> Maybe adding a comment (or a JBS entry) that these should be cleaned up 
> when --release is no longer supporting 9?

Sure. I restored the entries and added the following comment:

#Some of the APIs below have been removed (see JDK-8159544). However, these
#need to be retained until --release no longer supports 9.

See also the updated webrev: 
http://cr.openjdk.java.net/~mullan/webrevs/8159544/langtools.webrev.01/

--Sean

> 
> Thanks,
>      Jan
> 
> On 17.8.2017 21:08, Sean Mullan wrote:
>> Please review this JDK 10 change to remove the deprecated classes in
>> com.sun.security.auth.** that have been previously marked with
>> forRemoval=true in JDK 9.
>>
>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8159544/
>>
>> I have also copied Jan for reviewing a change in langtools, and also
>> build-dev for a change to one of the JDK Makefiles.
>>
>> Thanks,
>> Sean


From mstjohns at comcast.net  Fri Aug 18 18:57:43 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 18 Aug 2017 14:57:43 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <85a4352e-bdae-e965-1e74-f5120a7bafd0@oracle.com>
 <191df68e-a1d0-34c1-e255-d416e1998516@comcast.net>
 <878176fd-7585-a2c2-a5fc-f0c1dbb6083e@oracle.com>
 
 
Message-ID: 

On 8/17/2017 7:01 PM, Xuelei Fan wrote:
> On 8/17/2017 11:35 AM, Michael StJohns wrote:
>> On 8/17/2017 1:28 PM, Xuelei Fan wrote:
>>>> This is the same for ANY current publicly known curve - different 
>>>> providers may implement all some or none of them.  So extending 
>>>> this model for the curve25519 stuff isn't going to be any different 
>>>> old provider and new provider wise than is currently the case. If 
>>>> you want the new curves, you have to specify the new providers. If 
>>>> the new and old providers don't implement the same curves, you may 
>>>> need to deal with two different providers simultaneously - and 
>>>> that's not something that just happens.
>>>>
>>> I see your points.  Not-binding to a provider cause problems; 
>>> binding to a provider cause other problems.  There are a few 
>>> complains on the problems, and impact the real world applications in 
>>> practice.
>>
>> Basically, this is a failing of imagination when the various 
>> getInstance() methods were defined.  Now its possible to use 
>> Security.getProvider(Map)  to good effect (but more 
>> work) to find appropriate providers for appropriate signature/key 
>> agreement algorithms and curves.
>>
> I'm not sure how this applies to the compatibility impact concern.  
> See more in the example bellow.
>
>>
>>>
>>>
>>>> I don't think your concerns are valid.  I may still be missing 
>>>> something here - but would ask for a real-world example that 
>>>> actually shows breakage.
>>>>
>>> I happened to have a real-world example.  See
>>> https://bugs.openjdk.java.net/browse/JDK-8064330
>>
>> I'm not sure how this applies to the current question of whether or 
>> not its possible to integrate new EC curves?
>>
>>>
>>>
>>> This is an interesting bug.  At first it is requested to support 
>>> SHA224 in JSSE implementation. And, SHA224 is added as the supported 
>>> hash algorithm for TLS.  However, because SunMSCAPI does not support 
>>> SHA224 signature, compatibility issues comes.  So we removed SHA224 
>>> if the SunMSCAPI is presented.  Later, one found the code is unusual 
>>> as SHA224 and the related signature algorithms are supported by the 
>>> underlying providers, look like no reason to limit the use of 
>>> SHA224.  So, SHA224 is added back and then the compatibility issues 
>>> come back again.  Then we removed SHA224 again if the SunMSCAPI is 
>>> presented.  However, at the same time, another request is asking to 
>>> support SHA224 on Windows.  The API design itself put me in a 
>>> either-or situation.  I would try to avoid it if possible for new 
>>> design.
>>
>> This appears to be an MSCAPI issue vice a JSSE issue.
> MSCAPI is fine as it does not support SHA224.  JSSE is then in a bad 
> position because it cannot support SHA224 in a general way even one of 
> the underlying provider supports SHA224 but another one not.

No - I don't think both are fine.   MSCAPI could outsource algorithms it 
doesn't have internally to another provider - for a very limited set of 
classes (e.g. MessageDigest and Secure Random), but it would be smarter 
if JSSE just tried to see of the provider it was already using for other 
stuff had the available algorithm (e.g. using the long form of getInstance).

In the above case - MSCAPI should realize that it can't do a 
SHA224with... signature and just throw the appropriate error.  JSSE 
should know which TLS suites MSCAPI can support.  Or at least be able to 
figure out which ones it supports by checking which JCA algorithms are 
supported.

>
>> And the JCA specifically disclaims the guaranteed ability to use 
>> cryptographic objects from one provider in another provider.
> It's not the real problem.  The real problem is that there is a 
> provider support the requested algorithms, why not use it?  We can 
> say, the spec does not guarantee the behavior, but the application 
> still has a problem.  We also can say, we have a design flaw, but the 
> question is still there.

There is no design flaw, there is only incorrect programming. Basically, 
the only non-key related crypto algorithms in the providers are hashing 
and random number generation.    While its possible to use these across 
providers (and you might want to), special casing things to do this 
means (for example) that your FIPS approved signature mechanism might 
end up using a non-fips summary (hash) mechanism.

Every other crypto mechanism has or involves keys.  And there's no 
guarantee that keys are valid across providers.

>
>> Secondary users like the JSSE probably need to stick to a single 
>> provider for a given connection.
>>
> Stick to a single provider will open other windows for different 
> problems.  JCE spec does not grant one provider could implement all 
> services.

An application that needs to use two different cryptographic algorithm 
providers should be doing that explicitly and not having it happen under 
the covers.   For example, I was using the BC provider to deal with 
elliptic curve stuff for a long while.  That meant I was also using BC 
to deal with certificates (because the Sun provider didn't understand 
how to deal with the BC's ECKey implementation).   It was kind of a 
surprise at the time, but made me quite a bit more cautious about making 
sure I didn't leave the selection of the provider up to Java if I was 
doing anything remotely complicated.

Mostly a given provider has to implement all of the concrete classes 
that support a given class of key material - key generation, signatures, 
encryption etc.  Given the internal representation of the concrete 
classes can be anything I wouldn't expect a key generated by provider A 
to work with provider B without some conversion taking place.  In both 
the RSA and EC key spaces, I can convert a key to a spec, then then back 
to a key with minimal problems.  The spec contains ALL of the 
information I need to get a mathematically correct key out the back 
side.  Those keys (mostly the public ones) just work because under the 
covers good providers are running alien keys through a KeyFactory to get 
local keys they can use.


>
>>>
>>>
>>>> Treat these simply as new curves and let's move forward with very 
>>>> minimal changes to the public API.
>>>>
>>> I would like to treat it as two things.  One is to support new 
>>> curves for new forms.  The other one is to support named curves 
>>> [1].  For the support of new forms,  there are still significant 
>>> problems to solve. For the support of named curves (including the 
>>> current EC form), looks like we are in a not-that-bad situation 
>>> right now.  Will the named curves solution impacts the support of 
>>> new curves APIs in the future?  I don't see the impact yet.  I may 
>>> missing something, but I see no reason to option out the named 
>>> curves support.
>>>
>>
>> I'm not sure why you think this (the example in [1]) can't be done?
>>
>> I gave the example elsewhere, but let me expand it with my comment 
>> above (possibly faking the hash key names - sorry):
>>
>>>         HashMap neededAlgs = new HashMap<>();
>>>     neededAlgs.put("Signature.EdDSA", "");
>>>          neededAlgs.put("AlgorithmParameters.EC SupportedCurves", 
>>> "ed25519")
>>
>>
>>> Provider[] p = Security.getProviders(neededAlgs);
>>> if (p == null) throw new Exception ("Oops");
>>
>>> AlgorithmParameters parameters = 
>>> AlgorithmParameters.getInstance("EC", p[0]);
>>>          parameters.init(new ECGenParameterSpec("ed25519"));
>>>          ECParameterSpec ecParameters = 
>>> parameters.getParameterSpec(ECParameterSpec.class);
>>>
>>>          return KeyFactory.getInstance("EC", 
>>> p[0]).generatePublic(new ECPublicKeySpec(new ECPoint(x, y), 
>>> ecParameters));
>>
> Hm, good example!
>
> But it is really too weight to use for general application development.

Umm..  right now about 90+% of the EC stuff focuses on one of the NIST 
curves and pretty much all providers implement those.  But  - the set of 
curves that SunEC supports is different than the set of curves that 
BouncyCastle supports and I have to take that in consideration when 
picking the curve and the provider for my application.

I can either know which provider has which curves up front  (or assume 
they all have the most common curves) and pick the right provider and 
hard code it (and that will work mostly), or use something like the 
above and just have it work going forward.

>
> In the example, two crypto operations ("EC" AlgorithmParameters and 
> "EC" KeyFactory) are supported in the same provider.   In practice, 
> two crypto operations may be supported in different providers.

Actually, in this specific case you COULD use different providers - but 
they'd both have to understand what was in the ECParameterSpec in a 
non-proprietary way.   The first (AlgorithmParameter) provider would 
generate an ECParameterSpec which the second provider (the KeyFactory 
provider) would convert into a concrete public key (along with the other 
data).  Sort of the definition of the use of 'Spec classes.

In the above example, I know this works with the SunEC provider for the 
AlgorithmParameter side - but I'm pretty sure it doesn't work for the 
BouncyCastle side.

>
>> If you're talking more generally, NamedCurves should be a form of 
>> ECParameterSpec so you can read the name from the key, but there's no 
>> support for adding names to that spec.  Maybe extend it?  E.g.:
>>
>> package java.security.spec;
>> public class NamedECParameterSpec extends ECParameterSpec {
>>
>>     private Collection names;
>>     private Collection oids;
>>     public NamedECParameterSpec (EllipticCurve curve, ECPoint g, 
>> BigInteger n, int h, Collection names, Collection oids) {
>>          super (curve, g, n, h);
>>          if (names != null) {
>>              this.names = new ArrayList(names);
>>          }
>>          if (oids != null) {
>>              this.oids = new ArrayList(oids);
>>         }
>>    }
>>
>>     public Collection getNames() {
>>          if (names == null)
>>               return (Collection)Collections.EMPTY_LIST;
>>           else
>>              return Collections.unmodifiableList(names);
>>      }
>>
>>      etc....
>>
>>     This makes it easier to get exactly what you want from a key. 
>> Assuming the provider implements it.
>>
> I see your points.  But my concerns are not really about it. Except 
> the confusing and possibility to map/convert Montgomery curve or 
> Edwards curve or other forms [3][4] to Weierstrass form, I did not see 
> how the new proposal solve the problems I described in the previous 
> mails [1][2].
If by [1] you mean "There is no public api for named curves" - I would 
say that the above actually does provide part of that solution.  There 
are a number of times when I'm trying to convert a public key from Java 
to a smart card where I need to know the curve.  Being able to grab the 
curve name directly from the ECKey->ECParameterSpec would be useful.  If 
you mean there is no lookup by name to get direct to an ECParameterSpec 
- sure, but there are two work arounds.  The one in [1] and the other 
involving generating a key pair using ECGenParameterSpec with the curve 
name and then grabbing the ECParameterSpec from it.  The latter works 
with all providers, but seems clumsy.

I actually think the above solves a bunch of what you want for [2].   
((NamedECParameterSpec)pubKey.getParameterSpec()).getNames()

Your idea in section 4 of [2] makes me uncomfortable as it *really* 
changes the model for parameter based keys (EC, DSA and the new stuff).  
Would you move all of the old key and curves over to a new key type?  
(E.g. the OKPKey stuff).  Would you carry over all the backwards 
compatibility stuff (e.g. the complete set of curve parameters needed 
for the math) in those keys?  If not would you require additional curves 
to be accessible both the old and new ways?

The current stuff for Security.getProviders(Map filters) 
does what you want in section 4 - just in a few more lines.


Later, Mike

>
> Xuelei
>
>>> [1]: 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2013-October/009105.html 
>>
> [2]: 
> http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016194.html
> [3]: https://crypto.stanford.edu/pbc/notes/elliptic/explicit.html
> [4]: http://mathworld.wolfram.com/EllipticCurve.html




From adam.petcher at oracle.com  Fri Aug 18 19:26:18 2017
From: adam.petcher at oracle.com (Adam Petcher)
Date: Fri, 18 Aug 2017 15:26:18 -0400
Subject: JCA design for RFC 7748
In-Reply-To: <5c51266e-9826-0bec-bb2c-e4dc467839b3@comcast.net>
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>
 
 <5c51266e-9826-0bec-bb2c-e4dc467839b3@comcast.net>
Message-ID: 

On 8/17/2017 1:44 PM, Michael StJohns wrote:
> See inline.
>
> On 8/17/2017 11:19 AM, Adam Petcher wrote:
>
>>
>> Specifically, these standards have properties related to byte arrays 
>> like: "The Curve25519 function was carefully designed to allow all 
>> 32-byte strings as Diffie-Hellman public keys."[1]
>
> This statement is actually a problem.  Valid keys are in the range of 
> 1 to p-1 for the field (with some additional pruning).   32 byte 
> strings (or 256 bit integers) do not map 1-1 into that space.  E.g. 
> there are some actual canonical keys where multiple (at least 2) 32 
> byte strings map to them.  (See the pruning and clamping algorithms).  
> The NIST private key generation for EC private keys mitigates this 
> bias by either (a) repeatedly generating random keys until you get one 
> in the range or (b) generating a key stream with extra (64) bits and 
> reducing that mod p of the curve.

If you are concerned about the distribution of private keys in these 
standards, then you may want to raise your concerns on the CFRG mailing 
list (cfrg at irtf.org). I don't have this concern, so I think we should 
implement the RFC as written.

>
>>
>> RFC 8032 private keys: These are definitely bit strings, and modeling 
>> them as integers doesn't make much sense. The only thing that is ever 
>> done with these private keys is that they are used as input to a hash 
>> function.
>
> Again - no.   The actual private key is what you get after stage 3 of 
> section 5.1.5.  E.g. generate a random string of 32 bytes. Hash it to 
> help with the bad random generators (*sheesh*), Interpret the hash 
> after pruning as a little endian integer. 

I'm not sure I understand what you are suggesting. For Ed25519, the 
initial 32-byte secret is hashed to produce 64 bytes. The first 32 bytes 
are pruned, interpreted as an integer, and used to produce the public 
key. The second 32 bytes are also used in the signing operation and 
contribute to a deterministic nonce. See RFC 8032, section 5.1.6, step 
1. Are you suggesting that we should represent all 64 bytes as an integer?



From mstjohns at comcast.net  Fri Aug 18 20:52:01 2017
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 18 Aug 2017 16:52:01 -0400
Subject: JCA design for RFC 7748
In-Reply-To: 
References: 
 <0431dc93-81f2-b91d-dcf7-6a26b2ca94fc@comcast.net>
 <40d52dac-7064-75a2-7c7c-6aa641d1a286@oracle.com>
 
 <3d49ee85-9455-a8e9-0566-2170a5083da8@oracle.com>
 
 
 <42d37ff6-7ef8-e1da-56eb-76a1c45d15db@oracle.com>
 
 <325766ca-8784-ed65-2abe-7bc93dff783b@oracle.com>
 <78062ed1-70bc-e732-47f9-a08989838848@oracle.com>
 
 
 <3baab9d2-1229-6208-6cc6-98f0628b5e6f@comcast.net>
 
 <5c51266e-9826-0bec-bb2c-e4dc467839b3@comcast.net>
 
Message-ID: 

On 8/18/2017 3:26 PM, Adam Petcher wrote:
> On 8/17/2017 1:44 PM, Michael StJohns wrote:
>> See inline.
>>
>> On 8/17/2017 11:19 AM, Adam Petcher wrote:
>>
>>>
>>> Specifically, these standards have properties related to byte arrays 
>>> like: "The Curve25519 function was carefully designed to allow all 
>>> 32-byte strings as Diffie-Hellman public keys."[1]
>>
>> This statement is actually a problem.  Valid keys are in the range of 
>> 1 to p-1 for the field (with some additional pruning).   32 byte 
>> strings (or 256 bit integers) do not map 1-1 into that space.  E.g. 
>> there are some actual canonical keys where multiple (at least 2) 32 
>> byte strings map to them.  (See the pruning and clamping 
>> algorithms).  The NIST private key generation for EC private keys 
>> mitigates this bias by either (a) repeatedly generating random keys 
>> until you get one in the range or (b) generating a key stream with 
>> extra (64) bits and reducing that mod p of the curve.
>
> If you are concerned about the distribution of private keys in these 
> standards, then you may want to raise your concerns on the CFRG 
> mailing list (cfrg at irtf.org). I don't have this concern, so I think we 
> should implement the RFC as written.
  Basically, the RFC describes the form of the private key.  It also 
gives you an implementation for how to generate one.  BUT - any method 
that gives you an equivalent key and that has the same or better 
security guarantees is equally valid.    WRT to the RFC, I missed this 
at the time it went through but noticed it after having to deal with 
generation of normal EC keys and a FIPS evaluation. The bias is small, 
but it exists.  The method of the RFC does not reduce the bias.  The 
NIST method does.   I know which one I would choose.

Regardless - this has no bearing on the fact that the output of the key 
generation process is an integer.

>
>>
>>>
>>> RFC 8032 private keys: These are definitely bit strings, and 
>>> modeling them as integers doesn't make much sense. The only thing 
>>> that is ever done with these private keys is that they are used as 
>>> input to a hash function.
>>
>> Again - no.   The actual private key is what you get after stage 3 of 
>> section 5.1.5.  E.g. generate a random string of 32 bytes. Hash it to 
>> help with the bad random generators (*sheesh*), Interpret the hash 
>> after pruning as a little endian integer. 
>
> I'm not sure I understand what you are suggesting. For Ed25519, the 
> initial 32-byte secret is hashed to produce 64 bytes. The first 32 
> bytes are pruned, interpreted as an integer, and used to produce the 
> public key. The second 32 bytes are also used in the signing operation 
> and contribute to a deterministic nonce. See RFC 8032, section 5.1.6, 
> step 1. Are you suggesting that we should represent all 64 bytes as an 
> integer?

Sorry - I did miss this.   Unfortunately, it screws up making this work 
cleanly.    There are two ways of doing this - I'd prefer (1) but could 
live with (2):

1) The private key is a BigInteger (and that's how it gets in and out of 
the ECPrivateKeySpec as 's') derived as up to step 3.  The nonce is the 
leftmost 32 bytes of the  SHA512 of the private key expressed as a 
little endian integer).   The key thing about the deterministic nonce is 
that it's the same for the key for its signature lifetime (which I'm 
really not sure is a good thing - but its what we have).  The way the 
nonce is derived in the RFC shows one way.  Hashing the private key 
shows another way.  I'd prefer this because you can use the same 
input/output from the 'spec method for the ed25519 key as the curve25519 
key.   (do you really want two different spec classes for edxx and 
curvexxx keys???)

2) The private key is the 32byte secret array of step 1 stored in the 
concrete class.  The input and output ECPrivateKeySpec defines a 
transform from that array to/from a BigInteger to that array.  The 
private key concrete class includes storage for both the internal 's' 
little endian integer value and the internal 'prefix' value. This isn't 
as clean because the scalar secret 's' isn't the same as the 
ECPrivateKeySpec.getS(), but allows for impedance matching between the 
existing classes and the strangeness of an ed25519 private key.  It 
would definitely divorce keys from the two curve uses by doing it this way.

*sigh* The private key is an integer and that's really what needs to be 
represented.

Mike






From sibabrata.sahoo at oracle.com  Tue Aug 22 13:36:16 2017
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Tue, 22 Aug 2017 06:36:16 -0700 (PDT)
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
Message-ID: <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>

Hi Max,

Please find the updated webrev addressing all comments in applicable test files.

Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/

Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Wednesday, August 02, 2017 3:53 PM
To: Sibabrata Sahoo
Cc: Valerie Peng; security-dev at openjdk.java.net
Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better

I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:

38: This ProcessTools is deprecated. Is it possible to use the one in root repo?

53: Why make it public?

98-99: What localized strings are you trying to avoid?

103-104: Why do these 2 variables contain the option name? I mean in the following expression 

    String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)

you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say

    String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)

Or just simply

    String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)


128: This loop looks a little strange. I'd rather just write the content twice.

136: This is the only usage of service parameter? If so, why not just move the line into constructor?

140: Why is there a "-" after "Case:"?

141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?

172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?

212-245: Please add an empty line before every new mBuilder assignment.

221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?

I'll read the other two tests and hopefully they have similar structures.

Thanks
Max

> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
> 
> Hi,
>  
> Please review the patch for the following,
>  
> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>  
> Change description:
> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>  
> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>  
> Thanks,
> Siba



From weijun.wang at oracle.com  Wed Aug 23 08:12:55 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 23 Aug 2017 16:12:55 +0800
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
 <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
Message-ID: <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>

Is there any reason why service being "true" and "false" are in 2 @run? This means setup() will run twice.

--Max

> On Aug 22, 2017, at 9:36 PM, Sibabrata Sahoo  wrote:
> 
> Hi Max,
> 
> Please find the updated webrev addressing all comments in applicable test files.
> 
> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/
> 
> Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
> This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang 
> Sent: Wednesday, August 02, 2017 3:53 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; security-dev at openjdk.java.net
> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
> 
> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:
> 
> 38: This ProcessTools is deprecated. Is it possible to use the one in root repo?
> 
> 53: Why make it public?
> 
> 98-99: What localized strings are you trying to avoid?
> 
> 103-104: Why do these 2 variables contain the option name? I mean in the following expression 
> 
>    String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)
> 
> you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say
> 
>    String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)
> 
> Or just simply
> 
>    String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)
> 
> 
> 128: This loop looks a little strange. I'd rather just write the content twice.
> 
> 136: This is the only usage of service parameter? If so, why not just move the line into constructor?
> 
> 140: Why is there a "-" after "Case:"?
> 
> 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?
> 
> 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?
> 
> 212-245: Please add an empty line before every new mBuilder assignment.
> 
> 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?
> 
> I'll read the other two tests and hopefully they have similar structures.
> 
> Thanks
> Max
> 
>> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
>> 
>> Hi,
>> 
>> Please review the patch for the following,
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>> 
>> Change description:
>> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>> 
>> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
>> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
>> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>> 
>> Thanks,
>> Siba
> 



From sibabrata.sahoo at oracle.com  Wed Aug 23 08:17:50 2017
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 23 Aug 2017 01:17:50 -0700 (PDT)
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
 <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
 <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>
Message-ID: <36295f83-1f5f-4958-a2fd-857cd32cb0d6@default>

Hi Max,

I have splitted the @run to convert each run to consume minimum time to avoid any timeout for rare cases.

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Wednesday, August 23, 2017 1:43 PM
To: Sibabrata Sahoo
Cc: Valerie Peng; security-dev at openjdk.java.net
Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better

Is there any reason why service being "true" and "false" are in 2 @run? This means setup() will run twice.

--Max

> On Aug 22, 2017, at 9:36 PM, Sibabrata Sahoo  wrote:
> 
> Hi Max,
> 
> Please find the updated webrev addressing all comments in applicable test files.
> 
> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/
> 
> Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
> This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang 
> Sent: Wednesday, August 02, 2017 3:53 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; security-dev at openjdk.java.net
> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
> 
> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:
> 
> 38: This ProcessTools is deprecated. Is it possible to use the one in root repo?
> 
> 53: Why make it public?
> 
> 98-99: What localized strings are you trying to avoid?
> 
> 103-104: Why do these 2 variables contain the option name? I mean in the following expression 
> 
>    String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)
> 
> you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say
> 
>    String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)
> 
> Or just simply
> 
>    String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)
> 
> 
> 128: This loop looks a little strange. I'd rather just write the content twice.
> 
> 136: This is the only usage of service parameter? If so, why not just move the line into constructor?
> 
> 140: Why is there a "-" after "Case:"?
> 
> 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?
> 
> 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?
> 
> 212-245: Please add an empty line before every new mBuilder assignment.
> 
> 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?
> 
> I'll read the other two tests and hopefully they have similar structures.
> 
> Thanks
> Max
> 
>> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
>> 
>> Hi,
>> 
>> Please review the patch for the following,
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>> 
>> Change description:
>> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>> 
>> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
>> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
>> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>> 
>> Thanks,
>> Siba
> 



From weijun.wang at oracle.com  Wed Aug 23 09:34:02 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 23 Aug 2017 17:34:02 +0800
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <36295f83-1f5f-4958-a2fd-857cd32cb0d6@default>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
 <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
 <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>
 <36295f83-1f5f-4958-a2fd-857cd32cb0d6@default>
Message-ID: <956F9F43-E11F-4DAF-814A-6DD410B0CF80@oracle.com>

Then maybe you can also make setup() a separate @run.

--Max

> On Aug 23, 2017, at 4:17 PM, Sibabrata Sahoo  wrote:
> 
> Hi Max,
> 
> I have splitted the @run to convert each run to consume minimum time to avoid any timeout for rare cases.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang 
> Sent: Wednesday, August 23, 2017 1:43 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; security-dev at openjdk.java.net
> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
> 
> Is there any reason why service being "true" and "false" are in 2 @run? This means setup() will run twice.
> 
> --Max
> 
>> On Aug 22, 2017, at 9:36 PM, Sibabrata Sahoo  wrote:
>> 
>> Hi Max,
>> 
>> Please find the updated webrev addressing all comments in applicable test files.
>> 
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/
>> 
>> Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
>> This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.
>> 
>> Thanks,
>> Siba
>> 
>> -----Original Message-----
>> From: Weijun Wang 
>> Sent: Wednesday, August 02, 2017 3:53 PM
>> To: Sibabrata Sahoo
>> Cc: Valerie Peng; security-dev at openjdk.java.net
>> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
>> 
>> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:
>> 
>> 38: This ProcessTools is deprecated. Is it possible to use the one in root repo?
>> 
>> 53: Why make it public?
>> 
>> 98-99: What localized strings are you trying to avoid?
>> 
>> 103-104: Why do these 2 variables contain the option name? I mean in the following expression 
>> 
>>   String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)
>> 
>> you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say
>> 
>>   String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)
>> 
>> Or just simply
>> 
>>   String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)
>> 
>> 
>> 128: This loop looks a little strange. I'd rather just write the content twice.
>> 
>> 136: This is the only usage of service parameter? If so, why not just move the line into constructor?
>> 
>> 140: Why is there a "-" after "Case:"?
>> 
>> 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?
>> 
>> 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?
>> 
>> 212-245: Please add an empty line before every new mBuilder assignment.
>> 
>> 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?
>> 
>> I'll read the other two tests and hopefully they have similar structures.
>> 
>> Thanks
>> Max
>> 
>>> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the patch for the following,
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
>>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>>> 
>>> Change description:
>>> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>>> 
>>> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
>>> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
>>> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>>> 
>>> Thanks,
>>> Siba
>> 
> 



From sibabrata.sahoo at oracle.com  Wed Aug 23 12:30:39 2017
From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo)
Date: Wed, 23 Aug 2017 05:30:39 -0700 (PDT)
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <956F9F43-E11F-4DAF-814A-6DD410B0CF80@oracle.com>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
 <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
 <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>
 <36295f83-1f5f-4958-a2fd-857cd32cb0d6@default>
 <956F9F43-E11F-4DAF-814A-6DD410B0CF80@oracle.com>
Message-ID: <15472245-9bc9-44ba-9f0b-478b5e0a1f60@default>

Hi Max,

Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.02/

The setup will be called only once irrespective number of @run available inside the Test file.

Thanks,
Siba

-----Original Message-----
From: Weijun Wang 
Sent: Wednesday, August 23, 2017 3:04 PM
To: Sibabrata Sahoo
Cc: Valerie Peng; security-dev at openjdk.java.net
Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better

Then maybe you can also make setup() a separate @run.

--Max

> On Aug 23, 2017, at 4:17 PM, Sibabrata Sahoo  wrote:
> 
> Hi Max,
> 
> I have splitted the @run to convert each run to consume minimum time to avoid any timeout for rare cases.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang 
> Sent: Wednesday, August 23, 2017 1:43 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; security-dev at openjdk.java.net
> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
> 
> Is there any reason why service being "true" and "false" are in 2 @run? This means setup() will run twice.
> 
> --Max
> 
>> On Aug 22, 2017, at 9:36 PM, Sibabrata Sahoo  wrote:
>> 
>> Hi Max,
>> 
>> Please find the updated webrev addressing all comments in applicable test files.
>> 
>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/
>> 
>> Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
>> This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.
>> 
>> Thanks,
>> Siba
>> 
>> -----Original Message-----
>> From: Weijun Wang 
>> Sent: Wednesday, August 02, 2017 3:53 PM
>> To: Sibabrata Sahoo
>> Cc: Valerie Peng; security-dev at openjdk.java.net
>> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
>> 
>> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:
>> 
>> 38: This ProcessTools is deprecated. Is it possible to use the one in root repo?
>> 
>> 53: Why make it public?
>> 
>> 98-99: What localized strings are you trying to avoid?
>> 
>> 103-104: Why do these 2 variables contain the option name? I mean in the following expression 
>> 
>>   String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)
>> 
>> you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say
>> 
>>   String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)
>> 
>> Or just simply
>> 
>>   String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)
>> 
>> 
>> 128: This loop looks a little strange. I'd rather just write the content twice.
>> 
>> 136: This is the only usage of service parameter? If so, why not just move the line into constructor?
>> 
>> 140: Why is there a "-" after "Case:"?
>> 
>> 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?
>> 
>> 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?
>> 
>> 212-245: Please add an empty line before every new mBuilder assignment.
>> 
>> 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?
>> 
>> I'll read the other two tests and hopefully they have similar structures.
>> 
>> Thanks
>> Max
>> 
>>> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the patch for the following,
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
>>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>>> 
>>> Change description:
>>> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>>> 
>>> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
>>> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
>>> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>>> 
>>> Thanks,
>>> Siba
>> 
> 



From weijun.wang at oracle.com  Wed Aug 23 13:43:03 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 23 Aug 2017 21:43:03 +0800
Subject: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java
 should clean up better
In-Reply-To: <15472245-9bc9-44ba-9f0b-478b5e0a1f60@default>
References: <89402164-f4b1-4e36-b894-2ad997efd409@default>
 <6FE7586B-F891-41D7-892D-C5D07C5985F4@oracle.com>
 <134b293c-ea0a-43fe-a573-9079bb6c9c3e@default>
 <2F7EDBA6-73AC-4CE4-B788-25C484B1ED40@oracle.com>
 <36295f83-1f5f-4958-a2fd-857cd32cb0d6@default>
 <956F9F43-E11F-4DAF-814A-6DD410B0CF80@oracle.com>
 <15472245-9bc9-44ba-9f0b-478b5e0a1f60@default>
Message-ID: <2B3A9D50-403F-450C-8516-F58592CC8F88@oracle.com>

Hi Siba

Change looks fine. I have no other comments.

Thanks
Max

> On Aug 23, 2017, at 8:30 PM, Sibabrata Sahoo  wrote:
> 
> Hi Max,
> 
> Please find the updated webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.02/
> 
> The setup will be called only once irrespective number of @run available inside the Test file.
> 
> Thanks,
> Siba
> 
> -----Original Message-----
> From: Weijun Wang 
> Sent: Wednesday, August 23, 2017 3:04 PM
> To: Sibabrata Sahoo
> Cc: Valerie Peng; security-dev at openjdk.java.net
> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
> 
> Then maybe you can also make setup() a separate @run.
> 
> --Max
> 
>> On Aug 23, 2017, at 4:17 PM, Sibabrata Sahoo  wrote:
>> 
>> Hi Max,
>> 
>> I have splitted the @run to convert each run to consume minimum time to avoid any timeout for rare cases.
>> 
>> Thanks,
>> Siba
>> 
>> -----Original Message-----
>> From: Weijun Wang 
>> Sent: Wednesday, August 23, 2017 1:43 PM
>> To: Sibabrata Sahoo
>> Cc: Valerie Peng; security-dev at openjdk.java.net
>> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
>> 
>> Is there any reason why service being "true" and "false" are in 2 @run? This means setup() will run twice.
>> 
>> --Max
>> 
>>> On Aug 22, 2017, at 9:36 PM, Sibabrata Sahoo  wrote:
>>> 
>>> Hi Max,
>>> 
>>> Please find the updated webrev addressing all comments in applicable test files.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.01/
>>> 
>>> Regarding "172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?"
>>> This is just additional Test case for regular jars in modulepath and modular jars in classpath, which verifies how the type get resolved.
>>> 
>>> Thanks,
>>> Siba
>>> 
>>> -----Original Message-----
>>> From: Weijun Wang 
>>> Sent: Wednesday, August 02, 2017 3:53 PM
>>> To: Sibabrata Sahoo
>>> Cc: Valerie Peng; security-dev at openjdk.java.net
>>> Subject: Re: [10] RFR: JDK-8183310: java/security/modules/ModularTest.java should clean up better
>>> 
>>> I am reading JaasModularClientTest.java now. It?s much simpler than the original one. Some comments:
>>> 
>>> 38: This ProcessTools is deprecated. Is it possible to use the one in root repo?
>>> 
>>> 53: Why make it public?
>>> 
>>> 98-99: What localized strings are you trying to avoid?
>>> 
>>> 103-104: Why do these 2 variables contain the option name? I mean in the following expression 
>>> 
>>>  String.format("-cp %s --module-path %s %s %s", unnC, modL, addNMArg, C_TYPE)
>>> 
>>> you have put some option names (-cp, --module-path) in the format string but another (--add-modules) in an argument (addNMArg). It will be more clear to put option names in format string and option values in arguments, say
>>> 
>>>  String.format("-cp %s --module-path %s --add-modules %s %s", unnC, modL, "ml", C_TYPE)
>>> 
>>> Or just simply
>>> 
>>>  String.format("-cp %s --module-path %s --add-modules ml %s", unnC, modL, C_TYPE)
>>> 
>>> 
>>> 128: This loop looks a little strange. I'd rather just write the content twice.
>>> 
>>> 136: This is the only usage of service parameter? If so, why not just move the line into constructor?
>>> 
>>> 140: Why is there a "-" after "Case:"?
>>> 
>>> 141: In every case you are expecting EXP_RES. Why bother include it as a parameter? In fact, what else do you expect? If EXP_RES is not seen, shouldn't the client just fails with an exception? If so, why check contains() on line 197 and not look at the exit value?
>>> 
>>> 172-180: This sounds like you can use legacy jars as module jars and vice versa. Is this something new?
>>> 
>>> 212-245: Please add an empty line before every new mBuilder assignment.
>>> 
>>> 221: So you need jdk.security.auth for UnixPrincipal? It looks like this class is also available on Windows but I feel it a little strange. Maybe use UserPrincipal or create your new one?
>>> 
>>> I'll read the other two tests and hopefully they have similar structures.
>>> 
>>> Thanks
>>> Max
>>> 
>>>> On Jul 15, 2017, at 6:30 PM, Sibabrata Sahoo  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Please review the patch for the following,
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8183310
>>>> Webrev: http://cr.openjdk.java.net/~ssahoo/8183310/webrev.00/
>>>> 
>>>> Change description:
>>>> The code has been changed significantly for cleaning up existing code and to simplify it. During clean up, I have also removed the unwanted file ?java/security/modules/ModularTest.java?.
>>>> 
>>>> SecurityProviderModularTest.java - Verify security provider in all possible modular combination. There are 2 related files ?TestClient.java? and ?TestProvider.java? renamed and changed a little during clean up.
>>>> JaasModularClientTest.java ? Verify JAAS login module in all possible modular combination.
>>>> JaasModularDefaultHandlerTest.java - Verify JAAS default handler in all possible modular combination. As part of clean I have also removed ?TEST.properties? file.
>>>> 
>>>> Thanks,
>>>> Siba
>>> 
>> 
> 



From ivan.gerasimov at oracle.com  Wed Aug 23 20:54:39 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 23 Aug 2017 13:54:39 -0700
Subject: [10] RFR 8186654 : Poor quality of
 sun.security.util.Cache.EqualByteArray.hashCode()
Message-ID: 

Hello!

An auxiliary class EqualByteArray implements hashCode() in a way that 
small changes to the content do not change the hash value.

It is proposed to reuse Arrays.hashCode(byte[]) for the hash code 
calculations.

Also, the private int hash is made non-volatile, as it removes accessing 
to a volatile variable in the relatively frequently executed code for 
the price of relatively less likely chance of a double hash code 
calculation.  (For reference, java.lang.String uses the same approach.)

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8186654
WEBREV: http://cr.openjdk.java.net/~igerasim/8186654/00/webrev/

-- 
With kind regards,
Ivan Gerasimov



From weijun.wang at oracle.com  Thu Aug 24 09:28:14 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 Aug 2017 17:28:14 +0800
Subject: RFR 8186576: KerberosTicket does not properly handle renewable
 tickets at the end of their lifetime
Message-ID: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>

Please review the fix at

   http://cr.openjdk.java.net/~weijun/8186576/webrev.00

This is a MIT/krb5 bug [1], but we will accept it anyway. Also, renew such a ticket is now a no-op because the lifetime will not be extended anyway.

New test included.

Thanks
Max

[1] http://mailman.mit.edu/pipermail/krbdev/2017-August/012809.html

From vincent.x.ryan at oracle.com  Thu Aug 24 14:27:40 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 24 Aug 2017 15:27:40 +0100
Subject: [10] RFR 8173181: Empty string alias in KeyStore throws
 StringIndexOutOfBoundsException for getEntry()
Message-ID: 

Please review this fix to correct support for an empty string alias in PKCS12 keystores.
Thanks.

Bug: https://bugs.openjdk.java.net/browse/JDK-8173181 
Webrev: http://cr.openjdk.java.net/~vinnie/8173181/webrev.00/ 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Thu Aug 24 14:50:39 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 Aug 2017 22:50:39 +0800
Subject: [10] RFR 8173181: Empty string alias in KeyStore throws
 StringIndexOutOfBoundsException for getEntry()
In-Reply-To: 
References: 
Message-ID: <877457CB-E627-4D62-BBC0-B1323430CC9E@oracle.com>

1. Maybe just check length > 1?

2. The test's @summary seems unrelated.

--Max

> On Aug 24, 2017, at 10:27 PM, Vincent Ryan  wrote:
> 
> Please review this fix to correct support for an empty string alias in PKCS12 keystores.
> Thanks.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173181
> Webrev: http://cr.openjdk.java.net/~vinnie/8173181/webrev.00/
> 
> 



From vincent.x.ryan at oracle.com  Thu Aug 24 14:53:30 2017
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Thu, 24 Aug 2017 15:53:30 +0100
Subject: [10] RFR 8173181: Empty string alias in KeyStore throws
 StringIndexOutOfBoundsException for getEntry()
In-Reply-To: <877457CB-E627-4D62-BBC0-B1323430CC9E@oracle.com>
References: 
 <877457CB-E627-4D62-BBC0-B1323430CC9E@oracle.com>
Message-ID: <51C5843D-93E0-43A8-BF65-A52FDD3F28E7@oracle.com>


> On 24 Aug 2017, at 15:50, Weijun Wang  wrote:
> 
> 1. Maybe just check length > 1?

Yes. I?ll make the change.

> 
> 2. The test's @summary seems unrelated.

An empty alias is supported in JKS.


> 
> --Max
> 
>> On Aug 24, 2017, at 10:27 PM, Vincent Ryan  wrote:
>> 
>> Please review this fix to correct support for an empty string alias in PKCS12 keystores.
>> Thanks.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173181
>> Webrev: http://cr.openjdk.java.net/~vinnie/8173181/webrev.00/
>> 
>> 
> 



From weijun.wang at oracle.com  Thu Aug 24 15:02:21 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 Aug 2017 23:02:21 +0800
Subject: [10] RFR 8173181: Empty string alias in KeyStore throws
 StringIndexOutOfBoundsException for getEntry()
In-Reply-To: <51C5843D-93E0-43A8-BF65-A52FDD3F28E7@oracle.com>
References: 
 <877457CB-E627-4D62-BBC0-B1323430CC9E@oracle.com>
 <51C5843D-93E0-43A8-BF65-A52FDD3F28E7@oracle.com>
Message-ID: 


> On Aug 24, 2017, at 10:53 PM, Vincent Ryan  wrote:
> 
> 
>> On 24 Aug 2017, at 15:50, Weijun Wang  wrote:
>> 
>> 1. Maybe just check length > 1?
> 
> Yes. I?ll make the change.
> 
>> 
>> 2. The test's @summary seems unrelated.
> 
> An empty alias is supported in JKS.

Got it.

--Max

> 
> 
>> 
>> --Max
>> 
>>> On Aug 24, 2017, at 10:27 PM, Vincent Ryan  wrote:
>>> 
>>> Please review this fix to correct support for an empty string alias in PKCS12 keystores.
>>> Thanks.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173181
>>> Webrev: http://cr.openjdk.java.net/~vinnie/8173181/webrev.00/
>>> 
>>> 
>> 
> 



From xuelei.fan at oracle.com  Thu Aug 24 22:27:48 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 24 Aug 2017 15:27:48 -0700
Subject: RFR 8186576: KerberosTicket does not properly handle renewable
 tickets at the end of their lifetime
In-Reply-To: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>
References: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>
Message-ID: <67ddc8c8-9e32-60c0-6ed4-1ebba49ff6f6@oracle.com>

javax/security/auth/kerberos/KerberosTicket.java
------------------------------------------------
if (getRenewTill() == null) {
     // The current ticket's lifetime is greater than renew_until.
     // No need to refresh.
     return;
}

The comment is confusing to me.  Per the getRenewTill() specification, 
does "getRenewTill() == null" means the ticket is non-renewable (destroyed)?

Xuelei

On 8/24/2017 2:28 AM, Weijun Wang wrote:
> Please review the fix at
> 
>     http://cr.openjdk.java.net/~weijun/8186576/webrev.00
> 
> This is a MIT/krb5 bug [1], but we will accept it anyway. Also, renew such a ticket is now a no-op because the lifetime will not be extended anyway.
> 
> New test included.
> 
> Thanks
> Max
> 
> [1] http://mailman.mit.edu/pipermail/krbdev/2017-August/012809.html
> 


From weijun.wang at oracle.com  Thu Aug 24 23:44:20 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 25 Aug 2017 07:44:20 +0800
Subject: RFR 8186576: KerberosTicket does not properly handle renewable
 tickets at the end of their lifetime
In-Reply-To: <67ddc8c8-9e32-60c0-6ed4-1ebba49ff6f6@oracle.com>
References: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>
 <67ddc8c8-9e32-60c0-6ed4-1ebba49ff6f6@oracle.com>
Message-ID: <223CB58D-B4EE-40B1-9052-60AABB02A68E@oracle.com>


> On Aug 25, 2017, at 6:27 AM, Xuelei Fan  wrote:
> 
> javax/security/auth/kerberos/KerberosTicket.java
> ------------------------------------------------
> if (getRenewTill() == null) {
>    // The current ticket's lifetime is greater than renew_until.
>    // No need to refresh.
>    return;
> }
> 
> The comment is confusing to me.  Per the getRenewTill() specification, does "getRenewTill() == null" means the ticket is non-renewable (destroyed)?

This is a bug of MIT krb5's kdc implementation, which wrongly issues a renewable ticket without the renew_till field. We will have to deal with it.

getRenewTill()'s spec says null is return if the ticket is non-renewable (destroyed), but has not said it does not return null if it's renewable. Of course, it's an error case but I mean the spec has not enforced it.

I can enhance the comment to something like "Renewable ticket without renew_until. This is illegal and let's ignore it".

--Max

> 
> Xuelei
> 
> On 8/24/2017 2:28 AM, Weijun Wang wrote:
>> Please review the fix at
>>    http://cr.openjdk.java.net/~weijun/8186576/webrev.00
>> This is a MIT/krb5 bug [1], but we will accept it anyway. Also, renew such a ticket is now a no-op because the lifetime will not be extended anyway.
>> New test included.
>> Thanks
>> Max
>> [1] http://mailman.mit.edu/pipermail/krbdev/2017-August/012809.html



From xuelei.fan at oracle.com  Thu Aug 24 23:46:53 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 24 Aug 2017 16:46:53 -0700
Subject: RFR 8186576: KerberosTicket does not properly handle renewable
 tickets at the end of their lifetime
In-Reply-To: <223CB58D-B4EE-40B1-9052-60AABB02A68E@oracle.com>
References: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>
 <67ddc8c8-9e32-60c0-6ed4-1ebba49ff6f6@oracle.com>
 <223CB58D-B4EE-40B1-9052-60AABB02A68E@oracle.com>
Message-ID: 

On 8/24/2017 4:44 PM, Weijun Wang wrote:
> 
>> On Aug 25, 2017, at 6:27 AM, Xuelei Fan  wrote:
>>
>> javax/security/auth/kerberos/KerberosTicket.java
>> ------------------------------------------------
>> if (getRenewTill() == null) {
>>     // The current ticket's lifetime is greater than renew_until.
>>     // No need to refresh.
>>     return;
>> }
>>
>> The comment is confusing to me.  Per the getRenewTill() specification, does "getRenewTill() == null" means the ticket is non-renewable (destroyed)?
> 
> This is a bug of MIT krb5's kdc implementation, which wrongly issues a renewable ticket without the renew_till field. We will have to deal with it.
> 
> getRenewTill()'s spec says null is return if the ticket is non-renewable (destroyed), but has not said it does not return null if it's renewable. Of course, it's an error case but I mean the spec has not enforced it.
> 
> I can enhance the comment to something like "Renewable ticket without renew_until. This is illegal and let's ignore it".
> 
The new comment looks more reasonable to me.  Please note that you have 
two update calling getRenewTill().  Otherwise, looks fine.

Xuelei

> --Max
> 
>>
>> Xuelei
>>
>> On 8/24/2017 2:28 AM, Weijun Wang wrote:
>>> Please review the fix at
>>>     http://cr.openjdk.java.net/~weijun/8186576/webrev.00
>>> This is a MIT/krb5 bug [1], but we will accept it anyway. Also, renew such a ticket is now a no-op because the lifetime will not be extended anyway.
>>> New test included.
>>> Thanks
>>> Max
>>> [1] http://mailman.mit.edu/pipermail/krbdev/2017-August/012809.html
> 


From weijun.wang at oracle.com  Thu Aug 24 23:48:24 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 25 Aug 2017 07:48:24 +0800
Subject: RFR 8186576: KerberosTicket does not properly handle renewable
 tickets at the end of their lifetime
In-Reply-To: 
References: <178EE843-4A15-4D99-B8F9-D54262B18E98@oracle.com>
 <67ddc8c8-9e32-60c0-6ed4-1ebba49ff6f6@oracle.com>
 <223CB58D-B4EE-40B1-9052-60AABB02A68E@oracle.com>
 
Message-ID: <968F1293-7352-4524-BD37-F8939B855215@oracle.com>


> On Aug 25, 2017, at 7:46 AM, Xuelei Fan  wrote:
> 
> On 8/24/2017 4:44 PM, Weijun Wang wrote:
>>> On Aug 25, 2017, at 6:27 AM, Xuelei Fan  wrote:
>>> 
>>> javax/security/auth/kerberos/KerberosTicket.java
>>> ------------------------------------------------
>>> if (getRenewTill() == null) {
>>>    // The current ticket's lifetime is greater than renew_until.
>>>    // No need to refresh.
>>>    return;
>>> }
>>> 
>>> The comment is confusing to me.  Per the getRenewTill() specification, does "getRenewTill() == null" means the ticket is non-renewable (destroyed)?
>> This is a bug of MIT krb5's kdc implementation, which wrongly issues a renewable ticket without the renew_till field. We will have to deal with it.
>> getRenewTill()'s spec says null is return if the ticket is non-renewable (destroyed), but has not said it does not return null if it's renewable. Of course, it's an error case but I mean the spec has not enforced it.
>> I can enhance the comment to something like "Renewable ticket without renew_until. This is illegal and let's ignore it".
> The new comment looks more reasonable to me.  Please note that you have two update calling getRenewTill().  Otherwise, looks fine.
> 

Thanks. I'll update both.

--Max

> Xuelei
> 
>> --Max
>>> 
>>> Xuelei
>>> 
>>> On 8/24/2017 2:28 AM, Weijun Wang wrote:
>>>> Please review the fix at
>>>>    http://cr.openjdk.java.net/~weijun/8186576/webrev.00
>>>> This is a MIT/krb5 bug [1], but we will accept it anyway. Also, renew such a ticket is now a no-op because the lifetime will not be extended anyway.
>>>> New test included.
>>>> Thanks
>>>> Max
>>>> [1] http://mailman.mit.edu/pipermail/krbdev/2017-August/012809.html



From sean.coffey at oracle.com  Fri Aug 25 13:28:54 2017
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 25 Aug 2017 14:28:54 +0100
Subject: RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java
 test crashed due to unhandled case of cipher length value as 0
In-Reply-To: <3b6494f6-9bd5-bc4a-651e-1a4b6fc28ba9@oracle.com>
References: <3b6494f6-9bd5-bc4a-651e-1a4b6fc28ba9@oracle.com>
Message-ID: <0fd87c12-4a81-60d0-2efd-7cbfb79a1f87@oracle.com>

Tony pointed out off-list that the change to encodeISOArray() might not 
work.

"I'm not certain the change to encodeISOArray() is not going to work. In 
8, that method can be replaced by an intrinsic and miss your additional 
check.  Unlike in 9 where implEncodeISOArray() is intrinsfied.  It maybe 
best to backport the method name change done in 9 too."

I replied :

"That's a fair point Tony. Without risking too much change for 
jdk8u-dev, would it be ok to ensure that the len value is not <= 0 
before we call the method itself. There are only two call sites. 
Refactoring of various methods too place in JDK 9 and introduced 
implEncodeISOArray in that class. [1]. I think the change I'm proposing 
is just as useful and safer :

new webrev : 
http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u.02/webrev/"

The security-dev list got dropped. Re-adding here.

Regards,
Sean.

On 16/08/17 13:14, Se?n Coffey wrote:
>
> Looking to backport this fix to jdk8u-dev. The bug report is not 
> public but the JDK 9 review thread captures the details. The fix is 
> similar. Some extra intrinsics work in jdk9 wasn't applicable for the 
> jdk8u-dev port.
>
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044560.html 
>
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u/webrev/
> -- 
> Regards,
> Sean.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From anthony.scarpino at oracle.com  Fri Aug 25 14:34:01 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Fri, 25 Aug 2017 07:34:01 -0700
Subject: RFR : 8159035: com/sun/crypto/provider/Cipher/CTS/CTSMode.java
 test crashed due to unhandled case of cipher length value as 0
In-Reply-To: <0fd87c12-4a81-60d0-2efd-7cbfb79a1f87@oracle.com>
References: <3b6494f6-9bd5-bc4a-651e-1a4b6fc28ba9@oracle.com>
 <0fd87c12-4a81-60d0-2efd-7cbfb79a1f87@oracle.com>
Message-ID: 

Looks good

Tony

> On Aug 25, 2017, at 6:28 AM, Se?n Coffey  wrote:
> 
> Tony pointed out off-list that the change to encodeISOArray() might not work.
> 
> "I'm not certain the change to encodeISOArray() is not going to work. In 8, that method can be replaced by an intrinsic and miss your additional check.  Unlike in 9 where implEncodeISOArray() is intrinsfied.  It maybe best to backport the method name change done in 9 too."
> 
> I replied :
> 
> "That's a fair point Tony. Without risking too much change for jdk8u-dev, would it be ok to ensure that the len value is not <= 0 before we call the method itself. There are only two call sites. Refactoring of various methods too place in JDK 9 and introduced implEncodeISOArray in that class. [1]. I think the change I'm proposing is just as useful and safer : 
> 
> new webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u.02/webrev/"
> 
> The security-dev list got dropped. Re-adding here.
> Regards,
> Sean.
>> On 16/08/17 13:14, Se?n Coffey wrote:
>> Looking to backport this fix to jdk8u-dev. The bug report is not public but the JDK 9 review thread captures the details. The fix is similar. Some extra intrinsics work in jdk9 wasn't applicable for the jdk8u-dev port. 
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044560.html 
>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8159035.8u/webrev/ 
>> -- 
>> Regards,
>> Sean.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From xuelei.fan at oracle.com  Sat Aug 26 00:53:25 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 25 Aug 2017 17:53:25 -0700
Subject: Code Review Request, JDK-8179654 New JDK 9 typos in SSLEngineResult
Message-ID: 

Hi,

Please review this spec typo update in SSLEngineResult:

    http://cr.openjdk.java.net/~xuelei/8179654/webrev.00/

Thanks,
Xuelei


From anthony.scarpino at oracle.com  Sat Aug 26 01:24:06 2017
From: anthony.scarpino at oracle.com (Oracle)
Date: Fri, 25 Aug 2017 18:24:06 -0700
Subject: Code Review Request,
 JDK-8179654 New JDK 9 typos in SSLEngineResult
In-Reply-To: 
References: 
Message-ID: 

Looks fine

Tony

> On Aug 25, 2017, at 5:53 PM, Xuelei Fan  wrote:
> 
> Hi,
> 
> Please review this spec typo update in SSLEngineResult:
> 
>   http://cr.openjdk.java.net/~xuelei/8179654/webrev.00/
> 
> Thanks,
> Xuelei


From bradford.wetmore at oracle.com  Sat Aug 26 05:11:55 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 25 Aug 2017 22:11:55 -0700
Subject: Code Review Request, JDK-8179654 New JDK 9 typos in
 SSLEngineResult
In-Reply-To: 
References: 
 
Message-ID: <70bce8e7-3f69-7972-5925-161137f24367@oracle.com>

+1

Brad


On 8/25/2017 6:24 PM, Oracle wrote:
> Looks fine
> 
> Tony
> 
>> On Aug 25, 2017, at 5:53 PM, Xuelei Fan  wrote:
>>
>> Hi,
>>
>> Please review this spec typo update in SSLEngineResult:
>>
>>    http://cr.openjdk.java.net/~xuelei/8179654/webrev.00/
>>
>> Thanks,
>> Xuelei


From xuelei.fan at oracle.com  Sat Aug 26 21:25:50 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 26 Aug 2017 14:25:50 -0700
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: 
References: 
 
Message-ID: 

Hi Marin,

Sorry for the delay.

There are a few protocols that can benefits from exporting SSL/TLS 
handshake materials, including RFC 5929, RFC 5056, token binding and TLS 
1.3 itself.  Can we define a general API so as to exposing the handshake 
materials, so as to mitigate the inflating of JSSE APIs?  I may suggest 
make further evaluation before move on to following design and code.

 > 
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
I have two concerns about the design:

1. Channel binding may be not always required.
SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);

The SunJSSE provider happens to cache the finished messages in its 
implementation so you can use it for tls-unique, but it may not be true 
for other provider or other channel bindings.  Need to define a more 
reliable approach to get the handshake materials.

If the channel binding is not required, it may be not necessary to 
expose the handshake materials.  Need to define a solution to indicate 
the need of the exporting.

2. No way to know the update of the underlying handshake materials.
If renegotiation can takes place, need to define a interface to indicate 
that so that application can response accordingly.  See section 3 and 7 
of RFC 5929.

Thanks,
Xuelei

On 7/31/2017 8:53 AM, Martin Balao wrote:
> Hi,
> 
> Here it is an update for the proposed TLS Channel Bindings support in 
> OpenJDK:
> 
>  ?* 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/ 
> (browse online)
>  ?* 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip 
> (download)
> 
> Changes since v01:
> 
>  ?* getTlsChannelBinding API changed to return null by default (if not 
> implemented), instead of throwing an UnsupportedOperationException.
> 
>  ?* "tls-server-end-point" TLS channel binding now supported.
> 
> Kind regards,
> Martin.-
> 
> On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao  > wrote:
> 
>     Hi,
> 
>     Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
>     Bindings: e.g. public API to obtain TLS finished message) [1]:
> 
>      ?*
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
>     
>      ?*
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip
>     
> 
>     Notes:
>      ?* Implementation based on Channel Bindings for TLS (RFC 5929) [2]
> 
>      ?* Only "tls-unique" currently supported
> 
>     Look forward to your comments.
> 
>     Kind regards,
>     Martin.-
> 
>     --
>     [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>     
>     [2] - https://tools.ietf.org/html/rfc5929
>     
> 
> 


From ecki at zusammenkunft.net  Sat Aug 26 21:56:24 2017
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 26 Aug 2017 21:56:24 +0000
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: 
References: 
 ,
 
Message-ID: 

How about only passing it to an extended handshake listener. The material does not have to be cached (the app can do it if needed) and renegotiation works the same way. This can also be helpful for things like logging the master secret (for wireshark decryption). It can even handle auditing of session resumptions

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: security-dev  on behalf of Xuelei Fan 
Sent: Saturday, August 26, 2017 11:25:50 PM
To: Martin Balao; security-dev at openjdk.java.net
Subject: Re: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel Bindings)

Hi Marin,

Sorry for the delay.

There are a few protocols that can benefits from exporting SSL/TLS
handshake materials, including RFC 5929, RFC 5056, token binding and TLS
1.3 itself.  Can we define a general API so as to exposing the handshake
materials, so as to mitigate the inflating of JSSE APIs?  I may suggest
make further evaluation before move on to following design and code.

 >
http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
I have two concerns about the design:

1. Channel binding may be not always required.
SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);

The SunJSSE provider happens to cache the finished messages in its
implementation so you can use it for tls-unique, but it may not be true
for other provider or other channel bindings.  Need to define a more
reliable approach to get the handshake materials.

If the channel binding is not required, it may be not necessary to
expose the handshake materials.  Need to define a solution to indicate
the need of the exporting.

2. No way to know the update of the underlying handshake materials.
If renegotiation can takes place, need to define a interface to indicate
that so that application can response accordingly.  See section 3 and 7
of RFC 5929.

Thanks,
Xuelei

On 7/31/2017 8:53 AM, Martin Balao wrote:
> Hi,
>
> Here it is an update for the proposed TLS Channel Bindings support in
> OpenJDK:
>
>   *
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
> (browse online)
>   *
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip
> (download)
>
> Changes since v01:
>
>   * getTlsChannelBinding API changed to return null by default (if not
> implemented), instead of throwing an UnsupportedOperationException.
>
>   * "tls-server-end-point" TLS channel binding now supported.
>
> Kind regards,
> Martin.-
>
> On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao  > wrote:
>
>     Hi,
>
>     Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
>     Bindings: e.g. public API to obtain TLS finished message) [1]:
>
>       *
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
>     
>       *
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip
>     
>
>     Notes:
>       * Implementation based on Channel Bindings for TLS (RFC 5929) [2]
>
>       * Only "tls-unique" currently supported
>
>     Look forward to your comments.
>
>     Kind regards,
>     Martin.-
>
>     --
>     [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>     
>     [2] - https://tools.ietf.org/html/rfc5929
>     
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From xuelei.fan at oracle.com  Sat Aug 26 22:49:01 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Sat, 26 Aug 2017 15:49:01 -0700
Subject: Code Review Request: JDK-8148421 (Extended Master Secret TLS
 extension)
In-Reply-To: 
References: 
Message-ID: <809c45dd-463d-479b-8194-b78440a22b3a@oracle.com>

Hi Martin,

Sorry for the delay.

I like this no-API-change design.

There may be some interoperbility/compatibility issues because of 
implementation issues of the Extended Master Secret Extension.  Maybe, 
we want an approach to turn off the extension if there is a concern.  It 
could be a system property (for example, 
jsse.useExtendedMasterSecret="false").

Would you mind file a Compatibility & Specification Review (CSR) request 
for this feature proposal?  For more information, see the CSR wiki at 
OpenJDK:
    https://wiki.openjdk.java.net/display/csr/Main

I may have some comments about the implementation if the CSR request get 
approved.

Thanks & Regards,
Xuelei

On 8/4/2017 6:18 AM, Martin Balao wrote:
> Hi,
> 
> This is my proposal for JDK-8148421 (Support Transport Layer Security 
> (TLS) Session Hash and Extended Master Secret Extension) [1]:
> 
>  ?* 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.01/ 
> (browse 
> online)
>  ?* 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-8148421/webrev.01/8148421.webrev.01.zip 
> (download)
> 
> Notes:
> 
>  ?* There is no PKCS#11 support for Extended Master Secret key 
> derivation at this moment. NSS supports it through a vendor-specific 
> type definition (CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE and 
> CKM_NSS_TLS_EXTENDED_MASTER_KEY_DERIVE_DH in pkcs11n.h file). Thus, 
> P11TlsMasterSecretGenerator uses the legacy Master Key Derivation method 
> only.
> 
> Thanks in advanced,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8148421


From peterhansson_se at yahoo.com  Sun Aug 27 13:59:50 2017
From: peterhansson_se at yahoo.com (Peter Hansson)
Date: Sun, 27 Aug 2017 13:59:50 +0000 (UTC)
Subject: Fix for dealock issue in JDK's SPNEGO resulted in another deadlock
References: <367791380.1695643.1503842390438.ref@mail.yahoo.com>
Message-ID: <367791380.1695643.1503842390438@mail.yahoo.com>




Hi

I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform. The deadlock is a result of the fix for JDK-8032832 which introduced a lock on the classloader. Unfortunately this fix just introduces another bug (reported as JDK-8068184). I'm now soliciting advice from this list.

The bug essentially causes NetBeans IDE (or applications build on NetBeans Platform) to freeze on startup if the site is using a proxy which uses 'Negotiate' auth scheme.


The reason for the deadlock is straightforward:  

When doing SPNEGO exchange there's now (as a result of the fix) a lock on the classloader in NegotiateAuthentication.java:


   synchronized (loader) { 

       return isSupportedImpl(hci); 

   }


Now, on Windows it is very likely that the TGT cannot be obtained and for this reason the Authenticator gets invoked. In fact it is almost certain that a Java SE client application on Windows engaging in SPNEGO will have to invoke the Authenticator and for this reason the freeze affects A LOT of people. 


The Authenticator will get invoked WHILE there's a lock on the classloader. NetBeans' Authenticator will prompt the user for credentials using a dialog. Since NetBeans is Swing based this will happen Swing's EDT. Bringing up a dialog will almost inevitably require classloading (especially in the beginning of an application's life) and the EDT will then get stuck because the classloader is locked and because NetBeans' classloader also uses locking. This is what causes the freeze. The network task thread has a lock on the classloader but at the same time it is waiting for the user to respond to a dialog but this will never happen because the UI thread is stuck on class loading.


I see at least two avenues that can be pursued:


1. Fix in JDK: The fix introduced in JDK-8032832, putting a lock on the classloader, seems to me to have lots of unwanted side-effects. Was this really the only way to fix the reported issue?  Could this fix be revisited?

2. Fix in NetBeans: I'm not an expert on NetBeans' classloader. It seems to be me to be implemented at a time when locking on the classloader itself (using syncronized loadClass() method) was the general recommendation. But with the changes done in Java 7 to the default classloader the recommendations changed. 

http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.htmlSo a possible solution may be to change the NetBeans classloader to be more granular on syncronization along the lines of what the standard classloader does as of Java 7. I don't know if this is feasible at all. The NetBeans classloader(s) is really the magic sauce behind NetBeans' much acclaimed module system which underpins *everything* on the platform. So, I guess, less the original authors, there just isn't many people who would dare touch that piece of code. 


and there may be more solutions that I have overlooked.  :-)



Pls advice.

/Peter


From weijun.wang at oracle.com  Mon Aug 28 01:46:05 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 27 Aug 2017 18:46:05 -0700 (PDT)
Subject: Fix for dealock issue in JDK's SPNEGO resulted in another deadlock
Message-ID: 

No simpler solution inside HTTP/SPNEGO?

--Max

----- peterhansson_se at yahoo.com wrote:

> Hi
> 
> I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform.
> The deadlock is a result of the fix for JDK-8032832 which introduced a
> lock on the classloader. Unfortunately this fix just introduces
> another bug (reported as JDK-8068184). I'm now soliciting advice from
> this list.
> 
> The bug essentially causes NetBeans IDE (or applications build on
> NetBeans Platform) to freeze on startup if the site is using a proxy
> which uses 'Negotiate' auth scheme.
> 
> 
> The reason for the deadlock is straightforward:  
> 
> When doing SPNEGO exchange there's now (as a result of the fix) a lock
> on the classloader in NegotiateAuthentication.java:
> 
> 
>    synchronized (loader) { 
> 
>        return isSupportedImpl(hci); 
> 
>    }
> 
> 
> Now, on Windows it is very likely that the TGT cannot be obtained and
> for this reason the Authenticator gets invoked. In fact it is almost
> certain that a Java SE client application on Windows engaging in
> SPNEGO will have to invoke the Authenticator and for this reason the
> freeze affects A LOT of people. 
> 
> 
> The Authenticator will get invoked WHILE there's a lock on the
> classloader. NetBeans' Authenticator will prompt the user for
> credentials using a dialog. Since NetBeans is Swing based this will
> happen Swing's EDT. Bringing up a dialog will almost inevitably
> require classloading (especially in the beginning of an application's
> life) and the EDT will then get stuck because the classloader is
> locked and because NetBeans' classloader also uses locking. This is
> what causes the freeze. The network task thread has a lock on the
> classloader but at the same time it is waiting for the user to respond
> to a dialog but this will never happen because the UI thread is stuck
> on class loading.
> 
> 
> I see at least two avenues that can be pursued:
> 
> 
> 1. Fix in JDK: The fix introduced in JDK-8032832, putting a lock on
> the classloader, seems to me to have lots of unwanted side-effects.
> Was this really the only way to fix the reported issue?  Could this
> fix be revisited?
> 
> 2. Fix in NetBeans: I'm not an expert on NetBeans' classloader. It
> seems to be me to be implemented at a time when locking on the
> classloader itself (using syncronized loadClass() method) was the
> general recommendation. But with the changes done in Java 7 to the
> default classloader the recommendations changed. 
> 
> http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.htmlSo
> a possible solution may be to change the NetBeans classloader to be
> more granular on syncronization along the lines of what the standard
> classloader does as of Java 7. I don't know if this is feasible at
> all. The NetBeans classloader(s) is really the magic sauce behind
> NetBeans' much acclaimed module system which underpins *everything* on
> the platform. So, I guess, less the original authors, there just isn't
> many people who would dare touch that piece of code. 
> 
> 
> and there may be more solutions that I have overlooked.  :-)
> 
> 
> 
> Pls advice.
> 
> /Peter


From peterhansson_se at yahoo.com  Mon Aug 28 14:10:19 2017
From: peterhansson_se at yahoo.com (Peter Hansson)
Date: Mon, 28 Aug 2017 14:10:19 +0000 (UTC)
Subject: Fix for dealock issue in JDK's SPNEGO resulted in another deadlock
In-Reply-To: 
References: 
Message-ID: <959833396.2152279.1503929419986@mail.yahoo.com>




> No simpler solution inside HTTP/SPNEGO?


That's what I'm asking. :-)



Interestingly it seems there are similar bugs in the Eclipse and IntelliJ IDEA bug trackers.


https://bugs.eclipse.org/bugs/show_bug.cgi?id=469116

https://youtrack.jetbrains.com/issue/IDEA-133187


On Monday, August 28, 2017 3:46 AM, Weijun Wang  wrote:



No simpler solution inside HTTP/SPNEGO?

--Max

----- peterhansson_se at yahoo.com wrote:

> Hi
> 
> I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform.
> The deadlock is a result of the fix for JDK-8032832 which introduced a
> lock on the classloader. Unfortunately this fix just introduces
> another bug (reported as JDK-8068184). I'm now soliciting advice from
> this list.
> 
> The bug essentially causes NetBeans IDE (or applications build on
> NetBeans Platform) to freeze on startup if the site is using a proxy
> which uses 'Negotiate' auth scheme.
> 
> 
> The reason for the deadlock is straightforward:  
> 
> When doing SPNEGO exchange there's now (as a result of the fix) a lock
> on the classloader in NegotiateAuthentication.java:
> 
> 
>    synchronized (loader) { 
> 
>        return isSupportedImpl(hci); 
> 
>    }
> 
> 
> Now, on Windows it is very likely that the TGT cannot be obtained and
> for this reason the Authenticator gets invoked. In fact it is almost
> certain that a Java SE client application on Windows engaging in
> SPNEGO will have to invoke the Authenticator and for this reason the
> freeze affects A LOT of people. 
> 
> 
> The Authenticator will get invoked WHILE there's a lock on the
> classloader. NetBeans' Authenticator will prompt the user for
> credentials using a dialog. Since NetBeans is Swing based this will
> happen Swing's EDT. Bringing up a dialog will almost inevitably
> require classloading (especially in the beginning of an application's
> life) and the EDT will then get stuck because the classloader is
> locked and because NetBeans' classloader also uses locking. This is
> what causes the freeze. The network task thread has a lock on the
> classloader but at the same time it is waiting for the user to respond
> to a dialog but this will never happen because the UI thread is stuck
> on class loading.
> 
> 
> I see at least two avenues that can be pursued:
> 
> 
> 1. Fix in JDK: The fix introduced in JDK-8032832, putting a lock on
> the classloader, seems to me to have lots of unwanted side-effects.
> Was this really the only way to fix the reported issue?  Could this
> fix be revisited?
> 
> 2. Fix in NetBeans: I'm not an expert on NetBeans' classloader. It
> seems to be me to be implemented at a time when locking on the
> classloader itself (using syncronized loadClass() method) was the
> general recommendation. But with the changes done in Java 7 to the
> default classloader the recommendations changed. 
> 
> http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.htmlSo
> a possible solution may be to change the NetBeans classloader to be
> more granular on syncronization along the lines of what the standard
> classloader does as of Java 7. I don't know if this is feasible at
> all. The NetBeans classloader(s) is really the magic sauce behind
> NetBeans' much acclaimed module system which underpins *everything* on
> the platform. So, I guess, less the original authors, there just isn't
> many people who would dare touch that piece of code. 
> 
> 
> and there may be more solutions that I have overlooked.  :-)
> 
> 
> 
> Pls advice.
> 
> /Peter


From weijun.wang at oracle.com  Mon Aug 28 15:04:54 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 28 Aug 2017 23:04:54 +0800
Subject: Fix for dealock issue in JDK's SPNEGO resulted in another deadlock
In-Reply-To: <959833396.2152279.1503929419986@mail.yahoo.com>
References: 
 <959833396.2152279.1503929419986@mail.yahoo.com>
Message-ID: <78D356E9-22F7-4111-AF28-36E7AADE2429@oracle.com>

Ahh, IDEs are evil. :-)

I'll take a look.

Thanks
Max

> On Aug 28, 2017, at 10:10 PM, Peter Hansson  wrote:
> 
> 
> 
> 
>> No simpler solution inside HTTP/SPNEGO?
> 
> 
> That's what I'm asking. :-)
> 
> 
> 
> Interestingly it seems there are similar bugs in the Eclipse and IntelliJ IDEA bug trackers.
> 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=469116
> 
> https://youtrack.jetbrains.com/issue/IDEA-133187
> 
> 
> On Monday, August 28, 2017 3:46 AM, Weijun Wang  wrote:
> 
> 
> 
> No simpler solution inside HTTP/SPNEGO?
> 
> --Max
> 
> ----- peterhansson_se at yahoo.com wrote:
> 
>> Hi
>> 
>> I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform.



From weijun.wang at oracle.com  Mon Aug 28 15:12:19 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 28 Aug 2017 23:12:19 +0800
Subject: RFR 8186831: Kerberos ignores PA-DATA with a non-null s2kparams
Message-ID: 

Please review the fix at

   http://cr.openjdk.java.net/~weijun/8186831/webrev.00/

This is an old bug that is about to bite us soon.

Thanks
Max



From peterhansson_se at yahoo.com  Mon Aug 28 17:57:46 2017
From: peterhansson_se at yahoo.com (Peter Hansson)
Date: Mon, 28 Aug 2017 17:57:46 +0000 (UTC)
Subject: Fix for dealock issue in JDK's SPNEGO resulted in another deadlock
In-Reply-To: <78D356E9-22F7-4111-AF28-36E7AADE2429@oracle.com>
References: 
 <959833396.2152279.1503929419986@mail.yahoo.com>
 <78D356E9-22F7-4111-AF28-36E7AADE2429@oracle.com>
Message-ID: <1288951221.2318028.1503943066610@mail.yahoo.com>

Maybe the attached can help. It is a minimalistic Java Swing application which will demonstrate the bug.

Also, you'll need a proxy (or endpoint) which is asking for credentials using Negotiate auth scheme.  If you don't have one I've created a minimal Dummy Proxy Server which is doing just enough to trigger the bug.


https://bitbucket.org/phansson/dummy-proxy-server

(it is not a real proxy server, it doesn't actually proxy, but for the sake of triggering the bug that doesn't matter)


/Peter





On Monday, August 28, 2017 5:04 PM, Weijun Wang  wrote:



Ahh, IDEs are evil. :-)

I'll take a look.

Thanks
Max


> On Aug 28, 2017, at 10:10 PM, Peter Hansson  wrote:
> 
> 
> 
> 
>> No simpler solution inside HTTP/SPNEGO?
> 
> 
> That's what I'm asking. :-)
> 
> 
> 
> Interestingly it seems there are similar bugs in the Eclipse and IntelliJ IDEA bug trackers.
> 
> 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=469116
> 
> https://youtrack.jetbrains.com/issue/IDEA-133187
> 
> 
> On Monday, August 28, 2017 3:46 AM, Weijun Wang  wrote:
> 
> 
> 
> No simpler solution inside HTTP/SPNEGO?
> 
> --Max
> 
> ----- peterhansson_se at yahoo.com wrote:
> 
>> Hi
>> 
>> I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDKBug8068184Example.zip
Type: application/x-zip-compressed
Size: 4917 bytes
Desc: not available
URL: 

From mbalao at redhat.com  Tue Aug 29 18:50:34 2017
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 29 Aug 2017 14:50:34 -0400
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: 
References: 
 
 
Message-ID: 

Hi Xuelei,

>There are a few protocols that can benefits from exporting SSL/TLS
handshake materials, including RFC 5929, RFC 5056, token binding and TLS
1.3 itself.  Can we define a general API so as to exposing the handshake
materials, so as to mitigate the inflating of JSSE APIs?  I may suggest
make further evaluation before move on to following design and code.

Do you prefer an API like "public byte[] getTlsHandshakeMaterial(String
materialType)" (in SSLSocket and SSLEngine) where "materialType" can
eventually be "clientFinishedMessage"/"finishedMessage" or
"serverFinishedMessage"/"peerFinishedMessage"? I cannot think of
"serverCertificate" or "masterKey" as this is more related to a Session and
not neccessarily to a handshake. getTlsHandshakeMaterial would be a lower
level API and would move the burden of knowing which information is
required for "tls-unique" TLS channel binding to the API consumer. Looks
more like the OpenSSL approach (instead of the Python, SSLBoring or GnuTls
approaches). However, OpenSSL have specific methods for each piece of
information instead of a generic and parametrized one. I.e.:
SSL_get_finished or SSL_get_peer_finished. What other information do you
expect the Handshaker to provide?

>The SunJSSE provider happens to cache the finished messages in its
implementation so you can use it for tls-unique, but it may not be true for
other provider or other channel bindings.  Need to define a more reliable
approach to get the handshake materials.

I focused on SunJSSE provider. I'm not sure about how other providers may
implement this API and where they can get the required information from,
without knowing their internals. In regard to SunJSSE and "tls-unique"
binding type, I leveraged on existing data. If data weren't already there,
I would have to figure out how to get it from the handshake -doing the same
that was already done would have been an option-. Do you prefer the
Handshaker to provide a function to get different information and not just
the finished hash? (as for the public SSLSocket/SSLEngine
"getTlsHandshakeMaterial" API). Which other information may be useful to
get from the Handshaker? What do you mean by reliable? (given that this is
all SunJSSE internal and we have no external dependencies).

In regard to other channel bindings, it'll depend on the binding type the
way in which the information is obtained. I.e.: "tls-unique" SunJSSE
implementation leverages on cached finished messages. However,
"tls-server-end-point" leverages on stored certificates that are obtained
from the Session (not from the handshaker). Is there any specific channel
binding you are concerned with?

>If the channel binding is not required, it may be not necessary to expose
the handshake materials.  Need to define a solution to indicate the need of
the exporting.

Do you mean a lower layer knowing if the upper layer is going to require
that information and decide to provide it or not based on that knowledge? I
think I didn't get your point here.

>2. No way to know the update of the underlying handshake materials.
>If renegotiation can takes place, need to define a interface to indicate
that so that application can response accordingly.  See section 3 and 7 of
RFC 5929.

I intentionally skipped this -at the cost of a spurious authentication- to
avoid adding complexity to the API. An spurious authentication -which does
not appear likely to me- can easily be retried by the application. The RFC
5929 suggests APIs through which the application can *control* the flow
(i.e.: hold a renegotitation). This would expose JSSE internals. This is
more than notifying. Notification, in my opinion, adds no value: what if
the application already used the binding token before receiving the
notification? The spurious authentication will happen anyways and has to be
handled -i.e. retried-. It's just a timing issue. The real value is
controlling the flow as the RFC suggests, but at the cost of exposing JSSE
internals.

Kind regards,
Martin.-

On Sat, Aug 26, 2017 at 5:25 PM, Xuelei Fan  wrote:

> Hi Marin,
>
> Sorry for the delay.
>
> There are a few protocols that can benefits from exporting SSL/TLS
> handshake materials, including RFC 5929, RFC 5056, token binding and TLS
> 1.3 itself.  Can we define a general API so as to exposing the handshake
> materials, so as to mitigate the inflating of JSSE APIs?  I may suggest
> make further evaluation before move on to following design and code.
>
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
> 91070/webrev.02/
> I have two concerns about the design:
>
> 1. Channel binding may be not always required.
> SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);
>
> The SunJSSE provider happens to cache the finished messages in its
> implementation so you can use it for tls-unique, but it may not be true for
> other provider or other channel bindings.  Need to define a more reliable
> approach to get the handshake materials.
>
> If the channel binding is not required, it may be not necessary to expose
> the handshake materials.  Need to define a solution to indicate the need of
> the exporting.
>
> 2. No way to know the update of the underlying handshake materials.
> If renegotiation can takes place, need to define a interface to indicate
> that so that application can response accordingly.  See section 3 and 7 of
> RFC 5929.
>
> Thanks,
> Xuelei
>
> On 7/31/2017 8:53 AM, Martin Balao wrote:
>
>> Hi,
>>
>> Here it is an update for the proposed TLS Channel Bindings support in
>> OpenJDK:
>>
>>   * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.02/ (browse online)
>>   * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.02/6491070.webrev.02.zip (download)
>>
>> Changes since v01:
>>
>>   * getTlsChannelBinding API changed to return null by default (if not
>> implemented), instead of throwing an UnsupportedOperationException.
>>
>>   * "tls-server-end-point" TLS channel binding now supported.
>>
>> Kind regards,
>> Martin.-
>>
>> On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao > mbalao at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     Here it is my proposal for JDK-6491070 (Support for RFC 5929-Channel
>>     Bindings: e.g. public API to obtain TLS finished message) [1]:
>>
>>       *
>>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.01/
>>     > 491070/webrev.01/>
>>       *
>>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.01/6491070.webrev.01.zip
>>     > 491070/webrev.01/6491070.webrev.01.zip>
>>
>>     Notes:
>>       * Implementation based on Channel Bindings for TLS (RFC 5929) [2]
>>
>>       * Only "tls-unique" currently supported
>>
>>     Look forward to your comments.
>>
>>     Kind regards,
>>     Martin.-
>>
>>     --
>>     [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>>     
>>     [2] - https://tools.ietf.org/html/rfc5929
>>     
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From xuelei.fan at oracle.com  Tue Aug 29 20:34:36 2017
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 29 Aug 2017 13:34:36 -0700
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: 
References: 
 
 
 
Message-ID: <97c02f80-88aa-d0a7-f1e0-ba80b3a3b71d@oracle.com>

On 8/26/2017 2:56 PM, Bernd Eckenfels wrote:
 > How about only passing it to an extended handshake listener. The
 > material does not have to be cached (the app can do it if needed) and
 > renegotiation works the same way. This can also be helpful for things
 > like logging the master secret (for wireshark decryption). It can even
 > handle auditing of session resumptions
Martin, what do you think about Bernd's proposal above and similar 
callback mechanism?

More comment inlines.

On 8/29/2017 11:50 AM, Martin Balao wrote:
> Hi Xuelei,
> 
>  >There are a few protocols that can benefits from exporting SSL/TLS 
> handshake materials, including RFC 5929, RFC 5056, token binding and TLS 
> 1.3 itself.? Can we define a general API so as to exposing the handshake 
> materials, so as to mitigate the inflating of JSSE APIs?? I may suggest 
> make further evaluation before move on to following design and code.
> 
> Do you prefer an API like "public byte[] getTlsHandshakeMaterial(String 
> materialType)" (in SSLSocket and SSLEngine) where "materialType" can 
> eventually be "clientFinishedMessage"/"finishedMessage" or 
> "serverFinishedMessage"/"peerFinishedMessage"?
The problem of the APIs like that is, when applications call the method, 
it is not always return the expected result, and the implementation may 
have to cache the message even if an application never use it.  See more 
in the following example.

> I cannot think of 
> "serverCertificate" or "masterKey" as this is more related to a Session 
> and not neccessarily to a handshake. getTlsHandshakeMaterial would be a 
> lower level API and would move the burden of knowing which information 
> is required for "tls-unique" TLS channel binding to the API consumer. 
> Looks more like the OpenSSL approach (instead of the Python, SSLBoring 
> or GnuTls approaches). However, OpenSSL have specific methods for each 
> piece of information instead of a generic and parametrized one. I.e.: 
> SSL_get_finished or SSL_get_peer_finished. What other information do you 
> expect the Handshaker to provide?
> 
>  >The SunJSSE provider happens to cache the finished messages in its 
> implementation so you can use it for tls-unique, but it may not be true 
> for other provider or other channel bindings.? Need to define a more 
> reliable approach to get the handshake materials.
> 
> I focused on SunJSSE provider. I'm not sure about how other providers 
> may implement this API and where they can get the required information 
> from, without knowing their internals. In regard to SunJSSE and 
> "tls-unique" binding type, I leveraged on existing data. If data weren't 
> already there, I would have to figure out how to get it from the 
> handshake -doing the same that was already done would have been an 
> option-. Do you prefer the Handshaker to provide a function to get 
> different information and not just the finished hash? (as for the public 
> SSLSocket/SSLEngine "getTlsHandshakeMaterial" API). Which other 
> information may be useful to get from the Handshaker? What do you mean 
> by reliable? (given that this is all SunJSSE internal and we have no 
> external dependencies).
> 
Let consider the use of the API.
    byte[] getTlsChannelBinding("tls_unique");

I'm confusing when I try to use it by myself:
1. provider does not implement this method
    return null or empty?

It happens because an old provider should still work in new JDK, but old 
provider does not implement new APIs, or a new provider does not support 
this feature.

2. the method is called before handshaking
    return null or empty?

3. the method is called during handshaking
    return null, empty or the channel binding value?

4. the method is called at the same time the handshaking completed?
    return the channel binding value?

5. the method is called after the handshaking
    return the channel binding value?

6. the method is called during renegoitation
    return null, empty, the old binding value, or the new binding value?

7. the method is called after handshaking
    return old binding value, or the new binding value?

8. the method is called after the initial handshaking, but the binding 
value is changed shortly after because of renegotiation.
    how could application use the binding value?

We need a clear define of the behavior of the method.  It could be 
complicated if the method is designed as getTlsChannelBinding("tls_unique").

I feel that handshake material should be captured when
1. it is requested to capture the handshake material, and
2. the handshake material get produced.

For the getTlsChannelBinding("tls_unique") API, it is unknown:
1. Is it required to capture the handshake material?
2. Is the handshake material produced?

The two points could result in a few unexpected problems, as the above 8 
items that we may want to consider.

> In regard to other channel bindings, it'll depend on the binding type 
> the way in which the information is obtained. I.e.: "tls-unique" SunJSSE 
> implementation leverages on cached finished messages. However, 
> "tls-server-end-point" leverages on stored certificates that are 
> obtained from the Session (not from the handshaker). Is there any 
> specific channel binding you are concerned with?
> 
>  >If the channel binding is not required, it may be not necessary to 
> expose the handshake materials.? Need to define a solution to indicate 
> the need of the exporting.
> 
> Do you mean a lower layer knowing if the upper layer is going to require 
> that information and decide to provide it or not based on that 
> knowledge? I think I didn't get your point here.
> 
I mean, if an application want to support channel binding, the provider 
can provider the channel binding service;  If the an application does 
not want channel binding, the provider should be perform the channel 
binding service.  The getTlsChannelBinding() make the provider MUST 
perform channel binding cache or calculation no matter application want 
it or not.

>  >2. No way to know the update of the underlying handshake materials.
>  >If renegotiation can takes place, need to define a interface to 
> indicate that so that application can response accordingly.? See section 
> 3 and 7 of RFC 5929.
> 
> I intentionally skipped this -at the cost of a spurious authentication- 
> to avoid adding complexity to the API. An spurious authentication -which 
> does not appear likely to me- can easily be retried by the application. 
> The RFC 5929 suggests APIs through which the application can *control* 
> the flow (i.e.: hold a renegotitation). This would expose JSSE 
> internals. This is more than notifying. Notification, in my opinion, 
> adds no value: what if the application already used the binding token 
> before receiving the notification? The spurious authentication will 
> happen anyways and has to be handled -i.e. retried-. It's just a timing 
> issue. The real value is controlling the flow as the RFC suggests, but 
> at the cost of exposing JSSE internals.
> 
My understanding, the block of the protocol is to make sure application 
is performing the channel binding with the right value, or updating the 
value accordingly if necessary.  If you skip this and when renegotiation 
happen, the channel binding could be limited, or may not work as expected.

Thanks,
Xuelei

> Kind regards,
> Martin.-
> 
> On Sat, Aug 26, 2017 at 5:25 PM, Xuelei Fan  > wrote:
> 
>     Hi Marin,
> 
>     Sorry for the delay.
> 
>     There are a few protocols that can benefits from exporting SSL/TLS
>     handshake materials, including RFC 5929, RFC 5056, token binding and
>     TLS 1.3 itself.? Can we define a general API so as to exposing the
>     handshake materials, so as to mitigate the inflating of JSSE APIs? 
>     I may suggest make further evaluation before move on to following
>     design and code.
> 
>      >
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
>     
>     I have two concerns about the design:
> 
>     1. Channel binding may be not always required.
>     SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);
> 
>     The SunJSSE provider happens to cache the finished messages in its
>     implementation so you can use it for tls-unique, but it may not be
>     true for other provider or other channel bindings.? Need to define a
>     more reliable approach to get the handshake materials.
> 
>     If the channel binding is not required, it may be not necessary to
>     expose the handshake materials.? Need to define a solution to
>     indicate the need of the exporting.
> 
>     2. No way to know the update of the underlying handshake materials.
>     If renegotiation can takes place, need to define a interface to
>     indicate that so that application can response accordingly.? See
>     section 3 and 7 of RFC 5929.
> 
>     Thanks,
>     Xuelei
> 
>     On 7/31/2017 8:53 AM, Martin Balao wrote:
> 
>         Hi,
> 
>         Here it is an update for the proposed TLS Channel Bindings
>         support in OpenJDK:
> 
>          ??*
>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/
>         
>         (browse online)
>          ??*
>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.02/6491070.webrev.02.zip
>         
>         (download)
> 
>         Changes since v01:
> 
>          ??* getTlsChannelBinding API changed to return null by default
>         (if not implemented), instead of throwing an
>         UnsupportedOperationException.
> 
>          ??* "tls-server-end-point" TLS channel binding now supported.
> 
>         Kind regards,
>         Martin.-
> 
>         On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao                    >> wrote:
> 
>          ? ? Hi,
> 
>          ? ? Here it is my proposal for JDK-6491070 (Support for RFC
>         5929-Channel
>          ? ? Bindings: e.g. public API to obtain TLS finished message) [1]:
> 
>          ? ? ??*
>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
>         
>             
>                  >
>          ? ? ??*
>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip
>         
>             
>                  >
> 
>          ? ? Notes:
>          ? ? ??* Implementation based on Channel Bindings for TLS (RFC
>         5929) [2]
> 
>          ? ? ??* Only "tls-unique" currently supported
> 
>          ? ? Look forward to your comments.
> 
>          ? ? Kind regards,
>          ? ? Martin.-
> 
>          ? ? --
>          ? ? [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>         
>          ? ?          >
>          ? ? [2] - https://tools.ietf.org/html/rfc5929
>         
>          ? ?          >
> 
> 
> 


From bradford.wetmore at oracle.com  Tue Aug 29 22:33:54 2017
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 29 Aug 2017 15:33:54 -0700
Subject: RFR: 8170157, 8170245: Enable unlimited cryptographic policy by
 default in OracleJDK
In-Reply-To: <9ca65218-86b0-1209-8f11-9d0b2fd67c2b@oracle.com>
References: <9ca65218-86b0-1209-8f11-9d0b2fd67c2b@oracle.com>
Message-ID: <33d4d8cf-90ef-3653-48f0-96c0c327aca8@oracle.com>


Very minor comments/tweaks.

On 8/18/2017 7:01 AM, Se?n Coffey wrote:
> Looking to backport 8170157 to jdk8u-dev. The 8170245 test bug also gets 
> pulled in for this port since some tests need cleaning up to deal with 
> unlimited crypto environment.
> 
> webrev : 
> http://cr.openjdk.java.net/~coffeys/webrev.8170157.8u.01/webrev/index.html

Update copyright dates.  Looks like the original work was done in 
December 2016, but this is our actual push.

JceSecurity.java
================
265:  Suggestion since this is JDK/JRE specific:

jre/lib/security
->
/lib/security

Dynamic.java
============
Is the removal of the separate ECB case because the parameter will just 
be ignored?  Why was this a failing test case?

Thanks.

Brad





From weijun.wang at oracle.com  Thu Aug 31 08:49:04 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 31 Aug 2017 16:49:04 +0800
Subject: RFR 8186931: jdk.security.jarsigner package is missing package
 summary 
Message-ID: <8FC7DB36-00EC-475E-82D1-F2A48FDD03C8@oracle.com>

Please take a review at this new package.java file.

/*
* Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License version 2 only, as
* published by the Free Software Foundation. Oracle designates this
* particular file as subject to the "Classpath" exception as provided
* by Oracle in the LICENSE file that accompanied this code.
*
* This code is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
* version 2 for more details (a copy is included in the LICENSE file that
* accompanied this code).
*
* You should have received a copy of the GNU General Public License version
* 2 along with this work; if not, write to the Free Software Foundation,
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
* or visit www.oracle.com if you need additional information or have any
* questions.
*/

/**
* This package contains the {@link jdk.security.jarsigner.JarSigner} API,
* which backs the signing function of the {@code jarsigner} tool.
*/
package jdk.security.jarsigner;

Thanks
Max



From sean.mullan at oracle.com  Thu Aug 31 15:10:33 2017
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 31 Aug 2017 11:10:33 -0400
Subject: RFR 8186931: jdk.security.jarsigner package is missing package
 summary
In-Reply-To: <8FC7DB36-00EC-475E-82D1-F2A48FDD03C8@oracle.com>
References: <8FC7DB36-00EC-475E-82D1-F2A48FDD03C8@oracle.com>
Message-ID: 

On 8/31/17 4:49 AM, Weijun Wang wrote:

> /**
> * This package contains the {@link jdk.security.jarsigner.JarSigner} API,
> * which backs the signing function of the {@code jarsigner} tool.
> */

I think you should say something about that this API can be used to sign 
JAR files. The fact that it is also used by jarsigner seems less 
important to mention in the package description. I suggest changing this to:

"This package contains the {@link jdk.security.jarsigner.JarSigner} API 
which can be used to sign jar files."

--Sean


From mbalao at redhat.com  Thu Aug 31 18:41:31 2017
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 31 Aug 2017 14:41:31 -0400
Subject: Code Review Request: JDK-6491070 (Support for RFC 5929-Channel
 Bindings)
In-Reply-To: <97c02f80-88aa-d0a7-f1e0-ba80b3a3b71d@oracle.com>
References: 
 
 
 
 <97c02f80-88aa-d0a7-f1e0-ba80b3a3b71d@oracle.com>
Message-ID: 

Hi,

The material is already cached in the handshaker if secure renegotiation is
enabled. However, I agree with you that we are going to cache the value
even when secure renegotiation is not enabled, thus, wasting roughly 12
bytes (as bytes for an empty array are already consumed). In fact, the
exact case -adding a few conditionals to webrev.02- is the one in which
secure renegotiation is disabled and extended master secret is enabled.
GnuTls and OpenSSL -including its derivatives like Boring SSL and Python
(through OpenSSL)- always cache this information.

As for the empty / null cases, the API consumer was expected to ask for the
binding information after the TLS connection is established. It's on the
API consumer knowledge that asking for the information before (i.e.: just
after creating a disconnected socket) or while the handshake is taking
place, makes no sense and no valid value will be obtained (either we define
this as null or empty). For those providers that do not support this
feature, the information wouldn't have been available after the handshake.
However, I agree with you that before the handshake is completed there is
no means of knowing if the provider does support this API. My first webrev
(webrev.01) was throwing an UnsupportedOperationException to make this case
explicit but I had doubts regarding the real value it provides for the API
consumer. The proposed API was similar to Python, SSLBoring and GnuTLs.
However, handshake listener callbacks -as Bernd suggests- and the idea of
just exposing the handshake material (as a lower level API) sounds good to
me. I can give it a try. I propose then to bring the handshake information
as part of a HandshakeCompletedEvent instance, even though the callback
registrant may not consume it. Would that work for you?

In regard to the handshake material update -which I assumed unlikely-, the
point in which a renegotiation may take place (from the server side) is
when reading data, not when writing. That cannot be controlled by the
application because it's JSSE internal and not exposed. Thus, an
application may read from the socket, get the handshake material and write
a message using the binding value -which we can make sure that is the valid
one at that point-. However, as soon as the application reads again from
the socket, a renegotiation -if requested by the client- may be processed
and the binding value gets updated. The higher level protocol may fail
-because the binding value was already sent but not processed on the other
side- and a re-try needed. This looks independent of whether we use the
originally proposed API or the handshake listener callback interface (or
even a sync callback), because the underlying problem is that the
application cannot really control the renegotiation flow in the lower layer
(as RFC 5929 suggest). The options I see are adding more complexity to the
API and let the application control the renegotiation flow or live with
that and expect the application to retry.

Thanks,
Martin.-

On Tue, Aug 29, 2017 at 4:34 PM, Xuelei Fan  wrote:

> On 8/26/2017 2:56 PM, Bernd Eckenfels wrote:
> > How about only passing it to an extended handshake listener. The
> > material does not have to be cached (the app can do it if needed) and
> > renegotiation works the same way. This can also be helpful for things
> > like logging the master secret (for wireshark decryption). It can even
> > handle auditing of session resumptions
> Martin, what do you think about Bernd's proposal above and similar
> callback mechanism?
>
> More comment inlines.
>
> On 8/29/2017 11:50 AM, Martin Balao wrote:
>
>> Hi Xuelei,
>>
>>  >There are a few protocols that can benefits from exporting SSL/TLS
>> handshake materials, including RFC 5929, RFC 5056, token binding and TLS
>> 1.3 itself.  Can we define a general API so as to exposing the handshake
>> materials, so as to mitigate the inflating of JSSE APIs?  I may suggest
>> make further evaluation before move on to following design and code.
>>
>> Do you prefer an API like "public byte[] getTlsHandshakeMaterial(String
>> materialType)" (in SSLSocket and SSLEngine) where "materialType" can
>> eventually be "clientFinishedMessage"/"finishedMessage" or
>> "serverFinishedMessage"/"peerFinishedMessage"?
>>
> The problem of the APIs like that is, when applications call the method,
> it is not always return the expected result, and the implementation may
> have to cache the message even if an application never use it.  See more in
> the following example.
>
> I cannot think of "serverCertificate" or "masterKey" as this is more
>> related to a Session and not neccessarily to a handshake.
>> getTlsHandshakeMaterial would be a lower level API and would move the
>> burden of knowing which information is required for "tls-unique" TLS
>> channel binding to the API consumer. Looks more like the OpenSSL approach
>> (instead of the Python, SSLBoring or GnuTls approaches). However, OpenSSL
>> have specific methods for each piece of information instead of a generic
>> and parametrized one. I.e.: SSL_get_finished or SSL_get_peer_finished. What
>> other information do you expect the Handshaker to provide?
>>
>>  >The SunJSSE provider happens to cache the finished messages in its
>> implementation so you can use it for tls-unique, but it may not be true for
>> other provider or other channel bindings.  Need to define a more reliable
>> approach to get the handshake materials.
>>
>> I focused on SunJSSE provider. I'm not sure about how other providers may
>> implement this API and where they can get the required information from,
>> without knowing their internals. In regard to SunJSSE and "tls-unique"
>> binding type, I leveraged on existing data. If data weren't already there,
>> I would have to figure out how to get it from the handshake -doing the same
>> that was already done would have been an option-. Do you prefer the
>> Handshaker to provide a function to get different information and not just
>> the finished hash? (as for the public SSLSocket/SSLEngine
>> "getTlsHandshakeMaterial" API). Which other information may be useful to
>> get from the Handshaker? What do you mean by reliable? (given that this is
>> all SunJSSE internal and we have no external dependencies).
>>
>> Let consider the use of the API.
>    byte[] getTlsChannelBinding("tls_unique");
>
> I'm confusing when I try to use it by myself:
> 1. provider does not implement this method
>    return null or empty?
>
> It happens because an old provider should still work in new JDK, but old
> provider does not implement new APIs, or a new provider does not support
> this feature.
>
> 2. the method is called before handshaking
>    return null or empty?
>
> 3. the method is called during handshaking
>    return null, empty or the channel binding value?
>
> 4. the method is called at the same time the handshaking completed?
>    return the channel binding value?
>
> 5. the method is called after the handshaking
>    return the channel binding value?
>
> 6. the method is called during renegoitation
>    return null, empty, the old binding value, or the new binding value?
>
> 7. the method is called after handshaking
>    return old binding value, or the new binding value?
>
> 8. the method is called after the initial handshaking, but the binding
> value is changed shortly after because of renegotiation.
>    how could application use the binding value?
>
> We need a clear define of the behavior of the method.  It could be
> complicated if the method is designed as getTlsChannelBinding("tls_uniq
> ue").
>
> I feel that handshake material should be captured when
> 1. it is requested to capture the handshake material, and
> 2. the handshake material get produced.
>
> For the getTlsChannelBinding("tls_unique") API, it is unknown:
> 1. Is it required to capture the handshake material?
> 2. Is the handshake material produced?
>
> The two points could result in a few unexpected problems, as the above 8
> items that we may want to consider.
>
> In regard to other channel bindings, it'll depend on the binding type the
>> way in which the information is obtained. I.e.: "tls-unique" SunJSSE
>> implementation leverages on cached finished messages. However,
>> "tls-server-end-point" leverages on stored certificates that are obtained
>> from the Session (not from the handshaker). Is there any specific channel
>> binding you are concerned with?
>>
>>  >If the channel binding is not required, it may be not necessary to
>> expose the handshake materials.  Need to define a solution to indicate the
>> need of the exporting.
>>
>> Do you mean a lower layer knowing if the upper layer is going to require
>> that information and decide to provide it or not based on that knowledge? I
>> think I didn't get your point here.
>>
>> I mean, if an application want to support channel binding, the provider
> can provider the channel binding service;  If the an application does not
> want channel binding, the provider should be perform the channel binding
> service.  The getTlsChannelBinding() make the provider MUST perform channel
> binding cache or calculation no matter application want it or not.
>
>  >2. No way to know the update of the underlying handshake materials.
>>  >If renegotiation can takes place, need to define a interface to
>> indicate that so that application can response accordingly.  See section 3
>> and 7 of RFC 5929.
>>
>> I intentionally skipped this -at the cost of a spurious authentication-
>> to avoid adding complexity to the API. An spurious authentication -which
>> does not appear likely to me- can easily be retried by the application. The
>> RFC 5929 suggests APIs through which the application can *control* the flow
>> (i.e.: hold a renegotitation). This would expose JSSE internals. This is
>> more than notifying. Notification, in my opinion, adds no value: what if
>> the application already used the binding token before receiving the
>> notification? The spurious authentication will happen anyways and has to be
>> handled -i.e. retried-. It's just a timing issue. The real value is
>> controlling the flow as the RFC suggests, but at the cost of exposing JSSE
>> internals.
>>
>> My understanding, the block of the protocol is to make sure application
> is performing the channel binding with the right value, or updating the
> value accordingly if necessary.  If you skip this and when renegotiation
> happen, the channel binding could be limited, or may not work as expected.
>
> Thanks,
> Xuelei
>
> Kind regards,
>> Martin.-
>>
>>
>> On Sat, Aug 26, 2017 at 5:25 PM, Xuelei Fan > > wrote:
>>
>>     Hi Marin,
>>
>>     Sorry for the delay.
>>
>>     There are a few protocols that can benefits from exporting SSL/TLS
>>     handshake materials, including RFC 5929, RFC 5056, token binding and
>>     TLS 1.3 itself.  Can we define a general API so as to exposing the
>>     handshake materials, so as to mitigate the inflating of JSSE APIs?
>>  I may suggest make further evaluation before move on to following
>>     design and code.
>>
>>      >
>>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.02/
>>     > 491070/webrev.02/>
>>     I have two concerns about the design:
>>
>>     1. Channel binding may be not always required.
>>     SSLSocket/SSLEngine.getTlsChannelBinding(String bindingType);
>>
>>     The SunJSSE provider happens to cache the finished messages in its
>>     implementation so you can use it for tls-unique, but it may not be
>>     true for other provider or other channel bindings.  Need to define a
>>     more reliable approach to get the handshake materials.
>>
>>     If the channel binding is not required, it may be not necessary to
>>     expose the handshake materials.  Need to define a solution to
>>     indicate the need of the exporting.
>>
>>     2. No way to know the update of the underlying handshake materials.
>>     If renegotiation can takes place, need to define a interface to
>>     indicate that so that application can response accordingly.  See
>>     section 3 and 7 of RFC 5929.
>>
>>     Thanks,
>>     Xuelei
>>
>>     On 7/31/2017 8:53 AM, Martin Balao wrote:
>>
>>         Hi,
>>
>>         Here it is an update for the proposed TLS Channel Bindings
>>         support in OpenJDK:
>>
>>            *
>>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.02/
>>         > 491070/webrev.02/>
>>         (browse online)
>>            *
>>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.02/6491070.webrev.02.zip
>>         > 491070/webrev.02/6491070.webrev.02.zip>
>>         (download)
>>
>>         Changes since v01:
>>
>>            * getTlsChannelBinding API changed to return null by default
>>         (if not implemented), instead of throwing an
>>         UnsupportedOperationException.
>>
>>            * "tls-server-end-point" TLS channel binding now supported.
>>
>>         Kind regards,
>>         Martin.-
>>
>>         On Wed, Jul 26, 2017 at 4:12 PM, Martin Balao >          >
>>         >> wrote:
>>
>>              Hi,
>>
>>              Here it is my proposal for JDK-6491070 (Support for RFC
>>         5929-Channel
>>              Bindings: e.g. public API to obtain TLS finished message)
>> [1]:
>>
>>                *
>>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.01/
>>         > 491070/webrev.01/>
>>                     > gehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/
>>         > 491070/webrev.01/>>
>>                *
>>         http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-64
>> 91070/webrev.01/6491070.webrev.01.zip
>>         > 491070/webrev.01/6491070.webrev.01.zip>
>>                     > gehwolf/webrevs/mbalaoal/JDK-6491070/webrev.01/6491070.webrev.01.zip
>>         > 491070/webrev.01/6491070.webrev.01.zip>>
>>
>>              Notes:
>>                * Implementation based on Channel Bindings for TLS (RFC
>>         5929) [2]
>>
>>                * Only "tls-unique" currently supported
>>
>>              Look forward to your comments.
>>
>>              Kind regards,
>>              Martin.-
>>
>>              --
>>              [1] - https://bugs.openjdk.java.net/browse/JDK-6491070
>>         
>>              >         >
>>              [2] - https://tools.ietf.org/html/rfc5929
>>         
>>              >         >
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ivan.gerasimov at oracle.com  Thu Aug 31 20:10:32 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 31 Aug 2017 13:10:32 -0700
Subject: [10] XXS RFR 8187023: Cannot read pkcs11 config file in UTF-16
 environment
Message-ID: 

Hello!

Currently, when reading the pkcs11 config file, the default encoding is 
assumed.

This causes errors when the encoding is set to UTF-16.

Would you please help review the trivial fix?

Bug: https://bugs.openjdk.java.net/browse/JDK-8187023

Webrev: http://cr.openjdk.java.net/~igerasim/8187023/00/webrev/

-- 
With kind regards,
Ivan Gerasimov



From anthony.scarpino at oracle.com  Thu Aug 31 20:44:20 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 31 Aug 2017 13:44:20 -0700
Subject: [10] XXS RFR 8187023: Cannot read pkcs11 config file in UTF-16
 environment
In-Reply-To: 
References: 
Message-ID: <42d0bc04-6f0c-2889-9860-c8153bfb3949@oracle.com>

On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
> Hello!
> 
> Currently, when reading the pkcs11 config file, the default encoding is 
> assumed.
> 
> This causes errors when the encoding is set to UTF-16.
> 
> Would you please help review the trivial fix?
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8187023
> 
> Webrev: http://cr.openjdk.java.net/~igerasim/8187023/00/webrev/
> 

I thought config files were only ASCII only?  If someone puts a UTF-16 
character into the configuration file, are we sure it won't cause 
problems with the native library too?  PKCS11 itself only supports UTF-8.

Tony



From ivan.gerasimov at oracle.com  Thu Aug 31 21:19:41 2017
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 31 Aug 2017 14:19:41 -0700
Subject: [10] XXS RFR 8187023: Cannot read pkcs11 config file in UTF-16
 environment
In-Reply-To: <42d0bc04-6f0c-2889-9860-c8153bfb3949@oracle.com>
References: 
 <42d0bc04-6f0c-2889-9860-c8153bfb3949@oracle.com>
Message-ID: <92cb03c9-b99c-8e8a-0141-e7627d351fd9@oracle.com>



On 8/31/17 1:44 PM, Anthony Scarpino wrote:
> On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> Currently, when reading the pkcs11 config file, the default encoding 
>> is assumed.
>>
>> This causes errors when the encoding is set to UTF-16.
>>
>> Would you please help review the trivial fix?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187023
>>
>> Webrev: http://cr.openjdk.java.net/~igerasim/8187023/00/webrev/
>>
>
> I thought config files were only ASCII only?
That's correct.
I should have been more clear:  the error occurs when the config file is 
read by an application with -Dfile.encoding=UTF-16
In that case the config file is tried to be treated as encoded with UTF-16.

The solution is to explicitly specify the charset when the config file 
is opened for reading.

With kind regards,
Ivan

>   If someone puts a UTF-16 character into the configuration file, are 
> we sure it won't cause problems with the native library too?  PKCS11 
> itself only supports UTF-8.
>
> Tony
>
>


From anthony.scarpino at oracle.com  Thu Aug 31 23:04:44 2017
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Thu, 31 Aug 2017 16:04:44 -0700
Subject: [10] XXS RFR 8187023: Cannot read pkcs11 config file in UTF-16
 environment
In-Reply-To: <92cb03c9-b99c-8e8a-0141-e7627d351fd9@oracle.com>
References: 
 <42d0bc04-6f0c-2889-9860-c8153bfb3949@oracle.com>
 <92cb03c9-b99c-8e8a-0141-e7627d351fd9@oracle.com>
Message-ID: <5a577cac-ba59-aa79-c6d8-afd1c4fba565@oracle.com>

On 08/31/2017 02:19 PM, Ivan Gerasimov wrote:
> 
> 
> On 8/31/17 1:44 PM, Anthony Scarpino wrote:
>> On 08/31/2017 01:10 PM, Ivan Gerasimov wrote:
>>> Hello!
>>>
>>> Currently, when reading the pkcs11 config file, the default encoding 
>>> is assumed.
>>>
>>> This causes errors when the encoding is set to UTF-16.
>>>
>>> Would you please help review the trivial fix?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187023
>>>
>>> Webrev: http://cr.openjdk.java.net/~igerasim/8187023/00/webrev/
>>>
>>
>> I thought config files were only ASCII only?
> That's correct.
> I should have been more clear:  the error occurs when the config file is 
> read by an application with -Dfile.encoding=UTF-16
> In that case the config file is tried to be treated as encoded with UTF-16.
> 
> The solution is to explicitly specify the charset when the config file 
> is opened for reading.
> 
> With kind regards,
> Ivan

Thanks for the clarification.. Your changes look good to me.

Tony