On Thu, 8 Apr 2021 01:33:56 GMT, Weijun Wang wrote:
>> This code change does not intend to support multiple byte tags. Instead, it
>> aims to fail more gracefully when such a tag is encountered. For `DerValue`
>> constructors from an encoding (type I), an `IOException` will be thrown
>> since
On Thu, 8 Apr 2021 01:48:20 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
On Thu, 8 Apr 2021 01:42:16 GMT, Hai-May Chao wrote:
>> test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 96:
>>
>>> 94:
>>> 95: Certificate[] certChain = kstore.getCertificateChain("e1");
>>> 96: if (certChain.length != 2) {
>>
>> Try using `Asserts` class in
On Thu, 8 Apr 2021 01:48:20 GMT, Hai-May Chao wrote:
>> In testSignerJKS() has made sure that the new entry created with new key
>> password can *only* be accessed when a correct key password is provided in
>> order to retrieve the corresponding signer’s private key.
>
> The new entry
On Thu, 8 Apr 2021 01:42:18 GMT, Hai-May Chao wrote:
>> test/jdk/sun/security/tools/keytool/GenKeyPairSigner.java line 299:
>>
>>> 297: System.exit(1);
>>> 298: }
>>> 299:
>>
>> Since you are here, you can check if the new entry is indeed protected by
>> the new key
On Thu, 8 Apr 2021 00:01:57 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update with review comments
>
> src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java
> line 88:
>
> Please review the changes that adds the -signer option to keytool -genkeypair
> command. As key agreement algorithms do not have a signing algorithm, the
> specified signer's private key will be used to sign and generate a key
> agreement certificate.
> CSR review is at:
> This code change does not intend to support multiple byte tags. Instead, it
> aims to fail more gracefully when such a tag is encountered. For `DerValue`
> constructors from an encoding (type I), an `IOException` will be thrown since
> it's already in the throws clause. For constructors from
This code change does not intend to support multiple byte tags. Instead, it
aims to fail more gracefully when such a tag is encountered. For `DerValue`
constructors from an encoding (type I), an `IOException` will be thrown since
it's already in the throws clause. For constructors from tag and
On Wed, 7 Apr 2021 23:17:53 GMT, Hai-May Chao wrote:
>> Please review the changes that adds the -signer option to keytool
>> -genkeypair command. As key agreement algorithms do not have a signing
>> algorithm, the specified signer's private key will be used to sign and
>> generate a key
> Please review the changes that adds the -signer option to keytool -genkeypair
> command. As key agreement algorithms do not have a signing algorithm, the
> specified signer's private key will be used to sign and generate a key
> agreement certificate.
> CSR review is at:
On Fri, 2 Apr 2021 11:52:16 GMT, Weijun Wang wrote:
>>> Maybe we don't need to resolve it in this code change. If we look carefully
>>> at RFC 8410 Sections 10.1 and 10.2, it shows the X25519 certificate in 10.2
>>> is using the signer's SKID in 10.1 as its own SKID and it has no AKID.
>>>
On Fri, 2 Apr 2021 01:40:16 GMT, Weijun Wang wrote:
>> Hai-May Chao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update with review comments
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 1978:
>
>> 1976:
Hmm, could have sworn...
Thanks,
Paul
-Original Message-
From: "Langer, Christoph"
Date: Wednesday, April 7, 2021 at 3:16 PM
To: "Hohensee, Paul" , "Doerr, Martin"
, jdk-updates-dev ,
security-dev
Cc: "Lindenmaier, Goetz"
Subject: RE: [11u] RFR: 8226374: Restrict TLS signature
Hi Paul,
thanks for the review. The CSR that Martin mentions is the one that Oracle has
filed for 11.0.12-oracle. so we can simply reuse it.
As for 13, there exists a CSR as well: JDK-8256335
Best regards
Christoph
> -Original Message-
> From: Hohensee, Paul
> Sent: Mittwoch, 7.
The backport looks fine, except there's a missing blank line after FFDHE_2048
in NamedGroup.java. :) Thanks for filing a CSR (there doesn't seem to be one
for the 13u backport: perhaps Yan will add one after the fact). I'm not a
security person, so it would be great if someone who is reviews
On Tue, 6 Apr 2021 18:30:31 GMT, Martin Balao wrote:
>> Hi,
>>
>> I'd like to propose a fix for JDK-8261355 [1].
>>
>> The scheme used for holding data and padding while performing encryption
>> operations is almost the same than the existing one for decryption. The only
>> difference is
On Wed, 7 Apr 2021 16:42:53 GMT, Valerie Peng wrote:
>> @valeriepeng please take a look at my comments in-line and the new proposal
>> here:
>> https://github.com/openjdk/jdk/pull/2510/commits/b47c03edff1f48b925a67203102385470ac1afdc
>>
>> Thanks,
>> Martin.-
>
> Sure, will take another look.
On Tue, 6 Apr 2021 14:26:00 GMT, Martin Balao wrote:
>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
>> line 265:
>>
>>> 263: // NSS requires block-sized updates in multi-part
>>> operations.
>>> 264: reqBlockUpdates =
I agree that the response from Housley certainly supports that
"AutoPadding" is likely a safe mode to use. I still would prefer not to see
it (keeping things simple) but don't really have any objections to it.
For KW+PKCS5, I have (unfortunately) seen this deployed in the real world
and had to
*sigh* Minor correction in line.
On 4/7/2021 2:49 PM, Michael StJohns wrote:
On 4/7/2021 1:28 PM, Greg Rubin wrote:
Mike,
Yes, this was in response to your comment.
I'm aware that the IV really serves more as an integrity check and
mode signalling mechanism than anything else. My concern is
On 4/7/2021 1:28 PM, Greg Rubin wrote:
Mike,
Yes, this was in response to your comment.
I'm aware that the IV really serves more as an integrity check and
mode signalling mechanism than anything else. My concern is that in
the past few years I've seen various issues related to "in band
On Wed, 31 Mar 2021 21:47:24 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of the locking change to the RSA blinding code. The problem
> was reported that multithreaded performance suffered because there was one
> global lock on the many blindings operation. The change reduces
Mike,
Yes, this was in response to your comment.
I'm aware that the IV really serves more as an integrity check and mode
signalling mechanism than anything else. My concern is that in the past few
years I've seen various issues related to "in band signalling" where
something about the ciphertext
On Tue, 6 Apr 2021 18:29:56 GMT, Martin Balao wrote:
>> I will take a look.
>> Thanks~
>
> @valeriepeng please take a look at my comments in-line and the new proposal
> here:
> https://github.com/openjdk/jdk/pull/2510/commits/b47c03edff1f48b925a67203102385470ac1afdc
>
> Thanks,
> Martin.-
Hi,
JDK-8226374 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly. I've taken the 13u backport as source because it
resolves the wrong backport order with JDK-8242141.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8226374
11u CSR:
26 matches
Mail list logo
