Resumo

  • A revisão 06 de 30 de setembro do Internet-Draft do grupo TLS sobre identificadores de âncoras de confiança reduz de 255 para 32 bytes o comprimento máximo da forma binária de cada ID. A estrutura TLS TrustAnchorID passa a aceitar de 1 a 32 bytes. O estado no Datatracker é I-D Exists, não uma RFC publicada.
  • O novo texto exige cuidado com componentes OID que podem ser arbitrariamente grandes: uma conversão local não deve transbordar nem mudar o sentido de um ID válido. A negociação ajuda a escolher uma cadeia candidata; a política que aceita ou rejeita a CA continua com a parte que verifica.

Trocar uma raiz de certificação sem deixar clientes antigos para trás é um problema de coordenação, não apenas de criptografia. Uma ponta pode confiar na raiz nova, outra ainda requerer a antiga. O lado que apresenta o certificado precisa ter caminhos adequados e escolher qual deles enviar. O trust_anchors proposto pelo grupo TLS permite sinalizar as âncoras conhecidas por meio de IDs compactos, em vez de depender exclusivamente de listas extensas de nomes X.509. A sinalização pode melhorar a continuidade da transição, mas não instala uma raiz no dispositivo do cliente e não valida uma cadeia por ele.

O corte de tamanho é a notícia observável. Na edição de 14 de setembro, um ID binário podia ter até 255 bytes. A edição de 30 de setembro determina até 32 bytes, alterando também a declaração de TrustAnchorID de <1..2^8-1> para <1..32>. A justificativa do documento é permitir que as representações binária e decimal pontuada, tanto relativa quanto completa, permaneçam confortavelmente abaixo de 255 bytes. Seria enganoso transformar esse limite de tamanho por identificador em um limite de 32 autoridades, de 32 cadeias ou de 32 clientes.

Outra novidade está na distância entre tamanho de codificação e tamanho do número interpretado. Um componente de OID contido nos 32 bytes pode representar um inteiro enorme; padrões que agrupam âncoras também admitem valores assim. O capítulo acrescentado à revisão 06 diz que uma implementação não pode interpretar errado esses componentes ou entrar em comportamento indefinido quando um inteiro transborda. Recomenda manter as comparações e a correspondência no nível dos bytes, sem converter cada componente para um inteiro de largura fixa. É uma regra de robustez de interpretação, não prova de que algum software existente tenha falhado.

Em arquivos de configuração e diagnósticos, a forma decimal com pontos pode ser conveniente. O rascunho aceita que esses sistemas adotem limites próprios, mas exige tratamento interoperável para IDs válidos que não consigam representar. A implementação TLS deve aceitar componentes OID arbitrariamente grandes nos tipos de mensagem designados; antes de repassar um ID a outro módulo, pode descartar os não suportados. Se todos os IDs recebidos em EncryptedExtensions forem descartados, o resultado é equivalente a não receber a extensão. Isso não autoriza transformar um valor incompatível em uma permissão de confiança alternativa. Para quem estabelece limite por componente, a recomendação é suportar pelo menos até 2^32-1, abrangendo os números de empresa privados, e atribuir IDs dentro dessa faixa. O texto usa SHOULD, não uma declaração de conformidade já verificada no mercado.

Há uma correção adicional em um exemplo de grupos versionados: o extremo superior deixa de ser 2^64-1 e passa a infinito. Trata-se de uma fórmula ilustrativa, não de uma mudança demonstrada no conjunto de CAs em produção. Também importa a etapa institucional: o documento é do grupo de trabalho TLS, mas continua um Internet-Draft ativo com situação I-D Exists no IESG. O texto não revela implantação, adoção por produtos nem incidentes de segurança.

Fontes