From 1983-01-06 at gmx.net  Sun Dec  1 13:37:20 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Sun, 1 Dec 2019 14:37:20 +0100
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
Message-ID: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>

Hi folks,

I am one of the Apache HttpComponents committers and we get these nags
once in a while:

-
https://github.com/apache/httpcomponents-client/pull/178#discussion_r351492056
- https://issues.apache.org/jira/browse/HTTPCLIENT-2032
- https://stackoverflow.com/q/56306216/696632

It all boils down to that IOExceptions are not thrown as-is after the
introduction of TLS 1.3 in Java 11, but now wrapped in SSLExceptions
(partially fixed by JDK-8214339). This is counterproductive.

Questions:

* Why has this change been made?
* Why has the incompatible change not properly communicated to the
users/community?
* Can this be restored back to Java 8 behavior for 15 (14 not likely?!)
and 11u?

Looking into [1] the following requirements have been broken:
>   - Verify that the implementation does not break backward compatibility in unexpected ways.
>   - Verify that the implementation does not introduce any unexpected interoperability issues.

@Rory, can you engage also with Apache HttpComponents? We are not happy
with the situation.
I see your mails on other MLs like Maven and Tomcat where I commit too.

Regards,

Michael

[1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252

From anthony.scarpino at oracle.com  Mon Dec  2 03:32:00 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Sun, 1 Dec 2019 19:32:00 -0800
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <31E382BA-9BD6-416C-8483-1226ED848202@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
 <31E382BA-9BD6-416C-8483-1226ED848202@oracle.com>
Message-ID: <4aef65a5-5dc2-cb50-7d0a-a2f7d14af662@oracle.com>

On 11/27/19 5:26 PM, Weijun Wang wrote:
> In ConstraintsParameters.java:
> 
> You added curveStr assignment in the ConstraintsParameters(X509Certificate,...). Is it also necessary to do the same in the next constructor ConstraintsParameters(...,Key,...)? You can get curve name from the key.

I do not believe it is necessary because the algorithm, such as EC or 
AES, checks the key length . Also named curves do not have variable key 
lengths that I know of

Tony

> 
> Also, now that a key has a parameter that needs to checked, in the following public method in DisabledAlgorithmConstraints.java
> 
> public boolean permits(Key key) {
>      List<Constraint> list = getConstraints(key.getAlgorithm());
>      if (list == null) {
>          return true;
>      }
>      for (Constraint constraint : list) {
>          if (!constraint.permits(key)) {
>              if (debug != null) {
>                  debug.println("Constraints: failed key size" +
>                          "constraint check " + KeyUtil.getKeySize(key));
>              }
>              return false;
>          }
>      }
>      return true;
> }
> 
> should getConstraints() be called on both the algorithm name and the group name?
> 
> Thanks,
> Max
> 
> 
> 
>> On Nov 20, 2019, at 3:44 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>> I need a review of a disabled algorithms code change that allows EC curve names to be disabled for all the disabledAlgorithm properties.
>>
>> https://cr.openjdk.java.net/~ascarpino/8233228/webrev/
>>
>> Tony
> 
f

From weijun.wang at oracle.com  Mon Dec  2 05:16:51 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 2 Dec 2019 13:16:51 +0800
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <4aef65a5-5dc2-cb50-7d0a-a2f7d14af662@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
 <31E382BA-9BD6-416C-8483-1226ED848202@oracle.com>
 <4aef65a5-5dc2-cb50-7d0a-a2f7d14af662@oracle.com>
Message-ID: <350EEB3B-AB9C-40AD-996D-67241DD27D13@oracle.com>



> On Dec 2, 2019, at 11:32 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> On 11/27/19 5:26 PM, Weijun Wang wrote:
>> In ConstraintsParameters.java:
>> You added curveStr assignment in the ConstraintsParameters(X509Certificate,...). Is it also necessary to do the same in the next constructor ConstraintsParameters(...,Key,...)? You can get curve name from the key.
> 
> I do not believe it is necessary because the algorithm, such as EC or AES, checks the key length .

But a key can be disabled both with its length and group name.

> Also named curves do not have variable key lengths that I know of

Yes, that's right.

--Max

> 
> Tony
> 
>> Also, now that a key has a parameter that needs to checked, in the following public method in DisabledAlgorithmConstraints.java
>> public boolean permits(Key key) {
>>     List<Constraint> list = getConstraints(key.getAlgorithm());
>>     if (list == null) {
>>         return true;
>>     }
>>     for (Constraint constraint : list) {
>>         if (!constraint.permits(key)) {
>>             if (debug != null) {
>>                 debug.println("Constraints: failed key size" +
>>                         "constraint check " + KeyUtil.getKeySize(key));
>>             }
>>             return false;
>>         }
>>     }
>>     return true;
>> }
>> should getConstraints() be called on both the algorithm name and the group name?
>> Thanks,
>> Max
>>> On Nov 20, 2019, at 3:44 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>> 
>>> I need a review of a disabled algorithms code change that allows EC curve names to be disabled for all the disabledAlgorithm properties.
>>> 
>>> https://cr.openjdk.java.net/~ascarpino/8233228/webrev/
>>> 
>>> Tony
> f


From sean.mullan at oracle.com  Mon Dec  2 13:36:45 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 2 Dec 2019 08:36:45 -0500
Subject: RFR 8234744: KeyStore.store can write wrong type of file
In-Reply-To: <62A0FA86-31E2-489B-9C7D-708B18F19203@oracle.com>
References: <62A0FA86-31E2-489B-9C7D-708B18F19203@oracle.com>
Message-ID: <1e50a434-f145-1f37-9b55-6042a4a30d3d@oracle.com>

Looks fine.

--Sean

On 11/28/19 4:28 AM, Weijun Wang wrote:
> Please review the change at
> 
>     https://cr.openjdk.java.net/~weijun/8234744/webrev.00
> 
> A mach5 test on tier1,tier2 is ongoing.
> 
> Thanks,
> Max
> 

From xuelei.fan at oracle.com  Mon Dec  2 15:36:46 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 2 Dec 2019 07:36:46 -0800
Subject: RFR [14] JDK-8235183, Remove the "HACK CODE" in comment
Message-ID: <ffb5850a-40e0-bcc9-b92c-d528ebe4850f@oracle.com>

Hi,

Could I get the following update reviewed?
    http://cr.openjdk.java.net/~xuelei/8235183/webrev.00/

There are some comments in the SunJSSE implementation that come with 
"HACK CODE". Which are not really bad code. They are just used to mark 
unusual scenarios in case the block get removed in the future. However, 
"HACK" may have negative impression for some code readers. It would be 
nice to remove the "HACK CODE" and use some other words to mark the 
unusual scenarios.

Thanks,
Xuelei

From jamil.j.nimeh at oracle.com  Mon Dec  2 18:21:26 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 02 Dec 2019 10:21:26 -0800
Subject: RFR [14] JDK-8235183, Remove the "HACK CODE" in comment
In-Reply-To: <ffb5850a-40e0-bcc9-b92c-d528ebe4850f@oracle.com>
Message-ID: <201912021821.xB2ILVlw012147@userv0121.oracle.com>

Looks fine to me.--Jamil
-------- Original message --------From: Xuelei Fan <xuelei.fan at oracle.com> Date: 12/2/19  7:36 AM  (GMT-08:00) To: security-dev at openjdk.java.net Subject: RFR [14] JDK-8235183, Remove the "HACK CODE" in comment Hi,Could I get the following update reviewed???? http://cr.openjdk.java.net/~xuelei/8235183/webrev.00/There are some comments in the SunJSSE implementation that come with "HACK CODE". Which are not really bad code. They are just used to mark unusual scenarios in case the block get removed in the future. However, "HACK" may have negative impression for some code readers. It would be nice to remove the "HACK CODE" and use some other words to mark the unusual scenarios.Thanks,Xuelei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191202/f4487871/attachment.html>

From xuelei.fan at oracle.com  Mon Dec  2 18:34:42 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 2 Dec 2019 10:34:42 -0800
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
Message-ID: <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>

Hi,

Could someone please help to verify if the attached patch (JDK 14) works 
HttpComponents?

Thanks & Regards,
Xuelei

On 12/1/2019 5:37 AM, Michael Osipov wrote:
> Hi folks,
> 
> I am one of the Apache HttpComponents committers and we get these nags
> once in a while:
> 
> -
> https://github.com/apache/httpcomponents-client/pull/178#discussion_r351492056 
> 
> - https://issues.apache.org/jira/browse/HTTPCLIENT-2032
> - https://stackoverflow.com/q/56306216/696632
> 
> It all boils down to that IOExceptions are not thrown as-is after the
> introduction of TLS 1.3 in Java 11, but now wrapped in SSLExceptions
> (partially fixed by JDK-8214339). This is counterproductive.
> 
> Questions:
> 
> * Why has this change been made?
> * Why has the incompatible change not properly communicated to the
> users/community?
> * Can this be restored back to Java 8 behavior for 15 (14 not likely?!)
> and 11u?
> 
> Looking into [1] the following requirements have been broken:
>> ? - Verify that the implementation does not break backward 
>> compatibility in unexpected ways.
>> ? - Verify that the implementation does not introduce any unexpected 
>> interoperability issues.
> 
> @Rory, can you engage also with Apache HttpComponents? We are not happy
> with the situation.
> I see your mails on other MLs like Maven and Tomcat where I commit too.
> 
> Regards,
> 
> Michael
> 
> [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252
-------------- next part --------------
diff -r 2baa1f8721b8 src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
--- a/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java	Mon Dec 02 18:52:18 2019 +0100
+++ b/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java	Mon Dec 02 10:32:32 2019 -0800
@@ -1254,8 +1254,11 @@
             } catch (SSLHandshakeException she) {
                 // may be record sequence number overflow
                 throw conContext.fatal(Alert.HANDSHAKE_FAILURE, she);
-            } catch (IOException e) {
+            } catch (SSLException ssle) {
                 throw conContext.fatal(Alert.UNEXPECTED_MESSAGE, e);
+            }   // re-throw other IOException, which should be caused by
+                // the underlying plain socket and could be handled by
+                // applications (for example, re-try the connection).
             }
 
             // Is the sequence number is nearly overflow, or has the key usage

From 1983-01-06 at gmx.net  Mon Dec  2 19:13:34 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Mon, 2 Dec 2019 20:13:34 +0100
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
 <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
Message-ID: <f83bb236-9f11-60f1-4c43-4240a1b6019f@gmx.net>

Am 2019-12-02 um 19:34 schrieb Xuelei Fan:
> Hi,
>
> Could someone please help to verify if the attached patch (JDK 14) works
> HttpComponents?

Requested a review of the patch and will try myself.
I see also other spots where IOException is wrapped inside an SSLException:

*
https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java#L1069-L1071
*
https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java#L404-L406
*
https://github.com/AdoptOpenJDK/openjdk-jdk11u/blob/master/src/java.base/share/classes/sun/security/ssl/Alert.java#L125-L127

Michael

From simone.bordet at gmail.com  Mon Dec  2 20:46:48 2019
From: simone.bordet at gmail.com (Simone Bordet)
Date: Mon, 2 Dec 2019 21:46:48 +0100
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
 <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
Message-ID: <CAFWmRJ1rPLZSWSaxqMpE-USu_sYOqZaXkma+o50u538n0vZZ-Q@mail.gmail.com>

Hi,

On Mon, Dec 2, 2019 at 7:36 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:
>
> Hi,
>
> Could someone please help to verify if the attached patch (JDK 14) works
> HttpComponents?

I'm not sure I see the difference between a generic IOException and
SSLHandshakeException.

If a client is connecting to a busy proxy that sends a TLS
close_notify to the client, that would be a SSLHandshakeException even
though it may be actually possible to retry and get a successful
connection and TLS handshake.
On the other hand, if a busy proxy sends a FIN to the client, that
would be an IOException that may or not succeed when retried.
Or the server is running out of file descriptors, very likely will be
reported as an IOException, but retrying won't help.
Or the client is running out of file descriptors.
Or the client cannot connect to the server (again, a retry may or may
not be successful).

Bottom line is that for both cases (IOException and
SSLHandshakeException) a retry may be successful and as such client
code will have a hard time to detect when or not to retry in either
case.

SSLException (and subclasses) do not report the TLS AlertDescription
code, so it won't be possible to know the exact reason for the
SSLHandshakeException, and from it decide whether it's retryable or
not.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From rory.odonnell at oracle.com  Mon Dec  2 08:37:44 2019
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 2 Dec 2019 08:37:44 +0000
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
Message-ID: <74e49905-e48b-87b1-6536-47af1d40131a@oracle.com>


On 01/12/2019 13:37, Michael Osipov wrote:
> Hi folks,
>
> I am one of the Apache HttpComponents committers and we get these nags
> once in a while:
>
> -
> https://github.com/apache/httpcomponents-client/pull/178#discussion_r351492056 
>
> - https://issues.apache.org/jira/browse/HTTPCLIENT-2032
> - https://stackoverflow.com/q/56306216/696632
>
> It all boils down to that IOExceptions are not thrown as-is after the
> introduction of TLS 1.3 in Java 11, but now wrapped in SSLExceptions
> (partially fixed by JDK-8214339). This is counterproductive.
>
> Questions:
>
> * Why has this change been made?
> * Why has the incompatible change not properly communicated to the
> users/community?
> * Can this be restored back to Java 8 behavior for 15 (14 not likely?!)
> and 11u?
>
> Looking into [1] the following requirements have been broken:
>> ? - Verify that the implementation does not break backward 
>> compatibility in unexpected ways.
>> ? - Verify that the implementation does not introduce any unexpected 
>> interoperability issues.
>
> @Rory, can you engage also with Apache HttpComponents? We are not happy
> with the situation.
> I see your mails on other MLs like Maven and Tomcat where I commit too.

Hi Michel, we communicate directly with one of the chairpersons, I'll 
pass on your findings.

Rgds,Rory

>
> Regards,
>
> Michael
>
> [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252

-- 
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland


From martin.doerr at sap.com  Mon Dec  2 15:12:58 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 2 Dec 2019 15:12:58 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
Message-ID: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack?
Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191202/70b24a2d/attachment.html>

From hubert.debordeaux at thalesgroup.com  Mon Dec  2 16:50:51 2019
From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert)
Date: Mon, 2 Dec 2019 16:50:51 +0000
Subject: SunPKCS11 connection lost after Decrypt doFinal (noPadding) openjdk
 8_232
Message-ID: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>

Hello,
Following the update to OpenJDK 8_232, we did face a problem after a DECRYPT with no padding.
We use a SunPKCS11 provider linked to a Network HSM.
After a DECRYPT command (DES or AES) NOPADDING, we noticed the log : "Killing session (sun.security.pkcs11.P11Cipher.cancelOperation(P11Cipher.java:428)) active: 1"
All following commands failed with error : CKR_USER_NOT_LOGGED_IN

After a quick investigation, it looks like the fix JDK-8228565 done in P11Cipher.java is the root cause of this new behavior.
	....
	// Special handling to match SunJCE provider behavior
                if (bytesBuffered == 0 && padBufferLen == 0) {
                    return 0;
                }
	....
	} finally {
            		reset(doCancel);   // doCancel is true, so killSession is called.
        	}

This is a source code to reproduce the problem:
	SunPKCS11 p = new SunPKCS11(configName);           // config to Network HSM    
	p.setCallbackHandler(handler);    // Handler for password
        	Security.addProvider(p);
        
        	KeyStore.CallbackHandlerProtection chp =
                	new KeyStore.CallbackHandlerProtection(handler);
            	KeyStore.Builder builder = KeyStore.Builder.newInstance("PKCS11", p, chp);          
        	KeyStore keystore = builder.getKeyStore();
       	SecretKeyEntry entry = (SecretKeyEntry) keystore.getEntry("MyKeyAlias", null);         
        
        	Cipher cipher = Cipher.getInstance("DESede/CBC/NOPADDING", p.getName());                
        	IvParameterSpec ivParameterSpec = new IvParameterSpec(new byte[8]);  
        	// cipher a text
        	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
        	byte[] clearData = "clear text111111".getBytes();
        	byte[] cipheredData = cipher.doFinal(clearData);
           	// Decipher the result
        	cipher.init(Cipher.DECRYPT_MODE, entry.getSecretKey(), ivParameterSpec);         
        	byte[] clearTextResult = cipher.doFinal(cipheredData);
	// display the result        
	System.out.println(new String(clearTextResult));  // So far, no problem
        
              // Try another cipher
        	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
	byte[] clearData2 = "clear text222222".getBytes();
       	byte[] cipheredData2 = cipher.doFinal(clearData);
	// --> Failed with sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN

Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
	at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
	at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:581)

        
Workarounds:
	. use the SunPkcs11 jar file from openJDK 8_222
	. add a login after every decrypt commands
	. use PKCS5Padding when possible

Could you tell me if you can reproduce this problem and what is the best way for me to report it ?

Thanks you
Best Regards,
Hubert
 

From valerie.peng at oracle.com  Tue Dec  3 00:40:38 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 2 Dec 2019 16:40:38 -0800
Subject: 8216012: Infinite loop in RSA KeyPairGenerator
In-Reply-To: <OSBPR01MB167189BBBB394FF2C4FC5D1CE7950@OSBPR01MB1671.jpnprd01.prod.outlook.com>
References: <OSBPR01MB167189BBBB394FF2C4FC5D1CE7950@OSBPR01MB1671.jpnprd01.prod.outlook.com>
Message-ID: <1a312490-6f9a-9dc8-d5b3-8764623328e4@oracle.com>

Hi Masanori Yano,

I can help sponsoring this fix. However, as it's a P4, it may be  
targeted to 15 depending on the available cycles.

Are you a contributor for OpenJDK?

If not, please see http://openjdk.java.net/contribute/ for the process.

Thanks,
Valerie
On 10/8/2019 8:10 PM, yano-masanori at fujitsu.com wrote:
> Hello.
>
> I would like to contribute for JDK-8216012.
>
> The cause of this problem is RSAKeyPairGenerator that doesn't check
> the public exponent even though the algorithm of rsa key generation
> can use only odd exponent number.
>
> To generate a KeyPair, the RSAKeyPairGenerator finds two random primes
> P and Q, and calculate Phi = (P - 1) * (Q - 1). If Phi is not relative
> prime to exponent, RSAKeyPairGenerator retry from the first.
>
> The value of Phi must be an even number because P and Q are odd numbers.
> If exponent is an even number, the greatest common divisor cannot
> be 1 because one of common divisors is 2 which is bigger than 1.
> Therefore, generateKeyPair() method of RSAKeyPairGenerator cannot exit
> the retrying loop.
>
> To solve this problem, I propose to check whether the public exponent
> is even number.
>
> Please sponsor the following change.
>
> diff --git a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
> --- a/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
> +++ b/src/java.base/share/classes/sun/security/rsa/RSAKeyPairGenerator.java
> @@ -96,6 +96,10 @@
>                   throw new InvalidAlgorithmParameterException
>                           ("Public exponent must be 3 or larger");
>               }
> +            if (!tmpPublicExponent.testBit(0)) {
> +                throw new InvalidAlgorithmParameterException
> +                        ("Public exponent must be an odd number");
> +            }
>               if (tmpPublicExponent.bitLength() > tmpKeySize) {
>                   throw new InvalidAlgorithmParameterException
>                           ("Public exponent must be smaller than key size");
> diff --git a/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java
> new file mode 100644
> --- /dev/null
> +++ b/test/jdk/sun/security/rsa/TestKeyPairGeneratorExponent.java
> @@ -0,0 +1,65 @@
> +import java.math.BigInteger;
> +
> +import java.security.*;
> +import java.security.interfaces.*;
> +import java.security.spec.*;
> +
> +/**
> + * @test
> + * @bug 8216012
> + * @summary Tests the RSA public key exponent for KeyPairGenerator
> + * @run main/timeout=60 TestKeyPairGeneratorExponent
> + */
> +public class TestKeyPairGeneratorExponent {
> +    private static int keyLen = 512;
> +
> +    private static BigInteger[] validExponents = new BigInteger[] {
> +        RSAKeyGenParameterSpec.F0,
> +        RSAKeyGenParameterSpec.F4,
> +        // Since 512-bit exponent is larger than  modulus, fails in RSAPublicKeyImpl.checkExponentRange().
> +        BigInteger.ONE.shiftLeft(keyLen - 1).subtract(BigInteger.ONE)
> +    };
> +
> +    private static BigInteger[] invalidExponents = new BigInteger[] {
> +        BigInteger.valueOf(-1),
> +        BigInteger.ZERO,
> +        BigInteger.ONE,
> +        // 8216012: An even number causes infinite loop.
> +        BigInteger.valueOf(4),
> +        BigInteger.ONE.shiftLeft(keyLen)
> +    };
> +
> +    public static void testValidExponents(KeyPairGenerator kpg, BigInteger exponent) {
> +        try {
> +            kpg.initialize(new RSAKeyGenParameterSpec(keyLen, exponent));
> +            kpg.generateKeyPair();
> +        } catch(InvalidAlgorithmParameterException iape){
> +            throw new RuntimeException("Unexpected Exception: " + iape);
> +        }
> +    }
> +
> +    public static void testInvalidExponents(KeyPairGenerator kpg, BigInteger exponent) {
> +        try {
> +            kpg.initialize(new RSAKeyGenParameterSpec(keyLen, exponent));
> +            kpg.generateKeyPair();
> +            throw new RuntimeException("Expected InvalidAlgorithmParameterException was not thrown.");
> +        } catch(InvalidAlgorithmParameterException iape){
> +            // Expected InvalidAlgorithmParameterException was thrown.OK
> +        }
> +    }
> +
> +    public static void main(String[] args) throws Exception {
> +        Provider provider = Security.getProvider("SunRsaSign");
> +        KeyPairGenerator kpg;
> +
> +        for(BigInteger validExponent : validExponents) {
> +            kpg = KeyPairGenerator.getInstance("RSA", provider);
> +            testValidExponents(kpg, validExponent);
> +        }
> +
> +        for(BigInteger invalidExponent : invalidExponents) {
> +            kpg = KeyPairGenerator.getInstance("RSA", provider);
> +            testInvalidExponents(kpg, invalidExponent);
> +        }
> +    }
> +}
>
> Regards,
> Masanori Yano

From valerie.peng at oracle.com  Tue Dec  3 00:56:52 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 2 Dec 2019 16:56:52 -0800
Subject: SunPKCS11 connection lost after Decrypt doFinal (noPadding)
 openjdk 8_232
In-Reply-To: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>
References: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>

Hi Hubert,

I've filed https://bugs.openjdk.java.net/browse/JDK-8235215 to keep 
track of this issue.

I have not yet tried if this can be reproduced in house with NSS yet.

Just curious, which HSM vendor did you use? It'd be helpful to include 
in the bug report.

Thanks,
Valerie
On 12/2/2019 8:50 AM, DEBORDEAUX Hubert wrote:
> Hello,
> Following the update to OpenJDK 8_232, we did face a problem after a DECRYPT with no padding.
> We use a SunPKCS11 provider linked to a Network HSM.
> After a DECRYPT command (DES or AES) NOPADDING, we noticed the log : "Killing session (sun.security.pkcs11.P11Cipher.cancelOperation(P11Cipher.java:428)) active: 1"
> All following commands failed with error : CKR_USER_NOT_LOGGED_IN
>
> After a quick investigation, it looks like the fix JDK-8228565 done in P11Cipher.java is the root cause of this new behavior.
> 	....
> 	// Special handling to match SunJCE provider behavior
>                  if (bytesBuffered == 0 && padBufferLen == 0) {
>                      return 0;
>                  }
> 	....
> 	} finally {
>              		reset(doCancel);   // doCancel is true, so killSession is called.
>          	}
>
> This is a source code to reproduce the problem:
> 	SunPKCS11 p = new SunPKCS11(configName);           // config to Network HSM
> 	p.setCallbackHandler(handler);    // Handler for password
>          	Security.addProvider(p);
>          
>          	KeyStore.CallbackHandlerProtection chp =
>                  	new KeyStore.CallbackHandlerProtection(handler);
>              	KeyStore.Builder builder = KeyStore.Builder.newInstance("PKCS11", p, chp);
>          	KeyStore keystore = builder.getKeyStore();
>         	SecretKeyEntry entry = (SecretKeyEntry) keystore.getEntry("MyKeyAlias", null);
>          
>          	Cipher cipher = Cipher.getInstance("DESede/CBC/NOPADDING", p.getName());
>          	IvParameterSpec ivParameterSpec = new IvParameterSpec(new byte[8]);
>          	// cipher a text
>          	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
>          	byte[] clearData = "clear text111111".getBytes();
>          	byte[] cipheredData = cipher.doFinal(clearData);
>             	// Decipher the result
>          	cipher.init(Cipher.DECRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
>          	byte[] clearTextResult = cipher.doFinal(cipheredData);
> 	// display the result
> 	System.out.println(new String(clearTextResult));  // So far, no problem
>          
>                // Try another cipher
>          	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
> 	byte[] clearData2 = "clear text222222".getBytes();
>         	byte[] cipheredData2 = cipher.doFinal(clearData);
> 	// --> Failed with sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
>
> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
> 	at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
> 	at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:581)
>
>          
> Workarounds:
> 	. use the SunPkcs11 jar file from openJDK 8_222
> 	. add a login after every decrypt commands
> 	. use PKCS5Padding when possible
>
> Could you tell me if you can reproduce this problem and what is the best way for me to report it ?
>
> Thanks you
> Best Regards,
> Hubert
>   

From weijun.wang at oracle.com  Tue Dec  3 07:15:18 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 3 Dec 2019 15:15:18 +0800
Subject: RFR 8234267: DelegationPermission implementation doesn't
 completely follow the updated specification
In-Reply-To: <0E6DA7F8-7712-4FBF-B803-36B59832E8E4@oracle.com>
References: <0E6DA7F8-7712-4FBF-B803-36B59832E8E4@oracle.com>
Message-ID: <844E9BE6-9A6A-4A2D-9152-29AE6D409BA9@oracle.com>

Ping again.

> On Nov 16, 2019, at 10:02 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please take a review at
> 
>   http://cr.openjdk.java.net/~weijun/8234267/webrev.00/
> 
> Here, the returnDelims argument of the StringTokenizer is true so that we can detect duplicated delimiters.
> 
> If I understand correctly, after every non-delimiter token, the next one MUST be a delimiter. Therefore I haven't checked the 3rd, 5th, and the 7th. Please confirm this is correct.
> 
> Thanks,
> Max
> 


From 1983-01-06 at gmx.net  Tue Dec  3 13:45:58 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Tue, 3 Dec 2019 14:45:58 +0100
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
 <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
Message-ID: <47b484f0-d1bf-7ae7-2b92-ed4f84f54ecb@gmx.net>

Am 2019-12-02 um 19:34 schrieb Xuelei Fan:
> Hi,
>
> Could someone please help to verify if the attached patch (JDK 14) works
> HttpComponents?

The patch has been confirmed by the community. Can you go ahead and
apply it and as well as port back to 11u?

Michael

From sha.jiang at oracle.com  Tue Dec  3 14:31:49 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 3 Dec 2019 22:31:49 +0800
Subject: RFR[14] JDK-8235255: ProblemList
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
Message-ID: <08e1356e-08c7-1719-91c0-e3e3cd6b900b@oracle.com>

Hi,
It needs to put javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java 
into ProblemList due to JDK-8231810.

diff -r aa12d1f0bc66 test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt??? Tue Dec 03 14:10:53 2019 +0000
+++ b/test/jdk/ProblemList.txt??? Tue Dec 03 22:31:15 2019 +0800
@@ -681,6 +681,7 @@
 ?javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64
 ?javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64
 ?javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64
+javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java 8231810 generic-all

 ?sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all

Best regards,
John Jiang


From sean.mullan at oracle.com  Tue Dec  3 14:59:08 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 3 Dec 2019 09:59:08 -0500
Subject: RFR[14] JDK-8235255: ProblemList
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
In-Reply-To: <08e1356e-08c7-1719-91c0-e3e3cd6b900b@oracle.com>
References: <08e1356e-08c7-1719-91c0-e3e3cd6b900b@oracle.com>
Message-ID: <bedc87d0-96c6-0af5-e352-7d920e49f55a@oracle.com>

It looks fine to me.

--Sean

On 12/3/19 9:31 AM, sha.jiang at oracle.com wrote:
> Hi,
> It needs to put javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java 
> into ProblemList due to JDK-8231810.
> 
> diff -r aa12d1f0bc66 test/jdk/ProblemList.txt
> --- a/test/jdk/ProblemList.txt??? Tue Dec 03 14:10:53 2019 +0000
> +++ b/test/jdk/ProblemList.txt??? Tue Dec 03 22:31:15 2019 +0800
> @@ -681,6 +681,7 @@
>  ?javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64
>  ?javax/net/ssl/DTLS/RespondToRetransmit.java 8169086 macosx-x64
>  ?javax/net/ssl/DTLS/CipherSuite.java 8202059 macosx-x64
> +javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java 8231810 
> generic-all
> 
>  ?sun/security/provider/KeyStore/DKSTest.sh 8180266 windows-all
> 
> Best regards,
> John Jiang
> 

From xuelei.fan at oracle.com  Tue Dec  3 15:29:21 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 3 Dec 2019 07:29:21 -0800
Subject: Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions
In-Reply-To: <47b484f0-d1bf-7ae7-2b92-ed4f84f54ecb@gmx.net>
References: <ff7660f9-f38d-8b84-d825-7c2083104e21@gmx.net>
 <e91e0c84-cf64-674f-5be9-e39777597ddc@oracle.com>
 <47b484f0-d1bf-7ae7-2b92-ed4f84f54ecb@gmx.net>
Message-ID: <e7eabe71-5249-dedd-3bd5-8e3065d81512@oracle.com>

Thank you, Michael!  I will go ahead for OpenJDK code review.

Xuelei

On 12/3/2019 5:45 AM, Michael Osipov wrote:
> Am 2019-12-02 um 19:34 schrieb Xuelei Fan:
>> Hi,
>>
>> Could someone please help to verify if the attached patch (JDK 14) works
>> HttpComponents?
> 
> The patch has been confirmed by the community. Can you go ahead and
> apply it and as well as port back to 11u?
> 
> Michael

From xuelei.fan at oracle.com  Tue Dec  3 20:15:37 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 3 Dec 2019 12:15:37 -0800
Subject: RFR [14]: JDK-8235263, Aftermath of TLS 1.3 in Java 11 with wrapped
 IOExceptions
Message-ID: <c62c1423-0d16-82ae-4d2b-cd68dfd42af1@oracle.com>

Hi,

Could I get the following update reviewed?
    http://cr.openjdk.java.net/~xuelei/8235263/webrev.00/


In the SunJSSE provider, IOExceptions in application output stream was 
updated to be wrapped into SSLException so as to close underlying 
connections automatically. However, there are compatibility impact 
reported [1].

It is not a good solution to use specific exception and JSSE 
implementation details to switch business flow. However, as applications 
have used this way, we may want to fix the compatibility issue.

Simple fix, no new regression test.  The HttpComponents community had 
confirmed the patch [1].

Thanks,
Xuelei

[1]: 
https://mail.openjdk.java.net/pipermail/security-dev/2019-December/020956.html

From sean.mullan at oracle.com  Tue Dec  3 21:08:36 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 3 Dec 2019 16:08:36 -0500
Subject: RFR [14]: JDK-8235263, Aftermath of TLS 1.3 in Java 11 with
 wrapped IOExceptions
In-Reply-To: <c62c1423-0d16-82ae-4d2b-cd68dfd42af1@oracle.com>
References: <c62c1423-0d16-82ae-4d2b-cd68dfd42af1@oracle.com>
Message-ID: <f46185c2-53b2-3650-b446-b3f60471f6af@oracle.com>

Looks fine. The bug description is a bit dramatic though :) I would 
change it to not mention the Java version (which is already in the 
affectsVersion/Introduced in fields) and more descriptive of what is 
being changed, ex: "Revert TLS 1.3 change that wrapped IOExceptions".

--Sean

On 12/3/19 3:15 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/8235263/webrev.00/
> 
> 
> In the SunJSSE provider, IOExceptions in application output stream was 
> updated to be wrapped into SSLException so as to close underlying 
> connections automatically. However, there are compatibility impact 
> reported [1].
> 
> It is not a good solution to use specific exception and JSSE 
> implementation details to switch business flow. However, as applications 
> have used this way, we may want to fix the compatibility issue.
> 
> Simple fix, no new regression test.? The HttpComponents community had 
> confirmed the patch [1].
> 
> Thanks,
> Xuelei
> 
> [1]: 
> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/020956.html 
> 

From sean.coffey at oracle.com  Wed Dec  4 13:34:33 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 4 Dec 2019 13:34:33 +0000
Subject: SunPKCS11 connection lost after Decrypt doFinal (noPadding)
 openjdk 8_232
In-Reply-To: <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>
References: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>
 <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>
Message-ID: <3356c2c5-2a9e-3f1f-2772-52af1418c09b@oracle.com>

Also,

which JDK distro version of 8 are you using ? Note that the OpenJDK 
version has an extra few pkcs11 fixes in OpenJDK in this area (compared 
to the Oracle JDK 8 Updates) - Below being some of those :

https://bugs.openjdk.java.net/browse/JDK-8216597
https://bugs.openjdk.java.net/browse/JDK-6913047
https://bugs.openjdk.java.net/browse/JDK-6946830

Regards,
Sean.

On 03/12/19 00:56, Valerie Peng wrote:
> Hi Hubert,
>
> I've filed https://bugs.openjdk.java.net/browse/JDK-8235215 to keep 
> track of this issue.
>
> I have not yet tried if this can be reproduced in house with NSS yet.
>
> Just curious, which HSM vendor did you use? It'd be helpful to include 
> in the bug report.
>
> Thanks,
> Valerie
> On 12/2/2019 8:50 AM, DEBORDEAUX Hubert wrote:
>> Hello,
>> Following the update to OpenJDK 8_232, we did face a problem after a 
>> DECRYPT with no padding.
>> We use a SunPKCS11 provider linked to a Network HSM.
>> After a DECRYPT command (DES or AES) NOPADDING, we noticed the log : 
>> "Killing session 
>> (sun.security.pkcs11.P11Cipher.cancelOperation(P11Cipher.java:428)) 
>> active: 1"
>> All following commands failed with error : CKR_USER_NOT_LOGGED_IN
>>
>> After a quick investigation, it looks like the fix JDK-8228565 done 
>> in P11Cipher.java is the root cause of this new behavior.
>>     ....
>>     // Special handling to match SunJCE provider behavior
>>                  if (bytesBuffered == 0 && padBufferLen == 0) {
>>                      return 0;
>>                  }
>>     ....
>>     } finally {
>>                      reset(doCancel);   // doCancel is true, so 
>> killSession is called.
>>              }
>>
>> This is a source code to reproduce the problem:
>>     SunPKCS11 p = new SunPKCS11(configName);           // config to 
>> Network HSM
>>     p.setCallbackHandler(handler);    // Handler for password
>>              Security.addProvider(p);
>>                       KeyStore.CallbackHandlerProtection chp =
>>                      new KeyStore.CallbackHandlerProtection(handler);
>>                  KeyStore.Builder builder = 
>> KeyStore.Builder.newInstance("PKCS11", p, chp);
>>              KeyStore keystore = builder.getKeyStore();
>>             SecretKeyEntry entry = (SecretKeyEntry) 
>> keystore.getEntry("MyKeyAlias", null);
>>                       Cipher cipher = 
>> Cipher.getInstance("DESede/CBC/NOPADDING", p.getName());
>>              IvParameterSpec ivParameterSpec = new 
>> IvParameterSpec(new byte[8]);
>>              // cipher a text
>>              cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>              byte[] clearData = "clear text111111".getBytes();
>>              byte[] cipheredData = cipher.doFinal(clearData);
>>                 // Decipher the result
>>              cipher.init(Cipher.DECRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>              byte[] clearTextResult = cipher.doFinal(cipheredData);
>>     // display the result
>>     System.out.println(new String(clearTextResult));  // So far, no 
>> problem
>>                         // Try another cipher
>>              cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>     byte[] clearData2 = "clear text222222".getBytes();
>>             byte[] cipheredData2 = cipher.doFinal(clearData);
>>     // --> Failed with sun.security.pkcs11.wrapper.PKCS11Exception: 
>> CKR_USER_NOT_LOGGED_IN
>>
>> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 
>> CKR_USER_NOT_LOGGED_IN
>>     at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
>>     at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:581)
>>
>>          Workarounds:
>>     . use the SunPkcs11 jar file from openJDK 8_222
>>     . add a login after every decrypt commands
>>     . use PKCS5Padding when possible
>>
>> Could you tell me if you can reproduce this problem and what is the 
>> best way for me to report it ?
>>
>> Thanks you
>> Best Regards,
>> Hubert


From christoph.langer at sap.com  Wed Dec  4 14:39:56 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 4 Dec 2019 14:39:56 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <DB8PR02MB554734ACEB954B6F7FE66E348A5D0@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi Martin,

thanks for looking into this and coming up with this patch. The test failures were quite annoying ??

In hotspot, there is coding to define a macro "ATTRIBUTE_ALIGNED(x)". I'd rather like to see that we define such a macro in the JDK code as well and use it. I think it would make the code more readable. Other than that, +1

Cheers
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Doerr, Martin
> Sent: Montag, 2. Dezember 2019 16:13
> To: core-libs-dev at openjdk.java.net; security-dev <security-
> dev at openjdk.java.net>
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: [CAUTION] RFR(S): 8220348: [ntintel] asserts about copying
> unalinged array
> 
> Hi,
> 
> I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u
> backport):
> https://bugs.openjdk.java.net/browse/JDK-8220348
> 
> Some jdk native methods use jni_SetLongArrayRegion with a stack allocated
> buffer.
> jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires
> jlongs to be 8 byte aligned (asserted).
> However, Windows 32 bit only uses 4 byte alignment for jlong arrays by
> default.
> I found such issues in the following files:
> src/java.prefs/windows/native/libprefs/WindowsPreferences.c
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
> I suggest to use __declspec(align(8)) there.
> 
> Webrev:
> http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.0
> 0/
> Please review.
> 
> I think using 8 byte alignment is not a disadvantage for 64 bit.
> 
> I guess there are still people interested in this platform with jdk14. Otherwise
> I could contribute it as 11u only fix.
> 
> Is there a better way to force 8 byte alignment for jlongs or jlong arrays on
> stack?
> Best regards,
> Martin


From thomas.stuefe at gmail.com  Wed Dec  4 16:56:14 2019
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 4 Dec 2019 17:56:14 +0100
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like
the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable
with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi,
>
> I'd like to propose a fix for an old issue on 32 bit Windows (also for an
> 11u backport):
> https://bugs.openjdk.java.net/browse/JDK-8220348
>
> Some jdk native methods use jni_SetLongArrayRegion with a stack allocated
> buffer.
> jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires
> jlongs to be 8 byte aligned (asserted).
> However, Windows 32 bit only uses 4 byte alignment for jlong arrays by
> default.
> I found such issues in the following files:
> src/java.prefs/windows/native/libprefs/WindowsPreferences.c
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
> I suggest to use __declspec(align(8)) there.
>
> Webrev:
> http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
> Please review.
>
> I think using 8 byte alignment is not a disadvantage for 64 bit.
>
> I guess there are still people interested in this platform with jdk14.
> Otherwise I could contribute it as 11u only fix.
>
> Is there a better way to force 8 byte alignment for jlongs or jlong arrays
> on stack?
> Best regards,
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191204/e74be729/attachment.html>

From xuelei.fan at oracle.com  Wed Dec  4 18:32:24 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 4 Dec 2019 10:32:24 -0800
Subject: RFR 8234267: DelegationPermission implementation doesn't
 completely follow the updated specification
In-Reply-To: <844E9BE6-9A6A-4A2D-9152-29AE6D409BA9@oracle.com>
References: <0E6DA7F8-7712-4FBF-B803-36B59832E8E4@oracle.com>
 <844E9BE6-9A6A-4A2D-9152-29AE6D409BA9@oracle.com>
Message-ID: <ad458ed0-eded-0316-6e98-9fbacc039275@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 12/2/2019 11:15 PM, Weijun Wang wrote:
> Ping again.
> 
>> On Nov 16, 2019, at 10:02 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please take a review at
>>
>>    http://cr.openjdk.java.net/~weijun/8234267/webrev.00/
>>
>> Here, the returnDelims argument of the StringTokenizer is true so that we can detect duplicated delimiters.
>>
>> If I understand correctly, after every non-delimiter token, the next one MUST be a delimiter. Therefore I haven't checked the 3rd, 5th, and the 7th. Please confirm this is correct.
>>
>> Thanks,
>> Max
>>
> 

From RAJAN.HALADE at ORACLE.COM  Wed Dec  4 21:19:15 2019
From: RAJAN.HALADE at ORACLE.COM (Rajan Halade)
Date: Wed, 4 Dec 2019 13:19:15 -0800
Subject: RFR: 8190492: Remove SSLv2Hello and SSLv3 from default enabled TLS
 protocols
Message-ID: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>

May I request you to review following fix which removes SSLv2Hello and SSLv3 from default enabled protocols. 

SSLv3 has been deprecated with RFC 7568. We have already disabled it by default in 2015 by adding it to the jdk.tls.disabledAlgorithms property. This fix removes it from default enabled list as well. If client/server want to use this protocol they can still do so by enabling it with setEnabledProtocols() API.

Webrev: http://cr.openjdk.java.net/~rhalade/8190492/webrev.00/ <http://cr.openjdk.java.net/~rhalade/8190492/webrev.00/>

Thanks,
Rajan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191204/58b70802/attachment-0001.html>

From bradford.wetmore at oracle.com  Thu Dec  5 01:18:42 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Wed, 4 Dec 2019 17:18:42 -0800
Subject: RFR: 8190492: Remove SSLv2Hello and SSLv3 from default enabled
 TLS protocols
In-Reply-To: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>
References: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>
Message-ID: <cec39422-70be-ea5a-8080-ae82bd3cccd9@oracle.com>

In line 601, doesn't this mean that SSL3/SSL20Hello are not longer 
available as supported, and that you can't turn them back on?

Brad


On 12/4/2019 1:19 PM, Rajan Halade wrote:
> May I request you to review following fix which removes SSLv2Hello and 
> SSLv3 from default enabled protocols.
> 
> SSLv3 has been deprecated with RFC 7568. We have already?disabled it by 
> default in 2015 by adding it to the jdk.tls.disabledAlgorithms property. 
> This fix removes it from default enabled list as well. If client/server 
> want to use this protocol they can still do so by enabling it with 
> setEnabledProtocols() API.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8190492/webrev.00/
> 
> Thanks,
> Rajan
> 

From weijun.wang at oracle.com  Thu Dec  5 02:37:10 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 5 Dec 2019 10:37:10 +0800
Subject: RFR 8234267: DelegationPermission implementation doesn't
 completely follow the updated specification
In-Reply-To: <ad458ed0-eded-0316-6e98-9fbacc039275@oracle.com>
References: <0E6DA7F8-7712-4FBF-B803-36B59832E8E4@oracle.com>
 <844E9BE6-9A6A-4A2D-9152-29AE6D409BA9@oracle.com>
 <ad458ed0-eded-0316-6e98-9fbacc039275@oracle.com>
Message-ID: <A1EA2970-D27B-460F-9B6E-BD501C44EFFC@oracle.com>

Thanks!

> On Dec 5, 2019, at 2:32 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Looks fine to me.
> 
> Thanks,
> Xuelei
> 
> On 12/2/2019 11:15 PM, Weijun Wang wrote:
>> Ping again.
>>> On Nov 16, 2019, at 10:02 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Please take a review at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8234267/webrev.00/
>>> 
>>> Here, the returnDelims argument of the StringTokenizer is true so that we can detect duplicated delimiters.
>>> 
>>> If I understand correctly, after every non-delimiter token, the next one MUST be a delimiter. Therefore I haven't checked the 3rd, 5th, and the 7th. Please confirm this is correct.
>>> 
>>> Thanks,
>>> Max
>>> 


From weijun.wang at oracle.com  Thu Dec  5 02:49:52 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 5 Dec 2019 10:49:52 +0800
Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes
 during build
In-Reply-To: <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com>
References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com>
 <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com>
Message-ID: <45B0C9E5-D729-470C-ADA4-524204317164@oracle.com>

Ping the security side.

> On Nov 26, 2019, at 12:36 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Build change looks good.
> 
> /Erik
> 
> On 2019-11-22 18:59, Weijun Wang wrote:
>> Please review the change at
>> 
>>    http://cr.openjdk.java.net/~weijun/8234697/webrev.00/
>> 
>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file.
>> 
>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before.
>> 
>> Other smaller changes made to FieldGen.jsh:
>> 
>> 1. Package name
>> 2. No more jshell, but now Java
>> 3. Input/output paths as args for main()
>> 4. White spaces, wrapping and indentation
>> 
>> Thanks,
>> Max
>> 


From christoph.langer at sap.com  Thu Dec  5 11:16:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 5 Dec 2019 11:16:23 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <AM0PR0202MB329719A4E6BC2305E097A46B9A5C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>
 <AM0PR0202MB329719A4E6BC2305E097A46B9A5C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <DB8PR02MB5547658B363C35672B7D008D8A5C0@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi Martin,

I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it.

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Donnerstag, 5. Dezember 2019 12:00
To: Thomas St?fe <thomas.stuefe at gmail.com>; Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net; security-dev <security-dev at openjdk.java.net>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER)

I?d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack?
Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191205/82126481/attachment-0001.html>

From hubert.debordeaux at thalesgroup.com  Tue Dec  3 09:36:32 2019
From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert)
Date: Tue, 3 Dec 2019 09:36:32 +0000
Subject: SunPKCS11 connection lost after Decrypt doFinal (noPadding)
 openjdk 8_232
In-Reply-To: <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>
References: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>
 <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>
Message-ID: <MRXP264MB04716A584EBD6B75F20D82AFEC420@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>

Hello,
Thank you for the quick response.

The HSM we are using is the Bull Proteccio Trustway.

This is the pkcs11 config file : 

name = Proteccio_PKCS11
library = /opt/bull/client/nethsm.so
slot = 1
attributes = compatibility


Thanks,
Hubert

-----Original Message-----
From: Valerie Peng [mailto:valerie.peng at oracle.com] 
Sent: Tuesday, December 3, 2019 1:57
To: DEBORDEAUX Hubert <hubert.debordeaux at thalesgroup.com>; security-dev at openjdk.java.net
Subject: Re: SunPKCS11 connection lost after Decrypt doFinal (noPadding) openjdk 8_232

Hi Hubert,

I've filed https://bugs.openjdk.java.net/browse/JDK-8235215 to keep track of this issue.

I have not yet tried if this can be reproduced in house with NSS yet.

Just curious, which HSM vendor did you use? It'd be helpful to include in the bug report.

Thanks,
Valerie
On 12/2/2019 8:50 AM, DEBORDEAUX Hubert wrote:
> Hello,
> Following the update to OpenJDK 8_232, we did face a problem after a DECRYPT with no padding.
> We use a SunPKCS11 provider linked to a Network HSM.
> After a DECRYPT command (DES or AES) NOPADDING, we noticed the log : "Killing session (sun.security.pkcs11.P11Cipher.cancelOperation(P11Cipher.java:428)) active: 1"
> All following commands failed with error : CKR_USER_NOT_LOGGED_IN
>
> After a quick investigation, it looks like the fix JDK-8228565 done in P11Cipher.java is the root cause of this new behavior.
> 	....
> 	// Special handling to match SunJCE provider behavior
>                  if (bytesBuffered == 0 && padBufferLen == 0) {
>                      return 0;
>                  }
> 	....
> 	} finally {
>              		reset(doCancel);   // doCancel is true, so killSession is called.
>          	}
>
> This is a source code to reproduce the problem:
> 	SunPKCS11 p = new SunPKCS11(configName);           // config to Network HSM
> 	p.setCallbackHandler(handler);    // Handler for password
>          	Security.addProvider(p);
>          
>          	KeyStore.CallbackHandlerProtection chp =
>                  	new KeyStore.CallbackHandlerProtection(handler);
>              	KeyStore.Builder builder = KeyStore.Builder.newInstance("PKCS11", p, chp);
>          	KeyStore keystore = builder.getKeyStore();
>         	SecretKeyEntry entry = (SecretKeyEntry) 
> keystore.getEntry("MyKeyAlias", null);
>          
>          	Cipher cipher = Cipher.getInstance("DESede/CBC/NOPADDING", p.getName());
>          	IvParameterSpec ivParameterSpec = new IvParameterSpec(new byte[8]);
>          	// cipher a text
>          	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
>          	byte[] clearData = "clear text111111".getBytes();
>          	byte[] cipheredData = cipher.doFinal(clearData);
>             	// Decipher the result
>          	cipher.init(Cipher.DECRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
>          	byte[] clearTextResult = cipher.doFinal(cipheredData);
> 	// display the result
> 	System.out.println(new String(clearTextResult));  // So far, no 
> problem
>          
>                // Try another cipher
>          	cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), ivParameterSpec);
> 	byte[] clearData2 = "clear text222222".getBytes();
>         	byte[] cipheredData2 = cipher.doFinal(clearData);
> 	// --> Failed with sun.security.pkcs11.wrapper.PKCS11Exception: 
> CKR_USER_NOT_LOGGED_IN
>
> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_USER_NOT_LOGGED_IN
> 	at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
> 	at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:581)
>
>          
> Workarounds:
> 	. use the SunPkcs11 jar file from openJDK 8_222
> 	. add a login after every decrypt commands
> 	. use PKCS5Padding when possible
>
> Could you tell me if you can reproduce this problem and what is the best way for me to report it ?
>
> Thanks you
> Best Regards,
> Hubert
>   

From hubert.debordeaux at thalesgroup.com  Wed Dec  4 14:15:51 2019
From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert)
Date: Wed, 4 Dec 2019 14:15:51 +0000
Subject: SunPKCS11 connection lost after Decrypt doFinal (noPadding)
 openjdk 8_232
In-Reply-To: <3356c2c5-2a9e-3f1f-2772-52af1418c09b@oracle.com>
References: <MRXP264MB04718B7792D452CA24C95F56EC430@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>
 <07cbcbe6-a409-7836-53f9-4a819d5fca35@oracle.com>
 <3356c2c5-2a9e-3f1f-2772-52af1418c09b@oracle.com>
Message-ID: <MRXP264MB0471D622A640B9056651CA00EC5D0@MRXP264MB0471.FRAP264.PROD.OUTLOOK.COM>


I reproduced the issue using AdoptOpenJDK 8_232 on Windows 10.
One of our customers faced the same problem on CentOS 7.6. I guess it is the regular CentOS distribution.

Our first analysis of pkcs11 changes has been done on the following file : 
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/5456f24496f4/src/share/classes/sun/security/pkcs11/P11Cipher.java

We did not look at the other fixes as the update on P11Cipher seems to be the root cause.
But you are right, we are going to have a look at them also.


Thanks
Hubert



-----Original Message-----
From: Se?n Coffey [mailto:sean.coffey at oracle.com] 
Sent: Wednesday, December 4, 2019 14:35
To: Valerie Peng <valerie.peng at oracle.com>; DEBORDEAUX Hubert <hubert.debordeaux at thalesgroup.com>; security-dev at openjdk.java.net
Subject: Re: SunPKCS11 connection lost after Decrypt doFinal (noPadding) openjdk 8_232

Also,

which JDK distro version of 8 are you using ? Note that the OpenJDK version has an extra few pkcs11 fixes in OpenJDK in this area (compared to the Oracle JDK 8 Updates) - Below being some of those :

https://bugs.openjdk.java.net/browse/JDK-8216597
https://bugs.openjdk.java.net/browse/JDK-6913047
https://bugs.openjdk.java.net/browse/JDK-6946830

Regards,
Sean.

On 03/12/19 00:56, Valerie Peng wrote:
> Hi Hubert,
>
> I've filed https://bugs.openjdk.java.net/browse/JDK-8235215 to keep 
> track of this issue.
>
> I have not yet tried if this can be reproduced in house with NSS yet.
>
> Just curious, which HSM vendor did you use? It'd be helpful to include 
> in the bug report.
>
> Thanks,
> Valerie
> On 12/2/2019 8:50 AM, DEBORDEAUX Hubert wrote:
>> Hello,
>> Following the update to OpenJDK 8_232, we did face a problem after a 
>> DECRYPT with no padding.
>> We use a SunPKCS11 provider linked to a Network HSM.
>> After a DECRYPT command (DES or AES) NOPADDING, we noticed the log : 
>> "Killing session
>> (sun.security.pkcs11.P11Cipher.cancelOperation(P11Cipher.java:428))
>> active: 1"
>> All following commands failed with error : CKR_USER_NOT_LOGGED_IN
>>
>> After a quick investigation, it looks like the fix JDK-8228565 done 
>> in P11Cipher.java is the root cause of this new behavior.
>>     ....
>>     // Special handling to match SunJCE provider behavior
>>                  if (bytesBuffered == 0 && padBufferLen == 0) {
>>                      return 0;
>>                  }
>>     ....
>>     } finally {
>>                      reset(doCancel);   // doCancel is true, so 
>> killSession is called.
>>              }
>>
>> This is a source code to reproduce the problem:
>>     SunPKCS11 p = new SunPKCS11(configName);           // config to 
>> Network HSM
>>     p.setCallbackHandler(handler);    // Handler for password
>>              Security.addProvider(p);
>>                       KeyStore.CallbackHandlerProtection chp =
>>                      new KeyStore.CallbackHandlerProtection(handler);
>>                  KeyStore.Builder builder = 
>> KeyStore.Builder.newInstance("PKCS11", p, chp);
>>              KeyStore keystore = builder.getKeyStore();
>>             SecretKeyEntry entry = (SecretKeyEntry) 
>> keystore.getEntry("MyKeyAlias", null);
>>                       Cipher cipher = 
>> Cipher.getInstance("DESede/CBC/NOPADDING", p.getName());
>>              IvParameterSpec ivParameterSpec = new 
>> IvParameterSpec(new byte[8]);
>>              // cipher a text
>>              cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>              byte[] clearData = "clear text111111".getBytes();
>>              byte[] cipheredData = cipher.doFinal(clearData);
>>                 // Decipher the result
>>              cipher.init(Cipher.DECRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>              byte[] clearTextResult = cipher.doFinal(cipheredData);
>>     // display the result
>>     System.out.println(new String(clearTextResult));  // So far, no 
>> problem
>>                         // Try another cipher
>>              cipher.init(Cipher.ENCRYPT_MODE, entry.getSecretKey(), 
>> ivParameterSpec);
>>     byte[] clearData2 = "clear text222222".getBytes();
>>             byte[] cipheredData2 = cipher.doFinal(clearData);
>>     // --> Failed with sun.security.pkcs11.wrapper.PKCS11Exception: 
>> CKR_USER_NOT_LOGGED_IN
>>
>> Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 
>> CKR_USER_NOT_LOGGED_IN
>>     at sun.security.pkcs11.wrapper.PKCS11.C_EncryptUpdate(Native Method)
>>     at sun.security.pkcs11.P11Cipher.implUpdate(P11Cipher.java:581)
>>
>>          Workarounds:
>>     . use the SunPkcs11 jar file from openJDK 8_222
>>     . add a login after every decrypt commands
>>     . use PKCS5Padding when possible
>>
>> Could you tell me if you can reproduce this problem and what is the 
>> best way for me to report it ?
>>
>> Thanks you
>> Best Regards,
>> Hubert


From martin.doerr at sap.com  Thu Dec  5 10:59:59 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 5 Dec 2019 10:59:59 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>
Message-ID: <AM0PR0202MB329719A4E6BC2305E097A46B9A5C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER)

I?d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin <martin.doerr at sap.com>
Cc: core-libs-dev at openjdk.java.net; security-dev <security-dev at openjdk.java.net>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack?
Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191205/1619c32e/attachment.html>

From RAJAN.HALADE at ORACLE.COM  Thu Dec  5 22:12:23 2019
From: RAJAN.HALADE at ORACLE.COM (Rajan Halade)
Date: Thu, 5 Dec 2019 14:12:23 -0800
Subject: RFR: 8190492: Remove SSLv2Hello and SSLv3 from default enabled
 TLS protocols
In-Reply-To: <cec39422-70be-ea5a-8080-ae82bd3cccd9@oracle.com>
References: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>
 <cec39422-70be-ea5a-8080-ae82bd3cccd9@oracle.com>
Message-ID: <8722684A-D8CD-4F8A-BF51-A4B2BDC89F99@ORACLE.COM>

The method at line 596 is only called at line 855 from customizedProtocols class. It should really be read as getServerDefaultProtocols. Supported protocols are returned correctly on SSLEngine, SSLServerSocket, and SSLSocket.

I thought about cleaning/renaming it but then AbstractTLSContext already has serverDefaultProtocols and getProtocols() in customizedProtocols can also be moved out. I will file a separate bug to handle these cleanups.
 
Thanks,
Rajan

> On Dec 4, 2019, at 5:18 PM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> In line 601, doesn't this mean that SSL3/SSL20Hello are not longer available as supported, and that you can't turn them back on?
> 
> Brad
> 
> 
> On 12/4/2019 1:19 PM, Rajan Halade wrote:
>> May I request you to review following fix which removes SSLv2Hello and SSLv3 from default enabled protocols.
>> SSLv3 has been deprecated with RFC 7568. We have already disabled it by default in 2015 by adding it to the jdk.tls.disabledAlgorithms property. This fix removes it from default enabled list as well. If client/server want to use this protocol they can still do so by enabling it with setEnabledProtocols() API.
>> Webrev: http://cr.openjdk.java.net/~rhalade/8190492/webrev.00/
>> Thanks,
>> Rajan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191205/40e50e27/attachment.html>

From sean.mullan at oracle.com  Thu Dec  5 23:45:25 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 5 Dec 2019 18:45:25 -0500
Subject: RFR: 8190492: Remove SSLv2Hello and SSLv3 from default enabled
 TLS protocols
In-Reply-To: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>
References: <750BF183-ED95-452C-BEB8-E309C44C299A@ORACLE.COM>
Message-ID: <8d2fd91f-b26f-8c03-b9d3-11f750a7c1e6@oracle.com>

Looks good, and I see you have also drafted a CSR for this:

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

This looks good so I added my name as Reviewer. My only comment is that 
you could be more specific about the fully-qualified names of the APIs 
(instead of just getEnabledProtocols) and the specific system properties.

--Sean

On 12/4/19 4:19 PM, Rajan Halade wrote:
> May I request you to review following fix which removes SSLv2Hello and 
> SSLv3 from default enabled protocols.
> 
> SSLv3 has been deprecated with RFC 7568. We have already?disabled it by 
> default in 2015 by adding it to the jdk.tls.disabledAlgorithms property. 
> This fix removes it from default enabled list as well. If client/server 
> want to use this protocol they can still do so by enabling it with 
> setEnabledProtocols() API.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8190492/webrev.00/
> 
> Thanks,
> Rajan
> 

From weijun.wang at oracle.com  Fri Dec  6 08:27:51 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 6 Dec 2019 16:27:51 +0800
Subject: RFR 8005819: Support cross-realm MSSFU
In-Reply-To: <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
References: <b48121ca-f8a0-046e-816c-2e9e4a6c3544@redhat.com>
 <db10fd96-b762-c9b1-90ff-727aa727f699@redhat.com>
 <cbfd659a-68b5-df7e-7e17-2c77d4d5da1d@siemens.com>
 <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
Message-ID: <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>

Hi Martin,

Looks fine overall. Only two suggestions:

1. Can we change the signature of handleS4U2ProxyReferral so that there is only one credsInOut?

   String handleS4U2ProxyReferral(Credentials asCreds,
        Credentials[] credsInOut, PrincipalName sname)

and call it with "new Credentials[] {creds, null}"?

Then you can clearly specify

  input: first referral TGT for S4U2proxy, null
  output: service's final referral TGT, client's final referral TGT

2. Can we add a S4U2Type argument in serviceCreds(options,...)? Then its callers can specify it directly and there is no need for this method to guess it out.

Thanks,
Max

p.s. Something related but not for this enhancement. The getTGTforRealm method should not call Realm.getRealmsList() (i.e. use [capaths] in krb5.conf) when using referral. It should just follow the referral.

> On Nov 1, 2019, at 5:37 AM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi,
> 
> Webrev.02:
> 
> * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.02/
> 
> Changes:
> 
> * No need to create a new sname PrincipalName in
> CredentialsUtil::handleS4U2ProxyReferral as it's not mutable.
> 
> Regards,
> Martin.-
> 


From christoph.langer at sap.com  Fri Dec  6 13:24:17 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 6 Dec 2019 13:24:17 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <AM0PR0202MB32974998C55C74E58B9FFC909A5F0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>
 <AM0PR0202MB329719A4E6BC2305E097A46B9A5C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <DB8PR02MB5547658B363C35672B7D008D8A5C0@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <AM0PR0202MB32974998C55C74E58B9FFC909A5F0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <DB8PR02MB55470F93C0ED55E8A77B3DA38A5F0@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi Martin,

ok, you are the author ? so I won?t insist. ??

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Freitag, 6. Dezember 2019 12:22
To: Langer, Christoph <christoph.langer at sap.com>
Cc: core-libs-dev at openjdk.java.net; security-dev <security-dev at openjdk.java.net>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Thomas St?fe <thomas.stuefe at gmail.com>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Christoph,

that would work, but I don?t want to pollute this file with compiler specific defines. In addition, I don?t like introducing a macro which works on some platforms and does nothing on other ones (which is the case for hotspot?s ATTRIBUTE_ALIGNED).

Because Windows 32 bit is the only affected platform, I prefer not to touch other ones. Are you ok with webrev.00 as it is?

Best regards,
Martin



From: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Sent: Donnerstag, 5. Dezember 2019 12:16
To: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it.

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Donnerstag, 5. Dezember 2019 12:00
To: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER)

I?d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack?
Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191206/173501dd/attachment-0001.html>

From sean.mullan at oracle.com  Fri Dec  6 20:24:04 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 6 Dec 2019 15:24:04 -0500
Subject: [14] RFR for 8235184: Deprecate the legacy elliptic curves for removal
Message-ID: <acb91ecf-bad0-bb1a-11e6-5ebac2295914@oracle.com>

Please review this change to deprecate, and eventually remove the native 
legacy implementations of elliptic curves in the SunEC provider.

These curves are not implemented using modern formulas and techniques. 
We have already replaced some of these curves (secp256r1, secp384r1, and 
secp512r1) with a more modern implementation -- see JDK-8208698 [1] for 
more details.

With a few exceptions, the remaining curves are rarely used in practice. 
It does not make sense to invest what would be a significant amount of 
resources to replace all of them. Most of these curves have also been 
deprecated or obsoleted by TLS specifications - see RFC 8446 [2] and RFC 
8422 [3].

If time and resources permit, a small number of them may be replaced 
with more modern implementations.

Only the CSR needs to be reviewed since this is a docs-only change:

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

Thanks,
Sean

[1] https://bugs.openjdk.java.net/browse/JDK-8208698
[2] https://tools.ietf.org/html/rfc8446#appendix-B.3.1.4
[3] https://tools.ietf.org/html/rfc8422#section-5.1.1

From xuelei.fan at oracle.com  Sat Dec  7 03:55:14 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 6 Dec 2019 19:55:14 -0800
Subject: [14] RFR for 8235184: Deprecate the legacy elliptic curves for
 removal
In-Reply-To: <acb91ecf-bad0-bb1a-11e6-5ebac2295914@oracle.com>
References: <acb91ecf-bad0-bb1a-11e6-5ebac2295914@oracle.com>
Message-ID: <d6410a43-8667-18fe-e448-885aee166888@oracle.com>

Looks fine to me.  I added myself as reviewer.

Xuelei

On 12/6/2019 12:24 PM, Sean Mullan wrote:
> Please review this change to deprecate, and eventually remove the native 
> legacy implementations of elliptic curves in the SunEC provider.
> 
> These curves are not implemented using modern formulas and techniques. 
> We have already replaced some of these curves (secp256r1, secp384r1, and 
> secp512r1) with a more modern implementation -- see JDK-8208698 [1] for 
> more details.
> 
> With a few exceptions, the remaining curves are rarely used in practice. 
> It does not make sense to invest what would be a significant amount of 
> resources to replace all of them. Most of these curves have also been 
> deprecated or obsoleted by TLS specifications - see RFC 8446 [2] and RFC 
> 8422 [3].
> 
> If time and resources permit, a small number of them may be replaced 
> with more modern implementations.
> 
> Only the CSR needs to be reviewed since this is a docs-only change:
> 
>  ? https://bugs.openjdk.java.net/browse/JDK-8235184
> 
> Thanks,
> Sean
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8208698
> [2] https://tools.ietf.org/html/rfc8446#appendix-B.3.1.4
> [3] https://tools.ietf.org/html/rfc8422#section-5.1.1

From xuelei.fan at oracle.com  Mon Dec  9 14:51:04 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 9 Dec 2019 06:51:04 -0800
Subject: RFR [14] JDK-8235448, code cleanup/rename in SSLContextImpl.java
Message-ID: <4ce11b60-9429-538d-5ee7-ae7876895522@oracle.com>

Hi,

Could I get the following code reviewed?
    http://cr.openjdk.java.net/~xuelei/8235448/webrev.00/

This update made a few code cleanup, including remove unnecessary 
methods, comments, etc.

Just code cleanup, no new regression test.

Thanks,
Xuelei

From anthony.scarpino at oracle.com  Mon Dec  9 18:04:41 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 9 Dec 2019 10:04:41 -0800
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
Message-ID: <e52a0794-1386-489c-bb72-ebb3a38ad977@oracle.com>

I've updated the webrev to address many of the comments.  In particular 
adding checks when keys given directly.  Also, the changing from 
legacyEC hardcoded list to a security property jdk.disabled.namedCurves.

https://cr.openjdk.java.net/~ascarpino/8233228/webrev.01/

Tony

From anthony.scarpino at oracle.com  Mon Dec  9 18:10:49 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 9 Dec 2019 10:10:49 -0800
Subject: CSR RFR: 8233228: Support named curves for all disabledAlgorithms
Message-ID: <f5bf3a1e-e214-8928-8b40-7baf0c7de572@oracle.com>

I need a CSR review for the change with policy and property addition for 
8233228.

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

Tony


From jamil.j.nimeh at oracle.com  Mon Dec  9 18:50:39 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 9 Dec 2019 10:50:39 -0800
Subject: RFR [14] JDK-8235448, code cleanup/rename in SSLContextImpl.java
In-Reply-To: <4ce11b60-9429-538d-5ee7-ae7876895522@oracle.com>
References: <4ce11b60-9429-538d-5ee7-ae7876895522@oracle.com>
Message-ID: <829529c8-5e15-1673-9fed-e03187855975@oracle.com>

This looks pretty good to me.

--Jamil

On 12/9/19 6:51 AM, Xuelei Fan wrote:
> Hi,
>
> Could I get the following code reviewed?
> ?? http://cr.openjdk.java.net/~xuelei/8235448/webrev.00/
>
> This update made a few code cleanup, including remove unnecessary 
> methods, comments, etc.
>
> Just code cleanup, no new regression test.
>
> Thanks,
> Xuelei

From weijun.wang at oracle.com  Tue Dec 10 01:34:10 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 10 Dec 2019 09:34:10 +0800
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <e52a0794-1386-489c-bb72-ebb3a38ad977@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
 <e52a0794-1386-489c-bb72-ebb3a38ad977@oracle.com>
Message-ID: <B1206C40-BFFC-46E0-B0C4-1EA2823440BA@oracle.com>

Hi Tony,

Please include this tiny change to keytool:

diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java
--- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java
+++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java
@@ -4658,7 +4658,7 @@
                     rb.getString("whose.key.risk"),
                     label,
                     String.format(rb.getString("key.bit"),
-                            KeyUtil.getKeySize(key), key.getAlgorithm())));
+                            KeyUtil.getKeySize(key), fullDisplayAlgName(key))));
         }
     }

Without this change, when a new keypair is generated using a disabled curve name, it will show

   The generated certificate uses a 256-bit EC key which is considered a security risk.

with it, there is a clue

   The generated certificate uses a 256-bit EC (secp256k1) key which is considered a security risk.

I used to only check the algorithm name and key size.

Thanks,
Max


> On Dec 10, 2019, at 2:04 AM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
> I've updated the webrev to address many of the comments.  In particular adding checks when keys given directly.  Also, the changing from legacyEC hardcoded list to a security property jdk.disabled.namedCurves.
> 
> https://cr.openjdk.java.net/~ascarpino/8233228/webrev.01/
> 
> Tony


From sha.jiang at oracle.com  Tue Dec 10 08:29:22 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 10 Dec 2019 16:29:22 +0800
Subject: RFR[14] JDK-8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently
 with "java.lang.Exception: Unexpected EOF"
Message-ID: <3c25caf4-7a6d-2712-9c28-65b8ae76600c@oracle.com>

Hi,
When the server socket in this test tries to receive close_notify, 
possibly the client socket is (being) closed.

Without this patch, this failure was easily reproduced by running the 
test in a loop.
With this patch, I didn't reproduce it in the same way.

Issue: https://bugs.openjdk.java.net/browse/JDK-8231810
Webrev: http://cr.openjdk.java.net/~jjiang/8231810/webrev.00/

Best regards,
John Jiang


From weijun.wang at oracle.com  Tue Dec 10 09:45:48 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 10 Dec 2019 17:45:48 +0800
Subject: RFR 8234465: Encoded elliptic curve private keys should include the
 public point
Message-ID: <7289127A-15C5-4D04-8726-3D0EC52FAC64@oracle.com>

Please review the code change at

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

The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly generated, a copy of the ECPoint of the public key is put inside the private key. This ECPoint can be stored in a PKCS #8 file. When reading from a PKCS #8 file, it can also be loaded.

Since the ECPrivateKey class interface and the ECPrivateKeySpec spec do not have the public ECPoint, an ECPrivateKeyImpl will not have this info when created from these sources. So it's still optional. I haven't tried to calculate it.

Thanks,
Max


From sean.mullan at oracle.com  Tue Dec 10 13:57:20 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Dec 2019 08:57:20 -0500
Subject: CSR RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <f5bf3a1e-e214-8928-8b40-7baf0c7de572@oracle.com>
References: <f5bf3a1e-e214-8928-8b40-7baf0c7de572@oracle.com>
Message-ID: <0c971d23-59e9-aafe-72ea-603c3850a49f@oracle.com>

In general, this CSR looks good. Here are my specific comments:

- The Scope should be "JDK" since these are JDK supported security 
properties.

- The Fix Version should also include 7-pool.

- I would change the summary to "This change adds named elliptic curves 
to the jdk.[tls|certpath|jar].disabledAlgorithms security properties."

- In the Summary and/or Solution sections, you should add that you are 
disabling these legacy curves by default, and add some rationale as to 
why we are doing that. I don't see that specifically mentioned anywhere.

- In the Solution section, missing a period at end of first sentence.

- In the Solution section, there is a typo in the property name 
"jdk.disabled.NamedCurve" (should be plural).

- Typo: "full property name used" -> "full property name is used"

Comments in Specification section:
----------------------------------

1. Change:

+# in jdk.[tls|certpath|jar].disabledAlgorithms.  To include this list 
in any

to:

+# in the jdk.[tls|certpath|jar].disabledAlgorithms properties.  To 
include this list in any

2. We don't support the brainpoolP160r1, brainpoolP192r1, 
brainpoolP224r1 curves, so these don't need to be listed.

3. +# properities.  See the property for details.

Typo: "properties"

--Sean

On 12/9/19 1:10 PM, Anthony Scarpino wrote:
> I need a CSR review for the change with policy and property addition for 
> 8233228.
> 
> https://bugs.openjdk.java.net/browse/JDK-8235540
> 
> Tony
> 

From xuelei.fan at oracle.com  Tue Dec 10 14:01:16 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 10 Dec 2019 06:01:16 -0800
Subject: RFR [14]JDK-8235311, Tag mismatch may alert bad_record_mac
Message-ID: <ebe3c80d-ad3c-2c1c-6717-8bb4db6b83f0@oracle.com>

Hi,

Could I get the following code reviewed?

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

Basically, bad_record_mac alert should be used for AEADBadTagException.

Simple fix, no new regression test.  The TLS fuzzing test confirmed this 
patch.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Tue Dec 10 14:08:44 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 10 Dec 2019 06:08:44 -0800
Subject: RFR[14] JDK-8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently
 with "java.lang.Exception: Unexpected EOF"
In-Reply-To: <3c25caf4-7a6d-2712-9c28-65b8ae76600c@oracle.com>
References: <3c25caf4-7a6d-2712-9c28-65b8ae76600c@oracle.com>
Message-ID: <28f58223-1556-51a7-7bdc-4a6f46750eda@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 12/10/2019 12:29 AM, sha.jiang at oracle.com wrote:
> Hi,
> When the server socket in this test tries to receive close_notify, 
> possibly the client socket is (being) closed.
> 
> Without this patch, this failure was easily reproduced by running the 
> test in a loop.
> With this patch, I didn't reproduce it in the same way.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8231810
> Webrev: http://cr.openjdk.java.net/~jjiang/8231810/webrev.00/
> 
> Best regards,
> John Jiang
> 

From xuelei.fan at oracle.com  Tue Dec 10 14:34:17 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 10 Dec 2019 06:34:17 -0800
Subject: RFR [14] JDK-8235655, Clean the duplicated block in SSLContextImpl
Message-ID: <b95b8831-6f5f-c33a-eee9-01e004597019@oracle.com>

Hi,

Could I get the following code-cleanup patch reviewed?
    cr.openjdk.java.net/~xuelei/8235655/webrev.00

In the SSLContextImpl.java, duplicated arrays are used in the same 
block, which could be simplified.

Simple update, code cleanup, no new regression test.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Tue Dec 10 14:35:57 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 10 Dec 2019 06:35:57 -0800
Subject: RFR [14] JDK-8235655, Clean the duplicated block in SSLContextImpl
In-Reply-To: <b95b8831-6f5f-c33a-eee9-01e004597019@oracle.com>
References: <b95b8831-6f5f-c33a-eee9-01e004597019@oracle.com>
Message-ID: <5ce300bb-e762-bb05-86d9-6aa0fab02cee@oracle.com>



On 12/10/2019 6:34 AM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following code-cleanup patch reviewed?
>  ?? cr.openjdk.java.net/~xuelei/8235655/webrev.00
> 
missing the protocol part:
      http://cr.openjdk.java.net/~xuelei/8235655/webrev.00/

> In the SSLContextImpl.java, duplicated arrays are used in the same 
> block, which could be simplified.
> 
> Simple update, code cleanup, no new regression test.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Tue Dec 10 14:48:59 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Dec 2019 09:48:59 -0500
Subject: RFR [14]JDK-8235311, Tag mismatch may alert bad_record_mac
In-Reply-To: <ebe3c80d-ad3c-2c1c-6717-8bb4db6b83f0@oracle.com>
References: <ebe3c80d-ad3c-2c1c-6717-8bb4db6b83f0@oracle.com>
Message-ID: <47d04301-972a-b4fd-8ff1-38893a8dd47c@oracle.com>

Looks fine to me.

--Sean

On 12/10/19 9:01 AM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following code reviewed?
> 
>  ?? http://cr.openjdk.java.net/~xuelei/8235311/webrev.00/
> 
> Basically, bad_record_mac alert should be used for AEADBadTagException.
> 
> Simple fix, no new regression test.? The TLS fuzzing test confirmed this 
> patch.
> 
> Thanks,
> Xuelei

From sean.coffey at oracle.com  Tue Dec 10 16:08:11 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 10 Dec 2019 16:08:11 +0000
Subject: RFR [14] JDK-8235655, Clean the duplicated block in SSLContextImpl
In-Reply-To: <5ce300bb-e762-bb05-86d9-6aa0fab02cee@oracle.com>
References: <b95b8831-6f5f-c33a-eee9-01e004597019@oracle.com>
 <5ce300bb-e762-bb05-86d9-6aa0fab02cee@oracle.com>
Message-ID: <560bba52-5ec0-5df4-689d-7e8a91f23cb1@oracle.com>

Looks fine to me.

regards,
Sean.

On 10/12/2019 14:35, Xuelei Fan wrote:
>
>
> On 12/10/2019 6:34 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following code-cleanup patch reviewed?
>> ??? cr.openjdk.java.net/~xuelei/8235655/webrev.00
>>
> missing the protocol part:
> ???? http://cr.openjdk.java.net/~xuelei/8235655/webrev.00/
>
>> In the SSLContextImpl.java, duplicated arrays are used in the same 
>> block, which could be simplified.
>>
>> Simple update, code cleanup, no new regression test.
>>
>> Thanks,
>> Xuelei

From sean.mullan at oracle.com  Tue Dec 10 19:10:44 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Dec 2019 14:10:44 -0500
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <e52a0794-1386-489c-bb72-ebb3a38ad977@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
 <e52a0794-1386-489c-bb72-ebb3a38ad977@oracle.com>
Message-ID: <0decd7ed-fbff-e464-dc81-55efe49de551@oracle.com>

On 12/9/19 1:04 PM, Anthony Scarpino wrote:
> I've updated the webrev to address many of the comments.? In particular 
> adding checks when keys given directly.? Also, the changing from 
> legacyEC hardcoded list to a security property jdk.disabled.namedCurves.
> 
> https://cr.openjdk.java.net/~ascarpino/8233228/webrev.01/


* ConstraintsParameters.java

- minor, but toString() could use a StringBuilder to avoid extra String 
allocations.

* DisabledAlgorithmConstraints.java

107             if (s.compareToIgnoreCase(PROPERTY_DISABLED_EC_CURVES) 
== 0) {

or just use s.equalsCaseIgnore() instead.

--Sean



From anthony.scarpino at oracle.com  Tue Dec 10 22:37:38 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 10 Dec 2019 14:37:38 -0800
Subject: CSR RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <0c971d23-59e9-aafe-72ea-603c3850a49f@oracle.com>
References: <f5bf3a1e-e214-8928-8b40-7baf0c7de572@oracle.com>
 <0c971d23-59e9-aafe-72ea-603c3850a49f@oracle.com>
Message-ID: <db629243-80c9-3594-a947-cf9f972762e9@oracle.com>

I believe I have address all the comments in the updated CSR.  I have 
also added the "include" keyword for the new property along with the 
description for it's use.

However, regarding the brainpool curves, the ones you say that we do not 
support are in CurveDB.java.  It was my impression that CurveDB provided 
the parameters to create these named curves.  Where do you see that 
those 3 curves are not supported?

Tony

On 12/10/19 5:57 AM, Sean Mullan wrote:
> In general, this CSR looks good. Here are my specific comments:
> 
> - The Scope should be "JDK" since these are JDK supported security 
> properties.
> 
> - The Fix Version should also include 7-pool.
> 
> - I would change the summary to "This change adds named elliptic curves 
> to the jdk.[tls|certpath|jar].disabledAlgorithms security properties."
> 
> - In the Summary and/or Solution sections, you should add that you are 
> disabling these legacy curves by default, and add some rationale as to 
> why we are doing that. I don't see that specifically mentioned anywhere.
> 
> - In the Solution section, missing a period at end of first sentence.
> 
> - In the Solution section, there is a typo in the property name 
> "jdk.disabled.NamedCurve" (should be plural).
> 
> - Typo: "full property name used" -> "full property name is used"
> 
> Comments in Specification section:
> ----------------------------------
> 
> 1. Change:
> 
> +# in jdk.[tls|certpath|jar].disabledAlgorithms.? To include this list 
> in any
> 
> to:
> 
> +# in the jdk.[tls|certpath|jar].disabledAlgorithms properties.? To 
> include this list in any
> 
> 2. We don't support the brainpoolP160r1, brainpoolP192r1, 
> brainpoolP224r1 curves, so these don't need to be listed.
> 
> 3. +# properities.? See the property for details.
> 
> Typo: "properties"
> 
> --Sean
> 
> On 12/9/19 1:10 PM, Anthony Scarpino wrote:
>> I need a CSR review for the change with policy and property addition 
>> for 8233228.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235540
>>
>> Tony
>>


From sean.mullan at oracle.com  Tue Dec 10 23:00:01 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 10 Dec 2019 18:00:01 -0500
Subject: CSR RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <db629243-80c9-3594-a947-cf9f972762e9@oracle.com>
References: <f5bf3a1e-e214-8928-8b40-7baf0c7de572@oracle.com>
 <0c971d23-59e9-aafe-72ea-603c3850a49f@oracle.com>
 <db629243-80c9-3594-a947-cf9f972762e9@oracle.com>
Message-ID: <a990e67a-2b02-c660-22b0-8d87e442efa6@oracle.com>

On 12/10/19 5:37 PM, Anthony Scarpino wrote:
> I believe I have address all the comments in the updated CSR.? I have 
> also added the "include" keyword for the new property along with the 
> description for it's use.

Great.

> However, regarding the brainpool curves, the ones you say that we do not 
> support are in CurveDB.java.? It was my impression that CurveDB provided 
> the parameters to create these named curves.? Where do you see that 
> those 3 curves are not supported?

If you pass one of these curves to the following code:

         KeyPairGenerator ekpg = KeyPairGenerator.getInstance("EC");
         ECGenParameterSpec spec = new ECGenParameterSpec(curve);
         ekpg.initialize(spec);
         KeyPair kp = ekpg.generateKeyPair();

it will throw the following exception:

java.security.InvalidAlgorithmParameterException: Unsupported curve: 
brainpoolP160r1 (1.3.36.3.3.2.8.1.1.1)
	at 
jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator.ensureCurveIsSupported(ECKeyPairGenerator.java:137)
	at 
jdk.crypto.ec/sun.security.ec.ECKeyPairGenerator.initialize(ECKeyPairGenerator.java:114)
	at 
java.base/java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:699)
	at 
java.base/java.security.KeyPairGenerator.initialize(KeyPairGenerator.java:436)

so I don't think they are really supported. In any case, I have added my 
name as Reviewer to the CSR, but feel free to try to resolve this before 
you submit it.

--Sean

> 
> Tony
> 
> On 12/10/19 5:57 AM, Sean Mullan wrote:
>> In general, this CSR looks good. Here are my specific comments:
>>
>> - The Scope should be "JDK" since these are JDK supported security 
>> properties.
>>
>> - The Fix Version should also include 7-pool.
>>
>> - I would change the summary to "This change adds named elliptic 
>> curves to the jdk.[tls|certpath|jar].disabledAlgorithms security 
>> properties."
>>
>> - In the Summary and/or Solution sections, you should add that you are 
>> disabling these legacy curves by default, and add some rationale as to 
>> why we are doing that. I don't see that specifically mentioned anywhere.
>>
>> - In the Solution section, missing a period at end of first sentence.
>>
>> - In the Solution section, there is a typo in the property name 
>> "jdk.disabled.NamedCurve" (should be plural).
>>
>> - Typo: "full property name used" -> "full property name is used"
>>
>> Comments in Specification section:
>> ----------------------------------
>>
>> 1. Change:
>>
>> +# in jdk.[tls|certpath|jar].disabledAlgorithms.? To include this list 
>> in any
>>
>> to:
>>
>> +# in the jdk.[tls|certpath|jar].disabledAlgorithms properties.? To 
>> include this list in any
>>
>> 2. We don't support the brainpoolP160r1, brainpoolP192r1, 
>> brainpoolP224r1 curves, so these don't need to be listed.
>>
>> 3. +# properities.? See the property for details.
>>
>> Typo: "properties"
>>
>> --Sean
>>
>> On 12/9/19 1:10 PM, Anthony Scarpino wrote:
>>> I need a CSR review for the change with policy and property addition 
>>> for 8233228.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8235540
>>>
>>> Tony
>>>
> 

From anthony.scarpino at oracle.com  Wed Dec 11 05:08:26 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 10 Dec 2019 21:08:26 -0800
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
Message-ID: <3df8d6d6-6af2-816b-d2a5-072feb9e4f72@oracle.com>

Updated webrev:

Includes java.security updates
Max's addition
Sean's comments

http://cr.openjdk.java.net/~ascarpino/8233228/webrev.02/

Tony

From sean.mullan at oracle.com  Wed Dec 11 13:30:01 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 11 Dec 2019 08:30:01 -0500
Subject: [14] RFR: 8234870: Deprecate the OracleUcrypto JCE Provider for
 removal
Message-ID: <17a02e7f-7cc0-c268-7f7e-d98ca9a48145@oracle.com>

Please review this change to deprecate the OracleUcrypto JCE Provider 
for removal. This change is part of JEP 362 (Deprecate the Solaris and 
SPARC Ports) [1], which is Targeted to JDK 14.

Since this Enhancement was referenced from the JEP, I wasn't sure if a 
CSR was strictly necessary, but I drafted one anyway. Please review the 
CSR and diffs below.

CSR: https://bugs.openjdk.java.net/browse/JDK-8235432

Diffs:

diff -r 9b513dbd57a3 src/jdk.crypto.ucrypto/solaris/classes/module-info.java
--- a/src/jdk.crypto.ucrypto/solaris/classes/module-info.java   Wed Dec 
11 14:08:20 2019 +0100
+++ b/src/jdk.crypto.ucrypto/solaris/classes/module-info.java   Wed Dec 
11 08:25:25 2019 -0500
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 2014, 2017, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 2014, 2019, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -29,7 +29,10 @@
   * @provides java.security.Provider
   * @moduleGraph
   * @since 9
+ * @deprecated This module is deprecated and subject to removal in a future
+ *    version of the JDK. See JEP 362 for more information.
   */
+ at Deprecated(since="14", forRemoval=true)
  module jdk.crypto.ucrypto {
      provides java.security.Provider with 
com.oracle.security.ucrypto.UcryptoProvider;
  }

Thanks,
Sean

[1] https://openjdk.java.net/jeps/362

From Alan.Bateman at oracle.com  Wed Dec 11 13:43:27 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2019 13:43:27 +0000
Subject: [14] RFR: 8234870: Deprecate the OracleUcrypto JCE Provider for
 removal
In-Reply-To: <17a02e7f-7cc0-c268-7f7e-d98ca9a48145@oracle.com>
References: <17a02e7f-7cc0-c268-7f7e-d98ca9a48145@oracle.com>
Message-ID: <38130a5b-eb88-d2de-b314-be092b4a358d@oracle.com>

On 11/12/2019 13:30, Sean Mullan wrote:
> Please review this change to deprecate the OracleUcrypto JCE Provider 
> for removal. This change is part of JEP 362 (Deprecate the Solaris and 
> SPARC Ports) [1], which is Targeted to JDK 14.
>
> Since this Enhancement was referenced from the JEP, I wasn't sure if a 
> CSR was strictly necessary, but I drafted one anyway. Please review 
> the CSR and diffs below.
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8235432
This module doesn't export an API so I don't think the warning will ever 
be seen at compile-time. It's also not included in the API docs. So what 
you have is okay but you may find that a release note or other 
documentation will be needed to get the message out. Other idea is to 
add a comment to conf/security/java.security as that will be seen by 
those that edit the security configuration.

-Alan

From sean.mullan at oracle.com  Wed Dec 11 13:57:03 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 11 Dec 2019 08:57:03 -0500
Subject: [14] RFR: 8234870: Deprecate the OracleUcrypto JCE Provider for
 removal
In-Reply-To: <38130a5b-eb88-d2de-b314-be092b4a358d@oracle.com>
References: <17a02e7f-7cc0-c268-7f7e-d98ca9a48145@oracle.com>
 <38130a5b-eb88-d2de-b314-be092b4a358d@oracle.com>
Message-ID: <9a1022ed-19c4-76f0-8961-fa8c5b46d280@oracle.com>

On 12/11/19 8:43 AM, Alan Bateman wrote:
> On 11/12/2019 13:30, Sean Mullan wrote:
>> Please review this change to deprecate the OracleUcrypto JCE Provider 
>> for removal. This change is part of JEP 362 (Deprecate the Solaris and 
>> SPARC Ports) [1], which is Targeted to JDK 14.
>>
>> Since this Enhancement was referenced from the JEP, I wasn't sure if a 
>> CSR was strictly necessary, but I drafted one anyway. Please review 
>> the CSR and diffs below.
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8235432
> This module doesn't export an API so I don't think the warning will ever 
> be seen at compile-time. It's also not included in the API docs. So what 
> you have is okay but you may find that a release note or other 
> documentation will be needed to get the message out.

Yes, a release note will be published and the deprecation notice will be 
added to the OracleUcrypto section of the JDK Providers Guide.

> Other idea is to 
> add a comment to conf/security/java.security as that will be seen by 
> those that edit the security configuration.

Good idea. I have added the following:

diff -r 9b513dbd57a3 src/java.base/share/conf/security/java.security
--- a/src/java.base/share/conf/security/java.security   Wed Dec 11 
14:08:20 2019 +0100
+++ b/src/java.base/share/conf/security/java.security   Wed Dec 11 
08:55:59 2019 -0500
@@ -61,6 +61,8 @@
  # List of providers and their preference orders (see above):
  #
  #ifdef solaris
+# Note: The OracleUcrypto provider is deprecated and subject to removal in
+# a future version of the JDK. See JEP 362 for more information.
  security.provider.tbd=OracleUcrypto
  security.provider.tbd=SunPKCS11 
${java.home}/conf/security/sunpkcs11-solaris.cfg
  #endif

--Sean

From Alan.Bateman at oracle.com  Wed Dec 11 14:22:10 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 11 Dec 2019 14:22:10 +0000
Subject: [14] RFR: 8234870: Deprecate the OracleUcrypto JCE Provider for
 removal
In-Reply-To: <9a1022ed-19c4-76f0-8961-fa8c5b46d280@oracle.com>
References: <17a02e7f-7cc0-c268-7f7e-d98ca9a48145@oracle.com>
 <38130a5b-eb88-d2de-b314-be092b4a358d@oracle.com>
 <9a1022ed-19c4-76f0-8961-fa8c5b46d280@oracle.com>
Message-ID: <34412c6b-6342-1900-32cf-65ed3a95cb2f@oracle.com>

On 11/12/2019 13:57, Sean Mullan wrote:
>
> Good idea. I have added the following:
>
> diff -r 9b513dbd57a3 src/java.base/share/conf/security/java.security
> --- a/src/java.base/share/conf/security/java.security?? Wed Dec 11 
> 14:08:20 2019 +0100
> +++ b/src/java.base/share/conf/security/java.security?? Wed Dec 11 
> 08:55:59 2019 -0500
> @@ -61,6 +61,8 @@
> ?# List of providers and their preference orders (see above):
> ?#
> ?#ifdef solaris
> +# Note: The OracleUcrypto provider is deprecated and subject to 
> removal in
> +# a future version of the JDK. See JEP 362 for more information.
> ?security.provider.tbd=OracleUcrypto
> ?security.provider.tbd=SunPKCS11 
> ${java.home}/conf/security/sunpkcs11-solaris.cfg
> ?#endif
Good, I think I'll probably just use the first line as the JEP won't say 
when it will be removed.

-Alan

From sean.mullan at oracle.com  Wed Dec 11 17:58:46 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 11 Dec 2019 12:58:46 -0500
Subject: [14] RFR: 8233228: Support named curves for all disabledAlgorithms
In-Reply-To: <3df8d6d6-6af2-816b-d2a5-072feb9e4f72@oracle.com>
References: <e479b6c6-6876-86d5-214e-0948f3bf6f44@oracle.com>
 <3df8d6d6-6af2-816b-d2a5-072feb9e4f72@oracle.com>
Message-ID: <5749c628-a337-9737-bcbf-792f055fc47e@oracle.com>

Looks good.

--Sean

On 12/11/19 12:08 AM, Anthony Scarpino wrote:
> Updated webrev:
> 
> Includes java.security updates
> Max's addition
> Sean's comments
> 
> http://cr.openjdk.java.net/~ascarpino/8233228/webrev.02/
> 
> Tony

From mbalao at redhat.com  Wed Dec 11 19:36:19 2019
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 11 Dec 2019 16:36:19 -0300
Subject: RFR 8005819: Support cross-realm MSSFU
In-Reply-To: <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>
References: <b48121ca-f8a0-046e-816c-2e9e4a6c3544@redhat.com>
 <db10fd96-b762-c9b1-90ff-727aa727f699@redhat.com>
 <cbfd659a-68b5-df7e-7e17-2c77d4d5da1d@siemens.com>
 <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
 <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>
Message-ID: <1d5893fb-a16a-1d3c-696d-904c99af8ae7@redhat.com>

Hi Max,

Thanks for reviewing this proposal.

On 12/6/19 5:27 AM, Weijun Wang wrote:

> 1. Can we change the signature of handleS4U2ProxyReferral so that there is only one credsInOut?
> 
>    String handleS4U2ProxyReferral(Credentials asCreds,
>         Credentials[] credsInOut, PrincipalName sname)
> 
> and call it with "new Credentials[] {creds, null}"?
> 
> Then you can clearly specify
> 
>   input: first referral TGT for S4U2proxy, null
>   output: service's final referral TGT, client's final referral TGT
> 

Yes, sure.

> 2. Can we add a S4U2Type argument in serviceCreds(options,...)? Then its callers can specify it directly and there is no need for this method to guess it out.
> 

Yes, sure.

Webrev.04 has all of the above and better error handling when
Config.DISABLE_REFERRALS is true:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.04/

Note: Webrev.03 was never publicly proposed. Contained "better error
handling when Config.DISABLE_REFERRALS is true" part only.

Testing: no regressions found in jdk/sun/security/krb5. Did some
additional regression testing in my internal environment.

Are we good to go?

> p.s. Something related but not for this enhancement. The getTGTforRealm method should not call Realm.getRealmsList() (i.e. use [capaths] in krb5.conf) when using referral. It should just follow the referral.
> 

We can discuss this in the context of a different enhancement/fix. My
understanding is that even though Realm.getRealmsList is called
(potentially returning a path with different realms based on capath or
the domains hierarchy), RFC 6806 referrals may be just followed up at
any point of the path queries if available. This means that there is a
chance that one or more realms in the path returned by getRealmsList are
ignored.

Regards,
Martin.-


From weijun.wang at oracle.com  Thu Dec 12 01:07:36 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 12 Dec 2019 09:07:36 +0800
Subject: RFR 8005819: Support cross-realm MSSFU
In-Reply-To: <1d5893fb-a16a-1d3c-696d-904c99af8ae7@redhat.com>
References: <b48121ca-f8a0-046e-816c-2e9e4a6c3544@redhat.com>
 <db10fd96-b762-c9b1-90ff-727aa727f699@redhat.com>
 <cbfd659a-68b5-df7e-7e17-2c77d4d5da1d@siemens.com>
 <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
 <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>
 <1d5893fb-a16a-1d3c-696d-904c99af8ae7@redhat.com>
Message-ID: <A9AB7A78-AB3D-4774-AB9C-3E3AAFB72A50@oracle.com>

This looks good to me.

There is one confusion. I understand that handleS4U2ProxyReferral needs an in/out creds argument, but for serviceCredsReferrals the additionalTickets argument should only be in, right? However in this method you've modified the content of it after calling handleS4U2ProxyReferral. This is not fatal because it won't have any effect higher than acquireS4U2proxyCreds, but it does introduce an in/out argument to the serviceCreds/serviceCredsReferrals methods.

Anyway, even if this is worth amending we can fix it after RDP1 with a different issue.

Thanks,
Max

> On Dec 12, 2019, at 3:36 AM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Hi Max,
> 
> Thanks for reviewing this proposal.
> 
> On 12/6/19 5:27 AM, Weijun Wang wrote:
> 
>> 1. Can we change the signature of handleS4U2ProxyReferral so that there is only one credsInOut?
>> 
>>   String handleS4U2ProxyReferral(Credentials asCreds,
>>        Credentials[] credsInOut, PrincipalName sname)
>> 
>> and call it with "new Credentials[] {creds, null}"?
>> 
>> Then you can clearly specify
>> 
>>  input: first referral TGT for S4U2proxy, null
>>  output: service's final referral TGT, client's final referral TGT
>> 
> 
> Yes, sure.
> 
>> 2. Can we add a S4U2Type argument in serviceCreds(options,...)? Then its callers can specify it directly and there is no need for this method to guess it out.
>> 
> 
> Yes, sure.
> 
> Webrev.04 has all of the above and better error handling when
> Config.DISABLE_REFERRALS is true:
> 
> * http://cr.openjdk.java.net/~mbalao/webrevs/8005819/8005819.webrev.04/
> 
> Note: Webrev.03 was never publicly proposed. Contained "better error
> handling when Config.DISABLE_REFERRALS is true" part only.
> 
> Testing: no regressions found in jdk/sun/security/krb5. Did some
> additional regression testing in my internal environment.
> 
> Are we good to go?
> 
>> p.s. Something related but not for this enhancement. The getTGTforRealm method should not call Realm.getRealmsList() (i.e. use [capaths] in krb5.conf) when using referral. It should just follow the referral.
>> 
> 
> We can discuss this in the context of a different enhancement/fix. My
> understanding is that even though Realm.getRealmsList is called
> (potentially returning a path with different realms based on capath or
> the domains hierarchy), RFC 6806 referrals may be just followed up at
> any point of the path queries if available. This means that there is a
> chance that one or more realms in the path returned by getRealmsList are
> ignored.
> 
> Regards,
> Martin.-
> 


From weijun.wang at oracle.com  Thu Dec 12 01:21:38 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 12 Dec 2019 09:21:38 +0800
Subject: RFR 8234465: Encoded elliptic curve private keys should include
 the public point
In-Reply-To: <7289127A-15C5-4D04-8726-3D0EC52FAC64@oracle.com>
References: <7289127A-15C5-4D04-8726-3D0EC52FAC64@oracle.com>
Message-ID: <5C854316-BCF2-4156-9487-B4E2A80CE1E6@oracle.com>

Ping again. This is an enhancement.

> On Dec 10, 2019, at 5:45 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please review the code change at
> 
>   http://cr.openjdk.java.net/~weijun/8234465/webrev.00/
> 
> The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly generated, a copy of the ECPoint of the public key is put inside the private key. This ECPoint can be stored in a PKCS #8 file. When reading from a PKCS #8 file, it can also be loaded.
> 
> Since the ECPrivateKey class interface and the ECPrivateKeySpec spec do not have the public ECPoint, an ECPrivateKeyImpl will not have this info when created from these sources. So it's still optional. I haven't tried to calculate it.
> 
> Thanks,
> Max
> 


From xuelei.fan at oracle.com  Thu Dec 12 01:38:58 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 11 Dec 2019 17:38:58 -0800
Subject: RFR 8234465: Encoded elliptic curve private keys should include
 the public point
In-Reply-To: <5C854316-BCF2-4156-9487-B4E2A80CE1E6@oracle.com>
References: <7289127A-15C5-4D04-8726-3D0EC52FAC64@oracle.com>
 <5C854316-BCF2-4156-9487-B4E2A80CE1E6@oracle.com>
Message-ID: <daf4868c-d8d0-5360-5764-f35622a087ef@oracle.com>

What do you think about the compatibility impact?  Minimal?

In the ECPrivateKeyImpl.parseKeyBits() implementation, a while() loop is 
used.  As make it possible to pass publicKey before parameters.  Beside, 
I would check if the encoded parameter is valid or not.  They're not 
new, you can leave it as it is.

Otherwise, looks good to me.

Xuelei


On 12/11/2019 5:21 PM, Weijun Wang wrote:
> Ping again. This is an enhancement.
> 
>> On Dec 10, 2019, at 5:45 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Please review the code change at
>>
>>    http://cr.openjdk.java.net/~weijun/8234465/webrev.00/
>>
>> The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly generated, a copy of the ECPoint of the public key is put inside the private key. This ECPoint can be stored in a PKCS #8 file. When reading from a PKCS #8 file, it can also be loaded.
>>
>> Since the ECPrivateKey class interface and the ECPrivateKeySpec spec do not have the public ECPoint, an ECPrivateKeyImpl will not have this info when created from these sources. So it's still optional. I haven't tried to calculate it.
>>
>> Thanks,
>> Max
>>
> 

From weijun.wang at oracle.com  Thu Dec 12 03:02:05 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 12 Dec 2019 11:02:05 +0800
Subject: RFR 8234465: Encoded elliptic curve private keys should include
 the public point
In-Reply-To: <daf4868c-d8d0-5360-5764-f35622a087ef@oracle.com>
References: <7289127A-15C5-4D04-8726-3D0EC52FAC64@oracle.com>
 <5C854316-BCF2-4156-9487-B4E2A80CE1E6@oracle.com>
 <daf4868c-d8d0-5360-5764-f35622a087ef@oracle.com>
Message-ID: <4AC1B5E4-6D29-430C-8508-E4FBCF19228B@oracle.com>



> On Dec 12, 2019, at 9:38 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> What do you think about the compatibility impact?  Minimal?

I think the major compatibility impact is that ECUtil::decodePoint will throw an exception if the public ECPoint inside is invalid, but I think we shouldn't ignore it. 

Otherwise, the point read can now only be used to write back into a PKCS8 file and not used elsewhere.

> 
> In the ECPrivateKeyImpl.parseKeyBits() implementation, a while() loop is used.  As make it possible to pass publicKey before parameters.  Beside, I would check if the encoded parameter is valid or not.  They're not new, you can leave it as it is.

Yes, this is not complete, and it allows duplicated entries.

Thanks,
Max

> 
> Otherwise, looks good to me.
> 
> Xuelei
> 
> 
> On 12/11/2019 5:21 PM, Weijun Wang wrote:
>> Ping again. This is an enhancement.
>>> On Dec 10, 2019, at 5:45 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Please review the code change at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8234465/webrev.00/
>>> 
>>> The fix is mostly inside ECPrivateKeyImpl. When an EC keypair is newly generated, a copy of the ECPoint of the public key is put inside the private key. This ECPoint can be stored in a PKCS #8 file. When reading from a PKCS #8 file, it can also be loaded.
>>> 
>>> Since the ECPrivateKey class interface and the ECPrivateKeySpec spec do not have the public ECPoint, an ECPrivateKeyImpl will not have this info when created from these sources. So it's still optional. I haven't tried to calculate it.
>>> 
>>> Thanks,
>>> Max
>>> 


From sibabrata.sahoo at oracle.com  Thu Dec 12 10:25:22 2019
From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com)
Date: Thu, 12 Dec 2019 15:55:22 +0530
Subject: [14]RFR: 8234728: Some security tests should support TLSv1.3
Message-ID: <F828D06F-F6B1-44DA-8550-8E2A826E8B9E@oracle.com>

Hi Xuelei,

Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8234728 <https://bugs.openjdk.java.net/browse/JDK-8234728>
Webrev: http://cr.openjdk.java.net/~ssahoo/8234728/webrev.00/ <http://cr.openjdk.java.net/~ssahoo/8234728/webrev.00/>

Change:
The change it to support few of Tests to support TLSv1.3. Additionally 2 new Tests are added to verify CipherSuites order.
- javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java follows the CipherSuite order from "open/src/java.base/share/classes/sun/security/ssl/CipherSuite.java?. @ignore Tag has been removed and the test has been activated. Few comment correction made in ?open/src/java.base/share/classes/sun/security/ssl/CipherSuite.java? too.
- sun/security/util/HostnameMatcher/NullHostnameCheck.java, I changed the keystore to use RSA generated keys instead of DSA to support TLSv1.3.
-There are 2 new Test files to verify Cipher Suites order. I have kept "javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java? with @ignore tag until the bug is fixed in JDK. Have you created any JBS for it, else I can create it.

Thanks,
Siba



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191212/c8c8e727/attachment.htm>

From mbalao at redhat.com  Thu Dec 12 14:46:38 2019
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 12 Dec 2019 11:46:38 -0300
Subject: RFR 8005819: Support cross-realm MSSFU
In-Reply-To: <A9AB7A78-AB3D-4774-AB9C-3E3AAFB72A50@oracle.com>
References: <b48121ca-f8a0-046e-816c-2e9e4a6c3544@redhat.com>
 <db10fd96-b762-c9b1-90ff-727aa727f699@redhat.com>
 <cbfd659a-68b5-df7e-7e17-2c77d4d5da1d@siemens.com>
 <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
 <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>
 <1d5893fb-a16a-1d3c-696d-904c99af8ae7@redhat.com>
 <A9AB7A78-AB3D-4774-AB9C-3E3AAFB72A50@oracle.com>
Message-ID: <36d5a34c-ee53-dbd5-1c6d-6c884a90dcb9@redhat.com>

On 12/11/19 10:07 PM, Weijun Wang wrote:
> This looks good to me.

Great!

> 
> There is one confusion. I understand that handleS4U2ProxyReferral needs an in/out creds argument, but for serviceCredsReferrals the additionalTickets argument should only be in, right? However in this method you've modified the content of it after calling handleS4U2ProxyReferral. This is not fatal because it won't have any effect higher than acquireS4U2proxyCreds, but it does introduce an in/out argument to the serviceCreds/serviceCredsReferrals methods.
> 
> Anyway, even if this is worth amending we can fix it after RDP1 with a different issue.
> 

Good observation. I've had a look and you are probably right. The in/out
parameter is spread across all the code. Looks to me that, at some
point, the idea was that there could be more than one additional ticket
(and it was not an in/out parameter really). What makes me think so is
the iteration here [1]. Given that this is not particularly related to
8005819, I agree that it would be better to analyze it in the context of
a new fix. Before getting rid of the in/out parameter, I suggest to
decide whether or not there could be more than one ticket.

--
[1] -
http://hg.openjdk.java.net/jdk/jdk/file/fe65e995a765/src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCReqBody.java#l113


From xuelei.fan at oracle.com  Thu Dec 12 21:58:56 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 12 Dec 2019 13:58:56 -0800
Subject: [14]RFR: 8234728: Some security tests should support TLSv1.3
In-Reply-To: <F828D06F-F6B1-44DA-8550-8E2A826E8B9E@oracle.com>
References: <F828D06F-F6B1-44DA-8550-8E2A826E8B9E@oracle.com>
Message-ID: <53ecaef7-ec57-5f54-6d5a-61269040b37f@oracle.com>

Looks good to me.

Thanks,
Xuelei

On 12/12/2019 2:25 AM, sibabrata.sahoo at oracle.com wrote:
> Hi Xuelei,
> 
> Please review the patch for,
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234728
> Webrev: http://cr.openjdk.java.net/~ssahoo/8234728/webrev.00/
> 
> Change:
> The change it to support few of Tests to support TLSv1.3. Additionally 2 
> new Tests are added to verify CipherSuites order.
> - javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java?follows the 
> CipherSuite order from 
> "open/src/java.base/share/classes/sun/security/ssl/CipherSuite.java?. 
> @ignore Tag has been removed and the test has been activated. Few 
> comment correction made in 
> ?open/src/java.base/share/classes/sun/security/ssl/CipherSuite.java? too.
> -?sun/security/util/HostnameMatcher/NullHostnameCheck.java, I changed 
> the keystore to use RSA generated keys instead of DSA to support TLSv1.3.
> -There are 2 new Test files to verify Cipher Suites order. I have kept 
> "javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java? 
> with @ignore tag until the bug is fixed in JDK. Have you created any JBS 
> for it, else I can create it.
> 
> Thanks,
> Siba
> 
> 
> 

From weijun.wang at oracle.com  Thu Dec 12 23:32:17 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 13 Dec 2019 07:32:17 +0800
Subject: RFR 8005819: Support cross-realm MSSFU
In-Reply-To: <36d5a34c-ee53-dbd5-1c6d-6c884a90dcb9@redhat.com>
References: <b48121ca-f8a0-046e-816c-2e9e4a6c3544@redhat.com>
 <db10fd96-b762-c9b1-90ff-727aa727f699@redhat.com>
 <cbfd659a-68b5-df7e-7e17-2c77d4d5da1d@siemens.com>
 <12d309a6-bf97-cbc7-4f86-46c16f554583@redhat.com>
 <CEAF202D-FC33-4CC3-BA81-7420151F2DCF@oracle.com>
 <1d5893fb-a16a-1d3c-696d-904c99af8ae7@redhat.com>
 <A9AB7A78-AB3D-4774-AB9C-3E3AAFB72A50@oracle.com>
 <36d5a34c-ee53-dbd5-1c6d-6c884a90dcb9@redhat.com>
Message-ID: <8689B67F-2389-449D-BF29-642142006FE1@oracle.com>



> On Dec 12, 2019, at 10:46 PM, Martin Balao <mbalao at redhat.com> wrote:
> 
> Good observation. I've had a look and you are probably right. The in/out
> parameter is spread across all the code. Looks to me that, at some
> point, the idea was that there could be more than one additional ticket
> (and it was not an in/out parameter really). What makes me think so is
> the iteration here [1]. Given that this is not particularly related to
> 8005819, I agree that it would be better to analyze it in the context of
> a new fix. Before getting rid of the in/out parameter, I suggest to
> decide whether or not there could be more than one ticket.

I've only seen the one ticket case, but in the ASN.1 definition of KDC-REQ-BODY there can be multiple. Maybe one day we'll see more.

--Max

> 
> --
> [1] -
> http://hg.openjdk.java.net/jdk/jdk/file/fe65e995a765/src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCReqBody.java#l113
> 


From sibabrata.sahoo at oracle.com  Fri Dec 13 08:09:57 2019
From: sibabrata.sahoo at oracle.com (sibabrata.sahoo at oracle.com)
Date: Fri, 13 Dec 2019 13:39:57 +0530
Subject: =?utf-8?Q?=5B14=5D=3ARFR=3A8235874=3A_The_ordering_of_Cipher_Suit?=
 =?utf-8?Q?es_is_not_maintained_provided_through_=E2=80=9Cjdk=2Etls=2Eclie?=
 =?utf-8?Q?nt=2EcipherSuites=E2=80=9D_and_=E2=80=9Cjdk=2Etls=2Eserver=2Eci?=
 =?utf-8?Q?pherSuites=E2=80=9D_system_property=2E?=
Message-ID: <C4422649-1B23-41ED-8C33-FE77AFB0413F@oracle.com>

Hi,

Please review the patch for,
JBS: https://bugs.openjdk.java.net/browse/JDK-8235874 <https://bugs.openjdk.java.net/browse/JDK-8235874>
Webrev: http://cr.openjdk.java.net/~ssahoo/8235874/webrev.00/ <http://cr.openjdk.java.net/~ssahoo/8235874/webrev.00/>

This is a small fix to maintain the ordering of cipher suites provided through system property ?jdk.tls.client.cipherSuites? and ?jdk.tls.server.cipherSuites?.

Thanks,
Siba



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191213/cd7277e1/attachment.htm>

From sean.mullan at oracle.com  Fri Dec 13 16:07:43 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 13 Dec 2019 11:07:43 -0500
Subject: RFR 8234697: Generate sun.security.util.math.intpoly classes
 during build
In-Reply-To: <45B0C9E5-D729-470C-ADA4-524204317164@oracle.com>
References: <1A12CB42-2986-4C32-A53C-121E0C69A569@oracle.com>
 <50fcb0b6-b88b-81f7-8568-e5d8018fcd03@oracle.com>
 <45B0C9E5-D729-470C-ADA4-524204317164@oracle.com>
Message-ID: <9023686d-b1df-aa41-9959-41ba79aca25e@oracle.com>

Looks ok to me.

--Sean

On 12/4/19 9:49 PM, Weijun Wang wrote:
> Ping the security side.
> 
>> On Nov 26, 2019, at 12:36 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>
>> Build change looks good.
>>
>> /Erik
>>
>> On 2019-11-22 18:59, Weijun Wang wrote:
>>> Please review the change at
>>>
>>>     http://cr.openjdk.java.net/~weijun/8234697/webrev.00/
>>>
>>> The new lines in Gensrc-java.base.gmk mimics the one for CLDR_GEN_DONE at the beginning of the same file.
>>>
>>> I changed the BigInteger parameter in the FieldParams constructor (the one not reading terms) to its HEX string form and is now using the inverse. This makes sure the strings appeared here are exactly the same as the one used in CurveDB.java. The generated source code is identical to before.
>>>
>>> Other smaller changes made to FieldGen.jsh:
>>>
>>> 1. Package name
>>> 2. No more jshell, but now Java
>>> 3. Input/output paths as args for main()
>>> 4. White spaces, wrapping and indentation
>>>
>>> Thanks,
>>> Max
>>>
> 

From xuelei.fan at oracle.com  Fri Dec 13 16:52:36 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 13 Dec 2019 08:52:36 -0800
Subject: =?UTF-8?Q?Re=3a_=5b14=5d=3aRFR=3a8235874=3a_The_ordering_of_Cipher_?=
 =?UTF-8?Q?Suites_is_not_maintained_provided_through_=e2=80=9cjdk=2etls=2ecl?=
 =?UTF-8?B?aWVudC5jaXBoZXJTdWl0ZXPigJ0gYW5kIOKAnGpkay50bHMuc2VydmVyLmNpcGhl?=
 =?UTF-8?Q?rSuites=e2=80=9d_system_property=2e?=
In-Reply-To: <C4422649-1B23-41ED-8C33-FE77AFB0413F@oracle.com>
References: <C4422649-1B23-41ED-8C33-FE77AFB0413F@oracle.com>
Message-ID: <afaffb1c-08ce-1dea-c841-b56557c03318@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 12/13/2019 12:09 AM, sibabrata.sahoo at oracle.com wrote:
> Hi,
> 
> Please review the patch for,
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235874
> Webrev: http://cr.openjdk.java.net/~ssahoo/8235874/webrev.00/
> 
> This is a small fix to maintain the ordering of cipher suites provided 
> through system property??jdk.tls.client.cipherSuites? and 
> ?jdk.tls.server.cipherSuites?.
> 
> Thanks,
> Siba

From sha.jiang at oracle.com  Mon Dec 16 02:09:07 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 16 Dec 2019 10:09:07 +0800
Subject: RFR[14] JDK-8235813: System property fullCipherSuites is not used by
 javax/net/ssl/compatibility/Compatibility.java
Message-ID: <72b685cb-2fa5-4a4e-32ba-54b8ed3b09e3@oracle.com>

Hi,
javax/net/ssl/compatibility/Compatibility.java should use property 
fullCipherSuites to indicate if testing all of specific cipher suites.
In addition, the cases on TLS_ECDH_RSA cipher suites fail due to a 
RSA-signed EC key certificate has something wrong.

Issue: https://bugs.openjdk.java.net/browse/JDK-8235813
Webrev: http://cr.openjdk.java.net/~jjiang/8235813/webrev.00/

Best regards,
John Jiang


From martinrb at google.com  Mon Dec 16 02:44:02 2019
From: martinrb at google.com (Martin Buchholz)
Date: Sun, 15 Dec 2019 18:44:02 -0800
Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple
 definition" link errors
In-Reply-To: <MN2PR01MB609340237C91026379A363248F540@MN2PR01MB6093.prod.exchangelabs.com>
References: <MN2PR01MB609340237C91026379A363248F540@MN2PR01MB6093.prod.exchangelabs.com>
Message-ID: <CA+kOe0_D1sZNq5USp8PO4nLO2TvRj=E9KRU31x87Nua7VgB3DA@mail.gmail.com>

forwarded to other teams for review.

On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <
patrick at os.amperecomputing.com> wrote:

> Hi
>
> Please review this patch, if it should be reviewed by any group other than
> core-libs, please help forward it. Thanks.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
> Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/
>
> A recent GCC patch (supposed to be in GCC 10) exposes a couple of
> "multiple definition" link errors when building the jdk tip.
>
> [PATCH] PR85678: Change default to -fno-common
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html
>
> For example, the error message looks like:
> * For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
> build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple
> definition of `parentPathv'
> build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first
> defined here
> collect2: error: ld returned 1 exit status
>
> This was not an issue because the original default -fcommon allowed
> "global variables defined without an initializer" be handled as COMMON
> symbols, so it would not warn the problem like "same variable is
> accidentally defined in more than one compilation unit".
>
> About -fcommon vs -fno-cmmon:
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common
>
> Moving forward, building jdk with latest versions of GCC will trigger this
> error. Specifying "--with-extra-cflags='-fcommon'"  can make it work, but
> it just got things hidden again.
>
> In addition, -fcommon's behavior "is inconsistent with C++, and on many
> targets implies a speed and code size penalty on global variable
> references. It is mainly useful to enable legacy code to link without
> errors."
>
> Last, in case that other jdk developers would revisit this problem once
> again, I suggest fixing the error explicitly instead of using "-fcommon"
>
> Regards
> Patrick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191215/fdac0564/attachment.htm>

From Xuelei.Fan at Oracle.Com  Mon Dec 16 03:22:09 2019
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Sun, 15 Dec 2019 19:22:09 -0800
Subject: RFR[14] JDK-8235813: System property fullCipherSuites is not used
 by javax/net/ssl/compatibility/Compatibility.java
In-Reply-To: <72b685cb-2fa5-4a4e-32ba-54b8ed3b09e3@oracle.com>
References: <72b685cb-2fa5-4a4e-32ba-54b8ed3b09e3@oracle.com>
Message-ID: <97CB2DC6-83CB-4F8A-8E7F-FDED77156201@Oracle.Com>

I think the property is for test code only, is it?

The update looks fine to me.

Xuelei 

> On Dec 15, 2019, at 6:09 PM, sha.jiang at oracle.com wrote:
> 
> Hi,
> javax/net/ssl/compatibility/Compatibility.java should use property fullCipherSuites to indicate if testing all of specific cipher suites.
> In addition, the cases on TLS_ECDH_RSA cipher suites fail due to a RSA-signed EC key certificate has something wrong.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8235813
> Webrev: http://cr.openjdk.java.net/~jjiang/8235813/webrev.00/
> 
> Best regards,
> John Jiang
> 


From sha.jiang at oracle.com  Mon Dec 16 06:28:05 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 16 Dec 2019 14:28:05 +0800
Subject: RFR[14] JDK-8235813: System property fullCipherSuites is not used
 by javax/net/ssl/compatibility/Compatibility.java
In-Reply-To: <97CB2DC6-83CB-4F8A-8E7F-FDED77156201@Oracle.Com>
References: <72b685cb-2fa5-4a4e-32ba-54b8ed3b09e3@oracle.com>
 <97CB2DC6-83CB-4F8A-8E7F-FDED77156201@Oracle.Com>
Message-ID: <ddb720c0-cdc3-3c2c-f374-be300811556c@oracle.com>

Hi Xuelei,

On 2019/12/16 11:22, Xuelei Fan wrote:
> I think the property is for test code only, is it?
Yes. It is only used by this test.

>
> The update looks fine to me.
Thanks!

Best regards,
John Jiang
>
> Xuelei
>
>> On Dec 15, 2019, at 6:09 PM, sha.jiang at oracle.com wrote:
>>
>> Hi,
>> javax/net/ssl/compatibility/Compatibility.java should use property fullCipherSuites to indicate if testing all of specific cipher suites.
>> In addition, the cases on TLS_ECDH_RSA cipher suites fail due to a RSA-signed EC key certificate has something wrong.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8235813
>> Webrev: http://cr.openjdk.java.net/~jjiang/8235813/webrev.00/
>>
>> Best regards,
>> John Jiang
>>
>

From sean.coffey at oracle.com  Mon Dec 16 14:15:42 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 16 Dec 2019 14:15:42 +0000
Subject: RFR: 8234466: Class loading deadlock involving
 X509Factory#commitEvent()
Message-ID: <bda8519c-a77c-cc10-5874-5da552cd9c75@oracle.com>

The recent crypto event logging mechanism (JDK-8148188) has introduced a 
regression whereby the System Logger may be invoked too early in the 
bootstrap phase. This causes issue when JarFile objects are locked by 
JarFile verifier initialization code. The logging work records an X509 
Certificate which is used during the jar file 
verification/initialization phase and hence leads to an early 
System.Logger call.

One thread invokes the initialization of the Logger framework via 
ServiceLoader and waits to lock a JarFile in use via another thread. 
Unfortunately that other thread is also waiting for the System Logger to 
initialize. For now, I think we can avoid the early Logger 
initialization via use of a ThreadLocal. I've tried reproducing the 
reported issue through manual and automated tests but to no avail. I've 
added a new ServiceLoader test which has concurrent threads. One is 
loading providers and another is initializing JarFile verifiers. Hope it 
helps improve code coverage for the future.

JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/

-- 
Regards,
Sean.


From mbalao at redhat.com  Mon Dec 16 16:19:27 2019
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 16 Dec 2019 13:19:27 -0300
Subject: TLS 1.3: support for status_request extension in CertificateRequest
 messages
Message-ID: <d4fbe2d8-04cc-7ad0-22e1-13d0655f544a@redhat.com>

Hi all,

Looks to me that OpenJDK's TLS 1.3 implementation is not supporting
status_request extension in CertificateRequest messages [1]. This is
specified in RFC 8446 at section "4.4.2.1. OCSP Status and
SCT Extensions" [2]:

"A server MAY request that a client present an OCSP response with its
certificate by sending an empty "status_request" extension in its
CertificateRequest message.  If the client opts to send an OCSP
response, the body of its "status_request" extension MUST be a
CertificateStatus structure as defined in [RFC6066]."

Note: It's unclear to me why the RFC 8446 requires the status_request
extension to be empty when available in the CertificateRequest the
server sends to the client. Would have made more sense to me if the
extension where the same than in a ClientHello message.

A compatibility issue has been raised by golang people here [3].

My questions are:

 1) is there a reason why this was not implemented?

 2) in case there is not, is this on your roadmap or would you be
interested in a fix proposal?

Apologies if this has been discussed already, but couldn't find anything
on this list.

Thanks,
Martin.-

--
[1] -
https://hg.openjdk.java.net/jdk/jdk/file/de152e6a99a5/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#l98
[2] - https://tools.ietf.org/html/rfc8446#section-4.4.2.1
[3] - https://github.com/golang/go/issues/35722


From jamil.j.nimeh at oracle.com  Mon Dec 16 17:29:59 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 16 Dec 2019 09:29:59 -0800
Subject: TLS 1.3: support for status_request extension in
 CertificateRequest messages
In-Reply-To: <d4fbe2d8-04cc-7ad0-22e1-13d0655f544a@redhat.com>
References: <d4fbe2d8-04cc-7ad0-22e1-13d0655f544a@redhat.com>
Message-ID: <21527c15-fce6-71f5-7338-6759ebd77536@oracle.com>

It wasn't implemented primarily for time considerations during the 
initial TLS 1.3 implementation.? I had planned to go back at some point 
and add support for it.? It's the wrong thing to have an alert thrown by 
the client if the extension is present, since it's legal to have in TLS 
1.3.? Our client should have just omitted the response in-band but 
continued with the handshake.

If you want to take a swing at it, go for it.? I'd be happy to be a 
reviewer for it.

I agree about the empty nature of the extension...it seems like if and 
endpoint - server or client - is initiating status_request, then you 
might want to put responder IDs or other OCSP extensions in it, just as 
you would in the CH.? But I don't see anything yet in the errata 
relating to this.? It's probably best to just go right along with the 
spec.? I think that was what the Go folks were doing.

--Jamil

On 12/16/2019 8:19 AM, Martin Balao wrote:
> Hi all,
>
> Looks to me that OpenJDK's TLS 1.3 implementation is not supporting
> status_request extension in CertificateRequest messages [1]. This is
> specified in RFC 8446 at section "4.4.2.1. OCSP Status and
> SCT Extensions" [2]:
>
> "A server MAY request that a client present an OCSP response with its
> certificate by sending an empty "status_request" extension in its
> CertificateRequest message.  If the client opts to send an OCSP
> response, the body of its "status_request" extension MUST be a
> CertificateStatus structure as defined in [RFC6066]."
>
> Note: It's unclear to me why the RFC 8446 requires the status_request
> extension to be empty when available in the CertificateRequest the
> server sends to the client. Would have made more sense to me if the
> extension where the same than in a ClientHello message.
>
> A compatibility issue has been raised by golang people here [3].
>
> My questions are:
>
>   1) is there a reason why this was not implemented?
>
>   2) in case there is not, is this on your roadmap or would you be
> interested in a fix proposal?
>
> Apologies if this has been discussed already, but couldn't find anything
> on this list.
>
> Thanks,
> Martin.-
>
> --
> [1] -
> https://hg.openjdk.java.net/jdk/jdk/file/de152e6a99a5/src/java.base/share/classes/sun/security/ssl/SSLExtension.java#l98
> [2] - https://tools.ietf.org/html/rfc8446#section-4.4.2.1
> [3] - https://github.com/golang/go/issues/35722
>

From job at kimmeringer.de  Mon Dec 16 18:03:09 2019
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Mon, 16 Dec 2019 19:03:09 +0100
Subject: TLS Session Resumption with TLSv1.3 (but older as well while we're at
 it)
Message-ID: <78f6acfc-66ee-b4b3-1591-44cdb5fad8e1@kimmeringer.de>

Hi,

I'm having a lot of trouble with Java and the implementation of
an FTPS-client that can work with most of the FTPS servers out
there that require the data connection to be established with
TLS session resumption of the control channel's session. Because
the control channel is a different port (but the same host), the
JSSE mechanism to find a reusable session didn't work and
FTPS-transfers failed.

I'm not alone with this[1] and the solution with Java 7 and 8
was going "deeply reflective" and fiddle with the
sessionPortHostCache in the SSLSocket's sslContext. While
it's ugly and obviously a thing to break sooner or later, it
worked and kept data transfers "out there" functioning.

With Java 11 this "fix" doesn't work anymore as soon as TLSv1.3
is negotiated between client and server and even while
I might be able to come up with a new hack that might only
buy me some time until a future release of Java prevents the
access to the context's internals. So I'd like to ask questions
first, maybe there is a less brutal solution than the one,
the world of Java seemed to be currently using:

  - Is there a better way to ensure that a particular session
    is used for session resumption?
  - With [2] I have the impression that with TLSv1.3 session
    resumption only works once. Is that enforced by the standard
    or a JSSE-decision. If the former, that would mean that FTPS
    can't use TLSv1.3 (which would solve my problem at least in
    that direction ;-) because it's common that there are plenty
    of data connections being opened during an FTP-session
  - Also with [2] (but found that out myself as part of my
    JUnit-Tests), the session id that is reported to the server
    differs for the original ssl socket and the new one that
    got created after a session resumption. Is it still the
    case as it was 1.5 years ago that the create time is the
    only thing that allows you to check if two sessions are
    "the same"? I see potential attack vectors here for MITM
    attacks if System.currentTimeMillis isn't precise down
    to the millisecond.

Talking the world out of using FTPS is out of the order in my
eyes, so whatever the answers are here, I'll have to find a
solution here.


Thanks and best regards,

Lothar Kimmeringer

[1] https://eng.wealthfront.com/2016/06/10/connecting-to-an-ftps-server-with-ssl-session-reuse-in-java-7-and-8/
[2] https://mail.openjdk.java.net/pipermail/security-dev/2018-August/017993.html

From mbalao at redhat.com  Mon Dec 16 19:23:04 2019
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 16 Dec 2019 16:23:04 -0300
Subject: TLS 1.3: support for status_request extension in
 CertificateRequest messages
In-Reply-To: <21527c15-fce6-71f5-7338-6759ebd77536@oracle.com>
References: <d4fbe2d8-04cc-7ad0-22e1-13d0655f544a@redhat.com>
 <21527c15-fce6-71f5-7338-6759ebd77536@oracle.com>
Message-ID: <883edd9a-c4bd-b038-d2c7-4abaaa386bd1@redhat.com>

Hi Jamil,

Thanks for your answer.

On 12/16/19 2:29 PM, Jamil Nimeh wrote
> If you want to take a swing at it, go for it.? I'd be happy to be a
> reviewer for it.

I'm still unsure of how are we going to prioritize this but I'd let you
know if we go for it.

Regards,
Martin.-


From jamil.j.nimeh at oracle.com  Mon Dec 16 20:02:16 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 16 Dec 2019 12:02:16 -0800
Subject: TLS 1.3: support for status_request extension in
 CertificateRequest messages
In-Reply-To: <883edd9a-c4bd-b038-d2c7-4abaaa386bd1@redhat.com>
References: <d4fbe2d8-04cc-7ad0-22e1-13d0655f544a@redhat.com>
 <21527c15-fce6-71f5-7338-6759ebd77536@oracle.com>
 <883edd9a-c4bd-b038-d2c7-4abaaa386bd1@redhat.com>
Message-ID: <cc2eeb2d-9605-1b82-c53b-c932ddbe703a@oracle.com>

So maybe I'll make a short-term fix to at least make the client not barf 
on the status_request in the CR message from the server. That much 
should be done for correctness.? Making the client actually support OCSP 
stapling in its Cert message is a much bigger change and can come later.

I'll create a bug entry for the status_request handling part. The actual 
OCSP stapling support would have to be a separate issue and an RFE 
rather than a bug.

--Jamil

On 12/16/2019 11:23 AM, Martin Balao wrote:
> Hi Jamil,
>
> Thanks for your answer.
>
> On 12/16/19 2:29 PM, Jamil Nimeh wrote
>> If you want to take a swing at it, go for it.? I'd be happy to be a
>> reviewer for it.
> I'm still unsure of how are we going to prioritize this but I'd let you
> know if we go for it.
>
> Regards,
> Martin.-
>

From raell at web.de  Mon Dec 16 20:02:36 2019
From: raell at web.de (raell at web.de)
Date: Mon, 16 Dec 2019 21:02:36 +0100
Subject: Stateless session resumption for TLS 1.3 with
 enableSessionTicketExtension?
Message-ID: <trinity-4716d95b-3420-4f91-908c-3b0259cd4a68-1576526556852@3c-app-webde-bs04>


Dear all,
?

in Java 13 the new System properties jdk.tls.client.enableSessionTicketExtension and?jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2?and prior these properties support stateful session resumption?according to RFC 5077.
?
In TLS 1.3, however, there is no?SessionTicketExtension and it isn't clear from the description [1] what?impact jdk.tls.server.enableSessionTicketExtension has in case of a?TLS 1.3 connection.?
?
Question 1: Does a Java server perform on a TLS 1.3 connection?a?stateless resp. stateful session resumption, if?
jdk.tls.server.enableSessionTicketExtension is set to true resp. false??
?
Question 2: Does the content of the NewSessionTicket message in TLS 1.3?depend?on the value of jdk.tls.server.enableSessionTicketExtension??
?
Question 2 has been shortly discussed on the mailing list [2], but I?couldn't figure out what the final answer was.?
?
[1]:?https://bugs.openjdk.java.net/browse/JDK-8227105
[2]:?http://mail.openjdk.java.net/pipermail/security-dev/2019-July/020358.html
?
Best regards,?
?
Ralph?

From anthony.scarpino at oracle.com  Mon Dec 16 23:20:07 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 16 Dec 2019 15:20:07 -0800
Subject: Stateless session resumption for TLS 1.3 with
 enableSessionTicketExtension?
In-Reply-To: <trinity-4716d95b-3420-4f91-908c-3b0259cd4a68-1576526556852@3c-app-webde-bs04>
References: <trinity-4716d95b-3420-4f91-908c-3b0259cd4a68-1576526556852@3c-app-webde-bs04>
Message-ID: <9f0ed8a0-a2dd-d73a-2c32-57585f8b0a64@oracle.com>

On 12/16/19 12:02 PM, raell at web.de wrote:
> 
> Dear all,
>   
> 
> in Java 13 the new System properties jdk.tls.client.enableSessionTicketExtension and?jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2?and prior these properties support stateful session resumption?according to RFC 5077.
>   
> In TLS 1.3, however, there is no?SessionTicketExtension and it isn't clear from the description [1] what?impact jdk.tls.server.enableSessionTicketExtension has in case of a?TLS 1.3 connection.
>   
> Question 1: Does a Java server perform on a TLS 1.3 connection?a?stateless resp. stateful session resumption, if
> jdk.tls.server.enableSessionTicketExtension is set to true resp. false?

Yes

>   
> Question 2: Does the content of the NewSessionTicket message in TLS 1.3?depend?on the value of jdk.tls.server.enableSessionTicketExtension?

Yes


Tony

>   
> Question 2 has been shortly discussed on the mailing list [2], but I?couldn't figure out what the final answer was.
>   
> [1]:?https://bugs.openjdk.java.net/browse/JDK-8227105
> [2]:?http://mail.openjdk.java.net/pipermail/security-dev/2019-July/020358.html
>   
> Best regards,
>   
> Ralph
> 


From patrick at os.amperecomputing.com  Tue Dec 17 03:00:30 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Tue, 17 Dec 2019 03:00:30 +0000
Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple
 definition" link errors
In-Reply-To: <CA+kOe0_D1sZNq5USp8PO4nLO2TvRj=E9KRU31x87Nua7VgB3DA@mail.gmail.com>
References: <MN2PR01MB609340237C91026379A363248F540@MN2PR01MB6093.prod.exchangelabs.com>
 <CA+kOe0_D1sZNq5USp8PO4nLO2TvRj=E9KRU31x87Nua7VgB3DA@mail.gmail.com>
Message-ID: <DM6PR01MB6091782367AA8FFB1FD15E6F8F500@DM6PR01MB6091.prod.exchangelabs.com>

Thanks Martin.

Hi net-dev, and/or security-dev Reviewers,

Please help review and sponsor this patch if acceptable.
It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10).

JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/

Regards
Patrick

From: Martin Buchholz <martinrb at google.com>
Sent: Monday, December 16, 2019 10:44 AM
To: Patrick Zhang OS <patrick at os.amperecomputing.com>; net-dev <net-dev at openjdk.java.net>; OpenJDK <security-dev at openjdk.java.net>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

forwarded to other teams for review.

On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <patrick at os.amperecomputing.com<mailto:patrick at os.amperecomputing.com>> wrote:
Hi

Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks.

JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/

A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip.

[PATCH] PR85678: Change default to -fno-common
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html

For example, the error message looks like:
* For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv'
build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status

This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit".

About -fcommon vs -fno-cmmon:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common

Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'"  can make it work, but it just got things hidden again.

In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors."

Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon"

Regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191217/2ece9e61/attachment.htm>

From weijun.wang at oracle.com  Tue Dec 17 08:47:46 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 17 Dec 2019 16:47:46 +0800
Subject: [15] RFR 8236070: Multiple test failures after JDK-8234465
Message-ID: <482AFC2D-66F6-4BF0-A316-9E4FCC4AA6AD@oracle.com>

Multiple tests failed after my code change for including the public key into the encoded EC private key:

   https://bugs.openjdk.java.net/browse/JDK-8234465
   https://hg.openjdk.java.net/jdk/jdk/rev/066bb54fba95

The reason is that while a newly generated ECPrivateKeyImpl (or one decoded from a PKCS #8 file already containing the public key info) has the public key info and can encode it in a PKCS #8 file, the ECPrivateKeySpec still does not have the related method so a private key created from KeyFactory will not have it, and key comparison tests like KeySpecTest.java and TestEC.java fail.

Therefore I'd like to revert the change in JDK-8234465 and think of a better way to resolve this issue. We might either compare the keys in a different way or introduce the getPublicKey method to more classes to make this info available everywhere.

Thanks,
Max

p.s. DefaultSignatureAlgorithm.java fails with a different reason.

From chris.hegarty at oracle.com  Tue Dec 17 11:05:51 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 17 Dec 2019 11:05:51 +0000
Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple
 definition" link errors
In-Reply-To: <DM6PR01MB6091782367AA8FFB1FD15E6F8F500@DM6PR01MB6091.prod.exchangelabs.com>
References: <MN2PR01MB609340237C91026379A363248F540@MN2PR01MB6093.prod.exchangelabs.com>
 <CA+kOe0_D1sZNq5USp8PO4nLO2TvRj=E9KRU31x87Nua7VgB3DA@mail.gmail.com>
 <DM6PR01MB6091782367AA8FFB1FD15E6F8F500@DM6PR01MB6091.prod.exchangelabs.com>
Message-ID: <ACADE9D1-E11C-447E-8814-147BDC7F8004@oracle.com>

The changes to the SCTP code seem ok.

-Chris.

> On 17 Dec 2019, at 03:00, Patrick Zhang OS <patrick at os.amperecomputing.com> wrote:
> 
> Thanks Martin.
> 
> Hi net-dev, and/or security-dev Reviewers,
> 
> Please help review and sponsor this patch if acceptable.
> It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10).
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
> Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/
> 
> Regards
> Patrick
> 
> From: Martin Buchholz <martinrb at google.com>
> Sent: Monday, December 16, 2019 10:44 AM
> To: Patrick Zhang OS <patrick at os.amperecomputing.com>; net-dev <net-dev at openjdk.java.net>; OpenJDK <security-dev at openjdk.java.net>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors
> 
> forwarded to other teams for review.
> 
> On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <patrick at os.amperecomputing.com<mailto:patrick at os.amperecomputing.com>> wrote:
> Hi
> 
> Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
> Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/
> 
> A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip.
> 
> [PATCH] PR85678: Change default to -fno-common
> https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html
> 
> For example, the error message looks like:
> * For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
> build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv'
> build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here
> collect2: error: ld returned 1 exit status
> 
> This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit".
> 
> About -fcommon vs -fno-cmmon:
> https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common
> 
> Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'"  can make it work, but it just got things hidden again.
> 
> In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors."
> 
> Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon"
> 
> Regards
> Patrick


From sean.mullan at oracle.com  Tue Dec 17 12:52:55 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 17 Dec 2019 07:52:55 -0500
Subject: [15] RFR 8236070: Multiple test failures after JDK-8234465
In-Reply-To: <482AFC2D-66F6-4BF0-A316-9E4FCC4AA6AD@oracle.com>
References: <482AFC2D-66F6-4BF0-A316-9E4FCC4AA6AD@oracle.com>
Message-ID: <055c7dc5-297c-967a-018a-382decce1a79@oracle.com>


On 12/17/19 3:47 AM, Weijun Wang wrote:
> Multiple tests failed after my code change for including the public key into the encoded EC private key:
> 
>     https://bugs.openjdk.java.net/browse/JDK-8234465
>     https://hg.openjdk.java.net/jdk/jdk/rev/066bb54fba95
> 
> The reason is that while a newly generated ECPrivateKeyImpl (or one decoded from a PKCS #8 file already containing the public key info) has the public key info and can encode it in a PKCS #8 file, the ECPrivateKeySpec still does not have the related method so a private key created from KeyFactory will not have it, and key comparison tests like KeySpecTest.java and TestEC.java fail.
> 
> Therefore I'd like to revert the change in JDK-8234465 and think of a better way to resolve this issue. We might either compare the keys in a different way or introduce the getPublicKey method to more classes to make this info available everywhere.

Backing out the change is fine with me. I would suggest using a 
different title for the bug though, like "Backout fix for JDK-8234465."

--Sean

> 
> Thanks,
> Max
> 
> p.s. DefaultSignatureAlgorithm.java fails with a different reason.
> 

From raell at web.de  Tue Dec 17 12:53:51 2019
From: raell at web.de (raell at web.de)
Date: Tue, 17 Dec 2019 13:53:51 +0100
Subject: Stateless session resumption for TLS 1.3 with
 enableSessionTicketExtension?
In-Reply-To: <9f0ed8a0-a2dd-d73a-2c32-57585f8b0a64@oracle.com>
References: <trinity-4716d95b-3420-4f91-908c-3b0259cd4a68-1576526556852@3c-app-webde-bs04>
 <9f0ed8a0-a2dd-d73a-2c32-57585f8b0a64@oracle.com>
Message-ID: <trinity-8305b98a-d724-4d04-84df-1ece1e1e94b9-1576587231666@3c-app-webde-bap63>

Hi Tony,

thank you for the clarification.

Btw: If I'm not mistaken, the new System properties for stateless session resumption are not included in the documentation https://docs.oracle.com/en/java/javase/13/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-93DEEE16-0B70-40E5-BBE7-55C3FD432345 (Table 8-3) so far. If they should be added there at a later time, maybe, your clarification for TLS 1.3 could be incorporated there? 

Regards,

Ralph
?
?
?
On 12/16/2019 3:20 PM, Anthony Scarpino wrote:
>> Dear all,
>>
>>
>> in Java 13 the new System properties jdk.tls.client.enableSessionTicketExtension and?jdk.tls.server.enableSessionTicketExtension were introduced. In TLS 1.2?and prior these properties support stateful session resumption?according to RFC 5077.
>>
>> In TLS 1.3, however, there is no?SessionTicketExtension and it isn't clear from the description [1] what?impact jdk.tls.server.enableSessionTicketExtension has in case of a?TLS 1.3 connection.
>>
>> Question 1: Does a Java server perform on a TLS 1.3 connection?a?stateless resp. stateful session resumption, if
>> jdk.tls.server.enableSessionTicketExtension is set to true resp. false?

>Yes

>>
>> Question 2: Does the content of the NewSessionTicket message in TLS 1.3?depend?on the value of jdk.tls.server.enableSessionTicketExtension?

>Yes


>Tony

From sgehwolf at redhat.com  Tue Dec 17 19:30:04 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 17 Dec 2019 20:30:04 +0100
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing
 root program
Message-ID: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>

Hi,

Could I please get a review of this OpenJDK 8u backport of 8232019. The
JDK 11 patch did not apply cleanly for a couple of reasons:

   1. 8u still has the binary blob for cacerts (JDK-8193255 not
      backported, yet). Instead, I've updated to the revision in jdk11u,
      performed a build and copied the cacerts binary to 8u.
   2. JDK-8225392 not present in 8u, which added the checksum to
      VerifyCACerts.java. Thus, the 8u backport does not include this
      hunk. @bug annotation modified manually for the same reason.

Everything else is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/

Testing: sun/security/lib/cacerts/VerifyCACerts.java and
         security/infra/java/security/cert/CertPathValidator/certification
         Pass, except for ActalisCA.java which is problem-listed and still
         broken in HEAD (JDK-8224768)

Thoughts?

If reviewed, I'll try to get this in 8u242 via the critical fix request
label workflow.

Thanks,
Severin


From sgehwolf at redhat.com  Tue Dec 17 19:38:52 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 17 Dec 2019 20:38:52 +0100
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
Message-ID: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>

Hi,

Could I please get a review of this OpenJDK 8u backport of 8233223
which depends on 8u backport of 8232019[1]. The JDK 11u patch did not
apply cleanly for a couple of reasons:

   1. 8u still has the binary blob for cacerts (JDK-8193255
      not?backported, yet). Instead, I've updated to the revision in
      jdk11u, performed a build and copied the cacerts binary to 8u.
   2. JDK-8225392 not present in 8u, which added the checksum to
      VerifyCACerts.java. Thus, the 8u backport does not include
      this?hunk.
   3. JDK-8234245 not present in 8u.
   4. Due to 2) and 3) above @bug annotation modified manually for these
      reasons.

Everything else is the same.

Bug: https://bugs.openjdk.java.net/browse/JDK-8233223
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/

Testing: sun/security/lib/cacerts/VerifyCACerts.java and
         security/infra/java/security/cert/CertPathValidator/certification
         Pass, except for ActalisCA.java which is problem-listed and still
         broken in HEAD (JDK-8224768)

Thoughts?

Once reviewed, I'll try to get this into 8u242 via the critical fix
request label workflow.

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html


From javajiva at amazon.com  Tue Dec 17 23:43:32 2019
From: javajiva at amazon.com (Jiva, Azeem)
Date: Tue, 17 Dec 2019 23:43:32 +0000
Subject: Incorrect documentation
Message-ID: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>

Security experts,

  The official Java Security Standard Algorithm Names incorrectly documents the Signature.*withECDSAinP1363Format algorithms as

SEQUENCE ::= { r INTEGER, s INTEGER }

This is incorrect. The IEEE P1363 Format is defined as concatenating the r and s values (with no ASN.1 encoding, but with appropriate padding). The implementations appear correct. This just appears to be a documentation issue.  The documentation for Java 11, 12, and 13 would need to be updated.

I refer you to the Wikipedia page [2], item #7 that has the relevant information



Thank you.


[1]:  https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#signature-algorithms
[2]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191217/f2b13680/attachment-0001.htm>

From weijun.wang at oracle.com  Wed Dec 18 01:00:15 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 18 Dec 2019 09:00:15 +0800
Subject: Incorrect documentation
In-Reply-To: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>
References: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>
Message-ID: <42384369-3C41-44CF-8915-8404F2E3EE7C@oracle.com>

Thanks for the report. I've filed https://bugs.openjdk.java.net/browse/JDK-8236145.

--Max

> On Dec 18, 2019, at 7:43 AM, Jiva, Azeem <javajiva at amazon.com> wrote:
> 
> Security experts,
>   The official Java Security Standard Algorithm Names incorrectly documents the Signature.*withECDSAinP1363Format algorithms as
> 
> SEQUENCE ::= { r INTEGER, s INTEGER }
> 
> This is incorrect. The IEEE P1363 Format is defined as concatenating the r and s values (with no ASN.1 encoding, but with appropriate padding). The implementations appear correct. This just appears to be a documentation issue.  The documentation for Java 11, 12, and 13 would need to be updated.
> 
> I refer you to the Wikipedia page [2], item #7 that has the relevant information
> 
>  
> 
> Thank you.
> 
>  
>  
> [1]:  https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#signature-algorithms
> [2]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm


From ecki at zusammenkunft.net  Wed Dec 18 03:29:22 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 18 Dec 2019 03:29:22 +0000
Subject: Microsoft LDAP Channel Binding
Message-ID: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>

Hello,

Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers.

They also reminded Administrators to install the KB patch and turn the hardened Settings on.

Do you have experiences with this, will Java (8) work with the setting of "mandatory is supported" (1) and/or "mandatory" (2) for this key, and if not what is the plan here?

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

Gruss
Bernd
--
http://bernd.eckenfels.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191218/534fb7c8/attachment.htm>

From 1983-01-06 at gmx.net  Wed Dec 18 13:14:29 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Wed, 18 Dec 2019 14:14:29 +0100
Subject: Microsoft LDAP Channel Binding
Message-ID: <trinity-07f64c50-a660-4d19-b5c0-51ba709aa1fd-1576674869020@3c-app-gmx-bap05>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191218/805f2c00/attachment.htm>

From 1983-01-06 at gmx.net  Wed Dec 18 17:37:15 2019
From: 1983-01-06 at gmx.net (Michael Osipov)
Date: Wed, 18 Dec 2019 18:37:15 +0100
Subject: Microsoft LDAP Channel Binding
In-Reply-To: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>
References: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>
Message-ID: <74cf2a20-acc1-a210-2778-005b3b5e1309@gmx.net>

Am 2019-12-18 um 04:29 schrieb Bernd Eckenfels:
> Hello,
>
> Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers.

Another question here, typically Microsoft: What makes you think that
this is TLS channel binding? All I see is LDAP channel binding for which
I fail to find any technical documentation.

Michael

From martin.doerr at sap.com  Fri Dec  6 11:21:39 2019
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 6 Dec 2019 11:21:39 +0000
Subject: RFR(S): 8220348: [ntintel] asserts about copying unalinged array
In-Reply-To: <DB8PR02MB5547658B363C35672B7D008D8A5C0@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <AM0PR0202MB329727AA4A9ECA8F8DAD58F69A430@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <CAA-vtUwgbpUXJRTCENAiDJNkAA8=wQVvHdTOKUEEofr08VNO+Q@mail.gmail.com>
 <AM0PR0202MB329719A4E6BC2305E097A46B9A5C0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <DB8PR02MB5547658B363C35672B7D008D8A5C0@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB32974998C55C74E58B9FFC909A5F0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Christoph,

that would work, but I don?t want to pollute this file with compiler specific defines. In addition, I don?t like introducing a macro which works on some platforms and does nothing on other ones (which is the case for hotspot?s ATTRIBUTE_ALIGNED).

Because Windows 32 bit is the only affected platform, I prefer not to touch other ones. Are you ok with webrev.00 as it is?

Best regards,
Martin



From: Langer, Christoph <christoph.langer at sap.com>
Sent: Donnerstag, 5. Dezember 2019 12:16
To: Doerr, Martin <martin.doerr at sap.com>
Cc: core-libs-dev at openjdk.java.net; security-dev <security-dev at openjdk.java.net>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Thomas St?fe <thomas.stuefe at gmail.com>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

I can see that both places already include headers from src/java.base/share/native/libjava/. I suggest adding the define in jni_util.h. WindowsPreferences.c already includes it.

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Donnerstag, 5. Dezember 2019 12:00
To: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>; Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: RE: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Thomas and Christoph,

thanks for the reviews.

Other code in java.security.jgss also uses these #defined checks:
src/java.security.jgss/share/native/libj2gss/gssapi.h:#if defined (_WIN32) && defined (_MSC_VER)

I?d like to have it consistent with that.

@Christoph: I think having ATTRIBUTE_ALIGNED(x) would be nice. It could get defined easily for Visual Studio and GCC, but some other compilers may be more difficult. Note that this macro is only defined for a selected set of compilers in hotspot. If we wanted to add it, where should we define it?

Windows 32 bit seems to be the only platform which is affected by the problem that jlongs on stack are not 8 byte aligned.
(AFAIK, GCC uses -malign-double by default on 32 bit which should do the job for jlongs, too:
https://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/i386-and-x86_002d64-Options.html)

Best regards,
Martin


From: Thomas St?fe <thomas.stuefe at gmail.com<mailto:thomas.stuefe at gmail.com>>
Sent: Mittwoch, 4. Dezember 2019 17:56
To: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Cc: core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>; security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: Re: RFR(S): 8220348: [ntintel] asserts about copying unalinged array

Hi Martin,

this makes sense. This is the right way to force alignment. I do not like the platform code in the shared file but do not think this is a big deal.

+#if defined (_WIN32) && defined (_MSC_VER)

Why do you think we need _MSC_VER too? Is OpenJDK on Windows even buildable with anything other than VC++?

Cheers, Thomas

On Mon, Dec 2, 2019 at 4:14 PM Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:
Hi,

I'd like to propose a fix for an old issue on 32 bit Windows (also for an 11u backport):
https://bugs.openjdk.java.net/browse/JDK-8220348

Some jdk native methods use jni_SetLongArrayRegion with a stack allocated buffer.
jni_SetLongArrayRegion uses Copy::conjoint_jlongs_atomic which requires jlongs to be 8 byte aligned (asserted).
However, Windows 32 bit only uses 4 byte alignment for jlong arrays by default.
I found such issues in the following files:
src/java.prefs/windows/native/libprefs/WindowsPreferences.c
src/java.security.jgss/share/native/libj2gss/GSSLibStub.c
I suggest to use __declspec(align(8)) there.

Webrev:
http://cr.openjdk.java.net/~mdoerr/8220348_ntintel_stack_align/webrev.00/
Please review.

I think using 8 byte alignment is not a disadvantage for 64 bit.

I guess there are still people interested in this platform with jdk14. Otherwise I could contribute it as 11u only fix.

Is there a better way to force 8 byte alignment for jlongs or jlong arrays on stack?
Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191206/88f42585/attachment-0001.htm>

From brian.dyson at cox.net  Mon Dec  9 17:47:55 2019
From: brian.dyson at cox.net (Brian Dyson)
Date: Mon, 9 Dec 2019 09:47:55 -0800
Subject: Missing space in
 /jdk13/src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
 DEBUG output
Message-ID: <05f701d5aeb8$cb611390$62233ab0$@cox.net>

In KeyTab.java, if DEBUG is true, then System.out is written to.

In the readServiceKeys method (at about line 303), there is the following code:

System.out.println("Added key: " + entry.keyType +
    "version: " + entry.keyVersion);

However, the string "version: " is missing a leading space, so output looks like this:

Added key: 17version: 1
Added key: 18version: 1

Suggest a space is added to improve output readability. Change "version: " to " version: ".

Thank you,
Brian Dyson


From volker.simonis at gmail.com  Wed Dec 18 21:27:20 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 18 Dec 2019 22:27:20 +0100
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
In-Reply-To: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
Message-ID: <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>

Hi Severin,

not strictly a 8u "Reviewer" yet, but I've looked at your changes
(this one and 8232019) nevertheless :)

They both look good, except that I can not verify the new "cacert"
file because it is not in the patch (because it is binary). Not sure
if it is necessary to upload the whole file to cr.openjdk.java.net as
well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and
security/infra/java/security/cert/CertPathValidator/certification both
pass, then everything seems to be fine.

So thumbs up from me (for both, this one and 8232019).

Best regards,
Volker

On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi,
>
> Could I please get a review of this OpenJDK 8u backport of 8233223
> which depends on 8u backport of 8232019[1]. The JDK 11u patch did not
> apply cleanly for a couple of reasons:
>
>    1. 8u still has the binary blob for cacerts (JDK-8193255
>       not backported, yet). Instead, I've updated to the revision in
>       jdk11u, performed a build and copied the cacerts binary to 8u.
>    2. JDK-8225392 not present in 8u, which added the checksum to
>       VerifyCACerts.java. Thus, the 8u backport does not include
>       this hunk.
>    3. JDK-8234245 not present in 8u.
>    4. Due to 2) and 3) above @bug annotation modified manually for these
>       reasons.
>
> Everything else is the same.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233223
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/
>
> Testing: sun/security/lib/cacerts/VerifyCACerts.java and
>          security/infra/java/security/cert/CertPathValidator/certification
>          Pass, except for ActalisCA.java which is problem-listed and still
>          broken in HEAD (JDK-8224768)
>
> Thoughts?
>
> Once reviewed, I'll try to get this into 8u242 via the critical fix
> request label workflow.
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html
>

From ecki at zusammenkunft.net  Wed Dec 18 22:11:37 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 18 Dec 2019 22:11:37 +0000
Subject: Microsoft LDAP Channel Binding
In-Reply-To: <74cf2a20-acc1-a210-2778-005b3b5e1309@gmx.net>
References: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>,
 <74cf2a20-acc1-a210-2778-005b3b5e1309@gmx.net>
Message-ID: <DB6PR0301MB25360D401E75E1749EF1D006FF530@DB6PR0301MB2536.eurprd03.prod.outlook.com>

Hello,

As I understand it, it is about the Extended Protection for Integrated Windows Authentication (probably only GSSAPI/Kerberos and GSS-SPNEGO/SSPCred which is not a OpenJDK mechanism).

 In this case it includes Channel binding tokens into the subject information. CBT are not per-se TLS specific, however for traffic in TLS channels they do bind to the TLS session or to the endpoint. https://tools.ietf.org/html/rfc5056#section-3.2

Some projects have implemented channel binding for IIS or WinRm already, for example here is a good discussion: https://github.com/requests/requests-kerberos/pull/92

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Michael Osipov <1983-01-06 at gmx.net>
Gesendet: Mittwoch, Dezember 18, 2019 6:37 PM
An: Bernd Eckenfels; security-dev at openjdk.java.net
Betreff: Re: Microsoft LDAP Channel Binding

Am 2019-12-18 um 04:29 schrieb Bernd Eckenfels:
> Hello,
>
> Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers.

Another question here, typically Microsoft: What makes you think that
this is TLS channel binding? All I see is LDAP channel binding for which
I fail to find any technical documentation.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191218/656db7b7/attachment.htm>

From ecki at zusammenkunft.net  Wed Dec 18 22:28:24 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 18 Dec 2019 22:28:24 +0000
Subject: Microsoft LDAP Channel Binding
In-Reply-To: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>
References: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>
Message-ID: <DB6PR0301MB253644AFDE58991A4B606C30FF530@DB6PR0301MB2536.eurprd03.prod.outlook.com>

Here is a related bug

https://bugs.openjdk.java.net/browse/JDK-8208301 for ADFS.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: Bernd Eckenfels <ecki at zusammenkunft.net>
Gesendet: Mittwoch, Dezember 18, 2019 4:29 AM
An: security-dev at openjdk.java.net
Betreff: Microsoft LDAP Channel Binding

Hello,

Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers.

They also reminded Administrators to install the KB patch and turn the hardened Settings on.

Do you have experiences with this, will Java (8) work with the setting of "mandatory is supported" (1) and/or "mandatory" (2) for this key, and if not what is the plan here?

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

Gruss
Bernd
--
http://bernd.eckenfels.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191218/e3e59ede/attachment.htm>

From sgehwolf at redhat.com  Thu Dec 19 10:09:46 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Dec 2019 11:09:46 +0100
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
In-Reply-To: <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>
References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
 <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>
Message-ID: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>

Hi Volker,

On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote:
> Hi Severin,
> 
> not strictly a 8u "Reviewer" yet, but I've looked at your changes
> (this one and 8232019) nevertheless :)

Thanks for the review!

> They both look good, except that I can not verify the new "cacert"
> file because it is not in the patch (because it is binary). Not sure
> if it is necessary to upload the whole file to cr.openjdk.java.net as
> well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and
> security/infra/java/security/cert/CertPathValidator/certification both
> pass, then everything seems to be fine.

FWIW the raw download of the webrev's cacerts file should have the
binary blob:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts

And for 8232019:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts

Thanks,
Severin

> So thumbs up from me (for both, this one and 8232019).
> 
> Best regards,
> Volker
> 
> On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > Hi,
> > 
> > Could I please get a review of this OpenJDK 8u backport of 8233223
> > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not
> > apply cleanly for a couple of reasons:
> > 
> >    1. 8u still has the binary blob for cacerts (JDK-8193255
> >       not backported, yet). Instead, I've updated to the revision in
> >       jdk11u, performed a build and copied the cacerts binary to 8u.
> >    2. JDK-8225392 not present in 8u, which added the checksum to
> >       VerifyCACerts.java. Thus, the 8u backport does not include
> >       this hunk.
> >    3. JDK-8234245 not present in 8u.
> >    4. Due to 2) and 3) above @bug annotation modified manually for these
> >       reasons.
> > 
> > Everything else is the same.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/
> > 
> > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> >          security/infra/java/security/cert/CertPathValidator/certification
> >          Pass, except for ActalisCA.java which is problem-listed and still
> >          broken in HEAD (JDK-8224768)
> > 
> > Thoughts?
> > 
> > Once reviewed, I'll try to get this into 8u242 via the critical fix
> > request label workflow.
> > 
> > Thanks,
> > Severin
> > 
> > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html
> > 


From christoph.langer at sap.com  Thu Dec 19 17:04:46 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Dec 2019 17:04:46 +0000
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
Message-ID: <DB8PR02MB5547AE68FD22D59B0AF54DDC8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi Severin,

this looks good - when VerifyCACerts passes, everything is correct.

We shall definitely try to backport "JDK-8193255: Root Certificates should be stored in text format and assembled at build time" somehow, to have easier certificate backports.

Cheers
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 17. Dezember 2019 20:30
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing
> root program
> 
> Hi,
> 
> Could I please get a review of this OpenJDK 8u backport of 8232019. The
> JDK 11 patch did not apply cleanly for a couple of reasons:
> 
>    1. 8u still has the binary blob for cacerts (JDK-8193255 not
>       backported, yet). Instead, I've updated to the revision in jdk11u,
>       performed a build and copied the cacerts binary to 8u.
>    2. JDK-8225392 not present in 8u, which added the checksum to
>       VerifyCACerts.java. Thus, the 8u backport does not include this
>       hunk. @bug annotation modified manually for the same reason.
> 
> Everything else is the same.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8232019/jdk8/01/webrev/
> 
> Testing: sun/security/lib/cacerts/VerifyCACerts.java and
>          security/infra/java/security/cert/CertPathValidator/certification
>          Pass, except for ActalisCA.java which is problem-listed and still
>          broken in HEAD (JDK-8224768)
> 
> Thoughts?
> 
> If reviewed, I'll try to get this in 8u242 via the critical fix request
> label workflow.
> 
> Thanks,
> Severin


From christoph.langer at sap.com  Thu Dec 19 17:05:14 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Dec 2019 17:05:14 +0000
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
In-Reply-To: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>
References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
 <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>
 <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>
Message-ID: <DB8PR02MB5547DC6C191080F6044FC5158A520@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi Severin,

same here, looks good - when VerifyCACerts passes, everything is correct.

Cheers
Christoph

> -----Original Message-----
> From: security-dev <security-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Donnerstag, 19. Dezember 2019 11:10
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>; security-dev <security-
> dev at openjdk.java.net>
> Subject: Re: [8u] RFR: 8233223: Add Amazon Root CA certificates
> 
> Hi Volker,
> 
> On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote:
> > Hi Severin,
> >
> > not strictly a 8u "Reviewer" yet, but I've looked at your changes
> > (this one and 8232019) nevertheless :)
> 
> Thanks for the review!
> 
> > They both look good, except that I can not verify the new "cacert"
> > file because it is not in the patch (because it is binary). Not sure
> > if it is necessary to upload the whole file to cr.openjdk.java.net as
> > well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and
> > security/infra/java/security/cert/CertPathValidator/certification both
> > pass, then everything seems to be fine.
> 
> FWIW the raw download of the webrev's cacerts file should have the
> binary blob:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts
> 
> And for 8232019:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts
> 
> Thanks,
> Severin
> 
> > So thumbs up from me (for both, this one and 8232019).
> >
> > Best regards,
> > Volker
> >
> > On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf <sgehwolf at redhat.com>
> wrote:
> > > Hi,
> > >
> > > Could I please get a review of this OpenJDK 8u backport of 8233223
> > > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not
> > > apply cleanly for a couple of reasons:
> > >
> > >    1. 8u still has the binary blob for cacerts (JDK-8193255
> > >       not backported, yet). Instead, I've updated to the revision in
> > >       jdk11u, performed a build and copied the cacerts binary to 8u.
> > >    2. JDK-8225392 not present in 8u, which added the checksum to
> > >       VerifyCACerts.java. Thus, the 8u backport does not include
> > >       this hunk.
> > >    3. JDK-8234245 not present in 8u.
> > >    4. Due to 2) and 3) above @bug annotation modified manually for these
> > >       reasons.
> > >
> > > Everything else is the same.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8233223/jdk8/01/webrev/
> > >
> > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> > >          security/infra/java/security/cert/CertPathValidator/certification
> > >          Pass, except for ActalisCA.java which is problem-listed and still
> > >          broken in HEAD (JDK-8224768)
> > >
> > > Thoughts?
> > >
> > > Once reviewed, I'll try to get this into 8u242 via the critical fix
> > > request label workflow.
> > >
> > > Thanks,
> > > Severin
> > >
> > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-
> December/010813.html
> > >


From javajiva at amazon.com  Thu Dec 19 19:00:20 2019
From: javajiva at amazon.com (Jiva, Azeem)
Date: Thu, 19 Dec 2019 19:00:20 +0000
Subject: Incorrect documentation
In-Reply-To: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>
References: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>
Message-ID: <71B39869-BCDE-4B36-A45C-72E141F26C7A@amazon.com>

Hi,
 Following up here with suggested language for the section associated with the *inP1363Formatsignatures.  I don?t have write access to the JBS bug as of yet.

The ECDSA signature algorithms, as defined by ANSI X9.62, with an output defined in IEEE P1363 format. Both r and s are encoded as unsigned big-endian integers that have been padded to be equal in length to the curve order. The final encoded signature is the r ands concatenated as r || s, resulting in a byte array that is exactly twice as long as the curve order.
The DSA signature algorithms, as defined by ANSI X9.62, with an output defined in IEEE P1363 format. Both r and s are encoded as unsigned big-endian integers that have been padded to be equal in length to the underlying group order q. The final encoded signature is the r ands concatenated as r || s, resulting in a byte array that is exactly twice as long as the group order.


From: "Jiva, Azeem" <javajiva at amazon.com>
Date: Tuesday, December 17, 2019 at 3:43 PM
To: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>
Subject: Incorrect documentation

Security experts,

  The official Java Security Standard Algorithm Names incorrectly documents the Signature.*withECDSAinP1363Format algorithms as

SEQUENCE ::= { r INTEGER, s INTEGER }

This is incorrect. The IEEE P1363 Format is defined as concatenating the r and s values (with no ASN.1 encoding, but with appropriate padding). The implementations appear correct. This just appears to be a documentation issue.  The documentation for Java 11, 12, and 13 would need to be updated.

I refer you to the Wikipedia page [2], item #7 that has the relevant information



Thank you.


[1]:  https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#signature-algorithms
[2]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191219/9ed730e8/attachment-0001.htm>

From gnu.andrew at redhat.com  Thu Dec 19 19:29:45 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Thu, 19 Dec 2019 19:29:45 +0000
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
Message-ID: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>



On 17/12/2019 19:30, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this OpenJDK 8u backport of 8232019. The
> JDK 11 patch did not apply cleanly for a couple of reasons:
> 
>    1. 8u still has the binary blob for cacerts (JDK-8193255 not
>       backported, yet). Instead, I've updated to the revision in jdk11u,
>       performed a build and copied the cacerts binary to 8u.
>    2. JDK-8225392 not present in 8u, which added the checksum to
>       VerifyCACerts.java. Thus, the 8u backport does not include this
>       hunk. @bug annotation modified manually for the same reason.
> 
> Everything else is the same.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/
> 
> Testing: sun/security/lib/cacerts/VerifyCACerts.java and
>          security/infra/java/security/cert/CertPathValidator/certification
>          Pass, except for ActalisCA.java which is problem-listed and still
>          broken in HEAD (JDK-8224768)
> 
> Thoughts?
> 
> If reviewed, I'll try to get this in 8u242 via the critical fix request
> label workflow.
> 
> Thanks,
> Severin
> 

Going on this & the similar Amazon fix, I'd say we should backport
JDK-8193255 & JDK-8225392 first. The previous updates which alter a
binary file have been pretty much unreviewable and, if there's a better
solution to that, I'd rather we had it sooner rather than later.

Likewise, judging by the comment on JDK-8234245, I'd say that needs to
be applied between the LuxTrust & Amazon ones:

"This fixes an issue after JDK-8232019, so it needs to be included.
Patch applies cleanly."

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191219/1f05a423/signature.asc>

From sgehwolf at redhat.com  Thu Dec 19 20:13:45 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 19 Dec 2019 21:13:45 +0100
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
 <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>
Message-ID: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>

Hi Andrew,

On Thu, 2019-12-19 at 19:29 +0000, Andrew John Hughes wrote:
> 
> On 17/12/2019 19:30, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could I please get a review of this OpenJDK 8u backport of 8232019. The
> > JDK 11 patch did not apply cleanly for a couple of reasons:
> > 
> >    1. 8u still has the binary blob for cacerts (JDK-8193255 not
> >       backported, yet). Instead, I've updated to the revision in jdk11u,
> >       performed a build and copied the cacerts binary to 8u.
> >    2. JDK-8225392 not present in 8u, which added the checksum to
> >       VerifyCACerts.java. Thus, the 8u backport does not include this
> >       hunk. @bug annotation modified manually for the same reason.
> > 
> > Everything else is the same.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/
> > 
> > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> >          security/infra/java/security/cert/CertPathValidator/certification
> >          Pass, except for ActalisCA.java which is problem-listed and still
> >          broken in HEAD (JDK-8224768)
> > 
> > Thoughts?
> > 
> > If reviewed, I'll try to get this in 8u242 via the critical fix request
> > label workflow.
> > 
> > Thanks,
> > Severin
> > 
> 
> Going on this & the similar Amazon fix, I'd say we should backport
> JDK-8193255 & JDK-8225392 first. The previous updates which alter a
> binary file have been pretty much unreviewable and, if there's a better
> solution to that, I'd rather we had it sooner rather than later.

I agree with you that we should backport JDK-8193255. Question is when
would be a good time to do this. Given that there would be some benefit
for these to go into 8u242 if possible I'm not sure we should do JDK-
8193255 right now. After all, we've accepted this situation of having
the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 -
which brought this in - was integrated in 8u222.

The risk of a backport of JDK-8193255 seems higher (the build system in
8u is different, there is a bug tail) than accepting these backports
with the binary blob updates. Note that the backports as-is have been
reviewed by Christoph Langer, Volker Simonis and internally by Martin
Balao.

So, it looks like there are the following options:
   1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is.
   2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK-
      8233223 to 8u242.
   3. Defer backports of 2) to 8u252 with the caveat that we won't have
      certain certificates as compared to Oracle JDK.

I'm leaning towards option 1) or 3). Slight preference for 1)

> Likewise, judging by the comment on JDK-8234245, I'd say that needs to
> be applied between the LuxTrust & Amazon ones:
> 
> "This fixes an issue after JDK-8232019, so it needs to be included.
> Patch applies cleanly."

Not sure what caused JDK-8234245. It might be that it was caused by the
list of certs in the keystore not being ordered at first (fixed by JDK-
8225392?).

Thanks,
Severin


From christoph.langer at sap.com  Thu Dec 19 20:51:35 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 19 Dec 2019 20:51:35 +0000
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
 <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>
 <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>
Message-ID: <DB8PR02MB5547B29177558C45672EE8D38A520@DB8PR02MB5547.eurprd02.prod.outlook.com>

Hi,

Just FWIW: JDK-8234245 fixed an issue where a wrong checksum was used in the test update that came with JDK-8232019. So, both can probably marked fixed with one change (e.g. adding both bugs to the submit message...)

Cheers
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Severin Gehwolf
> Sent: Donnerstag, 19. Dezember 2019 21:14
> To: Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>
> Cc: security-dev <security-dev at openjdk.java.net>
> Subject: Re: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
> existing root program
> 
> Hi Andrew,
> 
> On Thu, 2019-12-19 at 19:29 +0000, Andrew John Hughes wrote:
> >
> > On 17/12/2019 19:30, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Could I please get a review of this OpenJDK 8u backport of 8232019. The
> > > JDK 11 patch did not apply cleanly for a couple of reasons:
> > >
> > >    1. 8u still has the binary blob for cacerts (JDK-8193255 not
> > >       backported, yet). Instead, I've updated to the revision in jdk11u,
> > >       performed a build and copied the cacerts binary to 8u.
> > >    2. JDK-8225392 not present in 8u, which added the checksum to
> > >       VerifyCACerts.java. Thus, the 8u backport does not include this
> > >       hunk. @bug annotation modified manually for the same reason.
> > >
> > > Everything else is the same.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8232019/jdk8/01/webrev/
> > >
> > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> > >          security/infra/java/security/cert/CertPathValidator/certification
> > >          Pass, except for ActalisCA.java which is problem-listed and still
> > >          broken in HEAD (JDK-8224768)
> > >
> > > Thoughts?
> > >
> > > If reviewed, I'll try to get this in 8u242 via the critical fix request
> > > label workflow.
> > >
> > > Thanks,
> > > Severin
> > >
> >
> > Going on this & the similar Amazon fix, I'd say we should backport
> > JDK-8193255 & JDK-8225392 first. The previous updates which alter a
> > binary file have been pretty much unreviewable and, if there's a better
> > solution to that, I'd rather we had it sooner rather than later.
> 
> I agree with you that we should backport JDK-8193255. Question is when
> would be a good time to do this. Given that there would be some benefit
> for these to go into 8u242 if possible I'm not sure we should do JDK-
> 8193255 right now. After all, we've accepted this situation of having
> the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 -
> which brought this in - was integrated in 8u222.
> 
> The risk of a backport of JDK-8193255 seems higher (the build system in
> 8u is different, there is a bug tail) than accepting these backports
> with the binary blob updates. Note that the backports as-is have been
> reviewed by Christoph Langer, Volker Simonis and internally by Martin
> Balao.
> 
> So, it looks like there are the following options:
>    1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is.
>    2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK-
>       8233223 to 8u242.
>    3. Defer backports of 2) to 8u252 with the caveat that we won't have
>       certain certificates as compared to Oracle JDK.
> 
> I'm leaning towards option 1) or 3). Slight preference for 1)
> 
> > Likewise, judging by the comment on JDK-8234245, I'd say that needs to
> > be applied between the LuxTrust & Amazon ones:
> >
> > "This fixes an issue after JDK-8232019, so it needs to be included.
> > Patch applies cleanly."
> 
> Not sure what caused JDK-8234245. It might be that it was caused by the
> list of certs in the keystore not being ordered at first (fixed by JDK-
> 8225392?).
> 
> Thanks,
> Severin


From patrick at os.amperecomputing.com  Fri Dec 20 03:05:33 2019
From: patrick at os.amperecomputing.com (Patrick Zhang OS)
Date: Fri, 20 Dec 2019 03:05:33 +0000
Subject: RFR: JDK-8235903: GCC default -fno-common exposes "multiple
 definition" link errors
In-Reply-To: <DM6PR01MB6091782367AA8FFB1FD15E6F8F500@DM6PR01MB6091.prod.exchangelabs.com>
References: <MN2PR01MB609340237C91026379A363248F540@MN2PR01MB6093.prod.exchangelabs.com>
 <CA+kOe0_D1sZNq5USp8PO4nLO2TvRj=E9KRU31x87Nua7VgB3DA@mail.gmail.com>
 <DM6PR01MB6091782367AA8FFB1FD15E6F8F500@DM6PR01MB6091.prod.exchangelabs.com>
Message-ID: <MN2PR01MB60933F6A58C943C7292120E08F2D0@MN2PR01MB6093.prod.exchangelabs.com>

Ping?

Could anyone please help review this, thanks.

Regards
Patrick

From: Patrick Zhang OS
Sent: Tuesday, December 17, 2019 11:01 AM
To: net-dev <net-dev at openjdk.java.net>; OpenJDK <security-dev at openjdk.java.net>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; Martin Buchholz <martinrb at google.com>
Subject: RE: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

Thanks Martin.

Hi net-dev, and/or security-dev Reviewers,

Please help review and sponsor this patch if acceptable.
It does not tend to bring any functionality changes, instead to propose an early fix, for the build (linking) errors with further toolchain (GCC 10).

JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/

Regards
Patrick

From: Martin Buchholz <martinrb at google.com<mailto:martinrb at google.com>>
Sent: Monday, December 16, 2019 10:44 AM
To: Patrick Zhang OS <patrick at os.amperecomputing.com<mailto:patrick at os.amperecomputing.com>>; net-dev <net-dev at openjdk.java.net<mailto:net-dev at openjdk.java.net>>; OpenJDK <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>
Subject: Re: RFR: JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors

forwarded to other teams for review.

On Fri, Dec 13, 2019 at 3:14 AM Patrick Zhang OS <patrick at os.amperecomputing.com<mailto:patrick at os.amperecomputing.com>> wrote:
Hi

Please review this patch, if it should be reviewed by any group other than core-libs, please help forward it. Thanks.

JBS: https://bugs.openjdk.java.net/browse/JDK-8235903
Webrev: http://cr.openjdk.java.net/~qpzhang/8235903/webrev.01/

A recent GCC patch (supposed to be in GCC 10) exposes a couple of "multiple definition" link errors when building the jdk tip.

[PATCH] PR85678: Change default to -fno-common
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01847.html

For example, the error message looks like:
* For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
build/support/native/java.base/libjava/childproc.o:(.bss+0x0): multiple definition of `parentPathv'
build/support/native/java.base/libjava/ProcessImpl_md.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status

This was not an issue because the original default -fcommon allowed "global variables defined without an initializer" be handled as COMMON symbols, so it would not warn the problem like "same variable is accidentally defined in more than one compilation unit".

About -fcommon vs -fno-cmmon:
https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fno-common

Moving forward, building jdk with latest versions of GCC will trigger this error. Specifying "--with-extra-cflags='-fcommon'"  can make it work, but it just got things hidden again.

In addition, -fcommon's behavior "is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors."

Last, in case that other jdk developers would revisit this problem once again, I suggest fixing the error explicitly instead of using "-fcommon"

Regards
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191220/dfb40e0a/attachment-0001.htm>

From gnu.andrew at redhat.com  Fri Dec 20 07:42:12 2019
From: gnu.andrew at redhat.com (Andrew John Hughes)
Date: Fri, 20 Dec 2019 07:42:12 +0000
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
 <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>
 <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>
Message-ID: <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com>



On 19/12/2019 20:13, Severin Gehwolf wrote:

snip...

>>>
>>
>> Going on this & the similar Amazon fix, I'd say we should backport
>> JDK-8193255 & JDK-8225392 first. The previous updates which alter a
>> binary file have been pretty much unreviewable and, if there's a better
>> solution to that, I'd rather we had it sooner rather than later.
> 
> I agree with you that we should backport JDK-8193255. Question is when
> would be a good time to do this. Given that there would be some benefit
> for these to go into 8u242 if possible I'm not sure we should do JDK-
> 8193255 right now. After all, we've accepted this situation of having
> the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 -
> which brought this in - was integrated in 8u222.
> 
> The risk of a backport of JDK-8193255 seems higher (the build system in
> 8u is different, there is a bug tail) than accepting these backports
> with the binary blob updates. Note that the backports as-is have been
> reviewed by Christoph Langer, Volker Simonis and internally by Martin
> Balao.
> 
> So, it looks like there are the following options:
>    1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is.
>    2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK-
>       8233223 to 8u242.
>    3. Defer backports of 2) to 8u252 with the caveat that we won't have
>       certain certificates as compared to Oracle JDK.
> 
> I'm leaning towards option 1) or 3). Slight preference for 1)
> 
>> Likewise, judging by the comment on JDK-8234245, I'd say that needs to
>> be applied between the LuxTrust & Amazon ones:
>>
>> "This fixes an issue after JDK-8232019, so it needs to be included.
>> Patch applies cleanly."
> 
> Not sure what caused JDK-8234245. It might be that it was caused by the
> list of certs in the keystore not being ordered at first (fixed by JDK-
> 8225392?).
> 
> Thanks,
> Severin
> 

There's an option #4:

4. Propose these backports for 8u242 and do the correct backports, with
JDK-8193255 and friends, in 8u252.

8193255 is sensitive to the status of cacerts at the time it is applied.
It needs to be backported with cacerts containing the same certificates
as it did when applied in later versions, so that the textual
replacements match. By applying these backports in 8u252, we'd
complicate the 8193255 backport further by having to effectively include
backports of the Amazon & LuxTrust updates in it.

So what I'd suggest is:

1. Do the full backport series in 8u252 from 8193255 on.
2. Create a separate bug for 8u242 to add the new certificates and apply
for jdk8u-critical-request for that.

When the two are merged together, the webrev changes in 8u242 should be
the same as those in 8u252, and the changed cacerts binary can just be
deleted.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191220/cd2d6e41/signature.asc>

From weijun.wang at oracle.com  Fri Dec 20 08:09:37 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 20 Dec 2019 16:09:37 +0800
Subject: Incorrect documentation
In-Reply-To: <71B39869-BCDE-4B36-A45C-72E141F26C7A@amazon.com>
References: <DCC68B56-0CC9-4880-80A7-B9279D8FAB5C@contoso.com>
 <71B39869-BCDE-4B36-A45C-72E141F26C7A@amazon.com>
Message-ID: <07707EA5-803C-49AC-A7F7-A7B1F4F2F619@oracle.com>

I've already updated the words into

    The format of the Signature bytes for these algorithms is the concatenation of the integers r and s in raw bytes.

It does not have the same detail as your description but I think it's enough to be differentiated from the one with an ASN.1 encoding.

Thanks,
Max

> On Dec 20, 2019, at 3:00 AM, Jiva, Azeem <javajiva at amazon.com> wrote:
> 
> Hi,
>  Following up here with suggested language for the section associated with the *inP1363Formatsignatures.  I don?t have write access to the JBS bug as of yet.
>  
> The ECDSA signature algorithms, as defined by ANSI X9.62, with an output defined in IEEE P1363 format. Both r and s are encoded as unsigned big-endian integers that have been padded to be equal in length to the curve order. The final encoded signature is the r ands concatenated as r || s, resulting in a byte array that is exactly twice as long as the curve order.
> 
> The DSA signature algorithms, as defined by ANSI X9.62, with an output defined in IEEE P1363 format. Both r and s are encoded as unsigned big-endian integers that have been padded to be equal in length to the underlying group order q. The final encoded signature is the r ands concatenated as r || s, resulting in a byte array that is exactly twice as long as the group order.
>  
>  
> From: "Jiva, Azeem" <javajiva at amazon.com>
> Date: Tuesday, December 17, 2019 at 3:43 PM
> To: "security-dev at openjdk.java.net" <security-dev at openjdk.java.net>
> Subject: Incorrect documentation
>  
> Security experts,
>   The official Java Security Standard Algorithm Names incorrectly documents the Signature.*withECDSAinP1363Format algorithms as
> 
> SEQUENCE ::= { r INTEGER, s INTEGER }
> 
> This is incorrect. The IEEE P1363 Format is defined as concatenating the r and s values (with no ASN.1 encoding, but with appropriate padding). The implementations appear correct. This just appears to be a documentation issue.  The documentation for Java 11, 12, and 13 would need to be updated.
> 
> I refer you to the Wikipedia page [2], item #7 that has the relevant information
> 
>  
> 
> Thank you.
> 
>  
>  
> [1]:  https://docs.oracle.com/en/java/javase/12/docs/specs/security/standard-names.html#signature-algorithms
> [2]: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Signature_generation_algorithm


From weijun.wang at oracle.com  Fri Dec 20 08:34:07 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 20 Dec 2019 16:34:07 +0800
Subject: Missing space in
 /jdk13/src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
 DEBUG output
In-Reply-To: <05f701d5aeb8$cb611390$62233ab0$@cox.net>
References: <05f701d5aeb8$cb611390$62233ab0$@cox.net>
Message-ID: <3C804C81-410E-4823-B340-33C1D0FDD4EC@oracle.com>

That's a good suggestion. I've filed https://bugs.openjdk.java.net/browse/JDK-8236405.

Thanks,
Max

> On Dec 10, 2019, at 1:47 AM, Brian Dyson <brian.dyson at cox.net> wrote:
> 
> In KeyTab.java, if DEBUG is true, then System.out is written to.
> 
> In the readServiceKeys method (at about line 303), there is the following code:
> 
> System.out.println("Added key: " + entry.keyType +
>    "version: " + entry.keyVersion);
> 
> However, the string "version: " is missing a leading space, so output looks like this:
> 
> Added key: 17version: 1
> Added key: 18version: 1
> 
> Suggest a space is added to improve output readability. Change "version: " to " version: ".
> 
> Thank you,
> Brian Dyson
> 


From weijun.wang at oracle.com  Fri Dec 20 08:39:31 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 20 Dec 2019 16:39:31 +0800
Subject: RFR 8236405: Enhancement to Kerberos debug output
Message-ID: <D10502F4-8B41-4842-AE55-033C8F6460F2@oracle.com>

Please review the fix at

   https://cr.openjdk.java.net/~weijun/8236405/webrev.00

Most are trivial on whitespaces and commas etc. I've changed the "LSA" word to "native ccache" in Credentials.java because the output is for both Windows and macOS.

Thanks,
Max


From weijun.wang at oracle.com  Fri Dec 20 08:44:13 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 20 Dec 2019 16:44:13 +0800
Subject: RFR 8236405: Enhancement to Kerberos debug output
In-Reply-To: <D10502F4-8B41-4842-AE55-033C8F6460F2@oracle.com>
References: <D10502F4-8B41-4842-AE55-033C8F6460F2@oracle.com>
Message-ID: <8A6BF839-ABEE-4DBB-AC7D-B7199F94E84D@oracle.com>

p.s. If you wonder why it seems there is no change for HostAddress.java, it's just an indentation difference:

diff --git a/src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java b/src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java
--- a/src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java
+++ b/src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddress.java
@@ -211,7 +211,7 @@
         }
         if (DEBUG) {
             if (addrType == Krb5.ADDRTYPE_INET ||
-                addrType == Krb5.ADDRTYPE_INET6) {
+                    addrType == Krb5.ADDRTYPE_INET6) {
                 System.out.println("Host address is " +
                         InetAddress.getByAddress(address));
             }

Thanks,
Max


> On Dec 20, 2019, at 4:39 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please review the fix at
> 
>   https://cr.openjdk.java.net/~weijun/8236405/webrev.00
> 
> Most are trivial on whitespaces and commas etc. I've changed the "LSA" word to "native ccache" in Credentials.java because the output is for both Windows and macOS.
> 
> Thanks,
> Max
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191220/7b426a31/attachment-0001.htm>

From sgehwolf at redhat.com  Fri Dec 20 09:38:02 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 20 Dec 2019 10:38:02 +0100
Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the
 existing root program
In-Reply-To: <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com>
References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com>
 <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com>
 <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com>
 <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com>
Message-ID: <4e12d11cf3f3c7bdde176426049ec8fb011405e4.camel@redhat.com>

On Fri, 2019-12-20 at 07:42 +0000, Andrew John Hughes wrote:
> 
> On 19/12/2019 20:13, Severin Gehwolf wrote:
> 
> snip...
> 
> > > 
> > > Going on this & the similar Amazon fix, I'd say we should backport
> > > JDK-8193255 & JDK-8225392 first. The previous updates which alter a
> > > binary file have been pretty much unreviewable and, if there's a better
> > > solution to that, I'd rather we had it sooner rather than later.
> > 
> > I agree with you that we should backport JDK-8193255. Question is when
> > would be a good time to do this. Given that there would be some benefit
> > for these to go into 8u242 if possible I'm not sure we should do JDK-
> > 8193255 right now. After all, we've accepted this situation of having
> > the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 -
> > which brought this in - was integrated in 8u222.
> > 
> > The risk of a backport of JDK-8193255 seems higher (the build system in
> > 8u is different, there is a bug tail) than accepting these backports
> > with the binary blob updates. Note that the backports as-is have been
> > reviewed by Christoph Langer, Volker Simonis and internally by Martin
> > Balao.
> > 
> > So, it looks like there are the following options:
> >    1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is.
> >    2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK-
> >       8233223 to 8u242.
> >    3. Defer backports of 2) to 8u252 with the caveat that we won't have
> >       certain certificates as compared to Oracle JDK.
> > 
> > I'm leaning towards option 1) or 3). Slight preference for 1)
> > 
> > > Likewise, judging by the comment on JDK-8234245, I'd say that needs to
> > > be applied between the LuxTrust & Amazon ones:
> > > 
> > > "This fixes an issue after JDK-8232019, so it needs to be included.
> > > Patch applies cleanly."
> > 
> > Not sure what caused JDK-8234245. It might be that it was caused by the
> > list of certs in the keystore not being ordered at first (fixed by JDK-
> > 8225392?).
> > 
> > Thanks,
> > Severin
> > 
> 
> There's an option #4:
> 
> 4. Propose these backports for 8u242 and do the correct backports, with
> JDK-8193255 and friends, in 8u252.

OK.

> 8193255 is sensitive to the status of cacerts at the time it is applied.
> It needs to be backported with cacerts containing the same certificates
> as it did when applied in later versions, so that the textual
> replacements match. By applying these backports in 8u252, we'd
> complicate the 8193255 backport further by having to effectively include
> backports of the Amazon & LuxTrust updates in it.
> 
> So what I'd suggest is:
> 
> 1. Do the full backport series in 8u252 from 8193255 on.
> 2. Create a separate bug for 8u242 to add the new certificates and apply
> for jdk8u-critical-request for that.

Can you clarify why a separate bug for 8u242 would be needed? Why can't
we just use 8232019 and 8233223? I'd include mentioning 8232019 and
8233223 for the backport of 8193255 for it to be clear that it has been
taken care of those additional cert updates. The 8193255 backport would
only start once 8u242 backports got merged back into jdk8u-dev. At no
point we'd miss inclusion of those. Saves creation of extra bugs.

Thanks,
Severin

> When the two are merged together, the webrev changes in 8u242 should be
> the same as those in 8u252, and the changed cacerts binary can just be
> deleted.
> 
> Thanks,


From sean.mullan at oracle.com  Fri Dec 20 14:14:10 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 20 Dec 2019 09:14:10 -0500
Subject: RFR 8236405: Enhancement to Kerberos debug output
In-Reply-To: <D10502F4-8B41-4842-AE55-033C8F6460F2@oracle.com>
References: <D10502F4-8B41-4842-AE55-033C8F6460F2@oracle.com>
Message-ID: <157630d1-25ae-cfe6-7b1e-57405bdd87f1@oracle.com>

Looks fine to me. Since this is a bug, I would remove "Enhancement" from 
the title. Maybe "Formatting issues in Kerberos debug output".

--Sean

On 12/20/19 3:39 AM, Weijun Wang wrote:
> Please review the fix at
> 
>     https://cr.openjdk.java.net/~weijun/8236405/webrev.00
> 
> Most are trivial on whitespaces and commas etc. I've changed the "LSA" word to "native ccache" in Credentials.java because the output is for both Windows and macOS.
> 
> Thanks,
> Max
> 

From sha.jiang at oracle.com  Fri Dec 20 15:26:05 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Fri, 20 Dec 2019 23:26:05 +0800
Subject: RFR[14] JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests
 support TLSv1.3
Message-ID: <5929007e-afe7-a4c5-4050-69fdbc7cd4b7@oracle.com>

Hi,
Because the below tests use MD5withRSA certificates, so TLSv1.3 cannot 
be used.
test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
test/jdk/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java

This fix just re-generates the certificates to use SHA256withRSA.

Issue: https://bugs.openjdk.java.net/browse/JDK-8234727
Webrev: http://cr.openjdk.java.net/~jjiang/8234727/webrev.00/

Best regards,
John Jiang


From xuelei.fan at oracle.com  Fri Dec 20 16:50:42 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 20 Dec 2019 08:50:42 -0800
Subject: RFR[14] JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests
 support TLSv1.3
In-Reply-To: <5929007e-afe7-a4c5-4050-69fdbc7cd4b7@oracle.com>
References: <5929007e-afe7-a4c5-4050-69fdbc7cd4b7@oracle.com>
Message-ID: <ceaad158-aadc-d5f5-a9fb-39caff8faf4e@oracle.com>

Looks fine to me.  Thanks!

Xuelei

On 12/20/2019 7:26 AM, sha.jiang at oracle.com wrote:
> Hi,
> Because the below tests use MD5withRSA certificates, so TLSv1.3 cannot 
> be used.
> test/jdk/sun/security/ssl/X509TrustManagerImpl/BasicConstraints.java
> test/jdk/sun/security/ssl/X509TrustManagerImpl/SelfIssuedCert.java
> 
> This fix just re-generates the certificates to use SHA256withRSA.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8234727
> Webrev: http://cr.openjdk.java.net/~jjiang/8234727/webrev.00/
> 
> Best regards,
> John Jiang
> 

From mbalao at redhat.com  Sat Dec 21 01:03:29 2019
From: mbalao at redhat.com (Martin Balao)
Date: Fri, 20 Dec 2019 22:03:29 -0300
Subject: SunPKCS11's Secmod and external modules in FIPS mode
Message-ID: <54c3b155-5f71-11d9-f8e3-74a416263ff4@redhat.com>

Hello,

SunPKCS11's Secmod in OpenJDK does not allow modules other than the NSS
Software Token to be configured in FIPS mode [1]. To give some context,
NSS represents modules internally with a structure called "struct
SECMODModuleStr" and the "fips" variable you see in [1] is the "isFIPS"
member of the module structure [2]. isFIPS is initialized by NSS to
false for all modules [3] but if the module spec string has a "FIPS"
flag, it may be turned to true [4]. Newer NSS versions (since bug
1531267 [5] [6]) may set isFIPS to true for all modules when
/proc/sys/crypto/fips_enabled is 1 in Linux systems. As a result, as
soon as the system is in FIPS mode and the NSSDB has more than the NSS
Software Token module in it, OpenJDK refuses to initialize the SunPKCS11
provider. You can see a real case with pk11-kit-trust as the external
module in RH1780335 [7].

This behavior has been the same since the very beginning of OpenJDK
(revision 2), and I couldn't find much information about it. There might
be a commit message previous to that.

I'm trying to understand the rationale behind it and see what would be
the implications of removing the check (note: couldn't notice anything
in my quick test by removing it).

Can someone give me a hint?

Thanks,
Martin.-

--
[1] -
https://hg.openjdk.java.net/jdk/jdk/file/59ddac265649/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java#l417
[2] -
https://github.com/nss-dev/nss/blob/c1ff439ca931f53c318e7381636ed5889b3d66f1/lib/pk11wrap/secmodt.h#L49
[3] -
https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L49
[4] -
https://github.com/nss-dev/nss/blob/a141cd68ece76118aebf8033c06d46a3692b55fe/lib/pk11wrap/pk11pars.c#L819
[5] - https://bugzilla.mozilla.org/show_bug.cgi?id=1531267
[6] - https://hg.mozilla.org/projects/nss/rev/536fd7c9db5a
[7] - https://bugzilla.redhat.com/show_bug.cgi?id=1780335


From mbalao at redhat.com  Sat Dec 21 05:52:33 2019
From: mbalao at redhat.com (Martin Balao)
Date: Sat, 21 Dec 2019 02:52:33 -0300
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
In-Reply-To: <DB8PR02MB5547DC6C191080F6044FC5158A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
 <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>
 <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>
 <DB8PR02MB5547DC6C191080F6044FC5158A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <99aac7f6-6f6f-c024-4952-923ff0c0d875@redhat.com>

I'm not a reviewer but I've had a look at Severin's 8233223 backport and
looked good to me too (4 / 4 certificates verified).


From weijun.wang at oracle.com  Sat Dec 21 11:23:29 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 21 Dec 2019 19:23:29 +0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
Message-ID: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>

Please take a review at

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

The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.

For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.

Thanks,
Max


From weijun.wang at oracle.com  Sat Dec 21 11:47:31 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 21 Dec 2019 19:47:31 +0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
In-Reply-To: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
References: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
Message-ID: <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>

Oh, I take back the "mutates the internal" words, it didn't. algName is only a local variable.

So the major problem of the current code is that while getName() is modified to return the "full" signature algorithm name, getEncodedParams() still returns it.

I realized my fix does have the problem that AlgorithmId.parse(input).encode() will be different from input, but making change at the root is still better than recognizing specifiedWithECDSA_oid and ignoring parameters everywhere.

Thanks,
Max


> On Dec 21, 2019, at 7:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Please take a review at
> 
>   http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
> 
> The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.
> 
> For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.
> 
> Thanks,
> Max
> 


From goetz.lindenmaier at sap.com  Sat Dec 21 12:20:33 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sat, 21 Dec 2019 12:20:33 +0000
Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe
Message-ID: <AM6PR02MB5347B947DF95B331293572FEEC2C0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi,

I would like to downport this for parity with 11.0.7-Oracle.
It does not apply clean because in 11 changes were applied in 
a different order than in 14.

http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-jdk11/

In ECUtil.java I had to resolve the Copyright.
  
patching file src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp
This fails because "8221407: Windows 32bit build error in libsunmscapi/security.cpp" and 
"8210870: Libsunmscapi improved interactions" are already in 11, but in 14 they come
on top of this change.
I resolved this file so that it looks the same as in 14 after 8221407.

After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same changes
for security.cpp:

jdk11 Filelog for security.cpp:

8213010: Supporting keys created with certmgr.exe
8213009: Refactoring existing SunMSCAPI classes
8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed
8221407: Windows 32bit build error in libsunmscapi/security.cpp
8210870: Libsunmscapi improved interactions
8196897: Improve PRNG supportjdk-11.0.1+0
8205445: Add RSASSA-PSS Signature support to SunMSCAPI
8204572: SetupJdkLibrary should setup SRC and -I flags automatically
8193262: JNI array not released in libsunmscapi convertToLittleEndian
8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
8199198: Remove unused functions in jdk.crypto.mscapi native code
8187443: Forest Consolidation: Move files to unified layout

Jdk/jdk filelog for security.cpp:

8221407: Windows 32bit build error in libsunmscapi/security.cpp
8210870: Libsunmscapi improved interactions
8213010: Supporting keys created with certmgr.exe
8213009: Refactoring existing SunMSCAPI classes
8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed
8196897: Improve PRNG support
8205445: Add RSASSA-PSS Signature support to SunMSCAPI
8204572: SetupJdkLibrary should setup SRC and -I flags automatically
8193262: JNI array not released in libsunmscapi convertToLittleEndian
8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
8199198: Remove unused functions in jdk.crypto.mscapi native code
8187443: Forest Consolidation: Move files to unified layout

Jdk/jdk has two changes on top of this.
But if updating to 8221407 in jdk/jdk, security.cpp are
Similar in both repos.

Best regards,
  Goetz.

From weijun.wang at oracle.com  Sat Dec 21 13:33:49 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 21 Dec 2019 21:33:49 +0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
In-Reply-To: <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>
References: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
 <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>
Message-ID: <02B6893C-7915-4436-A97B-27A8E9209315@oracle.com>

I uploaded a less disruptive webrev at https://cr.openjdk.java.net/~weijun/8236470/webrev.01.

--Max

> On Dec 21, 2019, at 7:47 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
> 
> Oh, I take back the "mutates the internal" words, it didn't. algName is only a local variable.
> 
> So the major problem of the current code is that while getName() is modified to return the "full" signature algorithm name, getEncodedParams() still returns it.
> 
> I realized my fix does have the problem that AlgorithmId.parse(input).encode() will be different from input, but making change at the root is still better than recognizing specifiedWithECDSA_oid and ignoring parameters everywhere.
> 
> Thanks,
> Max
> 
> 
>> On Dec 21, 2019, at 7:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>> 
>> Please take a review at
>> 
>>  http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
>> 
>> The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.
>> 
>> For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.
>> 
>> Thanks,
>> Max
>> 
> 


From volker.simonis at gmail.com  Sat Dec 21 15:06:46 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 21 Dec 2019 16:06:46 +0100
Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates
In-Reply-To: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>
References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com>
 <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com>
 <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com>
Message-ID: <CA+3eh13Un9oAWn_Wh7PBizGnDm4-5V3w0xfntfpUDo-FipWULw@mail.gmail.com>

On Thu, Dec 19, 2019 at 11:09 AM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi Volker,
>
> On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote:
> > Hi Severin,
> >
> > not strictly a 8u "Reviewer" yet, but I've looked at your changes
> > (this one and 8232019) nevertheless :)
>
> Thanks for the review!
>
> > They both look good, except that I can not verify the new "cacert"
> > file because it is not in the patch (because it is binary). Not sure
> > if it is necessary to upload the whole file to cr.openjdk.java.net as
> > well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and
> > security/infra/java/security/cert/CertPathValidator/certification both
> > pass, then everything seems to be fine.
>
> FWIW the raw download of the webrev's cacerts file should have the
> binary blob:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts
>

Yes, you're right. Didn't thought about that.

I've now downloaded it and can confirm that, as you wrote, all the
relevant tests except ActalisCA.java pass.

So, still thumbs up from me :)

Regards,
Volker

> And for 8232019:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts
>
> Thanks,
> Severin
>
> > So thumbs up from me (for both, this one and 8232019).
> >
> > Best regards,
> > Volker
> >
> > On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
> > > Hi,
> > >
> > > Could I please get a review of this OpenJDK 8u backport of 8233223
> > > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not
> > > apply cleanly for a couple of reasons:
> > >
> > >    1. 8u still has the binary blob for cacerts (JDK-8193255
> > >       not backported, yet). Instead, I've updated to the revision in
> > >       jdk11u, performed a build and copied the cacerts binary to 8u.
> > >    2. JDK-8225392 not present in 8u, which added the checksum to
> > >       VerifyCACerts.java. Thus, the 8u backport does not include
> > >       this hunk.
> > >    3. JDK-8234245 not present in 8u.
> > >    4. Due to 2) and 3) above @bug annotation modified manually for these
> > >       reasons.
> > >
> > > Everything else is the same.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/
> > >
> > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and
> > >          security/infra/java/security/cert/CertPathValidator/certification
> > >          Pass, except for ActalisCA.java which is problem-listed and still
> > >          broken in HEAD (JDK-8224768)
> > >
> > > Thoughts?
> > >
> > > Once reviewed, I'll try to get this into 8u242 via the critical fix
> > > request label workflow.
> > >
> > > Thanks,
> > > Severin
> > >
> > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html
> > >
>

From ecki at zusammenkunft.net  Sat Dec 21 21:15:30 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 21 Dec 2019 21:15:30 +0000
Subject: Microsoft LDAP Channel Binding
In-Reply-To: <74cf2a20-acc1-a210-2778-005b3b5e1309@gmx.net>
References: <AM5PR0301MB25298BE2147CA3561358F4B0FF530@AM5PR0301MB2529.eurprd03.prod.outlook.com>,
 <74cf2a20-acc1-a210-2778-005b3b5e1309@gmx.net>
Message-ID: <DB6PR0301MB2536383F127C277C121CB32BFF2C0@DB6PR0301MB2536.eurprd03.prod.outlook.com>

Hello,

I have been able to set-up a Windows 2019 Domain, so I did some testing with simple and disgest-MD5. As expected both will be rejected when the integritylevel=2 is set.

For Digest-md5 it is enough to request Auth-int with AD to get over this check (funny enough it seems to not sign requests only the login).

Here is some sample code and sample output:

https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0

(The password used was not the one shown).

BTW: in order to use DIGEST-MD5 with a AD user the user's password "encryption" must be configured to be reversible (and a new password must be set).

Next will be testing with TLS (and channel binding) once I get the LDAP certificate set up for this.
--
http://bernd.eckenfels.net

________________________________
Von: Michael Osipov <1983-01-06 at gmx.net>
Gesendet: Mittwoch, Dezember 18, 2019 6:37 PM
An: Bernd Eckenfels; security-dev at openjdk.java.net
Betreff: Re: Microsoft LDAP Channel Binding

Am 2019-12-18 um 04:29 schrieb Bernd Eckenfels:
> Hello,
>
> Microsoft just released an Security Advisory, announcing that upcoming Windows Server Versions will turn on mandatory TLS Channel Binding (and turn off simple binds with mandatory SASL signing) on LDAP Servers.

Another question here, typically Microsoft: What makes you think that
this is TLS channel binding? All I see is LDAP channel binding for which
I fail to find any technical documentation.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20191221/64999dc7/attachment-0001.htm>

From xuelei.fan at oracle.com  Mon Dec 23 16:11:01 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 23 Dec 2019 08:11:01 -0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
In-Reply-To: <02B6893C-7915-4436-A97B-27A8E9209315@oracle.com>
References: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
 <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>
 <02B6893C-7915-4436-A97B-27A8E9209315@oracle.com>
Message-ID: <f45e8350-56d4-7d3c-8b14-a9b65550b2c0@oracle.com>

Will the update for getEncodedParams() has other compatibility impact? 
As it is a public method, I'm not sure if the update is necessary and 
will impact ECDSA encoding in other places.  Please double check it.

Otherwise, looks good to me.

Xuelei

On 12/21/2019 5:33 AM, Weijun Wang wrote:
> I uploaded a less disruptive webrev at https://cr.openjdk.java.net/~weijun/8236470/webrev.01.
> 
> --Max
> 
>> On Dec 21, 2019, at 7:47 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>
>> Oh, I take back the "mutates the internal" words, it didn't. algName is only a local variable.
>>
>> So the major problem of the current code is that while getName() is modified to return the "full" signature algorithm name, getEncodedParams() still returns it.
>>
>> I realized my fix does have the problem that AlgorithmId.parse(input).encode() will be different from input, but making change at the root is still better than recognizing specifiedWithECDSA_oid and ignoring parameters everywhere.
>>
>> Thanks,
>> Max
>>
>>
>>> On Dec 21, 2019, at 7:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>
>>> Please take a review at
>>>
>>>   http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
>>>
>>> The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.
>>>
>>> For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.
>>>
>>> Thanks,
>>> Max
>>>
>>
> 

From christoph.langer at sap.com  Mon Dec 23 16:42:00 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Dec 2019 16:42:00 +0000
Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe
In-Reply-To: <AM6PR02MB5347B947DF95B331293572FEEC2C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
References: <AM6PR02MB5347B947DF95B331293572FEEC2C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984FDF15A1DF43A629A73638A2E0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Goetz,

this looks good to me. I compared security.cpp after I've applied your changes to the version in jdk/jdk and there are only the changes missing that come with newer changes JDK-8223003 and JDK-8223063.

Thanks for backporting this.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Samstag, 21. Dezember 2019 13:21
> To: jdk-updates-dev at openjdk.java.net; OpenJDK Dev list <security-
> dev at openjdk.java.net>
> Subject: [CAUTION] [11u] RFR: 8213010: Supporting keys created with
> certmgr.exe
> 
> Hi,
> 
> I would like to downport this for parity with 11.0.7-Oracle.
> It does not apply clean because in 11 changes were applied in
> a different order than in 14.
> 
> http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-jdk11/
> 
> In ECUtil.java I had to resolve the Copyright.
> 
> patching file
> src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp
> This fails because "8221407: Windows 32bit build error in
> libsunmscapi/security.cpp" and
> "8210870: Libsunmscapi improved interactions" are already in 11, but in 14
> they come
> on top of this change.
> I resolved this file so that it looks the same as in 14 after 8221407.
> 
> After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same
> changes
> for security.cpp:
> 
> jdk11 Filelog for security.cpp:
> 
> 8213010: Supporting keys created with certmgr.exe
> 8213009: Refactoring existing SunMSCAPI classes
> 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
> 8201355: Avoid native memory allocation in
> sun.security.mscapi.PRNG.generateSeed
> 8221407: Windows 32bit build error in libsunmscapi/security.cpp
> 8210870: Libsunmscapi improved interactions
> 8196897: Improve PRNG supportjdk-11.0.1+0
> 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
> 8204572: SetupJdkLibrary should setup SRC and -I flags automatically
> 8193262: JNI array not released in libsunmscapi convertToLittleEndian
> 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
> 8199198: Remove unused functions in jdk.crypto.mscapi native code
> 8187443: Forest Consolidation: Move files to unified layout
> 
> Jdk/jdk filelog for security.cpp:
> 
> 8221407: Windows 32bit build error in libsunmscapi/security.cpp
> 8210870: Libsunmscapi improved interactions
> 8213010: Supporting keys created with certmgr.exe
> 8213009: Refactoring existing SunMSCAPI classes
> 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
> 8201355: Avoid native memory allocation in
> sun.security.mscapi.PRNG.generateSeed
> 8196897: Improve PRNG support
> 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
> 8204572: SetupJdkLibrary should setup SRC and -I flags automatically
> 8193262: JNI array not released in libsunmscapi convertToLittleEndian
> 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
> 8199198: Remove unused functions in jdk.crypto.mscapi native code
> 8187443: Forest Consolidation: Move files to unified layout
> 
> Jdk/jdk has two changes on top of this.
> But if updating to 8221407 in jdk/jdk, security.cpp are
> Similar in both repos.
> 
> Best regards,
>   Goetz.

From goetz.lindenmaier at sap.com  Mon Dec 23 17:30:13 2019
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Dec 2019 17:30:13 +0000
Subject: [11u] RFR: 8213010: Supporting keys created with certmgr.exe
In-Reply-To: <AM6PR02MB4984FDF15A1DF43A629A73638A2E0@AM6PR02MB4984.eurprd02.prod.outlook.com>
References: <AM6PR02MB5347B947DF95B331293572FEEC2C0@AM6PR02MB5347.eurprd02.prod.outlook.com>
 <AM6PR02MB4984FDF15A1DF43A629A73638A2E0@AM6PR02MB4984.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB534730ADA35E2C187112033BEC2E0@AM6PR02MB5347.eurprd02.prod.outlook.com>

Hi Christoph, 

Thanks for reviewing!

Best regards,
  Goetz.

> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Monday, December 23, 2019 5:42 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net; OpenJDK Dev list <security-dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8213010: Supporting keys created with certmgr.exe
> 
> Hi Goetz,
> 
> this looks good to me. I compared security.cpp after I've applied your
> changes to the version in jdk/jdk and there are only the changes missing that
> come with newer changes JDK-8223003 and JDK-8223063.
> 
> Thanks for backporting this.
> 
> Cheers
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Samstag, 21. Dezember 2019 13:21
> > To: jdk-updates-dev at openjdk.java.net; OpenJDK Dev list <security-
> > dev at openjdk.java.net>
> > Subject: [CAUTION] [11u] RFR: 8213010: Supporting keys created with
> > certmgr.exe
> >
> > Hi,
> >
> > I would like to downport this for parity with 11.0.7-Oracle.
> > It does not apply clean because in 11 changes were applied in
> > a different order than in 14.
> >
> > http://cr.openjdk.java.net/~goetz/wr19/8213010-certmgr.exe_keys-
> jdk11/
> >
> > In ECUtil.java I had to resolve the Copyright.
> >
> > patching file
> > src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp
> > This fails because "8221407: Windows 32bit build error in
> > libsunmscapi/security.cpp" and
> > "8210870: Libsunmscapi improved interactions" are already in 11, but in 14
> > they come
> > on top of this change.
> > I resolved this file so that it looks the same as in 14 after 8221407.
> >
> > After pushing 8213009 and this, jdk11u-dev and jdk/jdk will have the same
> > changes
> > for security.cpp:
> >
> > jdk11 Filelog for security.cpp:
> >
> > 8213010: Supporting keys created with certmgr.exe
> > 8213009: Refactoring existing SunMSCAPI classes
> > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
> > 8201355: Avoid native memory allocation in
> > sun.security.mscapi.PRNG.generateSeed
> > 8221407: Windows 32bit build error in libsunmscapi/security.cpp
> > 8210870: Libsunmscapi improved interactions
> > 8196897: Improve PRNG supportjdk-11.0.1+0
> > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
> > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically
> > 8193262: JNI array not released in libsunmscapi convertToLittleEndian
> > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
> > 8199198: Remove unused functions in jdk.crypto.mscapi native code
> > 8187443: Forest Consolidation: Move files to unified layout
> >
> > Jdk/jdk filelog for security.cpp:
> >
> > 8221407: Windows 32bit build error in libsunmscapi/security.cpp
> > 8210870: Libsunmscapi improved interactions
> > 8213010: Supporting keys created with certmgr.exe
> > 8213009: Refactoring existing SunMSCAPI classes
> > 8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow
> > 8201355: Avoid native memory allocation in
> > sun.security.mscapi.PRNG.generateSeed
> > 8196897: Improve PRNG support
> > 8205445: Add RSASSA-PSS Signature support to SunMSCAPI
> > 8204572: SetupJdkLibrary should setup SRC and -I flags automatically
> > 8193262: JNI array not released in libsunmscapi convertToLittleEndian
> > 8198898: Compilation errors in jdk.crypto.mscapi with VS 2017
> > 8199198: Remove unused functions in jdk.crypto.mscapi native code
> > 8187443: Forest Consolidation: Move files to unified layout
> >
> > Jdk/jdk has two changes on top of this.
> > But if updating to 8221407 in jdk/jdk, security.cpp are
> > Similar in both repos.
> >
> > Best regards,
> >   Goetz.

From weijun.wang at oracle.com  Tue Dec 24 06:32:47 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 24 Dec 2019 14:32:47 +0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
In-Reply-To: <f45e8350-56d4-7d3c-8b14-a9b65550b2c0@oracle.com>
References: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
 <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>
 <02B6893C-7915-4436-A97B-27A8E9209315@oracle.com>
 <f45e8350-56d4-7d3c-8b14-a9b65550b2c0@oracle.com>
Message-ID: <97F321E5-7D00-40BB-B2F1-453064697B8D@oracle.com>



> On Dec 24, 2019, at 12:11 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> Will the update for getEncodedParams() has other compatibility impact? As it is a public method, I'm not sure if the update is necessary and will impact ECDSA encoding in other places.  Please double check it.

With the current code, ECDSA will always fail when trying to parse a parameters byte array containing a hash algorithm. Therefore this fix will not bring more error.

The only parameter for a ECDSA algorithm we can handle now is ECParameters (named curve). For ecdsa-with-SHA2, the parameter already contains the hash algorithm and I have no idea where to put the curve name. My fix just throws away the whole parameter. This should not be a problem since an EC key already knows its curve, and the best ECDSA can do is to reject the signature if the curve there does not match the key's curve. 

The final copy of https://tools.ietf.org/html/rfc5758 didn't mention ecdsa-with-SHA2 at all. It was removed in an earlier draft [1] and hopefully no one should be using it.

Thanks,
Max

[1] https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-pkix-sha2-dsa-ecdsa-05.txt

> 
> Otherwise, looks good to me.
> 
> Xuelei
> 
> On 12/21/2019 5:33 AM, Weijun Wang wrote:
>> I uploaded a less disruptive webrev at https://cr.openjdk.java.net/~weijun/8236470/webrev.01.
>> --Max
>>> On Dec 21, 2019, at 7:47 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>> 
>>> Oh, I take back the "mutates the internal" words, it didn't. algName is only a local variable.
>>> 
>>> So the major problem of the current code is that while getName() is modified to return the "full" signature algorithm name, getEncodedParams() still returns it.
>>> 
>>> I realized my fix does have the problem that AlgorithmId.parse(input).encode() will be different from input, but making change at the root is still better than recognizing specifiedWithECDSA_oid and ignoring parameters everywhere.
>>> 
>>> Thanks,
>>> Max
>>> 
>>> 
>>>> On Dec 21, 2019, at 7:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>> 
>>>> Please take a review at
>>>> 
>>>>  http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
>>>> 
>>>> The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.
>>>> 
>>>> For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.
>>>> 
>>>> Thanks,
>>>> Max
>>>> 
>>> 


From xuelei.fan at oracle.com  Tue Dec 24 16:19:48 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 24 Dec 2019 08:19:48 -0800
Subject: RFR 8236470: Deal with ECDSA using ecdsa-with-SHA2 plus hash
 algorithm as AlgorithmId
In-Reply-To: <97F321E5-7D00-40BB-B2F1-453064697B8D@oracle.com>
References: <A2B3888B-5868-41A2-8005-6477907A7F83@oracle.com>
 <1E70DAE4-EDCE-4E8D-BE26-898898A90065@oracle.com>
 <02B6893C-7915-4436-A97B-27A8E9209315@oracle.com>
 <f45e8350-56d4-7d3c-8b14-a9b65550b2c0@oracle.com>
 <97F321E5-7D00-40BB-B2F1-453064697B8D@oracle.com>
Message-ID: <bfda781b-9e0d-9961-1cfe-4cf3a6b407e3@oracle.com>

It makes sense to me.  No other comment. Thanks!

Xuelei

On 12/23/2019 10:32 PM, Weijun Wang wrote:
> 
> 
>> On Dec 24, 2019, at 12:11 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>
>> Will the update for getEncodedParams() has other compatibility impact? As it is a public method, I'm not sure if the update is necessary and will impact ECDSA encoding in other places.  Please double check it.
> 
> With the current code, ECDSA will always fail when trying to parse a parameters byte array containing a hash algorithm. Therefore this fix will not bring more error.
> 
> The only parameter for a ECDSA algorithm we can handle now is ECParameters (named curve). For ecdsa-with-SHA2, the parameter already contains the hash algorithm and I have no idea where to put the curve name. My fix just throws away the whole parameter. This should not be a problem since an EC key already knows its curve, and the best ECDSA can do is to reject the signature if the curve there does not match the key's curve.
> 
> The final copy of https://tools.ietf.org/html/rfc5758 didn't mention ecdsa-with-SHA2 at all. It was removed in an earlier draft [1] and hopefully no one should be using it.
> 
> Thanks,
> Max
> 
> [1] https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-pkix-sha2-dsa-ecdsa-05.txt
> 
>>
>> Otherwise, looks good to me.
>>
>> Xuelei
>>
>> On 12/21/2019 5:33 AM, Weijun Wang wrote:
>>> I uploaded a less disruptive webrev at https://cr.openjdk.java.net/~weijun/8236470/webrev.01.
>>> --Max
>>>> On Dec 21, 2019, at 7:47 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>
>>>> Oh, I take back the "mutates the internal" words, it didn't. algName is only a local variable.
>>>>
>>>> So the major problem of the current code is that while getName() is modified to return the "full" signature algorithm name, getEncodedParams() still returns it.
>>>>
>>>> I realized my fix does have the problem that AlgorithmId.parse(input).encode() will be different from input, but making change at the root is still better than recognizing specifiedWithECDSA_oid and ignoring parameters everywhere.
>>>>
>>>> Thanks,
>>>> Max
>>>>
>>>>
>>>>> On Dec 21, 2019, at 7:23 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>
>>>>> Please take a review at
>>>>>
>>>>>   http://cr.openjdk.java.net/~weijun/8236470/webrev.00/
>>>>>
>>>>> The current implementation is not good at dealing with ECDSA specified by ecdsa-with-SHA2 plus a hash algorithm. While the AlgorithmId::getName is able to return the "full" signature algorithm name, it mutates the internal, cannot be guaranteed to be called, and leaves the parameters unchanged. This fix move the logic to AlgorithmId::parse and the class becomes practically immutable.
>>>>>
>>>>> For Oracle internal reviewers: An update is made to the test also. The closed path has been wrong since the repo consolidation. We do have such certs in the closed area.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>
>