EMSA-PSS (RFC 8017 §9.1) calcula el hash de M' = 0x00×8 ‖ mHash ‖ salt para obtener H, construye DB = PS ‖ 0x01 ‖ salt, lo enmascara con MGF1(H) y produce maskedDB ‖ H ‖ 0xbc, que después se eleva a una potencia como cualquier firma RSA. Los parámetros son el hash, la función de generación de máscara (MGF1 con su propio hash), la longitud de la sal y el campo final (trailer field), y el firmante y el verificador deben coincidir en todos ellos.
La longitud de la sal es el fallo de interoperabilidad clásico. En JOSE, PS256/PS384/PS512 fijan MGF1 al mismo hash y la longitud de la sal a la longitud del hash (RFC 7518 §3.5), y FIPS 186-5 §5.4(g) exige 0 ≤ sLen ≤ hLen. OpenSSL 1.1.1 y 3.0 firmaban por defecto con la sal máxima (222 bytes para RSA-2048 con SHA-256), mientras que OpenSSL 3.1 y posteriores usan por defecto auto-digestmax, que en la práctica equivale a la longitud del resumen; un verificador que fija otra longitud rechaza la firma con salt length check failed.
TLS 1.3 exige PSS siempre que RSA firma datos del handshake: rsa_pss_rsae_sha256 (0x0804) usa una clave rsaEncryption normal y rsa_pss_pss_sha256 (0x0809), una clave restringida a PSS mediante el OID id-RSASSA-PSS 1.2.840.113549.1.1.10 (RFC 4055). PKCS #1 v1.5 solo sobrevive en las firmas de los certificados. Las claves son intercambiables con PKCS #1 v1.5: pasar un despliegue de RS256 a PS256 no requiere una clave nueva, solo verificadores que acepten PSS.