Hi Xuelei, thanks for the comments. I'll respond in-line:
On 10/21/2020 11:52 AM, Xuelei Fan wrote:
Hi Jamil,
Sorry for delay. It took a few days before I was able to read the
CSR. Just a few comments for your consideration.
In the specification section, you mentioned how to disable the
algorithms. It might not be necessary. It is just something we need
to implement so that it does not break the mechanism.
JN: I was under the impression that where System/Security properties
have an impact on the feature that we typically make note of it.
I'm not very sure of the order of EdDSA in the signature algorithms.
EdDSA and EdDSA certificate are not popular yet. I'm fine with the
order. Would you mind to share your consideration of the preference?
No real consideration. All I did was remove the explicit disable code
in SignatureScheme.java:278 - 286. The ordering in the enumeration then
shows up in the signature_algorithms[_cert] extensions. Ed* schemes
could be moved down a bit in the enumeration if we think that will make
a difference. I think it would only matter if a server or client had
both ECC and EdDSA keyed certs that would be up for selection. There
are other implementations that do have Ed* signature schemes a little
further down in their lists.
The list of signature schemes is out of the quote box and hard to
read. I may just list one scheme one line in one quote box, like:
+ ed25519
+ ed448
ecdsa_secp256r1_sha256
JN: I could do that. I was trying to avoid having it be a mile long,
but if it's not rendering horizontally then I'll change it. I suppose
it doesn't have to be the list of all sig schemes. Just a few lines of
context on either side of the new signature schemes should drive the
point home and keep it succinct.
I'm not very sure why EdDSA cannot apply to ServerKeyExchange and
CertificateVerify in TLS 1.0 and 1.1. ServerKeyExchange and
CertificateVerify is used to authenticate the server or the client's
possession of the private key of the cert. So if EdDSA cannot be used
for them, the EdDSA certificate should not be selected for TLS 1.0/1.1
as well. I did not read the RFC fully yet, it looks like that EdDSA
can be used for TLS 1.0/1.1 ServerKeyExchange and CertificateVerify as
well. I may miss something.
JN: So far I have yet to find a server implementation that will accept a
1.0/1.1 client hello with no signature_algorithms extension and not
barf. This of course assumes that the server only has EdDSA keyed TLS
certificates. As I mentioned to you on the side, if it's RSA/DSA/ECC
and has an EdDSA signature, then things work great. To be fair, I
haven't experimented with anything other than my modified JSSE and
OpenSSL so far.
Hope it helps.
Xuelei
On 10/13/2020 10:59 AM, Jamil Nimeh wrote:
Hi Folks,
I just put out the draft CSR for the RFE that adds EdDSA support in
JSSE. If anyone has some spare cycles to review this I'd appreciate it.
https://bugs.openjdk.java.net/browse/JDK-8254709
Thanks,
--Jamil
