8245686: Ed25519 and Ed448 present in handshake messages

[Xuelei Fan]

A simple fix like this looks good to me.  I may check this first, before 
the EC available and signature checking.

Xuelei

On 6/9/2020 3:12 PM, Anthony Scarpino wrote:
> Hi,
> 
> I need a code review of this very simple change for a situation that I'm 
> not sure is a problem in the real world.
> 
> The original TLS 1.3 putback added EdDSA to the TLS signature extensions 
> enumeration before there was an EdDSA JCE implementation or JSSE 
> support.  Without an implementation, a signature checks would not 
> include EdDSA for TLS extensions, signature_algorithms and 
> signature_algorithm_cert.  Now with JCE EdDSA support, the signature 
> check adds EdDSA to the extension, despite JSSE not having support yet 
> (JDK-8166596).  This causes a signature scheme authentication failure, 
> and JSSE moves onto the next certificate provided.
> 
> The only time this is a problem is if EdDSA is the only cert provided. 
> I'm not sure how realistic it is for one certificate to be provided.  If 
> someone knows multiple certificates are always available, I'm happy to 
> not make this change.
> 
> The fix is a simple check in the constructor to set the curves 
> unavailable after the signature check.  This code can be deleted when 
> JDK-8166596 is fixed in jdk16.  I had thought about commenting out the 
> enums, but then the logging code would not know what the id's were when 
> other clients and servers passed them to JSSE.
> 
> https://cr.openjdk.java.net/~ascarpino/8245686/webrev/
> 
> Tony