Add RSA-PSS signing support (TLS 1.3 client mutual authentication with RSA cert)

[EdouardMALOT]

Summary

This PR completes the RSA-PSS support introduced in #377 by adding the signing side: a TLS 1.3 client can now perform mutual authentication (client certificate) with an RSA certificate.

#377 added RSA-PSS verification, which lets a NetX Duo client verify the CertificateVerify sent by an RSA server. However, when the server requests a client certificate, the client must also sign its own CertificateVerify with RSA-PSS — RFC 8446 §4.4.3 forbids RSASSA-PKCS1-v1_5 in CertificateVerify. Before this PR, _nx_secure_tls_process_certificate_request() returned NX_SECURE_TLS_UNSUPPORTED_CERT_SIGN_TYPE for any RSA local certificate in TLS 1.3, making client-cert authentication impossible with RSA keys.

This implements rsa_pss_rsae_sha256 (0x0804), which is the mandatory-to-implement signature algorithm for CertificateVerify per RFC 8446 §9.1. Related: #161.

Changes

• crypto_libraries/inc/nx_crypto_rsa.h — declare _nx_crypto_rsa_pss_sign()
• crypto_libraries/src/nx_crypto_rsa.c — implement _nx_crypto_rsa_pss_sign(): EMSA-PSS-ENCODE (RFC 8017 §9.1.1), salt length == hash length as required by RFC 8446 §4.2.3, salt generated via NX_CRYPTO_RAND() (same entropy source as the ECDSA nonce path). The RSA private-key operation is then applied to the encoded message by the existing signing flow.
• nx_secure/src/nx_secure_tls_process_certificate_request.c — TLS 1.3: instead of rejecting RSA local certificates, select rsa_pss_rsae_sha256 and proceed with the client Certificate/CertificateVerify flow
• nx_secure/src/nx_secure_tls_send_certificate_verify.c — TLS 1.3: build the CertificateVerify message with the SignatureScheme wire code (rsa_pss_rsae_sha256/384/512 handled) and the PSS-encoded message, instead of PKCS#1 v1.5 padding (which remains used for TLS 1.2)

Notes / limitations

• When answering a CertificateRequest, the client currently selects rsa_pss_rsae_sha256 unconditionally (the RFC 8446 §9.1 MUST algorithm, supported by any compliant server). The CertificateVerify encoding path itself also supports rsa_pss_rsae_sha384/512 should the selection be extended later.
• rsa_pss_pss_* variants (RSASSA-PSS certificates, 0x0809–0x080b) are out of scope; this covers the common case of classic RSA certificates (rsae).

Test plan

• TLS 1.3 mutual authentication handshake (server requests a client certificate) completes with an RSA client certificate, rsa_pss_rsae_sha256 CertificateVerify accepted by the server (tested against a Mosquitto/OpenSSL broker requiring client certificates)
• TLS 1.3 server-only handshake (no CertificateRequest) unaffected
• TLS 1.2 client certificate path still uses RSASSA-PKCS1-v1_5 (unchanged behavior)

[EdouardMALOT]

@fdesbiens : the remaining Secure_Interoperability / run_tests failure is unrelated to this change — the job fails during the "Install softwares" step.

[fdesbiens]

Thank you for this PR, @EdouardMALOT, and for all the others you submitted.

I am currently on vacation; I will review them once I am back, the week of July 20.

[fdesbiens]

@fdesbiens : the remaining Secure_Interoperability / run_tests failure is unrelated to this change — the job fails during the "Install softwares" step.

This is expected. The script relies on ifconfig to tweak networking configuration, and this should be modernised. I will spend some time fixing this along with the reviews.