RFR CSR: JDK-8254709 (Support for EdDSA signature scheme in JSSE)

[Jamil Nimeh]

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