EMSA-PKCS1-v1_5（RFC 8017 §9.2）构造 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo，其中至少有 8 个 0xFF 字节，DigestInfo 是哈希算法和哈希值的 DER 编码。对于 SHA-256，DigestInfo 前缀为 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20。整个过程不含随机性，因此同一密钥和同一消息总是得到相同的签名。
使用场景：JOSE 的 RS256、RS384 和 RS512（RFC 7518 §3.3）；X.509 的 sha256WithRSAEncryption（1.2.840.113549.1.1.11）；TLS 1.2 签名；DKIM 的 rsa-sha256；SSH 的 rsa-sha2-256 和 rsa-sha2-512。TLS 1.3 只允许在证书内部的签名中使用它（rsa_pkcs1_sha256，0x0401）；握手签名必须使用 PSS。
已知的陷阱出在验证器上，而不在方案本身：解析器如果不检查 DigestInfo 是否填满了块的其余部分，就会让 Bleichenbacher 于2006年提出的、针对公钥指数为 3 的伪造攻击得逞。RFC 8017 §8.2.2 建议重新编码预期的块后再比较，FIPS 186-5 §5.4(h) 则详细列出了必需的检查。不要把这种签名填充与 PKCS #1 v1.5 加密填充（填充预言机问题）或 PKCS #1 私钥文件格式混为一谈。