8245686: Ed25519 and Ed448 present in handshake messages

Jamil Nimeh jamil.j.nimeh at oracle.com
Tue Jun 9 22:23:02 UTC 2020


Looks fine to me.

--Jamil

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



More information about the security-dev mailing list