Resumo

  • Os três valores *_legacy do RFC 9963 existem somente para o CertificateVerify do cliente depois da oferta correspondente em CertificateRequest.
  • O cliente não os anuncia no ClientHello nem os aceita do servidor; o servidor não os aceita se não os ofereceu. Implementações deveriam deixá-los desativados por padrão.
  • Valor registrado, oferta capturada, limitação da chave e sessão autenticada são fatos diferentes. Uma assinatura válida não cria direito de aplicação.

A compatibilidade tem direção e dono

TLS 1.3 passou a exigir RSASSA-PSS em CertificateVerify. Algumas chaves de certificado cliente, protegidas por hardware antigo, não conseguem produzir a forma PSS compatível. A falha pode aparecer tarde: TLS 1.3 já foi escolhido e o servidor só então pede autenticação do cliente.

O RFC 9963 oferece uma alternativa restrita a desativar TLS 1.3 para todos ou inventar um fallback externo. Um servidor que queira atender uma chave cliente legada pode listar um dos valores no signature_algorithms de CertificateRequest. O cliente usa esse valor na sua assinatura; o servidor só pode aceitá-lo se o tiver proposto. Não há permissão recíproca: o cliente não os anuncia no ClientHello, deve rejeitá-los em CertificateVerify do servidor, e a autenticação RSA de servidor em TLS 1.3 continua exigindo PSS.

Por isso, o rótulo “RSA legado ativo” é uma perda de evidência. O registro IANA prova que o valor existe e não é recomendado. A configuração e o CertificateRequest provam uma oferta local. O inventário prova se uma chave cliente realmente não suporta PSS. A transcrição prova o que foi selecionado e verificado. Cada fato tem responsável e prazo próprios.

Há também uma fronteira de formato. RFC 9963 exige a implementação correta de RFC 8017, seção 8.2: NULL obrigatório, DER válido e rejeição de assinaturas inválidas. Uma exceção de migração não transforma uma codificação defeituosa em prova suficiente.

Fechar a ponte exige mais que contar sessões

Registrar revisão de política, identificador de chave, CertificateRequest, algoritmo selecionado, resultado, conta associada e data de remoção permite manter a ponte curta. Testar ausência de oferta, uso no servidor, DER inválido e uma chave de substituição com PSS prova que o caminho é contido e pode ser desfeito.

Depois do handshake, seguem decisões locais: qual conta recebe a identidade, que operação ela pode pedir, quem aprova a mudança e como se mede o efeito. O protocolo padroniza a prova criptográfica; não absorve essas autoridades.