O EMSA-PKCS1-v1_5 (RFC 8017 §9.2) monta 0x00 ‖ 0x01 ‖ 0xFF…0xFF ‖ 0x00 ‖ DigestInfo, com pelo menos oito bytes 0xFF, em que DigestInfo é a codificação DER do algoritmo de hash e do hash. Para SHA-256, o prefixo do DigestInfo é 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20. Não há aleatoriedade, então a mesma chave e a mesma mensagem sempre produzem a mesma assinatura.
Onde é usado: JOSE RS256, RS384 e RS512 (RFC 7518 §3.3); X.509 sha256WithRSAEncryption (1.2.840.113549.1.1.11); assinaturas do TLS 1.2; DKIM rsa-sha256; SSH rsa-sha2-256 e rsa-sha2-512. O TLS 1.3 só o permite em assinaturas dentro de certificados (rsa_pkcs1_sha256, 0x0401); as assinaturas do handshake devem usar PSS.
A armadilha conhecida está nos verificadores, não no esquema: parsers que não conferiam se o DigestInfo preenchia o resto do bloco permitiram a falsificação de Bleichenbacher de 2006 para o expoente público 3. A RFC 8017 §8.2.2 recomenda refazer a codificação do bloco esperado e comparar, e a FIPS 186-5 §5.4(h) detalha as verificações exigidas. Não confunda esse padding de assinatura com o padding de criptografia do PKCS #1 v1.5 (o problema do padding oracle) nem com o formato de arquivo de chave privada PKCS #1.