O EMSA-PSS (RFC 8017 §9.1) calcula o hash de M' = 0x00×8 ‖ mHash ‖ salt para obter H, monta DB = PS ‖ 0x01 ‖ salt, mascara esse bloco com MGF1(H) e produz maskedDB ‖ H ‖ 0xbc, que depois é exponenciado como qualquer assinatura RSA. Os parâmetros são o hash, a função de geração de máscara (MGF1, com seu próprio hash), o comprimento do salt e o campo trailer, e o signatário e o verificador precisam concordar em todos eles.
O comprimento do salt é a falha clássica de interoperabilidade. Os PS256/PS384/PS512 do JOSE fixam a MGF1 no mesmo hash e o comprimento do salt no comprimento do hash (RFC 7518 §3.5), e o FIPS 186-5 §5.4(g) exige 0 ≤ sLen ≤ hLen. O OpenSSL 1.1.1 e o 3.0 assinavam por padrão com o salt máximo (222 bytes para RSA-2048 com SHA-256), enquanto o OpenSSL 3.1 e posteriores usam por padrão auto-digestmax, que na prática equivale ao comprimento do digest; um verificador que fixa outro comprimento rejeita a assinatura com salt length check failed.
O TLS 1.3 exige PSS sempre que o RSA assina dados do handshake: rsa_pss_rsae_sha256 (0x0804) usa uma chave rsaEncryption comum, e rsa_pss_pss_sha256 (0x0809), uma chave restrita ao PSS pelo OID id-RSASSA-PSS 1.2.840.113549.1.1.10 (RFC 4055). O PKCS #1 v1.5 sobrevive apenas nas assinaturas de certificados. As chaves são intercambiáveis com as do PKCS #1 v1.5: migrar uma implantação RS256 para PS256 não exige chave nova, apenas verificadores que aceitem PSS.