Resumo

  • O SC100 recebeu votos favoráveis de 22 emissores e três consumidores de certificados participantes, sem votos contrários nem abstenções. Em 31 de agosto de 2026, porém, a revisão de propriedade intelectual continuava aberta até 5 de setembro, 19h UTC.
  • O rascunho consolida deveres existentes. A Perspectiva de Rede Primária precisa validar DNSSEC nas consultas aplicáveis de controle de domínio e CAA; nas Perspectivas Remotas, essa validação é permitida, não obrigatória.
  • MPIC e DNSSEC não são controles equivalentes. O MPIC reúne observações independentes para corroborar a determinação primária; o DNSSEC classifica criptograficamente os dados vistos por um resolvedor.
  • Como o texto exclui o conjunto completo das consultas DNS de dois escopos de registro e autoauditoria, mas exige informação suficiente, a evidência mínima deve juntar um recibo temporal de controle do resolvedor a um recibo de emissão que nomeie a perspectiva primária.

A aprovação em votação ainda não é a publicação final

A página do SC100 registra 22 votos sim entre emissores. Apple, Cisco Systems e Mozilla deram os três votos sim entre consumidores. Não houve voto não nem abstenção; o quórum de 15 foi atingido.

A mesma página abre outra etapa. A revisão IPR começou em 6 de agosto, às 19h UTC, e deve terminar em 5 de setembro no mesmo horário. Até lá, participantes podem apresentar avisos para excluir reivindicações essenciais. A ata de 13 de agosto descreveu o SC100 como recém-ingressado nessa revisão.

O cabeçalho pode induzir uma leitura errada. A versão aceita do rascunho diz 2.2.9 e traz a data de 6 de agosto. As TLS Baseline Requirements em vigor também são 2.2.9, com a mesma data. Mas a tabela de revisões da publicação corrente termina no SC101; o SC100 não aparece. O índice de documentos identifica as edições publicadas, enquanto o anexo do SC100 mantém a marca DRAFT.

Por isso, um registro que informe apenas “2.2.9” não identifica sua autoridade normativa. É preciso guardar a condição do documento: Final Guideline corrente, Draft Maintenance Guideline em revisão ou eventual versão futura que incorpore o texto.

A própria cédula limita a narrativa. O SC100 não tem data de vigência porque se propõe a esclarecer e consolidar, sem modificar os requisitos. Este artigo não anuncia uma obrigação nova. Ele pergunta como tornar verificável uma obrigação cujo papel executor fica mais nítido.

O MUST tem endereço operacional

O dever nasceu no SC085v2 e passou a valer em 15 de março de 2026. Quando existe uma cadeia DNSSEC, as consultas pertinentes à validação de controle do domínio e à CAA feitas pela perspectiva primária precisam ser validadas. A versão corrente conserva a regra em trechos separados.

O rascunho aceito do SC100 reúne o material no §4.2.2.2 proposto. O resolvedor usado pela Perspectiva Primária deve executar o algoritmo do RFC 4035 §5, suportar NSEC3 e SHA-2 e tratar as questões de segurança do RFC 6840 §4.

Depois vem a alocação por papel. A Primária deve validar DNSSEC em todas as consultas relacionadas à autorização ou controle de domínio e ao processamento CAA. Os métodos restantes baseados em e-mail têm exceção parcial: CNAME, CAA e TXT usados para chegar ao Authorization Domain Name continuam obrigatórios; outras consultas recebem SHOULD. Para os demais métodos e CAA, política local não pode desligar a validação. Um erro observado na Primária, como SERVFAIL, não pode virar permissão de emitir, respeitado o limite da exceção.

Nas Remotas, o verbo é MAY. Elas podem validar até a âncora raiz da IANA dentro do MPIC. A opção não é proibição nem obrigação. Uma remota que não a executa não deve ser rotulada como protocolarmente Insecure; uma remota que a executa não prova sozinha a cadeia inteira de emissão.

O ponto decisivo é que dnssec=secure não contém seu próprio sujeito. O estado pode ter vindo da Primária, de uma Remota, de um ensaio ou de uma ferramenta de diagnóstico. Sem o papel, o serviço, o tempo e a consulta, não se demonstra o ato exigido.

O MPIC observa de vários lugares; o DNSSEC autentica o que um resolvedor viu

O SC067v3 introduziu a Corroboração de Emissão em Múltiplas Perspectivas para dificultar ataques BGP de prefixo igualmente específico contra validação de domínio. Para os métodos aplicáveis, perspectivas remotas corroboram a determinação da Primária antes da emissão.

O DNSSEC responde outra pergunta. Ele permite que o resolvedor classifique criptograficamente dados e provas de inexistência. O RFC 4035 usa estados como Secure, Insecure, Bogus e Indeterminate. Esses estados não informam a distância entre observadores, sua região, participação no quórum nem a decisão final da CA.

Desde 15 de junho de 2026, a etapa reproduzida no rascunho SC100 pede pelo menos quatro Perspectivas Remotas, o quórum da tabela e corroboradores em ao menos duas regiões de serviço RIR. Em 15 de dezembro, o mínimo sobe para cinco. Trata-se de quantidade de observadores remotos, não de quantidade de validadores DNSSEC sob obrigação.

O modelo precisa manter duas colunas. Para cada remota: ela corroborou ou não? Ela executou DNSSEC ou não, dentro da opção permitida? Se executou, qual foi o estado do seu próprio resolvedor? Um quórum MPIC bem-sucedido não pode ser convertido em “DNSSEC validado por todos”. E a ausência do MUST remoto não invalida a diversidade de observação que o MPIC entrega.

A suficiência foi escolhida em vez de um formato único

O SC096 retirou a verificação DNSSEC da obrigação ampla de registro de DCV e CAA. A justificativa disse que resolvedores não são construídos para log extensivo e indicou os registros de gestão de mudança como forma de demonstrar controles ativos.

O §4.2.2.2.7 proposto pelo SC100 mantém uma exclusão: o conjunto completo das informações de busca DNS ligadas ao DNSSEC ficaria fora da autoauditoria do §8.7 e dos logs do §5.4.1. Na frase seguinte, porém, exige que a CA retenha informação suficiente para verificar conformidade com o restante da seção.

A ata de 16 de julho mostra que o texto é deliberado. A questão remanescente era prescrever ou não uma implementação específica de log. A solução foi exigir evidência suficiente e manter liberdade sobre como conservá-la. A discussão recomeçou após a revisão; a ata de 30 de julho registrou que não houve novo comentário antes do voto.

Essa escolha protege arquiteturas distintas. Ao mesmo tempo, obriga cada CA a definir uma prova mínima. Uma captura de configuração sem vínculo com tentativa não basta. Guardar todo pacote DNS não é o padrão implícito. O objeto útil é um par de recibos com uma chave comum.

A capacidade e a execução precisam de recibos diferentes

O recibo de controle descreve a capacidade aprovada da Primária em um intervalo:

ID do controle + ID da Primária + ID do resolvedor/serviço + software/build + hash de configuração/política + versão das âncoras + capacidades RFC 4035/NSEC3/SHA-2/RFC 6840 + exceção local + testes + mudança aprovada + válido de/até

Configurações e segredos podem permanecer em armazenamento controlado, ligados por hash. O recibo comprova que certo controle existia e foi testado naquele período. Ele não comprova que toda solicitação usou o controle.

O recibo de emissão liga a tentativa ao controle:

ID da tentativa + certificado/pré-certificado + horários + nome/escopo + método DCV + escopo CAA + versão normativa + ID da Primária + ID do resolvedor/controle + famílias de consultas + estado DNSSEC + erro e decisão de fechamento + IDs Remotos + indicador DNSSEC e estado por Remota + regiões RIR + observações/quórum MPIC + linhagem de repetição + hash imutável

Quando uma Remota não executa a opção, a informação correta é “não executado, permitido”. Não é Insecure. Quando executa, o resultado pertence ao resolvedor daquela Remota. Copiar o estado Primário para todas as linhas destruiria a independência que a tabela pretende representar.

O par é uma proposta analítica de Daniel Kade, não uma lista escondida no SC100. Não é atribuído à DigiCert, aos endossantes, aos votantes, a um navegador, a auditor ou ao RFC. A norma deixa a implementação aberta; esta é uma forma de tornar “suficiente” testável sem exigir a consulta completa.

O elo, e não a quantidade de documentos, é a prova

A CP/CPS declara prática. Uma versão de software identifica uma implementação. Um teste demonstra um caso. Secure classifica uma observação. Um certificado registra que houve emissão. Um quórum MPIC mostra corroboradores. Ainda falta provar que, para aquela tentativa, a Primária usou aquele controle no conjunto exigido de consultas e tratou o erro antes da decisão.

O voto unânime não prova implantação em produção. A falta de detalhes públicos de uma CA não prova descumprimento. As fontes não permitem afirmar emissão indevida, envenenamento DNS, ocultação de log ou falha de empresa nomeada.

Também não permitem antecipar o resultado de 5 de setembro, a numeração da publicação posterior nem eventuais alterações. O estado verificável em 31 de agosto é: votação aprovada, revisão aberta, versão corrente ainda sem SC100.

Fontes