Resumo

  • draft-ietf-tls-trust-anchor-ids-06 propõe identificadores compactos para ajudar o servidor a selecionar uma cadeia de certificados; a lista do cliente pode ser incompleta ou inexata e não substitui a validação local.
  • Uma transição pode priorizar a cadeia nova e usar uma lista de âncoras disponíveis para uma única reconexão dirigida. O ganho de migração vem acompanhado de latência, falhas e possível exposição da população de clientes.
  • Sinal, inventário, seleção, validação, recuperação, privacidade e resultado precisam de donos e provas separados.

Toda transição de raiz produz duas realidades simultâneas. A equipe de certificados sabe que a nova cadeia está pronta. A população de clientes, porém, não atualiza confiança no mesmo instante. Tratar essas duas condições como um único estado — “a migração foi concluída” — costuma deslocar o risco para quem faz a conexão.

A revisão 06 do Internet-Draft sobre Trust Anchor IDs oferece uma maneira de negociar qual cadeia o servidor deve apresentar. Ela foi atualizada em 30 de setembro de 2026. O cabeçalho declara intenção de Standards Track, embora o registro congelado do Datatracker mantenha intended_std_level e std_level nulos. Ainda é um Internet-Draft, não um RFC, e as fontes não demonstram adoção, implantação ou interoperabilidade.

Um pedido de seleção, não uma fotografia da política

O servidor pode ter várias cadeias para a mesma identidade. A extensão certificate_authorities já informa autoridades aceitáveis, mas uma coleção de nomes distintos pode ocupar espaço demais. O rascunho cria IDs individuais curtos e IDs de grupo para reduzir esse custo.

O cliente envia uma RequestedTrustAnchorList sem ordem em ClientHello ou CertificateRequest. A lista pode estar vazia. Pode omitir âncoras realmente confiáveis, incluir âncoras que seriam rejeitadas e citar um grupo com membros mistos. O cliente pode preferir uma lista comum e parcial para reduzir tamanho ou evitar uma impressão digital precisa do seu repositório.

O servidor associa cada cadeia disponível ao ID individual da âncora emissora e aos padrões de grupo correspondentes. Ao receber a lista, procura uma interseção e escolhe um candidato. Se certificate_authorities também estiver presente, o texto permite que a satisfação de uma das extensões oriente a escolha. Sem correspondência, o servidor pode falhar ou usar um certificado alternativo.

Só depois o cliente decide se confia. Ele continua verificando a âncora efetiva, a identidade da aplicação, os prazos, algoritmos e restrições. Um metadado incorreto pode selecionar uma cadeia rejeitada. Uma lista deliberadamente imprecisa também. O fracasso preserva a fronteira: negociação não cria confiança.

A cadeia estrita não é um atalho de autorização

Quando a seleção corresponde ao ID pedido, o servidor pode incluir uma extensão trust_anchors vazia na mensagem Certificate. Esse sinal exige que a lista de certificados esteja completa, em ordem correta e sem elementos estranhos. O cliente pode tratá-la como um caminho pronto e deixar de buscar outras combinações.

RFC 4158 explica a construção de caminhos; RFC 5280, a validação. Uma cadeia pronta reduz a primeira atividade. Não elimina a segunda. Uma raiz não permitida, uma restrição de nome ou um algoritmo proibido continua produzindo rejeição.

Esse detalhe deve aparecer nos dados de produção. “Cadeia escolhida por correspondência com X” e “cadeia validada sob a política Y” são fatos diferentes. Se o observatório grava apenas qual CA foi servida, ele atribui ao servidor uma decisão que pertence ao cliente.

O mecanismo econômico da segunda conexão

O servidor pode publicar em EncryptedExtensions uma lista não vazia de IDs individuais disponíveis, ordenada por sua preferência. Se o cliente rejeitar a cadeia inicial, cruza essa lista com as âncoras que aceita, considera as preferências locais e remotas e abre nova conexão pedindo apenas um ID.

O rascunho permite no máximo uma repetição. Sem lista, sem interseção confiável ou após outra falha, a aplicação recebe erro. A reconexão também adiciona uma ida e volta. Ela é um instrumento de transição, não um recurso sem custo.

Considere uma empresa que deseja favorecer uma CA nova. O servidor coloca a nova cadeia no primeiro lugar e mantém a antiga disponível. Clientes atualizados têm sucesso de imediato. Clientes ainda dependentes da raiz antiga podem recuperar na conexão seguinte. A estratégia acelera a exposição da cadeia nova sem afirmar que a atualização chegou a todos.

Mas o operador passa a ter uma dívida mensurável. Quantos clientes repetem? Qual o aumento no p95 e p99? Que região ou versão concentra a recuperação? Por quanto tempo a cadeia antiga precisa existir? Se ninguém responder, a ponte de migração vira arquitetura permanente e a segunda conexão vira imposto silencioso.

Grupos economizam bytes e criam coordenação

Um ID de grupo representa várias âncoras. O cliente não precisa confiar em todas elas. Se o servidor selecionar um membro rejeitado, a correspondência do grupo estava correta e a validação também estará correta ao falhar.

O grupo exige um ciclo de vida: alocação, composição, versão, distribuição e retirada. Clientes e servidores precisam operar com definições compatíveis. Uma definição antiga não dá autoridade a uma raiz, mas pode gerar indisponibilidade de maneira previsível. O espaço economizado no pacote reaparece como trabalho institucional.

Também não se deve usar a cadeia escolhida pelo servidor como aprovação da CA. Ela expressa inventário, preferência e uma tentativa de coordenação. Não expressa reputação coletiva nem delegação política.

Privacidade em três modos

O texto diferencia clientes que nunca enviam IDs, enviam sob condição ou enviam sempre. O envio condicional normalmente exige uma sondagem ativa para ser observado. Uma lista incondicional pode ser capturada passivamente. Se for exclusiva de um usuário, torna-se identificador persistente.

Por isso o rascunho recomenda não enviar uma lista incondicional única e sugere um padrão compartilhado por um conjunto de anonimato. Ainda assim, uma lista derivada de conexões anteriores pode correlacionar sessões. O tamanho curto não resolve estabilidade, raridade ou histórico.

No sentido oposto, a lista de âncoras disponíveis do servidor deve ser filtrada pelo serviço solicitado e pelo contexto SNI. Uma plataforma compartilhada não deve revelar todo o seu inventário. Âncoras sensíveis não pertencem a esse canal.

A prova mínima da transição

Uma migração auditável precisa de sete registros. A política de sinal mostra IDs, grupos, condição de envio e regra de anonimato. O inventário de caminhos mostra cadeias existentes, atributos e origem dos metadados. A seleção e alternativa mostra o que casou, a preferência e a ação sem resultado.

A validação local preserva a versão do repositório, a identidade e o motivo exato. A recuperação registra a lista disponível, a única tentativa e a latência. A privacidade registra o modo de emissão, o estado anterior e o filtro por serviço. O resultado une caminho apresentado, handshake e efeito percebido pela aplicação.

Essa prova não exige um controlador universal de confiança. Ela permite que equipes diferentes comparem decisões sem entregar sua autoridade umas às outras. A transição passa a ser baseada em código executado e resultados observáveis, mantendo as escolhas futuras voluntárias.

Fontes