Resumo

  • A pull request 679 propõe incluir ML-DSA-44, ML-DSA-65 e ML-DSA-87 nos TLS Baseline Requirements para chaves e assinaturas de certificados, CRLs e respostas OCSP.
  • O preâmbulo nomeia clientes baseados em SDK, sistemas embarcados e IoT, middleware e aplicações que validam contra trust stores do sistema. Também afirma que a mudança não obrigaria um root store a confiar em ML-DSA nem alteraria a assinatura dos SCTs.
  • A carta do SCWG abrange certificados TLS de servidores acessíveis pela Internet. Porém, o Certificate Consumer com voto precisa produzir software destinado ao público para navegar a Web com segurança; a qualificação do emissor também depende da aceitação por esse navegador.
  • A exclusão expressa de PKI exclusivamente interna é mais estreita do que “todo uso não navegador”. O texto público deixa uma fronteira interpretativa, não uma resposta automática.
  • Em 2 de setembro de 2026, a SC-106 era uma PR aberta e marcada Draft, ausente da página oficial de ballots. Comentários e atas registram posições, não consenso ou decisão.
  • Um recibo de mandato deve identificar público, cláusula, representação, invariante, limites de root store e CT, evidência de implementação, foro alternativo e gatilho de revisão.

A demanda foi descrita com mais amplitude que a classe de voto

O argumento de necessidade da SC-106 é incomumente concreto. Em vez de falar apenas em “ecossistema”, a PR aponta relying parties que hoje não teriam caminho prático para autenticação pós-quântica na infraestrutura X.509 de confiança pública: clientes de serviço construídos com SDK, aparelhos embarcados e IoT, middleware empresarial e aplicações que dependem de trust stores gerenciados por fornecedores de sistema operacional.

Esses programas podem validar certificados de servidor sem serem navegadores. A carta do Server Certificate Working Group, contudo, define o membro votante da classe consumidora por um produto usado pelo público para navegar a Web com segurança. O membro emissor deve operar uma CA cujos certificados sejam considerados válidos por um navegador produzido por um desses consumidores.

Isso não reduz a experiência técnica de quem está na sala. Uma empresa pode manter navegador, sistema operacional e bibliotecas. Uma CA pode atender dispositivos e aplicações. Mas presença e conhecimento não são delegação. A distinção de Lu Heng entre stakeholder e principal impede que utilidade seja silenciosamente convertida em representação.

O registro precisa dizer qual afirmação está sendo feita. Trata-se de um mínimo para a Web que também serve a outros clientes? De uma atividade ancillary autorizada pela carta? Ou de um perfil de confiança pública para uma população mais ampla que não coincide com a classe consumidora votante? O mesmo diff técnico ganha significados institucionais diferentes em cada hipótese.

O commit congela um perfil, não uma confiança

O head eefc670… acrescenta os três parameter sets de FIPS 204, exige validação de encoding, define Key Usage para Subscriber Certificates e fixa os AlgorithmIdentifiers. Os parâmetros devem ficar ausentes. HashML-DSA não seria permitido.

O texto vincula chave e assinatura nos dois sentidos. Uma chave pública ML-DSA só pode ser certificada por assinatura ML-DSA. Uma assinatura ML-DSA em certificado ou precertificado só pode certificar chave ML-DSA. CRL e OCSP ficam fora da segunda proibição porque não certificam chave pública.

Ao mesmo tempo, o preâmbulo limita a autoridade da mudança. A aprovação não obrigaria qualquer operador de root store a admitir a hierarquia. O algoritmo usado pelo log para assinar SCT continuaria sob controle do operador de Certificate Transparency. Assim, conformidade de encoding, trust, transparência e validação não são um único estado.

Essa separação é correta, mas pede uma descrição do bloqueio. Para qual classe a ausência do perfil é realmente o obstáculo? Uma CA não consegue emitir sob auditoria? O root program não aceita a chave? A biblioteca não constrói o caminho? O trust store não distribui a raiz? A aplicação não negocia a credencial? As fontes não trazem inventário, população ou teste que una todos esses problemas.

Draft continua sendo Draft

O número SC-106 aparece no título da PR, e o preâmbulo usa “ballot” para descrever o objetivo. No corte da pesquisa, a interface pública mostrava Open e Draft, um commit e nenhuma review formal. A página de ballots do SCWG não continha SC-106 em Voting, IPR Review, Discussion, Draft / Under Consideration ou no histórico.

O estado atribuível é, portanto, “draft pull request”. Não há evidência pública de proponentes e endorsers formais, janela de discussão, votação, resultado, revisão IPR, Final Maintenance Guideline ou data efetiva.

A sequência importa porque cada etapa pertence a um decisor. Um autor propõe; o Working Group admite uma versão no processo; as duas classes votam; o IPR examina exclusões; o texto final entra em vigor; root programs, CAs, logs e clientes adotam ou delimitam. Chamar o primeiro arquivo de ballot efetivo faz a proposta herdar autoridade que ainda não recebeu.

O diff imutável serve para o oposto: manter a versão inicial reconhecível mesmo se a discussão a substituir.

A carta é ampla no objeto e estreita na qualificação

A seção de escopo permite ao SCWG definir requisitos e práticas para emissão e gestão de certificados TLS usados na autenticação de servidores acessíveis pela Internet. Também permite atualizações contra ameaças emergentes e atividades auxiliares. Não é uma frase limitada a uma implementação específica de navegador.

As regras de membership, porém, dizem de onde vem a decisão. O consumidor votante é qualificado pela navegação Web. O emissor votante é qualificado pela aceitação em navegador. A superfície técnica dos certificados é maior que o eleitorado institucional nomeado.

O out-of-scope ajuda sem encerrar o tema. Ele exclui uma PKI empresarial usada apenas internamente quando a raiz não é distribuída por qualquer Certificate Consumer, além de usos como code signing e S/MIME. Não afirma que todo cliente fora da Web esteja excluído. Também não transforma qualquer uso de TLS em representação pelo navegador.

A conclusão rigorosa preserva a ambiguidade: existe uma pergunta de interpretação. Se “servidor acessível pela Internet” ou “ancillary” é a base, o Working Group deve nomear a cláusula, o responsável pela interpretação e o limite. Uma regra de certificado não deveria decidir a constituição por consequência.

O debate de Tóquio já havia separado as duas leituras

As atas do F2F 64, em março de 2025, dedicam uma seção à delimitação dos TLS BR. Participantes discutiram navegador versus não navegador, trust stores de sistemas operacionais, aplicações server-to-server, PKI privada, agilidade e um eventual novo grupo de trabalho.

Uma corrente entendia que as políticas dos root programs de navegadores são a realidade operacional dos BR e que usos menos ágeis não deveriam restringir a evolução da Web. Outra observava que sistemas e aplicações usam as mesmas raízes, não têm alternativa equivalente e podem sofrer fragmentação se os requisitos se tornarem estritamente browser-specific.

As atas conservaram as duas perspectivas. Não registraram emenda de carta nem resolução. O valor probatório está em mostrar que o problema antecede a SC-106.

Os comentários de agosto de 2026 repetem a divisão. Um participante chamou o foco de non WebPKI. Ben Wilson sustentou que a assurance depende do caminho construído e aceito pelo relying party. Um participante de Chrome separou os dois sentidos de cadeia mista, questionou o alinhamento com a carta e sugeriu outro WG no Forum.

São argumentos públicos e atribuídos. Não são a posição do SCWG, e reações no GitHub não são votos.

A pureza da cadeia tem proprietários diferentes

O racional do Draft diz que um elo clássico limita a assurance daquele caminho ao nível clássico. Isso não decide se todo arranjo misto deve ser proibido no perfil. Um cliente pode aceitar um caminho completamente pós-quântico e rejeitar a alternativa clássica; a existência desta não altera criptograficamente o caminho aceito.

O RFC 5280 coloca o prospective path e a informação do trust anchor entre as entradas da validação. A seleção da âncora é matéria de política, e caminhos diferentes podem começar em âncoras diferentes. O BR controla a emissão da CA. O relying party e seu root policy controlam o caminho aceito.

Ainda pode haver motivo para uma proibição comum. Uma CA clássica assinando uma chave de assinante PQ expõe logs existentes a certificados maiores e mantém a autoridade no elo clássico. Uma CA PQ assinando temporariamente uma chave clássica pode ter função de transição e anti-downgrade. Tratar os dois sentidos como uma propriedade única apaga riscos diferentes.

O invariante deve ser nomeado: capacidade de CT para a Web, integridade do rótulo de um caminho PQ, sinalização de raiz, compatibilidade legada ou migração fora da Web. Um perfil comum só deve incorporar a parte que precisa ser comum.

Implementação real permite vários conjuntos

O roadmap do Chromium organiza uma transição Web em etapas: opções PQ, credenciais pareadas, proteção contra downgrade e, em horizonte remoto, remoção das opções clássicas. Para a Web pública, Chrome trabalha com Merkle Tree Certificates, não com confiança imediata em certificados X.509 ML-DSA tradicionais.

O programa de teste faz distinções adicionais. A partir do Chrome 150, certificados ML-DSA tradicionais podem ser usados em hierarquias privadas. Para MTC existe um root store de teste separado, habilitado de modo explícito e com cosigners classificados como não confiáveis para produção. Logs, mirroring e algoritmos têm regras próprias.

Isso não faz do plano do Chrome a resposta do IoT. Demonstra que teste, PKI privada e política pública podem avançar em compatibility sets separados.

FIPS 204 define o algoritmo. Um perfil define encoding e emissão. O root program define confiança. CT define admissão e transparência. A biblioteca define path building. A execução comprova resultado. A disciplina de especificação mínima de Lu Heng é útil exatamente para impedir que um desses atos fale em nome dos demais.

Um recibo curto para uma pergunta constitucional

O primeiro bloco deve registrar base, commit, status, proposer, endorsers, discussão, votação, votos por classe, IPR, versão final e data. O segundo separa navegadores, validadores do sistema, SDKs, embarcados, IoT, middleware, PKI privada e serviços públicos.

Para cada classe, o recibo cita a cláusula aplicável, quem pode interpretá-la, quem vota, quem participa sem voto e quem não possui canal formal. Não ter voto não concede veto; apenas impede afirmar representação plena.

O bloco técnico põe em linhas distintas encoding, path assurance, downgrade, capacidade CT e root admission. Cada linha contém invariante, decision owner, evidência, incerteza e opção local. O bloco de implementação lista vetores, biblioteca e versão, tamanho, caminho, piloto e falha.

Por fim, compara-se o foro: avançar no SCWG com interpretação publicada; esclarecer ou mudar a carta; criar WG para consumidores não navegador; ou manter pilotos específicos de raiz. Uma data de revisão e uma saída tornam reversível a restrição de transição.

O que não está provado

Não há ballot adotado, guideline vigente, compromisso de root store, resultado de CT ou interpretação coletiva da carta. Não há censo das aplicações nomeadas. Não se provou que todo mixed path é seguro ou inseguro, nem que o perfil atual bloqueia uma implantação específica.

Também não há base para dizer que a proposta é ilegítima ou desnecessária. O estado correto é uma necessidade alegada e tecnicamente detalhada, diante de uma fronteira institucional ainda sem recibo.

Agora é o momento barato para corrigir isso. Depois que auditorias, procurement e tooling tratarem o texto como “industry standard”, a dependência criada poderá ser usada para legitimar retroativamente o local onde a regra nasceu.

Clareza de mandato fortalece o profile

O SCWG pode decidir que sua competência sobre servidores Internet basta e publicar essa leitura. Pode reconhecer que clientes de sistema e dispositivos precisam de outro grupo. Pode deixar root programs testar até que um invariante comum seja medido.

Nenhuma dessas opções rejeita ML-DSA. Todas preservam a diferença entre utilidade e autoridade.

A SC-106 já distingue permissão do Forum, confiança da raiz e assinatura do SCT. O próximo passo é distinguir beneficiário e eleitor. Só então o profile terá exatamente o peso da decisão que o criou.

Fontes

  1. Lu Heng, “The Multi-Stakeholder Mirage”
  2. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  3. CA/Browser Forum, pull request 679 — SC-106
  4. Comparação imutável da SC-106
  5. TLS Baseline Requirements propostos
  6. Carta do Server Certificate Working Group
  7. Atas do F2F 64 do SCWG
  8. Bylaws do CA/Browser Forum
  9. Página de ballots do SCWG
  10. NIST FIPS 204
  11. RFC 5280, seção 6
  12. Chromium, roadmap de autenticação HTTPS pós-quântica
  13. Instruções de teste do Chrome Quantum-resistant Root Program