Supporting RSA signed client certificates with TLS 1.3

[jkuwaha]

Is your feature request related to a problem? Please describe.
With TLS 1.3, TLS session cannot be established with clients using RSA signed certificates.

Describe the solution you'd like
It would be good if NetX supports RSA signed client certificates with TLS 1.3.

[TiejunZhou-CN]

@jkuwaha , thanks for opening this feature request. This feature is in our backlog. It is not prioritized at the moment.

[jkuwaha]

@TiejunMS,
Thank you for the information.
We look forward to being supported (hopefully within a year).

[GKNSTM]

Hello. Any news on this feature request ? we would be very interested to have this RSA certificate support in TLS 1.3 in Netxduo.

[jespertragardh]

Mostly for making this more visible in search engines.

To my understanding, this applies to both client and server certificates.

The technical problem is that for RSA, NetX Duo supports only the RSA signature algorithms (as can be seen in the ClientHello message for a TLS 1.3 connection):

• rsa_pkcs1_sha256 (0x0401)
• rsa_pkcs1_sha384 (0x0501)
• rsa_pkcs1_sha512 (0x0601)

But these are RSASSA-PKCS1-v1_5 algorithms and according to RFC 8446 sect. 4.4.3 these may not be used for the CertificateVerify protocol message (send by server or client) regardless of how the certificate chain is signed. CertificateVerify must use RSASSA-PSS algorithms, one of:

• rsa_pss_pss_sha256(0x0809),
• rsa_pss_pss_sha384(0x080a),
• rsa_pss_pss_sha512(0x080b),

and until they are implemented, you cannot use RSA certificates with TLS 1.3 in NetX Duo.
You can you use ECC certificates so that CertificateVerify can be signed with ecdsa_secp256r1_sha256 and such a certificate can be signed with a RSA-based certificate (e.g. from the CA or its intermediates) because validation of the certificate chain is a different matter from verifying the signature of the CertificateVerify protocol message.

Formally, NetX Duo is not compliant with TLS 1.3 since RFC 8446 sect. 9.1 says:

9.1. Mandatory-to-Implement Cipher Suites

In the absence of an application profile standard specifying
otherwise:

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256
GCM cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384
GCM and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see
Appendix B.4).

A TLS-compliant application MUST support digital signatures with
rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for
CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A
TLS-compliant application MUST support key exchange with secp256r1
(NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].

Although a user of NetX Duo can of course use it in an application where a profile has been defined to waive these requirements.

[EdouardMALOT]

@jespertragardh Good summary. This is being addressed:

#377 (merged) — RSA-PSS verification: a TLS 1.3 client can now verify the server's CertificateVerify signed with rsa_pss_rsae_sha256/384/512, so RSA server certificates work.
#399 (open) — RSA-PSS signing: the client can sign its own CertificateVerify, enabling TLS 1.3 mutual authentication (client certificate) with an RSA key. Tested against a Mosquitto/OpenSSL broker.
Note: these implement the rsa_pss_rsae_* schemes (classic RSA certificates), including the mandatory-to-implement rsa_pss_rsae_sha256 from RFC 8446 §9.1. The rsa_pss_pss_* variants remain out of scope for now.