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.
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?
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
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.
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
