EMSA-PKCS1-v1_5 (RFC 8017 §9.2) construye 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo, con al menos ocho bytes 0xFF, donde DigestInfo es la codificación DER del algoritmo de hash y del hash. Para SHA-256, el prefijo DigestInfo es 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. No hay aleatoriedad, así que la misma clave y el mismo mensaje dan siempre la misma firma.
Dónde se usa: JOSE RS256, RS384 y RS512 (RFC 7518 §3.3); X.509 sha256WithRSAEncryption (1.2.840.113549.1.1.11); firmas de TLS 1.2; DKIM rsa-sha256; SSH rsa-sha2-256 y rsa-sha2-512. TLS 1.3 solo lo permite para las firmas dentro de los certificados (rsa_pkcs1_sha256, 0x0401); las firmas del handshake deben usar PSS.
El problema conocido está en los verificadores, no en el esquema: los analizadores que no comprobaban que el DigestInfo ocupara el resto del bloque permitieron la falsificación de Bleichenbacher de 2006 con exponente público 3. El RFC 8017 §8.2.2 recomienda volver a codificar el bloque esperado y comparar, y FIPS 186-5 §5.4(h) detalla las comprobaciones necesarias. No confundas este relleno de firma con el relleno de cifrado de PKCS #1 v1.5 (el problema del oráculo de relleno) ni con el formato de archivo de clave privada PKCS #1.