EMSA-PSS (RFC 8017, § 9.1) хеширует M' = 0x00×8 ‖ mHash ‖ salt в H, строит DB = PS ‖ 0x01 ‖ salt, маскирует его с помощью MGF1(H) и выдаёт maskedDB ‖ H ‖ 0xbc; затем результат возводится в степень, как в любой подписи RSA. Параметры схемы — хеш-функция, функция генерации маски (MGF1 со своим хешем), длина соли и завершающее поле (trailer field); подписант и проверяющая сторона должны согласовать их все.
Длина соли — классическая причина несовместимости. В JOSE PS256/PS384/PS512 фиксируют для MGF1 тот же хеш, а длину соли приравнивают к длине хеша (RFC 7518, § 3.5); FIPS 186-5, § 5.4(g), требует 0 ≤ sLen ≤ hLen. OpenSSL 1.1.1 и 3.0 по умолчанию подписывали с максимальной длиной соли (222 байта для RSA-2048 с SHA-256), а OpenSSL 3.1 и новее по умолчанию используют auto-digestmax, что на практике равно длине дайджеста; проверяющая сторона, которая закрепила другую длину, отклоняет подпись с ошибкой salt length check failed.
TLS 1.3 требует PSS всякий раз, когда RSA подписывает данные рукопожатия: rsa_pss_rsae_sha256 (0x0804) использует обычный ключ rsaEncryption, а rsa_pss_pss_sha256 (0x0809) — ключ, ограниченный схемой PSS с помощью OID id-RSASSA-PSS 1.2.840.113549.1.1.10 (RFC 4055). PKCS #1 v1.5 сохранился только в подписях сертификатов. Ключи взаимозаменяемы с PKCS #1 v1.5: чтобы перевести развёртывание с RS256 на PS256, новый ключ не нужен — нужны только проверяющие стороны, которые принимают PSS.