EMSA-PSS (RFC 8017 §9.1) hache M' = 0x00×8 ‖ mHash ‖ salt pour obtenir H, construit DB = PS ‖ 0x01 ‖ salt, le masque avec MGF1(H) et produit maskedDB ‖ H ‖ 0xbc, qui subit ensuite l’exponentiation comme n’importe quelle signature RSA. Les paramètres sont la fonction de hachage, la fonction de génération de masque (MGF1, avec sa propre fonction de hachage), la longueur du sel et le champ de fin (trailer field), et le signataire comme le vérificateur doivent s’accorder sur chacun d’eux.
La longueur du sel est la cause classique des échecs d’interopérabilité. Les algorithmes JOSE PS256/PS384/PS512 fixent pour MGF1 la même fonction de hachage et une longueur de sel égale à la longueur du condensat (RFC 7518 §3.5), et la FIPS 186-5 §5.4(g) exige 0 ≤ sLen ≤ hLen. OpenSSL 1.1.1 et 3.0 signaient par défaut avec le sel maximal (222 octets pour RSA-2048 avec SHA-256), tandis qu’OpenSSL 3.1 et versions ultérieures utilisent par défaut auto-digestmax, ce qui équivaut en pratique à la longueur du condensat ; un vérificateur qui impose une autre longueur rejette la signature avec salt length check failed.
TLS 1.3 exige PSS chaque fois que RSA signe des données du handshake : rsa_pss_rsae_sha256 (0x0804) utilise une clé rsaEncryption ordinaire, et rsa_pss_pss_sha256 (0x0809) une clé restreinte à PSS par l’OID id-RSASSA-PSS 1.2.840.113549.1.1.10 (RFC 4055). PKCS #1 v1.5 ne subsiste que dans les signatures de certificats. Les clés sont interchangeables avec PKCS #1 v1.5 : passer un déploiement RS256 à PS256 ne demande aucune nouvelle clé, seulement des vérificateurs qui acceptent PSS.