Resumo

  • RFC 9963 atribui três valores *_legacy para que um servidor TLS 1.3 peça explicitamente RSASSA-PKCS1-v1_5 a um certificado de cliente incapaz de produzir uma assinatura RSASSA-PSS compatível.
  • A exceção é limitada a CertificateVerify do cliente: não vale para CertificateVerify do servidor, nem para certificados de servidor, e deveria ficar desabilitada por padrão.

RFC 9963, de David Benjamin e Andrei Popov, cuida de uma dificuldade precisa de migração. TLS 1.3 retirou RSASSA-PKCS1-v1_5 de CertificateVerify em favor de RSASSA-PSS. A RFC descreve que certos equipamentos criptográficos do lado cliente, incluindo alguns TPMs, podem não gerar uma assinatura PSS compatível. Assim, os extremos podem escolher TLS 1.3 e só encontrar a falha quando o servidor pede um certificado de cliente.

A resposta não é trazer o mecanismo antigo de volta ao uso comum. O documento define rsa_pkcs1_sha256_legacy, rsa_pkcs1_sha384_legacy e rsa_pkcs1_sha512_legacy. Esses valores existem apenas para assinaturas no CertificateVerify do cliente e não são definidos em outros contextos. Esse detalhe define a fronteira operacional: um código informa o que um extremo pode dizer numa mensagem determinada; o nome de um algoritmo não concede licença geral a cada participante TLS.

As regras de negociação mantêm a exceção delimitada. O cliente não deve anunciar esses valores na extensão signature_algorithms do ClientHello, nem aceitá-los em um CertificateVerify do servidor. Um servidor que deseja aceitar um cliente com chave exclusivamente legada pode enviá-los em CertificateRequest e aceitar um na resposta do cliente, mas não pode aceitar valor que não ofereceu. O cliente afetado pode negociar a via quando ela é oferecida. Se sua chave suporta PSS, não deveria escolher a alternativa legada, embora essa capacidade nem sempre seja prática de verificar. Implementações deveriam começar com os valores desativados.

O limite do servidor é igualmente explícito. O problema de migração descrito não se aplica às chaves de servidor. Os novos valores são proibidos em certificados de servidor e PSS continua obrigatório para servidores TLS 1.3 que usam RSA. A exceção tampouco afrouxa a implementação: RFC 8017 precisa ser seguida, com parâmetro NULL obrigatório e codificação DER válida; o servidor deve rejeitar assinaturas que não atendam a esses requisitos.

O conjunto de fontes permite uma conclusão menor e mais útil. Servidor e cliente podem negociar intencionalmente uma exceção identificada sob condições declaradas. Isso não mostra que determinado TPM, navegador, biblioteca, empresa ou servidor a tenha adotado; não certifica uma sessão nem prova um resultado geral de segurança. O perfil IETF liga David Benjamin ao RFC e seu site público oferece contexto profissional, não evidência sobre sistemas de terceiros.

O mérito do mecanismo está nessa contenção. A pressão de compatibilidade é concreta, mas a rota é explícita, direcional e revogável por padrão. Um operador pode registrar a necessidade do cliente, a oferta do servidor, o resultado negociado e o critério de saída. O código permanece uma ferramenta precisa de protocolo, e não um substituto para uma narrativa inteira de implantação.

Sources