Resumo

  • No commit-base indicado pela SC-104, o certificado de assinante TLS deve conter a extensão não crítica Authority Information Access. Dentro dela, id-ad-caIssuers tem presença SHOULD e id-ad-ocsp, MAY.
  • O redline altera somente o MUST externo para SHOULD e torna condicional a exigência de um ou mais AccessDescription. As regras dos dois métodos permanecem intactas.
  • caIssuers aponta para material do emissor que pode auxiliar a construção do caminho de certificação; OCSP aponta para um serviço de status. Eles compartilham o contêiner, mas não exercem a mesma função.
  • O aviso público definiu o fim da votação para 3 de setembro de 2026, às 00:00 UTC. No corte de 2 de setembro, não havia base para declarar aprovação, revisão de IPR concluída ou Guideline final publicada.
  • Um registro confiável separa cinco estados: procedimento, perfil, método, bytes emitidos e comportamento do relying party. Uma única coluna “AIA conforme” mistura autoridades e provas diferentes.

O contêiner mais forte que seu conteúdo

A estrutura atual pode ser lida como três portas. A primeira exige que a extensão AIA exista no Subscriber Certificate. A segunda exige que, dentro da extensão, exista pelo menos um AccessDescription. A terceira define quais métodos podem atravessar essa porta.

No texto-base, a primeira porta é MUST. A terceira, contudo, não torna qualquer serviço individual obrigatório: caIssuers é SHOULD, OCSP é MAY, e outros métodos são MUST NOT. O contêiner tem força absoluta; cada conteúdo permitido tem uma força diferente e menor.

Isso não torna a extensão vazia ou desregulada. Se AIA estiver presente, os requisitos de sintaxe, tipo de localização, unicidade e ordem continuam valendo. Um SHOULD também não é ausência de regra. A questão é se o MUST do nível externo promete algo que nenhuma linha interna garante de modo individual.

A SC-104 responde com uma edição restrita. Troca o nível de presença externo para SHOULD e adiciona “If present” à cardinalidade. Não transforma caIssuers em MAY, não promove OCSP, não cria método, não muda OID e não generaliza a alteração para todos os tipos de certificado.

O título correto, portanto, não é “AIA deixa de existir”. É “a recomendação externa muda de nível, mantendo diferentes as regras internas”.

Exceção documentada não é o mesmo que omissão casual

RFC 2119 reserva SHOULD para uma recomendação da qual se pode divergir por razões válidas, depois de compreender e pesar as consequências. RFC 8174 esclarece o uso normativo das palavras em maiúsculas.

Se a SC-104 chegar a uma versão vigente, um certificado sem AIA deixará de contrariar um MUST de presença. Ainda assim, o emissor terá de administrar uma decisão contra o comportamento recomendado. Para tornar essa decisão auditável, precisa guardar a versão da regra, o motivo, o produto, a configuração de emissão, o intervalo de validade da exceção e os testes realizados.

Um campo Booleano não dá conta disso. false pode significar uma exceção estudada, uma migração incompleta ou um erro. Também não informa se o emissor retirou o contêiner todo ou modificou somente um método. A governança do SHOULD está justamente no contexto que o Booleano perde.

Há uma alternativa melhor: estados explícitos para inclusão padrão, exceção autorizada e desvio sem justificativa, cada um ligado à configuração que o produziu. A flexibilidade normativa pode coexistir com evidência local mais precisa.

Descoberta de cadeia e status são trabalhos separados

Segundo a RFC 5280, AIA contém informações ou serviços sobre o emissor. id-ad-caIssuers indica onde obter certificados do emissor e pode auxiliar a seleção de um caminho de certificação. id-ad-ocsp localiza um serviço online de status do certificado.

Ambos podem usar uma URI e aparecer na mesma sequência ASN.1. Isso não os transforma em equivalentes. Uma consulta OCSP não fornece, por definição, o mesmo objeto que uma localização caIssuers; recuperar um intermediário não demonstra que o status foi verificado.

Os próprios Baseline Requirements mantêm essa diferença em outras condições. Regras ligadas a CRL podem depender especificamente de um ponteiro OCSP dentro de AIA. Por isso, a observação deve guardar cada OID e localização, e não só a presença da extensão.

Também é preciso evitar inferir falha de cadeia a partir da ausência de caIssuers. O servidor TLS pode entregar o intermediário. O cliente pode tê-lo no armazenamento, em cache ou numa distribuição do fornecedor. Por outro lado, uma URL presente não prova que haverá consulta, conectividade, resposta correta ou caminho válido.

O certificado mostra o que foi codificado. Não mostra de onde vieram todos os insumos da validação.

Dois clientes documentados, várias condições ocultas

A Microsoft documenta que o Windows pode recuperar certificados de emissor ausentes por AIA e que administradores podem desativar essa recuperação. O nome do sistema operacional não basta como resultado de teste. Versão, política, cache, armazenamento, rede, URL e cadeia do servidor são variáveis necessárias.

A Mozilla descreveu em 2020 a pré-carga de certificados intermediários divulgados no Firefox por Remote Settings. Uma finalidade era reduzir erros de emissor desconhecido quando sites não enviavam corretamente o intermediário. A pré-carga mostra que um cliente pode receber material por outro canal, mas não comprova cobertura universal nem elimina o dever do servidor de entregar uma cadeia apropriada.

Esses exemplos não medem todo o ecossistema. Um Windows corporativo com recuperação desativada, um Firefox com intermediário pré-carregado e uma biblioteca embarcada sem busca de rede podem reagir de maneiras distintas ao mesmo certificado.

O teste reproduzível precisa registrar a fonte do intermediário: servidor, armazenamento local, cache, pré-carga ou busca caIssuers. Sem isso, o sucesso pode ser atribuído ao certificado quando, na verdade, outro canal cobriu a ausência. A dependência aparece somente quando esse canal muda.

A regra tem de percorrer o processo antes de valer

O aviso da SC-104 identifica Ethan Davis, da Google Trust Services, como proponente, e Roman Fischer, da SwissSign, e Stephen Davidson, da DigiCert, como endorsers. A base declarada é a versão 2.2.9 dos Baseline Requirements, com comparação fixa entre os commits ad77bf… e a0f9a7….

A discussão ocorreu de 20 a 27 de agosto de 2026 UTC, conforme o aviso. A votação foi marcada de 27 de agosto a 3 de setembro, às 00:00 UTC. No dia 2, a situação verificável era votação em curso.

Há etapas posteriores mesmo diante de um resultado favorável. O processo de propriedade intelectual e a publicação de uma Final Maintenance Guideline têm registros próprios. Um pull request aberto não é um voto; um voto não é uma revisão IPR; uma revisão não é a versão publicada com data de vigência.

O recibo processual deve preservar ballot, base, proposta, janelas, eleitorado, denominadores, votos, resultado, IPR, exclusões, Guideline e vigência. A informação mais recente acrescenta estado, mas não reescreve a natureza do documento em 2 de setembro.

Cinco estados que podem ser unidos sem virar um só

Procedimento. Identificador SC-104, commits, discussão, votação, IPR e publicação. Prova a autoridade de uma redação.

Perfil. Tipo de certificado, versão do Guideline, criticidade, nível de presença AIA e data efetiva. Prova a regra aplicável.

Método. OID, função, nível, localização, quantidade e ordenação de caIssuers e OCSP em linhas distintas. Prova a estrutura permitida ou recomendada.

Emissão. CA emissora, produto, versão da configuração, fingerprint, extensão e descrições observadas. Prova os bytes de um certificado.

Uso. Cliente, versão, plataforma, política, armazenamento, cache ou pré-carga, cadeia entregue, rede, busca, origem do intermediário, mecanismo de status e resultado. Prova uma execução delimitada.

A versão do Guideline une procedimento e perfil. A configuração liga perfil e emissão. O fingerprint liga emissão e uso. Mas a relação não permite substituir provas. Um cliente pode validar sem buscar AIA. Um certificado pode seguir uma exceção a SHOULD e falhar por outro motivo. Uma aprovação normativa não demonstra mudança de template.

A proposta de Lu Heng de separar especificação inicial comum, decisões futuras localmente verificáveis e adoção ajuda a manter essa fronteira. Não significa que ele tenha examinado a SC-104. É uma disciplina: publicação, implementação e efeito não são sinônimos.

O que a justificativa não mede

As fontes públicas usadas aqui não mostram a prevalência atual de AIA, caIssuers ou OCSP nos certificados de assinante. Não indicam quais CAs mudariam sua emissão. Não quantificam tamanho, privacidade, tráfego, latência, disponibilidade, segurança ou falhas. Não identificam um cliente cuja dependência motivou o ballot.

Isso não torna ilógica a justificativa. Se nenhuma linha interna garante um método específico, tornar o contêiner um SHOULD pode alinhar a estrutura normativa. Mas alinhamento não é benefício operacional comprovado.

Quem apoia não pode usar a pré-carga do Firefox como prova de que nenhuma omissão fará diferença. Quem se opõe não pode usar a recuperação do Windows como prova de dependência universal. Ambos precisam de amostras definidas, versões e configurações.

Uma afirmação do tamanho do diff

A SC-104 permite uma decisão estreita: o nível externo deve passar de MUST a SHOULD mantendo duas regras internas diferentes? O Working Group pode responder pelo processo estabelecido. Depois, CAs, root programs, clientes e servidores continuam responsáveis por suas próprias superfícies.

O registro de cinco estados impede que a decisão cresça indevidamente. Em vez de “AIA ficou opcional”, registra-se o termo exato. Em vez de “os clientes não precisam”, registra-se uma execução. Em vez de “a CA mudou”, inspeciona-se uma configuração e um fingerprint.

Duas linhas não pedem uma narrativa total sobre a Web PKI. Pedem uma cadeia de prova que saiba onde parar.

Fontes

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum, pull request 665 do servercert — SC-104
  3. Comparação imutável da SC-104
  4. CA/Browser Forum, issue 673 do servercert
  5. Arquivo público do aviso de votação SC-104
  6. TLS Baseline Requirements no commit-base do ballot
  7. Bylaws do CA/Browser Forum
  8. RFC 5280, seção 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, recuperação por Authority Information Access
  12. Mozilla Security Blog, pré-carga de certificados de CA intermediárias no Firefox