Hi,
Please review the proposal to update the default SSL session cache size
from infinite to 20480.
https://bugs.openjdk.java.net/browse/JDK-8213577
I know that the default 20480 does not fit all. I'd appreciate your
feedback if the value is acceptable.
Thanks,
Xuelei
> On Nov 9, 2018, at 12:28 AM, Adam Petcher wrote:
>
> On 11/8/2018 8:10 AM, Weijun Wang wrote:
>
>> - CurveDB.java:
>>
>> -add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,
>> +add("sect163r2 [NIST B-163]", "1.3.132.0.15", B,
>>
>> All other NIST B-*** curves do not have BD
To make sure the SecureCacheResponse class work, two new tests are added
(DefaultCacheResponse for default implementation, DummyCacheResponse for
a test implementation):
http://cr.openjdk.java.net/~xuelei/8212261/webrev.04/
Thanks,
Xuelei
On 11/8/2018 7:03 AM, Sean Mullan wrote:
On 11/7/1
On 11/7/18 3:52 AM, Baesken, Matthias wrote:
Sorry, I haven't had time to look at this in more detail yet. But, let's
take a step back first. Can you or Matthias explain in more detail why
this fix is necessary? What are the use cases and motivation?
Hello,
adding paths (or maybe more det
Oops. And the JBS ticket: https://bugs.openjdk.java.net/browse/JDK-8213363
On 11/8/2018 11:43 AM, Adam Petcher wrote:
webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8213493
This change fixes a bug related to the encoded format of X
webrev: http://cr.openjdk.java.net/~apetcher/8213363/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8213493
This change fixes a bug related to the encoded format of X25519/X448
private keys. The new code will not preserve compatibility with the
improperly-formatted keys produced by th
On 08/11/2018 15:03, Sean Mullan wrote:
Ah, I see. I am sure there is a good reason, but why doesn't it have an
implementation?
IIRC there was an implementation in the deploy code.
best regards,
-- daniel
On 11/8/2018 8:10 AM, Weijun Wang wrote:
- CurveDB.java:
-add("sect163r2 [NIST B-163]", "1.3.132.0.15", BD,
+add("sect163r2 [NIST B-163]", "1.3.132.0.15", B,
All other NIST B-*** curves do not have BD. This should have been a typo.
I think this will change the default 163-bit
I'm missing the motivation behind this question. Is the current set of
aliases causing some problem? Are they incomplete? Why is it bad that
"X9.62 prime256v1" works but "prime256v1" doesn't?
On 11/7/2018 10:05 PM, Weijun Wang wrote:
In CurveDB.java, we have
add("secp256r1 [NIST P-256, X9.62
Hi Sean,
I think we could still call the event
"jdk.SecurityPropertyModification", but add a @Description that explains
that events are only emitted for the JDK due to security concerns. If we
at a later stage want to include user events, we could add those and
remove the @Description, possib
On 11/7/2018 8:53 PM, Weijun Wang wrote:
Oh, I didn't know that.
To make sure -keyalg matches KeyPairGenerator.getInstance(), I'd like to
support it. If I read the impl correctly, you don't need to initialize it
anymore and if you really want to initialize it the params must be the same.
Cur
On 11/7/18 7:22 PM, Xuelei Fan wrote:
On 11/7/2018 1:30 PM, Sean Mullan wrote:
https://bugs.openjdk.java.net/browse/JDK-8213161
http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/
I didn't see a test for SecureCacheResponse - is it possible?
JDK does not have the reference implementat
Please also review the code change at
https://cr.openjdk.java.net/~weijun/8213400/webrev.00/
Notes:
- CertAndKeyGen.java:
generate(String name):
+try {
+keyGen.initialize(new NamedParameterSpec(name), prng);
+} catch (InvalidAlgorithmParameterExceptio
13 matches
Mail list logo
