EMSA-PSS（RFC 8017 §9.1）は、M' = 0x00×8 ‖ mHash ‖ salt をハッシュして H を求め、DB = PS ‖ 0x01 ‖ salt を組み立てて MGF1(H) でマスクし、maskedDB ‖ H ‖ 0xbc を出力します。これを通常の RSA 署名と同じようにべき乗します。パラメーターはハッシュ関数、マスク生成関数（独自のハッシュ関数を持つ MGF1）、ソルト長、トレーラーフィールドで、署名者と検証者はこれらすべてについて合意していなければなりません。
ソルト長は、相互運用性の問題の典型的な原因です。JOSE の PS256/PS384/PS512 は、MGF1 のハッシュ関数を署名と同じものに、ソルト長をハッシュ長に固定しています（RFC 7518 §3.5）。FIPS 186-5 §5.4(g) は 0 ≤ sLen ≤ hLen を求めています。OpenSSL 1.1.1 と 3.0 はデフォルトで最大長のソルトを使って署名していました（SHA-256 を使う RSA-2048 では 222 バイト）。一方、OpenSSL 3.1 以降のデフォルトは auto-digestmax で、実際にはダイジェスト長と等しくなります。異なる長さに固定している検証者は、salt length check failed というエラーで署名を拒否します。
TLS 1.3 では、RSA でハンドシェイクのデータに署名する場合は常に PSS が必須です。rsa_pss_rsae_sha256（0x0804）は通常の rsaEncryption 鍵を使い、rsa_pss_pss_sha256（0x0809）は id-RSASSA-PSS の OID 1.2.840.113549.1.1.10（RFC 4055）によって PSS 専用に制限された鍵を使います。PKCS #1 v1.5 が残っているのは証明書の署名だけです。鍵は PKCS #1 v1.5 と共通なので、RS256 の運用を PS256 に切り替えるのに新しい鍵は不要で、PSS を受け付ける検証者さえあれば足ります。