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