RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

During TLS handshake, hundreds of constraints are evaluated to determine which cipher suites are usable. Most of the evaluations are performed using `HandshakeContext#algorithmConstraints` object. By default that object contains a `SSLAlgorithmConstraints` instance wrapping another

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote: > During TLS handshake, hundreds of constraints are evaluated to determine > which cipher suites are usable. Most of the evaluations are performed using > `HandshakeContext#algorithmConstraints` object. By default that object > contains

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote: > During TLS handshake, hundreds of constraints are evaluated to determine > which cipher suites are usable. Most of the evaluations are performed using > `HandshakeContext#algorithmConstraints` object. By default that object > contains

Java Cryptographic Extension Survey

Hello, Java Cryptographic Extension (JCE) has been in Java SE for a long time and has made incremental changes over the years. Looking forward, we would like to know more about how projects are using JCE and what changes, features, and API enhancements would be helpful for your projects.

Re: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec

On Tue, 12 Apr 2022 02:48:51 GMT, Michael StJohns wrote: > I think deprecating DEFAULT? is wrong.? RFC8017 still has this definition: > > > RSAES-OAEP-params ::= SEQUENCE { > > hashAlgorithm [0] HashAlgorithm DEFAULT sha1, > > maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1,

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote: > During TLS handshake, hundreds of constraints are evaluated to determine > which cipher suites are usable. Most of the evaluations are performed using > `HandshakeContext#algorithmConstraints` object. By default that object > contains

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 15:19:41 GMT, Daniel Jeliński wrote: >> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java >> line 73: >> >>> 71: >>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints >>> userSpecifiedConstraints) { >>> 73: if

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote: > During TLS handshake, hundreds of constraints are evaluated to determine > which cipher suites are usable. Most of the evaluations are performed using > `HandshakeContext#algorithmConstraints` object. By default that object > contains

RFR: 8284796: sun.security.ssl.Finished::toString misses a line feed in the message format pattern

The log for Finished message looks like the below, "Finished": { "verify data": { : ... ... }'} // looks weird because a line feed is missing in the format pattern. ""Finished": '{'\n" + " "verify data": '{'\n" + "{0}\n" + " '}'" + // a line feed is needed "'}'", -

Re: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto

On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto src/java.base/share/classes/javax/crypto/CryptoPermission.java line 437: > 435: // may be the best try. > 436: return this.algParamSpec.equals(algParamSpec); >

Re: RFR: JDK-8284112 Minor cleanup could be done in javax.crypto

On Tue, 12 Apr 2022 21:59:09 GMT, Mark Powers wrote: > JDK-8284112 Minor cleanup could be done in javax.crypto Can you file a bug to update the javax.crypto files to use proper javadoc for mentioned classes, e.g. < code> tags. src/java.base/share/classes/javax/crypto/CryptoPermissions.java

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 15:40:46 GMT, Claes Redestad wrote: >> While this is technically true, `SSLAlgorithmConstraints` is an internal >> class, so it's very unlikely that we will ever get `SSLAlgorithmConstraints` >> other than `DEFAULT` here. > > Right, I see even `DEFAULT_SSL_ONLY` is only

Withdrawn: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

On Tue, 12 Apr 2022 16:55:28 GMT, Mat Carter wrote: > On Windows you can now access the local machine keystores using the strings > "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the > application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain

RFR: 6782021: add support for localmachine keystores on windows

On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the

Re: RFR: 8284694: Avoid evaluating SSLAlgorithmConstraints twice

On Tue, 12 Apr 2022 13:38:17 GMT, Claes Redestad wrote: >> During TLS handshake, hundreds of constraints are evaluated to determine >> which cipher suites are usable. Most of the evaluations are performed using >> `HandshakeContext#algorithmConstraints` object. By default that object >>

RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

On Windows you can now access the local machine keystores using the strings "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the application requires admin privileges. "Windows-MY" and "Windows-ROOT" remain unchanged, however given these original keystore strings mapped to the

Re: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider [v2]

> On Windows you can now access the local machine keystores using the strings > "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the > application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain unchanged, however given these > original keystore strings

Re: Proposal: Extend Windows KeyStore support to include access to the local machine location

Weijun Here's a PR [1] if you would like to review and consider sponsoring [1] https://github.com/openjdk/jdk/pull/8211 Cheers Mat Sent from Outlook From: Wei-Jun Wang Sent: Monday, April 11, 2022 3:33 PM To: Mat Carter Cc: Bernd

Re: Proposal: Extend Windows KeyStore support to include access to the local machine location

No problem. The code change looks fine to me but you will need to create a CSR. I'll add a comment in the PR. Thanks, Weijun > On Apr 12, 2022, at 5:37 PM, Mat Carter wrote: > > Weijun > > Here's a PR [1] if you would like to review and consider sponsoring > > [1]

RFR: JDK-8284112 Minor cleanup could be done in javax.crypto

JDK-8284112 Minor cleanup could be done in javax.crypto - Commit messages: - second iteration - Merge - first iteration Changes: https://git.openjdk.java.net/jdk/pull/8214/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8214=00 Issue:

Re: RFR: JDK-6782021: It is not possible to read local computer certificates with the SunMSCAPI provider

On Tue, 12 Apr 2022 19:03:40 GMT, Mat Carter wrote: > On Windows you can now access the local machine keystores using the strings > "Windows-MY-LOCALMACHINE" and "Windows-ROOT-LOCALMACHINE"; note the > application requires admin privileges. > > "Windows-MY" and "Windows-ROOT" remain