Resumo

  • Authorization Domain Name, ou ADN, é o nome cujo controle a autoridade certificadora comprova; ele pode ser derivado do FQDN solicitado, em vez de ser idêntico a ele.
  • SC101 descreve uma interpretação perigosa da definição anterior: remover rótulos à esquerda e depois seguir um CNAME poderia atribuir ao operador do destino uma autoridade que não alcança os subdomínios do cliente.
  • A regra nova escolhe primeiro o método de validação, restringe quais métodos podem seguir CNAME ou remover rótulos e, quando ambos são permitidos, exige CNAME antes da remoção.
  • Os TLS Baseline Requirements v2.2.9 entraram em vigor em 6 de agosto, mas permitem até 15 de novembro que a CA use a seção atual ou a seção 3.2.2.4 da v2.2.7. O recibo da emissão precisa dizer qual delas foi executada.

A versão atual contém uma bifurcação oficial

Os TLS Baseline Requirements v2.2.9 têm data de 6 de agosto de 2026. O histórico atribui a SC101 a clarificação de Authorization Domain Names; a tabela de datas relevantes marca 15 de novembro para o novo requisito de derivação.

O intervalo entre as datas não é um período de tolerância presumida. A própria seção 3.2.2.4 informa que, antes de 15 de novembro, uma CA pode obedecer à seção atual ou à seção correspondente da v2.2.7. A partir daquele dia, deve usar a seção atual.

Isso torna incompleta uma declaração aparentemente precisa. “A emissão cumpriu a versão corrente” pode significar que o sistema já implementou SC101 ou que exerceu legitimamente a alternativa anterior incorporada pela v2.2.9. A referência ao documento não revela o ramo percorrido pelo código.

O registro do ballot SC0101v2 mostra consenso entre os participantes: 27 emissores e os quatro consumidores Apple, Google, Microsoft e Mozilla votaram sim; não houve votos contrários nem abstenções. O resultado diz que os limiares foram cumpridos e registra quórum de 17. A discussão ocorreu de 12 a 19 de junho, a votação de 23 a 30 de junho e a revisão de propriedade intelectual terminou em 6 de agosto.

Esses fatos provam adoção. Não provam que todos os validadores, configurações, documentos CP/CPS, testes e nós de produção migraram na mesma hora. Consenso normativo e implantação têm identidades diferentes.

O nome validado define o limite de autoridade

Uma solicitação de certificado contém FQDNs. A CA seleciona um método aprovado e verifica o controle. O ADN é o nome sobre o qual esse método opera. Dependendo do método, a política pode permitir seguir aliases DNS ou retirar rótulos à esquerda para chegar ao ADN.

O mecanismo evita exigir provas redundantes para cada host. Mas um alias técnico não transfere a hierarquia de nomes. Quem opera o destino de tráfego ou de resolução não se torna automaticamente administrador dos subdomínios do cliente.

SC101 explica que a definição antiga misturava descrição e política, deixando dúvidas sobre a combinação e a repetição de etapas. Em uma leitura severa, a CA podia começar removendo rótulos do FQDN e depois seguir um ou mais CNAMEs.

Se example.com aponta por CNAME para example.org, o operador de example.org pode demonstrar controle do destino. Ele não recebe por isso controle sobre blog.example.com. Entretanto, retirar blog antes de seguir o alias faria o destino parecer suficiente para validar o nome do cliente. O ballot cita um operador de CDN como exemplo do terceiro que poderia controlar o destino.

A fonte não identifica uma exploração, um certificado indevido ou uma CA culpada. A análise não transforma o cenário em incidente. O problema comprovado é a ambiguidade capaz de produzir duas fronteiras de autorização.

Método, CNAME, remoção e ADN passam a ter ordem

SC101 começa pela escolha do método de validação. A escolha determina se o passo CNAME pode ser usado, se a remoção de rótulos pode ser usada, se ambos estão disponíveis ou se nenhum está. Métodos que validam em nomes técnicos com sublinhado não recebem por analogia os mesmos efeitos dos que atuam no próprio nome.

Quando as duas transformações são autorizadas e utilizadas, a CA segue a cadeia CNAME antes de retirar qualquer rótulo à esquerda. Assim, uma poda prévia não amplia a autoridade aparente do destino. O resultado vira o ADN, e o método selecionado comprova controle sobre esse ADN.

A implementação deve seguir o texto normativo integral e a tabela de métodos. O resumo não é especificação. Ele apenas torna visível o conjunto de estados que a evidência deveria guardar: entrada, método, permissões, observação CNAME, sequência de remoções, saída ADN e prova.

O processo de elaboração pode ser congelado. O ballot aponta uma comparação específica no GitHub, e a página de documentos preserva as versões atual e anteriores. As atas de 18 de junho registram a alteração de data feita na v2. Esses documentos contam como a norma nasceu, não qual caminho um validador executou.

O recibo deve conservar a derivação, não apenas o sucesso

Durante a bifurcação, um log binário de sucesso perde a informação decisiva. Um recibo mínimo associa:

hora de emissão + FQDN solicitado + método selecionado + versão/seção BR + observações e cadeia CNAME + remoções em ordem + ADN escolhido + identidade e hora da evidência + versão CP/CPS + release/configuração + referência de teste ou auditoria + exceções

O horário resolve quais opções eram permitidas. O par FQDN/ADN revela deslocamento de autoridade. O método determina transformações elegíveis. A versão separa v2.2.7 de v2.2.9. A observação DNS preserva um estado que pode desaparecer. A CP/CPS descreve a prática declarada; release e configuração descrevem o sistema que podia executá-la.

O conjunto precisa estar ligado a um identificador persistente da emissão ou certificado. Hashes podem tornar substituições detectáveis. Dados secretos de desafio não precisam ser públicos; controles de acesso e retenção continuam necessários. A meta é dar ao revisor autorizado uma reconstrução histórica, sem tratar o DNS de hoje como o DNS da emissão.

O recibo é uma proposta analítica de Daniel Kade, não uma obrigação textual inventada para o CA/Browser Forum. Os requisitos já estabelecem registros, política e auditoria. A conclusão é que uma escolha expressa entre dois algoritmos só se torna auditável quando a versão integra o registro.

CP/CPS, implantação e emissão são provas complementares

Certificate Policy e Certification Practice Statement dão efeito público às práticas da CA. O RFC 3647 fornece o quadro conhecido para esse material. Uma revisão pode anunciar data de adoção, métodos afetados e rollback.

Ela não é uma execução. A documentação pode preceder o último nó ou chegar depois do código. Um rollout gradual cria uma frota mista. Um sistema de contingência pode manter outra configuração. Uma tarefa aberta antes do prazo pode ser repetida depois. Política declarada, estado implantado e traço individual precisam ser ligados; nenhuma camada substitui as demais.

O Forum não opera os root stores

Os Baseline Requirements se definem como necessários, mas insuficientes, e condicionam a obrigatoriedade à adoção e aplicação pelos fornecedores de software das relying parties. O Forum produz o piso comum; os programas raiz decidem confiança e políticas próprias.

A Mozilla Root Store Policy incorpora requisitos comuns e mantém disposições Mozilla que podem prevalecer ou ser mais rigorosas. A Apple Root Program Policy mostra uma segunda camada de programa. Elas são usadas aqui para delimitar autoridade, não para avaliar implementação.

Ballot, CP/CPS, execução de uma emissão e decisão de root program são quatro arquivos. O rascunho já existente sobre Entrust e o poder do Google cobre o quarto. Esta pauta fica no terceiro: qual das duas derivações permitidas aceitou o nome?

Limite do que se sabe

As fontes públicas estabelecem a norma e o calendário. Não demonstram o estado de cada CA. A falta de anúncio não comprova atraso; uma menção genérica à v2.2.9 também não comprova adoção antecipada. Sem traço individual, o estado correto é “versão não demonstrada”.

Fontes