From weijun.wang at oracle.com Fri May 1 00:51:00 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 1 May 2020 08:51:00 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> Message-ID: > On Apr 30, 2020, at 9:55 PM, Weijun Wang wrote: > > Sorry, it's been a busy day on something else and I haven't looked at your webrev.01 yet. Will look at it tomorrow. > >> On Apr 30, 2020, at 8:15 AM, Valerie Peng wrote: >> >> >> If you look at the original SunJCE impl, it also did not register oid for RC4 cipher. So, that's why I didn't include RC4 oid in SecurityProviderConstants in the aliases for RC4. >> >> If I recall correctly, "RC4" is the algorithm name, however, due to some patent(?) concern, non-RSA vendors register their impl under "ARCFOUR" and set "RC4" to be the alias. So, that's the convention that I continue to use, i.e. use "ARCFOUR" as the standard name and "RC4" as the alias. >> >> I can add the oid as the RC4 alias for completeness sake. (Will update in webrev.02) > > Since ARCFOUR is the standard name, does it make sense to rewrite the OidString to > > ARCFOUR("1.2.840.113549.3.4", "RC4"), Sorry, I meant ARCFOUR("1.2.840.113549.3.4"), --Max > > --Max > >> >> Thanks, >> Valerie >> On 4/28/2020 2:39 AM, Weijun Wang wrote: >>> I found two algorithm names in a very twisted relation, in SecurityProviderConstants.java: >>> >>> store("ARCFOUR", "RC4"); >>> >>> and in OidString.java: >>> >>> RC4("1.2.840.113549.3.4", "ARCFOUR") >>> >>> So each is the other's alias, and because of this, Cipher.ARCFOUR does not have OID aliases. >>> >>> I can see in https://download.java.net/java/early_access/jdk15/docs/specs/security/standard-names.html that both ARCFOUR and RC4 are standard names. In my understanding, this means both must be supported and it looks like some kind of "required" alias. Is this the reason we have to define them in this way? >>> >>> Thanks, >>> Max >>> >>> >>>> On Apr 28, 2020, at 4:53 PM, Weijun Wang wrote: >>>> >>>> Where is the following OID used >>>> >>>> RSAEncryption("1.2.840.113549.1.1.1", "RSA"), // in RSA Cipher >>>> >>>> I only found in RSAUtil.java: >>>> >>>> case RSA: >>>> oid = AlgorithmId.RSAEncryption_oid; >>>> break; >>>> >>>> What if we do not give it a different stdName? Or, should we make it an alias in SunJCE for Cipher.RSA? >>>> >>>> --Max >>>> >>>> >>>>> On Apr 24, 2020, at 7:11 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> Would you have time to review this change? The current webrev attempts to cover all security classes where hard-coded oid strings and consolidate these known oid string values into a single enum type. The changes are quite extensive, I can trim back and only cover the provider algorithm oids if you prefer. There are pros and cons for both approach. >>>>> >>>>> I know that the naming convention is to use all upper case for enum constants, but choose to use the same naming convention as standard names to simplify the code. SecurityProviderConstants class defines the common mappings which are general to providers. Provider-specific alias mappings are handled in specific provider class, e.g. SunJSSE class. >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8242151 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8242151/webrev.00/ >>>>> >>>>> Mach5 runs clean. >>>>> >>>>> Valerie >>>>> > From weijun.wang at oracle.com Fri May 1 09:45:19 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 1 May 2020 17:45:19 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> Message-ID: ObjectIdentifier.java --------------------- Have you thought about storing the ObjectIdentifier object somewhere? ObjectIdentifier.of() creates a new object each time and the conversion of string to byte[] might be a performance issue. We used to have a lot of ObjectIdentifier objects in AlgorithmId but now we only have KnownOIDs. I had a talk with Stuart and he has a suggestion that we can stuff all pre-calculated OID DER encodings in a long byte array in a resource file, and in KnownOIDs each element has an offset/length pair that point to its DER encoding. Also, whatever cache mechanism we use in the future, I suggest making "new ObjectIdentifier(String)" private and keep "ObjectIdentifier of(String)". SecurityProviderConstants.java ------------------------------ public static List alias(String ... aliases) { return Arrays.asList(aliases); } Probably not necessary, you can simply call List.of(...) everywhere. SunMSCAPI.java -------------- Why not call getAliases() inside "new ProviderService" like in the other providers? Same in UCrypto. AlgorithmId.java ---------------- algOID(String). You don't check "if (name.indexOf('.') != -1)" at the beginning anymore. Is there an algorithm name containing "."? It's a pity we have to collect OIDs from other providers. Maybe it should only be necessary when we use that provider, for example, when encoding a signature, we should ask the provider about the OID. I wish there were a Signature::getAlgorithmId, but if not, maybe we can rename Algorithm::alfOID(name) to Algorithm::alfOID(name, provider). Do you know a bad case if we don't collect those OIDs? It must be some algorithm that is not in the Standard Names. Overall I think the change looks great, and we have a single place to store all OIDs. The mapping among the OID string, KnownOIDs, and ObjectIdentifier could be enhanced. Do you have a benchmark? Thanks, Max > On Apr 30, 2020, at 6:59 AM, Valerie Peng wrote: > > Here is the updated webrev http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/ From weijun.wang at oracle.com Fri May 1 13:16:19 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 1 May 2020 21:16:19 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> Message-ID: One more thing: In KnownOIDs.java, I found these 2 lines: PKIX_KP_BASE("1.3.6.1.5.5.7.3."), PKIX_OCSP_BASE("1.3.6.1.5.5.7.48."), IMHO, they should not belong here, at least, we should remove the dot at the end and make them real OIDs. I was testing the ObjectIdentifier generation and notice these two. Thanks, Max > On May 1, 2020, at 5:45 PM, Weijun Wang wrote: > > ObjectIdentifier.java > --------------------- > > Have you thought about storing the ObjectIdentifier object somewhere? ObjectIdentifier.of() creates a new object each time and the conversion of string to byte[] might be a performance issue. We used to have a lot of ObjectIdentifier objects in AlgorithmId but now we only have KnownOIDs. > > I had a talk with Stuart and he has a suggestion that we can stuff all pre-calculated OID DER encodings in a long byte array in a resource file, and in KnownOIDs each element has an offset/length pair that point to its DER encoding. Also, whatever cache mechanism we use in the future, I suggest making "new ObjectIdentifier(String)" private and keep "ObjectIdentifier of(String)". > > SecurityProviderConstants.java > ------------------------------ > > public static List alias(String ... aliases) { > return Arrays.asList(aliases); > } > > Probably not necessary, you can simply call List.of(...) everywhere. > > SunMSCAPI.java > -------------- > > Why not call getAliases() inside "new ProviderService" like in the other providers? Same in UCrypto. > > AlgorithmId.java > ---------------- > > algOID(String). You don't check "if (name.indexOf('.') != -1)" at the beginning anymore. Is there an algorithm name containing "."? > > It's a pity we have to collect OIDs from other providers. Maybe it should only be necessary when we use that provider, for example, when encoding a signature, we should ask the provider about the OID. I wish there were a Signature::getAlgorithmId, but if not, maybe we can rename Algorithm::alfOID(name) to Algorithm::alfOID(name, provider). > > Do you know a bad case if we don't collect those OIDs? It must be some algorithm that is not in the Standard Names. > > Overall I think the change looks great, and we have a single place to store all OIDs. The mapping among the OID string, KnownOIDs, and ObjectIdentifier could be enhanced. Do you have a benchmark? > > Thanks, > Max > > >> On Apr 30, 2020, at 6:59 AM, Valerie Peng wrote: >> >> Here is the updated webrev http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/ > From hai-may.chao at oracle.com Fri May 1 16:02:18 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 1 May 2020 09:02:18 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> Message-ID: <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> Hi, With small change added to ?Usages.java' test, here is the updated webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ Thanks, Hai-May > On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: > > Hi, > > I?d like to request a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 > CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 > Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ > > The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. > > Thanks, > Hai-May > > > From RAJAN.HALADE at ORACLE.COM Fri May 1 17:53:11 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Fri, 1 May 2020 10:53:11 -0700 Subject: RFR: 8225069: Remove Comodo root certificate that is expiring in May 2020 Message-ID: <2BDE6A72-E6B0-4E0F-8212-CD3F6BA13B07@ORACLE.COM> Please review this fix to remove expiring Comodo root CA ?AddTrust Class 1 CA Root?. Other two, AddTrust Qualified CA Root and AddTrust External CA Root, will remain since there are code signing certificates issued from those. Webrev: http://cr.openjdk.java.net/~rhalade/8225069/webrev.00/ Thanks, Rajan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 1 18:07:27 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 May 2020 14:07:27 -0400 Subject: RFR: 8225069: Remove Comodo root certificate that is expiring in May 2020 In-Reply-To: <2BDE6A72-E6B0-4E0F-8212-CD3F6BA13B07@ORACLE.COM> References: <2BDE6A72-E6B0-4E0F-8212-CD3F6BA13B07@ORACLE.COM> Message-ID: <6fe089db-0ced-ec2f-c9d0-c7fcb36e829f@oracle.com> Looks good. --Sean On 5/1/20 1:53 PM, Rajan Halade wrote: > Please review this fix to remove expiring Comodo root CA ?AddTrust Class > 1 CA Root?. Other two, AddTrust Qualified CA Root and AddTrust External > CA Root, will remain since there are code signing certificates issued > from those. > > Webrev: http://cr.openjdk.java.net/~rhalade/8225069/webrev.00/ > > Thanks, > Rajan > From anthony.scarpino at oracle.com Fri May 1 18:32:21 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 1 May 2020 11:32:21 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <0860fcd8-9cb7-7041-a448-7db3bc709224@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <0860fcd8-9cb7-7041-a448-7db3bc709224@oracle.com> Message-ID: <0fc2b585-4c5b-7d7f-65c6-2ec468455077@oracle.com> On 4/28/20 5:58 PM, Bradford Wetmore wrote: > Hi Tony, > > Apologies for the delay. > > > I updated the webrev with some minor updates that were commented > > previously. > > > > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.01/ > > I've finished the APIs and a fair chunk of the implementation, but had > some initial comments. > > Overall, the APIs look reasonable and I (or whoever) should have no > problems adding TLS support for EdDSA once this is in place. > > ??? https://bugs.openjdk.java.net/browse/JDK-8166596 > > BTW, I reviewed based off the webrev.01 version (above), but I found in > a later email exchange there was mention of a .04: > > > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.04/ > > dated April 1.? I'm hoping that was just a proposed change idea, and not > a new version to review.? Please advise if so. > > In my comments below, if I say "you" below, it's the colloquial "you." > Could be you or the previous engineer. > > If some of these questions have already been answered, I'll apologize in > advance. I'm getting up to speed in RFC 8032 specifics so forgive any > "duh" questions. > > ---- > > Common:? Throughout the API's, I noticed multiple minor javadoc > style issues, such as: > > ??? . periods inconsistencies (missing or extras) (e.g.? EdECPoint) > ??? . omissions of @code (e.g. EdDSAParameterSpec/EdECPoint/etc.) > > Suggest a javadoc sweep before final CSR.? I started calling them out, > but stopped. > > For keysize in things like KeyPairGenerator, why are we using 255/448 > (externally and internally) instead of 256/456?? From RFC 8032: > > ??? section 3.2:? "An EdDSA private key is a b-bit string k" > + > ??? section 5.1.5/Ed25519:? "The private key is 32 octets (256 bits, > ??? corresponding to b) of cryptographically secure random data..." > ??? section 5.2.5/Ed448:? "The private key is 57 octets (456 bits, > ??? corresponding to b) of cryptographically secure random data..." > > and > > ??? section 3, parameter 2: "EdDSA public keys have exactly b bits" > and > ??? section 5.1:? "(parameter) b: 256" > ??? section 5.2:? "(parameter) b: 456" > > The Wikipedia entry also lists as 256.? https://en.wikipedia.org/wiki/EdDSA > > I notice BC does actually use both. > > https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L365 > > https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L371 I have no answer why 255 and 448 are stored, but changing them breaks the underlying implementation. If a problem occurs where we need 256 & 456, it can be addressed in a different way. > > > Why did you decide to not use the full algorithm names for the variants > e.g. > Ed25519ctx/Ed25519ph/Ed448ph instead of just Ed25519/Ed448 and let the > selection be done using the Parameters.? More for my understanding than > an issue. The variants are not the normal case it would seem. Even the spec hints at this. I suspect Adam didn't want to create all these algorithm names just for a few variations. I can understand the logic. If a parameter spec can address them, why not. The base is Ed25519/Ed448. > > Also, I thing you and Max might have discussed EdDSA vs EDDSA (case), > but in a different context.? RFC 8410/Section 8, the full names are > "EdDSA"/"Ed25519"/"Ed448", > but you're using "EDDSA"/"ED25519"/"ED448". > There is precedence for upper/lower case in our Java Standard Names. > https://docs.oracle.com/en/java/javase/14/docs/specs/security/standard-names.html > , so just wondering why you're standardizing on the upper case variant? That is the plan. The reviews you were looking at hadn't fixed that entirely. > > Is Ed448ph working?? I've been playing with your test vectors from RFC > 8032 in test/jdk/sun/security/ec/ed/TestEdDSA.java, where you included > Ed25519/Ed25519ctx/Ed25519ph, but omitted several (6 of 9) of the Ed448 > tests and all of the Ed448ph tests. I tried very quickly to add the two > Ed448ph tests in in section 7.5, but no luck.? Could be pilot error, but > I tried a lot of different combos (with/without ph boolean, null array > vs. empty array, etc), but seems like it should have been > straightforward given the test framework. See comments below > > > Specific file comments: > > make/jdk/src/classes/build/tools/intpoly/FieldGen.java > -------------------------------------------- > Lines 643-650 are creating a bunch of comment like this which are > the BigInteger values used later: > > > //(0%nat,16110573)::(26%nat,10012311)::(52%nat,30238081)::(78%nat,-8746018)::(104%nat,1367802)::nil. > > > but what is the format of comment expressing?? What ae %nat/nil/::/etc. I do not know. That file is used to create the Interpolynomial files. It's probably a comment that explains what is created using the constant time code. I have not had to run this file. > > src/java.base/share/classes/java/security/spec/NamedParameterSpec.java > -------------------------------------------- > 94: This never seems to be called in our main test suite, so not sure > why this is here.? Please add a comment as to why you added this new > no-args constructor.? (was it some Class.newInstance() somewhere/prevent > unexpected object creation/some kind of reflection?) > > Minor nit, you could put this constructor above the other constructor, > it gets kind of lost here visually. It may have been created when I was trying different ideas for the CSR for potentially subclassing the EdDSA algorithm parameter spec. I deleted it > > src/java.base/share/classes/sun/security/pkcs/PKCS7.java > -------------------------------------------- > 832:? Seems like the right thing to do for making things bulletproof. > You're convinced this shouldn't happen in our code somewhere?? (i.e. > unexpected new failure?) The method in question reads the algorithm string searching for "with". There is no "with" here in the algorithm string. The digest is internal part of the algorithm and not interchangeable like the other Signatures. Finally ED448's digest algorithm is SHAKE256, which we do not have a standard name for nor support in a provider. Max was ok with this decision. > > src/java.base/share/classes/sun/security/provider/SHA3.java > -------------------------------------------- > I see what you did here and made 0x06 a parameter in each of the > implementation classes, but wondering why?? Is there another change I > haven't gotten to yet? SHAKE256.java > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java > > -------------------------------------------- > 74:? Why 255 and not 256?? (See comment above) > > src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java > > -------------------------------------------- > OK - I didn't check the math closely in this package, but the > refactoring looks reasonable. > > src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java > -------------------------------------------- > 47:? Do you want to mention a new copy of the array is returned here? > You do say this in the spec version, and we do in the XECPrivateKey > interface. I'm changing this for consistency with XECPrivateKey. Personally I'm not in favor of interfaces with this sort of requirement and think it's up to the underlying implementation. If there is a situation where you don't want the copy, now the spec is in conflict. I don't have an example where this would happen, I just feel it's over-specifying the interface. When you get to Signature.getParameters(), and the follow-on bug & CSR to fix that, you may understand why I say this. > > 48:? @code the Optional. > > 53:? Might suggest reworking this to mention the Optional, since it is > actually the return type.? See XECPrivatekey for an example. Ok for both > > src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java > ------------------------------------------ > 47:? @code the EdECPoint. Ok > > src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java > -------------------------------------------- > Do you want to include checks/restrictions for contexts > 255 chars? Sure > > 52/65:? @code the EdDSAParameterSpec ok > > 92:? "...bound to the signature" sounds premature.? This is the context > bound to the EdDSAParameteerSpec, which hasn't been yet bound to the > signature. ok > > 94:? The word "empty" here seems overloaded between empty arrays which > are array objects with no elements, and empty Optionals which are > Optionals with no values which would later throw a > NoSuchElementException on a get().? Wondering if there is a better way > to say this to not cause confusion? Maybe saying this is an "empty > Optional?" I just put Optional in front of it, I think that makes is clear. I know it can get confusing with null and empty. > > src/java.base/share/classes/java/security/spec/EdECPrivateKeySpec.java > -------------------------------------------- > 33:? Same comment about representation as above. Sorry, I don't understand. What above comment about representation? > > test/jdk/sun/security/ec/ed/TestEdDSA.java > -------------------------------------------- > 40:? Should not need this kind of SecureRandom initialization anymore. > Remove the seed byte array. ok > > 51:? Please add some comments in here to indicate that these are the > test vectors from RFC 8032, so that folks can mentally map if they so > choose. I put it in the @summary > > 194:? Comment is above, but more details here.? All of the test vectors > were included to this point, then it just stopped after 3 Ed448 tests, > leaving out 6 of 9 tests, including all of the Ed448ph tests.? RFC pages > 32-39.? Intentional? I did try to stick in the two Ed448ph tests from > 7.5, and it failed, so maybe I'm missing something? That's a really good catch.. I do not know why he did that, Adam said all the tests passed, so I didn't have reason to go back and make sure all the tests from the RFC were include. I do not know why he implemented about half of them. After I added the tests I saw the Ed448ph fail too. Took me a while to finally fine out that the code was using on the message SHAKE256 with a length of 114 instead of a length of 64. Everything is working in my workspace now. > > Thanks, I'll continue on tomorrow. Ok.. that should have happen on wednesday :) Due to the schedule I can't keep dragging this out longer. If you have them please send them to me today. Tony > > Brad > > > On 3/23/2020 11:53 AM, Anthony Scarpino wrote: >> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>> Hi >>> >>> I need a code review for the EdDSA support in JEP 339.? The code >>> builds on the existing java implemented constant time classes used >>> for XDH and the NIST curves.? The change also adds classes to the >>> public API to support EdDSA operations. >>> >>> All information about the JEP is located at: >>> JEP 339: https://bugs.openjdk.java.net/browse/JDK-8199231 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8190219 >>> >>> webrev: https://cr.openjdk.java.net/~ascarpino/8166597/webrev/ >>> >>> thanks >>> >>> Tony > From sean.mullan at oracle.com Fri May 1 18:50:20 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 1 May 2020 14:50:20 -0400 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> Message-ID: <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> * Main.java: 2067 Event.setReportListener(new Event.Reporter() { 2068 @Override 2069 public void handle(String t, Object... o) { 2070 System.out.println(String.format(rb.getString(t), o)); 2071 } 2072 }); I think you could use a lambda expression above. * Event.java: 35 static Reporter reporter = null; Make this private? Also, no need to explicitly initialize to null as that is the default value. Can you add some comments at the top of the class describing the purpose of this class? * EnableRevocation.java - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. --Sean On 5/1/20 12:02 PM, Hai-May Chao wrote: > Hi, > > With small change added to ?Usages.java' test, here is the updated webrev: > > https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ > > Thanks, > Hai-May > >> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >> >> Hi, >> >> I?d like to request a review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >> >> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >> >> Thanks, >> Hai-May >> >> >> > From valerie.peng at oracle.com Fri May 1 22:29:58 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 1 May 2020 15:29:58 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> Message-ID: <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> These two BASE ones are simply used to get rid of the hardcoded oid string code in keytool/Main.java. I can remove them (in webrev.02) and maybe you can update keytool/Main.java later to use the right KnownOIDs enum for oid construction? There are a few places in keytool/Main.java which can be updated to use the enum KnownOIDs, but that's a bit far from the main purpose of this RFE. Thanks, Valerie On 5/1/2020 6:16 AM, Weijun Wang wrote: > One more thing: > > In KnownOIDs.java, I found these 2 lines: > > PKIX_KP_BASE("1.3.6.1.5.5.7.3."), > PKIX_OCSP_BASE("1.3.6.1.5.5.7.48."), > > IMHO, they should not belong here, at least, we should remove the dot at the end and make them real OIDs. > > I was testing the ObjectIdentifier generation and notice these two. > > Thanks, > Max > > >> On May 1, 2020, at 5:45 PM, Weijun Wang wrote: >> >> ObjectIdentifier.java >> --------------------- >> >> Have you thought about storing the ObjectIdentifier object somewhere? ObjectIdentifier.of() creates a new object each time and the conversion of string to byte[] might be a performance issue. We used to have a lot of ObjectIdentifier objects in AlgorithmId but now we only have KnownOIDs. >> >> I had a talk with Stuart and he has a suggestion that we can stuff all pre-calculated OID DER encodings in a long byte array in a resource file, and in KnownOIDs each element has an offset/length pair that point to its DER encoding. Also, whatever cache mechanism we use in the future, I suggest making "new ObjectIdentifier(String)" private and keep "ObjectIdentifier of(String)". >> >> SecurityProviderConstants.java >> ------------------------------ >> >> public static List alias(String ... aliases) { >> return Arrays.asList(aliases); >> } >> >> Probably not necessary, you can simply call List.of(...) everywhere. >> >> SunMSCAPI.java >> -------------- >> >> Why not call getAliases() inside "new ProviderService" like in the other providers? Same in UCrypto. >> >> AlgorithmId.java >> ---------------- >> >> algOID(String). You don't check "if (name.indexOf('.') != -1)" at the beginning anymore. Is there an algorithm name containing "."? >> >> It's a pity we have to collect OIDs from other providers. Maybe it should only be necessary when we use that provider, for example, when encoding a signature, we should ask the provider about the OID. I wish there were a Signature::getAlgorithmId, but if not, maybe we can rename Algorithm::alfOID(name) to Algorithm::alfOID(name, provider). >> >> Do you know a bad case if we don't collect those OIDs? It must be some algorithm that is not in the Standard Names. >> >> Overall I think the change looks great, and we have a single place to store all OIDs. The mapping among the OID string, KnownOIDs, and ObjectIdentifier could be enhanced. Do you have a benchmark? >> >> Thanks, >> Max >> >> >>> On Apr 30, 2020, at 6:59 AM, Valerie Peng wrote: >>> >>> Here is the updated webrev http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/ From valerie.peng at oracle.com Fri May 1 22:45:20 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 1 May 2020 15:45:20 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> Message-ID: <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Hmm, I took a shot at keytool/Main.java and used KnownOIDs.findMatch(...) to construct the oid. They will be included in webrev.02. Thanks, Valerie On 5/1/2020 3:29 PM, Valerie Peng wrote: > > These two BASE ones are simply used to get rid of the hardcoded oid > string code in keytool/Main.java. > > I can remove them (in webrev.02) and maybe you can update > keytool/Main.java later to use the right KnownOIDs enum for oid > construction? There are a few places in keytool/Main.java which can be > updated to use the enum KnownOIDs, but that's a bit far from the main > purpose of this RFE. > > Thanks, > Valerie > On 5/1/2020 6:16 AM, Weijun Wang wrote: >> One more thing: >> >> In KnownOIDs.java, I found these 2 lines: >> >> ???? PKIX_KP_BASE("1.3.6.1.5.5.7.3."), >> ???? PKIX_OCSP_BASE("1.3.6.1.5.5.7.48."), >> >> IMHO, they should not belong here, at least, we should remove the dot >> at the end and make them real OIDs. >> >> I was testing the ObjectIdentifier generation and notice these two. >> >> Thanks, >> Max >> >> >>> On May 1, 2020, at 5:45 PM, Weijun Wang wrote: >>> >>> ObjectIdentifier.java >>> --------------------- >>> >>> Have you thought about storing the ObjectIdentifier object >>> somewhere? ObjectIdentifier.of() creates a new object each time and >>> the conversion of string to byte[] might be a performance issue. We >>> used to have a lot of ObjectIdentifier objects in AlgorithmId but >>> now we only have KnownOIDs. >>> >>> I had a talk with Stuart and he has a suggestion that we can stuff >>> all pre-calculated OID DER encodings in a long byte array in a >>> resource file, and in KnownOIDs each element has an offset/length >>> pair that point to its DER encoding. Also, whatever cache mechanism >>> we use in the future, I suggest making "new >>> ObjectIdentifier(String)" private and keep "ObjectIdentifier >>> of(String)". >>> >>> SecurityProviderConstants.java >>> ------------------------------ >>> >>> ??? public static List alias(String ... aliases) { >>> ??????? return Arrays.asList(aliases); >>> ??? } >>> >>> Probably not necessary, you can simply call List.of(...) everywhere. >>> >>> SunMSCAPI.java >>> -------------- >>> >>> Why not call getAliases() inside "new ProviderService" like in the >>> other providers? Same in UCrypto. >>> >>> AlgorithmId.java >>> ---------------- >>> >>> algOID(String). You don't check "if (name.indexOf('.') != -1)" at >>> the beginning anymore. Is there an algorithm name containing "."? >>> >>> It's a pity we have to collect OIDs from other providers. Maybe it >>> should only be necessary when we use that provider, for example, >>> when encoding a signature, we should ask the provider about the OID. >>> I wish there were a Signature::getAlgorithmId, but if not, maybe we >>> can rename Algorithm::alfOID(name) to Algorithm::alfOID(name, >>> provider). >>> >>> Do you know a bad case if we don't collect those OIDs? It must be >>> some algorithm that is not in the Standard Names. >>> >>> Overall I think the change looks great, and we have a single place >>> to store all OIDs. The mapping among the OID string, KnownOIDs, and >>> ObjectIdentifier could be enhanced. Do you have a benchmark? >>> >>> Thanks, >>> Max >>> >>> >>>> On Apr 30, 2020, at 6:59 AM, Valerie Peng >>>> wrote: >>>> >>>> Here is the updated webrev >>>> http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/ From bradford.wetmore at oracle.com Sat May 2 01:21:48 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 1 May 2020 18:21:48 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <0fc2b585-4c5b-7d7f-65c6-2ec468455077@oracle.com> References: <0361ab57-3265-5584-30af-58ceca429ac7@oracle.com> <0860fcd8-9cb7-7041-a448-7db3bc709224@oracle.com> <0fc2b585-4c5b-7d7f-65c6-2ec468455077@oracle.com> Message-ID: >> For keysize in things like KeyPairGenerator, why are we using 255/448 >> (externally and internally) instead of 256/456?? From RFC 8032: >> >> ???? section 3.2:? "An EdDSA private key is a b-bit string k" >> + >> ???? section 5.1.5/Ed25519:? "The private key is 32 octets (256 bits, >> ???? corresponding to b) of cryptographically secure random data..." >> ???? section 5.2.5/Ed448:? "The private key is 57 octets (456 bits, >> ???? corresponding to b) of cryptographically secure random data..." >> >> and >> >> ???? section 3, parameter 2: "EdDSA public keys have exactly b bits" >> and >> ???? section 5.1:? "(parameter) b: 256" >> ???? section 5.2:? "(parameter) b: 456" >> >> The Wikipedia entry also lists as 256. >> https://en.wikipedia.org/wiki/EdDSA >> >> I notice BC does actually use both. >> >> https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L365 >> >> https://github.com/bcgit/bc-java/blob/master/prov/src/test/jdk1.4/org/bouncycastle/jce/provider/test/EdECTest.java#L371 > > > I have no answer why 255 and 448 are stored, but changing them breaks > the underlying implementation.? If a problem occurs where we need 256 & > 456, it can be addressed in a different way. Tony and I have talked over this offline, and we've decided we'll follow the sizings of what was done for XDH (x25519/x448 Key Exchange) which is 255/448. Further comments captured here for posterity: ---begin--- I wasn't talking changing about the internal representation, my question was more about whether the "keysize" we present to things like KeyPairGenerator should be the actual keysize in storage bits, or the "keysize" based on the p value. i.e. KeyPairGenerator kpg = KeyPairGenerator.getInstance("EdDSA"); kpg.initialize(XXX); Right now, if I call kgp.initialize(256), it fails with an j.s.IPE. Only 255 and 448 are allowed. My initial thought was that it should be the keysize representation, which would be 32/57 bytes (256/456 bits), but I can see the other way since the curve is over the fields 2^255 - 19 and 2^448 - 2^224 - 1, I am not sure what should be going here. KeyPairGenerator All key pair generators share the concepts of a keysize...The keysize is interpreted differently for different algorithms (e.g., in the case of the DSA algorithm, the keysize corresponds to the length of the modulus). void KeypairGenerator.initalize(int keysize); Initializes the key pair generator for a certain keysize keysize - the keysize. This is an algorithm-specific metric, such as modulus length, specified in number of bits. ---end--- >> Why did you decide to not use the full algorithm names for the >> variants e.g. >> Ed25519ctx/Ed25519ph/Ed448ph instead of just Ed25519/Ed448 and let the >> selection be done using the Parameters.? More for my understanding >> than an issue. > > The variants are not the normal case it would seem.? Even the spec hints > at this.? I suspect Adam didn't want to create all these algorithm names > just for a few variations.? I can understand the logic.? If a parameter > spec can address them, why not.? The base is Ed25519/Ed448. I can buy that. It's made pretty clear in the EdDSAParameterSpec how to set. >> Also, I thing you and Max might have discussed EdDSA vs EDDSA (case), >> but in a different context.? RFC 8410/Section 8, the full names are >> "EdDSA"/"Ed25519"/"Ed448", >> but you're using "EDDSA"/"ED25519"/"ED448". >> There is precedence for upper/lower case in our Java Standard Names. >> https://docs.oracle.com/en/java/javase/14/docs/specs/security/standard-names.html >> , so just wondering why you're standardizing on the upper case variant? > > That is the plan.? The reviews you were looking at hadn't fixed that > entirely. Tony/I talked further, he is going to go with the RFC naming style: EdDSA/etc. >> src/java.base/share/classes/java/security/spec/NamedParameterSpec.java >> -------------------------------------------- >> 94: This never seems to be called in our main test suite, so not sure >> why this is here.? Please add a comment as to why you added this new >> no-args constructor.? (was it some Class.newInstance() >> somewhere/prevent unexpected object creation/some kind of reflection?) >> >> Minor nit, you could put this constructor above the other constructor, >> it gets kind of lost here visually. > > It may have been created when I was trying different ideas for the CSR > for potentially subclassing the EdDSA algorithm parameter spec.? I > deleted it Thanks, I was scratching my head! ;) >> src/java.base/share/classes/sun/security/pkcs/PKCS7.java >> -------------------------------------------- >> 832:? Seems like the right thing to do for making things bulletproof. >> You're convinced this shouldn't happen in our code somewhere?? (i.e. >> unexpected new failure?) > > The method in question reads the algorithm string searching for "with". > There is no "with" here in the algorithm string. The digest is internal > part of the algorithm and not interchangeable like the other Signatures. > ?Finally ED448's digest algorithm is SHAKE256, which we do not have a > standard name for nor support in a provider.? Max was ok with this > decision. Ok. >> src/java.base/share/classes/sun/security/provider/SHA3.java >> -------------------------------------------- >> I see what you did here and made 0x06 a parameter in each of the >> implementation classes, but wondering why?? Is there another change I >> haven't gotten to yet? > > SHAKE256.java Ok, I see it now. Thanks. >> src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java >> -------------------------------------------- >> 47:? Do you want to mention a new copy of the array is returned here? >> You do say this in the spec version, and we do in the XECPrivateKey >> interface. > > I'm changing this for consistency with XECPrivateKey.? Personally I'm > not in favor of interfaces with this sort of requirement and think it's > up to the underlying implementation.? If there is a situation where you > don't want the copy, now the spec is in conflict.? I don't have an > example where this would happen, I just feel it's over-specifying the > interface. > > When you get to Signature.getParameters(), and the follow-on bug & CSR > to fix that, you may understand why I say this. Ok. >> src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java >> ------------------------------------------ > 47:? @code the EdECPoint. Just a quick reminder, there were other javadoc issues throughout. Would be good to take a pass looking at javadoc again. I only called out a few. >> src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java >> -------------------------------------------- >> Do you want to include checks/restrictions for contexts > 255 chars? > > Sure Thanks. >> 94:? The word "empty" here seems overloaded between empty arrays which >> are array objects with no elements, and empty Optionals which are >> Optionals with no values which would later throw a >> NoSuchElementException on a get().? Wondering if there is a better way >> to say this to not cause confusion? Maybe saying this is an "empty >> Optional?" > > I just put Optional in front of it, I think that makes is clear.? I know > it can get confusing with null and empty. I'll try to remember to take a look at the final version when it's ready. Not quite envisioning what you ended with. >> src/java.base/share/classes/java/security/spec/EdECPrivateKeySpec.java >> -------------------------------------------- >> 33:? Same comment about representation as above. > > Sorry, I don't understand.? What above comment about representation? My bad, I had a previous comment that I decided against making, and then forgot to remove this one. >> 51:? Please add some comments in here to indicate that these are the >> test vectors from RFC 8032, so that folks can mentally map if they so >> choose. > > I put it in the @summary That's probably close enough to where the tests are defined that folks can find the source easily. >> 194:? Comment is above, but more details here.? All of the test >> vectors were included to this point, then it just stopped after 3 >> Ed448 tests, leaving out 6 of 9 tests, including all of the Ed448ph >> tests.? RFC pages 32-39.? Intentional? I did try to stick in the two >> Ed448ph tests from 7.5, and it failed, so maybe I'm missing something? > > That's a really good catch.. I do not know why he did that, Adam said > all the tests passed, so I didn't have reason to go back and make sure > all the tests from the RFC were include. I do not know why he > implemented about half of them. > > After I added the tests I saw the Ed448ph fail too.? Took me a while to > finally fine out that the code was using on the message SHAKE256 with a > length of 114 instead of a length of 64.? Everything is working in my > workspace now. I didn't review the fix itself, but it did pass the one test in my workspace. I'll get to that soon. > >> >> Thanks, I'll continue on tomorrow. > > Ok.. that should have happen on wednesday :) Still working on them. > Due to the schedule I can't keep dragging this out longer.? If you have > them please send them to me today. I'll see if I can get some more time over the weekend. The APIs are ok with me tho, given what we talked about. I'm down in the impl code at this point, which can be fixed later if issues arise. Thanks, Brad From weijun.wang at oracle.com Sat May 2 02:49:45 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 2 May 2020 10:49:45 +0800 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> Message-ID: <6D9531FD-0B27-4497-A459-500EAC9AA2BE@oracle.com> > > * EnableRevocation.java > > - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. What if we use 0.0.0.0 for both OCSP and CRLDP? I assume it will return immediately, just hope it's not an uncaught RuntimeException. --Max > > Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. > > --Sean > > On 5/1/20 12:02 PM, Hai-May Chao wrote: >> Hi, >> With small change added to ?Usages.java' test, here is the updated webrev: >> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >> Thanks, >> Hai-May >>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>> >>> Hi, >>> >>> I?d like to request a review for: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>> >>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>> >>> Thanks, >>> Hai-May >>> >>> >>> From Alan.Bateman at oracle.com Sat May 2 14:30:03 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 2 May 2020 15:30:03 +0100 Subject: 8244281: test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java fails with --illegal-access=deny Message-ID: <5e010de8-6b4f-d30c-b6b8-b58ae378936f@oracle.com> I need a reviewer for a small update to test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java. The test accesses a private field in com.sun.crypto.provider from a VM launched by the test. The launched VM needs to be run with --add-open to open the package, otherwise the test will fail when illegal reflective access is denied by default. -Alan. diff -r 104385e30663 test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java --- a/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java Sat May 02 09:00:04 2020 +0530 +++ b/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java Sat May 02 15:26:58 2020 +0100 @@ -88,6 +88,7 @@ ???? private static void executeCommand(List cmd, String expectedCount) ???????????? throws Throwable { + cmd.add("--add-opens=java.base/com.sun.crypto.provider=ALL-UNNAMED"); ???????? cmd.add(IterationCount.class.getName()); ???????? cmd.add(clientStr); ???????? cmd.add(expectedCount); From weijun.wang at oracle.com Sat May 2 14:49:01 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 2 May 2020 22:49:01 +0800 Subject: 8244281: test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java fails with --illegal-access=deny In-Reply-To: <5e010de8-6b4f-d30c-b6b8-b58ae378936f@oracle.com> References: <5e010de8-6b4f-d30c-b6b8-b58ae378936f@oracle.com> Message-ID: <481D5677-F2C0-483E-A512-5CA2AC85010A@oracle.com> The change looks fine to me. Thanks, Max > On May 2, 2020, at 10:30 PM, Alan Bateman wrote: > > > I need a reviewer for a small update to test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java. The test accesses a private field in com.sun.crypto.provider from a VM launched by the test. The launched VM needs to be run with --add-open to open the package, otherwise the test will fail when illegal reflective access is denied by default. > > -Alan. > > diff -r 104385e30663 test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java > --- a/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java Sat May 02 09:00:04 2020 +0530 > +++ b/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java Sat May 02 15:26:58 2020 +0100 > @@ -88,6 +88,7 @@ > > private static void executeCommand(List cmd, String expectedCount) > throws Throwable { > + cmd.add("--add-opens=java.base/com.sun.crypto.provider=ALL-UNNAMED"); > cmd.add(IterationCount.class.getName()); > cmd.add(clientStr); > cmd.add(expectedCount); From xuelei.fan at oracle.com Sat May 2 15:28:30 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 2 May 2020 08:28:30 -0700 Subject: 8244281: test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java fails with --illegal-access=deny In-Reply-To: <5e010de8-6b4f-d30c-b6b8-b58ae378936f@oracle.com> References: <5e010de8-6b4f-d30c-b6b8-b58ae378936f@oracle.com> Message-ID: Looks good to me. Thanks, Xuelei On 5/2/2020 7:30 AM, Alan Bateman wrote: > > I need a reviewer for a small update to > test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java. The > test accesses a private field in com.sun.crypto.provider from a VM > launched by the test. The launched VM needs to be run with --add-open to > open the package, otherwise the test will fail when illegal reflective > access is denied by default. > > -Alan. > > diff -r 104385e30663 > test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java > --- a/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java > Sat May 02 09:00:04 2020 +0530 > +++ b/test/jdk/com/sun/crypto/provider/KeyProtector/IterationCount.java > Sat May 02 15:26:58 2020 +0100 > @@ -88,6 +88,7 @@ > > ???? private static void executeCommand(List cmd, String > expectedCount) > ???????????? throws Throwable { > + cmd.add("--add-opens=java.base/com.sun.crypto.provider=ALL-UNNAMED"); > ???????? cmd.add(IterationCount.class.getName()); > ???????? cmd.add(clientStr); > ???????? cmd.add(expectedCount); From hai-may.chao at oracle.com Sat May 2 18:19:02 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Sat, 2 May 2020 11:19:02 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> Message-ID: <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> Hi Sean, Thanks for your review. Reply inline. > On May 1, 2020, at 11:50 AM, Sean Mullan wrote: > > * Main.java: > > 2067 Event.setReportListener(new Event.Reporter() { > 2068 @Override > 2069 public void handle(String t, Object... o) { > 2070 System.out.println(String.format(rb.getString(t), o)); > 2071 } > 2072 }); > > I think you could use a lambda expression above. Done. > > * Event.java: > > 35 static Reporter reporter = null; > > Make this private? Also, no need to explicitly initialize to null as that is the default value. Done (made it private). > > Can you add some comments at the top of the class describing the purpose of this class? Done. > > * EnableRevocation.java > > - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. > > Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. Done (Release note: JDK-8244285, and man page: JDK-8244274). Updated webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ Thanks, Hai-May > > --Sean > > On 5/1/20 12:02 PM, Hai-May Chao wrote: >> Hi, >> With small change added to ?Usages.java' test, here is the updated webrev: >> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >> Thanks, >> Hai-May >>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>> >>> Hi, >>> >>> I?d like to request a review for: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>> >>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>> >>> Thanks, >>> Hai-May >>> >>> >>> From hai-may.chao at oracle.com Sat May 2 18:20:32 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Sat, 2 May 2020 11:20:32 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <6D9531FD-0B27-4497-A459-500EAC9AA2BE@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <6D9531FD-0B27-4497-A459-500EAC9AA2BE@oracle.com> Message-ID: <5ABF3E99-8DBD-47D2-8CE9-E13D4515E124@oracle.com> Thanks Max! Using localhost would do it as well. Hai-May > On May 1, 2020, at 7:49 PM, Weijun Wang wrote: > >> >> * EnableRevocation.java >> >> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. > > What if we use 0.0.0.0 for both OCSP and CRLDP? I assume it will return immediately, just hope it's not an uncaught RuntimeException. > > --Max > >> >> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >> >> --Sean >> >> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>> Hi, >>> With small change added to ?Usages.java' test, here is the updated webrev: >>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>> Thanks, >>> Hai-May >>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>> >>>> Hi, >>>> >>>> I?d like to request a review for: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>> >>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>> > From weijun.wang at oracle.com Sun May 3 00:25:57 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 3 May 2020 08:25:57 +0800 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> Message-ID: In jarsigner/Main, you can just call pkixParameters.setRevocationEnabled(revocationCheck); Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. Thanks, Max > On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: > > Hi Sean, > > Thanks for your review. Reply inline. > >> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >> >> * Main.java: >> >> 2067 Event.setReportListener(new Event.Reporter() { >> 2068 @Override >> 2069 public void handle(String t, Object... o) { >> 2070 System.out.println(String.format(rb.getString(t), o)); >> 2071 } >> 2072 }); >> >> I think you could use a lambda expression above. > > Done. > >> >> * Event.java: >> >> 35 static Reporter reporter = null; >> >> Make this private? Also, no need to explicitly initialize to null as that is the default value. > > Done (made it private). > >> >> Can you add some comments at the top of the class describing the purpose of this class? > > Done. > >> >> * EnableRevocation.java >> >> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. > > It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. > >> >> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. > > Done (Release note: JDK-8244285, and man page: JDK-8244274). > > Updated webrev: > https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ > > Thanks, > Hai-May > > >> >> --Sean >> >> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>> Hi, >>> With small change added to ?Usages.java' test, here is the updated webrev: >>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>> Thanks, >>> Hai-May >>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>> >>>> Hi, >>>> >>>> I?d like to request a review for: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>> >>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>> > From mikael.vidstedt at oracle.com Mon May 4 05:12:12 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 3 May 2020 22:12:12 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) Message-ID: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> Please review this change which implements part of JEP 381: JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! Background: Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. Testing: A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. Cheers, Mikael [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From sibabrata.sahoo at oracle.com Mon May 4 06:27:11 2020 From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com) Date: Mon, 4 May 2020 11:57:11 +0530 Subject: [15] RFR: 8242335: Additional Tests for RSASSA-PSS In-Reply-To: <61ba42dc-5492-69fe-ec3e-360d93fc6a7b@oracle.com> References: <61ba42dc-5492-69fe-ec3e-360d93fc6a7b@oracle.com> Message-ID: <9D040E41-FAAB-4352-B05A-C81DD80B0073@oracle.com> Hi Valerie, Here is the updated web rev addressing the following comments. There are 7 lines of additional change added [Line: 126-133] to re-verify the signature with another Signature instance. Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.01/ Thanks, Siba > On 01-May-2020, at 4:58 AM, Valerie Peng wrote: > > Hi, Siba, > > Here are my comments: > > > > - Typos: Initialisation -> Initialization. > > - the 2nd algorithm specific initialization using reflection doesn't seem too useful. The code path should be exactly the same as the non-reflection one. Maybe just remove it. > > Rest looks fine. > > Thanks, > Valerie > On 4/28/2020 12:38 AM, sibabrata.sahoo at oracle.com wrote: >> Hi Valerie, >> >> Please review the patch for, >> JBS: https://bugs.openjdk.java.net/browse/JDK-8242335 >> Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.00/ >> >> These are additional Tests developed to support RSASSA-PSS algorithm. One is key compatibility with OpenSSL generated while the other one is the API Tests for serialized keys. >> >> Thanks, >> Siba >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From thejasvi.v.voniadka at oracle.com Mon May 4 12:35:14 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Mon, 4 May 2020 05:35:14 -0700 (PDT) Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: References: Message-ID: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> Adding jmx-dev and security-dev. -----Original Message----- From: Thejasvi Voniadka Sent: Monday, May 4, 2020 12:56 PM To: core-libs-dev at openjdk.java.net Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE when needed. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit only the full patch to be committed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From weijun.wang at oracle.com Mon May 4 13:58:02 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 4 May 2020 21:58:02 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> Message-ID: <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> I've gone through all files. Many of them are PKCS11-related, it will be nice if Valerie can confirm my findings. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: Maybe we should not support $ISA at all? test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: Please also remove the whole else block from line 61. test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: It's not worth keeping this test. Error has never occurred on other platforms. test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: 128-135: There is no need to use a try-catch block. test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: 54-60: No need 81-97: No need. Just a single run() is OK. 101: Remove the ", p" argument test/jdk/java/security/MessageDigest/TestDigestIOStream.java: test/jdk/java/security/MessageDigest/TestSameLength.java: test/jdk/java/security/MessageDigest/TestSameValue.java: No need for isSHA3Supported(). The SUN provider should always be there. Inside the test where NoSuchAlgorithmException is caught, the catch block can be removed and no need to try test/jdk/java/security/MessageDigest/UnsupportedProvider.java: Not worth keeping this test. test/jdk/sun/security/jca/PreferredProviderTest.java: 53: remove "for other platform" test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java Remove the comments on lines 37-40 test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: Not worth keeping the tests in this directory. test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: No need for try test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: No need for this catch block test/jdk/sun/security/tools/keytool/fakegen/PSS.java: Please also remove the comment on lines 35-37. test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: Please also remove the comment on lines 36-38. Thanks, Max > On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From valerie.peng at oracle.com Mon May 4 16:29:31 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 4 May 2020 09:29:31 -0700 Subject: [15] RFR: 8242335: Additional Tests for RSASSA-PSS In-Reply-To: <9D040E41-FAAB-4352-B05A-C81DD80B0073@oracle.com> References: <61ba42dc-5492-69fe-ec3e-360d93fc6a7b@oracle.com> <9D040E41-FAAB-4352-B05A-C81DD80B0073@oracle.com> Message-ID: <721245a8-a64f-dd4f-3812-c47052763dc3@oracle.com> Updated webrev looks fine. Thanks, Valerie On 5/3/2020 11:27 PM, sibabrata.sahoo at oracle.com wrote: > Hi Valerie, > > Here is the updated web rev addressing the following comments. There > are 7 lines of additional change added [Line: 126-133] to re-verify > the signature with another Signature instance. > > Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.01/ > > Thanks, > Siba > > > >> On 01-May-2020, at 4:58 AM, Valerie Peng > > wrote: >> >> Hi, Siba, >> >> Here are my comments: >> >> >> >> - Typos: Initialisation -> Initialization. >> >> - the 2nd algorithm specific initialization using reflection doesn't >> seem too useful. The code path should be exactly the same as the >> non-reflection one. Maybe just remove it. >> >> Rest looks fine. >> >> Thanks, >> Valerie >> On 4/28/2020 12:38 AM, sibabrata.sahoo at oracle.com wrote: >>> Hi Valerie, >>> >>> Please review the patch for, >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242335 >>> Webrev: http://cr.openjdk.java.net/~ssahoo/8242335/webrev.00/ >>> >>> These are additional Tests developed to support RSASSA-PSS >>> algorithm. One is key compatibility with OpenSSL generated while the >>> other one is the API Tests for serialized keys. >>> >>> Thanks, >>> Siba >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Mon May 4 17:17:33 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 4 May 2020 10:17:33 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: References: Message-ID: <28494de4-f0b8-51a8-af89-e26b27d23ef5@oracle.com> On 2/25/20 12:49 PM, Anthony Scarpino wrote: > Hi > > I need a code review for the EdDSA support in JEP 339.? The code builds > on the existing java implemented constant time classes used for XDH and > the NIST curves.? The change also adds classes to the public API to > support EdDSA operations. > Here is the final code review for the JEP. As the JEP is preparing to move to Propose-to-Target, if you have comments please state if they must be fixed as part of the initial putback. https://cr.openjdk.java.net/~ascarpino/8166597/webrev.05/ thanks Tony From hai-may.chao at oracle.com Mon May 4 19:48:16 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Mon, 4 May 2020 12:48:16 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> Message-ID: <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> Hi Max, > On May 2, 2020, at 5:25 PM, Weijun Wang wrote: > > In jarsigner/Main, you can just call > > pkixParameters.setRevocationEnabled(revocationCheck); Ok > > Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. It is easily reproducible. I should have better explained why the suggested changes did not work but not due to race condition. The code pkixParameters.setRevocationEnabled(revocationCheck) only sets the revocation checker enabled. It is the validateCertChain() in Main.java, which calls into RevocationChecker.check() and ultimately calls Event.report() prior to making OCSP and CRL connections. If we call clearReportListener in loadKeyStore() method (i.e finally{ }as suggested), for OCSP, by the time when OCSP.getOCSPBytes() comes in to report the OCSP event, the reporter has been cleared. And this would be same problem for CRL. So it cannot be called immediately. Thanks, Hai-May > > Thanks, > Max > >> On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: >> >> Hi Sean, >> >> Thanks for your review. Reply inline. >> >>> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >>> >>> * Main.java: >>> >>> 2067 Event.setReportListener(new Event.Reporter() { >>> 2068 @Override >>> 2069 public void handle(String t, Object... o) { >>> 2070 System.out.println(String.format(rb.getString(t), o)); >>> 2071 } >>> 2072 }); >>> >>> I think you could use a lambda expression above. >> >> Done. >> >>> >>> * Event.java: >>> >>> 35 static Reporter reporter = null; >>> >>> Make this private? Also, no need to explicitly initialize to null as that is the default value. >> >> Done (made it private). >> >>> >>> Can you add some comments at the top of the class describing the purpose of this class? >> >> Done. >> >>> >>> * EnableRevocation.java >>> >>> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. >> >> It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. >> >>> >>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >> >> Done (Release note: JDK-8244285, and man page: JDK-8244274). >> >> Updated webrev: >> https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ >> >> Thanks, >> Hai-May >> >> >>> >>> --Sean >>> >>> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>>> Hi, >>>> With small change added to ?Usages.java' test, here is the updated webrev: >>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>>> Thanks, >>>> Hai-May >>>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?d like to request a review for: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>>> >>>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>> >> > From sha.jiang at oracle.com Mon May 4 23:02:17 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 5 May 2020 07:02:17 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> Message-ID: Hi, Generally, this patch doesn't take care of the solaris/sunos/ucrypto-related words in test summaries, code comments, configs and READMEs. E.g. test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java test/jdk/sun/security/provider/MessageDigest/TestSHAClone.java test/jdk/sun/security/util/Resources/Format.config test/jdk/sun/security/pkcs11/KeyStore/BasicData/README Would we need some follow-up issues to double-check this point? test/jdk/sun/security/tools/keytool/KeyToolTest.java 39?? * Testing Solaris Cryptography Framework PKCS11 keystores: 40?? *?????? # make sure you've already run pktool and set test12 as pin 41?? *?????? echo | java -Dsolaris KeyToolTest ... 1863????????????? if (System.getProperty("solaris") != null) { 1864????????????????? // For Solaris Cryptography Framework 1865????????????????? t.srcP11Arg = SUN_SRC_P11_ARG; 1866????????????????? t.p11Arg = SUN_P11_ARG; 1867????????????????? t.testPKCS11(); 1868????????????????? t.testPKCS11ImportKeyStore(); 1869????????????????? t.i18nPKCS11Test(); 1870????????????? } It may be necessary to remove the above lines. test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.policy It looks this manual test and the associated policy are solaris-related only. Could these files be removed as well? In fact, the solaris-related com.sun.security.auth classes, including SolarisPrincipal, are already removed. test/jdk/sun/security/pkcs11/tls/TestPRF.java 114????????????????????????? if (secret == null) { 115????????????????????????????? // This fails on Solaris, but since we never call this 116????????????????????????????? // API for this case in JSSE, ignore the failure. 117????????????????????????????? // (SunJSSE uses the CKM_TLS_KEY_AND_MAC_DERIVE 118????????????????????????????? // mechanism) 119????????????????????????????? System.out.print("X"); 120????????????????????????????? continue; 121????????????????????????? } Could remove this block? Best regards, John Jiang On 2020/5/4 13:12, Mikael Vidstedt wrote: > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From weijun.wang at oracle.com Tue May 5 01:01:51 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 May 2020 09:01:51 +0800 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> Message-ID: > On May 5, 2020, at 3:48 AM, Hai-May Chao wrote: > > Hi Max, > >> On May 2, 2020, at 5:25 PM, Weijun Wang wrote: >> >> In jarsigner/Main, you can just call >> >> pkixParameters.setRevocationEnabled(revocationCheck); > > Ok > >> >> Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. > > It is easily reproducible. I should have better explained why the suggested changes did not work but not due to race condition. The code pkixParameters.setRevocationEnabled(revocationCheck) only sets the revocation checker enabled. It is the validateCertChain() in Main.java, which calls into RevocationChecker.check() and ultimately calls Event.report() prior to making OCSP and CRL connections. If we call clearReportListener in loadKeyStore() method (i.e finally{ }as suggested), for OCSP, by the time when OCSP.getOCSPBytes() comes in to report the OCSP event, the reporter has been cleared. And this would be same problem for CRL. So it cannot be called immediately. Then I assume the following is OK. try { setReportListener(); validator.validate(); } finally { clearReportListener(); } Thanks, Max > > Thanks, > Hai-May > >> >> Thanks, >> Max >> >>> On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: >>> >>> Hi Sean, >>> >>> Thanks for your review. Reply inline. >>> >>>> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >>>> >>>> * Main.java: >>>> >>>> 2067 Event.setReportListener(new Event.Reporter() { >>>> 2068 @Override >>>> 2069 public void handle(String t, Object... o) { >>>> 2070 System.out.println(String.format(rb.getString(t), o)); >>>> 2071 } >>>> 2072 }); >>>> >>>> I think you could use a lambda expression above. >>> >>> Done. >>> >>>> >>>> * Event.java: >>>> >>>> 35 static Reporter reporter = null; >>>> >>>> Make this private? Also, no need to explicitly initialize to null as that is the default value. >>> >>> Done (made it private). >>> >>>> >>>> Can you add some comments at the top of the class describing the purpose of this class? >>> >>> Done. >>> >>>> >>>> * EnableRevocation.java >>>> >>>> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. >>> >>> It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. >>> >>>> >>>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >>> >>> Done (Release note: JDK-8244285, and man page: JDK-8244274). >>> >>> Updated webrev: >>> https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ >>> >>> Thanks, >>> Hai-May >>> >>> >>>> >>>> --Sean >>>> >>>> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>>>> Hi, >>>>> With small change added to ?Usages.java' test, here is the updated webrev: >>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>>>> Thanks, >>>>> Hai-May >>>>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I?d like to request a review for: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>>>> >>>>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>> >>> >> > From bradford.wetmore at oracle.com Tue May 5 01:12:54 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 4 May 2020 18:12:54 -0700 Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <28494de4-f0b8-51a8-af89-e26b27d23ef5@oracle.com> References: <28494de4-f0b8-51a8-af89-e26b27d23ef5@oracle.com> Message-ID: <5175fb0b-cdb0-b3ec-05ba-9cf3cc31d20b@oracle.com> All minor nits, can be done later if it won't be a problem to make minor API wording tweaks. On 5/4/2020 10:17 AM, Anthony Scarpino wrote: > On 2/25/20 12:49 PM, Anthony Scarpino wrote: >> Hi >> >> I need a code review for the EdDSA support in JEP 339.? The code >> builds on the existing java implemented constant time classes used for >> XDH and the NIST curves.? The change also adds classes to the public >> API to support EdDSA operations. >> > > Here is the final code review for the JEP. As the JEP is preparing to > move to Propose-to-Target, if you have comments please state if they > must be fixed as part of the initial putback. > > https://cr.openjdk.java.net/~ascarpino/8166597/webrev.05/ Javadoc issues remain throughout java.security.*. e.g. EdDCPoint @param y the y-coordinate, represented using a BigInteger -> @param y the y-coordinate, represented using a @{code BigInteger} a boolean indicating whether the x-coordinate is odd. -> a boolean indicating whether the x-coordinate is odd src/java.base/share/classes/sun/security/provider/SHA3.java ---------- 114: Is this comment about the 2-bit suffix still correct? src/java.base/share/classes/sun/security/util/KeyUtil.java ---------- 2: Copyright date. 110: Do you want to go with the hardcoded values, or fix the commented out code? src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java ---------- 38: Very minor nit: EdEC reads a bit awkward to my eye: that term isn't used in the RFC. Change or keep. Maybe: An EdEC private key -> An Edwards-Curve private key ... or An {@code EdECPrivateKey} ... Noticed some new typos, or you could do a minor replacement and reduce some of the duplicate wording. 51: the an {@code Optional} -> an {@code Optional} 52: Ff -> If Alternate idea: You could take out the second sentence in the method description above and replace the @return with: * @return the private key byte array, or an empty {@code Optional} if the * key cannot be extracted (e.g. if the provider is a hardware token * and the private key is not allowed to leave the crypto boundary). This was based on the XEC wording. Your call/choice. src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java ---------- 37: Same comment about EdEC. Change or keep. src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java ---------- 92: Repeat of previous comment from last week. You replied "Ok" but didn't see a change yet. "...bound to the signature" sounds premature. This is the context bound to the EdDSAParameteerSpec, which hasn't been yet bound to the signature. src/java.base/share/classes/java/security/spec/EdECPoint.java ---------- 38: Same comment about EdEC. Change or keep. test/jdk/sun/security/ec/ed/TestEdDSA.java ---------- Nits: 211-212: Indention problem 159/257/258/301: Extra whitespace. 313: The context value was set correctly from a previous test, but wouldn't hurt to reiterate it here. Brad From weijun.wang at oracle.com Tue May 5 01:24:00 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 May 2020 09:24:00 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Message-ID: Do you want to add OIDs in CurveDB into KnownOIDs as well? Thanks, Max From mbalao at redhat.com Tue May 5 03:58:08 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 5 May 2020 00:58:08 -0300 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> Message-ID: Hi Max, On 3/30/20 5:24 PM, Martin Balao wrote: > > CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 > Now that the CSR has been approved, are we good to push? Thanks, Martin.- From hai-may.chao at oracle.com Tue May 5 04:36:56 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Mon, 4 May 2020 21:36:56 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> Message-ID: <5B636E18-36FE-4500-89A6-F32A17499E59@oracle.com> > On May 4, 2020, at 6:01 PM, Weijun Wang wrote: > > > >> On May 5, 2020, at 3:48 AM, Hai-May Chao wrote: >> >> Hi Max, >> >>> On May 2, 2020, at 5:25 PM, Weijun Wang wrote: >>> >>> In jarsigner/Main, you can just call >>> >>> pkixParameters.setRevocationEnabled(revocationCheck); >> >> Ok >> >>> >>> Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. >> >> It is easily reproducible. I should have better explained why the suggested changes did not work but not due to race condition. The code pkixParameters.setRevocationEnabled(revocationCheck) only sets the revocation checker enabled. It is the validateCertChain() in Main.java, which calls into RevocationChecker.check() and ultimately calls Event.report() prior to making OCSP and CRL connections. If we call clearReportListener in loadKeyStore() method (i.e finally{ }as suggested), for OCSP, by the time when OCSP.getOCSPBytes() comes in to report the OCSP event, the reporter has been cleared. And this would be same problem for CRL. So it cannot be called immediately. > > Then I assume the following is OK. > > try { > setReportListener(); > validator.validate(); > } finally { > clearReportListener(); > } > I?d like to know if there is an issue with the current webrev, which is being tested and it?s working as expected. I?ve also tried with your previous suggested change, and it didn?t work. Thanks, Hai-May > Thanks, > Max > >> >> Thanks, >> Hai-May >> >>> >>> Thanks, >>> Max >>> >>>> On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: >>>> >>>> Hi Sean, >>>> >>>> Thanks for your review. Reply inline. >>>> >>>>> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >>>>> >>>>> * Main.java: >>>>> >>>>> 2067 Event.setReportListener(new Event.Reporter() { >>>>> 2068 @Override >>>>> 2069 public void handle(String t, Object... o) { >>>>> 2070 System.out.println(String.format(rb.getString(t), o)); >>>>> 2071 } >>>>> 2072 }); >>>>> >>>>> I think you could use a lambda expression above. >>>> >>>> Done. >>>> >>>>> >>>>> * Event.java: >>>>> >>>>> 35 static Reporter reporter = null; >>>>> >>>>> Make this private? Also, no need to explicitly initialize to null as that is the default value. >>>> >>>> Done (made it private). >>>> >>>>> >>>>> Can you add some comments at the top of the class describing the purpose of this class? >>>> >>>> Done. >>>> >>>>> >>>>> * EnableRevocation.java >>>>> >>>>> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. >>>> >>>> It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. >>>> >>>>> >>>>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >>>> >>>> Done (Release note: JDK-8244285, and man page: JDK-8244274). >>>> >>>> Updated webrev: >>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ >>>> >>>> Thanks, >>>> Hai-May >>>> >>>> >>>>> >>>>> --Sean >>>>> >>>>> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>>>>> Hi, >>>>>> With small change added to ?Usages.java' test, here is the updated webrev: >>>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>>>>> Thanks, >>>>>> Hai-May >>>>>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I?d like to request a review for: >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>>>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>>>>> >>>>>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>>>>> >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>> >>>>>>> >>>>>>> >>>> >>> >> > From weijun.wang at oracle.com Tue May 5 05:01:58 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 May 2020 13:01:58 +0800 Subject: RFR 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: References: <59502395-9f82-36cb-434b-395e4d405e60@redhat.com> <47E67F43-220E-4FD2-A70D-D7666AF1C91F@oracle.com> <5a56bb03-42c7-74af-8a73-228803209ece@redhat.com> <5e4d1d7a-22f0-8f89-04de-acf1e5d14482@redhat.com> Message-ID: <3A813426-0057-4658-B563-B0A56D15ED4C@oracle.com> Yes, please. Thanks, Max > On May 5, 2020, at 11:58 AM, Martin Balao wrote: > > Hi Max, > > On 3/30/20 5:24 PM, Martin Balao wrote: >> >> CSR requested here: https://bugs.openjdk.java.net/browse/JDK-8241871 >> > > Now that the CSR has been approved, are we good to push? > > Thanks, > Martin.- > From weijun.wang at oracle.com Tue May 5 05:23:04 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 May 2020 13:23:04 +0800 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <5B636E18-36FE-4500-89A6-F32A17499E59@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> <5B636E18-36FE-4500-89A6-F32A17499E59@oracle.com> Message-ID: <479400DE-EB77-42F5-BFEA-5937610EAD27@oracle.com> > On May 5, 2020, at 12:36 PM, Hai-May Chao wrote: > > > >> On May 4, 2020, at 6:01 PM, Weijun Wang wrote: >> >> >> >>> On May 5, 2020, at 3:48 AM, Hai-May Chao wrote: >>> >>> Hi Max, >>> >>>> On May 2, 2020, at 5:25 PM, Weijun Wang wrote: >>>> >>>> In jarsigner/Main, you can just call >>>> >>>> pkixParameters.setRevocationEnabled(revocationCheck); >>> >>> Ok >>> >>>> >>>> Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. >>> >>> It is easily reproducible. I should have better explained why the suggested changes did not work but not due to race condition. The code pkixParameters.setRevocationEnabled(revocationCheck) only sets the revocation checker enabled. It is the validateCertChain() in Main.java, which calls into RevocationChecker.check() and ultimately calls Event.report() prior to making OCSP and CRL connections. If we call clearReportListener in loadKeyStore() method I don't intend to clear the listener in loadKeyStore(). >>> (i.e finally{ }as suggested), for OCSP, by the time when OCSP.getOCSPBytes() comes in to report the OCSP event, the reporter has been cleared. And this would be same problem for CRL. So it cannot be called immediately. I was thinking about clearing the listener only after validation. However, I can see now that Validator.getInstance(...).validate(...) is called in validateCertChain(), then called in multiple places. It's a little complicated to set/clear multiple times. So it's OK to clear it in run(). Do you think we can also set the listener in this method? Say, before the "if (verify)" line? Thanks, Max >> >> Then I assume the following is OK. >> >> try { >> setReportListener(); >> validator.validate(); >> } finally { >> clearReportListener(); >> } >> > > I?d like to know if there is an issue with the current webrev, which is being tested and it?s working as expected. I?ve also tried with your previous suggested change, and it didn?t work. > > Thanks, > Hai-May > > >> Thanks, >> Max >> >>> >>> Thanks, >>> Hai-May >>> >>>> >>>> Thanks, >>>> Max >>>> >>>>> On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: >>>>> >>>>> Hi Sean, >>>>> >>>>> Thanks for your review. Reply inline. >>>>> >>>>>> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >>>>>> >>>>>> * Main.java: >>>>>> >>>>>> 2067 Event.setReportListener(new Event.Reporter() { >>>>>> 2068 @Override >>>>>> 2069 public void handle(String t, Object... o) { >>>>>> 2070 System.out.println(String.format(rb.getString(t), o)); >>>>>> 2071 } >>>>>> 2072 }); >>>>>> >>>>>> I think you could use a lambda expression above. >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> * Event.java: >>>>>> >>>>>> 35 static Reporter reporter = null; >>>>>> >>>>>> Make this private? Also, no need to explicitly initialize to null as that is the default value. >>>>> >>>>> Done (made it private). >>>>> >>>>>> >>>>>> Can you add some comments at the top of the class describing the purpose of this class? >>>>> >>>>> Done. >>>>> >>>>>> >>>>>> * EnableRevocation.java >>>>>> >>>>>> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. >>>>> >>>>> It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. >>>>> >>>>>> >>>>>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >>>>> >>>>> Done (Release note: JDK-8244285, and man page: JDK-8244274). >>>>> >>>>> Updated webrev: >>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ >>>>> >>>>> Thanks, >>>>> Hai-May >>>>> >>>>> >>>>>> >>>>>> --Sean >>>>>> >>>>>> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>>>>>> Hi, >>>>>>> With small change added to ?Usages.java' test, here is the updated webrev: >>>>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>>>>>> Thanks, >>>>>>> Hai-May >>>>>>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I?d like to request a review for: >>>>>>>> >>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>>>>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>>>>>> >>>>>>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Hai-May From hai-may.chao at oracle.com Tue May 5 08:07:30 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 5 May 2020 01:07:30 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <479400DE-EB77-42F5-BFEA-5937610EAD27@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> <232846F1-B89B-4CA9-97BC-5FD443AC7924@oracle.com> <5B636E18-36FE-4500-89A6-F32A17499E59@oracle.com> <479400DE-EB77-42F5-BFEA-5937610EAD27@oracle.com> Message-ID: <8AEB8F03-21D2-4AD5-AAB6-A8D1D68D86E3@oracle.com> > On May 4, 2020, at 10:23 PM, Weijun Wang wrote: > > > >> On May 5, 2020, at 12:36 PM, Hai-May Chao wrote: >> >> >> >>> On May 4, 2020, at 6:01 PM, Weijun Wang wrote: >>> >>> >>> >>>> On May 5, 2020, at 3:48 AM, Hai-May Chao wrote: >>>> >>>> Hi Max, >>>> >>>>> On May 2, 2020, at 5:25 PM, Weijun Wang wrote: >>>>> >>>>> In jarsigner/Main, you can just call >>>>> >>>>> pkixParameters.setRevocationEnabled(revocationCheck); >>>> >>>> Ok >>>> >>>>> >>>>> Last time, you mentioned that "Event.clearReportListener()" cannot be called immediately after validation check because of some race conditions. Is that easily reproducible? I still find it strange. >>>> >>>> It is easily reproducible. I should have better explained why the suggested changes did not work but not due to race condition. The code pkixParameters.setRevocationEnabled(revocationCheck) only sets the revocation checker enabled. It is the validateCertChain() in Main.java, which calls into RevocationChecker.check() and ultimately calls Event.report() prior to making OCSP and CRL connections. If we call clearReportListener in loadKeyStore() method > > I don't intend to clear the listener in loadKeyStore(). > >>>> (i.e finally{ }as suggested), for OCSP, by the time when OCSP.getOCSPBytes() comes in to report the OCSP event, the reporter has been cleared. And this would be same problem for CRL. So it cannot be called immediately. > > I was thinking about clearing the listener only after validation. However, I can see now that Validator.getInstance(...).validate(...) is called in validateCertChain(), then called in multiple places. It's a little complicated to set/clear multiple times. > > So it's OK to clear it in run(). Do you think we can also set the listener in this method? Say, before the "if (verify)" line? The current change is based on the original flow where it sets PKIX revocation. Hence, I?d like to keep the current change as is unless there is an issue with it. Thanks, Hai-May > > Thanks, > Max > >>> >>> Then I assume the following is OK. >>> >>> try { >>> setReportListener(); >>> validator.validate(); >>> } finally { >>> clearReportListener(); >>> } >>> >> >> I?d like to know if there is an issue with the current webrev, which is being tested and it?s working as expected. I?ve also tried with your previous suggested change, and it didn?t work. >> >> Thanks, >> Hai-May >> >> >>> Thanks, >>> Max >>> >>>> >>>> Thanks, >>>> Hai-May >>>> >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On May 3, 2020, at 2:19 AM, Hai-May Chao wrote: >>>>>> >>>>>> Hi Sean, >>>>>> >>>>>> Thanks for your review. Reply inline. >>>>>> >>>>>>> On May 1, 2020, at 11:50 AM, Sean Mullan wrote: >>>>>>> >>>>>>> * Main.java: >>>>>>> >>>>>>> 2067 Event.setReportListener(new Event.Reporter() { >>>>>>> 2068 @Override >>>>>>> 2069 public void handle(String t, Object... o) { >>>>>>> 2070 System.out.println(String.format(rb.getString(t), o)); >>>>>>> 2071 } >>>>>>> 2072 }); >>>>>>> >>>>>>> I think you could use a lambda expression above. >>>>>> >>>>>> Done. >>>>>> >>>>>>> >>>>>>> * Event.java: >>>>>>> >>>>>>> 35 static Reporter reporter = null; >>>>>>> >>>>>>> Make this private? Also, no need to explicitly initialize to null as that is the default value. >>>>>> >>>>>> Done (made it private). >>>>>> >>>>>>> >>>>>>> Can you add some comments at the top of the class describing the purpose of this class? >>>>>> >>>>>> Done. >>>>>> >>>>>>> >>>>>>> * EnableRevocation.java >>>>>>> >>>>>>> - How long does this test take - does it hang for a little while trying to make a connection or timeout right away? If it takes a while, you could experiment with overriding the default timeouts for CRLs and OCSP checks to make this test finish faster. Use the system properties com.sun.security.ocsp.timeout and com.sun.security.crl.readtimeout. >>>>>> >>>>>> It does not hang for OCSP as the certificate is set with localhost as OCSP responder. It hangs just a little for CRL, thus I?ve changed the certificate to local host instead of remote host. The whole test is finishing very fast now. >>>>>> >>>>>>> >>>>>>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >>>>>> >>>>>> Done (Release note: JDK-8244285, and man page: JDK-8244274). >>>>>> >>>>>> Updated webrev: >>>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Hai-May >>>>>> >>>>>> >>>>>>> >>>>>>> --Sean >>>>>>> >>>>>>> On 5/1/20 12:02 PM, Hai-May Chao wrote: >>>>>>>> Hi, >>>>>>>> With small change added to ?Usages.java' test, here is the updated webrev: >>>>>>>> https://cr.openjdk.java.net/~hchao/8242060/webrev.01/ >>>>>>>> Thanks, >>>>>>>> Hai-May >>>>>>>>> On Apr 30, 2020, at 4:29 PM, Hai-May Chao wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I?d like to request a review for: >>>>>>>>> >>>>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8242060 >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244046 >>>>>>>>> Webrev: https://cr.openjdk.java.net/~hchao/8242060/webrev.00/ >>>>>>>>> >>>>>>>>> The jarsigner command currently does certificate chain validation, but does not check revocation. Users won?t be able to know if the certificates are revoked. This change is to provide an option in jarsigner to enable the revocation check, and to emit progress messages when jarsigner starts network connections to get OCSP responses and CRL. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hai-May -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 5 10:33:50 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 5 May 2020 18:33:50 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Message-ID: I am playing with keytool + BouncyCastle and generate a key pair using the sigalg "SHA3-256WITHECDSA", and `keytool -list` cannot show the signature name. So I tried 2 changes in AlgorithmId.java: 1. add both the name->oid and oid->name mapping inside collectOIDAliases() for 3rd party providers 2. fallback to this mapping if KnownOIDs.findMatch() fails in getName(). Then I can see the signature name. You can consider including this or we can make this in a future RFE. Thanks, Max From sean.mullan at oracle.com Tue May 5 13:16:15 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 5 May 2020 09:16:15 -0400 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> Message-ID: <3396d70b-47d3-8655-de62-9b213b22dc8f@oracle.com> On 5/2/20 2:19 PM, Hai-May Chao wrote: >> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. > Done (Release note: JDK-8244285, and man page: JDK-8244274). I added a few more details to the release note. Otherwise, looks good, so you can mark it Resolved/Delivered. --Sean From xuelei.fan at oracle.com Tue May 5 18:29:16 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 5 May 2020 11:29:16 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension Message-ID: Hi, Could I get the following update reviewed? RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460 webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/ The "certificate_authorities" extension is an optional extension introduced in TLS 1.3 and used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection. In TLS 1.2, this function is built in the CertificateRequest handshake massage. This function is supported in TLS 1.2 and prior versions. However, it is not implemented in the TLS 1.3 implementation. Without this function, the authentication certificate selected may be not the one the peer could accepted, when there are multiple certificates available. Thanks, Xuelei From hai-may.chao at oracle.com Tue May 5 19:29:33 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Tue, 5 May 2020 12:29:33 -0700 Subject: RFR[15] 8242060: Add revocation checking to jarsigner In-Reply-To: <3396d70b-47d3-8655-de62-9b213b22dc8f@oracle.com> References: <7E68A787-C066-4731-869C-3E87FD993E71@oracle.com> <7ECB4874-1F94-484E-8E33-8481069EB89F@oracle.com> <39442fe4-0e6e-76bd-3b58-529d888120a3@oracle.com> <3DC6759F-3373-495F-9CBF-AA1ACB4A7437@oracle.com> <3396d70b-47d3-8655-de62-9b213b22dc8f@oracle.com> Message-ID: > On May 5, 2020, at 6:16 AM, Sean Mullan wrote: > > On 5/2/20 2:19 PM, Hai-May Chao wrote: >>> Looks good otherwise. Please add a release-note and open a follow-on issue to update the man page with the new option. >> Done (Release note: JDK-8244285, and man page: JDK-8244274). > > I added a few more details to the release note. Otherwise, looks good, so you can mark it Resolved/Delivered. > Thanks for your review. I?ve marked it Resolved/Delivered. Hai-May From mikael.vidstedt at oracle.com Tue May 5 22:51:52 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 5 May 2020 15:51:52 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> Message-ID: <5F0E6D22-8DB6-4121-AA40-8DB0F155677E@oracle.com> Max, Thank you so much for the thorough review! I?m working on an incremental webrev but could use some help - comments/questions inline.. > On May 4, 2020, at 6:58 AM, Weijun Wang wrote: > > I've gone through all files. Many of them are PKCS11-related, it will be nice if Valerie can confirm my findings. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: > > Maybe we should not support $ISA at all? It does seem like it could go, but I?m not comfortable making that change myself. How about a follow-up issue? > test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: > > Please also remove the whole else block from line 61. Fixed. > test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: > > It's not worth keeping this test. Error has never occurred on other platforms. Fixed. > test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: > > 128-135: There is no need to use a try-catch block. Fixed. > test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: > > 54-60: No need Fixed. > 81-97: No need. Just a single run() is OK. > 101: Remove the ", p? argument I?m not sure I understand what to do here. Help? :) > test/jdk/java/security/MessageDigest/TestDigestIOStream.java: > test/jdk/java/security/MessageDigest/TestSameLength.java: > test/jdk/java/security/MessageDigest/TestSameValue.java: > > No need for isSHA3Supported(). The SUN provider should always be there. Fixed. > Inside the test where NoSuchAlgorithmException is caught, the catch block can be removed and no need to try Fixed. > test/jdk/java/security/MessageDigest/UnsupportedProvider.java: > > Not worth keeping this test. Fixed. > test/jdk/sun/security/jca/PreferredProviderTest.java: > > 53: remove "for other platform? Fixed. > test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java > > Remove the comments on lines 37-40 Fixed. > test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: > > Not worth keeping the tests in this directory. Fixed. > test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: > > No need for try Fixed. > test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: > > Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, You tell me? :) > test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: > > No need for this catch block Fixed (removed the InvalidAlgorithmParameterException catch). > test/jdk/sun/security/tools/keytool/fakegen/PSS.java: > > Please also remove the comment on lines 35-37. Fixed. > test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: > > Please also remove the comment on lines 36-38. Fixed. Cheers, Mikael > >> On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From mikael.vidstedt at oracle.com Tue May 5 23:17:34 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 5 May 2020 16:17:34 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> Message-ID: <2862604D-D03A-47AC-89D2-212862F525D5@oracle.com> John, Thanks for the review! Comments/questions inline.. > On May 4, 2020, at 4:02 PM, sha.jiang at oracle.com wrote: > > Hi, > Generally, this patch doesn't take care of the solaris/sunos/ucrypto-related > words in test summaries, code comments, configs and READMEs. > E.g. > test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java > test/jdk/sun/security/provider/MessageDigest/TestSHAClone.java > test/jdk/sun/security/util/Resources/Format.config > test/jdk/sun/security/pkcs11/KeyStore/BasicData/README > Would we need some follow-up issues to double-check this point? I?ve deliberately avoided changing comments I didn?t feel comfortable modifying. I?d prefer to file follow-ups as needed, but if you have specific suggestions (or patches!) I should include in the already huge patch do let me know. > test/jdk/sun/security/tools/keytool/KeyToolTest.java > 39 * Testing Solaris Cryptography Framework PKCS11 keystores: > 40 * # make sure you've already run pktool and set test12 as pin > 41 * echo | java -Dsolaris KeyToolTest > ... > 1863 if (System.getProperty("solaris") != null) { > 1864 // For Solaris Cryptography Framework > 1865 t.srcP11Arg = SUN_SRC_P11_ARG; > 1866 t.p11Arg = SUN_P11_ARG; > 1867 t.testPKCS11(); > 1868 t.testPKCS11ImportKeyStore(); > 1869 t.i18nPKCS11Test(); > 1870 } > It may be necessary to remove the above lines. I was staring at this one for quite a while. AFAICT there?s nothing Solaris specific about that block or the methods it?s calling - to me it looks like the property just happens to be called ?solaris?, but it could equally well be called ?pkcs11? or ?standard? or ?foobar?. That said, I don?t know enough about PKCS11 & friends to say for sure. Do let me know if it is indeed dead code and should be removed.. > test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java > test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.policy > It looks this manual test and the associated policy are solaris-related only. > Could these files be removed as well? > In fact, the solaris-related com.sun.security.auth classes, including > SolarisPrincipal, are already removed. Ah, that indeed seems to be the case. Made me wonder why the test doesn?t fail to compile altogether, but then I noticed that it?s ProblemListed on all platforms.. How about a follow-up since this isn?t strictly related to the Solaris/SPARC removal itself - perhaps https://bugs.openjdk.java.net/browse/JDK-8039280 covers it? > test/jdk/sun/security/pkcs11/tls/TestPRF.java > 114 if (secret == null) { > 115 // This fails on Solaris, but since we never call this > 116 // API for this case in JSSE, ignore the failure. > 117 // (SunJSSE uses the CKM_TLS_KEY_AND_MAC_DERIVE > 118 // mechanism) > 119 System.out.print("X"); > 120 continue; > 121 } > Could remove this block? Good question - the comment certainly makes it sound Solaris specific, but could be a stale comment.. Cheers, Mikael > > On 2020/5/4 13:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From valerie.peng at oracle.com Wed May 6 00:13:27 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 5 May 2020 17:13:27 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> Message-ID: <495f8fb5-0493-b6ae-d569-3c936ab08886@oracle.com> Hi Max, Thanks for the comments, they are very helpful. I should have webrev.02 ready in a bit. Please find comments below in line. On 5/1/2020 2:45 AM, Weijun Wang wrote: > ObjectIdentifier.java > --------------------- > > Have you thought about storing the ObjectIdentifier object somewhere? ObjectIdentifier.of() creates a new object each time and the conversion of string to byte[] might be a performance issue. We used to have a lot of ObjectIdentifier objects in AlgorithmId but now we only have KnownOIDs. The ObjectIdentifier objects are stored inside the oidTable map in AlgorithmId class. I removed the static oid constants which aren't referenced. The oids are retrieved from the oidTable when needed. With the webrev, we are exchange oid construction with a map look up, at least this is the intention. > I had a talk with Stuart and he has a suggestion that we can stuff all pre-calculated OID DER encodings in a long byte array in a resource file, and in KnownOIDs each element has an offset/length pair that point to its DER encoding. Also, whatever cache mechanism we use in the future, I suggest making "new ObjectIdentifier(String)" private and keep "ObjectIdentifier of(String)". Done in webrev.02. > > SecurityProviderConstants.java > ------------------------------ > > public static List alias(String ... aliases) { > return Arrays.asList(aliases); > } > > Probably not necessary, you can simply call List.of(...) everywhere. Done in webrev.02. > > SunMSCAPI.java > -------------- > > Why not call getAliases() inside "new ProviderService" like in the other providers? Same in UCrypto. Ok, done in webrev.02. > > AlgorithmId.java > ---------------- > > algOID(String). You don't check "if (name.indexOf('.') != -1)" at the beginning anymore. Is there an algorithm name containing "."? Nope, it's more because the KnownOIDs enum can handle oid string lookup, so I just need to remove the "OID." prefix if present. > It's a pity we have to collect OIDs from other providers. Maybe it should only be necessary when we use that provider, for example, when encoding a signature, we should ask the provider about the OID. I wish there were a Signature::getAlgorithmId, but if not, maybe we can rename Algorithm::alfOID(name) to Algorithm::alfOID(name, provider). The existing OID collection code in AlgorithmId class serves as a safety net when new OID alias mapping is added to provider but AlgorithmId class is not also updated. After this KnownOIDs change, this safety net may not be that necessary and for performance reason, the code would skip JDK providers. However, for max backward compatibility, we may have to keep it. I agree with your name->oid mapping can be provider-specific and handling that would be somewhat sticky with current code. As for including an extra provider argument, I am not sure if that'd work across the board as the caller of AlgorithmId class may not have the provider info. OID usage can be somewhat complicated as demonstrated by this change. > Do you know a bad case if we don't collect those OIDs? It must be some algorithm that is not in the Standard Names. With existing regression tests, nothing breaks if we don't collect the OID aliases. > Overall I think the change looks great, and we have a single place to store all OIDs. The mapping among the OID string, KnownOIDs, and ObjectIdentifier could be enhanced. Do you have a benchmark? I have not done one. I can try something out once I finish addressing your other comments. Thanks, Valerie > > Thanks, > Max > > >> On Apr 30, 2020, at 6:59 AM, Valerie Peng wrote: >> >> Here is the updated webrev http://cr.openjdk.java.net/~valeriep/8242151/webrev.01/ From weijun.wang at oracle.com Wed May 6 02:29:02 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 May 2020 10:29:02 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <5F0E6D22-8DB6-4121-AA40-8DB0F155677E@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> <5F0E6D22-8DB6-4121-AA40-8DB0F155677E@oracle.com> Message-ID: > On May 6, 2020, at 6:51 AM, Mikael Vidstedt wrote: > > > Max, > > Thank you so much for the thorough review! I?m working on an incremental webrev but could use some help - comments/questions inline.. > >> On May 4, 2020, at 6:58 AM, Weijun Wang wrote: >> >> I've gone through all files. Many of them are PKCS11-related, it will be nice if Valerie can confirm my findings. >> >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: >> >> Maybe we should not support $ISA at all? > > It does seem like it could go, but I?m not comfortable making that change myself. How about a follow-up issue? Sure. > >> test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: >> >> Please also remove the whole else block from line 61. > > Fixed. > >> test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: >> >> It's not worth keeping this test. Error has never occurred on other platforms. > > Fixed. > >> test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: >> >> 128-135: There is no need to use a try-catch block. > > Fixed. > >> test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: >> >> 54-60: No need > > Fixed. > >> 81-97: No need. Just a single run() is OK. >> 101: Remove the ", p? argument > > I?m not sure I understand what to do here. Help? :) Since there is only one provider having "jceks" you can 1 remove run() method 2 rename runTest(p) to run() 3 call 'KeyStore.getInstance("jceks")' without the "p" argument. > >> test/jdk/java/security/MessageDigest/TestDigestIOStream.java: >> test/jdk/java/security/MessageDigest/TestSameLength.java: >> test/jdk/java/security/MessageDigest/TestSameValue.java: >> >> No need for isSHA3Supported(). The SUN provider should always be there. > > Fixed. > >> Inside the test where NoSuchAlgorithmException is caught, the catch block can be removed and no need to try > > Fixed. > >> test/jdk/java/security/MessageDigest/UnsupportedProvider.java: >> >> Not worth keeping this test. > > Fixed. > >> test/jdk/sun/security/jca/PreferredProviderTest.java: >> >> 53: remove "for other platform? > > Fixed. > >> test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java >> >> Remove the comments on lines 37-40 > > Fixed. > >> test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: >> >> Not worth keeping the tests in this directory. > > Fixed. > >> test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: >> >> No need for try > > Fixed. > >> test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: >> >> Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, > > You tell me? :) This is why I included Valerie, I'll ping her. Thanks, Max > >> test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: >> >> No need for this catch block > > Fixed (removed the InvalidAlgorithmParameterException catch). > >> test/jdk/sun/security/tools/keytool/fakegen/PSS.java: >> >> Please also remove the comment on lines 35-37. > > Fixed. > >> test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: >> >> Please also remove the comment on lines 36-38. > > Fixed. > > Cheers, > Mikael > >> >>> On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >> > From valerie.peng at oracle.com Wed May 6 03:18:18 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 May 2020 03:18:18 +0000 (UTC) Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Message-ID: Hi Max, Webrev has been updated, http://cr.openjdk.java.net/~valeriep/8242151/webrev.02/. Major changes are: - Moved oidTable caching from AlgorithmId class to ObjectIdentifier class. Made ObjectIdentifier constructor private and callers have to use the of(String) method which always check the oidTable cache before creating new instances. Some more files (src files and tests) are added to the webrev due to the private ObjectIdentifier constructor change. - Arrays.asList() calls are now replaced with List.of() calls. - KnownOIDs enum has been enhanced with registerName() method for ensuring that same standard name can have at most one enum mapping. Added the method stdName() instead of relying on toString(). Added aliases support to KnownOIDs enums. Note that external aliases are in SecurityProviderConstants class. The two non-oid BASE ones are removed and keytool/Main.java is updated. - SecurityProviderConstants class will pick up the internal aliases and combine with external aliases and handle multiple oid enums in its store(...) method. - Updated SunRsaSign provider to use the same naming convention (append the letter A) and fixed its KeyFactory and KeyPairGenerator to use the same oid as before. Also update providers outside of the java.base module in a similar fashion. As for the comments below. Please find replies inline. On 5/4/2020 6:24 PM, Weijun Wang wrote: > Do you want to add OIDs in CurveDB into KnownOIDs as well? Sure, will do in webrev.03. Thanks, Valerie > > Thanks, > Max From thejasvi.v.voniadka at oracle.com Wed May 6 06:09:21 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 5 May 2020 23:09:21 -0700 (PDT) Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> References: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> Message-ID: <4f805057-4bdb-42d7-b1e7-bf658a052615@default> Hello, A quick follow-up on this request.. -----Original Message----- From: Thejasvi Voniadka Sent: Monday, May 4, 2020 12:56 PM To: core-libs-dev at openjdk.java.net Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE when needed. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit only the full patch to be committed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From weijun.wang at oracle.com Wed May 6 12:48:12 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 May 2020 20:48:12 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Message-ID: <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> - PBES2Parameters.java: In parseKDF(), any OID can be accepted as kdfAlgo, wonder if it would lead to unexpected result: jshell> var a = AlgorithmParameters.getInstance("PBEWithHmacSHA256AndAES_256") jshell> a.init(new PBEParameterSpec("hello".getBytes(), 100, new IvParameterSpec("iv".getBytes()))) jshell> var b = a.getEncoded() jshell> b b ==> byte[61] { 48, 59, 48, 40, 6, 9, 42, -122, 72, -122, -9, 13, 1, 5, 12, 48, 27, 4, 5, 104, 101, 108, 108, 111, 2, 1, 100, 2, 1, 32, 48, 12, 6, 8, 42, -122, 72, -122, -9, 13, 2, 9, 5, 0, 48, 15, 6, 9, 96, -122, 72, 1, 101, 3, 4, 1, 42, 4, 2, 105, 118 } // Modify HmacSHA512("1.2.840.113549.2.11") to MD2("1.2.840.113549.2.2") jshell> b[41] = 2 $44 ==> 2 jshell> b b ==> byte[61] { 48, 59, 48, 40, 6, 9, 42, -122, 72, -122, -9, 13, 1, 5, 12, 48, 27, 4, 5, 104, 101, 108, 108, 111, 2, 1, 100, 2, 1, 32, 48, 12, 6, 8, 42, -122, 72, -122, -9, 13, 2, 2, 5, 0, 48, 15, 6, 9, 96, -122, 72, 1, 101, 3, 4, 1, 42, 4, 2, 105, 118 } jshell> a = AlgorithmParameters.getInstance("PBEWithHmacSHA256AndAES_256") jshell> a.init(b) jshell> a a ==> PBEWithMD2AndAES_256 - PKCS9Attribute.java: It looks you can declare and initialize and at the same time make it an element in an array at the same time, like this public static final ObjectIdentifier EMAIL_ADDRESS_OID = PKCS9_OIDS[1] = ObjectIdentifier.of(KnownOIDs.EmailAddress); Then there is no need to write two lines EMAIL_ADDRESS_OID = PKCS9_OIDS[1] = ObjectIdentifier.of(KnownOIDs.EmailAddress); public static final ObjectIdentifier EMAIL_ADDRESS_OID; Also, looks like the strings are never used anywhere inside JDK public static final String EMAIL_ADDRESS_STR = "EmailAddress"; ... Can we remove them? If we want them back, it can be KnownOIDs.stdName. - AlgorithmId.java: getName(): Can we use the collected map from 3rd party providers? I asked this last time. - OIDMap.java: Maybe we can simplify this file later. - KnownOIDs.java: register(): Are you throwing a RuntimeException only when debug is true? This sounds incorrect. "already registered; no need to continue;" Can this happen? You don't manually register preferred ones now. No other comment. Thanks, Max p.s. JGSS uses ObjectIdentifier also, but it also has its own public Oid class. Maybe we can think about it in a different RFE. > On May 6, 2020, at 11:18 AM, Valerie Peng wrote: > > Hi Max, > > Webrev has been updated, http://cr.openjdk.java.net/~valeriep/8242151/webrev.02/. > > Major changes are: > > - Moved oidTable caching from AlgorithmId class to ObjectIdentifier class. Made ObjectIdentifier constructor private and callers have to use the of(String) method which always check the oidTable cache before creating new instances. Some more files (src files and tests) are added to the webrev due to the private ObjectIdentifier constructor change. > > - Arrays.asList() calls are now replaced with List.of() calls. > > - KnownOIDs enum has been enhanced with registerName() method for ensuring that same standard name can have at most one enum mapping. Added the method stdName() instead of relying on toString(). Added aliases support to KnownOIDs enums. Note that external aliases are in SecurityProviderConstants class. The two non-oid BASE ones are removed and keytool/Main.java is updated. > > - SecurityProviderConstants class will pick up the internal aliases and combine with external aliases and handle multiple oid enums in its store(...) method. > > - Updated SunRsaSign provider to use the same naming convention (append the letter A) and fixed its KeyFactory and KeyPairGenerator to use the same oid as before. Also update providers outside of the java.base module in a similar fashion. > > As for the comments below. Please find replies inline. > > On 5/4/2020 6:24 PM, Weijun Wang wrote: >> Do you want to add OIDs in CurveDB into KnownOIDs as well? > > Sure, will do in webrev.03. > > Thanks, > > Valerie > >> >> Thanks, >> Max From shivangi.g.gupta at oracle.com Wed May 6 17:30:24 2020 From: shivangi.g.gupta at oracle.com (shivangi.g.gupta at oracle.com) Date: Wed, 6 May 2020 23:00:24 +0530 Subject: RFR: 8231958: Test for JDK-8228825: Enhance ECDSA Message-ID: Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8231958 Description: ???????? There were few curves which were removed from supported list as part of JDK-8228825. These can be added back to supported list with jdk.tls.namedGroups property. ???????? The test ?test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java? is enhanced to test? one of those curves.As these curves are not supported by TLS1.3 so bypassed? that specific? curve for TLS1.3. Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8231958/webrev.00/ The patch has been tested on mach5, and the individual test was passed. Thanks Shivangi From jjk90331 at gmail.com Wed May 6 14:42:32 2020 From: jjk90331 at gmail.com (jjk) Date: Wed, 6 May 2020 07:42:32 -0700 (MST) Subject: openjdk 13 + ; SunEC, secp256r1 ecc encryption Message-ID: <1588776152232-0.post@n7.nabble.com> Dear SMEs Do openJDk versions 13 and above support EC encryption? for me secp256r1 curve is enough as it is common amongst several other platforms (non-java). Is this something natively supported (13+)? I saw various on sunec.jar, native system.load(..) etc. Appreciate if someone can also point me to a simple working code for encryption and decryption. PS: I want to avoid third party libs such as BC etc.. if possible Thanks in anticipation -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html From anthony.scarpino at oracle.com Wed May 6 18:47:45 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 6 May 2020 11:47:45 -0700 Subject: openjdk 13 + ; SunEC, secp256r1 ecc encryption In-Reply-To: <1588776152232-0.post@n7.nabble.com> References: <1588776152232-0.post@n7.nabble.com> Message-ID: On 5/6/20 7:42 AM, jjk wrote: > Dear SMEs > > Do openJDk versions 13 and above support EC encryption? for me secp256r1 > curve is enough as it is common amongst several other platforms (non-java). > > Is this something natively supported (13+)? I saw various on sunec.jar, > native system.load(..) etc. > > Appreciate if someone can also point me to a simple working code for > encryption and decryption. > > PS: I want to avoid third party libs such as BC etc.. if possible > > Thanks in anticipation > > > > -- > Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html > Hi, spec256r1 is supported in all current releases. The native implementation is part of the java release. 14 uses a java only implementation and not the native implementation. A quick search for "java sign verify ECDSA" on google will provide you many examples on how to use it. Tony From shivangi.g.gupta at oracle.com Wed May 6 20:23:09 2020 From: shivangi.g.gupta at oracle.com (shivangi.g.gupta at oracle.com) Date: Thu, 7 May 2020 01:53:09 +0530 Subject: RFR: 8231958: Test for JDK-8228825: Enhance ECDSA In-Reply-To: References: Message-ID: <55bc8b43-3319-dd5c-5f2a-7647cee3aa0d@oracle.com> Ignore this review thread for now, I need to rework the fix. ~Shivangi On 06/05/20 11:00 PM, shivangi.g.gupta at oracle.com wrote: > Hi, > > May I please find a sponsor for this patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231958 > > Description: > ???????? There were few curves which were removed from supported list > as part of JDK-8228825. These can be added back to supported list with > jdk.tls.namedGroups property. > ???????? The test > ?test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java? is > enhanced to test? one of those curves.As these curves are not > supported by TLS1.3 so bypassed? that specific? curve for TLS1.3. > > > Webrev: http://cr.openjdk.java.net/~sshivang/reviews/8231958/webrev.00/ > > The patch has been tested on mach5, and the individual test was passed. > > Thanks > > Shivangi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerie.peng at oracle.com Wed May 6 21:54:02 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 May 2020 14:54:02 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> Message-ID: <29505bd9-ea7d-2bc7-4b6c-3ed7fba4ce86@oracle.com> Sure, I can include this in. Will address in webrev.03. Thanks, Valerie On 5/5/2020 3:33 AM, Weijun Wang wrote: > I am playing with keytool + BouncyCastle and generate a key pair using the sigalg "SHA3-256WITHECDSA", and `keytool -list` cannot show the signature name. > > So I tried 2 changes in AlgorithmId.java: > > 1. add both the name->oid and oid->name mapping inside collectOIDAliases() for 3rd party providers > > 2. fallback to this mapping if KnownOIDs.findMatch() fails in getName(). > > Then I can see the signature name. > > You can consider including this or we can make this in a future RFE. > > Thanks, > Max > From valerie.peng at oracle.com Wed May 6 22:27:36 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 6 May 2020 15:27:36 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> Message-ID: <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> Hi Max, Thanks for the review, I find your comments very useful. Please find responses inline. On 5/6/2020 5:48 AM, Weijun Wang wrote: > - PBES2Parameters.java: > > In parseKDF(), any OID can be accepted as kdfAlgo, wonder if it would lead to unexpected result: > > jshell> var a = AlgorithmParameters.getInstance("PBEWithHmacSHA256AndAES_256") > > jshell> a.init(new PBEParameterSpec("hello".getBytes(), 100, new IvParameterSpec("iv".getBytes()))) > > jshell> var b = a.getEncoded() > > jshell> b > b ==> byte[61] { 48, 59, 48, 40, 6, 9, 42, -122, 72, -122, -9, 13, 1, 5, 12, 48, 27, 4, 5, 104, 101, 108, 108, 111, 2, 1, 100, 2, 1, 32, 48, 12, 6, 8, 42, -122, 72, -122, -9, 13, 2, 9, 5, 0, 48, 15, 6, 9, 96, -122, 72, 1, 101, 3, 4, 1, 42, 4, 2, 105, 118 } > > // Modify HmacSHA512("1.2.840.113549.2.11") to MD2("1.2.840.113549.2.2") > jshell> b[41] = 2 > $44 ==> 2 > > jshell> b > b ==> byte[61] { 48, 59, 48, 40, 6, 9, 42, -122, 72, -122, -9, 13, 1, 5, 12, 48, 27, 4, 5, 104, 101, 108, 108, 111, 2, 1, 100, 2, 1, 32, 48, 12, 6, 8, 42, -122, 72, -122, -9, 13, 2, 2, 5, 0, 48, 15, 6, 9, 96, -122, 72, 1, 101, 3, 4, 1, 42, 4, 2, 105, 118 } > > jshell> a = AlgorithmParameters.getInstance("PBEWithHmacSHA256AndAES_256") > > jshell> a.init(b) > > jshell> a > a ==> PBEWithMD2AndAES_256 Ok, good catch, I will add some check back in (webrev.03) to at least match exsting impl. It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? > - PKCS9Attribute.java: > > It looks you can declare and initialize and at the same time make it an element in an array at the same time, like this > > public static final ObjectIdentifier EMAIL_ADDRESS_OID = PKCS9_OIDS[1] = > ObjectIdentifier.of(KnownOIDs.EmailAddress); > > Then there is no need to write two lines > > EMAIL_ADDRESS_OID = PKCS9_OIDS[1] = > ObjectIdentifier.of(KnownOIDs.EmailAddress); > public static final ObjectIdentifier EMAIL_ADDRESS_OID; > > Also, looks like the strings are never used anywhere inside JDK > > public static final String EMAIL_ADDRESS_STR = "EmailAddress"; > ... > > Can we remove them? If we want them back, it can be KnownOIDs.stdName. Ok, I removed them and updated some more source and test to use the other PKCS9Attribute constructor which takes an oid instead. It seems that the constructor which takes String then become unused with this change, so I commented it out (in webrev.03). > - AlgorithmId.java: > > getName(): Can we use the collected map from 3rd party providers? I asked this last time. Sure. I have just replied to your other email. Will include in webrev.03. > - OIDMap.java: > > Maybe we can simplify this file later. Yes, looks like some more house scrubbing is needed later. > - KnownOIDs.java: > > register(): Are you throwing a RuntimeException only when debug is true? This sounds incorrect. > > "already registered; no need to continue;" Can this happen? You don't manually register preferred ones now. Correct, should have removed the debug check. Missed this one. Also removed the "already registered" part of code as it is now obsolete (in webrev.03). Thanks, Valerie > No other comment. > > Thanks, > Max > > p.s. JGSS uses ObjectIdentifier also, but it also has its own public Oid class. Maybe we can think about it in a different RFE. > > >> On May 6, 2020, at 11:18 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Webrev has been updated, http://cr.openjdk.java.net/~valeriep/8242151/webrev.02/. >> >> Major changes are: >> >> - Moved oidTable caching from AlgorithmId class to ObjectIdentifier class. Made ObjectIdentifier constructor private and callers have to use the of(String) method which always check the oidTable cache before creating new instances. Some more files (src files and tests) are added to the webrev due to the private ObjectIdentifier constructor change. >> >> - Arrays.asList() calls are now replaced with List.of() calls. >> >> - KnownOIDs enum has been enhanced with registerName() method for ensuring that same standard name can have at most one enum mapping. Added the method stdName() instead of relying on toString(). Added aliases support to KnownOIDs enums. Note that external aliases are in SecurityProviderConstants class. The two non-oid BASE ones are removed and keytool/Main.java is updated. >> >> - SecurityProviderConstants class will pick up the internal aliases and combine with external aliases and handle multiple oid enums in its store(...) method. >> >> - Updated SunRsaSign provider to use the same naming convention (append the letter A) and fixed its KeyFactory and KeyPairGenerator to use the same oid as before. Also update providers outside of the java.base module in a similar fashion. >> >> As for the comments below. Please find replies inline. >> >> On 5/4/2020 6:24 PM, Weijun Wang wrote: >>> Do you want to add OIDs in CurveDB into KnownOIDs as well? >> Sure, will do in webrev.03. >> >> Thanks, >> >> Valerie >> >>> Thanks, >>> Max From weijun.wang at oracle.com Thu May 7 01:59:02 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 May 2020 09:59:02 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> Message-ID: <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> > > It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. --Max From mikael.vidstedt at oracle.com Thu May 7 04:59:21 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:59:21 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> <5F0E6D22-8DB6-4121-AA40-8DB0F155677E@oracle.com> Message-ID: <48C531F1-83A4-4A09-B1C4-9A6B3CB95DF4@oracle.com> > On May 5, 2020, at 7:29 PM, Weijun Wang wrote: > > > >> On May 6, 2020, at 6:51 AM, Mikael Vidstedt wrote: >> >> >> Max, >> >> Thank you so much for the thorough review! I?m working on an incremental webrev but could use some help - comments/questions inline.. >> >>> On May 4, 2020, at 6:58 AM, Weijun Wang wrote: >>> >>> I've gone through all files. Many of them are PKCS11-related, it will be nice if Valerie can confirm my findings. >>> >>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: >>> >>> Maybe we should not support $ISA at all? >> >> It does seem like it could go, but I?m not comfortable making that change myself. How about a follow-up issue? > > Sure. > >> >>> test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: >>> >>> Please also remove the whole else block from line 61. >> >> Fixed. >> >>> test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: >>> >>> It's not worth keeping this test. Error has never occurred on other platforms. >> >> Fixed. >> >>> test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: >>> >>> 128-135: There is no need to use a try-catch block. >> >> Fixed. >> >>> test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: >>> >>> 54-60: No need >> >> Fixed. >> >>> 81-97: No need. Just a single run() is OK. >>> 101: Remove the ", p? argument >> >> I?m not sure I understand what to do here. Help? :) > > Since there is only one provider having "jceks" you can > > 1 remove run() method > 2 rename runTest(p) to run() > 3 call 'KeyStore.getInstance("jceks")' without the "p" argument. Thank you! I did exactly that. > >> >>> test/jdk/java/security/MessageDigest/TestDigestIOStream.java: >>> test/jdk/java/security/MessageDigest/TestSameLength.java: >>> test/jdk/java/security/MessageDigest/TestSameValue.java: >>> >>> No need for isSHA3Supported(). The SUN provider should always be there. >> >> Fixed. >> >>> Inside the test where NoSuchAlgorithmException is caught, the catch block can be removed and no need to try >> >> Fixed. >> >>> test/jdk/java/security/MessageDigest/UnsupportedProvider.java: >>> >>> Not worth keeping this test. >> >> Fixed. >> >>> test/jdk/sun/security/jca/PreferredProviderTest.java: >>> >>> 53: remove "for other platform? >> >> Fixed. >> >>> test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java >>> >>> Remove the comments on lines 37-40 >> >> Fixed. >> >>> test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: >>> >>> Not worth keeping the tests in this directory. >> >> Fixed. >> >>> test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: >>> >>> No need for try >> >> Fixed. >> >>> test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: >>> >>> Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, >> >> You tell me? :) > > This is why I included Valerie, I'll ping her. Sounds good, I?ll wait for Valerie?s feedback. Cheers, Mikael > > Thanks, > Max > >> >>> test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: >>> >>> No need for this catch block >> >> Fixed (removed the InvalidAlgorithmParameterException catch). >> >>> test/jdk/sun/security/tools/keytool/fakegen/PSS.java: >>> >>> Please also remove the comment on lines 35-37. >> >> Fixed. >> >>> test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: >>> >>> Please also remove the comment on lines 36-38. >> >> Fixed. >> >> Cheers, >> Mikael >> >>> >>>> On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> Please review this change which implements part of JEP 381: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>>> >>>> >>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>>> >>>> >>>> Background: >>>> >>>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>>> >>>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>>> >>>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>>> >>>> >>>> Testing: >>>> >>>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >>> >> > From mikael.vidstedt at oracle.com Thu May 7 05:05:31 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 22:05:31 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> Message-ID: <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> New webrev here: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ Items yet to be resolved: * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java Cheers, Mikael > On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From weijun.wang at oracle.com Thu May 7 08:02:39 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 May 2020 16:02:39 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> Message-ID: > On May 7, 2020, at 1:05 PM, Mikael Vidstedt wrote: > > > New webrev here: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ > > Items yet to be resolved: > > * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java Maybe keep it now. I remember on Ubuntu the libraries are also in different directories for x64 and x86. > > * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java 1. remove all lines except for the 1st in the test's @summary 2. remove the whole "if (System.getProperty("solaris") != null)" block in main() 3. remove the static final String fields SUN_P11_ARG and SUN_SRC_P11_ARG > > * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java The test has been neglected for a long time, but I think in theory the SolarisPrincipal can be substituted into UnixPrincipal. Let's keep it. > > * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java I don't quite understand this test, but I think we can simply remove the block. The comment seems to suggest that this will not fail on Solaris. Let's see what would happen on other platforms. Thanks, Max > > Cheers, > Mikael > >> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From weijun.wang at oracle.com Thu May 7 08:06:39 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 7 May 2020 16:06:39 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> Message-ID: > >> >> * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java > > The test has been neglected for a long time, but I think in theory the SolarisPrincipal can be substituted into UnixPrincipal. Let's keep it. Please just s/Solaris/Unix/ in PrincipalExpansionError.java and PrincipalExpansionError.policy now. Thanks, Max From sean.mullan at oracle.com Thu May 7 20:31:35 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 7 May 2020 16:31:35 -0400 Subject: RFR: 8237888: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval Message-ID: <8665d15c-bb25-0575-11a1-174744ad399a@oracle.com> The LuxTrust CA has resolved the issue on their side, so the fix is simply to remove the test from the ProblemList: diff -r 868fe697bad4 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Thu May 07 19:18:22 2020 +0100 +++ b/test/jdk/ProblemList.txt Thu May 07 16:30:47 2020 -0400 @@ -704,7 +704,6 @@ sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 8209398 generic-all security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java 8224768 generic-all -security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java 8237888 generic-all sun/security/smartcardio/TestChannel.java 8039280 generic-all sun/security/smartcardio/TestConnect.java 8039280 generic-all --Sean From valerie.peng at oracle.com Thu May 7 21:48:37 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 May 2020 14:48:37 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> Message-ID: <5a999a9f-4581-8839-6f13-3de5adc6fc90@oracle.com> > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: > > Maybe we should not support $ISA at all? I suppose it should be ok not supporting $ISA. Existing PKCS11 provider documentation does not mention it anyway. > test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: > > Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, This test will be run as there is an out-of-box PKCS11 provider named "SunPKCS11" (which is sort of a dummy for actual crypto operations but it can still be used to test the generic configuration parsing functionality in this test). As for removing the tests, I am more on the conservative side. We should only remove tests which are no longer necessary due to the removal of Solaris support. There are already a lot of changes involved here. Valerie On 5/4/2020 6:58 AM, Weijun Wang wrote: > I've gone through all files. Many of them are PKCS11-related, it will be nice if Valerie can confirm my findings. > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: > > Maybe we should not support $ISA at all? > > test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: > > Please also remove the whole else block from line 61. > > test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: > > It's not worth keeping this test. Error has never occurred on other platforms. > > test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: > > 128-135: There is no need to use a try-catch block. > > test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: > > 54-60: No need > 81-97: No need. Just a single run() is OK. > 101: Remove the ", p" argument > > test/jdk/java/security/MessageDigest/TestDigestIOStream.java: > test/jdk/java/security/MessageDigest/TestSameLength.java: > test/jdk/java/security/MessageDigest/TestSameValue.java: > > No need for isSHA3Supported(). The SUN provider should always be there. > Inside the test where NoSuchAlgorithmException is caught, the catch block can be removed and no need to try > > test/jdk/java/security/MessageDigest/UnsupportedProvider.java: > > Not worth keeping this test. > > test/jdk/sun/security/jca/PreferredProviderTest.java: > > 53: remove "for other platform" > > test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java > > Remove the comments on lines 37-40 > > test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: > > Not worth keeping the tests in this directory. > > test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: > > No need for try > > test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: > > Will this test ever run? There is no out-of-box SunPKCS11 provider. Even if one is configured manually, the name is likely to be SunPKCS11-XYZ, > > test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: > > No need for this catch block > > test/jdk/sun/security/tools/keytool/fakegen/PSS.java: > > Please also remove the comment on lines 35-37. > > test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: > > Please also remove the comment on lines 36-38. > > Thanks, > Max > > > >> On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From mikael.vidstedt at oracle.com Thu May 7 21:51:42 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 14:51:42 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> Message-ID: Will generate a new webrev shortly, meanwhile some comments inline.. > On May 7, 2020, at 1:02 AM, Weijun Wang wrote: > > > >> On May 7, 2020, at 1:05 PM, Mikael Vidstedt wrote: >> >> >> New webrev here: >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ >> >> Items yet to be resolved: >> >> * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java > > Maybe keep it now. I remember on Ubuntu the libraries are also in different directories for x64 and x86. I?ll leave it the way it is in webrev.01. Just to make sure we?re on the same page: the only remaining effect it will have is that the "$ISA/? substring will be removed if it?s found. A possible removal can perhaps be handled as a follow-up instead? > >> >> * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java > > 1. remove all lines except for the 1st in the test's @summary > 2. remove the whole "if (System.getProperty("solaris") != null)" block in main() > 3. remove the static final String fields SUN_P11_ARG and SUN_SRC_P11_ARG Thanks for the off-thread education on why this code is indeed Solaris specific: all other platforms need the -addprovider option to enable PKCS11, Solaris comes with enabled by default. > >> >> * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java > > The test has been neglected for a long time, but I think in theory the SolarisPrincipal can be substituted into UnixPrincipal. Let's keep it. I changed SolarisPrincipal to UnixPrincipal in the .java and .policy files, but did *not* verify that the test works as expected with that change. > >> >> * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java > > I don't quite understand this test, but I think we can simply remove the block. The comment seems to suggest that this will not fail on Solaris. Let's see what would happen on other platforms. Consider it gone! Cheers, Mikael > >> >>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >> > From valerie.peng at oracle.com Thu May 7 22:06:33 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 May 2020 15:06:33 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <5a999a9f-4581-8839-6f13-3de5adc6fc90@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <87B408F8-9919-4FD6-92B3-848411732C9A@oracle.com> <5a999a9f-4581-8839-6f13-3de5adc6fc90@oracle.com> Message-ID: <4e701a17-497f-eb69-9392-4330d2dfb580@oracle.com> One more thing: > test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: > > Not worth keeping the tests in this directory. We do need the tests under test/jdk/sun/security/pkcs11/Config/, please add them back if you have already removed them. As stated earlier, the config parsing function can be tested against the dummy SunPKCS11 provider. Thanks, Valerie On 5/7/2020 2:48 PM, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: >> >> ??? Maybe we should not support $ISA at all? > > I suppose it should be ok not supporting $ISA. Existing PKCS11 > provider documentation does not mention it anyway. > >> test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: >> >> ??? Will this test ever run? There is no out-of-box SunPKCS11 >> provider. Even if one is configured manually, the name is likely to >> be SunPKCS11-XYZ, > This test will be run as there is an out-of-box PKCS11 provider named > "SunPKCS11" (which is sort of a dummy for actual crypto operations but > it can still be used to test the generic configuration parsing > functionality in this test). > > > As for removing the tests, I am more on the conservative side. We > should only remove tests which are no longer necessary due to the > removal of Solaris support. There are already a lot of changes > involved here. > Valerie > > On 5/4/2020 6:58 AM, Weijun Wang wrote: >> I've gone through all files. Many of them are PKCS11-related, it will >> be nice if Valerie can confirm my findings. >> >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java: >> >> ??? Maybe we should not support $ISA at all? >> >> test/jdk/com/sun/security/auth/login/ConfigFile/InconsistentError.java: >> >> ??? Please also remove the whole else block from line 61. >> >> test/jdk/java/security/KeyPairGenerator/SolarisShortDSA.java: >> >> ??? It's not worth keeping this test. Error has never occurred on >> other platforms. >> >> test/jdk/java/security/KeyStore/TestKeyStoreBasic.java: >> >> ??? 128-135: There is no need to use a try-catch block. >> >> test/jdk/java/security/KeyStore/TestKeyStoreEntry.java: >> >> ??? 54-60: No need >> ??? 81-97: No need. Just a single run() is OK. >> ??? 101: Remove the ", p" argument >> >> test/jdk/java/security/MessageDigest/TestDigestIOStream.java: >> test/jdk/java/security/MessageDigest/TestSameLength.java: >> test/jdk/java/security/MessageDigest/TestSameValue.java: >> >> ??? No need for isSHA3Supported(). The SUN provider should always be >> there. >> ??? Inside the test where NoSuchAlgorithmException is caught, the >> catch block can be removed and no need to try >> >> test/jdk/java/security/MessageDigest/UnsupportedProvider.java: >> >> ??? Not worth keeping this test. >> >> test/jdk/sun/security/jca/PreferredProviderTest.java: >> >> ??? 53: remove "for other platform" >> >> test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java >> >> ??? Remove the comments on lines 37-40 >> >> test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java: >> >> ??? Not worth keeping the tests in this directory. >> >> test/jdk/sun/security/pkcs11/Mac/MacSameTest.java: >> >> ??? No need for try >> >> test/jdk/sun/security/pkcs11/Provider/ConfigShortPath.java: >> >> ??? Will this test ever run? There is no out-of-box SunPKCS11 >> provider. Even if one is configured manually, the name is likely to >> be SunPKCS11-XYZ, >> >> test/jdk/sun/security/pkcs11/tls/TestKeyMaterial.java: >> >> ??? No need for this catch block >> >> test/jdk/sun/security/tools/keytool/fakegen/PSS.java: >> >> ??? Please also remove the comment on lines 35-37. >> >> test/jdk/sun/security/tools/keytool/fakegen/DefaultSignatureAlgorithm.java: >> >> >> ??? Please also remove the comment on lines 36-38. >> >> Thanks, >> Max >> >> >> >>> On May 4, 2020, at 1:12 PM, Mikael Vidstedt >>> wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was >>> *extremely* mind-numbing, so I appreciate your help reviewing all >>> the individual changes carefully. You may want to get that coffee >>> cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas >>> touched, this patch is one out of in total six partial patches which >>> together make up the necessary changes to remove the Solaris and >>> SPARC ports. The other patches are being sent out for review to >>> mailing lists appropriate for the respective areas the touch. An >>> email will be sent to jdk-dev summarizing all the patches/reviews. >>> To be clear: this patch is *not* in itself complete and stand-alone >>> - all of the (six) patches are needed to form a complete patch. Some >>> changes in this patch may look wrong or incomplete unless also >>> looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, >>> but in case you have comments on changes in other areas, outside of >>> the files included in this thread, please provide those comments >>> directly in the thread on the appropriate mailing list for that area >>> if possible. >>> >>> In case it helps, the changes were effectively produced by searching >>> for and updating any code mentioning ?solaris", ?sparc?, >>> ?solstudio?, ?sunos?, etc. More information about the areas impacted >>> can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed >>> tier1-8, as well as client tier1-2. Additional testing will be done >>> after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] >>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From xuelei.fan at oracle.com Thu May 7 23:07:18 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 7 May 2020 16:07:18 -0700 Subject: RFR: 8237888: security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java fails when checking validity interval In-Reply-To: <8665d15c-bb25-0575-11a1-174744ad399a@oracle.com> References: <8665d15c-bb25-0575-11a1-174744ad399a@oracle.com> Message-ID: Looks fine to me. Xuelei On 5/7/2020 1:31 PM, Sean Mullan wrote: > The LuxTrust CA has resolved the issue on their side, so the fix is > simply to remove the test from the ProblemList: > > diff -r 868fe697bad4 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt? Thu May 07 19:18:22 2020 +0100 > +++ b/test/jdk/ProblemList.txt? Thu May 07 16:30:47 2020 -0400 > @@ -704,7 +704,6 @@ > ?sun/security/pkcs11/KeyStore/SecretKeysBasic.sh 8209398 generic-all > > > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > ?8224768 generic-all > -security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java > 8237888 generic-all > > ?sun/security/smartcardio/TestChannel.java 8039280 generic-all > ?sun/security/smartcardio/TestConnect.java 8039280 generic-all > > --Sean From valerie.peng at oracle.com Thu May 7 23:08:42 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 May 2020 16:08:42 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <2862604D-D03A-47AC-89D2-212862F525D5@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2862604D-D03A-47AC-89D2-212862F525D5@oracle.com> Message-ID: <192ba822-cd87-3558-c22e-a5b3288021cc@oracle.com> It should be ok to remove the if (secret == null) block of test/jdk/sun/security/pkcs11/tls/TestPRF.java. I verified that the test runs fine on Linux without that block, so the comment is legit. Thanks, Valerie On 5/5/2020 4:17 PM, Mikael Vidstedt wrote: > John, > > Thanks for the review! Comments/questions inline.. > >> On May 4, 2020, at 4:02 PM, sha.jiang at oracle.com wrote: >> >> Hi, >> Generally, this patch doesn't take care of the solaris/sunos/ucrypto-related >> words in test summaries, code comments, configs and READMEs. >> E.g. >> test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java >> test/jdk/sun/security/provider/MessageDigest/TestSHAClone.java >> test/jdk/sun/security/util/Resources/Format.config >> test/jdk/sun/security/pkcs11/KeyStore/BasicData/README >> Would we need some follow-up issues to double-check this point? > I?ve deliberately avoided changing comments I didn?t feel comfortable modifying. I?d prefer to file follow-ups as needed, but if you have specific suggestions (or patches!) I should include in the already huge patch do let me know. > >> test/jdk/sun/security/tools/keytool/KeyToolTest.java >> 39 * Testing Solaris Cryptography Framework PKCS11 keystores: >> 40 * # make sure you've already run pktool and set test12 as pin >> 41 * echo | java -Dsolaris KeyToolTest >> ... >> 1863 if (System.getProperty("solaris") != null) { >> 1864 // For Solaris Cryptography Framework >> 1865 t.srcP11Arg = SUN_SRC_P11_ARG; >> 1866 t.p11Arg = SUN_P11_ARG; >> 1867 t.testPKCS11(); >> 1868 t.testPKCS11ImportKeyStore(); >> 1869 t.i18nPKCS11Test(); >> 1870 } >> It may be necessary to remove the above lines. > I was staring at this one for quite a while. AFAICT there?s nothing Solaris specific about that block or the methods it?s calling - to me it looks like the property just happens to be called ?solaris?, but it could equally well be called ?pkcs11? or ?standard? or ?foobar?. That said, I don?t know enough about PKCS11 & friends to say for sure. Do let me know if it is indeed dead code and should be removed.. > >> test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java >> test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.policy >> It looks this manual test and the associated policy are solaris-related only. >> Could these files be removed as well? >> In fact, the solaris-related com.sun.security.auth classes, including >> SolarisPrincipal, are already removed. > Ah, that indeed seems to be the case. Made me wonder why the test doesn?t fail to compile altogether, but then I noticed that it?s ProblemListed on all platforms.. > > How about a follow-up since this isn?t strictly related to the Solaris/SPARC removal itself - perhaps https://bugs.openjdk.java.net/browse/JDK-8039280 covers it? > >> test/jdk/sun/security/pkcs11/tls/TestPRF.java >> 114 if (secret == null) { >> 115 // This fails on Solaris, but since we never call this >> 116 // API for this case in JSSE, ignore the failure. >> 117 // (SunJSSE uses the CKM_TLS_KEY_AND_MAC_DERIVE >> 118 // mechanism) >> 119 System.out.print("X"); >> 120 continue; >> 121 } >> Could remove this block? > Good question - the comment certainly makes it sound Solaris specific, but could be a stale comment.. > > Cheers, > Mikael > >> On 2020/5/4 13:12, Mikael Vidstedt wrote: >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From valerie.peng at oracle.com Thu May 7 23:17:49 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 7 May 2020 16:17:49 -0700 Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException In-Reply-To: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> References: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> Message-ID: <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> Ping? On 4/23/2020 3:28 PM, Valerie Peng wrote: > Anyone has time to help review this fix? After the support for > RSASSA-PSS keys is added, when parsing the DER encoding, the key > algorithm is based on the parsed algorithm oid/name. However, an > exception is thrown if the parsed algorithm oid/name is neither RSA > nor RSASSA-PSS. For this particular report, the algorithm oid is > 1.3.14.3.2.15 which is unsupport/unrecognized by JDK. In earlier > releases, the bytes are parsed but key algorithm is always "RSA". > > To maintain this backward compatibility behavior, I changed the > current impl to set the key algorithm upon key construction time w/ a > KeyType argument (RSA or RSASSA-PSS) even when DER encoding is given. > After parsing the DER encoding, for non-RSA keys, the parsed algorithm > oid/name should match the given key type, otherwise an exception is > thrown. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242897 > > Webrev: http://cr.openjdk.java.net/~valeriep/8242897/webrev.00/ > > Mach5 run is clean. > > Thanks, > Valerie From thejasvi.v.voniadka at oracle.com Fri May 8 00:47:28 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Thu, 7 May 2020 17:47:28 -0700 (PDT) Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Message-ID: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> Hi, May someone please sponsor this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE and FINER. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit the full patch to be pushed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From mikael.vidstedt at oracle.com Fri May 8 03:51:42 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 20:51:42 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <192ba822-cd87-3558-c22e-a5b3288021cc@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2862604D-D03A-47AC-89D2-212862F525D5@oracle.com> <192ba822-cd87-3558-c22e-a5b3288021cc@oracle.com> Message-ID: <75BA4549-87A3-49C5-AEE9-9D12A7E45D20@oracle.com> > On May 7, 2020, at 4:08 PM, Valerie Peng wrote: > > It should be ok to remove the if (secret == null) block of test/jdk/sun/security/pkcs11/tls/TestPRF.java. > > I verified that the test runs fine on Linux without that block, so the comment is legit. Thank you for verifying! I?ll revert the removal of the test/jdk/sun/security/pkcs11/Config/ files and send out a new webrev in a minute! Cheers, Mikael > > Thanks, > Valerie > On 5/5/2020 4:17 PM, Mikael Vidstedt wrote: >> John, >> >> Thanks for the review! Comments/questions inline.. >> >>> On May 4, 2020, at 4:02 PM, sha.jiang at oracle.com wrote: >>> >>> Hi, >>> Generally, this patch doesn't take care of the solaris/sunos/ucrypto-related >>> words in test summaries, code comments, configs and READMEs. >>> E.g. >>> test/jdk/javax/net/ssl/templates/SSLEngineTemplate.java >>> test/jdk/sun/security/provider/MessageDigest/TestSHAClone.java >>> test/jdk/sun/security/util/Resources/Format.config >>> test/jdk/sun/security/pkcs11/KeyStore/BasicData/README >>> Would we need some follow-up issues to double-check this point? >> I?ve deliberately avoided changing comments I didn?t feel comfortable modifying. I?d prefer to file follow-ups as needed, but if you have specific suggestions (or patches!) I should include in the already huge patch do let me know. >> >>> test/jdk/sun/security/tools/keytool/KeyToolTest.java >>> 39 * Testing Solaris Cryptography Framework PKCS11 keystores: >>> 40 * # make sure you've already run pktool and set test12 as pin >>> 41 * echo | java -Dsolaris KeyToolTest >>> ... >>> 1863 if (System.getProperty("solaris") != null) { >>> 1864 // For Solaris Cryptography Framework >>> 1865 t.srcP11Arg = SUN_SRC_P11_ARG; >>> 1866 t.p11Arg = SUN_P11_ARG; >>> 1867 t.testPKCS11(); >>> 1868 t.testPKCS11ImportKeyStore(); >>> 1869 t.i18nPKCS11Test(); >>> 1870 } >>> It may be necessary to remove the above lines. >> I was staring at this one for quite a while. AFAICT there?s nothing Solaris specific about that block or the methods it?s calling - to me it looks like the property just happens to be called ?solaris?, but it could equally well be called ?pkcs11? or ?standard? or ?foobar?. That said, I don?t know enough about PKCS11 & friends to say for sure. Do let me know if it is indeed dead code and should be removed.. >> >>> test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java >>> test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.policy >>> It looks this manual test and the associated policy are solaris-related only. >>> Could these files be removed as well? >>> In fact, the solaris-related com.sun.security.auth classes, including >>> SolarisPrincipal, are already removed. >> Ah, that indeed seems to be the case. Made me wonder why the test doesn?t fail to compile altogether, but then I noticed that it?s ProblemListed on all platforms.. >> >> How about a follow-up since this isn?t strictly related to the Solaris/SPARC removal itself - perhaps https://bugs.openjdk.java.net/browse/JDK-8039280 covers it? >> >>> test/jdk/sun/security/pkcs11/tls/TestPRF.java >>> 114 if (secret == null) { >>> 115 // This fails on Solaris, but since we never call this >>> 116 // API for this case in JSSE, ignore the failure. >>> 117 // (SunJSSE uses the CKM_TLS_KEY_AND_MAC_DERIVE >>> 118 // mechanism) >>> 119 System.out.print("X"); >>> 120 continue; >>> 121 } >>> Could remove this block? >> Good question - the comment certainly makes it sound Solaris specific, but could be a stale comment.. >> >> Cheers, >> Mikael >> >>> On 2020/5/4 13:12, Mikael Vidstedt wrote: >>>> Please review this change which implements part of JEP 381: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>>> >>>> >>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>>> >>>> >>>> Background: >>>> >>>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>>> >>>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>>> >>>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>>> >>>> >>>> Testing: >>>> >>>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From mikael.vidstedt at oracle.com Fri May 8 03:54:39 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 20:54:39 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> Message-ID: <2043A190-C82A-4265-9F5D-CD4142E65814@oracle.com> New webrev: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security.incr/open/webrev/ Items to be resolved: * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java Cheers, Mikael > On May 6, 2020, at 10:05 PM, Mikael Vidstedt wrote: > > > New webrev here: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ > > Items yet to be resolved: > > * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java > > * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java > > * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java > > * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java > > Cheers, > Mikael > >> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From weijun.wang at oracle.com Fri May 8 09:41:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 May 2020 17:41:08 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 Message-ID: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. I also take this chance to make some format change. There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. Thanks, Max From weijun.wang at oracle.com Fri May 8 10:39:58 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 May 2020 18:39:58 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> Message-ID: Found an existing test I can update. Webrev updated at http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ Thanks, Max > On May 8, 2020, at 5:41 PM, Weijun Wang wrote: > > Please take a review at > > http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ > > Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. > > I also take this chance to make some format change. > > There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. > > Thanks, > Max > From valerie.peng at oracle.com Fri May 8 19:02:09 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 8 May 2020 12:02:09 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> Message-ID: <773a7b09-4812-cd7e-56ac-ba5b1a24d064@oracle.com> Noticed one minor thing: Additional lines can be removed, i.e. other non-SunPKCS11-nss ones can probably removed, i.e. line 15, 16, and 19. Thanks, Valerie On 5/6/2020 10:05 PM, Mikael Vidstedt wrote: > New webrev here: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ > > Items yet to be resolved: > > * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java > > * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java > > * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java > > * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java > > Cheers, > Mikael > >> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From valerie.peng at oracle.com Fri May 8 20:14:57 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 8 May 2020 13:14:57 -0700 Subject: [15] RFR JDK-8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 Message-ID: Anyone can help with this trivial two-line change? Just updating the version to 1.8.26 from 1.8.24, no change to the headers' content besides the version change/update. RFE: https://bugs.openjdk.java.net/browse/JDK-8244151 Webrev: http://cr.openjdk.java.net/~valeriep/8244151/webrev.00/ Thanks, Valerie From xuelei.fan at oracle.com Fri May 8 21:29:21 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 8 May 2020 14:29:21 -0700 Subject: [15] RFR JDK-8244151: Update MUSCLE PC/SC-Lite headers to the latest release 1.8.26 In-Reply-To: References: Message-ID: <81c90974-e0c4-031c-3f87-f21169b9327e@oracle.com> Looks fine to me. Xuelei On 5/8/2020 1:14 PM, Valerie Peng wrote: > > Anyone can help with this trivial two-line change? Just updating the > version to 1.8.26 from 1.8.24, no change to the headers' content besides > the version change/update. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8244151 > > Webrev: http://cr.openjdk.java.net/~valeriep/8244151/webrev.00/ > > Thanks, > Valerie From weijun.wang at oracle.com Sat May 9 03:29:40 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 9 May 2020 11:29:40 +0800 Subject: RFR 8244674: Third-party code version check Message-ID: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8244674/webrev.00 I've consolidated 2 old tests into one and added a new case. Thanks, Max From sha.jiang at oracle.com Mon May 11 01:28:21 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 11 May 2020 09:28:21 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests Message-ID: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> Hi, This patch introduces a TSA server, which can work with jarsigner. This server will be used by the following jar signing tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8244683 Webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ Best regards, John Jiang From weijun.wang at oracle.com Mon May 11 02:50:40 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 May 2020 10:50:40 +0800 Subject: RFR 8244674: Third-party code version check In-Reply-To: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> References: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> Message-ID: <196BD31B-61A0-49D7-8597-4A4FB2D7D03A@oracle.com> Can you update the existing TimeStampCheck test to use this class? I know that test can simulate some error conditions. Maybe you can add one or more virtual methods in this class so TimeStampCheck can override them. getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() instead. It will be enhanced to support new algorithm. Param: How about making it a JDK 14 record? Thanks, Max > On May 9, 2020, at 11:29 AM, Weijun Wang wrote: > > Please take a review at > > https://cr.openjdk.java.net/~weijun/8244674/webrev.00 > > I've consolidated 2 old tests into one and added a new case. > > Thanks, > Max > From weijun.wang at oracle.com Mon May 11 02:51:09 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 May 2020 10:51:09 +0800 Subject: RFR 8244674: Third-party code version check In-Reply-To: <196BD31B-61A0-49D7-8597-4A4FB2D7D03A@oracle.com> References: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> <196BD31B-61A0-49D7-8597-4A4FB2D7D03A@oracle.com> Message-ID: <686CD470-8208-4BCC-B66D-3E783040BE50@oracle.com> Sorry, send the wrong reply. Please ignore this mail. > On May 11, 2020, at 10:50 AM, Weijun Wang wrote: > > Can you update the existing TimeStampCheck test to use this class? I know that test can simulate some error conditions. Maybe you can add one or more virtual methods in this class so TimeStampCheck can override them. > > getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() instead. It will be enhanced to support new algorithm. > > Param: How about making it a JDK 14 record? > > Thanks, > Max > > >> On May 9, 2020, at 11:29 AM, Weijun Wang wrote: >> >> Please take a review at >> >> https://cr.openjdk.java.net/~weijun/8244674/webrev.00 >> >> I've consolidated 2 old tests into one and added a new case. >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Mon May 11 02:51:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 11 May 2020 10:51:49 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> Message-ID: Can you update the existing TimeStampCheck test to use this class? I know that test can simulate some error conditions. Maybe you can add one or more virtual methods in this class so TimeStampCheck can override them. getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() instead. It will be enhanced to support new algorithm. Param: How about making it a JDK 14 record? Thanks, Max > On May 11, 2020, at 9:28 AM, sha.jiang at oracle.com wrote: > > Hi, > This patch introduces a TSA server, which can work with jarsigner. > This server will be used by the following jar signing tests. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8244683 > Webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ > > Best regards, > John Jiang > From michele.adduci at openlimit.com Mon May 11 08:50:06 2020 From: michele.adduci at openlimit.com (Michele Adduci) Date: Mon, 11 May 2020 10:50:06 +0200 Subject: ECDSA Algorithms not available with jlink Message-ID: <8d79b4ba-d170-3abd-2343-910c2067992e@openlimit.com> Hello, my name is Michele Adduci and I've freshly subscribed to this mailing list because I'm seeking for advice/help on an issue that arose during the creation of a new application and I couldn't find my answers by searching online. I'm using JDK 14.0.1 GA and trying to create a small redistributable version of my application using the combo jlink + jpackage. In my application, I'm trying to validate some signatures with algorithm such a||||||s SHA256withECDSA, SHA384withECDSA and SHA512withECDSA. If I run my application with the standard JDK distribution, the application is working correctly, but if I run it with the result of jlink+jpackage, I get errors like "SHA256withECSA Signature not available" I've double-checked that libsunec.so is in place under the 'runtime/lib' folder, but I've seen that the SunEC provider isn't loaded at all during the start (just SUN and SunRSA are being loaded). The jlink modules I'm using are: java.desktop,java.smartcardio,java.management,java.sql,java.logging,java.net.http,java.xml.crypto,jdk.crypto.ec and my jlink command is the following one: jlink --strip-debug \ ????? --strip-native-commands \ ????? --bind-services \ ????? --no-header-files \ ????? --no-man-pages \ ????? --compress=2 \ ????? --module-path ${JAVA_HOME}/jmods \ ????? --add-modules java.desktop,java.smartcardio,java.management,java.sql,java.logging,java.net.http,java.xml.crypto,jdk.crypto.ec \ ????? --output jlink-runtime What am I doing wrong? The issue is present in both Windows and Linux - I cannot test on Mac. Kind regards and thanks in advance for your help Michele Adduci -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2242 bytes Desc: S/MIME Cryptographic Signature URL: From sean.mullan at oracle.com Mon May 11 11:42:44 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 11 May 2020 07:42:44 -0400 Subject: ECDSA Algorithms not available with jlink In-Reply-To: <8d79b4ba-d170-3abd-2343-910c2067992e@openlimit.com> References: <8d79b4ba-d170-3abd-2343-910c2067992e@openlimit.com> Message-ID: Hi, Thanks for letting us know about this. We would like to figure out what might be causing this. However, this is not the best forum for debugging issues. Can you please file a bug at https://bugreport.java.com/bugreport/ ? Can you also attach the debug output when running with "java -Djava.security.debug=all ..." to the bug report. A test program that reproduces the issue would also be useful, but probably not necessary unless we cannot reproduce the issue. Thanks, Sean On 5/11/20 4:50 AM, Michele Adduci wrote: > > Hello, > > my name is Michele Adduci and I've freshly subscribed to this mailing > list because I'm seeking for advice/help on an issue that arose during > the creation of a new application and I couldn't find my answers by > searching online. > > I'm using JDK 14.0.1 GA and trying to create a small redistributable > version of my application using the combo jlink + jpackage. > > In my application, I'm trying to validate some signatures with > algorithm such a||||||s SHA256withECDSA, SHA384withECDSA and > SHA512withECDSA. If I run my application with the standard JDK > distribution, the application is working correctly, but if I run it > with the result of jlink+jpackage, I get errors like > > "SHA256withECSA Signature not available" > > I've double-checked that libsunec.so is in place under the > 'runtime/lib' folder, but I've seen that the SunEC provider isn't > loaded at all during the start (just SUN and SunRSA are being loaded). > > The jlink modules I'm using are: > > java.desktop,java.smartcardio,java.management,java.sql,java.logging,java.net.http,java.xml.crypto,jdk.crypto.ec > > and my jlink command is the following one: > > > jlink --strip-debug \ > ????? --strip-native-commands \ > ????? --bind-services \ > ????? --no-header-files \ > ????? --no-man-pages \ > ????? --compress=2 \ > ????? --module-path ${JAVA_HOME}/jmods \ > ????? --add-modules > java.desktop,java.smartcardio,java.management,java.sql,java.logging,java.net.http,java.xml.crypto,jdk.crypto.ec > \ > ????? --output jlink-runtime > > > What am I doing wrong? The issue is present in both Windows and Linux > - I cannot test on Mac. > > Kind regards and thanks in advance for your help > > Michele Adduci > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Mon May 11 14:50:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 11 May 2020 10:50:02 -0400 Subject: RFR 8244674: Third-party code version check In-Reply-To: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> References: <27D3BB46-6554-49CA-B9FC-6833125888B1@oracle.com> Message-ID: Looks good to me. --Sean On 5/8/20 11:29 PM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8244674/webrev.00 > > I've consolidated 2 old tests into one and added a new case. > > Thanks, > Max > From mikael.vidstedt at oracle.com Mon May 11 21:27:18 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 11 May 2020 14:27:18 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <2043A190-C82A-4265-9F5D-CD4142E65814@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> <2043A190-C82A-4265-9F5D-CD4142E65814@oracle.com> Message-ID: <0256918F-22B1-401C-9E2F-D2A740C94F6C@oracle.com> New webrev fixing Basic.policy based on Valeries?s comment: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.03/security/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.03/security.incr/open/webrev/ Cheers, Mikael > On May 7, 2020, at 8:54 PM, Mikael Vidstedt wrote: > > > New webrev: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security.incr/open/webrev/ > > Items to be resolved: > > * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java > > Cheers, > Mikael > >> On May 6, 2020, at 10:05 PM, Mikael Vidstedt wrote: >> >> >> New webrev here: >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ >> >> Items yet to be resolved: >> >> * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java >> >> * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java >> >> * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java >> >> * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java >> >> Cheers, >> Mikael >> >>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >>> >>> >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >>> >>> Background: >>> >>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>> >>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>> >>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>> >>> >>> Testing: >>> >>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>> >>> Cheers, >>> Mikael >>> >>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >> > From bradford.wetmore at oracle.com Tue May 12 00:07:20 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 11 May 2020 17:07:20 -0700 (PDT) Subject: [RFR] 8166597: Crypto support for the EdDSA Signature Algorithm (JEP 339) In-Reply-To: <5175fb0b-cdb0-b3ec-05ba-9cf3cc31d20b@oracle.com> References: <28494de4-f0b8-51a8-af89-e26b27d23ef5@oracle.com> <5175fb0b-cdb0-b3ec-05ba-9cf3cc31d20b@oracle.com> Message-ID: Finally found the bottom of the review. ;) I'll send you minor nits (unused imports/etc.) in a separate email. src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAOperations.java ---------- 136: Here you are calling sun.security.util.ArrayUtil.reverse() (and swap()), but you also added a reverse code in EdDSAPublicKeyImpl.java. I would suggest removing the one in EdDSAPublicKeyImpl and make those calls call into ArrayUtil. 141: Wouldn't it be better to use a temporary variable here instead of 2 array reversals? src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSASignature.java ---------- 115-118: You're calling edKey.getPoint() twice here. 139/150: indent problem. test/jdk/sun/security/ec/ed/TestEdDSA.java ---------- 362: Extra //XXX test/jdk/sun/security/ec/ed/TestEdOps.java ---------- Please put in where you got these test vectors. 206: Could you put in a quick note here why you're doing this? i.e. to avoid draining the system's entropy pool by using a seeded PRNG. Thanks, Brad On 5/4/2020 6:12 PM, Bradford Wetmore wrote: > All minor nits, can be done later if it won't be a problem to make minor > API wording tweaks. > > On 5/4/2020 10:17 AM, Anthony Scarpino wrote: >> On 2/25/20 12:49 PM, Anthony Scarpino wrote: >>> Hi >>> >>> I need a code review for the EdDSA support in JEP 339.? The code >>> builds on the existing java implemented constant time classes used >>> for XDH and the NIST curves.? The change also adds classes to the >>> public API to support EdDSA operations. >>> >> >> Here is the final code review for the JEP. As the JEP is preparing to >> move to Propose-to-Target, if you have comments please state if they >> must be fixed as part of the initial putback. >> >> https://cr.openjdk.java.net/~ascarpino/8166597/webrev.05/ > > Javadoc issues remain throughout java.security.*. > > e.g. EdDCPoint > @param y the y-coordinate, represented using a BigInteger > -> > @param y the y-coordinate, represented using a @{code BigInteger} > > a boolean indicating whether the x-coordinate is odd. > -> > a boolean indicating whether the x-coordinate is odd > > src/java.base/share/classes/sun/security/provider/SHA3.java > ---------- > 114:? Is this comment about the 2-bit suffix still correct? > > src/java.base/share/classes/sun/security/util/KeyUtil.java > ---------- > 2:? Copyright date. > > 110:? Do you want to go with the hardcoded values, or fix the commented > out code? > > src/java.base/share/classes/java/security/interfaces/EdECPrivateKey.java > ---------- > 38:? Very minor nit: EdEC reads a bit awkward to my eye: that term isn't > used in the RFC.? Change or keep.? Maybe: > > An EdEC private key > -> > An Edwards-Curve private key ... > or > An {@code EdECPrivateKey} ... > > Noticed some new typos, or you could do a minor replacement and reduce > some of the duplicate wording. > > 51: > the an {@code Optional} > -> > an {@code Optional} > > 52: > Ff > -> > If > > Alternate idea:? You could take out the second sentence in the method > description above and replace the @return with: > > ??? * @return the private key byte array, or an empty {@code Optional} > if the > ??? *???? key cannot be extracted (e.g. if the provider is a hardware > token > ??? *???? and the private key is not allowed to leave the crypto > boundary). > > This was based on the XEC wording.? Your call/choice. > > src/java.base/share/classes/java/security/interfaces/EdECPublicKey.java > ---------- > 37:? Same comment about EdEC.? Change or keep. > > src/java.base/share/classes/java/security/spec/EdDSAParameterSpec.java > ---------- > 92:? Repeat of previous comment from last week.?? You replied "Ok" but > didn't > see a change yet. > > "...bound to the signature" sounds premature.? This is the context bound > to the EdDSAParameteerSpec, which hasn't been yet bound to the signature. > > src/java.base/share/classes/java/security/spec/EdECPoint.java > ---------- > 38:? Same comment about EdEC.? Change or keep. > > test/jdk/sun/security/ec/ed/TestEdDSA.java > ---------- > Nits: > > 211-212:? Indention problem > > 159/257/258/301:? Extra whitespace. > > 313:? The context value was set correctly from a previous test, but > wouldn't hurt to reiterate it here. > > Brad > From valerie.peng at oracle.com Tue May 12 01:00:36 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 May 2020 18:00:36 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (security) In-Reply-To: <0256918F-22B1-401C-9E2F-D2A740C94F6C@oracle.com> References: <6D3279C1-570F-4175-9B27-66CF60D36057@oracle.com> <2C0906F9-9FCA-4A63-8672-6B9AB29FF492@oracle.com> <2043A190-C82A-4265-9F5D-CD4142E65814@oracle.com> <0256918F-22B1-401C-9E2F-D2A740C94F6C@oracle.com> Message-ID: <062f7012-e417-9858-3702-dd25cd591289@oracle.com> Incremental changes look fine. Thanks, Valerie On 5/11/2020 2:27 PM, Mikael Vidstedt wrote: > New webrev fixing Basic.policy based on Valeries?s comment: > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.03/security/open/webrev/ > incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.03/security.incr/open/webrev/ > > Cheers, > Mikael > >> On May 7, 2020, at 8:54 PM, Mikael Vidstedt wrote: >> >> >> New webrev: >> >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security/open/webrev/ >> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.02/security.incr/open/webrev/ >> >> Items to be resolved: >> >> * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java >> >> Cheers, >> Mikael >> >>> On May 6, 2020, at 10:05 PM, Mikael Vidstedt wrote: >>> >>> >>> New webrev here: >>> >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security/open/webrev/ >>> incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/security.incr/open/webrev/ >>> >>> Items yet to be resolved: >>> >>> * File follow-up to drop $ISA support in src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java >>> >>> * Get confirmation on the ?solaris? property in test/jdk/sun/security/tools/keytool/KeyToolTest.java >>> >>> * Get confirmation if https://bugs.openjdk.java.net/browse/JDK-8039280 is enough to cover test/jdk/sun/security/provider/PolicyParser/PrincipalExpansionError.java >>> >>> * Get confirmation on what to do about the "(secret == null)? block in test/jdk/sun/security/pkcs11/tls/TestPRF.java >>> >>> Cheers, >>> Mikael >>> >>>> On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: >>>> >>>> >>>> Please review this change which implements part of JEP 381: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/security/open/webrev/ >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>>> >>>> >>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>>> >>>> >>>> Background: >>>> >>>> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >>>> >>>> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >>>> >>>> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >>>> >>>> >>>> Testing: >>>> >>>> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >>>> >>>> Cheers, >>>> Mikael >>>> >>>> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From valerie.peng at oracle.com Tue May 12 01:25:22 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 11 May 2020 18:25:22 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> Message-ID: <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> Thanks for filing the bug for PBES2Parameters class. Webrev for 8242151 is updated at: http://cr.openjdk.java.net/~valeriep/8242151/webrev.03/ It addresses: - added KnownOIDs for CurveDB class - updated the KDF parsing code in PBES2Parameters class to match existing behavior - removed the String constants of PKCS9Attribute class and commented out its constructor which takes String argument - use 3rd party aliasing info in AlgorithmId.getName() impl - misc changes to KnownOIDs class regarding the register() impl Thanks, Valerie On 5/6/2020 6:59 PM, Weijun Wang wrote: >> It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? > I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. > > Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. > > --Max > From thejasvi.v.voniadka at oracle.com Tue May 12 02:18:27 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Mon, 11 May 2020 19:18:27 -0700 (PDT) Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> References: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> Message-ID: <5ff0d35a-1a19-4a30-9c59-d7f9d29aba28@default> Ping.. -----Original Message----- From: Thejasvi Voniadka Sent: Friday, May 8, 2020 6:17 AM To: core-libs-dev at openjdk.java.net; jmx-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May someone please sponsor this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE and FINER. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit the full patch to be pushed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From weijun.wang at oracle.com Tue May 12 04:24:30 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 12 May 2020 12:24:30 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> Message-ID: Some files have trailing spaces. KnownOIDs.java: - Is there an order for the fields? I see they are grouped but now always ordered. - Unused "import java.security.Provider;" - 1.3.14.3.2.29 used to be an alias for SHA1withRSA, now it's not. Is this intended? - s/_/-/ in process() is now used for SHA3_224 -> SHA3-224 SHA3_256 -> SHA3-256 SHA3_384 -> SHA3-384 SHA3_512 -> SHA3-512 HmacSHA3_224 -> HmacSHA3-224 HmacSHA3_256 -> HmacSHA3-256 HmacSHA3_384 -> HmacSHA3-384 HmacSHA3_512 -> HmacSHA3-512 SHA3_224withRSA -> SHA3-224withRSA SHA3_256withRSA -> SHA3-256withRSA SHA3_384withRSA -> SHA3-384withRSA SHA3_512withRSA -> SHA3-512withRSA RSASSA_PSS -> RSASSA-PSS CHACHA20_POLY1305 -> CHACHA20-POLY1305 Can we just hardcode the stdName in constructor and remove the substitution? It looks fragile and expensive to me. What if we invent a name like AES_128overSHA3_256? - Now that you've added EC curve names starting with a lowercase letter, can we also use "serverAuth"? - I wonder if we can split the aliases by hand, i.e. modify secp256r1("1.2.840.10045.3.1.7", "secp256r1 [NIST P-256, X9.62 prime256v1]"), to secp256r1("1.2.840.10045.3.1.7", "secp256r1", "NIST P-256", "X9.62 prime256v1"), After all the names will be split into pieces, and we can also use KnownOIDs inside NamedCurve. PBES2Parameters.java: - It's a little pity we need to hardcode several names here. Is 'o.stdName().startsWith("HmacSHA")' enough? This looks like a hack but can save us some hassle if we support more later. Everything else looks fine. Thanks, Max > On May 12, 2020, at 9:25 AM, Valerie Peng wrote: > > Thanks for filing the bug for PBES2Parameters class. > > Webrev for 8242151 is updated at: http://cr.openjdk.java.net/~valeriep/8242151/webrev.03/ > > It addresses: > > - added KnownOIDs for CurveDB class > - updated the KDF parsing code in PBES2Parameters class to match existing behavior > - removed the String constants of PKCS9Attribute class and commented out its constructor which takes String argument > - use 3rd party aliasing info in AlgorithmId.getName() impl > - misc changes to KnownOIDs class regarding the register() impl > > Thanks, > > Valerie > > On 5/6/2020 6:59 PM, Weijun Wang wrote: >>> It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? >> I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. >> >> Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. >> >> --Max >> From sean.mullan at oracle.com Tue May 12 19:40:03 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 12 May 2020 15:40:03 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: Message-ID: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> On 5/5/20 2:29 PM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed? > > RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 > CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 We have previously used the syntax "enable[Extension]" when naming system properties that enable optional extensions. Thus, it seems this name would be more consistent: "jdk.tls.client.enableCertificateAuthoritiesExtension" However, it is a bit long, so maybe we could abbreviate it to CA: "jdk.tls.client.enableCAExtension" Also, it is a bit unfortunate that we have to have a system property to enable it. Can we not enable it based on whether the configured X509TrustManager.getAcceptedIssuers returns a non-empty list? > Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460 > webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/ * src/java.base/share/classes/sun/security/ssl/CertificateRequest.java Missing copyright update. * src/java.base/share/classes/sun/security/ssl/SSLExtension.java 748 // Switch on certificate_authorities extention in ClientHello? typo: s/extention/extension Is the '?' at the end intentional or a typo? * src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java 70 if (!authorities.contains(encodedPrincipal)) { 71 authorities.add(encodedPrincipal); 72 } Is it really necessary to remove duplicates? Seems kind of expensive to iterate over the list every single time for what should be a rare case. 108 X500Principal[] getAuthorities() { Here you know the size of the array up front so you could avoid using a List and populate the array directly. * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java The test doesn't seem to do much, other than make sure you can make a connection if the extension is enabled. Can you test the scenario below where you can show that the extension addresses the issue where the certificate selected may not be the one the peer can accept? --Sean > > The "certificate_authorities" extension is an optional extension > introduced in TLS 1.3 and used to indicate the certificate authorities > (CAs) which an endpoint supports and which SHOULD be used by the > receiving endpoint to guide certificate selection. > > In TLS 1.2, this function is built in the CertificateRequest handshake > massage. > > This function is supported in TLS 1.2 and prior versions. However, it is > not implemented in the TLS 1.3 implementation. Without this function, > the authentication certificate selected may be not the one the peer > could accepted, when there are multiple certificates available. > > Thanks, > Xuelei From xuelei.fan at oracle.com Tue May 12 21:43:44 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 12 May 2020 14:43:44 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ On 5/12/2020 12:40 PM, Sean Mullan wrote: > On 5/5/20 2:29 PM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed? >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 > > We have previously used the syntax "enable[Extension]" when naming > system properties that enable optional extensions. Thus, it seems this > name would be more consistent: > "jdk.tls.client.enableCertificateAuthoritiesExtension" > > However, it is a bit long, so maybe we could abbreviate it to CA: > "jdk.tls.client.enableCAExtension" > "enableCAExtension" looks fine, but it is not as instinctive as "indicateCertificateAuthorities". We used to use "enableXXExtension" because normally there is only one behavior for the extension. However, for the Certificate Authorities extension, it could be requested by server side to indicate client cert selection, or by client side to indicate server cert selection. It is not straightforward to know if "enableCAExtension" means accepting server request, or produce client request. It is not expected to use this extension regularly. Please let me know if you still prefer to use "enableCAExtension". > Also, it is a bit unfortunate that we have to have a system property to > enable it. Can we not enable it based on whether the configured > X509TrustManager.getAcceptedIssuers returns a non-empty list? > We can do that on server side, but there are compatibility impact on client behavior if we did it in client side. See #2 in the "Specification" section. >> Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460 >> webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/ > > * src/java.base/share/classes/sun/security/ssl/CertificateRequest.java > > Missing copyright update. > > * src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > ? 748???????????? // Switch on certificate_authorities extention in > ClientHello? > > typo: s/extention/extension > > Is the '?' at the end intentional or a typo? > Updated. > * > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > > ? 70???????????????? if (!authorities.contains(encodedPrincipal)) { > ? 71???????????????????? authorities.add(encodedPrincipal); > ? 72???????????????? } > > Is it really necessary to remove duplicates? Seems kind of expensive to > iterate over the list every single time for what should be a rare case. > Good point! Update here, and revert the update for CertificateRequest.java as well. > ?108???????? X500Principal[] getAuthorities() { > > Here you know the size of the array up front so you could avoid using a > List and populate the array directly. > Good catch! > * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java > > The test doesn't seem to do much, other than make sure you can make a > connection if the extension is enabled. Can you test the scenario below > where you can show that the extension addresses the issue where the > certificate selected may not be the one the peer can accept? > With this update, the certificate selected must be the one the peer can accept. It may be helpful to add test cases to make sure the connection is terminated if no certification can be selected. I will try to add more test cases. Thanks, Xuelei > --Sean > >> >> The "certificate_authorities" extension is an optional extension >> introduced in TLS 1.3 and used to indicate the certificate authorities >> (CAs) which an endpoint supports and which SHOULD be used by the >> receiving endpoint to guide certificate selection. >> >> In TLS 1.2, this function is built in the CertificateRequest handshake >> massage. >> >> This function is supported in TLS 1.2 and prior versions. However, it >> is not implemented in the TLS 1.3 implementation. Without this >> function, the authentication certificate selected may be not the one >> the peer could accepted, when there are multiple certificates available. >> >> Thanks, >> Xuelei From sha.jiang at oracle.com Wed May 13 00:18:26 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 13 May 2020 08:18:26 +0800 Subject: RFR[15] JDK-8244683: A TSA server used by tests In-Reply-To: References: <2b05e3d5-d49b-f0a9-080e-89b64142d637@oracle.com> Message-ID: <520cfd3f-facf-2879-26f5-770836d2adde@oracle.com> Hi Max, Thanks for your comments! Please review the updated webrev: http://cr.openjdk.java.net/~jjiang/8244683/webrev.02/ The codes are refactored significantly. On 2020/5/11 10:51, Weijun Wang wrote: > Can you update the existing TimeStampCheck test to use this class? I know that test can simulate some error conditions. Maybe you can add one or more virtual methods in this class so TimeStampCheck can override them. This test is updated to use this TSA server. A new introduced class, namely TsaInterceptor, defines some extension points for the signing. > getDefaultSigAlgo(): Please call AlgorithmId.getDefaultSigAlgForKey() instead. It will be enhanced to support new algorithm. Fixed. > Param: How about making it a JDK 14 record? In the updated webrev, this class has changed to TsaParam. The fields are not final, and especially this class could be extended by tests. With my understanding, this language feature may not be applicable for this scenario . Best regards, John Jiang > Thanks, > Max > >> On May 11, 2020, at 9:28 AM,sha.jiang at oracle.com wrote: >> >> Hi, >> This patch introduces a TSA server, which can work with jarsigner. >> This server will be used by the following jar signing tests. >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8244683 >> Webrev:http://cr.openjdk.java.net/~jjiang/8244683/webrev.00/ >> >> Best regards, >> John Jiang >> From sibabrata.sahoo at oracle.com Wed May 13 09:55:37 2020 From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com) Date: Wed, 13 May 2020 15:25:37 +0530 Subject: [15] RFR: 8209632: Develop new tests for EdDSA API Message-ID: Hi Tony, Please review the patch of new Tests developed for EdDSA, JBS: https://bugs.openjdk.java.net/browse/JDK-8209632 Webrev: http://cr.openjdk.java.net/~ssahoo/8209632/webrev.00/ Thanks, Siba -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Wed May 13 10:00:06 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 13 May 2020 10:00:06 +0000 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: Hello Xuelei, I?m not a reviewer but I have some comment which could be helpful for your implementation. We?ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations. According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with ?illegal_parameter? fatal alert. This issue can be easily reproduced on the client side: 1) put additional certificates into cacerts file, about 200 certs in total, 2) enable certificate_authorities extension in the ClientHello message 3) connect to https://www.google.com [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java [2] - https://tools.ietf.org/html/rfc8446#page-45 Thank you Alexey > On 13 May 2020, at 00:43, Xuelei Fan wrote: > > Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ > > On 5/12/2020 12:40 PM, Sean Mullan wrote: >> On 5/5/20 2:29 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 >> We have previously used the syntax "enable[Extension]" when naming system properties that enable optional extensions. Thus, it seems this name would be more consistent: "jdk.tls.client.enableCertificateAuthoritiesExtension" >> However, it is a bit long, so maybe we could abbreviate it to CA: "jdk.tls.client.enableCAExtension" > "enableCAExtension" looks fine, but it is not as instinctive as "indicateCertificateAuthorities". > > We used to use "enableXXExtension" because normally there is only one behavior for the extension. However, for the Certificate Authorities extension, it could be requested by server side to indicate client cert selection, or by client side to indicate server cert selection. It is not straightforward to know if "enableCAExtension" means accepting server request, or produce client request. > > It is not expected to use this extension regularly. > > Please let me know if you still prefer to use "enableCAExtension". > >> Also, it is a bit unfortunate that we have to have a system property to enable it. Can we not enable it based on whether the configured X509TrustManager.getAcceptedIssuers returns a non-empty list? > We can do that on server side, but there are compatibility impact on client behavior if we did it in client side. See #2 in the "Specification" section. > >>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460 >>> webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/ >> * src/java.base/share/classes/sun/security/ssl/CertificateRequest.java >> Missing copyright update. >> * src/java.base/share/classes/sun/security/ssl/SSLExtension.java >> 748 // Switch on certificate_authorities extention in ClientHello? >> typo: s/extention/extension >> Is the '?' at the end intentional or a typo? > Updated. > >> * src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java 70 if (!authorities.contains(encodedPrincipal)) { >> 71 authorities.add(encodedPrincipal); >> 72 } >> Is it really necessary to remove duplicates? Seems kind of expensive to iterate over the list every single time for what should be a rare case. > Good point! Update here, and revert the update for CertificateRequest.java as well. > >> 108 X500Principal[] getAuthorities() { >> Here you know the size of the array up front so you could avoid using a List and populate the array directly. > Good catch! > >> * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java >> The test doesn't seem to do much, other than make sure you can make a connection if the extension is enabled. Can you test the scenario below where you can show that the extension addresses the issue where the certificate selected may not be the one the peer can accept? > With this update, the certificate selected must be the one the peer can accept. It may be helpful to add test cases to make sure the connection is terminated if no certification can be selected. I will try to add more test cases. > > Thanks, > Xuelei > >> --Sean >>> >>> The "certificate_authorities" extension is an optional extension introduced in TLS 1.3 and used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection. >>> >>> In TLS 1.2, this function is built in the CertificateRequest handshake massage. >>> >>> This function is supported in TLS 1.2 and prior versions. However, it is not implemented in the TLS 1.3 implementation. Without this function, the authentication certificate selected may be not the one the peer could accepted, when there are multiple certificates available. >>> >>> Thanks, >>> Xuelei -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Wed May 13 13:38:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 May 2020 09:38:02 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> On 5/12/20 5:43 PM, Xuelei Fan wrote: > Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ > > On 5/12/2020 12:40 PM, Sean Mullan wrote: >> On 5/5/20 2:29 PM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed? >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 >> >> We have previously used the syntax "enable[Extension]" when naming >> system properties that enable optional extensions. Thus, it seems this >> name would be more consistent: >> "jdk.tls.client.enableCertificateAuthoritiesExtension" >> >> However, it is a bit long, so maybe we could abbreviate it to CA: >> "jdk.tls.client.enableCAExtension" >> > "enableCAExtension" looks fine, but it is not as instinctive as > "indicateCertificateAuthorities". I think naming consistency is important. > We used to use "enableXXExtension" because normally there is only one > behavior for the extension.? However, for the Certificate Authorities > extension, it could be requested by server side to indicate client cert > selection, or by client side to indicate server cert selection.? It is > not straightforward to know if "enableCAExtension" means accepting > server request, or produce client request. But doesn't "jdk.tls.client" mean enable the extension on the client side? I am not following why the word "indicate" helps better distinguish between setting the extension on the client or server side. > It is not expected to use this extension regularly. > > Please let me know if you still prefer to use "enableCAExtension". > >> Also, it is a bit unfortunate that we have to have a system property >> to enable it. Can we not enable it based on whether the configured >> X509TrustManager.getAcceptedIssuers returns a non-empty list? >> > We can do that on server side, but there are compatibility impact on > client behavior if we did it in client side.? See #2 in the > "Specification" section. But doesn't the default JDK PKIX TrustManager throw a fatal exception and close the connection if the server's certificate cannot be validated? Could we check if the PKIX TrustManager is being used? If a client wants to accept self-signed or untrusted server certificates, I would have expected them to have to use a custom X509TrustManager that allows that, and that getAcceptedIssuers() should return an empty List. Is that not is what is typically done in practice? --Sean From anthony.scarpino at oracle.com Wed May 13 16:41:48 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 May 2020 09:41:48 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: On 4/30/20 10:19 AM, Xuelei Fan wrote: > Hi, > > Could I get the following update reviewed: > ??? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ > > For TLS 1.3 full handshake, if the last handshake flight wraps the > Finished together with other handshake message, for example client > certificate, the flight could be wrapped and encrypted in one record and > delegated tasks would be used.? There is no chance to return FINISHED > handshake status with SSLEngine.(un)wrap(). However, per the > HandshakeStatus.FINISHED specification, this handshake status is only > generated by a call to SSLEngine.wrap()/unwrap() and it is never > generated by SSLEngine.getHandshakeStatus(). > > In order to workaround this case for TLS 1.3, the FINISHED status could > present with SSLEngine.wrap() while delivering of the NewSessionTicket > post-handshake message.? If this post-handshake message is not needed, a > follow-on SSLEngine.wrap() should be called to indicate the FINISHED > handshake status.? Although this special SSLEngine.wrap() should not > consume or produce any application or network data. > > I also clean up some debug log, names and code style a little bit. > > The update could be confirmed with Tomcat and Firefox in private mode, > as described in the bug description.? As this case happens only when > psk_key_exchange_modes does not present, which is not a behavior > supported by JDK, I did not find a workaround for a new regression test > yet.? I added the labels, noreg-external and noreg-hard. > > Thanks, > Xuelei I do not fully understand the situation, mostly because of SSLEngine semantics. In normal operation, does is HandshakeStatus.FINISHED returned when Finished is received or after the NewSessionTicket message? My understanding would have been after Finished because NST is suppose to be a post handshake message. So in this case there is no problem, correct? I'm trying to figure out why you need an empty NST. Is the problem when a number of messages are bundled together. For example, the Finished message with a partial NST, then Finished isn't processed and both sides are waiting? Or do both sides continue normal traffic, it's jut the HandshakeStatus.FINISHED is one operation behind? One code comment so far: 433: The debug message purpose was to say the NST is a stateless ticket and not a preshared key. Can we keep "stateless" in the message? Tony From valerie.peng at oracle.com Wed May 13 19:17:59 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 13 May 2020 12:17:59 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> Message-ID: <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> Hi Max, Thanks for review~ Webrev is updated accordingly for your comments: http://cr.openjdk.java.net/~valeriep/8242151/webrev.04/ Please find replies inline below: On 5/11/2020 9:24 PM, Weijun Wang wrote: > Some files have trailing spaces. Yes, I generally check for white spaces before integration. Now that you mention it, I checked and included this in webrev.04. > KnownOIDs.java: > > - Is there an order for the fields? I see they are grouped but now always ordered. Well, the fields are grouped based on their oid with comments stating their parent node value. Within the same group, they are ordered so it's easier to spot missing/gap values. The less used ones are placed at the end. > > - Unused "import java.security.Provider;" Removed. > - 1.3.14.3.2.29 used to be an alias for SHA1withRSA, now it's not. Is this intended? Good catch. I added the necessary entry to SecurityProviderConstants class now. > - s/_/-/ in process() is now used for > > SHA3_224 -> SHA3-224 > SHA3_256 -> SHA3-256 > SHA3_384 -> SHA3-384 > SHA3_512 -> SHA3-512 > HmacSHA3_224 -> HmacSHA3-224 > HmacSHA3_256 -> HmacSHA3-256 > HmacSHA3_384 -> HmacSHA3-384 > HmacSHA3_512 -> HmacSHA3-512 > SHA3_224withRSA -> SHA3-224withRSA > SHA3_256withRSA -> SHA3-256withRSA > SHA3_384withRSA -> SHA3-384withRSA > SHA3_512withRSA -> SHA3-512withRSA > RSASSA_PSS -> RSASSA-PSS > CHACHA20_POLY1305 -> CHACHA20-POLY1305 > > Can we just hardcode the stdName in constructor and remove the substitution? It looks fragile and expensive to me. What if we invent a name like AES_128overSHA3_256? The process() code is also used as "/" is not allowed as variable names. Anyway, I have removed the process() method and hardcoded all relevant entries with a standard name. > - Now that you've added EC curve names starting with a lowercase letter, can we also use "serverAuth"? Alright, if that's what you prefer. I added a comment at the top of KnownOIDs class to explain why some starts with lowercase. > - I wonder if we can split the aliases by hand, i.e. modify > > secp256r1("1.2.840.10045.3.1.7", > "secp256r1 [NIST P-256, X9.62 prime256v1]"), > > to > > secp256r1("1.2.840.10045.3.1.7", > "secp256r1", "NIST P-256", "X9.62 prime256v1"), > > After all the names will be split into pieces, and we can also use KnownOIDs inside NamedCurve. I switched to this approach, however, there is one minor behavior change - to avoid the pattern parsing code (which I suppose is the main benefit of this approach), the NamedCurve.getName() method now returns the stdName of the KnownOIDs enum instead of the formatted string which contains both stdName and aliases. I also added NamedCurve.getAliases() method which returns the aliases of the KnownOIDs enum. This touchs SunEC, CurveDB, NamedCurve, and KnownOIDs classes. > PBES2Parameters.java: > > - It's a little pity we need to hardcode several names here. Is 'o.stdName().startsWith("HmacSHA")' enough? This looks like a hack but can save us some hassle if we support more later. Well, I prefer to keep the current changes as it enforces the same restriction as the existing impl. With the "startsWith" check, it is looser as it won't reject HmacSHA3-xxx ones. If we support more later, this should error out and should be obvious that an update is required. Thanks, Valerie > > Everything else looks fine. > > Thanks, > Max > > > >> On May 12, 2020, at 9:25 AM, Valerie Peng wrote: >> >> Thanks for filing the bug for PBES2Parameters class. >> >> Webrev for 8242151 is updated at: http://cr.openjdk.java.net/~valeriep/8242151/webrev.03/ >> >> It addresses: >> >> - added KnownOIDs for CurveDB class >> - updated the KDF parsing code in PBES2Parameters class to match existing behavior >> - removed the String constants of PKCS9Attribute class and commented out its constructor which takes String argument >> - use 3rd party aliasing info in AlgorithmId.getName() impl >> - misc changes to KnownOIDs class regarding the register() impl >> >> Thanks, >> >> Valerie >> >> On 5/6/2020 6:59 PM, Weijun Wang wrote: >>>> It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? >>> I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. >>> >>> Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. >>> >>> --Max >>> From xuelei.fan at oracle.com Wed May 13 20:16:25 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 May 2020 13:16:25 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> Message-ID: <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.02/ The CSR and release note were updated accordingly, to use the new system property. On 5/13/2020 6:38 AM, Sean Mullan wrote: > On 5/12/20 5:43 PM, Xuelei Fan wrote: >> Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ >> >> On 5/12/2020 12:40 PM, Sean Mullan wrote: >>> On 5/5/20 2:29 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Could I get the following update reviewed? >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 >>> >>> We have previously used the syntax "enable[Extension]" when naming >>> system properties that enable optional extensions. Thus, it seems >>> this name would be more consistent: >>> "jdk.tls.client.enableCertificateAuthoritiesExtension" >>> >>> However, it is a bit long, so maybe we could abbreviate it to CA: >>> "jdk.tls.client.enableCAExtension" >>> >> "enableCAExtension" looks fine, but it is not as instinctive as >> "indicateCertificateAuthorities". > > I think naming consistency is important. > >> We used to use "enableXXExtension" because normally there is only one >> behavior for the extension.? However, for the Certificate Authorities >> extension, it could be requested by server side to indicate client >> cert selection, or by client side to indicate server cert selection. >> It is not straightforward to know if "enableCAExtension" means >> accepting server request, or produce client request. > > But doesn't "jdk.tls.client" mean enable the extension on the client side? > > I am not following why the word "indicate" helps better distinguish > between setting the extension on the client or server side. > Okay, updated to use "enableCAExtension" for the property name. >> It is not expected to use this extension regularly. >> >> Please let me know if you still prefer to use "enableCAExtension". >> >>> Also, it is a bit unfortunate that we have to have a system property >>> to enable it. Can we not enable it based on whether the configured >>> X509TrustManager.getAcceptedIssuers returns a non-empty list? >>> >> We can do that on server side, but there are compatibility impact on >> client behavior if we did it in client side.? See #2 in the >> "Specification" section. > > But doesn't the default JDK PKIX TrustManager throw a fatal exception > and close the connection if the server's certificate cannot be > validated? Could we check if the PKIX TrustManager is being used? > Yes, the trust manager could throw a fatal exception and close the connection if the trust cannot be established. The fallback mechanism is implemented in the customized trust manager, that if users accept the cert, the cert is trusted, and no exception and the handshaking continued. It is too later to fallback after the connection closed. > If a client wants to accept self-signed or untrusted server > certificates, I would have expected them to have to use a custom > X509TrustManager that allows that, and that getAcceptedIssuers() should > return an empty List. Is that not is what is typically done in practice? > Yes, customized trust manager is used to accept users manually selection. As the users may also want to accept normal certificate without manually involved, so getAcceptedIssuers() should respect those CA as well. Xuelei From xuelei.fan at oracle.com Wed May 13 20:22:22 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 May 2020 13:22:22 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: Hi Alexey, It a good information for interop. Thank you! I will see how to workaround it. Thanks, Xuelei On 5/13/2020 3:00 AM, Alexey Bakhtin wrote: > Hello Xuelei, > > I?m not a reviewer but I have some comment which could be helpful for your implementation. > We?ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations. > According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with ?illegal_parameter? fatal alert. > This issue can be easily reproduced on the client side: > 1) put additional certificates into cacerts file, about 200 certs in total, > 2) enable certificate_authorities extension in the ClientHello message > 3) connect to https://www.google.com > > [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java > [2] - https://tools.ietf.org/html/rfc8446#page-45 > > Thank you > Alexey > >> On 13 May 2020, at 00:43, Xuelei Fan wrote: >> >> Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ >> >> On 5/12/2020 12:40 PM, Sean Mullan wrote: >>> On 5/5/20 2:29 PM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Could I get the following update reviewed? >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 >>> We have previously used the syntax "enable[Extension]" when naming system properties that enable optional extensions. Thus, it seems this name would be more consistent: "jdk.tls.client.enableCertificateAuthoritiesExtension" >>> However, it is a bit long, so maybe we could abbreviate it to CA: "jdk.tls.client.enableCAExtension" >> "enableCAExtension" looks fine, but it is not as instinctive as "indicateCertificateAuthorities". >> >> We used to use "enableXXExtension" because normally there is only one behavior for the extension. However, for the Certificate Authorities extension, it could be requested by server side to indicate client cert selection, or by client side to indicate server cert selection. It is not straightforward to know if "enableCAExtension" means accepting server request, or produce client request. >> >> It is not expected to use this extension regularly. >> >> Please let me know if you still prefer to use "enableCAExtension". >> >>> Also, it is a bit unfortunate that we have to have a system property to enable it. Can we not enable it based on whether the configured X509TrustManager.getAcceptedIssuers returns a non-empty list? >> We can do that on server side, but there are compatibility impact on client behavior if we did it in client side. See #2 in the "Specification" section. >> >>>> Release-note: https://bugs.openjdk.java.net/browse/JDK-8244460 >>>> webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.00/ >>> * src/java.base/share/classes/sun/security/ssl/CertificateRequest.java >>> Missing copyright update. >>> * src/java.base/share/classes/sun/security/ssl/SSLExtension.java >>> 748 // Switch on certificate_authorities extention in ClientHello? >>> typo: s/extention/extension >>> Is the '?' at the end intentional or a typo? >> Updated. >> >>> * src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java 70 if (!authorities.contains(encodedPrincipal)) { >>> 71 authorities.add(encodedPrincipal); >>> 72 } >>> Is it really necessary to remove duplicates? Seems kind of expensive to iterate over the list every single time for what should be a rare case. >> Good point! Update here, and revert the update for CertificateRequest.java as well. >> >>> 108 X500Principal[] getAuthorities() { >>> Here you know the size of the array up front so you could avoid using a List and populate the array directly. >> Good catch! >> >>> * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java >>> The test doesn't seem to do much, other than make sure you can make a connection if the extension is enabled. Can you test the scenario below where you can show that the extension addresses the issue where the certificate selected may not be the one the peer can accept? >> With this update, the certificate selected must be the one the peer can accept. It may be helpful to add test cases to make sure the connection is terminated if no certification can be selected. I will try to add more test cases. >> >> Thanks, >> Xuelei >> >>> --Sean >>>> >>>> The "certificate_authorities" extension is an optional extension introduced in TLS 1.3 and used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection. >>>> >>>> In TLS 1.2, this function is built in the CertificateRequest handshake massage. >>>> >>>> This function is supported in TLS 1.2 and prior versions. However, it is not implemented in the TLS 1.3 implementation. Without this function, the authentication certificate selected may be not the one the peer could accepted, when there are multiple certificates available. >>>> >>>> Thanks, >>>> Xuelei > From xuelei.fan at oracle.com Wed May 13 20:44:20 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 May 2020 13:44:20 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: On 5/13/2020 9:41 AM, Anthony Scarpino wrote: > On 4/30/20 10:19 AM, Xuelei Fan wrote: >> Hi, >> >> Could I get the following update reviewed: >> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >> >> For TLS 1.3 full handshake, if the last handshake flight wraps the >> Finished together with other handshake message, for example client >> certificate, the flight could be wrapped and encrypted in one record >> and delegated tasks would be used.? There is no chance to return >> FINISHED handshake status with SSLEngine.(un)wrap(). However, per the >> HandshakeStatus.FINISHED specification, this handshake status is only >> generated by a call to SSLEngine.wrap()/unwrap() and it is never >> generated by SSLEngine.getHandshakeStatus(). >> >> In order to workaround this case for TLS 1.3, the FINISHED status >> could present with SSLEngine.wrap() while delivering of the >> NewSessionTicket post-handshake message.? If this post-handshake >> message is not needed, a follow-on SSLEngine.wrap() should be called >> to indicate the FINISHED handshake status.? Although this special >> SSLEngine.wrap() should not consume or produce any application or >> network data. >> >> I also clean up some debug log, names and code style a little bit. >> >> The update could be confirmed with Tomcat and Firefox in private mode, >> as described in the bug description.? As this case happens only when >> psk_key_exchange_modes does not present, which is not a behavior >> supported by JDK, I did not find a workaround for a new regression >> test yet.? I added the labels, noreg-external and noreg-hard. >> >> Thanks, >> Xuelei > > I do not fully understand the situation, mostly because of SSLEngine > semantics.? In normal operation, does is HandshakeStatus.FINISHED > returned when Finished is received or after the NewSessionTicket > message? Not exactly. For TLS 1.2, FINISHED will be returned with unwrap() of the finished handshake message. However, for TLS 1.3, FINISHED will be returned any longer, because the finished handshake message is wrapped with certificate message in one record. For TLS 1.3: 1. client send certificate, certificate verify and finished handshake message in one record. 2. server call unwrap(), and return NEED_TASK to handle the certificate and certificate verify. So, no more FINISHED for the unwrap() return. It is fine if there is a after NewSessionTicket message. The wrap() for the post-handshake message will return FINISHED. The bug reported is a special one that the Firefox is run in private mode, which does not request NewSessionTicket. So there is no post-handshake generated and sent in server side. Then, there is no FINISHED can be used if applications depends on it. To workaround the case, a dummy wrap() or unwrap() could be used to get the FINISHED. The wrap() or unwrap() actually do nothing but return the FINISHED status. > My understanding would have been after Finished because NST is > suppose to be a post handshake message.? So in this case there is no > problem, correct? > Correct. > I'm trying to figure out why you need an empty NST.? Is the problem when > a number of messages are bundled together.? For example, the Finished > message with a partial NST, then Finished isn't processed and both sides > are waiting?? Or do both sides continue normal traffic, it's jut the > HandshakeStatus.FINISHED is one operation behind? > It should be fine as empty NST is just a signal to indicate the next call to wrap(). The next call to wrap() just use the signal for the return of FINISHED status, not network data produced, delivered or consumed. > > One code comment so far: > 433:? The debug message purpose was to say the NST is a stateless ticket > and not a preshared key.? Can we keep "stateless" in the message? > NewSessionTicket.java? Sure, I may just want to shrink to one line. It was not intended. Xuelei From sean.mullan at oracle.com Wed May 13 21:11:04 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 13 May 2020 17:11:04 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> Message-ID: <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> On 5/13/20 4:16 PM, Xuelei Fan wrote: > Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.02/ > > The CSR and release note were updated accordingly, to use the new system > property. > > On 5/13/2020 6:38 AM, Sean Mullan wrote: >> On 5/12/20 5:43 PM, Xuelei Fan wrote: >>> Updated webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.01/ >>> >>> On 5/12/2020 12:40 PM, Sean Mullan wrote: >>>> On 5/5/20 2:29 PM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Could I get the following update reviewed? >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8206925 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8244441 >>>> >>>> We have previously used the syntax "enable[Extension]" when naming >>>> system properties that enable optional extensions. Thus, it seems >>>> this name would be more consistent: >>>> "jdk.tls.client.enableCertificateAuthoritiesExtension" >>>> >>>> However, it is a bit long, so maybe we could abbreviate it to CA: >>>> "jdk.tls.client.enableCAExtension" >>>> >>> "enableCAExtension" looks fine, but it is not as instinctive as >>> "indicateCertificateAuthorities". >> >> I think naming consistency is important. >> >>> We used to use "enableXXExtension" because normally there is only one >>> behavior for the extension.? However, for the Certificate Authorities >>> extension, it could be requested by server side to indicate client >>> cert selection, or by client side to indicate server cert selection. >>> It is not straightforward to know if "enableCAExtension" means >>> accepting server request, or produce client request. >> >> But doesn't "jdk.tls.client" mean enable the extension on the client >> side? >> >> I am not following why the word "indicate" helps better distinguish >> between setting the extension on the client or server side. >> > Okay, updated to use "enableCAExtension" for the property name. > >>> It is not expected to use this extension regularly. >>> >>> Please let me know if you still prefer to use "enableCAExtension". >>> >>>> Also, it is a bit unfortunate that we have to have a system property >>>> to enable it. Can we not enable it based on whether the configured >>>> X509TrustManager.getAcceptedIssuers returns a non-empty list? >>>> >>> We can do that on server side, but there are compatibility impact on >>> client behavior if we did it in client side.? See #2 in the >>> "Specification" section. >> >> But doesn't the default JDK PKIX TrustManager throw a fatal exception >> and close the connection if the server's certificate cannot be >> validated? Could we check if the PKIX TrustManager is being used? >> > Yes, the trust manager could throw a fatal exception and close the > connection if the trust cannot be established.? The fallback mechanism > is implemented in the customized trust manager, that if users accept the > cert, the cert is trusted, and no exception and the handshaking > continued.? It is too later to fallback after the connection closed. >> If a client wants to accept self-signed or untrusted server >> certificates, I would have expected them to have to use a custom >> X509TrustManager that allows that, and that getAcceptedIssuers() >> should return an empty List. Is that not is what is typically done in >> practice? >> > Yes, customized trust manager is used to accept users manually > selection.? As the users may also want to accept normal certificate > without manually involved, so getAcceptedIssuers() should respect those > CA as well. I see. Out of curiosity, have you checked how other implementations handle this extension? For web browsers, they typically give the user the option of proceeding if the server certificate is not trusted. Seems to be a bit of a configuration dilemma as you may want this extension enabled for certain sites that have multiple certificates, but not as a general default because then you wouldn't be able to connect to untrusted sites (at your own risk of course). I wonder if it would have been better for the RFC to allow the server to treat this extension more as a hint, and still return its chain if an acceptable certificate could not be found. --Sean From xuelei.fan at oracle.com Wed May 13 21:20:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 13 May 2020 14:20:14 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> Message-ID: On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>> It is not expected to use this extension regularly. >>>> >>>> Please let me know if you still prefer to use "enableCAExtension". >>>> >>>>> Also, it is a bit unfortunate that we have to have a system >>>>> property to enable it. Can we not enable it based on whether the >>>>> configured X509TrustManager.getAcceptedIssuers returns a non-empty >>>>> list? >>>>> >>>> We can do that on server side, but there are compatibility impact on >>>> client behavior if we did it in client side.? See #2 in the >>>> "Specification" section. >>> >>> But doesn't the default JDK PKIX TrustManager throw a fatal exception >>> and close the connection if the server's certificate cannot be >>> validated? Could we check if the PKIX TrustManager is being used? >>> >> Yes, the trust manager could throw a fatal exception and close the >> connection if the trust cannot be established.? The fallback mechanism >> is implemented in the customized trust manager, that if users accept >> the cert, the cert is trusted, and no exception and the handshaking >> continued.? It is too later to fallback after the connection closed. > >>> If a client wants to accept self-signed or untrusted server >>> certificates, I would have expected them to have to use a custom >>> X509TrustManager that allows that, and that getAcceptedIssuers() >>> should return an empty List. Is that not is what is typically done in >>> practice? >>> >> Yes, customized trust manager is used to accept users manually >> selection.? As the users may also want to accept normal certificate >> without manually involved, so getAcceptedIssuers() should respect >> those CA as well. > > I see. Out of curiosity, have you checked how other implementations > handle this extension? For web browsers, they typically give the user > the option of proceeding if the server certificate is not trusted. Seems > to be a bit of a configuration dilemma as you may want this extension > enabled for certain sites that have multiple certificates, but not as a > general default because then you wouldn't be able to connect to > untrusted sites (at your own risk of course). I wonder if it would have > been better for the RFC to allow the server to treat this extension more > as a hint, and still return its chain if an acceptable certificate could > not be found. If it is treated as a hint, then it might be better no have this extension. I checked with browsers, the extension is not present in ClientHello. For JDK, I would not expect a lot use of this extension in client side. It is just designed to workaround a few cases, just as you mentioned above. Xuelei From valerie.peng at oracle.com Thu May 14 00:16:44 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 13 May 2020 17:16:44 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> Message-ID: <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> I will take a look. Valerie On 5/8/2020 3:39 AM, Weijun Wang wrote: > Found an existing test I can update. Webrev updated at > > http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ > > Thanks, > Max > >> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >> >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >> >> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >> >> I also take this chance to make some format change. >> >> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >> >> Thanks, >> Max >> From weijun.wang at oracle.com Thu May 14 02:03:08 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 May 2020 10:03:08 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> Message-ID: > On May 14, 2020, at 3:17 AM, Valerie Peng wrote: > > Hi Max, > > Thanks for review~ > > Webrev is updated accordingly for your comments: http://cr.openjdk.java.net/~valeriep/8242151/webrev.04/ > > Please find replies inline below: > > On 5/11/2020 9:24 PM, Weijun Wang wrote: >> Some files have trailing spaces. > Yes, I generally check for white spaces before integration. Now that you mention it, I checked and included this in webrev.04. >> KnownOIDs.java: >> >> - Is there an order for the fields? I see they are grouped but now always ordered. > > Well, the fields are grouped based on their oid with comments stating their parent node value. Within the same group, they are ordered so it's easier to spot missing/gap values. > > The less used ones are placed at the end. > >> >> - Unused "import java.security.Provider;" > Removed. >> - 1.3.14.3.2.29 used to be an alias for SHA1withRSA, now it's not. Is this intended? > Good catch. I added the necessary entry to SecurityProviderConstants class now. >> - s/_/-/ in process() is now used for >> >> SHA3_224 -> SHA3-224 >> SHA3_256 -> SHA3-256 >> SHA3_384 -> SHA3-384 >> SHA3_512 -> SHA3-512 >> HmacSHA3_224 -> HmacSHA3-224 >> HmacSHA3_256 -> HmacSHA3-256 >> HmacSHA3_384 -> HmacSHA3-384 >> HmacSHA3_512 -> HmacSHA3-512 >> SHA3_224withRSA -> SHA3-224withRSA >> SHA3_256withRSA -> SHA3-256withRSA >> SHA3_384withRSA -> SHA3-384withRSA >> SHA3_512withRSA -> SHA3-512withRSA >> RSASSA_PSS -> RSASSA-PSS >> CHACHA20_POLY1305 -> CHACHA20-POLY1305 >> >> Can we just hardcode the stdName in constructor and remove the substitution? It looks fragile and expensive to me. What if we invent a name like AES_128overSHA3_256? > The process() code is also used as "/" is not allowed as variable names. Anyway, I have removed the process() method and hardcoded all relevant entries with a standard name. I was OK with the $ -> / conversion, but it's up to you to decide whether to keep that. >> - Now that you've added EC curve names starting with a lowercase letter, can we also use "serverAuth"? > Alright, if that's what you prefer. I added a comment at the top of KnownOIDs class to explain why some starts with lowercase. >> - I wonder if we can split the aliases by hand, i.e. modify >> >> secp256r1("1.2.840.10045.3.1.7", >> "secp256r1 [NIST P-256, X9.62 prime256v1]"), >> >> to >> >> secp256r1("1.2.840.10045.3.1.7", >> "secp256r1", "NIST P-256", "X9.62 prime256v1"), >> >> After all the names will be split into pieces, and we can also use KnownOIDs inside NamedCurve. > > I switched to this approach, however, there is one minor behavior change - to avoid the pattern parsing code (which I suppose is the main benefit of this approach), the NamedCurve.getName() method now returns the stdName of the KnownOIDs enum instead of the formatted string which contains both stdName and aliases. I also added NamedCurve.getAliases() method which returns the aliases of the KnownOIDs enum. This touchs SunEC, CurveDB, NamedCurve, and KnownOIDs classes. CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! :-) > >> PBES2Parameters.java: >> >> - It's a little pity we need to hardcode several names here. Is 'o.stdName().startsWith("HmacSHA")' enough? This looks like a hack but can save us some hassle if we support more later. > > Well, I prefer to keep the current changes as it enforces the same restriction as the existing impl. With the "startsWith" check, it is looser as it won't reject HmacSHA3-xxx ones. If we support more later, this should error out and should be obvious that an update is required. Fair enough. Everything else looks fine to me. Thanks, Max > > Thanks, > > Valerie > >> >> Everything else looks fine. >> >> Thanks, >> Max >> >> >> >>> On May 12, 2020, at 9:25 AM, Valerie Peng wrote: >>> >>> Thanks for filing the bug for PBES2Parameters class. >>> >>> Webrev for 8242151 is updated at: http://cr.openjdk.java.net/~valeriep/8242151/webrev.03/ >>> >>> It addresses: >>> >>> - added KnownOIDs for CurveDB class >>> - updated the KDF parsing code in PBES2Parameters class to match existing behavior >>> - removed the String constants of PKCS9Attribute class and commented out its constructor which takes String argument >>> - use 3rd party aliasing info in AlgorithmId.getName() impl >>> - misc changes to KnownOIDs class regarding the register() impl >>> >>> Thanks, >>> >>> Valerie >>> >>> On 5/6/2020 6:59 PM, Weijun Wang wrote: >>>>> It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? >>>> I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. >>>> >>>> Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. >>>> >>>> --Max From anthony.scarpino at oracle.com Thu May 14 03:30:40 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 13 May 2020 20:30:40 -0700 Subject: [15] RFR: 8209632: Develop new tests for EdDSA API In-Reply-To: References: Message-ID: <3b4f7260-b596-ea23-0078-f125f6998205@oracle.com> On 5/13/20 2:55 AM, sibabrata.sahoo at oracle.com wrote: > Hi Tony, > > Please review the patch of new Tests developed for EdDSA, > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209632 > Webrev: http://cr.openjdk.java.net/~ssahoo/8209632/webrev.00/ > > Thanks, > Siba > > > Looking through the tests, I didn't see any problems. They looked good to me. Just one thing caught my eye. EdDSANegativeTest.java: I noticed you have InvaliPrivateKey and InvaliPublicKey. I assume that was not intentional to leave the 'd' out. I don't mind it being left out if that was your choice. thanks Tony From sibabrata.sahoo at oracle.com Thu May 14 04:50:55 2020 From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com) Date: Thu, 14 May 2020 10:20:55 +0530 Subject: [15] RFR: 8209632: Develop new tests for EdDSA API In-Reply-To: <3b4f7260-b596-ea23-0078-f125f6998205@oracle.com> References: <3b4f7260-b596-ea23-0078-f125f6998205@oracle.com> Message-ID: It?s a typo issue. I can add missing character ?d? before pushing the change. Thanks, Siba > On 14-May-2020, at 9:00 AM, Anthony Scarpino wrote: > > On 5/13/20 2:55 AM, sibabrata.sahoo at oracle.com wrote: >> Hi Tony, >> Please review the patch of new Tests developed for EdDSA, >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209632 >> Webrev: http://cr.openjdk.java.net/~ssahoo/8209632/webrev.00/ >> Thanks, >> Siba > > Looking through the tests, I didn't see any problems. They looked good to me. Just one thing caught my eye. > > EdDSANegativeTest.java: > > I noticed you have InvaliPrivateKey and InvaliPublicKey. I assume that was not intentional to leave the 'd' out. I don't mind it being left out if that was your choice. > > thanks > > Tony From weijun.wang at oracle.com Thu May 14 06:11:40 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 May 2020 14:11:40 +0800 Subject: RFR 8244974: Test sun/security/krb5/auto/ReplayCachePrecise.java failes to throw KrbException Message-ID: <198FD7D6-1849-42C4-834D-F0A0BB38A300@oracle.com> Please take a review at https://cr.openjdk.java.net/~weijun/8244974/webrev.00 Time could change during the test and the cache thought it's a new entry. Thanks, Max From alexey at azul.com Thu May 14 10:52:40 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 14 May 2020 10:52:40 +0000 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: Hello Xuelei, I?ve posted a reproducer for described issue: http://cr.openjdk.java.net/~abakhtin/8206925/ The test passed and returns code=200 from the server in case of CA extension disabled on the client side: $JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com The test fails with ?fatal alert: illegal_parameter? in case of CA extension enabled on the client side: java -Djavax.net.debug=none -Djdk.tls.client.enableCAExtension=false -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com I would suggest to control number of CA in the ClientHello message. It could be done with additional system property. Default value should allow to send ClientHello message in a single record. Application can enlarge it if the server supports ClientHello in several TLS records. Thank you Alexey > On 13 May 2020, at 13:00, Alexey Bakhtin wrote: > > Hello Xuelei, > > I?m not a reviewer but I have some comment which could be helpful for your implementation. > We?ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations. > According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with ?illegal_parameter? fatal alert. > This issue can be easily reproduced on the client side: > 1) put additional certificates into cacerts file, about 200 certs in total, > 2) enable certificate_authorities extension in the ClientHello message > 3) connect to https://www.google.com > > [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java > [2] - https://tools.ietf.org/html/rfc8446#page-45 > > Thank you > Alexey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From alexey at azul.com Thu May 14 11:07:09 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 14 May 2020 11:07:09 +0000 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: Just fix a missprint: It should be -Djdk.tls.client.enableCAExtension=true in the reproducer: $JAVA_HOME/bin/java -Djdk.tls.client.enableCAExtension=true -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com > On 14 May 2020, at 13:52, Alexey Bakhtin wrote: > > Hello Xuelei, > > I?ve posted a reproducer for described issue: > http://cr.openjdk.java.net/~abakhtin/8206925/ > > The test passed and returns code=200 from the server in case of CA extension disabled on the client side: > $JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com > > The test fails with ?fatal alert: illegal_parameter? in case of CA extension enabled on the client side: > java -Djavax.net.debug=none -Djdk.tls.client.enableCAExtension=false -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com > > I would suggest to control number of CA in the ClientHello message. It could be done with additional system property. Default value should allow to send ClientHello message in a single record. Application can enlarge it if the server supports ClientHello in several TLS records. > > Thank you > Alexey > >> On 13 May 2020, at 13:00, Alexey Bakhtin wrote: >> >> Hello Xuelei, >> >> I?m not a reviewer but I have some comment which could be helpful for your implementation. >> We?ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations. >> According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with ?illegal_parameter? fatal alert. >> This issue can be easily reproduced on the client side: >> 1) put additional certificates into cacerts file, about 200 certs in total, >> 2) enable certificate_authorities extension in the ClientHello message >> 3) connect to https://www.google.com >> >> [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java >> [2] - https://tools.ietf.org/html/rfc8446#page-45 >> >> Thank you >> Alexey > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sean.mullan at oracle.com Thu May 14 14:32:59 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 May 2020 10:32:59 -0400 Subject: RFR 8244974: Test sun/security/krb5/auto/ReplayCachePrecise.java failes to throw KrbException In-Reply-To: <198FD7D6-1849-42C4-834D-F0A0BB38A300@oracle.com> References: <198FD7D6-1849-42C4-834D-F0A0BB38A300@oracle.com> Message-ID: <55a5a14b-caba-e2db-b32b-eed9696567d8@oracle.com> 8244974 is closed. I assume you mean the duplicate 8218482. Fix looks good. --Sean On 5/14/20 2:11 AM, Weijun Wang wrote: > Please take a review at > > https://cr.openjdk.java.net/~weijun/8244974/webrev.00 > > Time could change during the test and the cache thought it's a new entry. > > Thanks, > Max > From weijun.wang at oracle.com Thu May 14 15:07:56 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 14 May 2020 23:07:56 +0800 Subject: RFR 8244974: Test sun/security/krb5/auto/ReplayCachePrecise.java failes to throw KrbException In-Reply-To: <55a5a14b-caba-e2db-b32b-eed9696567d8@oracle.com> References: <198FD7D6-1849-42C4-834D-F0A0BB38A300@oracle.com> <55a5a14b-caba-e2db-b32b-eed9696567d8@oracle.com> Message-ID: <3B45E8A7-0E1E-456C-9B22-3EEB03BF687C@oracle.com> Ah yes. Thanks. --Max > On May 14, 2020, at 10:32 PM, Sean Mullan wrote: > > 8244974 is closed. I assume you mean the duplicate 8218482. > > Fix looks good. > > --Sean > > On 5/14/20 2:11 AM, Weijun Wang wrote: >> Please take a review at >> https://cr.openjdk.java.net/~weijun/8244974/webrev.00 >> Time could change during the test and the cache thought it's a new entry. >> Thanks, >> Max From sean.mullan at oracle.com Thu May 14 20:38:49 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 14 May 2020 16:38:49 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> Message-ID: <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> For the CSR, why did you check the binary and behavioral boxes for compatibility risk? Otherwise it looks good, and I added my name as Reviewer. I will review the updated webrev later. Please file and add a link to a docs issue to document the new system property. --Sean On 5/13/20 5:20 PM, Xuelei Fan wrote: > > On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>> It is not expected to use this extension regularly. >>>>> >>>>> Please let me know if you still prefer to use "enableCAExtension". >>>>> >>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>> property to enable it. Can we not enable it based on whether the >>>>>> configured X509TrustManager.getAcceptedIssuers returns a non-empty >>>>>> list? >>>>>> >>>>> We can do that on server side, but there are compatibility impact >>>>> on client behavior if we did it in client side.? See #2 in the >>>>> "Specification" section. >>>> >>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>> exception and close the connection if the server's certificate >>>> cannot be validated? Could we check if the PKIX TrustManager is >>>> being used? >>>> >>> Yes, the trust manager could throw a fatal exception and close the >>> connection if the trust cannot be established.? The fallback >>> mechanism is implemented in the customized trust manager, that if >>> users accept the cert, the cert is trusted, and no exception and the >>> handshaking continued.? It is too later to fallback after the >>> connection closed. >> >>>> If a client wants to accept self-signed or untrusted server >>>> certificates, I would have expected them to have to use a custom >>>> X509TrustManager that allows that, and that getAcceptedIssuers() >>>> should return an empty List. Is that not is what is typically done >>>> in practice? >>>> >>> Yes, customized trust manager is used to accept users manually >>> selection.? As the users may also want to accept normal certificate >>> without manually involved, so getAcceptedIssuers() should respect >>> those CA as well. >> >> I see. Out of curiosity, have you checked how other implementations >> handle this extension? For web browsers, they typically give the user >> the option of proceeding if the server certificate is not trusted. >> Seems to be a bit of a configuration dilemma as you may want this >> extension enabled for certain sites that have multiple certificates, >> but not as a general default because then you wouldn't be able to >> connect to untrusted sites (at your own risk of course). I wonder if >> it would have been better for the RFC to allow the server to treat >> this extension more as a hint, and still return its chain if an >> acceptable certificate could not be found. > If it is treated as a hint, then it might be better no have this extension. > > I checked with browsers, the extension is not present in ClientHello. > For JDK, I would not expect a lot use of this extension in client side. > It is just designed to workaround a few cases, just as you mentioned above. > > Xuelei From xuelei.fan at oracle.com Fri May 15 05:18:46 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 14 May 2020 22:18:46 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> Message-ID: <349f9972-9efc-c390-230a-ff2b2c1b1bb4@oracle.com> Hi Alexey, Thanks for the reproducer. Would you mind add it to JDK-8206925 for further testing? I think more about if a control number could be helpful. If the certificate authorities can not be fully listed, it cannot be used to indicate the peer certificate selection accuracy. For example, client support A, B and C, and is only able to indicate A and B. If the server supports C, the connection cannot be established with this extension. This is not the expected behavior. Maybe, it is no worse than without this extension. The extension is not enabled in client side by default because of the compatibility issues as described in the CSR. I don't expect this extension used a lot in client side in practice. Maybe, turn off this extension could help to mitigate the impact for now. I added more comments in the code and release note, to make sure developers understand the impact and take care of the issues. I agree that there is still a gap to cover some other case that there is a log CAs and cannot survive without the extension. Let's if it is a real problem in practice. We can go back and rethink of the solution when needed. Thanks, Xuelei On 5/14/2020 4:07 AM, Alexey Bakhtin wrote: > Just fix a missprint: > It should be -Djdk.tls.client.enableCAExtension=true in the reproducer: > $JAVA_HOME/bin/java -Djdk.tls.client.enableCAExtension=true -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com > > >> On 14 May 2020, at 13:52, Alexey Bakhtin wrote: >> >> Hello Xuelei, >> >> I?ve posted a reproducer for described issue: >> http://cr.openjdk.java.net/~abakhtin/8206925/ >> >> The test passed and returns code=200 from the server in case of CA extension disabled on the client side: >> $JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com >> >> The test fails with ?fatal alert: illegal_parameter? in case of CA extension enabled on the client side: >> java -Djavax.net.debug=none -Djdk.tls.client.enableCAExtension=false -Djavax.net.ssl.trustStore=./cacerts -Djavax.net.ssl.trustStorePassword=changeit HttpsClient https://www.google.com >> >> I would suggest to control number of CA in the ClientHello message. It could be done with additional system property. Default value should allow to send ClientHello message in a single record. Application can enlarge it if the server supports ClientHello in several TLS records. >> >> Thank you >> Alexey >> >>> On 13 May 2020, at 13:00, Alexey Bakhtin wrote: >>> >>> Hello Xuelei, >>> >>> I?m not a reviewer but I have some comment which could be helpful for your implementation. >>> We?ve developed CA Extension in the OpenJSSE provider [1] and found an issue with a third party server implementations. >>> According to RFC-8446 specification [2] the maximum size of the CA extension is 2^16 bytes. The maximum TLS record size is 2^14 bytes. In case of handshake message is bigger then maximum TLS record size, it should be splitted into several records. In fact, some server implementations does not allow ClientHello message bigger than the Maximum TLS record size and aborts connection immediately with ?illegal_parameter? fatal alert. >>> This issue can be easily reproduced on the client side: >>> 1) put additional certificates into cacerts file, about 200 certs in total, >>> 2) enable certificate_authorities extension in the ClientHello message >>> 3) connect to https://www.google.com >>> >>> [1] - https://github.com/openjsse/openjsse/blob/master/src/main/java/org/openjsse/sun/security/ssl/CertificateAuthorityExtension.java >>> [2] - https://tools.ietf.org/html/rfc8446#page-45 >>> >>> Thank you >>> Alexey >> > From xuelei.fan at oracle.com Fri May 15 05:22:56 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 14 May 2020 22:22:56 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> Message-ID: <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> Alexey has some good point about the size limit of the extension. I added more comments about the compatibility impact and interop impact when there is too much CAs to meet the size limits in CSR, source code and release notes. New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460 I have not had a chance to add a negative test case yet. On 5/14/2020 1:38 PM, Sean Mullan wrote: > For the CSR, why did you check the binary and behavioral boxes for > compatibility risk? I should not check the boxes. Removed. Thanks, Xuelei > Otherwise it looks good, and I added my name as > Reviewer. I will review the updated webrev later. > > Please file and add a link to a docs issue to document the new system > property. > > --Sean > > On 5/13/20 5:20 PM, Xuelei Fan wrote: >> >> On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>>> It is not expected to use this extension regularly. >>>>>> >>>>>> Please let me know if you still prefer to use "enableCAExtension". >>>>>> >>>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>>> property to enable it. Can we not enable it based on whether the >>>>>>> configured X509TrustManager.getAcceptedIssuers returns a >>>>>>> non-empty list? >>>>>>> >>>>>> We can do that on server side, but there are compatibility impact >>>>>> on client behavior if we did it in client side.? See #2 in the >>>>>> "Specification" section. >>>>> >>>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>>> exception and close the connection if the server's certificate >>>>> cannot be validated? Could we check if the PKIX TrustManager is >>>>> being used? >>>>> >>>> Yes, the trust manager could throw a fatal exception and close the >>>> connection if the trust cannot be established.? The fallback >>>> mechanism is implemented in the customized trust manager, that if >>>> users accept the cert, the cert is trusted, and no exception and the >>>> handshaking continued.? It is too later to fallback after the >>>> connection closed. >>> >>>>> If a client wants to accept self-signed or untrusted server >>>>> certificates, I would have expected them to have to use a custom >>>>> X509TrustManager that allows that, and that getAcceptedIssuers() >>>>> should return an empty List. Is that not is what is typically done >>>>> in practice? >>>>> >>>> Yes, customized trust manager is used to accept users manually >>>> selection.? As the users may also want to accept normal certificate >>>> without manually involved, so getAcceptedIssuers() should respect >>>> those CA as well. >>> >>> I see. Out of curiosity, have you checked how other implementations >>> handle this extension? For web browsers, they typically give the user >>> the option of proceeding if the server certificate is not trusted. >>> Seems to be a bit of a configuration dilemma as you may want this >>> extension enabled for certain sites that have multiple certificates, >>> but not as a general default because then you wouldn't be able to >>> connect to untrusted sites (at your own risk of course). I wonder if >>> it would have been better for the RFC to allow the server to treat >>> this extension more as a hint, and still return its chain if an >>> acceptable certificate could not be found. >> If it is treated as a hint, then it might be better no have this >> extension. >> >> I checked with browsers, the extension is not present in ClientHello. >> For JDK, I would not expect a lot use of this extension in client >> side. It is just designed to workaround a few cases, just as you >> mentioned above. >> >> Xuelei From sean.mullan at oracle.com Fri May 15 12:27:30 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 15 May 2020 08:27:30 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> Message-ID: <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> On 5/15/20 1:22 AM, Xuelei Fan wrote: > Alexey has some good point about the size limit of the extension.? I > added more comments about the compatibility impact and interop impact > when there is too much CAs to meet the size limits in CSR, source code > and release notes. > > New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460 > > I have not had a chance to add a negative test case yet. By negative test case, do you mean trying to exceed the maximum number of CAs? I agree that would be a good test to add, as we may or may not exceed that number some day, but it would be good to know when/if we do. --Sean > > On 5/14/2020 1:38 PM, Sean Mullan wrote: >> For the CSR, why did you check the binary and behavioral boxes for >> compatibility risk? > I should not check the boxes.? Removed. > > Thanks, > Xuelei > >> Otherwise it looks good, and I added my name as Reviewer. I will >> review the updated webrev later. >> >> Please file and add a link to a docs issue to document the new system >> property. >> >> --Sean >> >> On 5/13/20 5:20 PM, Xuelei Fan wrote: >>> >>> On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>>>> It is not expected to use this extension regularly. >>>>>>> >>>>>>> Please let me know if you still prefer to use "enableCAExtension". >>>>>>> >>>>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>>>> property to enable it. Can we not enable it based on whether the >>>>>>>> configured X509TrustManager.getAcceptedIssuers returns a >>>>>>>> non-empty list? >>>>>>>> >>>>>>> We can do that on server side, but there are compatibility impact >>>>>>> on client behavior if we did it in client side.? See #2 in the >>>>>>> "Specification" section. >>>>>> >>>>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>>>> exception and close the connection if the server's certificate >>>>>> cannot be validated? Could we check if the PKIX TrustManager is >>>>>> being used? >>>>>> >>>>> Yes, the trust manager could throw a fatal exception and close the >>>>> connection if the trust cannot be established.? The fallback >>>>> mechanism is implemented in the customized trust manager, that if >>>>> users accept the cert, the cert is trusted, and no exception and >>>>> the handshaking continued.? It is too later to fallback after the >>>>> connection closed. >>>> >>>>>> If a client wants to accept self-signed or untrusted server >>>>>> certificates, I would have expected them to have to use a custom >>>>>> X509TrustManager that allows that, and that getAcceptedIssuers() >>>>>> should return an empty List. Is that not is what is typically done >>>>>> in practice? >>>>>> >>>>> Yes, customized trust manager is used to accept users manually >>>>> selection.? As the users may also want to accept normal certificate >>>>> without manually involved, so getAcceptedIssuers() should respect >>>>> those CA as well. >>>> >>>> I see. Out of curiosity, have you checked how other implementations >>>> handle this extension? For web browsers, they typically give the >>>> user the option of proceeding if the server certificate is not >>>> trusted. Seems to be a bit of a configuration dilemma as you may >>>> want this extension enabled for certain sites that have multiple >>>> certificates, but not as a general default because then you wouldn't >>>> be able to connect to untrusted sites (at your own risk of course). >>>> I wonder if it would have been better for the RFC to allow the >>>> server to treat this extension more as a hint, and still return its >>>> chain if an acceptable certificate could not be found. >>> If it is treated as a hint, then it might be better no have this >>> extension. >>> >>> I checked with browsers, the extension is not present in ClientHello. >>> For JDK, I would not expect a lot use of this extension in client >>> side. It is just designed to workaround a few cases, just as you >>> mentioned above. >>> >>> Xuelei From sha.jiang at oracle.com Fri May 15 12:38:16 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 15 May 2020 20:38:16 +0800 Subject: RFR[15] JDK-8245005: javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant Message-ID: Hi, Possibly run the manual test javax/net/ssl/compatibility/BasicConnectTest.java with JDK builds supporting TLS_KRB5 cipher suites. However these cipher suites are not in test/jdk/javax/net/ssl/TLSCommon/ChpherSuite.java. When convert a TLS_KRB5 cipher suite name to a ChpherSuite enum, IllegalArgumentException will be raised. This patch just adds TLS_KRB5 cipher suites to ChpherSuite.java. In addition, test/jdk/javax/net/ssl/compatibility/Compatibility.java was already removed, so test/jdk/javax/net/ssl/compatibility/README should be updated accordingly. Issue: https://bugs.openjdk.java.net/browse/JDK-8245005 Webrev: http://cr.openjdk.java.net/~jjiang/8245005/webrev.00/ Best regards, John Jiang From xuelei.fan at oracle.com Fri May 15 16:08:58 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 May 2020 09:08:58 -0700 Subject: RFR[15] JDK-8245005: javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant In-Reply-To: References: Message-ID: <5693eddc-796d-f2d0-b8ae-50979fd43fad@oracle.com> Looks good to me. Xuelei On 5/15/2020 5:38 AM, sha.jiang at oracle.com wrote: > Hi, > Possibly run the manual test > javax/net/ssl/compatibility/BasicConnectTest.java > with JDK builds supporting TLS_KRB5 cipher suites. However these cipher > suites > are not in test/jdk/javax/net/ssl/TLSCommon/ChpherSuite.java. When > convert a > TLS_KRB5 cipher suite name to a ChpherSuite enum, IllegalArgumentException > will be raised. This patch just adds TLS_KRB5 cipher suites to > ChpherSuite.java. > > In addition, test/jdk/javax/net/ssl/compatibility/Compatibility.java was > already > removed, so test/jdk/javax/net/ssl/compatibility/README should be updated > accordingly. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8245005 > Webrev: http://cr.openjdk.java.net/~jjiang/8245005/webrev.00/ > > Best regards, > John Jiang From valerie.peng at oracle.com Fri May 15 21:47:14 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 15 May 2020 14:47:14 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> Message-ID: <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> Hi Max, I have updated the webrev (http://cr.openjdk.java.net/~valeriep/8242151/webrev.05/) to address your suggestion below. Touched classes are NamedCurve, CurveDB, ConstraintsParameters, and SunEC. The result of using the single method looks pretty good - clean and shorter code. :) > CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). > > In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! > Thanks, Valerie On 5/13/2020 7:03 PM, Weijun Wang wrote: > >> On May 14, 2020, at 3:17 AM, Valerie Peng wrote: >> >> Hi Max, >> >> Thanks for review~ >> >> Webrev is updated accordingly for your comments: http://cr.openjdk.java.net/~valeriep/8242151/webrev.04/ >> >> Please find replies inline below: >> >> On 5/11/2020 9:24 PM, Weijun Wang wrote: >>> Some files have trailing spaces. >> Yes, I generally check for white spaces before integration. Now that you mention it, I checked and included this in webrev.04. >>> KnownOIDs.java: >>> >>> - Is there an order for the fields? I see they are grouped but now always ordered. >> Well, the fields are grouped based on their oid with comments stating their parent node value. Within the same group, they are ordered so it's easier to spot missing/gap values. >> >> The less used ones are placed at the end. >> >>> - Unused "import java.security.Provider;" >> Removed. >>> - 1.3.14.3.2.29 used to be an alias for SHA1withRSA, now it's not. Is this intended? >> Good catch. I added the necessary entry to SecurityProviderConstants class now. >>> - s/_/-/ in process() is now used for >>> >>> SHA3_224 -> SHA3-224 >>> SHA3_256 -> SHA3-256 >>> SHA3_384 -> SHA3-384 >>> SHA3_512 -> SHA3-512 >>> HmacSHA3_224 -> HmacSHA3-224 >>> HmacSHA3_256 -> HmacSHA3-256 >>> HmacSHA3_384 -> HmacSHA3-384 >>> HmacSHA3_512 -> HmacSHA3-512 >>> SHA3_224withRSA -> SHA3-224withRSA >>> SHA3_256withRSA -> SHA3-256withRSA >>> SHA3_384withRSA -> SHA3-384withRSA >>> SHA3_512withRSA -> SHA3-512withRSA >>> RSASSA_PSS -> RSASSA-PSS >>> CHACHA20_POLY1305 -> CHACHA20-POLY1305 >>> >>> Can we just hardcode the stdName in constructor and remove the substitution? It looks fragile and expensive to me. What if we invent a name like AES_128overSHA3_256? >> The process() code is also used as "/" is not allowed as variable names. Anyway, I have removed the process() method and hardcoded all relevant entries with a standard name. > I was OK with the $ -> / conversion, but it's up to you to decide whether to keep that. > >>> - Now that you've added EC curve names starting with a lowercase letter, can we also use "serverAuth"? >> Alright, if that's what you prefer. I added a comment at the top of KnownOIDs class to explain why some starts with lowercase. >>> - I wonder if we can split the aliases by hand, i.e. modify >>> >>> secp256r1("1.2.840.10045.3.1.7", >>> "secp256r1 [NIST P-256, X9.62 prime256v1]"), >>> >>> to >>> >>> secp256r1("1.2.840.10045.3.1.7", >>> "secp256r1", "NIST P-256", "X9.62 prime256v1"), >>> >>> After all the names will be split into pieces, and we can also use KnownOIDs inside NamedCurve. >> I switched to this approach, however, there is one minor behavior change - to avoid the pattern parsing code (which I suppose is the main benefit of this approach), the NamedCurve.getName() method now returns the stdName of the KnownOIDs enum instead of the formatted string which contains both stdName and aliases. I also added NamedCurve.getAliases() method which returns the aliases of the KnownOIDs enum. This touchs SunEC, CurveDB, NamedCurve, and KnownOIDs classes. > CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). > > In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! :-) > >>> PBES2Parameters.java: >>> >>> - It's a little pity we need to hardcode several names here. Is 'o.stdName().startsWith("HmacSHA")' enough? This looks like a hack but can save us some hassle if we support more later. >> Well, I prefer to keep the current changes as it enforces the same restriction as the existing impl. With the "startsWith" check, it is looser as it won't reject HmacSHA3-xxx ones. If we support more later, this should error out and should be obvious that an update is required. > Fair enough. > > Everything else looks fine to me. > > Thanks, > Max > >> Thanks, >> >> Valerie >> >>> Everything else looks fine. >>> >>> Thanks, >>> Max >>> >>> >>> >>>> On May 12, 2020, at 9:25 AM, Valerie Peng wrote: >>>> >>>> Thanks for filing the bug for PBES2Parameters class. >>>> >>>> Webrev for 8242151 is updated at: http://cr.openjdk.java.net/~valeriep/8242151/webrev.03/ >>>> >>>> It addresses: >>>> >>>> - added KnownOIDs for CurveDB class >>>> - updated the KDF parsing code in PBES2Parameters class to match existing behavior >>>> - removed the String constants of PKCS9Attribute class and commented out its constructor which takes String argument >>>> - use 3rd party aliasing info in AlgorithmId.getName() impl >>>> - misc changes to KnownOIDs class regarding the register() impl >>>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> On 5/6/2020 6:59 PM, Weijun Wang wrote: >>>>>> It seems that existing impl of PBES2Parameters class only enforces that the KDF algo is one of the HmacSHAxxx. But it does not throw exception if the instance is requested with "PBEWithHmacSHA256AndAES_256" and then initialized with DER encoding containing "PBEWithHmacSHA512AndAES_256". Perhaps it should be further tightened up? >>>>> I think so. There is a general "PBES2" that allows filling in the algorithms at init() but if they are already inside the algorithm name, then only the same can appear in the encoding. >>>>> >>>>> Filed https://bugs.openjdk.java.net/browse/JDK-8244564. Maybe we will backport it. >>>>> >>>>> --Max From xuelei.fan at oracle.com Fri May 15 22:11:01 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 15 May 2020 15:11:01 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> Message-ID: <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> New webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.04/ On 5/15/2020 5:27 AM, Sean Mullan wrote: > On 5/15/20 1:22 AM, Xuelei Fan wrote: >> Alexey has some good point about the size limit of the extension.? I >> added more comments about the compatibility impact and interop impact >> when there is too much CAs to meet the size limits in CSR, source code >> and release notes. >> >> New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460 >> >> I have not had a chance to add a negative test case yet. > > By negative test case, do you mean trying to exceed the maximum number > of CAs? I agree that would be a good test to add, as we may or may not > exceed that number some day, but it would be good to know when/if we do. > Yes. I added a new test case in webrev.04 (TooMuchCAs.java). Xuelei > --Sean > >> >> On 5/14/2020 1:38 PM, Sean Mullan wrote: >>> For the CSR, why did you check the binary and behavioral boxes for >>> compatibility risk? >> I should not check the boxes.? Removed. >> >> Thanks, >> Xuelei >> >>> Otherwise it looks good, and I added my name as Reviewer. I will >>> review the updated webrev later. >>> >>> Please file and add a link to a docs issue to document the new system >>> property. >>> >>> --Sean >>> >>> On 5/13/20 5:20 PM, Xuelei Fan wrote: >>>> >>>> On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>>>>> It is not expected to use this extension regularly. >>>>>>>> >>>>>>>> Please let me know if you still prefer to use "enableCAExtension". >>>>>>>> >>>>>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>>>>> property to enable it. Can we not enable it based on whether >>>>>>>>> the configured X509TrustManager.getAcceptedIssuers returns a >>>>>>>>> non-empty list? >>>>>>>>> >>>>>>>> We can do that on server side, but there are compatibility >>>>>>>> impact on client behavior if we did it in client side.? See #2 >>>>>>>> in the "Specification" section. >>>>>>> >>>>>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>>>>> exception and close the connection if the server's certificate >>>>>>> cannot be validated? Could we check if the PKIX TrustManager is >>>>>>> being used? >>>>>>> >>>>>> Yes, the trust manager could throw a fatal exception and close the >>>>>> connection if the trust cannot be established.? The fallback >>>>>> mechanism is implemented in the customized trust manager, that if >>>>>> users accept the cert, the cert is trusted, and no exception and >>>>>> the handshaking continued.? It is too later to fallback after the >>>>>> connection closed. >>>>> >>>>>>> If a client wants to accept self-signed or untrusted server >>>>>>> certificates, I would have expected them to have to use a custom >>>>>>> X509TrustManager that allows that, and that getAcceptedIssuers() >>>>>>> should return an empty List. Is that not is what is typically >>>>>>> done in practice? >>>>>>> >>>>>> Yes, customized trust manager is used to accept users manually >>>>>> selection.? As the users may also want to accept normal >>>>>> certificate without manually involved, so getAcceptedIssuers() >>>>>> should respect those CA as well. >>>>> >>>>> I see. Out of curiosity, have you checked how other implementations >>>>> handle this extension? For web browsers, they typically give the >>>>> user the option of proceeding if the server certificate is not >>>>> trusted. Seems to be a bit of a configuration dilemma as you may >>>>> want this extension enabled for certain sites that have multiple >>>>> certificates, but not as a general default because then you >>>>> wouldn't be able to connect to untrusted sites (at your own risk of >>>>> course). I wonder if it would have been better for the RFC to allow >>>>> the server to treat this extension more as a hint, and still return >>>>> its chain if an acceptable certificate could not be found. >>>> If it is treated as a hint, then it might be better no have this >>>> extension. >>>> >>>> I checked with browsers, the extension is not present in >>>> ClientHello. For JDK, I would not expect a lot use of this extension >>>> in client side. It is just designed to workaround a few cases, just >>>> as you mentioned above. >>>> >>>> Xuelei From weijun.wang at oracle.com Sat May 16 03:57:34 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 16 May 2020 11:57:34 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> Message-ID: <71A4906F-2FFD-46BD-A303-DEBA35B56B86@oracle.com> Well done. Everything looks fine to me. --Max > On May 16, 2020, at 5:47 AM, Valerie Peng wrote: > > Hi Max, > > I have updated the webrev (http://cr.openjdk.java.net/~valeriep/8242151/webrev.05/) to address your suggestion below. Touched classes are NamedCurve, CurveDB, ConstraintsParameters, and SunEC. The result of using the single method looks pretty good - clean and shorter code. :) > >> CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). >> >> In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! >> > Thanks, > Valerie > From sha.jiang at oracle.com Sat May 16 06:40:54 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Sat, 16 May 2020 14:40:54 +0800 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases Message-ID: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> Hi, This patch adds some new createTrustStore() and createKeyStore() methods to test lib class jdk.test.lib.security.KeyStoreUtils. These new methods allow to pass trust/key store aliases in. Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ Best regards, John Jiang From valerie.peng at oracle.com Mon May 18 17:41:18 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 May 2020 10:41:18 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> Message-ID: <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> Hi Max, I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) ??? private static void checkTrailingBytes(DerInputStream derIn, int version) ??????????? throws IOException { ??????? boolean hasAttributes = false; ??????? boolean hasPublicKey = false; ??????? while (derIn.available () != 0) { ??????????? // check for OPTIONAL attributes and/or publicKey ??????????? DerValue tmp = derIn.getDerValue(); ??????????? if (tmp.isContextSpecific((byte)0) && !hasAttributes) { ??????????????? // OPTIONAL attributes not supported yet ??????????????? // discard for now and move on ??????????????? hasAttributes = true; ??????????? } else if (version == V2 && tmp.isContextSpecific((byte)1) && ??????????????? !hasPublicKey) { ??????????????? // OPTIONAL v2 public key not supported yet ??????????????? // discard for now and move on ??????????????? hasPublicKey = true; ??????????? } else { ??????????????? throw new IOException ("illegal encoding in private key"); ??????????? } ??????? } ??? } Besides the encoding parsing check above, maybe V1, V2 can be made private static? I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. Thanks, Valerie On 5/13/2020 5:16 PM, Valerie Peng wrote: > I will take a look. > > Valerie > > On 5/8/2020 3:39 AM, Weijun Wang wrote: >> Found an existing test I can update. Webrev updated at >> >> ??? http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >> >> Thanks, >> Max >> >>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>> >>> Please take a review at >>> >>> ?? http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>> >>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey >>> and attributes are still not parsed. >>> >>> I also take this chance to make some format change. >>> >>> There is no regression test and I'll add one. I can generate a PKCS8 >>> key and then modify the version from 0 to 1 and try to read it. Or I >>> can find a PKCS8 generated by some other tool and embed it the test >>> to read it. Please advise which is better. >>> >>> Thanks, >>> Max >>> From valerie.peng at oracle.com Mon May 18 18:44:35 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 May 2020 11:44:35 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <71A4906F-2FFD-46BD-A303-DEBA35B56B86@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> <71A4906F-2FFD-46BD-A303-DEBA35B56B86@oracle.com> Message-ID: Great, thanks much for the thorough review~ Valerie On 5/15/2020 8:57 PM, Weijun Wang wrote: > Well done. Everything looks fine to me. > > --Max > >> On May 16, 2020, at 5:47 AM, Valerie Peng wrote: >> >> Hi Max, >> >> I have updated the webrev (http://cr.openjdk.java.net/~valeriep/8242151/webrev.05/) to address your suggestion below. Touched classes are NamedCurve, CurveDB, ConstraintsParameters, and SunEC. The result of using the single method looks pretty good - clean and shorter code. :) >> >>> CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). >>> >>> In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! >>> >> Thanks, >> Valerie >> From hai-may.chao at oracle.com Mon May 18 20:05:03 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Mon, 18 May 2020 13:05:03 -0700 Subject: RFR[15] 8245151: jarsigner should not raise duplicate warnings on verification Message-ID: <990A0372-9FD1-4E2C-96AD-FDB98577E0F4@oracle.com> Hi, I?d like to request a review for - JBS: https://bugs.openjdk.java.net/browse/JDK-8245151 Webrev: https://cr.openjdk.java.net/~hchao/8245151/webrev.00/ The change is to provide a distinct warning for jarsigner -verify command when it detects weak timestamp digest algorithms are used (by -tsadigestalg when signing). Thanks, Hai-May From valerie.peng at oracle.com Mon May 18 21:36:21 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 18 May 2020 14:36:21 -0700 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> <71A4906F-2FFD-46BD-A303-DEBA35B56B86@oracle.com> Message-ID: <0d02b256-5db1-0aca-9669-15d6874ec766@oracle.com> Updated again due to the merge with Tony's EdDSA change: http://cr.openjdk.java.net/~valeriep/8242151/webrev.06 Added Ed25519 and Ed448 to KnownOIDs, and rest are just adjustments accordingly. Touched: src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAParameters.java src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java src/java.base/share/classes/sun/security/x509/AlgorithmId.java src/java.base/share/classes/sun/security/util/KnownOIDs.java Pre-integration Mach5 job is running. Thanks, Valerie On 5/18/2020 11:44 AM, Valerie Peng wrote: > Great, thanks much for the thorough review~ > > Valerie > > On 5/15/2020 8:57 PM, Weijun Wang wrote: >> Well done. Everything looks fine to me. >> >> --Max >> >>> On May 16, 2020, at 5:47 AM, Valerie Peng >>> wrote: >>> >>> Hi Max, >>> >>> I have updated the webrev >>> (http://cr.openjdk.java.net/~valeriep/8242151/webrev.05/) to address >>> your suggestion below. Touched classes are NamedCurve, CurveDB, >>> ConstraintsParameters, and SunEC. The result of using the single >>> method looks pretty good - clean and shorter code. :) >>> >>>> CurveDB.getNamesByOID is only used in >>>> ConstraintsParameters.getNamedCurveFromKey(), but we already have a >>>> NamedCurve there and you can directly use it without converting to >>>> nc.getObjectId(). >>>> >>>> In fact, it looks like nc.getAliases() and nc.getName() are always >>>> used together. Can we just remove these 2 and add a new method >>>> nc.getNameAndAliases()? Then there will be no compatibility impact >>>> for getName() at all! >>>> >>> Thanks, >>> Valerie >>> From weijun.wang at oracle.com Tue May 19 00:38:39 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 May 2020 08:38:39 +0800 Subject: [15] RFR JDK-8242151 Improve OID mapping and reuse among JDK security providers for aliases registration In-Reply-To: <0d02b256-5db1-0aca-9669-15d6874ec766@oracle.com> References: <241ebee1-4250-1de9-4299-6cfb02ad4448@oracle.com> <7A4907B0-C933-4DF5-92BF-9658E8013D60@oracle.com> <47951cfa-00ab-a1fa-e569-d80ac0e5b615@oracle.com> <89d5a22c-1582-bfb6-18d7-1324c81559ed@oracle.com> <1FC5DC25-0260-4501-B336-7BD951BD527F@oracle.com> <6a763985-d0fa-f700-b4bf-746f603fe45f@oracle.com> <7D1AA693-9625-4241-A7D0-1663AF0C88CB@oracle.com> <9aefd223-1eaf-2bd7-0698-aa7bab602674@oracle.com> <21fde17f-552d-68de-f535-78274852bfd9@oracle.com> <098dc5fe-7127-1d50-9ad0-54b3472da82a@oracle.com> <71A4906F-2FFD-46BD-A303-DEBA35B56B86@oracle.com> <0d02b256-5db1-0aca-9669-15d6874ec766@oracle.com> Message-ID: <3A9B2254-8751-417E-BE96-E057516FC748@oracle.com> Still looks fine to me. Thanks, Max > On May 19, 2020, at 5:36 AM, Valerie Peng wrote: > > Updated again due to the merge with Tony's EdDSA change: > > http://cr.openjdk.java.net/~valeriep/8242151/webrev.06 > > Added Ed25519 and Ed448 to KnownOIDs, and rest are just adjustments accordingly. > > Touched: > > src/jdk.crypto.ec/share/classes/sun/security/ec/ed/EdDSAParameters.java > src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java > src/java.base/share/classes/sun/security/x509/AlgorithmId.java > src/java.base/share/classes/sun/security/util/KnownOIDs.java > > Pre-integration Mach5 job is running. > > Thanks, > > Valerie > > On 5/18/2020 11:44 AM, Valerie Peng wrote: >> Great, thanks much for the thorough review~ >> >> Valerie >> >> On 5/15/2020 8:57 PM, Weijun Wang wrote: >>> Well done. Everything looks fine to me. >>> >>> --Max >>> >>>> On May 16, 2020, at 5:47 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> I have updated the webrev (http://cr.openjdk.java.net/~valeriep/8242151/webrev.05/) to address your suggestion below. Touched classes are NamedCurve, CurveDB, ConstraintsParameters, and SunEC. The result of using the single method looks pretty good - clean and shorter code. :) >>>> >>>>> CurveDB.getNamesByOID is only used in ConstraintsParameters.getNamedCurveFromKey(), but we already have a NamedCurve there and you can directly use it without converting to nc.getObjectId(). >>>>> >>>>> In fact, it looks like nc.getAliases() and nc.getName() are always used together. Can we just remove these 2 and add a new method nc.getNameAndAliases()? Then there will be no compatibility impact for getName() at all! >>>>> >>>> Thanks, >>>> Valerie >>>> From weijun.wang at oracle.com Tue May 19 02:40:17 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 May 2020 10:40:17 +0800 Subject: RFR[15] 8245151: jarsigner should not raise duplicate warnings on verification In-Reply-To: <990A0372-9FD1-4E2C-96AD-FDB98577E0F4@oracle.com> References: <990A0372-9FD1-4E2C-96AD-FDB98577E0F4@oracle.com> Message-ID: Looks fine to me. Thanks, Max > On May 19, 2020, at 4:05 AM, Hai-May Chao wrote: > > Hi, > > I?d like to request a review for - > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245151 > Webrev: https://cr.openjdk.java.net/~hchao/8245151/webrev.00/ > > The change is to provide a distinct warning for jarsigner -verify command when it detects weak timestamp digest algorithms are used (by -tsadigestalg when signing). > > Thanks, > Hai-May > From weijun.wang at oracle.com Tue May 19 04:36:03 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 May 2020 12:36:03 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> Message-ID: > On May 19, 2020, at 1:41 AM, Valerie Peng wrote: > > Hi Max, > > I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. > > In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) > > private static void checkTrailingBytes(DerInputStream derIn, int version) > throws IOException { > boolean hasAttributes = false; > boolean hasPublicKey = false; > while (derIn.available () != 0) { > // check for OPTIONAL attributes and/or publicKey > DerValue tmp = derIn.getDerValue(); > if (tmp.isContextSpecific((byte)0) && !hasAttributes) { > // OPTIONAL attributes not supported yet > // discard for now and move on > hasAttributes = true; > } else if (version == V2 && tmp.isContextSpecific((byte)1) && > !hasPublicKey) { > // OPTIONAL v2 public key not supported yet > // discard for now and move on > hasPublicKey = true; > } else { > throw new IOException ("illegal encoding in private key"); > } > } > } I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). > > Besides the encoding parsing check above, maybe V1, V2 can be made private static? OK. > I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. Yes. > > As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. If you still want checkTrailingBytes, then yes. Thanks, Max > > Thanks, > > Valerie > > > On 5/13/2020 5:16 PM, Valerie Peng wrote: >> I will take a look. >> >> Valerie >> >> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>> Found an existing test I can update. Webrev updated at >>> >>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>> >>> Thanks, >>> Max >>> >>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>> >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>> >>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>> >>>> I also take this chance to make some format change. >>>> >>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>> >>>> Thanks, >>>> Max >>>> From weijun.wang at oracle.com Tue May 19 09:43:43 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 May 2020 17:43:43 +0800 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA Message-ID: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> Please review the CSR at https://bugs.openjdk.java.net/browse/JDK-8245274 The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. // Same values for RSA and DSA private static String ifcFfcStrength (int bitLength) { if (bitLength > 7680) { // 256 bits return "SHA512"; } else if (bitLength > 3072) { // 192 bits return "SHA384"; } else { // 128 bits and less return "SHA256"; } } and it's not adjustable. I don't know what the best place is for this info. Thanks, Max From weijun.wang at oracle.com Tue May 19 13:58:25 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 19 May 2020 21:58:25 +0800 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> Message-ID: <7A6C9438-12F8-4713-A350-EC97A4FE8C71@oracle.com> One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg Ed448"? It looks like we should support it because we can call Signature.getInstance() on it, but even if so, the block extension name will still be "EDD" (or "EdDSA"). --Max > On May 19, 2020, at 5:43 PM, Weijun Wang wrote: > > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8245274 > > The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. > > Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. > > // Same values for RSA and DSA > private static String ifcFfcStrength (int bitLength) { > if (bitLength > 7680) { // 256 bits > return "SHA512"; > } else if (bitLength > 3072) { // 192 bits > return "SHA384"; > } else { // 128 bits and less > return "SHA256"; > } > } > > and it's not adjustable. I don't know what the best place is for this info. > > Thanks, > Max > From xuelei.fan at oracle.com Tue May 19 16:03:25 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 19 May 2020 09:03:25 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <7A6C9438-12F8-4713-A350-EC97A4FE8C71@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> <7A6C9438-12F8-4713-A350-EC97A4FE8C71@oracle.com> Message-ID: <5be05b21-43ff-a386-f573-1da90ceffbbd@oracle.com> On 5/19/2020 6:58 AM, Weijun Wang wrote: > One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg Ed448"? I would like to have the two options. > It looks like we should support it because we can call Signature.getInstance() on it, but even if so, the block extension name will still be "EDD" (or "EdDSA"). > It may be a stupid question, can RSASSA-PSS share the 'rsa', and EdDSA share or the 'ec' block file extension? Xuelei > --Max > > >> On May 19, 2020, at 5:43 PM, Weijun Wang wrote: >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8245274 >> >> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >> >> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >> >> // Same values for RSA and DSA >> private static String ifcFfcStrength (int bitLength) { >> if (bitLength > 7680) { // 256 bits >> return "SHA512"; >> } else if (bitLength > 3072) { // 192 bits >> return "SHA384"; >> } else { // 128 bits and less >> return "SHA256"; >> } >> } >> >> and it's not adjustable. I don't know what the best place is for this info. >> >> Thanks, >> Max >> > From alexey at azul.com Tue May 19 16:25:28 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 19 May 2020 16:25:28 +0000 Subject: LDAP Channel Binding Message-ID: <151594AA-E00F-4032-B2A3-83B7E15CC366@azul.com> Hello Bernd, Michael, We?ve been working on the same issue and found that the Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate): ? The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: ? initiator and acceptor addresses should be set to NULL ? initiator and acceptor address types should be zero. It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. On the base of this information we?ve made a patch for the LDAP, SASL and JGSS modules to generate channel binding data automatically if requested by an application. This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. Right now "tls-server-end-point" Channel Binding type is supported only. The client extracts server certificate from the underlying TLS connection and creates Channel Binding data for JGSS/Kerberos authentication if application indicates com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. The patch is available at : http://cr.openjdk.java.net/~abakhtin/channel_binding/webrev.v0/ [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 [2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html Regards Alexey Date: Tue, 18 Feb 2020 19:17:20 +0100 From: Michael Osipov To: Bernd Eckenfels , "security-dev at openjdk.java.net" Subject: Re: LDAP Channel Binding Message-ID: <28180b5f-515d-aab7-b901-b74153964d86 at apache.org> Content-Type: text/plain; charset=windows-1252; format=flowed Since we don't know what type of channel binding is used, how do you want to fix that? Are we finally talking about TLS channel binding? But which tls-unique or tls-server-end-point? Can you provide a pcap from that comm as well as debug dump from JSSE and JNDI? Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From anthony.scarpino at oracle.com Tue May 19 18:03:07 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 May 2020 11:03:07 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> Message-ID: <4ff9dd84-1ddb-5aef-673f-7380cf3f555d@oracle.com> On 5/19/20 2:43 AM, Weijun Wang wrote: > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8245274 > > The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. Is the block file extension just the old FAT 8.3 filename format? Is there something requiring we have an extension or that it be three or fewer? I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name. > > Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. > > // Same values for RSA and DSA > private static String ifcFfcStrength (int bitLength) { > if (bitLength > 7680) { // 256 bits > return "SHA512"; > } else if (bitLength > 3072) { // 192 bits > return "SHA384"; > } else { // 128 bits and less > return "SHA256"; > } > } > > and it's not adjustable. I don't know what the best place is for this info. Does that make it different than other algorithms that require the parameters to be set? It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly. Tony > > Thanks, > Max > From anthony.scarpino at oracle.com Tue May 19 18:05:21 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 May 2020 11:05:21 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <7A6C9438-12F8-4713-A350-EC97A4FE8C71@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> <7A6C9438-12F8-4713-A350-EC97A4FE8C71@oracle.com> Message-ID: <3bbcc43e-100d-5d90-f162-98bd26e7cbb9@oracle.com> On 5/19/20 6:58 AM, Weijun Wang wrote: > One more thing: do you think we should allow "-siglag Ed25519" and "-sigalg Ed448"? It looks like we should support it because we can call Signature.getInstance() on it, but even if so, the block extension name will still be "EDD" (or "EdDSA"). The extensions can be the same. It will be the code that will determine which curve it is based off the certificate info, I hope. > > --Max > > >> On May 19, 2020, at 5:43 PM, Weijun Wang wrote: >> >> Please review the CSR at >> >> https://bugs.openjdk.java.net/browse/JDK-8245274 >> >> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >> >> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >> >> // Same values for RSA and DSA >> private static String ifcFfcStrength (int bitLength) { >> if (bitLength > 7680) { // 256 bits >> return "SHA512"; >> } else if (bitLength > 3072) { // 192 bits >> return "SHA384"; >> } else { // 128 bits and less >> return "SHA256"; >> } >> } >> >> and it's not adjustable. I don't know what the best place is for this info. >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Tue May 19 20:17:57 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 May 2020 04:17:57 +0800 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <5be05b21-43ff-a386-f573-1da90ceffbbd@oracle.com> References: <5be05b21-43ff-a386-f573-1da90ceffbbd@oracle.com> Message-ID: <78842492-F821-4823-A58F-49C29DC65230@oracle.com> > ? 2020?5?20??00:03?Xuelei Fan ??? > > It may be a stupid question, can RSASSA-PSS share the 'rsa', and EdDSA share or the 'ec' block file extension? This is a brave idea. It should work. ?Max From anthony.scarpino at oracle.com Tue May 19 20:25:00 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 May 2020 13:25:00 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <4ff9dd84-1ddb-5aef-673f-7380cf3f555d@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> <4ff9dd84-1ddb-5aef-673f-7380cf3f555d@oracle.com> Message-ID: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required. Are these signature files just a byte array of the signature result? Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key. In my quick look at the spec, I don't see any the file format definition. Tony On 5/19/20 11:03 AM, Anthony Scarpino wrote: > On 5/19/20 2:43 AM, Weijun Wang wrote: >> Please review the CSR at >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8245274 >> >> The most arguable is the new block extension names. I drafted "PSS" >> for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names >> never exceeded 3 letters. If we do not care about this, we can just >> make them "RSASSA-PSS" and "EdDSA". We've always treated the extension >> name in a case-insensitive way but this needs some debugging. > > Is the block file extension just the old FAT 8.3 filename format?? Is > there something requiring we have an extension or that it be three or > fewer?? I'd prefer we just have no extension, or if having some > extension make sense, I'd prefer the full name. > >> >> Another thing I haven't mentioned in the CSR is about using `-sigalg >> RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of >> the PSS parameters will be determined by the key size of the key, i.e. >> >> ???? // Same values for RSA and DSA >> ???? private static String ifcFfcStrength (int bitLength) { >> ???????? if (bitLength > 7680) { // 256 bits >> ???????????? return "SHA512"; >> ???????? } else if (bitLength > 3072) {? // 192 bits >> ???????????? return "SHA384"; >> ???????? } else? { // 128 bits and less >> ???????????? return "SHA256"; >> ???????? } >> ???? } >> >> and it's not adjustable. I don't know what the best place is for this >> info. > > Does that make it different than other algorithms that require the > parameters to be set?? It sounds like something for the man page and > treated as a doc update in the CSR if I understand the situation correctly. > > Tony > >> >> Thanks, >> Max >> > From weijun.wang at oracle.com Tue May 19 20:30:18 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 May 2020 04:30:18 +0800 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> References: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> Message-ID: <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> The block file is a pkcs7 in DER. It contains every algid you want. IIRC you can put a DSA signature in a .RSA file. ?Max > ? 2020?5?20??04:25?Anthony Scarpino ??? > > ?I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required. > > Are these signature files just a byte array of the signature result? Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key. In my quick look at the spec, I don't see any the file format definition. > > Tony > >> On 5/19/20 11:03 AM, Anthony Scarpino wrote: >>> On 5/19/20 2:43 AM, Weijun Wang wrote: >>> Please review the CSR at >>> >>> https://bugs.openjdk.java.net/browse/JDK-8245274 >>> >>> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >> Is the block file extension just the old FAT 8.3 filename format? Is there something requiring we have an extension or that it be three or fewer? I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name. >>> >>> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >>> >>> // Same values for RSA and DSA >>> private static String ifcFfcStrength (int bitLength) { >>> if (bitLength > 7680) { // 256 bits >>> return "SHA512"; >>> } else if (bitLength > 3072) { // 192 bits >>> return "SHA384"; >>> } else { // 128 bits and less >>> return "SHA256"; >>> } >>> } >>> >>> and it's not adjustable. I don't know what the best place is for this info. >> Does that make it different than other algorithms that require the parameters to be set? It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly. >> Tony >>> >>> Thanks, >>> Max >>> > From anthony.scarpino at oracle.com Tue May 19 20:40:31 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 19 May 2020 13:40:31 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> References: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> Message-ID: If the code exists that reusing the old extensions, then that's probably best. But if it requires a large reworking of the code maybe it's not worth all that work when two new extension values are easier. I'm ok either way you want to proceed. Tony On 5/19/20 1:30 PM, Weijun Wang wrote: > The block file is a pkcs7 in DER. It contains every algid you want. IIRC you can put a DSA signature in a .RSA file. > > ?Max > >> ? 2020?5?20??04:25?Anthony Scarpino ??? >> >> ?I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required. >> >> Are these signature files just a byte array of the signature result? Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key. In my quick look at the spec, I don't see any the file format definition. >> >> Tony >> >>> On 5/19/20 11:03 AM, Anthony Scarpino wrote: >>>> On 5/19/20 2:43 AM, Weijun Wang wrote: >>>> Please review the CSR at >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8245274 >>>> >>>> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >>> Is the block file extension just the old FAT 8.3 filename format? Is there something requiring we have an extension or that it be three or fewer? I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name. >>>> >>>> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >>>> >>>> // Same values for RSA and DSA >>>> private static String ifcFfcStrength (int bitLength) { >>>> if (bitLength > 7680) { // 256 bits >>>> return "SHA512"; >>>> } else if (bitLength > 3072) { // 192 bits >>>> return "SHA384"; >>>> } else { // 128 bits and less >>>> return "SHA256"; >>>> } >>>> } >>>> >>>> and it's not adjustable. I don't know what the best place is for this info. >>> Does that make it different than other algorithms that require the parameters to be set? It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly. >>> Tony >>>> >>>> Thanks, >>>> Max >>>> >> > From weijun.wang at oracle.com Wed May 20 02:06:17 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 20 May 2020 10:06:17 +0800 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> Message-ID: Not complicated at all. It works and I've updated the CSR. --Max > On May 20, 2020, at 4:40 AM, Anthony Scarpino wrote: > > If the code exists that reusing the old extensions, then that's probably best. But if it requires a large reworking of the code maybe it's not worth all that work when two new extension values are easier. I'm ok either way you want to proceed. > > Tony > > > On 5/19/20 1:30 PM, Weijun Wang wrote: >> The block file is a pkcs7 in DER. It contains every algid you want. IIRC you can put a DSA signature in a .RSA file. >> ?Max >>> ? 2020?5?20??04:25?Anthony Scarpino ??? >>> >>> ?I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required. >>> >>> Are these signature files just a byte array of the signature result? Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key. In my quick look at the spec, I don't see any the file format definition. >>> >>> Tony >>> >>>> On 5/19/20 11:03 AM, Anthony Scarpino wrote: >>>>> On 5/19/20 2:43 AM, Weijun Wang wrote: >>>>> Please review the CSR at >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8245274 >>>>> >>>>> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >>>> Is the block file extension just the old FAT 8.3 filename format? Is there something requiring we have an extension or that it be three or fewer? I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name. >>>>> >>>>> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >>>>> >>>>> // Same values for RSA and DSA >>>>> private static String ifcFfcStrength (int bitLength) { >>>>> if (bitLength > 7680) { // 256 bits >>>>> return "SHA512"; >>>>> } else if (bitLength > 3072) { // 192 bits >>>>> return "SHA384"; >>>>> } else { // 128 bits and less >>>>> return "SHA256"; >>>>> } >>>>> } >>>>> >>>>> and it's not adjustable. I don't know what the best place is for this info. >>>> Does that make it different than other algorithms that require the parameters to be set? It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly. >>>> Tony >>>>> >>>>> Thanks, >>>>> Max >>>>> >>> > From valerie.peng at oracle.com Wed May 20 04:58:05 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 May 2020 21:58:05 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> References: <7EFBCC4C-FAAD-4987-AD86-578C2C73DD83@oracle.com> Message-ID: For RSASSA-PSS signature algorithm, if the signature parameters are generated/derived, they should be included somewhere with the signed jar. I assume that the .RSA contains only the signature bytes? If the format is not extensible, maybe we need a mechanism for including the parameters. Valerie On 5/19/2020 2:43 AM, Weijun Wang wrote: > Please review the CSR at > > https://bugs.openjdk.java.net/browse/JDK-8245274 > > The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. > > Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. > > // Same values for RSA and DSA > private static String ifcFfcStrength (int bitLength) { > if (bitLength > 7680) { // 256 bits > return "SHA512"; > } else if (bitLength > 3072) { // 192 bits > return "SHA384"; > } else { // 128 bits and less > return "SHA256"; > } > } > > and it's not adjustable. I don't know what the best place is for this info. > > Thanks, > Max > From valerie.peng at oracle.com Wed May 20 05:08:31 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 May 2020 22:08:31 -0700 Subject: [CSR RFR] 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> References: <3a5de752-f5cb-9a20-b97e-30af6189426a@oracle.com> <241A3A82-0F73-4E2C-9554-B3300F45BA6B@oracle.com> Message-ID: Great, if the block file is PKCS7 and contains the signature AlgorithmId encoding, then the generated RSASSA-PSS parameter can be included inside along with the RSASSA-PSS oid. Valerie On 5/19/2020 1:30 PM, Weijun Wang wrote: > The block file is a pkcs7 in DER. It contains every algid you want. IIRC you can put a DSA signature in a .RSA file. > > ?Max > >> ? 2020?5?20??04:25?Anthony Scarpino ??? >> >> ?I just noticed at the end of your CSR the link to the jar spec and I see that 1-3 character extension are required. >> >> Are these signature files just a byte array of the signature result? Is the extension the only thing that tells what kind of signature it is? Reusing ".EC" or ".RSA" makes sense if there is an OID that identifies the key. In my quick look at the spec, I don't see any the file format definition. >> >> Tony >> >>> On 5/19/20 11:03 AM, Anthony Scarpino wrote: >>>> On 5/19/20 2:43 AM, Weijun Wang wrote: >>>> Please review the CSR at >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8245274 >>>> >>>> The most arguable is the new block extension names. I drafted "PSS" for "RSASSA-PSS", and "EDD" for "EdDSA", since the old extension names never exceeded 3 letters. If we do not care about this, we can just make them "RSASSA-PSS" and "EdDSA". We've always treated the extension name in a case-insensitive way but this needs some debugging. >>> Is the block file extension just the old FAT 8.3 filename format? Is there something requiring we have an extension or that it be three or fewer? I'd prefer we just have no extension, or if having some extension make sense, I'd prefer the full name. >>>> Another thing I haven't mentioned in the CSR is about using `-sigalg RSASSA-PSS` for an RSA key. The hashAlgorithm and maskGenAlgorithm of the PSS parameters will be determined by the key size of the key, i.e. >>>> >>>> // Same values for RSA and DSA >>>> private static String ifcFfcStrength (int bitLength) { >>>> if (bitLength > 7680) { // 256 bits >>>> return "SHA512"; >>>> } else if (bitLength > 3072) { // 192 bits >>>> return "SHA384"; >>>> } else { // 128 bits and less >>>> return "SHA256"; >>>> } >>>> } >>>> >>>> and it's not adjustable. I don't know what the best place is for this info. >>> Does that make it different than other algorithms that require the parameters to be set? It sounds like something for the man page and treated as a doc update in the CSR if I understand the situation correctly. >>> Tony >>>> Thanks, >>>> Max >>>> From valerie.peng at oracle.com Wed May 20 05:37:24 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 19 May 2020 22:37:24 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> Message-ID: <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. Thanks, Valerie On 5/18/2020 9:36 PM, Weijun Wang wrote: >> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >> >> Hi Max, >> >> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >> >> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >> >> private static void checkTrailingBytes(DerInputStream derIn, int version) >> throws IOException { >> boolean hasAttributes = false; >> boolean hasPublicKey = false; >> while (derIn.available () != 0) { >> // check for OPTIONAL attributes and/or publicKey >> DerValue tmp = derIn.getDerValue(); >> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >> // OPTIONAL attributes not supported yet >> // discard for now and move on >> hasAttributes = true; >> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >> !hasPublicKey) { >> // OPTIONAL v2 public key not supported yet >> // discard for now and move on >> hasPublicKey = true; >> } else { >> throw new IOException ("illegal encoding in private key"); >> } >> } >> } > I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). > >> Besides the encoding parsing check above, maybe V1, V2 can be made private static? > OK. > >> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. > Yes. > >> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. > If you still want checkTrailingBytes, then yes. > > Thanks, > Max > >> Thanks, >> >> Valerie >> >> >> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>> I will take a look. >>> >>> Valerie >>> >>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>> Found an existing test I can update. Webrev updated at >>>> >>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>> >>>> Thanks, >>>> Max >>>> >>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>> >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>> >>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>> >>>>> I also take this chance to make some format change. >>>>> >>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>> >>>>> Thanks, >>>>> Max >>>>> From valerie.peng at oracle.com Wed May 20 20:21:42 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 20 May 2020 13:21:42 -0700 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases In-Reply-To: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> References: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> Message-ID: <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> Hi John, - line 125, typo: "aliaes" should be "aliases" - line 132: if aliases is not null, check its length is certStrs.length - line 152, use the specified type instead of DEFAULT_TYPE? - line 176, maybe it's better to just supply the type, clearer and less dependency. With this extra aliases argument, number of createTrustStore(...) methods doubled from 2 to 4, number of createKeyStore(...) methods also doubled from 4 to 8. Isn't it a bit much to have 8 methods doing the same thing? Especially in the case of createKeyStore(...), quite a few of them have long list of arguments with the same type, combining this with the large number of methods, it can get confusing on which method is called. How often do you think the aliases are supplied? Maybe we only add methods which will be used instead of adding all possible combinations. Thanks, Valerie On 5/15/2020 11:40 PM, sha.jiang at oracle.com wrote: > Hi, > This patch adds some new createTrustStore() and createKeyStore() > methods to test > lib class jdk.test.lib.security.KeyStoreUtils. > These new methods allow to pass trust/key store aliases in. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 > Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ > > Best regards, > John Jiang > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Thu May 21 02:38:49 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 21 May 2020 10:38:49 +0800 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases In-Reply-To: <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> References: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> Message-ID: <023b046e-83d1-32ec-f8bd-b1a886be0ef4@oracle.com> Hi Valerie, Thanks for your comments! On 2020/5/21 04:21, Valerie Peng wrote: > > Hi John, > > - line 125, typo: "aliaes" should be "aliases" > Will fix it. > - line 132: if aliases is not null, check its length is certStrs.length > Will fix it. > - line 152, use the specified type instead of DEFAULT_TYPE? > Will fix it. > - line 176, maybe it's better to just supply the type, clearer and > less dependency. > Not get this point. Could you please describe some more? > With this extra aliases argument, number of createTrustStore(...) > methods doubled from 2 to 4, number of createKeyStore(...) methods > also doubled from 4 to 8. Isn't it a bit much to have 8 methods doing > the same thing? Especially in the case of createKeyStore(...), quite a > few of them have long list of arguments with the same type, combining > this with the large number of methods, it can get confusing on which > method is called. How often do you think the aliases are supplied? > Maybe we only add methods which will be used instead of adding all > possible combinations. > I'll remove 4 createKeyStore(...) methods (like the below one) that have long list of arguments. createKeyStore(String type, String[] keyAlgos, ??????????? String[] keyStrs, String[] passwords, String[] certStrs, ??????????? String[] aliases) It looks no test is using them. My tests also won't use them. Best regards, John Jiang > > Thanks, > Valerie > On 5/15/2020 11:40 PM, sha.jiang at oracle.com wrote: >> Hi, >> This patch adds some new createTrustStore() and createKeyStore() >> methods to test >> lib class jdk.test.lib.security.KeyStoreUtils. >> These new methods allow to pass trust/key store aliases in. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 >> Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ >> >> Best regards, >> John Jiang >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Thu May 21 07:35:07 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 07:35:07 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Message-ID: Hello, Could you please review the following patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate). The channel binding data is calculated as following : ? The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: ? initiator and acceptor addresses should be set to NULL ? initiator and acceptor address types should be zero. It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. This patch introduces changes in the LDAP, SASL and JGSS modules to generate channel binding data automatically if requested by an application. This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. Right now "tls-server-end-point" Channel Binding type is supported only. The client extracts server certificate from the underlying TLS connection and creates Channel Binding data for JGSS/Kerberos authentication if application indicates com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 [2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html Initial discussion of this issue is available at security-dev list: https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From stooke at redhat.com Thu May 21 17:24:32 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 21 May 2020 13:24:32 -0400 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows Message-ID: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> Hello, I'd like to request a review for: JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ This change implements the given intrinsics on Windows. The Windows toolchain has no 128 bit integer types, and no inline asm (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as it is with gcc.? This patch had to change some of the linux implementation to account for these limitations. My gratitude for Andrew Haley for doing the heavy lifting at the core of this patch. The patch, if accepted, will be offered to 11u as a potential backport.? The changes apply cleanly modulo some line number changes. As for the speedup, this test case: BigInteger base = BigInteger.ONE.shiftLeft(1024); long count = LongStream.rangeClosed(2, 100_000) ??? .mapToObj(n -> BigInteger.valueOf(n).add(base)) ??? .filter(i -> i.isProbablePrime(50)) ??? .count(); goes from 1 minute 20 seconds down to about 35 seconds om my VM, over multiple runs.? As is the case on other platforms where the intrinsics are supported, they will be enabled by default on Windows. Thank you for your time, -Simon Tooke Principle Software Engineer, Red Hat Canada From valerie.peng at oracle.com Thu May 21 22:08:02 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 21 May 2020 15:08:02 -0700 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases In-Reply-To: <023b046e-83d1-32ec-f8bd-b1a886be0ef4@oracle.com> References: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> <023b046e-83d1-32ec-f8bd-b1a886be0ef4@oracle.com> Message-ID: <875e8f7f-b94a-19a6-a90a-a6bde65c2295@oracle.com> On 5/20/2020 7:38 PM, sha.jiang at oracle.com wrote: > >> - line 176, maybe it's better to just supply the type, clearer and >> less dependency. >> > Not get this point. > Could you please describe some more? I mean to change line 176 as below (see the added text in blue): 176 return createTrustStore(DEFAULT_TYPE, certStrs, null); >> With this extra aliases argument, number of createTrustStore(...) >> methods doubled from 2 to 4, number of createKeyStore(...) methods >> also doubled from 4 to 8. Isn't it a bit much to have 8 methods doing >> the same thing? Especially in the case of createKeyStore(...), quite >> a few of them have long list of arguments with the same type, >> combining this with the large number of methods, it can get confusing >> on which method is called. How often do you think the aliases are >> supplied? Maybe we only add methods which will be used instead of >> adding all possible combinations. >> > I'll remove 4 createKeyStore(...) methods (like the below one) that > have long list of arguments. > createKeyStore(String type, String[] keyAlgos, > ??????????? String[] keyStrs, String[] passwords, String[] certStrs, > ??????????? String[] aliases) > It looks no test is using them. My tests also won't use them. Sounds good. Thanks, Valerie > > Best regards, > John Jiang >> >> Thanks, >> Valerie >> On 5/15/2020 11:40 PM, sha.jiang at oracle.com wrote: >>> Hi, >>> This patch adds some new createTrustStore() and createKeyStore() >>> methods to test >>> lib class jdk.test.lib.security.KeyStoreUtils. >>> These new methods allow to pass trust/key store aliases in. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ >>> >>> Best regards, >>> John Jiang >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sha.jiang at oracle.com Fri May 22 03:18:24 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 22 May 2020 11:18:24 +0800 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases In-Reply-To: <875e8f7f-b94a-19a6-a90a-a6bde65c2295@oracle.com> References: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> <023b046e-83d1-32ec-f8bd-b1a886be0ef4@oracle.com> <875e8f7f-b94a-19a6-a90a-a6bde65c2295@oracle.com> Message-ID: <7579bb12-d03a-81ea-08fc-75e4a9a599ad@oracle.com> Hi Valerie, Thanks for your clarification! Could you please review this updated webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.01/ Best regards, John Jiang On 2020/5/22 06:08, Valerie Peng wrote: > > > On 5/20/2020 7:38 PM, sha.jiang at oracle.com wrote: >> >>> - line 176, maybe it's better to just supply the type, clearer and >>> less dependency. >>> >> Not get this point. >> Could you please describe some more? > > I mean to change line 176 as below (see the added text in blue): > > 176 return createTrustStore(DEFAULT_TYPE, certStrs, null); > > >>> With this extra aliases argument, number of createTrustStore(...) >>> methods doubled from 2 to 4, number of createKeyStore(...) methods >>> also doubled from 4 to 8. Isn't it a bit much to have 8 methods >>> doing the same thing? Especially in the case of createKeyStore(...), >>> quite a few of them have long list of arguments with the same type, >>> combining this with the large number of methods, it can get >>> confusing on which method is called. How often do you think the >>> aliases are supplied? Maybe we only add methods which will be used >>> instead of adding all possible combinations. >>> >> I'll remove 4 createKeyStore(...) methods (like the below one) that >> have long list of arguments. >> createKeyStore(String type, String[] keyAlgos, >> ??????????? String[] keyStrs, String[] passwords, String[] certStrs, >> ??????????? String[] aliases) >> It looks no test is using them. My tests also won't use them. > > Sounds good. > > Thanks, > Valerie >> >> Best regards, >> John Jiang >>> >>> Thanks, >>> Valerie >>> On 5/15/2020 11:40 PM, sha.jiang at oracle.com wrote: >>>> Hi, >>>> This patch adds some new createTrustStore() and createKeyStore() >>>> methods to test >>>> lib class jdk.test.lib.security.KeyStoreUtils. >>>> These new methods allow to pass trust/key store aliases in. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ >>>> >>>> Best regards, >>>> John Jiang >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri May 22 14:04:31 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2020 10:04:31 -0400 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> Message-ID: <2442a046-6640-f759-6330-e971405f0c78@oracle.com> Cross-posting to hotspot-dev for additional review since the code changes are in hotspot. --Sean On 5/21/20 1:24 PM, Simon Tooke wrote: > Hello, > > I'd like to request a review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk/00/00/ > > This change implements the given intrinsics on Windows. > > The Windows toolchain has no 128 bit integer types, and no inline asm > (on x64 and Arm).? In addition, 'long' is 4 bytes, not 8, as it is with > gcc.? This patch had to change some of the linux implementation to > account for these limitations. > > My gratitude for Andrew Haley for doing the heavy lifting at the core of > this patch. > > The patch, if accepted, will be offered to 11u as a potential backport. > The changes apply cleanly modulo some line number changes. > > As for the speedup, this test case: > > BigInteger base = BigInteger.ONE.shiftLeft(1024); > long count = LongStream.rangeClosed(2, 100_000) > ??? .mapToObj(n -> BigInteger.valueOf(n).add(base)) > ??? .filter(i -> i.isProbablePrime(50)) > ??? .count(); > > goes from 1 minute 20 seconds down to about 35 seconds om my VM, over > multiple runs.? As is the case on other platforms where the intrinsics > are supported, they will be enabled by default on Windows. > > Thank you for your time, > > -Simon Tooke > > > Principle Software Engineer, > > Red Hat Canada > > > From weijun.wang at oracle.com Fri May 22 14:30:41 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 22 May 2020 22:30:41 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA Message-ID: Please take a review at CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ Major points in CSR: - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms major code changes: - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed Next I'll do some basic interop tests with openssl and BouncyCastle. Thanks, Max From sean.mullan at oracle.com Fri May 22 15:41:22 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2020 11:41:22 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> Message-ID: On 5/15/20 6:11 PM, Xuelei Fan wrote: > New webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.04/ * src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java 212 SSLLogger.warning( 213 "Too much certificate authorities to use " + 214 "the certificate_authorities extension"); How about: "The number of CAs exceeds the maximum size of the certificate_authorities extension" * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java The test is still using the previous property name: jdk.tls.client.indicateCertificateAuthorities * test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java Will this test FAIL if we ever exceed the maximum number of CAs? I think it is important that it does FAIL, as the extension is effectively not working anymore and could cause compatibility issues. I even think we would need to try to think of some way to fix it, either by seeing if some CAs could be excluded - not really sure, hopefully it won't ever happen but we would want to know about it in advance. * src/java.base/share/classes/sun/security/ssl/SSLExtension.java Some typos and wording suggestions: 750 // Note: Plese be careful to enable this extension in ClientHello. Typo: Please 757 // untrusted server certificate. If this extension is enabled in 758 // the ClientHello handshake message, the server does not send 759 // certificate which is not indicated in the extension. The server 760 // will just terminate handshake and close the connection. Then A few more details would be useful above - how about combining the 2 sentences as: "If this extension is enabled in the ClientHello handshake message, and the server's certificate does not chain back to any of the CAs in the extension, then the server will terminate the handshake and close the connection." 761 // there is no chance for client to perform the manually checking. "the client" s/manually checking/manual check/ 762 // Therefore, enable this extension in ClientHello may lead to s/enable/enabling/ 767 // maximum TLS record size is 2^14 bytes. In case of handshake s/In case of/If the/ 768 // message is bigger then maximum TLS record size, it should be s/then/than the/ 770 // implementations does not allow ClientHello message bigger than s/does/do/ s/message/messages/ 771 // the maximum TLS record size and aborts connection immediately s/aborts connection immediately/will immediately abort the connection/ 772 // with a fatal alert. Therefore, if the client accepts too much s/accepts too much/trusts too many/ 775 // Further more, if the client accepts too much CAs to meet the 776 // size limit of the extension, enabling this extension in client s/Further more/Furthermore/ s/accepts too much CAs to meet the/trusts more CAs such that it exceeds the/ --Sean > > On 5/15/2020 5:27 AM, Sean Mullan wrote: >> On 5/15/20 1:22 AM, Xuelei Fan wrote: >>> Alexey has some good point about the size limit of the extension.? I >>> added more comments about the compatibility impact and interop impact >>> when there is too much CAs to meet the size limits in CSR, source >>> code and release notes. >>> >>> New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460 >>> >>> I have not had a chance to add a negative test case yet. >> >> By negative test case, do you mean trying to exceed the maximum number >> of CAs? I agree that would be a good test to add, as we may or may not >> exceed that number some day, but it would be good to know when/if we do. >> > Yes.? I added a new test case in webrev.04 (TooMuchCAs.java). > > Xuelei > >> --Sean >> >>> >>> On 5/14/2020 1:38 PM, Sean Mullan wrote: >>>> For the CSR, why did you check the binary and behavioral boxes for >>>> compatibility risk? >>> I should not check the boxes.? Removed. >>> >>> Thanks, >>> Xuelei >>> >>>> Otherwise it looks good, and I added my name as Reviewer. I will >>>> review the updated webrev later. >>>> >>>> Please file and add a link to a docs issue to document the new >>>> system property. >>>> >>>> --Sean >>>> >>>> On 5/13/20 5:20 PM, Xuelei Fan wrote: >>>>> >>>>> On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>>>>>> It is not expected to use this extension regularly. >>>>>>>>> >>>>>>>>> Please let me know if you still prefer to use "enableCAExtension". >>>>>>>>> >>>>>>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>>>>>> property to enable it. Can we not enable it based on whether >>>>>>>>>> the configured X509TrustManager.getAcceptedIssuers returns a >>>>>>>>>> non-empty list? >>>>>>>>>> >>>>>>>>> We can do that on server side, but there are compatibility >>>>>>>>> impact on client behavior if we did it in client side.? See #2 >>>>>>>>> in the "Specification" section. >>>>>>>> >>>>>>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>>>>>> exception and close the connection if the server's certificate >>>>>>>> cannot be validated? Could we check if the PKIX TrustManager is >>>>>>>> being used? >>>>>>>> >>>>>>> Yes, the trust manager could throw a fatal exception and close >>>>>>> the connection if the trust cannot be established.? The fallback >>>>>>> mechanism is implemented in the customized trust manager, that if >>>>>>> users accept the cert, the cert is trusted, and no exception and >>>>>>> the handshaking continued.? It is too later to fallback after the >>>>>>> connection closed. >>>>>> >>>>>>>> If a client wants to accept self-signed or untrusted server >>>>>>>> certificates, I would have expected them to have to use a custom >>>>>>>> X509TrustManager that allows that, and that getAcceptedIssuers() >>>>>>>> should return an empty List. Is that not is what is typically >>>>>>>> done in practice? >>>>>>>> >>>>>>> Yes, customized trust manager is used to accept users manually >>>>>>> selection.? As the users may also want to accept normal >>>>>>> certificate without manually involved, so getAcceptedIssuers() >>>>>>> should respect those CA as well. >>>>>> >>>>>> I see. Out of curiosity, have you checked how other >>>>>> implementations handle this extension? For web browsers, they >>>>>> typically give the user the option of proceeding if the server >>>>>> certificate is not trusted. Seems to be a bit of a configuration >>>>>> dilemma as you may want this extension enabled for certain sites >>>>>> that have multiple certificates, but not as a general default >>>>>> because then you wouldn't be able to connect to untrusted sites >>>>>> (at your own risk of course). I wonder if it would have been >>>>>> better for the RFC to allow the server to treat this extension >>>>>> more as a hint, and still return its chain if an acceptable >>>>>> certificate could not be found. >>>>> If it is treated as a hint, then it might be better no have this >>>>> extension. >>>>> >>>>> I checked with browsers, the extension is not present in >>>>> ClientHello. For JDK, I would not expect a lot use of this >>>>> extension in client side. It is just designed to workaround a few >>>>> cases, just as you mentioned above. >>>>> >>>>> Xuelei From xuelei.fan at oracle.com Fri May 22 17:55:20 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 May 2020 10:55:20 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> Message-ID: <7d2d05b4-86c5-78b1-538d-21d03d0ae1be@oracle.com> All good comments. I updated the code and CSR accordingly. http://cr.openjdk.java.net/~xuelei/8206925/webrev.05/ On 5/22/2020 8:41 AM, Sean Mullan wrote: > On 5/15/20 6:11 PM, Xuelei Fan wrote: >> New webrev: http://cr.openjdk.java.net/~xuelei/8206925/webrev.04/ > > * > src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java > > > ?212???????????????????? SSLLogger.warning( > ?213???????????????????????????? "Too much certificate authorities to > use " + > ?214???????????????????????????? "the certificate_authorities extension"); > > How about: "The number of CAs exceeds the maximum size of the > certificate_authorities extension" > > * test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java > > The test is still using the previous property name: > jdk.tls.client.indicateCertificateAuthorities > > * test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java > > Will this test FAIL if we ever exceed the maximum number of CAs? I think > it is important that it does FAIL, as the extension is effectively not > working anymore and could cause compatibility issues. I even think we > would need to try to think of some way to fix it, either by seeing if > some CAs could be excluded - not really sure, hopefully it won't ever > happen but we would want to know about it in advance. > Alexey (from azul) and I discussed the idea to control the number of CAs. However, there are still some issues in practice. "If the certificate authorities can not be fully listed, it cannot be used to indicate the peer certificate selection accuracy. For example, client support A, B and C, and is only able to indicate A and B. If the server supports C, the connection cannot be established with this extension. This is not the expected behavior. Maybe, it is no worse than without this extension. " It looks like safer that the extension is not used if the size exceed the limit, at least there ARE less compatibility issues. I have a note in the CSR and release note for the behaviors. The test case, TooMuchCAs, is used to make sure the connection can be established when the CAs size exceed the limit (no extension used). Xuelei > * src/java.base/share/classes/sun/security/ssl/SSLExtension.java > > Some typos and wording suggestions: > > 750???????????? // Note: Plese be careful to enable this extension in > ClientHello. > > Typo: Please > > ?757???????????? // untrusted server certificate. If this extension is > enabled in > ?758???????????? // the ClientHello handshake message, the server does > not send > ?759???????????? // certificate which is not indicated in the > extension.? The server > ?760???????????? // will just terminate handshake and close the > connection.? Then > > A few more details would be useful above - how about combining the 2 > sentences as: > > "If this extension is enabled in the ClientHello handshake message, and > the server's certificate does not chain back to any of the CAs in the > extension, then the server will terminate the handshake and close the > connection." > > 761???????????? // there is no chance for client to perform the manually > checking. > > "the client" > s/manually checking/manual check/ > > 762???????????? // Therefore, enable this extension in ClientHello may > lead to > > s/enable/enabling/ > > 767???????????? // maximum TLS record size is 2^14 bytes.? In case of > handshake > > s/In case of/If the/ > > 768???????????? // message is bigger then maximum TLS record size, it > should be > > s/then/than the/ > > 770???????????? // implementations does not allow ClientHello message > bigger than > > s/does/do/ > s/message/messages/ > > 771???????????? // the maximum TLS record size and aborts connection > immediately > > s/aborts connection immediately/will immediately abort the connection/ > > 772???????????? // with a fatal alert.? Therefore, if the client accepts > too much > > s/accepts too much/trusts too many/ > > 775???????????? // Further more, if the client accepts too much CAs to > meet the > 776???????????? // size limit of the extension, enabling this extension > in client > > s/Further more/Furthermore/ > s/accepts too much CAs to meet the/trusts more CAs such that it exceeds > the/ > > --Sean > >> >> On 5/15/2020 5:27 AM, Sean Mullan wrote: >>> On 5/15/20 1:22 AM, Xuelei Fan wrote: >>>> Alexey has some good point about the size limit of the extension.? I >>>> added more comments about the compatibility impact and interop >>>> impact when there is too much CAs to meet the size limits in CSR, >>>> source code and release notes. >>>> >>>> New webrev: https://bugs.openjdk.java.net/browse/JDK-8244460 >>>> >>>> I have not had a chance to add a negative test case yet. >>> >>> By negative test case, do you mean trying to exceed the maximum >>> number of CAs? I agree that would be a good test to add, as we may or >>> may not exceed that number some day, but it would be good to know >>> when/if we do. >>> >> Yes.? I added a new test case in webrev.04 (TooMuchCAs.java). >> >> Xuelei >> >>> --Sean >>> >>>> >>>> On 5/14/2020 1:38 PM, Sean Mullan wrote: >>>>> For the CSR, why did you check the binary and behavioral boxes for >>>>> compatibility risk? >>>> I should not check the boxes.? Removed. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Otherwise it looks good, and I added my name as Reviewer. I will >>>>> review the updated webrev later. >>>>> >>>>> Please file and add a link to a docs issue to document the new >>>>> system property. >>>>> >>>>> --Sean >>>>> >>>>> On 5/13/20 5:20 PM, Xuelei Fan wrote: >>>>>> >>>>>> On 5/13/2020 2:11 PM, Sean Mullan wrote: >>>>>>>>>> It is not expected to use this extension regularly. >>>>>>>>>> >>>>>>>>>> Please let me know if you still prefer to use >>>>>>>>>> "enableCAExtension". >>>>>>>>>> >>>>>>>>>>> Also, it is a bit unfortunate that we have to have a system >>>>>>>>>>> property to enable it. Can we not enable it based on whether >>>>>>>>>>> the configured X509TrustManager.getAcceptedIssuers returns a >>>>>>>>>>> non-empty list? >>>>>>>>>>> >>>>>>>>>> We can do that on server side, but there are compatibility >>>>>>>>>> impact on client behavior if we did it in client side.? See #2 >>>>>>>>>> in the "Specification" section. >>>>>>>>> >>>>>>>>> But doesn't the default JDK PKIX TrustManager throw a fatal >>>>>>>>> exception and close the connection if the server's certificate >>>>>>>>> cannot be validated? Could we check if the PKIX TrustManager is >>>>>>>>> being used? >>>>>>>>> >>>>>>>> Yes, the trust manager could throw a fatal exception and close >>>>>>>> the connection if the trust cannot be established.? The fallback >>>>>>>> mechanism is implemented in the customized trust manager, that >>>>>>>> if users accept the cert, the cert is trusted, and no exception >>>>>>>> and the handshaking continued.? It is too later to fallback >>>>>>>> after the connection closed. >>>>>>> >>>>>>>>> If a client wants to accept self-signed or untrusted server >>>>>>>>> certificates, I would have expected them to have to use a >>>>>>>>> custom X509TrustManager that allows that, and that >>>>>>>>> getAcceptedIssuers() should return an empty List. Is that not >>>>>>>>> is what is typically done in practice? >>>>>>>>> >>>>>>>> Yes, customized trust manager is used to accept users manually >>>>>>>> selection.? As the users may also want to accept normal >>>>>>>> certificate without manually involved, so getAcceptedIssuers() >>>>>>>> should respect those CA as well. >>>>>>> >>>>>>> I see. Out of curiosity, have you checked how other >>>>>>> implementations handle this extension? For web browsers, they >>>>>>> typically give the user the option of proceeding if the server >>>>>>> certificate is not trusted. Seems to be a bit of a configuration >>>>>>> dilemma as you may want this extension enabled for certain sites >>>>>>> that have multiple certificates, but not as a general default >>>>>>> because then you wouldn't be able to connect to untrusted sites >>>>>>> (at your own risk of course). I wonder if it would have been >>>>>>> better for the RFC to allow the server to treat this extension >>>>>>> more as a hint, and still return its chain if an acceptable >>>>>>> certificate could not be found. >>>>>> If it is treated as a hint, then it might be better no have this >>>>>> extension. >>>>>> >>>>>> I checked with browsers, the extension is not present in >>>>>> ClientHello. For JDK, I would not expect a lot use of this >>>>>> extension in client side. It is just designed to workaround a few >>>>>> cases, just as you mentioned above. >>>>>> >>>>>> Xuelei From sean.mullan at oracle.com Fri May 22 18:17:04 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2020 14:17:04 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: <7d2d05b4-86c5-78b1-538d-21d03d0ae1be@oracle.com> References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> <7d2d05b4-86c5-78b1-538d-21d03d0ae1be@oracle.com> Message-ID: On 5/22/20 1:55 PM, Xuelei Fan wrote: >> * test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java >> >> Will this test FAIL if we ever exceed the maximum number of CAs? I >> think it is important that it does FAIL, as the extension is >> effectively not working anymore and could cause compatibility issues. >> I even think we would need to try to think of some way to fix it, >> either by seeing if some CAs could be excluded - not really sure, >> hopefully it won't ever happen but we would want to know about it in >> advance. >> > Alexey (from azul) and I discussed the idea to control the number of > CAs.? However, there are still some issues in practice. > > "If the certificate authorities can not be fully listed, it cannot be > used to indicate the peer certificate selection accuracy.? For example, > client support A, B and C, and is only able to indicate A and B.? If the > server supports C, the connection cannot be established with this > extension. This is not the expected behavior.? Maybe, it is no worse > than without this extension. " > > It looks like safer that the extension is not used if the size exceed > the limit, at least there ARE less compatibility issues.? I have a note > in the CSR and release note for the behaviors. > > The test case, TooMuchCAs, is used to make sure the connection can be > established when the CAs size exceed the limit (no extension used). Sure, I agree that is the best behavior. I guess my point is that if we ever really exceed the maximum number of CAs in the cacerts keystore, it would be good to have a test that will fail because of that. Minimally, this would allow us to publish a release note warning users that the CA extension will no longer work unless some roots are removed. Would the other test fail (test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java) if that happens? --Sean From sean.mullan at oracle.com Fri May 22 20:44:08 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 22 May 2020 16:44:08 -0400 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: Message-ID: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> On 5/22/20 10:30 AM, Weijun Wang wrote: > Please take a review at > > CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 > webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ > > Major points in CSR: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner In the CSR, it says "In fact, the new -sigalg option values are quite useless and do not need to specified." What happens if you specify anything other than the defaults? In the Supported Algorithms, what does keysize: (empty) mean? Do you mean "any size" as in the current table for DSA? > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms I think the CSR should have the proposed changes to the JAR specification instead of just saying it will be described. Also, we never defined the "EC" type, so I think this CSR is a good opportunity to also fix that and add that extension to the JAR spec. --Sean > major code changes: > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > Next I'll do some basic interop tests with openssl and BouncyCastle. > > Thanks, > Max > From xuelei.fan at oracle.com Fri May 22 22:38:29 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 22 May 2020 15:38:29 -0700 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> <7d2d05b4-86c5-78b1-538d-21d03d0ae1be@oracle.com> Message-ID: On 5/22/2020 11:17 AM, Sean Mullan wrote: > On 5/22/20 1:55 PM, Xuelei Fan wrote: >>> * test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java >>> >>> Will this test FAIL if we ever exceed the maximum number of CAs? I >>> think it is important that it does FAIL, as the extension is >>> effectively not working anymore and could cause compatibility issues. >>> I even think we would need to try to think of some way to fix it, >>> either by seeing if some CAs could be excluded - not really sure, >>> hopefully it won't ever happen but we would want to know about it in >>> advance. >>> >> Alexey (from azul) and I discussed the idea to control the number of >> CAs.? However, there are still some issues in practice. >> >> "If the certificate authorities can not be fully listed, it cannot be >> used to indicate the peer certificate selection accuracy.? For >> example, client support A, B and C, and is only able to indicate A and >> B.? If the server supports C, the connection cannot be established >> with this extension. This is not the expected behavior.? Maybe, it is >> no worse than without this extension. " >> >> It looks like safer that the extension is not used if the size exceed >> the limit, at least there ARE less compatibility issues.? I have a >> note in the CSR and release note for the behaviors. >> >> The test case, TooMuchCAs, is used to make sure the connection can be >> established when the CAs size exceed the limit (no extension used). > > Sure, I agree that is the best behavior. I guess my point is that if we > ever really exceed the maximum number of CAs in the cacerts keystore, it > would be good to have a test that will fail because of that. Minimally, > this would allow us to publish a release note warning users that the CA > extension will no longer work unless some roots are removed. > Good point. It is useful to have a test case to check the size limit of the cacert keystore. A new test case, CacertsLimit.java, is added. The same webrev URL is used: http://cr.openjdk.java.net/~xuelei/8206925/webrev.05/ > Would the other test fail > (test/jdk/sun/security/ssl/X509KeyManager/CertificateAuthorities.java) > if that happens? > No, it should pass. Xuelei From weijun.wang at oracle.com Sat May 23 01:24:41 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2020 09:24:41 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> Message-ID: > On May 23, 2020, at 4:44 AM, Sean Mullan wrote: > > On 5/22/20 10:30 AM, Weijun Wang wrote: >> Please take a review at >> CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 >> webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ >> Major points in CSR: >> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > In the CSR, it says "In fact, the new -sigalg option values are quite useless and do not need to specified." > > What happens if you specify anything other than the defaults? If not compatible with the key alg, an error will be reported. This is implemented in SignatureUtil.checkKeyAndSigAlgMatch. Precisely, if the key alg is RSASSA-PSS, you can only set "-siglag RSASSA-PSS". For Ed25519, everything other than "-sigalg EdDSA" or "-sigalg Ed25519" will lead to an error, and these 2 are actually the same. > > In the Supported Algorithms, what does keysize: (empty) mean? Do you mean "any size" as in the current table for DSA? You can say that (RSASSA-PSS can be any size, EdDSA can be any of those 2 sizes). Of course, it's not unrelated, and I've added "using the same parameters of the key" in the default siglag cells. For EdDSA, it's more precise to say "using the same key size". > >> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms > > I think the CSR should have the proposed changes to the JAR specification instead of just saying it will be described. Also, we never defined the "EC" type, so I think this CSR is a good opportunity to also fix that and add that extension to the JAR spec. OK. Thanks, Max > > --Sean > >> major code changes: >> - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java >> - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId >> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing >> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms >> - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed >> Next I'll do some basic interop tests with openssl and BouncyCastle. >> Thanks, >> Max From weijun.wang at oracle.com Sat May 23 01:45:24 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2020 09:45:24 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> Message-ID: <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> >> >> In the Supported Algorithms, what does keysize: (empty) mean? Do you mean "any size" as in the current table for DSA? > > You can say that (RSASSA-PSS can be any size, EdDSA can be any of those 2 sizes). Of course, it's not unrelated, and I've added "using the same parameters of the key" in the default siglag cells. For EdDSA, it's more precise to say "using the same key size". > I just realized that an RSASSA-PSS key could have no params in its AlgorithmId. In this case, the key size will be used to determine the params of the Signature similar to that of RSA (i.e. 2048 key leads to RSASSA-PSS using SHA-256 as hash and MGF1 algorithms). I'll find out a way to describe this. Thanks, Max From hai-may.chao at oracle.com Sat May 23 03:01:50 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 22 May 2020 20:01:50 -0700 Subject: RFR[15] 8245665: Test WeakAlg.java should only make sure no warning for weak signature algorithms by keytool on root CA Message-ID: Hi, I?d like to request q review for - JBS: https://bugs.openjdk.java.net/browse/JDK-8245665 Webrev: https://cr.openjdk.java.net/~hchao/8245665/webrev.00/ Keytool only emits warnings for the root CA in cacerts using the weak key, but not for using the weak algorithm. So test case WeakAlg.java should do the checking on warnings accordingly. Thanks, Hai-May From weijun.wang at oracle.com Sat May 23 03:50:17 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2020 11:50:17 +0800 Subject: RFR[15] 8245665: Test WeakAlg.java should only make sure no warning for weak signature algorithms by keytool on root CA In-Reply-To: References: Message-ID: You probably should use shouldNotMatch() because here it's a pattern match instead of simply contain. Try add a MD5withRSA cert there to see how it works. Thanks, Max > On May 23, 2020, at 11:01 AM, Hai-May Chao wrote: > > Hi, > > I?d like to request q review for - > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245665 > Webrev: https://cr.openjdk.java.net/~hchao/8245665/webrev.00/ > > Keytool only emits warnings for the root CA in cacerts using the weak key, but not for using the weak algorithm. So test case WeakAlg.java should do the checking on warnings accordingly. > > Thanks, > Hai-May > From hai-may.chao at oracle.com Sat May 23 06:44:29 2020 From: hai-may.chao at oracle.com (Hai-May Chao) Date: Fri, 22 May 2020 23:44:29 -0700 Subject: RFR[15] 8245665: Test WeakAlg.java should only make sure no warning for weak signature algorithms by keytool on root CA In-Reply-To: References: Message-ID: <3256D90D-B40E-474D-B676-0B0C352AAB99@oracle.com> I did testing with a MD5RSA root CA. Updated the webrev. Thanks, Hai-May > On May 22, 2020, at 8:50 PM, Weijun Wang wrote: > > You probably should use shouldNotMatch() because here it's a pattern match instead of simply contain. > > Try add a MD5withRSA cert there to see how it works. > > Thanks, > Max > >> On May 23, 2020, at 11:01 AM, Hai-May Chao wrote: >> >> Hi, >> >> I?d like to request q review for - >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245665 >> Webrev: https://cr.openjdk.java.net/~hchao/8245665/webrev.00/ >> >> Keytool only emits warnings for the root CA in cacerts using the weak key, but not for using the weak algorithm. So test case WeakAlg.java should do the checking on warnings accordingly. >> >> Thanks, >> Hai-May >> > From weijun.wang at oracle.com Sat May 23 06:50:51 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2020 14:50:51 +0800 Subject: RFR[15] 8245665: Test WeakAlg.java should only make sure no warning for weak signature algorithms by keytool on root CA In-Reply-To: <3256D90D-B40E-474D-B676-0B0C352AAB99@oracle.com> References: <3256D90D-B40E-474D-B676-0B0C352AAB99@oracle.com> Message-ID: <1C627526-3887-458C-90C3-E4DDD8D3CEEC@oracle.com> Good. It's at https://hg.openjdk.java.net/jdk/jdk/rev/6309cf0a3b17 now. > On May 23, 2020, at 2:44 PM, Hai-May Chao wrote: > > I did testing with a MD5RSA root CA. Updated the webrev. > > Thanks, > Hai-May > > >> On May 22, 2020, at 8:50 PM, Weijun Wang wrote: >> >> You probably should use shouldNotMatch() because here it's a pattern match instead of simply contain. >> >> Try add a MD5withRSA cert there to see how it works. >> >> Thanks, >> Max >> >>> On May 23, 2020, at 11:01 AM, Hai-May Chao wrote: >>> >>> Hi, >>> >>> I?d like to request q review for - >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245665 >>> Webrev: https://cr.openjdk.java.net/~hchao/8245665/webrev.00/ >>> >>> Keytool only emits warnings for the root CA in cacerts using the weak key, but not for using the weak algorithm. So test case WeakAlg.java should do the checking on warnings accordingly. >>> >>> Thanks, >>> Hai-May >>> >> > From weijun.wang at oracle.com Sat May 23 08:21:12 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 23 May 2020 16:21:12 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> Message-ID: CSR updated at https://bugs.openjdk.java.net/browse/JDK-8245274 with the full patch on docs. Thanks, Max > On May 23, 2020, at 9:45 AM, Weijun Wang wrote: > >>> >>> In the Supported Algorithms, what does keysize: (empty) mean? Do you mean "any size" as in the current table for DSA? >> >> You can say that (RSASSA-PSS can be any size, EdDSA can be any of those 2 sizes). Of course, it's not unrelated, and I've added "using the same parameters of the key" in the default siglag cells. For EdDSA, it's more precise to say "using the same key size". >> > > I just realized that an RSASSA-PSS key could have no params in its AlgorithmId. In this case, the key size will be used to determine the params of the Signature similar to that of RSA (i.e. 2048 key leads to RSASSA-PSS using SHA-256 as hash and MGF1 algorithms). > > I'll find out a way to describe this. > > Thanks, > Max > From 1983-01-06 at gmx.net Sat May 23 23:38:06 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 24 May 2020 01:38:06 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: > Hello, > > Could you please review the following patch: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 > Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ Let's go through your changes statically: * The JIRA issue title has a typo * The word "cannot" is incorrectly spelled throughout all exception messages > + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { > + throw new UnsupportedOperationException("LdapCtx: " + > + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); "LdapCtx: " is redundant because the stacktrace will contain the class name already. A better message would be: "Channel binding type '%s' is not supported". Not just the plain value. > + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { > + if (connectTimeout == -1) > + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + > + CONNECT_TIMEOUT + " property is set."); * Same here with the message * The IAE is wrong because passed value is correct, but leads to an invalid state because connection timeout is -1. You need an IllegalStateException here. Stupid question: how can one create a GSS security context when the TLS security context has not been established yet? > --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 > +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 > @@ -531,9 +531,12 @@ > public void setChannelBinding(ChannelBinding channelBindings) > throws GSSException { > > - if (mechCtxt == null) > + if (mechCtxt == null) { > + if (this.channelBindings != null) { > + throw new GSSException(GSSException.BAD_BINDINGS); > + } > this.channelBindings = channelBindings; > - > + } > } I don't understand the purpose of this hunk. Is this safeguard to set bindings only once? > private static final int CHANNEL_BINDING_AF_INET = 2; > private static final int CHANNEL_BINDING_AF_INET6 = 24; > private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; > + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; This should sort from 0 to 255 and not at the end. > private int getAddrType(InetAddress addr) { > - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; > + int addressType = CHANNEL_BINDING_AF_UNSPEC; > // initialize addrtype in CB first > - cb->initiator_addrtype = GSS_C_AF_NULLADDR; > - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > + cb->initiator_addrtype = GSS_C_AF_UNSPEC; > + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; This looks wrong to me -- as you already mentioned -- this violates RFC 2744, section 3.11, last sentence: > or omit addressing information, specifying > GSS_C_AF_NULLADDR as the address-types. > /* release initiator address */ > - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { > + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && > + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { > resetGSSBuffer(&(cb->initiator_address)); > } > /* release acceptor address */ > - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { > + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && > + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { > resetGSSBuffer(&(cb->acceptor_address)); > } Unspecified does not mean that it is null. > + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); > + byte[] cbData = Arrays.copyOf(prefix, > + prefix.length + tlsCB.getData().length ); > + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); Since you are calling "tlsCB.getData()" multiple times, this should go into a variable. > + secCtx.setChannelBinding(new ChannelBinding(null, null, cbData)); Why not use new ChannelBinding(cbData)? > + String hashAlg = serverCertificate.getSigAlgName(). > + replace("SHA", "SHA-").toUpperCase(); > + int ind = hashAlg.indexOf("WITH"); > + if (ind > 0) { > + hashAlg = hashAlg.substring(0, ind); > + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { > + hashAlg = "SHA-256"; > + } I have several problems with that, some might be hypothetical: * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then at sun.security.x509.AlgorithmId.getName() it uses nameTable to translate OIDs to readible names. With indexOf("WITH") you are implying that the cert's sig alg may not use a cryptographic function, but this would mean that if the OID is 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, wouldn't you? I also don't know how realistic "PBEWith..." is. This likely needs more thought or I am missing something. * Exception messages are inconsistent. Sometimes "TLS channel binding", sometimes just "channel binding". To avoid misunderstandings it should always read "TLS channel binding..". Generally, I have two fundemental issues: * How do you know that address type must be UNSPEC and not NULLADDR? Trial and error? * Changing the default address type against the RFC will break every installation using channel bindings relying on it with cross GSS-API implementations. There must be another way to solve this. A system property would also be problematic because if you have a product which connects to MS and non-MS backends at the same time, channel bindings would be broken again. What about introducing a UnspecEmptyInetAddress() which gives the proper AF type, but #getAddress() would return null? This should satisfy the requirements, InitialToken as well as the RFC. this of course needs to be properly passed to native providers too. GssKrb5Client would also need to know that this channel binding is explicitly for Active Directory and not some other, spec-compliant, SASL peer (property on LdapCtx?) One could easily use this for custom code with a SSLServerSocket paired with Java SASL or in C, OpenSSL and Cyrus SASL. Michael PS: Yes, I am a nitpicker. From 1983-01-06 at gmx.net Sun May 24 09:00:36 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 24 May 2020 11:00:36 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Message-ID: <6118c0df-30c2-0b2c-a67f-3a74bddc839d@gmx.net> Am 2020-05-24 um 01:38 schrieb Michael Osipov: > Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: > ... > What about introducing a UnspecEmptyInetAddress() which gives the proper > AF type, but #getAddress() would return null? This should satisfy the > requirements, InitialToken as well as the RFC. this of course needs to > be properly passed to native providers too. GssKrb5Client would also > need to know that this channel binding is explicitly for Active > Directory and not some other, spec-compliant, SASL peer (property on > LdapCtx?) Giving this more thought. I believe you have also found a bug in InitialToken#getAddrType(InetAddress). It would return CHANNEL_BINDING_AF_NULL_ADDR if addr is neither Inet6 nor Inet6, but is not null which is wrong. But this is just a hypothetical case. M From sha.jiang at oracle.com Mon May 25 01:53:19 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Mon, 25 May 2020 09:53:19 +0800 Subject: RFR[15] JDK-8245691: Add EdDSA certificstes to SSLSocketTemplate and CertUtils Message-ID: Hi, This patch just adds some EdDSA, including Ed25519 and Ed448, certificates to javax/net/ssl/SSLSocketTemplate.java and jdk/test/lib/security/CertUtils.java. Please note these new certificates are not used by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8245691 Webrev: http://cr.openjdk.java.net/~jjiang/8245691/webrev.00/ Best regards, John Jiang From xuelei.fan at oracle.com Mon May 25 03:11:41 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 24 May 2020 20:11:41 -0700 Subject: RFR[15] JDK-8245691: Add EdDSA certificstes to SSLSocketTemplate and CertUtils In-Reply-To: References: Message-ID: <6018e7e1-46d9-246e-5731-299ab10ee284@oracle.com> Looks good to me. Thank you for adding the cert for EdDSA. Xuelei On 5/24/2020 6:53 PM, sha.jiang at oracle.com wrote: > Hi, > This patch just adds some EdDSA, including Ed25519 and Ed448, certificates > to javax/net/ssl/SSLSocketTemplate.java and > jdk/test/lib/security/CertUtils.java. > > Please note these new certificates are not used by default. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8245691 > Webrev: http://cr.openjdk.java.net/~jjiang/8245691/webrev.00/ > > Best regards, > John Jiang > From 1983-01-06 at gmx.net Mon May 25 10:15:04 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Mon, 25 May 2020 12:15:04 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: Am 2020-05-24 um 22:29 schrieb Thomas Maslen: > [Off-list reply just to you two gents. Feel free to forward it to the list > if it helps, or ignore it if it doesn't] > > I'm just adding my 0.02 on zero vs 255 for the "no address" type in a > channel binding > > ---------- Forwarded message ---------- >> From: Michael Osipov <1983-01-06 at gmx.net> >> To: Alexey Bakhtin , "core-libs-dev at openjdk.java.net" < >> core-libs-dev at openjdk.java.net> >> Cc: "security-dev at openjdk.java.net" >> Bcc: >> Date: Sun, 24 May 2020 01:38:06 +0200 >> Subject: Re: RFR: 8245527: LDAP Cnannel Binding support for Java >> GSS/Kerberos >> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> Let's go through your changes statically: >> > > [...] > >> private static final int CHANNEL_BINDING_AF_INET = 2; >>> private static final int CHANNEL_BINDING_AF_INET6 = 24; >>> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >>> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; >> >> This should sort from 0 to 255 and not at the end. Understood, then this requires an inline comment. > Usually I would agree, but in this case there is a perverse relationship > between 255 and 0 (see below), so grouping them together like this _may_ > help the reader to understand that there's something funny going on. > >> private int getAddrType(InetAddress addr) { >>> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >>> + int addressType = CHANNEL_BINDING_AF_UNSPEC; >> >>> // initialize addrtype in CB first >>> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >>> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >>> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >>> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; >> >> This looks wrong to me -- as you already mentioned -- this violates RFC >> 2744, section 3.11, last sentence: >>> or omit addressing information, specifying >>> GSS_C_AF_NULLADDR as the address-types. >> > > Michael: what's going on here, I believe, is that in theory of course one > should do what the RFC says and use GSS_C_AF_NULLADDR (255) but instead all > the main implementations with which one would want to interoperate blithely > use zero (because, IMO, they were written by bloody C programmers) -- and > Alexey is doing the best he can to interoperate with those rather than with > the letter of the spec that noone implements. > > viz previous discussion on the IETF kitten list: > > https://mailarchive.ietf.org/arch/msg/kitten/Jx8ok5BBHu5GIrpdu8i6-4NtsZM/ > > > which refers to: > > https://mailarchive.ietf.org/arch/msg/kitten/ZGkBijVg080plyyQOv53bL08qRU/ > > > >> >>> /* release initiator address */ >>> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >>> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->initiator_address)); >>> } >>> /* release acceptor address */ >>> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >>> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->acceptor_address)); >>> } >> >> Unspecified does not mean that it is null. >> > > [...] > > >> Generally, I have two fundemental issues: >> * How do you know that address type must be UNSPEC and not NULLADDR? >> Trial and error? >> > > Pretty much... > > >> * Changing the default address type against the RFC will break every >> installation using channel bindings relying on it with cross GSS-API >> implementations. >> > > In theory, yes; in practice, the opposite. So I read the discussions. RFC 2744 shall not be changed, people admitted that the spec of SASL GS2 mechs is wrong and should be changed, but this has not happened yet. It remained at UNSPEC all the years. So we have several issues here: * GSS-API C bindings and SASL requests are two distinct RFCs which require/mandate differnt things. * The change in JGSS in unrelated to this patch because GSS-API knows nothing about SASL and its fauly spec. Since we are doing LDAP over SASL here and RFC 5801 requires to be UNSPEC (0) the SASL TlsChannelBinding class must take that into account. Unfortunately, JGSS implies with the args of the ChannelBinding the type fo the adress. So will change my opinion a bit: No property for AD/non-AD is necessary, but handling of UNSPEC is required. JGSS shall remain at NULLADDR. The subtype UnspecEmptyInetAddress should be at least evaluated. Michael From weijun.wang at oracle.com Mon May 25 13:26:49 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 25 May 2020 21:26:49 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> Message-ID: <3F346366-F6F1-4F9D-B035-DF2B0026C23E@oracle.com> I find the duplication of parsing code annoyed. I'll see if I can consolidate them into one. --Max > On May 20, 2020, at 1:37 PM, Valerie Peng wrote: > > > True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. > > Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. > > Thanks, > Valerie > On 5/18/2020 9:36 PM, Weijun Wang wrote: >>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>> >>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>> >>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>> throws IOException { >>> boolean hasAttributes = false; >>> boolean hasPublicKey = false; >>> while (derIn.available () != 0) { >>> // check for OPTIONAL attributes and/or publicKey >>> DerValue tmp = derIn.getDerValue(); >>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>> // OPTIONAL attributes not supported yet >>> // discard for now and move on >>> hasAttributes = true; >>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>> !hasPublicKey) { >>> // OPTIONAL v2 public key not supported yet >>> // discard for now and move on >>> hasPublicKey = true; >>> } else { >>> throw new IOException ("illegal encoding in private key"); >>> } >>> } >>> } >> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >> >>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >> OK. >> >>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >> Yes. >> >>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >> If you still want checkTrailingBytes, then yes. >> >> Thanks, >> Max >> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>> I will take a look. >>>> >>>> Valerie >>>> >>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>> Found an existing test I can update. Webrev updated at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>> >>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>> >>>>>> I also take this chance to make some format change. >>>>>> >>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> From alexey at azul.com Mon May 25 15:33:33 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 25 May 2020 15:33:33 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Message-ID: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Hello Michael, Thomas, Thank you a lot for review and suggestions. I?ve fixed most of the issues except of fundamental one I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. Updated webrev is available at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ Also, please see my comments below. Regards Alexey > On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ > > Let's go through your changes statically: > > * The JIRA issue title has a typo Thank you. Fixed in Jira > * The word "cannot" is incorrectly spelled throughout all exception messages Fixed from ?can not? to ?cannot" > >> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >> + throw new UnsupportedOperationException("LdapCtx: " + >> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); > > > "LdapCtx: " is redundant because the stacktrace will contain the class > name already. A better message would be: "Channel binding type '%s' is > not supported". Not just the plain value. Exception message is corrected > >> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >> + if (connectTimeout == -1) >> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >> + CONNECT_TIMEOUT + " property is set."); > > * Same here with the message Not sure, What?s wrong with the message ? > * The IAE is wrong because passed value is correct, but leads to an > invalid state because connection timeout is -1. You need an > IllegalStateException here. Thank you. You are right again. Changed to IllegalStateException > > Stupid question: how can one create a GSS security context when the TLS > security context has not been established yet? This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. The only changes here is to prevent double setting of channel binding data. > >> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >> @@ -531,9 +531,12 @@ >> public void setChannelBinding(ChannelBinding channelBindings) >> throws GSSException { >> >> - if (mechCtxt == null) >> + if (mechCtxt == null) { >> + if (this.channelBindings != null) { >> + throw new GSSException(GSSException.BAD_BINDINGS); >> + } >> this.channelBindings = channelBindings; >> - >> + } >> } > > I don't understand the purpose of this hunk. Is this safeguard to set > bindings only once? > >> private static final int CHANNEL_BINDING_AF_INET = 2; >> private static final int CHANNEL_BINDING_AF_INET6 = 24; >> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; > > This should sort from 0 to 255 and not at the end. OK. Moved to the top. > >> private int getAddrType(InetAddress addr) { >> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >> + int addressType = CHANNEL_BINDING_AF_UNSPEC; > >> // initialize addrtype in CB first >> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; > > This looks wrong to me -- as you already mentioned -- this violates RFC > 2744, section 3.11, last sentence: >> or omit addressing information, specifying >> GSS_C_AF_NULLADDR as the address-types. > >> /* release initiator address */ >> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >> resetGSSBuffer(&(cb->initiator_address)); >> } >> /* release acceptor address */ >> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >> resetGSSBuffer(&(cb->acceptor_address)); >> } > > Unspecified does not mean that it is null. > >> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >> + byte[] cbData = Arrays.copyOf(prefix, >> + prefix.length + tlsCB.getData().length ); >> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); > > Since you are calling "tlsCB.getData()" multiple times, this should go > into a variable. Temporary variable is added > > >> + secCtx.setChannelBinding(new > ChannelBinding(null, null, cbData)); > > Why not use new ChannelBinding(cbData)? Right. updated > >> + String hashAlg = serverCertificate.getSigAlgName(). >> + replace("SHA", "SHA-").toUpperCase(); >> + int ind = hashAlg.indexOf("WITH"); >> + if (ind > 0) { >> + hashAlg = hashAlg.substring(0, ind); >> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >> + hashAlg = "SHA-256"; >> + } > > I have several problems with that, some might be hypothetical: > > * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. Looking at implementation I do not think it is realistic to get name in the non-English locale. I do not think it should be fixed > * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then > at sun.security.x509.AlgorithmId.getName() it uses nameTable to > translate OIDs to readible names. > > With indexOf("WITH") you are implying that the cert's sig alg may not > use a cryptographic function, but this would mean that if the OID is > 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, > wouldn't you? > I also don't know how realistic "PBEWith..." is. > > This likely needs more thought or I am missing something. > I do not think it is realistic scenario to have certificate signature algorithm without crypto function. indexOf(?WITH?) just used to find end out hash algorithm name. > * Exception messages are inconsistent. Sometimes "TLS channel binding", > sometimes just "channel binding". To avoid misunderstandings it should > always read "TLS channel binding..". > Messages are updated. > Generally, I have two fundemental issues: > * How do you know that address type must be UNSPEC and not NULLADDR? > Trial and error? I did not find any strict specification about TLS Channel Binding format in Windows server. So, it was a lot of experiments, reading related forums and docs. One of the doc, that turns me to try UNSPEC type is the following: https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication > * Changing the default address type against the RFC will break every > installation using channel bindings relying on it with cross GSS-API > implementations. I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. > > There must be another way to solve this. A system property would also be > problematic because if you have a product which connects to MS and > non-MS backends at the same time, channel bindings would be broken again. > > What about introducing a UnspecEmptyInetAddress() which gives the proper > AF type, but #getAddress() would return null? This should satisfy the > requirements, InitialToken as well as the RFC. this of course needs to > be properly passed to native providers too. GssKrb5Client would also > need to know that this channel binding is explicitly for Active > Directory and not some other, spec-compliant, SASL peer (property on > LdapCtx?) > > One could easily use this for custom code with a SSLServerSocket paired > with Java SASL or in C, OpenSSL and Cyrus SASL. > > Michael > > PS: Yes, I am a nitpicker. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From thomas.mpp.maslen at gmail.com Tue May 26 03:04:27 2020 From: thomas.mpp.maslen at gmail.com (Thomas Maslen) Date: Mon, 25 May 2020 20:04:27 -0700 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: On Mon, May 25, 2020 at 3:15 AM Michael Osipov <1983-01-06 at gmx.net> wrote: [...] > So I read the discussions. RFC 2744 shall not be changed, people > admitted that the spec of SASL GS2 mechs is wrong and should be changed, > but this has not happened yet. It remained at UNSPEC all the years. > > So we have several issues here: > * GSS-API C bindings and SASL requests are two distinct RFCs which > require/mandate differnt things. > * The change in JGSS in unrelated to this patch because GSS-API knows > nothing about SASL and its fauly spec. > > Since we are doing LDAP over SASL here and RFC 5801 requires to be > UNSPEC (0) the SASL TlsChannelBinding class must take that into account. > Unfortunately, JGSS implies with the args of the ChannelBinding the type > fo the adress. So will change my opinion a bit: > > No property for AD/non-AD is necessary, but handling of UNSPEC is > required. JGSS shall remain at NULLADDR. The subtype > UnspecEmptyInetAddress should be at least evaluated. > > Michael > No. This isn't just about RFC 5801. As Alexey Bakhtin observed, this also applies to channel bindings for HTTP Negotiate Authentication (loosely aka "SPNEGO"), not only for NTLM (which probably isn't at issue here) but also for Kerberos -- that's where I first encountered this, working on a proprietary Java Kerberos implementation. More generally, if you want channel bindings to interoperate in the GSSAPI Kerberos Mechanism for any protocol -- SASL GS2, HTTP Negotiate Authentication, or anything else -- ignore the fact that RFC 2744 specifies 255 for the "no address" case and do what everyone actually does: use zero. Here is a test from MIT Kerberos that (implicitly) uses zero: https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_bindings.c And here is one from Heimdal: https://github.com/heimdal/heimdal/blob/5057d04f6a47f05f1ed7c617458722104d4c17dc/lib/gssapi/test_context.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Tue May 26 04:02:25 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2020 12:02:25 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> Message-ID: <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> The new definition at https://tools.ietf.org/html/rfc5958 shows, OneAsymmetricKey ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] Attributes OPTIONAL, ..., [[2: publicKey [1] PublicKey OPTIONAL ]], ... } According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: The string "..." in ASN.1 is called an extension marker. The extension marker, ellipsis, is an indication that extension additions are expected. It makes no statement as to how such additions should be handled. However they shall not be treated as an error during the decoding process. So there might be more fields in the future. Do you still insist we need more validation? Thanks, Max > On May 20, 2020, at 1:37 PM, Valerie Peng wrote: > > > True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. > > Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. > > Thanks, > Valerie > On 5/18/2020 9:36 PM, Weijun Wang wrote: >>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>> >>> Hi Max, >>> >>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>> >>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>> >>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>> throws IOException { >>> boolean hasAttributes = false; >>> boolean hasPublicKey = false; >>> while (derIn.available () != 0) { >>> // check for OPTIONAL attributes and/or publicKey >>> DerValue tmp = derIn.getDerValue(); >>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>> // OPTIONAL attributes not supported yet >>> // discard for now and move on >>> hasAttributes = true; >>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>> !hasPublicKey) { >>> // OPTIONAL v2 public key not supported yet >>> // discard for now and move on >>> hasPublicKey = true; >>> } else { >>> throw new IOException ("illegal encoding in private key"); >>> } >>> } >>> } >> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >> >>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >> OK. >> >>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >> Yes. >> >>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >> If you still want checkTrailingBytes, then yes. >> >> Thanks, >> Max >> >>> Thanks, >>> >>> Valerie >>> >>> >>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>> I will take a look. >>>> >>>> Valerie >>>> >>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>> Found an existing test I can update. Webrev updated at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>> >>>>>> Please take a review at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>> >>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>> >>>>>> I also take this chance to make some format change. >>>>>> >>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> From alexey at azul.com Tue May 26 13:23:24 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 13:23:24 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <2F27D9CD-A15C-4946-976D-C522C39FB126@azul.com> Hi Michael, Thomas, Unfortunately we can not fix address type issue with the UnspecEmptyInetAddress subclass. We can not create subclass of InetAddress without changing public API. We can try similar approach but create subclass of ChannelBinding class instead. It is not so elegant like UnspecEmptyInetAddress approach but it could help to distinguish between TLS channel binding and Channel Bindings set by application. Later we can remove this workaround In case we prove that UNSPEC type should be used in all types of Channel Bindings. Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ Regards Alexey > On 26 May 2020, at 06:04, Thomas Maslen wrote: > > On Mon, May 25, 2020 at 3:15 AM Michael Osipov <1983-01-06 at gmx.net> wrote: > [...] > So I read the discussions. RFC 2744 shall not be changed, people > admitted that the spec of SASL GS2 mechs is wrong and should be changed, > but this has not happened yet. It remained at UNSPEC all the years. > > So we have several issues here: > * GSS-API C bindings and SASL requests are two distinct RFCs which > require/mandate differnt things. > * The change in JGSS in unrelated to this patch because GSS-API knows > nothing about SASL and its fauly spec. > > Since we are doing LDAP over SASL here and RFC 5801 requires to be > UNSPEC (0) the SASL TlsChannelBinding class must take that into account. > Unfortunately, JGSS implies with the args of the ChannelBinding the type > fo the adress. So will change my opinion a bit: > > No property for AD/non-AD is necessary, but handling of UNSPEC is > required. JGSS shall remain at NULLADDR. The subtype > UnspecEmptyInetAddress should be at least evaluated. > > Michael > > No. This isn't just about RFC 5801. As Alexey Bakhtin observed, this also applies to channel bindings for HTTP Negotiate Authentication (loosely aka "SPNEGO"), not only for NTLM (which probably isn't at issue here) but also for Kerberos -- that's where I first encountered this, working on a proprietary Java Kerberos implementation. > > More generally, if you want channel bindings to interoperate in the GSSAPI Kerberos Mechanism for any protocol -- SASL GS2, HTTP Negotiate Authentication, or anything else -- ignore the fact that RFC 2744 specifies 255 for the "no address" case and do what everyone actually does: use zero. > > Here is a test from MIT Kerberos that (implicitly) uses zero: https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_bindings.c > > And here is one from Heimdal: https://github.com/heimdal/heimdal/blob/5057d04f6a47f05f1ed7c617458722104d4c17dc/lib/gssapi/test_context.c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From daniel.fuchs at oracle.com Tue May 26 14:14:49 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 May 2020 15:14:49 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: Hi Alexey, This is not a review. A few high level comments however: For that kind of change that introduce a new environment property you will need to file a CSR, and probably provide some release notes as well. Your changes seem to trigger new IllegalStateException and UnsupportedOperationExceptions which are undocumented. I believe they should be replaced by NamingException which is documented at the public API level. Also it would be good to have a test that validates that the proposed changes works as expected. I will not comment on the security libs changes - I'm clearly out of my depth there. It's a bit distasteful that the LdapCtxt/LdapClient have to have knowledge of channel binding and extract the certificates from the SSLSocket to pass them to the lower layer. Ideally this should rather be handled by the SASL layers? best regards, -- daniel On 25/05/2020 16:33, Alexey Bakhtin wrote: > Updated webrev is available at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ From weijun.wang at oracle.com Tue May 26 14:50:22 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2020 22:50:22 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> I have a question on GssKrb5Client.java: Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. Thanks, Max > On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: > > Hello, > > Could you please review the following patch: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 > Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ > > The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding > (based on the TLS server certificate). The channel binding data is calculated as following : > ? The client calculates a hash of the TLS server certificate. > The hash algorithm is selected on the base of the certificate signature algorithm. > Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based > ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: > ? initiator and acceptor addresses should be set to NULL > ? initiator and acceptor address types should be zero. > It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that > the address type should be set to GSS_C_AF_NULLADDR=0xFF, > instead of GSS_C_AF_UNSPEC=0x00. > > This patch introduces changes in the LDAP, SASL and JGSS modules > to generate channel binding data automatically if requested by an application. > This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes > initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. > The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates > Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. > Right now "tls-server-end-point" Channel Binding type is supported only. > The client extracts server certificate from the underlying TLS connection and creates > Channel Binding data for JGSS/Kerberos authentication if application indicates > com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. > Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property > to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. > > [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 > > [2] - > https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html > > Initial discussion of this issue is available at security-dev list: > https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From aleksej.efimov at oracle.com Tue May 26 14:55:05 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 26 May 2020 15:55:05 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> Hi Alexey, I agree with all Daniel's comments. Few thoughts about moving the implementation down to SASL layers: Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? Maybe investigate moving all the new code to GssKrb5Client SASL client implementation (GssKrb5Client class, "GSSAPI" authentication mechanism name): - That may require to store the server certificate extracted from SSLSocket into new context environment property - The code that processes and checks the String value of channel binding type value could also be moved to GssKrb5Client or to TlsChannelBinding - Add TlsChannelBinding factory method that creates an object from the server certificate and the string value of the environment property could also be useful here All of that will allow us to keep the fix specific to "JGSS/Kerberos" area and will keep LdapCtx/LdapClient code changes minimal and clear of "JGSS/Kerberos" details Best Regards, Aleksei On 26/05/2020 15:14, Daniel Fuchs wrote: > Hi Alexey, > > This is not a review. A few high level comments however: > > For that kind of change that introduce a new environment > property you will need to file a CSR, and probably provide > some release notes as well. > > Your changes seem to trigger new IllegalStateException and > UnsupportedOperationExceptions which are undocumented. > I believe they should be replaced by NamingException which > is documented at the public API level. > > Also it would be good to have a test that validates that > the proposed changes works as expected. > > I will not comment on the security libs changes - I'm clearly > out of my depth there. It's a bit distasteful that the > LdapCtxt/LdapClient have to have knowledge of channel binding > and extract the certificates from the SSLSocket to pass them to > the lower layer. Ideally this should rather be handled by the > SASL layers? > > best regards, > > -- daniel > > > On 25/05/2020 16:33, Alexey Bakhtin wrote: >> Updated webrev is available >> at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ > From alexey at azul.com Tue May 26 16:27:58 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 16:27:58 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> Message-ID: Hello Aleks, Daniel, Thank you for your comments. I don?t like that the code is split into several modules too. The reason of doing it is I can not get TLS server certificate from the JGSS/Kerberos code. The only place Where I can fetch it is LdapClient. If I understand your idea correctly, I can extract TLS server certificate in the LdapClient and put it into internal environment property as byte array without mention about Channel Binding. It will be done for every LDAPS connection. In case of ?com.sun.security.sasl.channelbinding=tls-server-end-point? property specified, GssKrb5Client extracts certificate from the internal environment property and use it to create TLS Channel Binding. In this case almost all Channel Binding code could be moved to GssKrb5Client. LdapClient still changed but not mention about Channel Binding. Changes in the LdapCtx could be omitted. Regards Alexey > On 26 May 2020, at 17:55, Aleks Efimov wrote: > > Hi Alexey, > > I agree with all Daniel's comments. > > Few thoughts about moving the implementation down to SASL layers: > Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? > Maybe investigate moving all the new code to GssKrb5Client SASL client implementation (GssKrb5Client class, "GSSAPI" authentication mechanism name): > - That may require to store the server certificate extracted from SSLSocket into new context environment property > - The code that processes and checks the String value of channel binding type value could also be moved to GssKrb5Client or to TlsChannelBinding > - Add TlsChannelBinding factory method that creates an object from the server certificate and the string value of the environment property could also be useful here > > All of that will allow us to keep the fix specific to "JGSS/Kerberos" area and will keep LdapCtx/LdapClient code changes minimal and clear of "JGSS/Kerberos" details > > Best Regards, > Aleksei > > On 26/05/2020 15:14, Daniel Fuchs wrote: >> Hi Alexey, >> >> This is not a review. A few high level comments however: >> >> For that kind of change that introduce a new environment >> property you will need to file a CSR, and probably provide >> some release notes as well. >> >> Your changes seem to trigger new IllegalStateException and >> UnsupportedOperationExceptions which are undocumented. >> I believe they should be replaced by NamingException which >> is documented at the public API level. >> >> Also it would be good to have a test that validates that >> the proposed changes works as expected. >> >> I will not comment on the security libs changes - I'm clearly >> out of my depth there. It's a bit distasteful that the >> LdapCtxt/LdapClient have to have knowledge of channel binding >> and extract the certificates from the SSLSocket to pass them to >> the lower layer. Ideally this should rather be handled by the >> SASL layers? >> >> best regards, >> >> -- daniel >> >> >> On 25/05/2020 16:33, Alexey Bakhtin wrote: >>> Updated webrev is available at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From alexey at azul.com Tue May 26 17:46:11 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 17:46:11 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> Message-ID: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is calculated as following : >> ? The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >> ? initiator and acceptor addresses should be set to NULL >> ? initiator and acceptor address types should be zero. >> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection and creates >> Channel Binding data for JGSS/Kerberos authentication if application indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ecki at zusammenkunft.net Tue May 26 17:53:12 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 May 2020 17:53:12 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>, <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Message-ID: Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That would help jgss for the other mechanisms for channel bindings (cbt) as well. Not sure how jgss and JSSE will talk to each other.. via SASL? -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alexey Bakhtin Gesendet: Tuesday, May 26, 2020 7:46:11 PM An: Weijun Wang Cc: security-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net ; Michael Osipov Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is calculated as following : >> ? The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >> ? initiator and acceptor addresses should be set to NULL >> ? initiator and acceptor address types should be zero. >> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection and creates >> Channel Binding data for JGSS/Kerberos authentication if application indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue May 26 18:08:49 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2020 11:08:49 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: Ping ... On 5/13/2020 1:44 PM, Xuelei Fan wrote: > On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed: >>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>> >>> For TLS 1.3 full handshake, if the last handshake flight wraps the >>> Finished together with other handshake message, for example client >>> certificate, the flight could be wrapped and encrypted in one record >>> and delegated tasks would be used.? There is no chance to return >>> FINISHED handshake status with SSLEngine.(un)wrap(). However, per the >>> HandshakeStatus.FINISHED specification, this handshake status is only >>> generated by a call to SSLEngine.wrap()/unwrap() and it is never >>> generated by SSLEngine.getHandshakeStatus(). >>> >>> In order to workaround this case for TLS 1.3, the FINISHED status >>> could present with SSLEngine.wrap() while delivering of the >>> NewSessionTicket post-handshake message.? If this post-handshake >>> message is not needed, a follow-on SSLEngine.wrap() should be called >>> to indicate the FINISHED handshake status.? Although this special >>> SSLEngine.wrap() should not consume or produce any application or >>> network data. >>> >>> I also clean up some debug log, names and code style a little bit. >>> >>> The update could be confirmed with Tomcat and Firefox in private >>> mode, as described in the bug description.? As this case happens only >>> when psk_key_exchange_modes does not present, which is not a behavior >>> supported by JDK, I did not find a workaround for a new regression >>> test yet.? I added the labels, noreg-external and noreg-hard. >>> >>> Thanks, >>> Xuelei >> >> I do not fully understand the situation, mostly because of SSLEngine >> semantics.? In normal operation, does is HandshakeStatus.FINISHED >> returned when Finished is received or after the NewSessionTicket message? > Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() of > the finished handshake message.? However, for TLS 1.3, FINISHED will be > returned any longer, because the finished handshake message is wrapped > with certificate message in one record. > > For TLS 1.3: > 1. client send certificate, certificate verify and finished handshake > message in one record. > 2. server call unwrap(), and return NEED_TASK to handle the certificate > and certificate verify. > > So, no more FINISHED for the unwrap() return. > > It is fine if there is a after NewSessionTicket message.? The wrap() for > the post-handshake message will return FINISHED. > > The bug reported is a special one that the Firefox is run in private > mode, which does not request NewSessionTicket.? So there is no > post-handshake generated and sent in server side.? Then, there is no > FINISHED can be used if applications depends on it. > > To workaround the case, a dummy wrap() or unwrap() could be used to get > the FINISHED.? The wrap() or unwrap() actually do nothing but return the > FINISHED status. > >> My understanding would have been after Finished because NST is suppose >> to be a post handshake message.? So in this case there is no problem, >> correct? >> > Correct. > >> I'm trying to figure out why you need an empty NST.? Is the problem >> when a number of messages are bundled together.? For example, the >> Finished message with a partial NST, then Finished isn't processed and >> both sides are waiting?? Or do both sides continue normal traffic, >> it's jut the HandshakeStatus.FINISHED is one operation behind? >> > It should be fine as empty NST is just a signal to indicate the next > call to wrap().? The next call to wrap() just use the signal for the > return of FINISHED status, not network data produced, delivered or > consumed. > >> >> One code comment so far: >> 433:? The debug message purpose was to say the NST is a stateless >> ticket and not a preshared key.? Can we keep "stateless" in the message? >> > NewSessionTicket.java?? Sure, I may just want to shrink to one line.? It > was not intended. > > Xuelei From valerie.peng at oracle.com Tue May 26 19:07:28 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 26 May 2020 12:07:28 -0700 Subject: RFR[15] JDK-8245134: test/lib/jdk/test/lib/security/KeyStoreUtils.java should allow to specify aliases In-Reply-To: <7579bb12-d03a-81ea-08fc-75e4a9a599ad@oracle.com> References: <92a827d8-1cb3-01a2-763b-65f3ae06baaa@oracle.com> <295193c9-d389-a04c-f143-44a80d47431e@oracle.com> <023b046e-83d1-32ec-f8bd-b1a886be0ef4@oracle.com> <875e8f7f-b94a-19a6-a90a-a6bde65c2295@oracle.com> <7579bb12-d03a-81ea-08fc-75e4a9a599ad@oracle.com> Message-ID: Looks good. Cleaner and shorter this way~ Thanks, Valerie On 5/21/2020 8:18 PM, sha.jiang at oracle.com wrote: > > Hi Valerie, > Thanks for your clarification! > > Could you please review this updated webrev: > http://cr.openjdk.java.net/~jjiang/8245134/webrev.01/ > > Best regards, > John Jiang > > On 2020/5/22 06:08, Valerie Peng wrote: >> >> >> On 5/20/2020 7:38 PM, sha.jiang at oracle.com wrote: >>> >>>> - line 176, maybe it's better to just supply the type, clearer and >>>> less dependency. >>>> >>> Not get this point. >>> Could you please describe some more? >> >> I mean to change line 176 as below (see the added text in blue): >> >> 176 return createTrustStore(DEFAULT_TYPE, certStrs, null); >> >> >>>> With this extra aliases argument, number of createTrustStore(...) >>>> methods doubled from 2 to 4, number of createKeyStore(...) methods >>>> also doubled from 4 to 8. Isn't it a bit much to have 8 methods >>>> doing the same thing? Especially in the case of >>>> createKeyStore(...), quite a few of them have long list of >>>> arguments with the same type, combining this with the large number >>>> of methods, it can get confusing on which method is called. How >>>> often do you think the aliases are supplied? Maybe we only add >>>> methods which will be used instead of adding all possible combinations. >>>> >>> I'll remove 4 createKeyStore(...) methods (like the below one) that >>> have long list of arguments. >>> createKeyStore(String type, String[] keyAlgos, >>> ??????????? String[] keyStrs, String[] passwords, String[] certStrs, >>> ??????????? String[] aliases) >>> It looks no test is using them. My tests also won't use them. >> >> Sounds good. >> >> Thanks, >> Valerie >>> >>> Best regards, >>> John Jiang >>>> >>>> Thanks, >>>> Valerie >>>> On 5/15/2020 11:40 PM, sha.jiang at oracle.com wrote: >>>>> Hi, >>>>> This patch adds some new createTrustStore() and createKeyStore() >>>>> methods to test >>>>> lib class jdk.test.lib.security.KeyStoreUtils. >>>>> These new methods allow to pass trust/key store aliases in. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8245134 >>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8245134/webrev.00/ >>>>> >>>>> Best regards, >>>>> John Jiang >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony.scarpino at oracle.com Tue May 26 20:26:45 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 26 May 2020 13:26:45 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: On 5/13/20 1:44 PM, Xuelei Fan wrote: > On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>> Hi, >>> >>> Could I get the following update reviewed: >>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>> >>> For TLS 1.3 full handshake, if the last handshake flight wraps the >>> Finished together with other handshake message, for example client >>> certificate, the flight could be wrapped and encrypted in one record >>> and delegated tasks would be used.? There is no chance to return >>> FINISHED handshake status with SSLEngine.(un)wrap(). However, per the >>> HandshakeStatus.FINISHED specification, this handshake status is only >>> generated by a call to SSLEngine.wrap()/unwrap() and it is never >>> generated by SSLEngine.getHandshakeStatus(). >>> >>> In order to workaround this case for TLS 1.3, the FINISHED status >>> could present with SSLEngine.wrap() while delivering of the >>> NewSessionTicket post-handshake message.? If this post-handshake >>> message is not needed, a follow-on SSLEngine.wrap() should be called >>> to indicate the FINISHED handshake status.? Although this special >>> SSLEngine.wrap() should not consume or produce any application or >>> network data. >>> >>> I also clean up some debug log, names and code style a little bit. >>> >>> The update could be confirmed with Tomcat and Firefox in private >>> mode, as described in the bug description.? As this case happens only >>> when psk_key_exchange_modes does not present, which is not a behavior >>> supported by JDK, I did not find a workaround for a new regression >>> test yet.? I added the labels, noreg-external and noreg-hard. >>> >>> Thanks, >>> Xuelei >> >> I do not fully understand the situation, mostly because of SSLEngine >> semantics.? In normal operation, does is HandshakeStatus.FINISHED >> returned when Finished is received or after the NewSessionTicket message? > Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() of > the finished handshake message.? However, for TLS 1.3, FINISHED will be > returned any longer, because the finished handshake message is wrapped > with certificate message in one record. > > For TLS 1.3: > 1. client send certificate, certificate verify and finished handshake > message in one record. > 2. server call unwrap(), and return NEED_TASK to handle the certificate > and certificate verify. > > So, no more FINISHED for the unwrap() return. > > It is fine if there is a after NewSessionTicket message.? The wrap() for > the post-handshake message will return FINISHED. > > The bug reported is a special one that the Firefox is run in private > mode, which does not request NewSessionTicket.? So there is no > post-handshake generated and sent in server side.? Then, there is no > FINISHED can be used if applications depends on it. > > To workaround the case, a dummy wrap() or unwrap() could be used to get > the FINISHED.? The wrap() or unwrap() actually do nothing but return the > FINISHED status. > I don't want to be problematic, but I don't really agree with creating dummy messages to generate wrap/unwrap operations in the TLS code. If SSLEngine is doing something wrong with not fully reading the buffer, then I feel it's SSLEngine that should be fixed to handle the situation right. Maybe not put the finished message or put all these messages together. Maybe Brad may know of a way out of this problem? If creating a dummy message is the only way to fix this, then I'm ok with it. It is just not a clean fix in my mind. >> My understanding would have been after Finished because NST is suppose >> to be a post handshake message.? So in this case there is no problem, >> correct? >> > Correct. > >> I'm trying to figure out why you need an empty NST.? Is the problem >> when a number of messages are bundled together.? For example, the >> Finished message with a partial NST, then Finished isn't processed and >> both sides are waiting?? Or do both sides continue normal traffic, >> it's jut the HandshakeStatus.FINISHED is one operation behind? >> > It should be fine as empty NST is just a signal to indicate the next > call to wrap().? The next call to wrap() just use the signal for the > return of FINISHED status, not network data produced, delivered or > consumed. > >> >> One code comment so far: >> 433:? The debug message purpose was to say the NST is a stateless >> ticket and not a preshared key.? Can we keep "stateless" in the message? >> > NewSessionTicket.java?? Sure, I may just want to shrink to one line.? It > was not intended. shrinking the message is fine, it just needs to be clear which message ticket type got sent. thanks Tony > > Xuelei From valerie.peng at oracle.com Tue May 26 20:37:07 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 26 May 2020 13:37:07 -0700 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: I am also concerned about the changes in GSSLibStub.c about the default value being GSS_C_AF_UNSPECinstead of GSS_C_AF_NULLADDR (line 194-195). Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd prefer to not changing the default value for addresstype for the same reason which Michael has already stated. Thanks, Valerie On 5/25/2020 8:33 AM, Alexey Bakhtin wrote: > Hello Michael, Thomas, > > Thank you a lot for review and suggestions. > I?ve fixed most of the issues except of fundamental one > I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. > > Updated webrev is available at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ > > Also, please see my comments below. > > Regards > Alexey > >> On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> Let's go through your changes statically: >> >> * The JIRA issue title has a typo > Thank you. Fixed in Jira >> * The word "cannot" is incorrectly spelled throughout all exception messages > Fixed from ?can not? to ?cannot" >>> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >>> + throw new UnsupportedOperationException("LdapCtx: " + >>> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); >> >> "LdapCtx: " is redundant because the stacktrace will contain the class >> name already. A better message would be: "Channel binding type '%s' is >> not supported". Not just the plain value. > Exception message is corrected >>> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >>> + if (connectTimeout == -1) >>> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >>> + CONNECT_TIMEOUT + " property is set."); >> * Same here with the message > Not sure, What?s wrong with the message ? >> * The IAE is wrong because passed value is correct, but leads to an >> invalid state because connection timeout is -1. You need an >> IllegalStateException here. > Thank you. You are right again. Changed to IllegalStateException >> Stupid question: how can one create a GSS security context when the TLS >> security context has not been established yet? > This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. > The only changes here is to prevent double setting of channel binding data. > >>> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>> @@ -531,9 +531,12 @@ >>> public void setChannelBinding(ChannelBinding channelBindings) >>> throws GSSException { >>> >>> - if (mechCtxt == null) >>> + if (mechCtxt == null) { >>> + if (this.channelBindings != null) { >>> + throw new GSSException(GSSException.BAD_BINDINGS); >>> + } >>> this.channelBindings = channelBindings; >>> - >>> + } >>> } >> I don't understand the purpose of this hunk. Is this safeguard to set >> bindings only once? >> >>> private static final int CHANNEL_BINDING_AF_INET = 2; >>> private static final int CHANNEL_BINDING_AF_INET6 = 24; >>> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >>> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; >> This should sort from 0 to 255 and not at the end. > OK. Moved to the top. > >>> private int getAddrType(InetAddress addr) { >>> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >>> + int addressType = CHANNEL_BINDING_AF_UNSPEC; >>> // initialize addrtype in CB first >>> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >>> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >>> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >>> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; >> This looks wrong to me -- as you already mentioned -- this violates RFC >> 2744, section 3.11, last sentence: >>> or omit addressing information, specifying >>> GSS_C_AF_NULLADDR as the address-types. >>> /* release initiator address */ >>> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >>> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->initiator_address)); >>> } >>> /* release acceptor address */ >>> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >>> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->acceptor_address)); >>> } >> Unspecified does not mean that it is null. >> >>> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >>> + byte[] cbData = Arrays.copyOf(prefix, >>> + prefix.length + tlsCB.getData().length ); >>> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); >> Since you are calling "tlsCB.getData()" multiple times, this should go >> into a variable. > Temporary variable is added > >> >>> + secCtx.setChannelBinding(new >> ChannelBinding(null, null, cbData)); >> >> Why not use new ChannelBinding(cbData)? > Right. updated > >>> + String hashAlg = serverCertificate.getSigAlgName(). >>> + replace("SHA", "SHA-").toUpperCase(); >>> + int ind = hashAlg.indexOf("WITH"); >>> + if (ind > 0) { >>> + hashAlg = hashAlg.substring(0, ind); >>> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >>> + hashAlg = "SHA-256"; >>> + } >> I have several problems with that, some might be hypothetical: >> >> * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH > As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. > Looking at implementation I do not think it is realistic to get name in the non-English locale. > I do not think it should be fixed > >> * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then >> at sun.security.x509.AlgorithmId.getName() it uses nameTable to >> translate OIDs to readible names. >> >> With indexOf("WITH") you are implying that the cert's sig alg may not >> use a cryptographic function, but this would mean that if the OID is >> 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, >> wouldn't you? >> I also don't know how realistic "PBEWith..." is. >> >> This likely needs more thought or I am missing something. >> > I do not think it is realistic scenario to have certificate signature algorithm without crypto function. > indexOf(?WITH?) just used to find end out hash algorithm name. > >> * Exception messages are inconsistent. Sometimes "TLS channel binding", >> sometimes just "channel binding". To avoid misunderstandings it should >> always read "TLS channel binding..". >> > Messages are updated. > >> Generally, I have two fundemental issues: >> * How do you know that address type must be UNSPEC and not NULLADDR? >> Trial and error? > I did not find any strict specification about TLS Channel Binding format in Windows server. > So, it was a lot of experiments, reading related forums and docs. > One of the doc, that turns me to try UNSPEC type is the following: > https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication > >> * Changing the default address type against the RFC will break every >> installation using channel bindings relying on it with cross GSS-API >> implementations. > I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. > The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. > >> There must be another way to solve this. A system property would also be >> problematic because if you have a product which connects to MS and >> non-MS backends at the same time, channel bindings would be broken again. >> >> What about introducing a UnspecEmptyInetAddress() which gives the proper >> AF type, but #getAddress() would return null? This should satisfy the >> requirements, InitialToken as well as the RFC. this of course needs to >> be properly passed to native providers too. GssKrb5Client would also >> need to know that this channel binding is explicitly for Active >> Directory and not some other, spec-compliant, SASL peer (property on >> LdapCtx?) >> >> One could easily use this for custom code with a SSLServerSocket paired >> with Java SASL or in C, OpenSSL and Cyrus SASL. >> >> Michael >> >> PS: Yes, I am a nitpicker. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.lamoureux at rsa.com Mon May 18 12:03:39 2020 From: francois.lamoureux at rsa.com (Lamoureux, Francois) Date: Mon, 18 May 2020 12:03:39 +0000 Subject: Default algorithm for new SecureRandom() Message-ID: Dell Customer Communication - Confidential Hi, While we appreciate that a performance issue was fixed in JDK-7092821, the issue JDK-8228613 which results in new SecureRandom() being non-deterministic, hence resulting in any possible supported algorithm supported by the JCE provider is affecting our implementation, hence affecting many customers. I would like to discuss the approach of implementing a SecureRandom.DEFAULT, as initially posted at JDK-8229521. Regards, Fran?ois -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Tue May 26 21:40:42 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 26 May 2020 14:40:42 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: On 5/26/2020 1:26 PM, Anthony Scarpino wrote: > On 5/13/20 1:44 PM, Xuelei Fan wrote: >> On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >>> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Could I get the following update reviewed: >>>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>>> >>>> For TLS 1.3 full handshake, if the last handshake flight wraps the >>>> Finished together with other handshake message, for example client >>>> certificate, the flight could be wrapped and encrypted in one record >>>> and delegated tasks would be used.? There is no chance to return >>>> FINISHED handshake status with SSLEngine.(un)wrap(). However, per >>>> the HandshakeStatus.FINISHED specification, this handshake status is >>>> only generated by a call to SSLEngine.wrap()/unwrap() and it is >>>> never generated by SSLEngine.getHandshakeStatus(). >>>> >>>> In order to workaround this case for TLS 1.3, the FINISHED status >>>> could present with SSLEngine.wrap() while delivering of the >>>> NewSessionTicket post-handshake message.? If this post-handshake >>>> message is not needed, a follow-on SSLEngine.wrap() should be called >>>> to indicate the FINISHED handshake status.? Although this special >>>> SSLEngine.wrap() should not consume or produce any application or >>>> network data. >>>> >>>> I also clean up some debug log, names and code style a little bit. >>>> >>>> The update could be confirmed with Tomcat and Firefox in private >>>> mode, as described in the bug description.? As this case happens >>>> only when psk_key_exchange_modes does not present, which is not a >>>> behavior supported by JDK, I did not find a workaround for a new >>>> regression test yet.? I added the labels, noreg-external and >>>> noreg-hard. >>>> >>>> Thanks, >>>> Xuelei >>> >>> I do not fully understand the situation, mostly because of SSLEngine >>> semantics.? In normal operation, does is HandshakeStatus.FINISHED >>> returned when Finished is received or after the NewSessionTicket >>> message? >> Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() of >> the finished handshake message.? However, for TLS 1.3, FINISHED will >> be returned any longer, because the finished handshake message is >> wrapped with certificate message in one record. >> >> For TLS 1.3: >> 1. client send certificate, certificate verify and finished handshake >> message in one record. >> 2. server call unwrap(), and return NEED_TASK to handle the >> certificate and certificate verify. >> >> So, no more FINISHED for the unwrap() return. >> >> It is fine if there is a after NewSessionTicket message.? The wrap() >> for the post-handshake message will return FINISHED. >> >> The bug reported is a special one that the Firefox is run in private >> mode, which does not request NewSessionTicket.? So there is no >> post-handshake generated and sent in server side.? Then, there is no >> FINISHED can be used if applications depends on it. >> >> To workaround the case, a dummy wrap() or unwrap() could be used to >> get the FINISHED.? The wrap() or unwrap() actually do nothing but >> return the FINISHED status. >> > > I don't want to be problematic, but I don't really agree with creating > dummy messages to generate wrap/unwrap operations in the TLS code. No dummy message created. Only need to call wrap() or unwrap(), but not data consumed or generated by the call to wrap() or unwrap(), no application data consumed, no network data consumed, no application data generated, no network data generated. > If > SSLEngine is doing something wrong with not fully reading the buffer, > then I feel it's SSLEngine that should be fixed to handle the situation > right. It is not caused by SSLEngine that does not fully reading the buffer. Let me try again about what's the problem. The client (Firefox) sends, Certificate and CerticateVerify and Finished handshake messages in one record. The record is encrypted. 1. One call to SSLEngine.unrwap() will read the record, and decrypt the record. 2. One call to SSLEngine.unwrap() cannot read the Certificate and CerticateVerify handshake message only, without reading the Finished handshake message. It means the unwrap() method will consume the record data fully for all three handshake messages. 3. The Certificate and CerticateVerify should be handled in delegated tasks, so the call to SSLEngine.unwrap() return NEED_TASK. 4. As the SSLEngine.unwrap() return NEED_TASK, it cannot return the FINISHED status at the same time. 5. The FINISHED status is only be able to return with SSLEngine.unwrap() or SSLEngine.wrap(), and cannot returned from delegated tasks. So the SSLEngine.getHandshakeStatus() after the tasks cannot be used to indicate the FINISHED status. 6. Then FINISHED status is missed, applications like Tomcat run into problem, like the bug described. That's the problem of the bug as far as I can see. I agreed it is not good to have an additional wrap() or unwrap() that did nothing, but I have no better idea. It would be nice if we could have a fix in JDK 15, considering the impact on Tomcat and Firefox. I'm open if there is alternative solution or workaround. > Maybe not put the finished message or put all these messages > together. > > Maybe Brad may know of a way out of this problem?? If creating a dummy > message is the only way to fix this, then I'm ok with it.? It is just > not a clean fix in my mind. > > >>> My understanding would have been after Finished because NST is >>> suppose to be a post handshake message.? So in this case there is no >>> problem, correct? >>> >> Correct. >> >>> I'm trying to figure out why you need an empty NST.? Is the problem >>> when a number of messages are bundled together.? For example, the >>> Finished message with a partial NST, then Finished isn't processed >>> and both sides are waiting?? Or do both sides continue normal >>> traffic, it's jut the HandshakeStatus.FINISHED is one operation behind? >>> >> It should be fine as empty NST is just a signal to indicate the next >> call to wrap().? The next call to wrap() just use the signal for the >> return of FINISHED status, not network data produced, delivered or >> consumed. >> >>> >>> One code comment so far: >>> 433:? The debug message purpose was to say the NST is a stateless >>> ticket and not a preshared key.? Can we keep "stateless" in the message? >>> >> NewSessionTicket.java?? Sure, I may just want to shrink to one line. >> It was not intended. > > shrinking the message is fine, it just needs to be clear which message > ticket type got sent. > Added back. Xuelei From valerie.peng at oracle.com Tue May 26 23:14:53 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 26 May 2020 16:14:53 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> Message-ID: <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> I suppose we can allow trailing data to conform to "..." then. But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? Valerie On 5/25/2020 9:02 PM, Weijun Wang wrote: > The new definition at https://tools.ietf.org/html/rfc5958 shows, > > OneAsymmetricKey ::= SEQUENCE { > version Version, > privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, > privateKey PrivateKey, > attributes [0] Attributes OPTIONAL, > ..., > [[2: publicKey [1] PublicKey OPTIONAL ]], > ... > } > > According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: > > The string "..." in ASN.1 is called an extension marker. The extension marker, > ellipsis, is an indication that extension additions are expected. It makes no > statement as to how such additions should be handled. However they shall not be > treated as an error during the decoding process. > > So there might be more fields in the future. Do you still insist we need more validation? > > Thanks, > Max > > >> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >> >> >> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >> >> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >> >> Thanks, >> Valerie >> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>> >>>> Hi Max, >>>> >>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>> >>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>> >>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>> throws IOException { >>>> boolean hasAttributes = false; >>>> boolean hasPublicKey = false; >>>> while (derIn.available () != 0) { >>>> // check for OPTIONAL attributes and/or publicKey >>>> DerValue tmp = derIn.getDerValue(); >>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>> // OPTIONAL attributes not supported yet >>>> // discard for now and move on >>>> hasAttributes = true; >>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>> !hasPublicKey) { >>>> // OPTIONAL v2 public key not supported yet >>>> // discard for now and move on >>>> hasPublicKey = true; >>>> } else { >>>> throw new IOException ("illegal encoding in private key"); >>>> } >>>> } >>>> } >>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>> >>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>> OK. >>> >>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>> Yes. >>> >>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>> If you still want checkTrailingBytes, then yes. >>> >>> Thanks, >>> Max >>> >>>> Thanks, >>>> >>>> Valerie >>>> >>>> >>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>> I will take a look. >>>>> >>>>> Valerie >>>>> >>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>> Found an existing test I can update. Webrev updated at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>> >>>>>>> Please take a review at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>> >>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>> >>>>>>> I also take this chance to make some format change. >>>>>>> >>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> From weijun.wang at oracle.com Wed May 27 00:21:27 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 08:21:27 +0800 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8242068/webrev.01/ Two major changes: 1. Always use the signature algorithm directly in SignerInfo::signatureAlgorithm: In PKCS7 SignerInfo SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } We have always been putting "SHA-1" etc into DigestAlgorithmIdentifier, and "RSA", "DSA", "EC" into signatureAlgorithm. The latest https://tools.ietf.org/html/rfc5652#section-10.1.2 claims it to be The SignatureAlgorithmIdentifier type identifies a signature algorithm, and it can also identify a message digest algorithm. Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with SHA-256. It's complicated to always divide a signature algorithm into a digest algorithm and an encryption algorithm (and with the new RSASSA-PSS and EdDSA it's not easy to define it), therefore I decide to use the signature algorithm directly from now on. Fortunately Java has been able to parse this for a very long time so there is no compatibility issue. I noticed BouncyCastle has been doing the same, and OpenSSL too except for RSA. 2. Support both SHAKE256 and SHAKE256-LEN while parsing a Ed448 SignerInfo. They are both described in https://www.rfc-editor.org/rfc/rfc8419.html although it's a little complicated. To be standard compliant (https://www.rfc-editor.org/rfc/rfc8419.html#section-3.2 and we don't use Signed Attributes), by default Java will use SHAKE256 as the digestAlgorithm. However I noticed BouncyCastle does not recognize it, so if you set the system property "jdk.security.pkcs7.ed448.digalg.haslen" to "true", it will use SHAKE256-LEN (len == 512). I haven't described this system property in the CSR yet. Thanks, Max > On May 22, 2020, at 10:30 PM, Weijun Wang wrote: > > Please take a review at > > CSR : https://bugs.openjdk.java.net/browse/JDK-8245274 > webrev : http://cr.openjdk.java.net/~weijun/8242068/webrev.00/ > > Major points in CSR: > > - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in jarsigner > > - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a signed JAR) are reused for new signature algorithms > > major code changes: > > - Move signature related utilities methods from AlgorithmId.java to SignatureUtil.java > > - Add new SignatureUtil methods fromKey() and fromSignature() to simplify creating Signature and getting its AlgorithmId > > - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing > > - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all old and new signature algorithms > > - Mark all -altsign related code deprecated and they can be removed once ContentSigner is removed > > Next I'll do some basic interop tests with openssl and BouncyCastle. > > Thanks, > Max > From weijun.wang at oracle.com Wed May 27 00:54:33 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 08:54:33 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> Message-ID: <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. Thanks, Max > On May 27, 2020, at 7:14 AM, Valerie Peng wrote: > > I suppose we can allow trailing data to conform to "..." then. > > But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? > > Valerie > > On 5/25/2020 9:02 PM, Weijun Wang wrote: >> The new definition at https://tools.ietf.org/html/rfc5958 shows, >> >> OneAsymmetricKey ::= SEQUENCE { >> version Version, >> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >> privateKey PrivateKey, >> attributes [0] Attributes OPTIONAL, >> ..., >> [[2: publicKey [1] PublicKey OPTIONAL ]], >> ... >> } >> >> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >> >> The string "..." in ASN.1 is called an extension marker. The extension marker, >> ellipsis, is an indication that extension additions are expected. It makes no >> statement as to how such additions should be handled. However they shall not be >> treated as an error during the decoding process. >> >> So there might be more fields in the future. Do you still insist we need more validation? >> >> Thanks, >> Max >> >> >>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>> >>> >>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>> >>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>> >>> Thanks, >>> Valerie >>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>> >>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>> >>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>> throws IOException { >>>>> boolean hasAttributes = false; >>>>> boolean hasPublicKey = false; >>>>> while (derIn.available () != 0) { >>>>> // check for OPTIONAL attributes and/or publicKey >>>>> DerValue tmp = derIn.getDerValue(); >>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>> // OPTIONAL attributes not supported yet >>>>> // discard for now and move on >>>>> hasAttributes = true; >>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>> !hasPublicKey) { >>>>> // OPTIONAL v2 public key not supported yet >>>>> // discard for now and move on >>>>> hasPublicKey = true; >>>>> } else { >>>>> throw new IOException ("illegal encoding in private key"); >>>>> } >>>>> } >>>>> } >>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>> >>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>> OK. >>>> >>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>> Yes. >>>> >>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>> If you still want checkTrailingBytes, then yes. >>>> >>>> Thanks, >>>> Max >>>> >>>>> Thanks, >>>>> >>>>> Valerie >>>>> >>>>> >>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>> I will take a look. >>>>>> >>>>>> Valerie >>>>>> >>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>> Found an existing test I can update. Webrev updated at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Max >>>>>>> >>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>> >>>>>>>> Please take a review at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>> >>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>> >>>>>>>> I also take this chance to make some format change. >>>>>>>> >>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> From weijun.wang at oracle.com Wed May 27 03:31:43 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 11:31:43 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Message-ID: <35E1389C-302B-4D91-B7E9-13DBB6921179@oracle.com> > On May 27, 2020, at 1:46 AM, Alexey Bakhtin wrote: > > Hello Max, > > Thank you review. > If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. Not sure if I understand, what do "Different SASL protocols" mean? Here LdapClient is the application and therefore the "protocol". Are you worried that another SASL mechanism might choose a different prefix? I really find the TLS word in a SASL mechanism strange. It belongs to a different layer. --Max > This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. > > Alexey > >> On 26 May 2020, at 17:50, Weijun Wang wrote: >> >> I have a question on GssKrb5Client.java: >> >> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >> >> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >> >> Thanks, >> Max >> >>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>> >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>> >>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>> (based on the TLS server certificate). The channel binding data is calculated as following : >>> ? The client calculates a hash of the TLS server certificate. >>> The hash algorithm is selected on the base of the certificate signature algorithm. >>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>> ? initiator and acceptor addresses should be set to NULL >>> ? initiator and acceptor address types should be zero. >>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>> instead of GSS_C_AF_UNSPEC=0x00. >>> >>> This patch introduces changes in the LDAP, SASL and JGSS modules >>> to generate channel binding data automatically if requested by an application. >>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>> Right now "tls-server-end-point" Channel Binding type is supported only. >>> The client extracts server certificate from the underlying TLS connection and creates >>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>> >>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>> >>> [2] - >>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>> >>> Initial discussion of this issue is available at security-dev list: >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html > From alexey at azul.com Wed May 27 09:42:20 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 09:42:20 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I?ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ This fix allows to set GSS_C_AF_UNSPEC address type for the tls-server-end-point channel binding only Regards Alexey > On 26 May 2020, at 23:37, Valerie Peng wrote: > > I am also concerned about the changes in GSSLibStub.c about the default value being GSS_C_AF_UNSPEC instead of GSS_C_AF_NULLADDR (line 194-195). > > Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd prefer to not changing the default value for addresstype for the same reason which Michael has already stated. > > Thanks, > Valerie > > > On 5/25/2020 8:33 AM, Alexey Bakhtin wrote: >> Hello Michael, Thomas, >> >> Thank you a lot for review and suggestions. >> I?ve fixed most of the issues except of fundamental one >> I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. >> >> Updated webrev is available at: >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ >> >> >> Also, please see my comments below. >> >> Regards >> Alexey >> >> >>> On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> >>> wrote: >>> >>> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >>> >>>> Hello, >>>> >>>> Could you please review the following patch: >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8245527 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>> Let's go through your changes statically: >>> >>> * The JIRA issue title has a typo >>> >> Thank you. Fixed in Jira >> >>> * The word "cannot" is incorrectly spelled throughout all exception messages >>> >> Fixed from ?can not? to ?cannot" >> >>>> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >>>> + throw new UnsupportedOperationException("LdapCtx: " + >>>> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); >>>> >>> >>> "LdapCtx: " is redundant because the stacktrace will contain the class >>> name already. A better message would be: "Channel binding type '%s' is >>> not supported". Not just the plain value. >>> >> Exception message is corrected >> >>>> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >>>> + if (connectTimeout == -1) >>>> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >>>> + CONNECT_TIMEOUT + " property is set."); >>>> >>> * Same here with the message >>> >> Not sure, What?s wrong with the message ? >> >>> * The IAE is wrong because passed value is correct, but leads to an >>> invalid state because connection timeout is -1. You need an >>> IllegalStateException here. >>> >> Thank you. You are right again. Changed to IllegalStateException >> >>> Stupid question: how can one create a GSS security context when the TLS >>> security context has not been established yet? >>> >> This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. >> The only changes here is to prevent double setting of channel binding data. >> >> >>>> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>>> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>>> @@ -531,9 +531,12 @@ >>>> public void setChannelBinding(ChannelBinding channelBindings) >>>> throws GSSException { >>>> >>>> - if (mechCtxt == null) >>>> + if (mechCtxt == null) { >>>> + if (this.channelBindings != null) { >>>> + throw new GSSException(GSSException.BAD_BINDINGS); >>>> + } >>>> this.channelBindings = channelBindings; >>>> - >>>> + } >>>> } >>>> >>> I don't understand the purpose of this hunk. Is this safeguard to set >>> bindings only once? >>> >>> >>>> private static final int CHANNEL_BINDING_AF_INET = 2; >>>> private static final int CHANNEL_BINDING_AF_INET6 = 24; >>>> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >>>> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; >>>> >>> This should sort from 0 to 255 and not at the end. >>> >> OK. Moved to the top. >> >> >>>> private int getAddrType(InetAddress addr) { >>>> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >>>> + int addressType = CHANNEL_BINDING_AF_UNSPEC; >>>> >>>> // initialize addrtype in CB first >>>> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >>>> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >>>> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >>>> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; >>>> >>> This looks wrong to me -- as you already mentioned -- this violates RFC >>> 2744, section 3.11, last sentence: >>> >>>> or omit addressing information, specifying >>>> GSS_C_AF_NULLADDR as the address-types. >>>> >>>> /* release initiator address */ >>>> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >>>> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >>>> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >>>> resetGSSBuffer(&(cb->initiator_address)); >>>> } >>>> /* release acceptor address */ >>>> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >>>> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >>>> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >>>> resetGSSBuffer(&(cb->acceptor_address)); >>>> } >>>> >>> Unspecified does not mean that it is null. >>> >>> >>>> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >>>> + byte[] cbData = Arrays.copyOf(prefix, >>>> + prefix.length + tlsCB.getData().length ); >>>> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); >>>> >>> Since you are calling "tlsCB.getData()" multiple times, this should go >>> into a variable. >>> >> Temporary variable is added >> >> >>> >>>> + secCtx.setChannelBinding(new >>>> >>> ChannelBinding(null, null, cbData)); >>> >>> Why not use new ChannelBinding(cbData)? >>> >> Right. updated >> >> >>>> + String hashAlg = serverCertificate.getSigAlgName(). >>>> + replace("SHA", "SHA-").toUpperCase(); >>>> + int ind = hashAlg.indexOf("WITH"); >>>> + if (ind > 0) { >>>> + hashAlg = hashAlg.substring(0, ind); >>>> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >>>> + hashAlg = "SHA-256"; >>>> + } >>>> >>> I have several problems with that, some might be hypothetical: >>> >>> * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH >>> >> As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. >> Looking at implementation I do not think it is realistic to get name in the non-English locale. >> I do not think it should be fixed >> >> >>> * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2 >>> , then >>> at sun.security.x509.AlgorithmId.getName() it uses nameTable to >>> translate OIDs to readible names. >>> >>> With indexOf("WITH") you are implying that the cert's sig alg may not >>> use a cryptographic function, but this would mean that if the OID is >>> 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, >>> wouldn't you? >>> I also don't know how realistic "PBEWith..." is. >>> >>> This likely needs more thought or I am missing something. >>> >>> >> I do not think it is realistic scenario to have certificate signature algorithm without crypto function. >> indexOf(?WITH?) just used to find end out hash algorithm name. >> >> >>> * Exception messages are inconsistent. Sometimes "TLS channel binding", >>> sometimes just "channel binding". To avoid misunderstandings it should >>> always read "TLS channel binding..". >>> >>> >> Messages are updated. >> >> >>> Generally, I have two fundemental issues: >>> * How do you know that address type must be UNSPEC and not NULLADDR? >>> Trial and error? >>> >> I did not find any strict specification about TLS Channel Binding format in Windows server. >> So, it was a lot of experiments, reading related forums and docs. >> One of the doc, that turns me to try UNSPEC type is the following: >> >> https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication >> >> >> >>> * Changing the default address type against the RFC will break every >>> installation using channel bindings relying on it with cross GSS-API >>> implementations. >>> >> I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. >> The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. >> >> >>> There must be another way to solve this. A system property would also be >>> problematic because if you have a product which connects to MS and >>> non-MS backends at the same time, channel bindings would be broken again. >>> >>> What about introducing a UnspecEmptyInetAddress() which gives the proper >>> AF type, but #getAddress() would return null? This should satisfy the >>> requirements, InitialToken as well as the RFC. this of course needs to >>> be properly passed to native providers too. GssKrb5Client would also >>> need to know that this channel binding is explicitly for Active >>> Directory and not some other, spec-compliant, SASL peer (property on >>> LdapCtx?) >>> >>> One could easily use this for custom code with a SSLServerSocket paired >>> with Java SASL or in C, OpenSSL and Cyrus SASL. >>> >>> Michael >>> >>> PS: Yes, I am a nitpicker. >>> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From aph at redhat.com Wed May 27 09:51:31 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2020 10:51:31 +0100 Subject: RFR[15] JDK-8243114: Implement montgomery{Multiply, Square}intrinsics on Windows In-Reply-To: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> References: <725e8e5a-71b5-7d6e-4d3a-7c799a52ab56@redhat.com> Message-ID: On 21/05/2020 18:24, Simon Tooke wrote: > This change implements the given intrinsics on Windows. Thank you. Does julong work on Windows, rather than unsigned long long? If not, perhaps a local typedef might help. All those "unsigned log long"s look a bit clumsy. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ecki at zusammenkunft.net Wed May 27 10:12:14 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 27 May 2020 10:12:14 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> , <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Message-ID: LdapCtxt: 2568 /** 2569 * Sets the read timeout value 2570 */ 2571 private void setChannelBindingType(String cbTypeProp) { Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? Gruss Bernd ________________________________ Von: security-dev im Auftrag von Alexey Bakhtin Gesendet: Mittwoch, Mai 27, 2020 11:43 AM An: Valerie Peng Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun.wang at oracle.com Wed May 27 10:25:15 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 18:25:15 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> > On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: > > The hash algorithm is selected on the base of the certificate signature algorithm. > Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 According to https://www.rfc-editor.org/rfc/rfc5929#section-4.1, this is the right approach. I'm just curious if you have seen newer signature algorithms like RSASSA-PSS and EdDSA used in reality, since the latest TLS spec already defined ciphersuites around them. Thanks, Max From alexey at azul.com Wed May 27 10:48:13 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 10:48:13 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Message-ID: <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Hello Bernd, > On 27 May 2020, at 13:12, Bernd Eckenfels wrote: > > LdapCtxt: > 2568 /** > 2569 * Sets the read timeout value > 2570 */ > 2571 private void setChannelBindingType(String cbTypeProp) { Thank you. This is misprint. Should be ?Sets the channel binding type? About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. Actually, we can force to wait for handshake completion but what timeout should be set in this case. As mentioned by Danial, information about new property and timeout should be documented in the release notes. For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings > > Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, > > what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) > > This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? > > Gruss > Bernd > > Von: security-dev im Auftrag von Alexey Bakhtin > Gesendet: Mittwoch, Mai 27, 2020 11:43 AM > An: Valerie Peng > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen > Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos > > Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From aleksej.efimov at oracle.com Wed May 27 13:13:14 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 27 May 2020 14:13:14 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Message-ID: Hi Alexey, I have question about timeouts: LdapCtx has 2 timeout properties: connectTimeout and readTimeout. First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply). Both of them have default values set to '-1' which means that the LDAP stack would not set any timeouts for connect and/or reading operations. Could you, please, share the failures you're observing with no connect timeout set? Best, Aleksei On 27/05/2020 11:48, Alexey Bakhtin wrote: > Hello Bernd, > >> On 27 May 2020, at 13:12, Bernd Eckenfels wrote: >> >> LdapCtxt: >> 2568 /** >> 2569 * Sets the read timeout value >> 2570 */ >> 2571 private void setChannelBindingType(String cbTypeProp) { > > Thank you. This is misprint. Should be ?Sets the channel binding type? > About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. > Actually, we can force to wait for handshake completion but what timeout should be set in this case. > As mentioned by Danial, information about new property and timeout should be documented in the release notes. > For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings > > >> Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, >> >> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) >> >> This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? >> >> Gruss >> Bernd >> >> Von: security-dev im Auftrag von Alexey Bakhtin >> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM >> An: Valerie Peng >> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen >> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos >> >> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ From alexey at azul.com Wed May 27 14:14:43 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 14:14:43 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> References: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> Message-ID: <2B5DEFB0-6D19-412E-B1D7-B7984D87F7B0@azul.com> Hi Max, You are right, It is possible that algorithm name is not confirm With format. As soon as RFC5929 does not specify this situation I would suggest to use ?SHA-256? hash instead of throwing SaslException exception. Regards Alexey > On 27 May 2020, at 13:25, Weijun Wang wrote: > > > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 > > According to https://www.rfc-editor.org/rfc/rfc5929#section-4.1, this is the right approach. I'm just curious if you have seen newer signature algorithms like RSASSA-PSS and EdDSA used in reality, since the latest TLS spec already defined ciphersuites around them. > > Thanks, > Max -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From research at bensmyth.com Wed May 27 14:23:20 2020 From: research at bensmyth.com (Ben Smyth) Date: Wed, 27 May 2020 16:23:20 +0200 Subject: Refactoring TLS code Message-ID: I have written a TLS 1.3 tutorial ( https://bensmyth.com/publications/2019-TLS-tutorial/) which includes source code from JDK 11. Whilst explaining the code, I noticed some possible refactoring that would simplify the (JDK 11 & current) code base: - createHkdfInfo is defined three times: SSLBasicKeyDerivation.createHkdfInfo could perhaps be dropped in favour of SSLSecretDerivation.createHkdfInfo (noting a slight difference regarding runtime exceptions), as can SSLTrafficKeyDerivation.T13TrafficKeyDerivation.createHkdfInfo (noting the need to supply 0x00 as the context). - ServerHello.T13ServerHelloProducer.produce and ServerHello.T13ServerHelloConsumer.consume each define code to changeclient/server handshake traffic secrets. The code is identical up to contexts, labels s_hs_traffic and c_hs_traffic, treatment of null in tricks to make the compiler happy (cf. return null; and return; in catch-branches), alpha-renaming of one variable, and whitespace (and some obsolete, commented-out code). - Similarly to the previous point, Finished.T13FinishedProducer.onProduceFinished and Finished.T13FinishedConsumer.onConsumeFinished define code to derive traffic secrets and corresponding traffic keys, (unsurprisingly) computations are similar. (The same is true for other secrets and traffic keys.) - CertificateVerify.onProduceCertificateVerify is defined for ServerHandshakeContext and ClientHandshakeContext, both instances are identical up to variables shc and chc (with the former using string "server" and the latter using "client" for logging). - Not really refactoring, but comment on ClientHello:1172 says extension key_share is ignored, when it isn't (extension psk_key_exchange_modes, pre_shared_key, and protocol_version are). My apologises if this mail is considered noise (or is simply wrong)---I figured suggestions for simplifying JDK's code base might be useful. Best regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey at azul.com Wed May 27 14:57:08 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 14:57:08 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Message-ID: <2037375D-FBEB-491F-803F-F813D9ECB741@azul.com> Hello Aleks, I mean ?com.sun.jndi.ldap.connect.timeout? property. The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: Connection.java >> if (connectTimeout > 0) { >> int socketTimeout = sslSocket.getSoTimeout(); >> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >> sslSocket.startHandshake(); >> sslSocket.setSoTimeout(socketTimeout); >> } Without this property handshake is started later asynchronously. As result >> certs = ssock.getSession().getPeerCertificates(); in the LdapClient.java could return SSLPeerUnverifiedException(). This exception will be wrapped to NamingException and thrown to application. This is not usually happens but I saw it on the slow connection Alexey > On 27 May 2020, at 16:13, Aleks Efimov wrote: > > Hi Alexey, > > I have question about timeouts: > LdapCtx has 2 timeout properties: connectTimeout and readTimeout. > First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply). > Both of them have default values set to '-1' which means that the LDAP stack would not set any timeouts for connect and/or reading operations. > > Could you, please, share the failures you're observing with no connect timeout set? > > Best, > Aleksei > > On 27/05/2020 11:48, Alexey Bakhtin wrote: >> Hello Bernd, >> >>> On 27 May 2020, at 13:12, Bernd Eckenfels wrote: >>> >>> LdapCtxt: >>> 2568 /** >>> 2569 * Sets the read timeout value >>> 2570 */ >>> 2571 private void setChannelBindingType(String cbTypeProp) { >> >> Thank you. This is misprint. Should be ?Sets the channel binding type? >> About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. >> Actually, we can force to wait for handshake completion but what timeout should be set in this case. >> As mentioned by Danial, information about new property and timeout should be documented in the release notes. >> For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings >> >> >>> Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, >>> >>> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) >>> >>> This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? >>> >>> Gruss >>> Bernd >>> >>> Von: security-dev im Auftrag von Alexey Bakhtin >>> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM >>> An: Valerie Peng >>> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen >>> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos >>> >>> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xuelei.fan at oracle.com Wed May 27 14:57:50 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 May 2020 07:57:50 -0700 Subject: Refactoring TLS code In-Reply-To: References: Message-ID: <41e7ffa7-3e30-b789-7cd3-e3726ad5a895@oracle.com> Hi Ben, The tutorial is impressive to me. Thanks for the reporting, I filed a RFE for the tracking: https://bugs.openjdk.java.net/browse/JDK-8245983 Xuelei On 5/27/2020 7:23 AM, Ben Smyth wrote: > I have written a TLS 1.3 tutorial > (https://bensmyth.com/publications/2019-TLS-tutorial/) which includes > source code from JDK 11. Whilst explaining the code, I noticed some > possible refactoring that would simplify the (JDK 11 & current) code base: > > - createHkdfInfo is defined three times: > SSLBasicKeyDerivation.createHkdfInfo could perhaps be dropped in favour > of SSLSecretDerivation.createHkdfInfo (noting a slight difference > regarding runtime exceptions), as can > SSLTrafficKeyDerivation.T13TrafficKeyDerivation.createHkdfInfo (noting > the need to supply 0x00 as the context). > > - ServerHello.T13ServerHelloProducer.produce and > ServerHello.T13ServerHelloConsumer.consume each define code to > changeclient/server handshake traffic secrets. The code is identical up > to contexts, labels s_hs_traffic and c_hs_traffic, treatment of null in > tricks to make the compiler happy (cf. return null; and return; in > catch-branches), alpha-renaming of one variable, and whitespace (and > some obsolete, commented-out code). > > - Similarly to the previous point, > Finished.T13FinishedProducer.onProduceFinished and > Finished.T13FinishedConsumer.onConsumeFinished define code to derive > traffic secrets and corresponding traffic keys, (unsurprisingly) > computations are similar. (The same is true for other secrets and > traffic keys.) > > - CertificateVerify.onProduceCertificateVerify is defined for > ServerHandshakeContext and ClientHandshakeContext, both instances are > identical up to variables shc and chc (with the former using string > "server" and the latter using "client" for logging). > > - Not really refactoring, but comment on ClientHello:1172 says extension > key_share is ignored, when it isn't (extension psk_key_exchange_modes, > pre_shared_key, and protocol_version are). > > My apologises if this mail is considered noise (or is simply wrong)---I > figured suggestions for simplifying JDK's code base might be useful. > > > Best regards, > > Ben From sean.mullan at oracle.com Wed May 27 15:24:02 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 27 May 2020 11:24:02 -0400 Subject: RFR JDK-8206925,,Support the certificate_authorities extension In-Reply-To: References: <1db8f24c-2a27-2c1e-2a0d-380df34fc35f@oracle.com> <44221480-8676-0fc4-4289-e2fc376bf22c@oracle.com> <49d92d7e-d934-6b97-8dc6-7e859ec47226@oracle.com> <1ee6f6a2-9c77-014f-889a-cbb63287e29c@oracle.com> <8e389e7d-0535-2645-5fa8-9cfbbb826e2d@oracle.com> <8b9342b0-3d43-77a6-5f83-05eed5d7a4a7@oracle.com> <2e633d60-8533-e5e8-f262-2deffa41f442@oracle.com> <938477ba-759e-516c-f1cd-394c3f2a4977@oracle.com> <7d2d05b4-86c5-78b1-538d-21d03d0ae1be@oracle.com> Message-ID: <3f1b1bae-35cc-bfc3-cced-3abc30fcb5a2@oracle.com> On 5/22/20 6:38 PM, Xuelei Fan wrote: > On 5/22/2020 11:17 AM, Sean Mullan wrote: >> On 5/22/20 1:55 PM, Xuelei Fan wrote: >>>> * test/jdk/sun/security/ssl/X509TrustManagerImpl/TooMuchCAs.java >>>> >>>> Will this test FAIL if we ever exceed the maximum number of CAs? I >>>> think it is important that it does FAIL, as the extension is >>>> effectively not working anymore and could cause compatibility >>>> issues. I even think we would need to try to think of some way to >>>> fix it, either by seeing if some CAs could be excluded - not really >>>> sure, hopefully it won't ever happen but we would want to know about >>>> it in advance. >>>> >>> Alexey (from azul) and I discussed the idea to control the number of >>> CAs.? However, there are still some issues in practice. >>> >>> "If the certificate authorities can not be fully listed, it cannot be >>> used to indicate the peer certificate selection accuracy.? For >>> example, client support A, B and C, and is only able to indicate A >>> and B.? If the server supports C, the connection cannot be >>> established with this extension. This is not the expected behavior. >>> Maybe, it is no worse than without this extension. " >>> >>> It looks like safer that the extension is not used if the size exceed >>> the limit, at least there ARE less compatibility issues.? I have a >>> note in the CSR and release note for the behaviors. >>> >>> The test case, TooMuchCAs, is used to make sure the connection can be >>> established when the CAs size exceed the limit (no extension used). >> >> Sure, I agree that is the best behavior. I guess my point is that if >> we ever really exceed the maximum number of CAs in the cacerts >> keystore, it would be good to have a test that will fail because of >> that. Minimally, this would allow us to publish a release note warning >> users that the CA extension will no longer work unless some roots are >> removed. >> > Good point.? It is useful to have a test case to check the size limit of > the cacert keystore.? A new test case, CacertsLimit.java, is added.? The > same webrev URL is used: > ?? http://cr.openjdk.java.net/~xuelei/8206925/webrev.05/ 71 "certificate_authorities extension can be used " + typo: s/can/cannot/ Looks good otherwise. --Sean From anthony.scarpino at oracle.com Wed May 27 20:22:52 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Wed, 27 May 2020 13:22:52 -0700 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported Message-ID: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Hi, I need a javadoc review for a Signature/SignatureSpi parameters change that is needed to the spec, which affects EdDSA. The existing spec was very strict in the way set and get parameters were handled. This modifies that slightly by allowing null to be returned by the get methods when it is unsupported after the parameters have been set. Since null was an allowed return value, this minimizes the backwards compatibility chances. CSR: https://bugs.openjdk.java.net/browse/JDK-8243425 webrev: https://cr.openjdk.java.net/~ascarpino/8243424/webrev/ Tony From valerie.peng at oracle.com Thu May 28 00:46:05 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 27 May 2020 17:46:05 -0700 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> Message-ID: <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> Hi Max, I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. A few notable differences which I am not so sure about are - the encodedKey is returned by getEncoded() directly w/o cloning, and - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. Thanks, Valerie On 5/26/2020 5:54 PM, Weijun Wang wrote: > Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. > > However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. > > Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. > > Thanks, > Max > > >> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >> >> I suppose we can allow trailing data to conform to "..." then. >> >> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >> >> Valerie >> >> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>> >>> OneAsymmetricKey ::= SEQUENCE { >>> version Version, >>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>> privateKey PrivateKey, >>> attributes [0] Attributes OPTIONAL, >>> ..., >>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>> ... >>> } >>> >>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>> >>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>> ellipsis, is an indication that extension additions are expected. It makes no >>> statement as to how such additions should be handled. However they shall not be >>> treated as an error during the decoding process. >>> >>> So there might be more fields in the future. Do you still insist we need more validation? >>> >>> Thanks, >>> Max >>> >>> >>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>> >>>> >>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>> >>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>> >>>> Thanks, >>>> Valerie >>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>> >>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>> >>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>> throws IOException { >>>>>> boolean hasAttributes = false; >>>>>> boolean hasPublicKey = false; >>>>>> while (derIn.available () != 0) { >>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>> DerValue tmp = derIn.getDerValue(); >>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>> // OPTIONAL attributes not supported yet >>>>>> // discard for now and move on >>>>>> hasAttributes = true; >>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>> !hasPublicKey) { >>>>>> // OPTIONAL v2 public key not supported yet >>>>>> // discard for now and move on >>>>>> hasPublicKey = true; >>>>>> } else { >>>>>> throw new IOException ("illegal encoding in private key"); >>>>>> } >>>>>> } >>>>>> } >>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>> >>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>> OK. >>>>> >>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>> Yes. >>>>> >>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>> If you still want checkTrailingBytes, then yes. >>>>> >>>>> Thanks, >>>>> Max >>>>> >>>>>> Thanks, >>>>>> >>>>>> Valerie >>>>>> >>>>>> >>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>> I will take a look. >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max >>>>>>>> >>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> Please take a review at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>> >>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>> >>>>>>>>> I also take this chance to make some format change. >>>>>>>>> >>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> From weijun.wang at oracle.com Thu May 28 01:16:18 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 28 May 2020 09:16:18 +0800 Subject: RFR 8244565: Accept PKCS #8 with version number 1 In-Reply-To: <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> References: <2088E2A0-FB0B-4E06-9563-037C49531274@oracle.com> <876ce618-35f1-a5e3-14c6-be754e2d34b8@oracle.com> <78a6d1c5-666e-1be1-7514-ae4f8c8acad6@oracle.com> <5b29d921-3efa-c01e-330b-8b2a052d4bfb@oracle.com> <49FE4C42-8C35-4C9A-A0C5-DB3CFAA6B61E@oracle.com> <09327ec8-34f0-57b1-f4b5-9c95a572566a@oracle.com> <74378A56-8536-4151-9B5D-257FBD5969EA@oracle.com> <253066b0-4a5f-4311-f3aa-4d6cd2393809@oracle.com> Message-ID: <24F7645C-EBF8-4BD3-A547-32F0E00F132C@oracle.com> > On May 28, 2020, at 8:46 AM, Valerie Peng wrote: > > Hi Max, > > I like this new structure better. Much easier to understand. Most of the changes are technical debt that's accumulated inside PKCS8Key class. > > A few notable differences which I am not so sure about are > > - the encodedKey is returned by getEncoded() directly w/o cloning, and Too bad. I'll fix. > > - the protected parseKeyBits() method being made private. I wonder if the parseKeyBits() method should be made abstract so it's more obvious that the subclasses needs to parse the key bytes into algorithm-specific components. Or how about I just inline parseKeyBits in those child classes into their constructors? I don't think the child class will forget it. Otherwise, why write a child class? Thanks, Max > > Thanks, > Valerie > On 5/26/2020 5:54 PM, Weijun Wang wrote: >> Can you please take a look (not a review) at an updated webrev at http://cr.openjdk.java.net/~weijun/8244565/webrev.02/? It contains the code to inspect the extra fields. I haven't deal with the "..." here yet. >> >> However, when I tried to consolidate the DER parsing into one place, I've made more and more changes everywhere. The major change now is a base constructor PKCS8Key(byte[]) and subclass constructors that call it and no more protected parseKeyBits(). Although I don't think there is any technical error here but at the end of the day I'm asking myself if this is too much code change for such a simple bug. >> >> Do you like the overall structure? If yes, I'll continue this way. Otherwise, I can restrict the change only inside PKCS8Key. >> >> Thanks, >> Max >> >> >>> On May 27, 2020, at 7:14 AM, Valerie Peng wrote: >>> >>> I suppose we can allow trailing data to conform to "..." then. >>> >>> But the "[[2: publicKey [1] PublicKey OPTIONAL ]]," line mean that the publicKey should not be present for V1? This should be checked? >>> >>> Valerie >>> >>> On 5/25/2020 9:02 PM, Weijun Wang wrote: >>>> The new definition at https://tools.ietf.org/html/rfc5958 shows, >>>> >>>> OneAsymmetricKey ::= SEQUENCE { >>>> version Version, >>>> privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, >>>> privateKey PrivateKey, >>>> attributes [0] Attributes OPTIONAL, >>>> ..., >>>> [[2: publicKey [1] PublicKey OPTIONAL ]], >>>> ... >>>> } >>>> >>>> According to https://www.ibm.com/support/pages/what-does-string-three-elipses-mean-asn1: >>>> >>>> The string "..." in ASN.1 is called an extension marker. The extension marker, >>>> ellipsis, is an indication that extension additions are expected. It makes no >>>> statement as to how such additions should be handled. However they shall not be >>>> treated as an error during the decoding process. >>>> >>>> So there might be more fields in the future. Do you still insist we need more validation? >>>> >>>> Thanks, >>>> Max >>>> >>>> >>>>> On May 20, 2020, at 1:37 PM, Valerie Peng wrote: >>>>> >>>>> >>>>> True, the current handling of the extra bytes in parseKey() and decode() are kind of opposite, one does not allow any extra bytes but the other ignores all. The trailing bytes may look harmless but simply ignores it may open up something unexpected. >>>>> >>>>> Given that this is key related class, I think it's important to do reasonable validation even though we currently do not use these trailing bytes. It'd also be good if the handling can be consistent regardless of the call path. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> On 5/18/2020 9:36 PM, Weijun Wang wrote: >>>>>>> On May 19, 2020, at 1:41 AM, Valerie Peng wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> I saw in the bug description that handling and parsing of the public key will be resolved in a separate enhancement which is fine with me. >>>>>>> >>>>>>> In addition to relaxing the PKCS8 version check to accept 1, the current webrev does not check for the trailing bytes and its validity. Perhaps we should consider adding necessary checks to ensure spec conformance? Perhaps some utility method like: (This includes basic checks plus checks for multiple attributes and version 1 w/ public key. ) >>>>>>> >>>>>>> private static void checkTrailingBytes(DerInputStream derIn, int version) >>>>>>> throws IOException { >>>>>>> boolean hasAttributes = false; >>>>>>> boolean hasPublicKey = false; >>>>>>> while (derIn.available () != 0) { >>>>>>> // check for OPTIONAL attributes and/or publicKey >>>>>>> DerValue tmp = derIn.getDerValue(); >>>>>>> if (tmp.isContextSpecific((byte)0) && !hasAttributes) { >>>>>>> // OPTIONAL attributes not supported yet >>>>>>> // discard for now and move on >>>>>>> hasAttributes = true; >>>>>>> } else if (version == V2 && tmp.isContextSpecific((byte)1) && >>>>>>> !hasPublicKey) { >>>>>>> // OPTIONAL v2 public key not supported yet >>>>>>> // discard for now and move on >>>>>>> hasPublicKey = true; >>>>>>> } else { >>>>>>> throw new IOException ("illegal encoding in private key"); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>> I wonder if this is necessary. The extra bytes are quite harmless, and we didn't check it in decode(). >>>>>> >>>>>>> Besides the encoding parsing check above, maybe V1, V2 can be made private static? >>>>>> OK. >>>>>> >>>>>>> I noticed that the PKCS8Key class has a block of code under the comments "Try again using JDK1.1-style...", however the provider property "PrivateKey.PKCS#8." seems long gone? Without these property, this block of code seems useless and probably should be cleaned up as well. >>>>>> Yes. >>>>>> >>>>>>> As for the test, the existing comments for the EXPECTED bytes are off and plain misleading. Could you please fix them or at least remove them. For example, the comment of "integer 3" should be associated with "0x02, 0x01, 0x03," bytes instead of "0x01, 0x02, 0x02,". In the updated test, NEW_ENCODED_KEY_INTS is PKCS8 v1 key and NEW_ENCODED_KEY_INTS_2 is PKCS8 v2 key w/ public key. Since the version value is always at index 4, we can either clone the existing bytes or directly override the version value in NEW_ENCODED_KEY_INTS or NEW_ENCODED_KEY_INTS_2 to add additional negative tests, e.g. encoding w/ the version value 2 (anything besides the allowed 0 and 1), version value 0 w/ trailing public key. It'd be nice to test version 1 w/ trailing bytes w/ invalid tag value as well. >>>>>> If you still want checkTrailingBytes, then yes. >>>>>> >>>>>> Thanks, >>>>>> Max >>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Valerie >>>>>>> >>>>>>> >>>>>>> On 5/13/2020 5:16 PM, Valerie Peng wrote: >>>>>>>> I will take a look. >>>>>>>> >>>>>>>> Valerie >>>>>>>> >>>>>>>> On 5/8/2020 3:39 AM, Weijun Wang wrote: >>>>>>>>> Found an existing test I can update. Webrev updated at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.01/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> On May 8, 2020, at 5:41 PM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> Please take a review at >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~weijun/8244565/webrev.00/ >>>>>>>>>> >>>>>>>>>> Now we accepts a PKCS8 file with version being 0 or 1. The publicKey and attributes are still not parsed. >>>>>>>>>> >>>>>>>>>> I also take this chance to make some format change. >>>>>>>>>> >>>>>>>>>> There is no regression test and I'll add one. I can generate a PKCS8 key and then modify the version from 0 to 1 and try to read it. Or I can find a PKCS8 generated by some other tool and embed it the test to read it. Please advise which is better. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max >>>>>>>>>> From xuelei.fan at oracle.com Thu May 28 03:44:12 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 27 May 2020 20:44:12 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> Message-ID: <94e98b03-bb05-1c6c-ec87-1dd5f788da2e@oracle.com> Tony and I had a private chat, and I understand his concerns better now. The name of the variable TransportContext.needEmptySessionTicket is confusing. I updated it to "needHandshakeFinishedStatus" per the suggestion, together with other change according to the comments. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8240871/webrev.01/ Thanks, Xuelei On 5/26/2020 2:40 PM, Xuelei Fan wrote: > On 5/26/2020 1:26 PM, Anthony Scarpino wrote: >> On 5/13/20 1:44 PM, Xuelei Fan wrote: >>> On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >>>> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Could I get the following update reviewed: >>>>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>>>> >>>>> For TLS 1.3 full handshake, if the last handshake flight wraps the >>>>> Finished together with other handshake message, for example client >>>>> certificate, the flight could be wrapped and encrypted in one >>>>> record and delegated tasks would be used.? There is no chance to >>>>> return FINISHED handshake status with SSLEngine.(un)wrap(). >>>>> However, per the HandshakeStatus.FINISHED specification, this >>>>> handshake status is only generated by a call to >>>>> SSLEngine.wrap()/unwrap() and it is never generated by >>>>> SSLEngine.getHandshakeStatus(). >>>>> >>>>> In order to workaround this case for TLS 1.3, the FINISHED status >>>>> could present with SSLEngine.wrap() while delivering of the >>>>> NewSessionTicket post-handshake message.? If this post-handshake >>>>> message is not needed, a follow-on SSLEngine.wrap() should be >>>>> called to indicate the FINISHED handshake status.? Although this >>>>> special SSLEngine.wrap() should not consume or produce any >>>>> application or network data. >>>>> >>>>> I also clean up some debug log, names and code style a little bit. >>>>> >>>>> The update could be confirmed with Tomcat and Firefox in private >>>>> mode, as described in the bug description.? As this case happens >>>>> only when psk_key_exchange_modes does not present, which is not a >>>>> behavior supported by JDK, I did not find a workaround for a new >>>>> regression test yet.? I added the labels, noreg-external and >>>>> noreg-hard. >>>>> >>>>> Thanks, >>>>> Xuelei >>>> >>>> I do not fully understand the situation, mostly because of SSLEngine >>>> semantics.? In normal operation, does is HandshakeStatus.FINISHED >>>> returned when Finished is received or after the NewSessionTicket >>>> message? >>> Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() of >>> the finished handshake message.? However, for TLS 1.3, FINISHED will >>> be returned any longer, because the finished handshake message is >>> wrapped with certificate message in one record. >>> >>> For TLS 1.3: >>> 1. client send certificate, certificate verify and finished handshake >>> message in one record. >>> 2. server call unwrap(), and return NEED_TASK to handle the >>> certificate and certificate verify. >>> >>> So, no more FINISHED for the unwrap() return. >>> >>> It is fine if there is a after NewSessionTicket message.? The wrap() >>> for the post-handshake message will return FINISHED. >>> >>> The bug reported is a special one that the Firefox is run in private >>> mode, which does not request NewSessionTicket.? So there is no >>> post-handshake generated and sent in server side.? Then, there is no >>> FINISHED can be used if applications depends on it. >>> >>> To workaround the case, a dummy wrap() or unwrap() could be used to >>> get the FINISHED.? The wrap() or unwrap() actually do nothing but >>> return the FINISHED status. >>> >> >> I don't want to be problematic, but I don't really agree with creating >> dummy messages to generate wrap/unwrap operations in the TLS code. > No dummy message created.? Only need to call wrap() or unwrap(), but not > data consumed or generated by the call to wrap() or unwrap(), no > application data consumed, no network data consumed, no application data > generated, no network data generated. > >> If SSLEngine is doing something wrong with not fully reading the >> buffer, then I feel it's SSLEngine that should be fixed to handle the >> situation right. > It is not caused by SSLEngine that does not fully reading the buffer. > Let me try again about what's the problem. > > The client (Firefox) sends, Certificate and CerticateVerify and Finished > handshake messages in one record.? The record is encrypted. > 1. One call to SSLEngine.unrwap() will read the record, and decrypt the > record. > 2. One call to SSLEngine.unwrap() cannot read the Certificate and > CerticateVerify handshake message only, without reading the Finished > handshake message.? It means the unwrap() method will consume the record > data fully for all three handshake messages. > 3. The Certificate and CerticateVerify should be handled in delegated > tasks, so the call to SSLEngine.unwrap() return NEED_TASK. > 4. As the SSLEngine.unwrap() return NEED_TASK, it cannot return the > FINISHED status at the same time. > 5. The FINISHED status is only be able to return with SSLEngine.unwrap() > or SSLEngine.wrap(), and cannot returned from delegated tasks.? So the > SSLEngine.getHandshakeStatus() after the tasks cannot be used to > indicate the FINISHED status. > 6. Then FINISHED status is missed, applications like Tomcat run into > problem, like the bug described. > > That's the problem of the bug as far as I can see.? I agreed it is not > good to have an additional wrap() or unwrap() that did nothing, but I > have no better idea.? It would be nice if we could have a fix in JDK 15, > considering the impact on Tomcat and Firefox.? I'm open if there is > alternative solution or workaround. > > >> Maybe not put the finished message or put all these messages together. >> >> Maybe Brad may know of a way out of this problem?? If creating a dummy >> message is the only way to fix this, then I'm ok with it.? It is just >> not a clean fix in my mind. >> >> >>>> My understanding would have been after Finished because NST is >>>> suppose to be a post handshake message.? So in this case there is no >>>> problem, correct? >>>> >>> Correct. >>> >>>> I'm trying to figure out why you need an empty NST.? Is the problem >>>> when a number of messages are bundled together.? For example, the >>>> Finished message with a partial NST, then Finished isn't processed >>>> and both sides are waiting?? Or do both sides continue normal >>>> traffic, it's jut the HandshakeStatus.FINISHED is one operation behind? >>>> >>> It should be fine as empty NST is just a signal to indicate the next >>> call to wrap().? The next call to wrap() just use the signal for the >>> return of FINISHED status, not network data produced, delivered or >>> consumed. >>> >>>> >>>> One code comment so far: >>>> 433:? The debug message purpose was to say the NST is a stateless >>>> ticket and not a preshared key.? Can we keep "stateless" in the >>>> message? >>>> >>> NewSessionTicket.java?? Sure, I may just want to shrink to one line. >>> It was not intended. >> >> shrinking the message is fine, it just needs to be clear which message >> ticket type got sent. >> > Added back. > > Xuelei From anthony.scarpino at oracle.com Fri May 29 15:59:46 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 29 May 2020 08:59:46 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: <94e98b03-bb05-1c6c-ec87-1dd5f788da2e@oracle.com> References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> <94e98b03-bb05-1c6c-ec87-1dd5f788da2e@oracle.com> Message-ID: Thanks for the changes Xuelei, it is much clearer to me now. Two minor things and a question. NewSessionTicket:323. The comment talks about an empty session ticket, SSLEngineImpl:167. Comment uses old variable name One question, NewSessionTicket 464-470 and SSLEngineImpl.writeRecord() 167-172 both set needHandshakeFinishedStatus false. If the NST code sets needHandshakeFinishedStatus before the asynchronous call to writeRecord(), couldn't that not change the status? Would it be better to only have the writeRecord() check? thanks Tony On 5/27/20 8:44 PM, Xuelei Fan wrote: > Tony and I had a private chat, and I understand his concerns better now. > ?The name of the variable TransportContext.needEmptySessionTicket is > confusing.? I updated it to "needHandshakeFinishedStatus" per the > suggestion, together with other change according to the comments. > > Here is the new webrev: > ?? http://cr.openjdk.java.net/~xuelei/8240871/webrev.01/ > > Thanks, > Xuelei > > On 5/26/2020 2:40 PM, Xuelei Fan wrote: >> On 5/26/2020 1:26 PM, Anthony Scarpino wrote: >>> On 5/13/20 1:44 PM, Xuelei Fan wrote: >>>> On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >>>>> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Could I get the following update reviewed: >>>>>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>>>>> >>>>>> For TLS 1.3 full handshake, if the last handshake flight wraps the >>>>>> Finished together with other handshake message, for example client >>>>>> certificate, the flight could be wrapped and encrypted in one >>>>>> record and delegated tasks would be used.? There is no chance to >>>>>> return FINISHED handshake status with SSLEngine.(un)wrap(). >>>>>> However, per the HandshakeStatus.FINISHED specification, this >>>>>> handshake status is only generated by a call to >>>>>> SSLEngine.wrap()/unwrap() and it is never generated by >>>>>> SSLEngine.getHandshakeStatus(). >>>>>> >>>>>> In order to workaround this case for TLS 1.3, the FINISHED status >>>>>> could present with SSLEngine.wrap() while delivering of the >>>>>> NewSessionTicket post-handshake message.? If this post-handshake >>>>>> message is not needed, a follow-on SSLEngine.wrap() should be >>>>>> called to indicate the FINISHED handshake status.? Although this >>>>>> special SSLEngine.wrap() should not consume or produce any >>>>>> application or network data. >>>>>> >>>>>> I also clean up some debug log, names and code style a little bit. >>>>>> >>>>>> The update could be confirmed with Tomcat and Firefox in private >>>>>> mode, as described in the bug description.? As this case happens >>>>>> only when psk_key_exchange_modes does not present, which is not a >>>>>> behavior supported by JDK, I did not find a workaround for a new >>>>>> regression test yet.? I added the labels, noreg-external and >>>>>> noreg-hard. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>> >>>>> I do not fully understand the situation, mostly because of >>>>> SSLEngine semantics.? In normal operation, does is >>>>> HandshakeStatus.FINISHED returned when Finished is received or >>>>> after the NewSessionTicket message? >>>> Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() >>>> of the finished handshake message.? However, for TLS 1.3, FINISHED >>>> will be returned any longer, because the finished handshake message >>>> is wrapped with certificate message in one record. >>>> >>>> For TLS 1.3: >>>> 1. client send certificate, certificate verify and finished >>>> handshake message in one record. >>>> 2. server call unwrap(), and return NEED_TASK to handle the >>>> certificate and certificate verify. >>>> >>>> So, no more FINISHED for the unwrap() return. >>>> >>>> It is fine if there is a after NewSessionTicket message.? The wrap() >>>> for the post-handshake message will return FINISHED. >>>> >>>> The bug reported is a special one that the Firefox is run in private >>>> mode, which does not request NewSessionTicket.? So there is no >>>> post-handshake generated and sent in server side.? Then, there is no >>>> FINISHED can be used if applications depends on it. >>>> >>>> To workaround the case, a dummy wrap() or unwrap() could be used to >>>> get the FINISHED.? The wrap() or unwrap() actually do nothing but >>>> return the FINISHED status. >>>> >>> >>> I don't want to be problematic, but I don't really agree with >>> creating dummy messages to generate wrap/unwrap operations in the TLS >>> code. >> No dummy message created.? Only need to call wrap() or unwrap(), but >> not data consumed or generated by the call to wrap() or unwrap(), no >> application data consumed, no network data consumed, no application >> data generated, no network data generated. >> >>> If SSLEngine is doing something wrong with not fully reading the >>> buffer, then I feel it's SSLEngine that should be fixed to handle the >>> situation right. >> It is not caused by SSLEngine that does not fully reading the buffer. >> Let me try again about what's the problem. >> >> The client (Firefox) sends, Certificate and CerticateVerify and >> Finished handshake messages in one record.? The record is encrypted. >> 1. One call to SSLEngine.unrwap() will read the record, and decrypt >> the record. >> 2. One call to SSLEngine.unwrap() cannot read the Certificate and >> CerticateVerify handshake message only, without reading the Finished >> handshake message.? It means the unwrap() method will consume the >> record data fully for all three handshake messages. >> 3. The Certificate and CerticateVerify should be handled in delegated >> tasks, so the call to SSLEngine.unwrap() return NEED_TASK. >> 4. As the SSLEngine.unwrap() return NEED_TASK, it cannot return the >> FINISHED status at the same time. >> 5. The FINISHED status is only be able to return with >> SSLEngine.unwrap() or SSLEngine.wrap(), and cannot returned from >> delegated tasks.? So the SSLEngine.getHandshakeStatus() after the >> tasks cannot be used to indicate the FINISHED status. >> 6. Then FINISHED status is missed, applications like Tomcat run into >> problem, like the bug described. >> >> That's the problem of the bug as far as I can see.? I agreed it is not >> good to have an additional wrap() or unwrap() that did nothing, but I >> have no better idea.? It would be nice if we could have a fix in JDK >> 15, considering the impact on Tomcat and Firefox.? I'm open if there >> is alternative solution or workaround. >> >> >>> Maybe not put the finished message or put all these messages together. >>> >>> Maybe Brad may know of a way out of this problem?? If creating a >>> dummy message is the only way to fix this, then I'm ok with it.? It >>> is just not a clean fix in my mind. >>> >>> >>>>> My understanding would have been after Finished because NST is >>>>> suppose to be a post handshake message.? So in this case there is >>>>> no problem, correct? >>>>> >>>> Correct. >>>> >>>>> I'm trying to figure out why you need an empty NST.? Is the problem >>>>> when a number of messages are bundled together.? For example, the >>>>> Finished message with a partial NST, then Finished isn't processed >>>>> and both sides are waiting?? Or do both sides continue normal >>>>> traffic, it's jut the HandshakeStatus.FINISHED is one operation >>>>> behind? >>>>> >>>> It should be fine as empty NST is just a signal to indicate the next >>>> call to wrap().? The next call to wrap() just use the signal for the >>>> return of FINISHED status, not network data produced, delivered or >>>> consumed. >>>> >>>>> >>>>> One code comment so far: >>>>> 433:? The debug message purpose was to say the NST is a stateless >>>>> ticket and not a preshared key.? Can we keep "stateless" in the >>>>> message? >>>>> >>>> NewSessionTicket.java?? Sure, I may just want to shrink to one line. >>>> It was not intended. >>> >>> shrinking the message is fine, it just needs to be clear which >>> message ticket type got sent. >>> >> Added back. >> >> Xuelei From xuelei.fan at oracle.com Fri May 29 16:54:14 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 29 May 2020 09:54:14 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> <94e98b03-bb05-1c6c-ec87-1dd5f788da2e@oracle.com> Message-ID: <9f956eea-1303-633e-62cd-7daba803c8af@oracle.com> On 5/29/2020 8:59 AM, Anthony Scarpino wrote: > Thanks for the changes Xuelei, it is much clearer to me now.? Two minor > things and a question. > > > NewSessionTicket:323.? The comment talks about an empty session ticket, > > SSLEngineImpl:167.? Comment uses old variable name > Oops, I still missed the two above. Updated in my local workspace. > One question, NewSessionTicket 464-470 and SSLEngineImpl.writeRecord() > 167-172 both set needHandshakeFinishedStatus false. If the NST code sets > needHandshakeFinishedStatus before the asynchronous call to > writeRecord(), couldn't that not change the status? Good question. I double checked that the session ticket delivery and writeRecord() are synchronized. The set and use of needHandshakeFinishedStatus are thread safe. > Would it be better > to only have the writeRecord() check? > The two block are used for different purpose. If the client support session ticket (psk_key_exchange_modes.psk_dhe_ke), the server will response with a session ticket in the last handshake wrap(). The wrap() method will return FINISHED status. For this case, as the FINISHED status could be caught, there is no need to have an additional wrap() to return the FINISHED handshake status any longer. The block in NewSessionTicket 464-470 is used to indicate the case. If the Firefox run in private mode, the psk_key_exchange_modes extension is not used, and the server will not response with session ticket. Then, the FINISHED status get missed if Certificate + CertificateVerify + Finished hanshake messages wrapped in one record. The block in SSLEngineImpl.writeRecord() 167-172 is used to handle this case. Thanks, Xuelei > thanks > Tony > > > On 5/27/20 8:44 PM, Xuelei Fan wrote: >> Tony and I had a private chat, and I understand his concerns better >> now. ??The name of the variable >> TransportContext.needEmptySessionTicket is confusing.? I updated it to >> "needHandshakeFinishedStatus" per the suggestion, together with other >> change according to the comments. >> >> Here is the new webrev: >> ??? http://cr.openjdk.java.net/~xuelei/8240871/webrev.01/ >> >> Thanks, >> Xuelei >> >> On 5/26/2020 2:40 PM, Xuelei Fan wrote: >>> On 5/26/2020 1:26 PM, Anthony Scarpino wrote: >>>> On 5/13/20 1:44 PM, Xuelei Fan wrote: >>>>> On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >>>>>> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Could I get the following update reviewed: >>>>>>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>>>>>> >>>>>>> For TLS 1.3 full handshake, if the last handshake flight wraps >>>>>>> the Finished together with other handshake message, for example >>>>>>> client certificate, the flight could be wrapped and encrypted in >>>>>>> one record and delegated tasks would be used.? There is no chance >>>>>>> to return FINISHED handshake status with SSLEngine.(un)wrap(). >>>>>>> However, per the HandshakeStatus.FINISHED specification, this >>>>>>> handshake status is only generated by a call to >>>>>>> SSLEngine.wrap()/unwrap() and it is never generated by >>>>>>> SSLEngine.getHandshakeStatus(). >>>>>>> >>>>>>> In order to workaround this case for TLS 1.3, the FINISHED status >>>>>>> could present with SSLEngine.wrap() while delivering of the >>>>>>> NewSessionTicket post-handshake message.? If this post-handshake >>>>>>> message is not needed, a follow-on SSLEngine.wrap() should be >>>>>>> called to indicate the FINISHED handshake status.? Although this >>>>>>> special SSLEngine.wrap() should not consume or produce any >>>>>>> application or network data. >>>>>>> >>>>>>> I also clean up some debug log, names and code style a little bit. >>>>>>> >>>>>>> The update could be confirmed with Tomcat and Firefox in private >>>>>>> mode, as described in the bug description.? As this case happens >>>>>>> only when psk_key_exchange_modes does not present, which is not a >>>>>>> behavior supported by JDK, I did not find a workaround for a new >>>>>>> regression test yet.? I added the labels, noreg-external and >>>>>>> noreg-hard. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>> >>>>>> I do not fully understand the situation, mostly because of >>>>>> SSLEngine semantics.? In normal operation, does is >>>>>> HandshakeStatus.FINISHED returned when Finished is received or >>>>>> after the NewSessionTicket message? >>>>> Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() >>>>> of the finished handshake message.? However, for TLS 1.3, FINISHED >>>>> will be returned any longer, because the finished handshake message >>>>> is wrapped with certificate message in one record. >>>>> >>>>> For TLS 1.3: >>>>> 1. client send certificate, certificate verify and finished >>>>> handshake message in one record. >>>>> 2. server call unwrap(), and return NEED_TASK to handle the >>>>> certificate and certificate verify. >>>>> >>>>> So, no more FINISHED for the unwrap() return. >>>>> >>>>> It is fine if there is a after NewSessionTicket message.? The >>>>> wrap() for the post-handshake message will return FINISHED. >>>>> >>>>> The bug reported is a special one that the Firefox is run in >>>>> private mode, which does not request NewSessionTicket.? So there is >>>>> no post-handshake generated and sent in server side.? Then, there >>>>> is no FINISHED can be used if applications depends on it. >>>>> >>>>> To workaround the case, a dummy wrap() or unwrap() could be used to >>>>> get the FINISHED.? The wrap() or unwrap() actually do nothing but >>>>> return the FINISHED status. >>>>> >>>> >>>> I don't want to be problematic, but I don't really agree with >>>> creating dummy messages to generate wrap/unwrap operations in the >>>> TLS code. >>> No dummy message created.? Only need to call wrap() or unwrap(), but >>> not data consumed or generated by the call to wrap() or unwrap(), no >>> application data consumed, no network data consumed, no application >>> data generated, no network data generated. >>> >>>> If SSLEngine is doing something wrong with not fully reading the >>>> buffer, then I feel it's SSLEngine that should be fixed to handle >>>> the situation right. >>> It is not caused by SSLEngine that does not fully reading the buffer. >>> Let me try again about what's the problem. >>> >>> The client (Firefox) sends, Certificate and CerticateVerify and >>> Finished handshake messages in one record.? The record is encrypted. >>> 1. One call to SSLEngine.unrwap() will read the record, and decrypt >>> the record. >>> 2. One call to SSLEngine.unwrap() cannot read the Certificate and >>> CerticateVerify handshake message only, without reading the Finished >>> handshake message.? It means the unwrap() method will consume the >>> record data fully for all three handshake messages. >>> 3. The Certificate and CerticateVerify should be handled in delegated >>> tasks, so the call to SSLEngine.unwrap() return NEED_TASK. >>> 4. As the SSLEngine.unwrap() return NEED_TASK, it cannot return the >>> FINISHED status at the same time. >>> 5. The FINISHED status is only be able to return with >>> SSLEngine.unwrap() or SSLEngine.wrap(), and cannot returned from >>> delegated tasks.? So the SSLEngine.getHandshakeStatus() after the >>> tasks cannot be used to indicate the FINISHED status. >>> 6. Then FINISHED status is missed, applications like Tomcat run into >>> problem, like the bug described. >>> >>> That's the problem of the bug as far as I can see.? I agreed it is >>> not good to have an additional wrap() or unwrap() that did nothing, >>> but I have no better idea.? It would be nice if we could have a fix >>> in JDK 15, considering the impact on Tomcat and Firefox.? I'm open if >>> there is alternative solution or workaround. >>> >>> >>>> Maybe not put the finished message or put all these messages together. >>>> >>>> Maybe Brad may know of a way out of this problem?? If creating a >>>> dummy message is the only way to fix this, then I'm ok with it.? It >>>> is just not a clean fix in my mind. >>>> >>>> >>>>>> My understanding would have been after Finished because NST is >>>>>> suppose to be a post handshake message.? So in this case there is >>>>>> no problem, correct? >>>>>> >>>>> Correct. >>>>> >>>>>> I'm trying to figure out why you need an empty NST.? Is the >>>>>> problem when a number of messages are bundled together.? For >>>>>> example, the Finished message with a partial NST, then Finished >>>>>> isn't processed and both sides are waiting?? Or do both sides >>>>>> continue normal traffic, it's jut the HandshakeStatus.FINISHED is >>>>>> one operation behind? >>>>>> >>>>> It should be fine as empty NST is just a signal to indicate the >>>>> next call to wrap().? The next call to wrap() just use the signal >>>>> for the return of FINISHED status, not network data produced, >>>>> delivered or consumed. >>>>> >>>>>> >>>>>> One code comment so far: >>>>>> 433:? The debug message purpose was to say the NST is a stateless >>>>>> ticket and not a preshared key.? Can we keep "stateless" in the >>>>>> message? >>>>>> >>>>> NewSessionTicket.java?? Sure, I may just want to shrink to one >>>>> line. It was not intended. >>>> >>>> shrinking the message is fine, it just needs to be clear which >>>> message ticket type got sent. >>>> >>> Added back. >>> >>> Xuelei > From anthony.scarpino at oracle.com Fri May 29 17:17:59 2020 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 29 May 2020 10:17:59 -0700 Subject: RFR JDK-8240871: SSLEngine handshake status immediately after the handshake can be NOT_HANDSHAKING rather than FINISHED with TLSv1.3 In-Reply-To: <9f956eea-1303-633e-62cd-7daba803c8af@oracle.com> References: <45679299-101e-45c6-ed51-232f9e4f94c8@oracle.com> <94e98b03-bb05-1c6c-ec87-1dd5f788da2e@oracle.com> <9f956eea-1303-633e-62cd-7daba803c8af@oracle.com> Message-ID: Ok thanks.. no further questions. Tony On 5/29/20 9:54 AM, Xuelei Fan wrote: > On 5/29/2020 8:59 AM, Anthony Scarpino wrote: >> Thanks for the changes Xuelei, it is much clearer to me now.? Two >> minor things and a question. >> >> >> NewSessionTicket:323.? The comment talks about an empty session ticket, >> >> SSLEngineImpl:167.? Comment uses old variable name >> > Oops, I still missed the two above.? Updated in my local workspace. > >> One question, NewSessionTicket 464-470 and SSLEngineImpl.writeRecord() >> 167-172 both set needHandshakeFinishedStatus false. If the NST code >> sets needHandshakeFinishedStatus before the asynchronous call to >> writeRecord(), couldn't that not change the status? > Good question.? I double checked that the session ticket delivery and > writeRecord() are synchronized.? The set and use of > needHandshakeFinishedStatus are thread safe. > >> Would it be better to only have the writeRecord() check? >> > The two block are used for different purpose. > > If the client support session ticket > (psk_key_exchange_modes.psk_dhe_ke), the server will response with a > session ticket in the last handshake wrap().? The wrap() method will > return FINISHED status.? For this case, as the FINISHED status could be > caught, there is no need to have an additional wrap()? to return the > FINISHED handshake status any longer. The block in NewSessionTicket > 464-470 is used to indicate the case. > > If the Firefox run in private mode, the psk_key_exchange_modes extension > is not used, and the server will not response with session ticket. Then, > the FINISHED status get missed if Certificate + CertificateVerify + > Finished hanshake messages wrapped in one record.? The block in > SSLEngineImpl.writeRecord() 167-172 is used to handle this case. > > Thanks, > Xuelei > >> thanks >> Tony >> >> >> On 5/27/20 8:44 PM, Xuelei Fan wrote: >>> Tony and I had a private chat, and I understand his concerns better >>> now. ??The name of the variable >>> TransportContext.needEmptySessionTicket is confusing.? I updated it >>> to "needHandshakeFinishedStatus" per the suggestion, together with >>> other change according to the comments. >>> >>> Here is the new webrev: >>> ??? http://cr.openjdk.java.net/~xuelei/8240871/webrev.01/ >>> >>> Thanks, >>> Xuelei >>> >>> On 5/26/2020 2:40 PM, Xuelei Fan wrote: >>>> On 5/26/2020 1:26 PM, Anthony Scarpino wrote: >>>>> On 5/13/20 1:44 PM, Xuelei Fan wrote: >>>>>> On 5/13/2020 9:41 AM, Anthony Scarpino wrote: >>>>>>> On 4/30/20 10:19 AM, Xuelei Fan wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Could I get the following update reviewed: >>>>>>>> ???? http://cr.openjdk.java.net/~xuelei/8240871/webrev.00/ >>>>>>>> >>>>>>>> For TLS 1.3 full handshake, if the last handshake flight wraps >>>>>>>> the Finished together with other handshake message, for example >>>>>>>> client certificate, the flight could be wrapped and encrypted in >>>>>>>> one record and delegated tasks would be used.? There is no >>>>>>>> chance to return FINISHED handshake status with >>>>>>>> SSLEngine.(un)wrap(). However, per the HandshakeStatus.FINISHED >>>>>>>> specification, this handshake status is only generated by a call >>>>>>>> to SSLEngine.wrap()/unwrap() and it is never generated by >>>>>>>> SSLEngine.getHandshakeStatus(). >>>>>>>> >>>>>>>> In order to workaround this case for TLS 1.3, the FINISHED >>>>>>>> status could present with SSLEngine.wrap() while delivering of >>>>>>>> the NewSessionTicket post-handshake message.? If this >>>>>>>> post-handshake message is not needed, a follow-on >>>>>>>> SSLEngine.wrap() should be called to indicate the FINISHED >>>>>>>> handshake status.? Although this special SSLEngine.wrap() should >>>>>>>> not consume or produce any application or network data. >>>>>>>> >>>>>>>> I also clean up some debug log, names and code style a little bit. >>>>>>>> >>>>>>>> The update could be confirmed with Tomcat and Firefox in private >>>>>>>> mode, as described in the bug description.? As this case happens >>>>>>>> only when psk_key_exchange_modes does not present, which is not >>>>>>>> a behavior supported by JDK, I did not find a workaround for a >>>>>>>> new regression test yet.? I added the labels, noreg-external and >>>>>>>> noreg-hard. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>> >>>>>>> I do not fully understand the situation, mostly because of >>>>>>> SSLEngine semantics.? In normal operation, does is >>>>>>> HandshakeStatus.FINISHED returned when Finished is received or >>>>>>> after the NewSessionTicket message? >>>>>> Not exactly.? For TLS 1.2, FINISHED will be returned with unwrap() >>>>>> of the finished handshake message.? However, for TLS 1.3, FINISHED >>>>>> will be returned any longer, because the finished handshake >>>>>> message is wrapped with certificate message in one record. >>>>>> >>>>>> For TLS 1.3: >>>>>> 1. client send certificate, certificate verify and finished >>>>>> handshake message in one record. >>>>>> 2. server call unwrap(), and return NEED_TASK to handle the >>>>>> certificate and certificate verify. >>>>>> >>>>>> So, no more FINISHED for the unwrap() return. >>>>>> >>>>>> It is fine if there is a after NewSessionTicket message.? The >>>>>> wrap() for the post-handshake message will return FINISHED. >>>>>> >>>>>> The bug reported is a special one that the Firefox is run in >>>>>> private mode, which does not request NewSessionTicket.? So there >>>>>> is no post-handshake generated and sent in server side.? Then, >>>>>> there is no FINISHED can be used if applications depends on it. >>>>>> >>>>>> To workaround the case, a dummy wrap() or unwrap() could be used >>>>>> to get the FINISHED.? The wrap() or unwrap() actually do nothing >>>>>> but return the FINISHED status. >>>>>> >>>>> >>>>> I don't want to be problematic, but I don't really agree with >>>>> creating dummy messages to generate wrap/unwrap operations in the >>>>> TLS code. >>>> No dummy message created.? Only need to call wrap() or unwrap(), but >>>> not data consumed or generated by the call to wrap() or unwrap(), no >>>> application data consumed, no network data consumed, no application >>>> data generated, no network data generated. >>>> >>>>> If SSLEngine is doing something wrong with not fully reading the >>>>> buffer, then I feel it's SSLEngine that should be fixed to handle >>>>> the situation right. >>>> It is not caused by SSLEngine that does not fully reading the >>>> buffer. Let me try again about what's the problem. >>>> >>>> The client (Firefox) sends, Certificate and CerticateVerify and >>>> Finished handshake messages in one record.? The record is encrypted. >>>> 1. One call to SSLEngine.unrwap() will read the record, and decrypt >>>> the record. >>>> 2. One call to SSLEngine.unwrap() cannot read the Certificate and >>>> CerticateVerify handshake message only, without reading the Finished >>>> handshake message.? It means the unwrap() method will consume the >>>> record data fully for all three handshake messages. >>>> 3. The Certificate and CerticateVerify should be handled in >>>> delegated tasks, so the call to SSLEngine.unwrap() return NEED_TASK. >>>> 4. As the SSLEngine.unwrap() return NEED_TASK, it cannot return the >>>> FINISHED status at the same time. >>>> 5. The FINISHED status is only be able to return with >>>> SSLEngine.unwrap() or SSLEngine.wrap(), and cannot returned from >>>> delegated tasks.? So the SSLEngine.getHandshakeStatus() after the >>>> tasks cannot be used to indicate the FINISHED status. >>>> 6. Then FINISHED status is missed, applications like Tomcat run into >>>> problem, like the bug described. >>>> >>>> That's the problem of the bug as far as I can see.? I agreed it is >>>> not good to have an additional wrap() or unwrap() that did nothing, >>>> but I have no better idea.? It would be nice if we could have a fix >>>> in JDK 15, considering the impact on Tomcat and Firefox.? I'm open >>>> if there is alternative solution or workaround. >>>> >>>> >>>>> Maybe not put the finished message or put all these messages together. >>>>> >>>>> Maybe Brad may know of a way out of this problem?? If creating a >>>>> dummy message is the only way to fix this, then I'm ok with it.? It >>>>> is just not a clean fix in my mind. >>>>> >>>>> >>>>>>> My understanding would have been after Finished because NST is >>>>>>> suppose to be a post handshake message.? So in this case there is >>>>>>> no problem, correct? >>>>>>> >>>>>> Correct. >>>>>> >>>>>>> I'm trying to figure out why you need an empty NST.? Is the >>>>>>> problem when a number of messages are bundled together.? For >>>>>>> example, the Finished message with a partial NST, then Finished >>>>>>> isn't processed and both sides are waiting?? Or do both sides >>>>>>> continue normal traffic, it's jut the HandshakeStatus.FINISHED is >>>>>>> one operation behind? >>>>>>> >>>>>> It should be fine as empty NST is just a signal to indicate the >>>>>> next call to wrap().? The next call to wrap() just use the signal >>>>>> for the return of FINISHED status, not network data produced, >>>>>> delivered or consumed. >>>>>> >>>>>>> >>>>>>> One code comment so far: >>>>>>> 433:? The debug message purpose was to say the NST is a stateless >>>>>>> ticket and not a preshared key.? Can we keep "stateless" in the >>>>>>> message? >>>>>>> >>>>>> NewSessionTicket.java?? Sure, I may just want to shrink to one >>>>>> line. It was not intended. >>>>> >>>>> shrinking the message is fine, it just needs to be clear which >>>>> message ticket type got sent. >>>>> >>>> Added back. >>>> >>>> Xuelei >> From sean.mullan at oracle.com Fri May 29 19:32:18 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 29 May 2020 15:32:18 -0400 Subject: RFR 8242068: Signed JAR support for RSASSA-PSS and EdDSA In-Reply-To: References: <1f29a11a-40de-2e56-7524-1323d0ed326d@oracle.com> <95519263-3ED3-4D80-AB30-80A86ECAA611@oracle.com> Message-ID: <6d2f9950-5306-b4a9-d62e-688bbac2f989@oracle.com> On 5/23/20 4:21 AM, Weijun Wang wrote: > CSR updated at https://bugs.openjdk.java.net/browse/JDK-8245274 with the full patch on docs. Good to remove all of the DSA references :) I had a few comments, mostly wording suggestions: - In the Problem section, you should add references to the RFCs. - Solution section: RSASSA-RSS and EdDSA keys can be used to signed a JAR file typo: signed/signed - Comments on the Specification section: Some of this wording where you discuss what is going to be done in jarsigner and the tool doc seems more like it belongs in the Solution section, but it may be ok either way (not sure, I guess Joe will let you know if it is an issue). +RSASSA-PSS \<= 3072 RSASSA-PSS using SHA-256 + \<= 7680 RSASSA-PSS using SHA-384 + \> 7680 RSASSA-PSS using SHA-512 It might be better to be more specific, for example "RSASSA-PSS with the SHA-256 message digest algorithm" I used the term "with" as that is the word we use in the standard signature algorithm strings. +pair using `-keyalg EdDSA`, user can specify `-keysize 255` or `-keysize 448` s/user/a user/ +Ed25519 key pair is generated. User can also directly specifies `-keyalg Ed25519` s/User/A user/ s/specifies/specify/ + By default, the `jarsigner` command signs a JAR file using one of the following + algorithms files depending on the type and size of the private key: Not your changes, but there is a grammar error above. I would also mention block files, since you have added it to the table, so how about: "By default, the `jarsigner` command signs a JAR file using the following algorithms and block file extension depending on the type and size of the private key:" +will use a new `PSSParameterSpec` parameters that is determined by the key's s/a new/new/ +for keysize \<= 3072 bits, use a `PSSParameterSpec` with SHA-256 as the hash s/use a `PSSParameterSpec`/a `PSSParameterSpec` will be used/ +and MGF1 algorithms; for keysize \<= 7680 bits, use SHA-384; for +keysize \>= 7680 bits, use SHA-512. s/use SHA-384/SHA-384 will be used/ s/use SHA-512/SHA-512 will be used/ --Sean From valerie.peng at oracle.com Fri May 29 21:07:03 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 29 May 2020 14:07:03 -0700 Subject: [15] RFR JDK-8242897 KeyFactory.generatePublic( x509Spec ) failed with java.security.InvalidKeyException In-Reply-To: <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> References: <73f67be4-9e09-00da-5a87-b2fa4f99bc91@oracle.com> <72eb4030-4a15-3683-fb37-b66e038b5c43@oracle.com> Message-ID: Re-worked the fix a bit to take in Max's feedback: Webrev updated athttp://cr.openjdk.java.net/~valeriep/8242897/webrev.01/ Instead of completely reverting to the pre-PSS behavior of ignoring the OID in the DER encoding, this updated webrev has special handling to work with the scenario in the bug report. Most changes are code refactoring driven by the argument type change... Thanks, Valerie On 5/7/2020 4:17 PM, Valerie Peng wrote: > Ping? > > On 4/23/2020 3:28 PM, Valerie Peng wrote: >> Anyone has time to help review this fix? After the support for >> RSASSA-PSS keys is added, when parsing the DER encoding, the key >> algorithm is based on the parsed algorithm oid/name. However, an >> exception is thrown if the parsed algorithm oid/name is neither RSA >> nor RSASSA-PSS. For this particular report, the algorithm oid is >> 1.3.14.3.2.15 which is unsupport/unrecognized by JDK. In earlier >> releases, the bytes are parsed but key algorithm is always "RSA". >> >> To maintain this backward compatibility behavior, I changed the >> current impl to set the key algorithm upon key construction time w/ a >> KeyType argument (RSA or RSASSA-PSS) even when DER encoding is given. >> After parsing the DER encoding, for non-RSA keys, the parsed >> algorithm oid/name should match the given key type, otherwise an >> exception is thrown. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8242897 >> >> Webrev: http://cr.openjdk.java.net/~valeriep/8242897/webrev.00/ >> >> Mach5 run is clean. >> >> Thanks, >> Valerie From weijun.wang at oracle.com Sat May 30 11:54:47 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 30 May 2020 19:54:47 +0800 Subject: RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ Message-ID: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8246193/webrev.00/ While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible there is no PA-DATA at all. This could happen when preauth is turned off. Thanks, Max From weijun.wang at oracle.com Sat May 30 16:57:38 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 31 May 2020 00:57:38 +0800 Subject: [RFR] 8243424: Signature and SignatureSpi get parameter methods may throw null when unsupported In-Reply-To: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> References: <7f527c40-eb1f-6310-b82e-7de5be287a71@oracle.com> Message-ID: <3BE6EAC1-1453-40DD-8A90-F636AB6B64E0@oracle.com> I wish AlgorithmParameters was actually AlgorithmIdentifier which is OID+params, but it's too late. Sigh. --Max > On May 28, 2020, at 4:22 AM, Anthony Scarpino wrote: > > Hi, > > I need a javadoc review for a Signature/SignatureSpi parameters change that is needed to the spec, which affects EdDSA. The existing spec was very strict in the way set and get parameters were handled. This modifies that slightly by allowing null to be returned by the get methods when it is unsupported after the parameters have been set. Since null was an allowed return value, this minimizes the backwards compatibility chances. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8243425 > webrev: https://cr.openjdk.java.net/~ascarpino/8243424/webrev/ > > Tony From mbalao at redhat.com Sun May 31 00:34:22 2020 From: mbalao at redhat.com (Martin Balao) Date: Sat, 30 May 2020 21:34:22 -0300 Subject: RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ In-Reply-To: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> References: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> Message-ID: On 5/30/20 8:54 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8246193/webrev.00/ > > While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible there is no PA-DATA at all. This could happen when preauth is turned off. > I'm not a JDK main line reviewer BUT I've analyzed this problem and the fix looks good to me. Regards, Martin.- From xuelei.fan at oracle.com Sun May 31 02:03:41 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 30 May 2020 19:03:41 -0700 Subject: RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ In-Reply-To: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> References: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> Message-ID: <2dfacab3-2f61-0d75-3c6e-4ee1422af535@oracle.com> Looks good to me. You may also want to update the copyright date in KDC.java. Xuelei On 5/30/2020 4:54 AM, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8246193/webrev.00/ > > While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible there is no PA-DATA at all. This could happen when preauth is turned off. > > Thanks, > Max > From weijun.wang at oracle.com Sun May 31 02:13:51 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 31 May 2020 10:13:51 +0800 Subject: RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ In-Reply-To: <2dfacab3-2f61-0d75-3c6e-4ee1422af535@oracle.com> References: <7A029511-2D27-4342-9848-D58D82A08A0C@oracle.com> <2dfacab3-2f61-0d75-3c6e-4ee1422af535@oracle.com> Message-ID: Thanks. Updated and pushed. --Max > On May 31, 2020, at 10:03 AM, Xuelei Fan wrote: > > Looks good to me. You may also want to update the copyright date in KDC.java. > > Xuelei > > On 5/30/2020 4:54 AM, Weijun Wang wrote: >> Please take a review at >> http://cr.openjdk.java.net/~weijun/8246193/webrev.00/ >> While searching for ENC-PA-REP in the PA-DATA list of AS-REQ, it's possible there is no PA-DATA at all. This could happen when preauth is turned off. >> Thanks, >> Max