Resumo

  • Cada extensão do X.509 v3 leva um OID, um booleano critical cujo padrão é falso e um valor codificado; a escolha está dentro dos dados assinados.
  • Uma extensão crítica desconhecida ou impossível de processar exige rejeição. Uma extensão não crítica desconhecida pode ser ignorada, mas deve ser processada quando reconhecida.
  • Criticidade não mede prioridade, confiança ou veracidade. Ela informa se a ausência de uma capacidade semântica torna o certificado inaceitável.

O certificado antigo tinha conteúdo contado

O RFC 1422, de 1993, descrevia o certificado usado no PEM por sete componentes principais: versão, número de série, assinatura, emissor, validade, sujeito e chave pública. Era a forma da primeira geração do X.509. Ela resolvia um vínculo importante, mas não tinha um campo geral para todas as futuras maneiras de limitar nomes, usos de chave, políticas e delegações.

O X.509 v3 acrescentou uma sequência de extensões. Quando o RFC 2459 publicou o primeiro perfil para a PKI da Internet, em 1999, já podia listar extensões padronizadas e permitir outras registradas por organizações. A estrutura externa permanecia estável enquanto os significados se multiplicavam.

A compatibilidade, porém, deixou de ser uma propriedade automática. Um programa antigo não conhecia OIDs criados depois de sua distribuição. Rejeitar todo OID desconhecido impediria crescimento; ignorar todos faria uma nova restrição desaparecer exatamente nos validadores menos capazes de aplicá-la.

Três elementos atribuíam o custo da novidade

No RFC 5280, extnID identifica a semântica, extnValue guarda sua codificação DER e critical define a reação à falta de compreensão. O booleano é falso quando omitido.

Se um sistema não reconhece uma extensão crítica, deve rejeitar o certificado. Se reconhece o OID mas não consegue processar a informação, também deve rejeitar. Uma extensão não crítica desconhecida pode ser deixada de lado. Isso não torna facultativa uma extensão conhecida: reconhecê-la traz a obrigação de processá-la mesmo quando o bit é falso.

Crítico não quer dizer “mais seguro”. Não muda a assinatura, não autentica melhor o sujeito e não confirma que a CA investigou corretamente. Quer dizer que o resultado não pode ser sucesso sem aquela semântica.

O bit integra TBSCertificate e está protegido pela assinatura junto com o OID e o valor. Um intermediário não pode tornar a extensão não crítica para salvar um cliente legado. Também é vedado repetir a mesma extensão no certificado, evitando que duas cópias concorrentes transformem validação em escolha de precedência.

As fronteiras estavam em campos concretos

Quando o campo de sujeito está vazio e a única identidade aparece em subjectAltName, a extensão deve ser crítica. Um validador que a desconheça não pode aceitar a chave sem ler o único nome ao qual ela foi vinculada.

Em certificados de CA usados para verificar assinaturas de outros certificados, basicConstraints deve existir e ser crítica. O booleano cA diz se a chave pode atuar como autoridade; o limite de caminho pode restringir quantas camadas de delegação seguem. Ignorar o campo pode alargar uma competência limitada.

nameConstraints limita os espaços de nomes dos certificados abaixo de uma CA intermediária e deve ser crítica. Uma CA autorizada apenas para um conjunto de domínios não pode parecer universal a um software que desconheça a restrição. policyConstraints e inhibitAnyPolicy também retiram possibilidades do caminho e, por isso, exigem processamento.

Outras extensões são deliberadamente não críticas. Um identificador ou localizador pode ajudar sem definir a autoridade essencial do certificado. Não existe uma escala única em que TRUE seja sempre a opção mais prudente. O perfil de cada extensão responde se o uso ainda é correto sem compreender aquele campo.

Recursos de numeração e TLS escolheram lados diferentes

O RFC 3779 criou extensões para blocos IP e identificadores de sistemas autônomos. Recomendou marcá-las como críticas porque uma parte que usa o certificado precisa entender quais recursos estão sob direito de uso. Uma assinatura válida sem a extensão de recursos não responde à pergunta operacional para a qual o certificado foi emitido.

O RFC 7633 recomendou o contrário como padrão para TLS Feature. Torná-la crítica faria validadores antigos recusarem o certificado. Essa ruptura só faz sentido quando excluir tais clientes é um comportamento desejado, não uma consequência acidental da implantação.

O emissor não ganha simultaneamente alcance legado e aplicação universal da regra. Não crítico preserva alcance e aceita desconhecimento. Crítico preserva o mandato e aceita rejeição. O bit tornou explícito quem pagaria a migração.

A recusa existia onde o código rodava

O RFC 3280 colocou o tratamento das extensões em um algoritmo detalhado de validação de caminho. O RFC 5280 manteve a obrigação de resultado: extensões críticas aplicáveis precisam ser reconhecidas e processadas, e qualquer falha encerra o caminho.

Publicar um OID cria uma referência comum; assinar o valor registra uma declaração do emissor. Nenhum dos dois atos instala suporte no destinatário. A regra ganha efeito apenas onde um validador em execução identifica, decodifica, aplica e recusa. O registro descreve o contrato; não cria adoção por si só.

O RFC 9618, de 2024, preservou essa honestidade ao atualizar a validação de políticas. Uma aplicação pode desativar a função se não precisar dela. Mas, diante de extensões críticas de política, deve tratá-las como desconhecidas e rejeitar. Ausência de capacidade não pode ser apresentada como cumprimento.

Validade de caminho não era autoridade ilimitada

O resultado bem-sucedido informa que um caminho escolhido satisfez assinaturas, datas e restrições para uma âncora e finalidade. Não prova honestidade do sujeito, correção material da CA, integridade presente da chave privada nem adequação a toda decisão empresarial.

Um OID conhecido pode conter bytes malformados; bytes válidos podem violar a semântica. Caminhos diferentes podem trazer intermediárias e limitações diferentes. A criticidade impede que uma obrigação desconhecida seja apagada em silêncio, mas não reúne toda confiança em um booleano.

RFC 1422, RFC 2459, RFC 3280, RFC 5280, RFC 3779, RFC 7633 e RFC 9618 sustentam a história, a sintaxe e as regras especificadas. Eles não medem participação atual de navegadores, incidência de falhas, população de certificados ou conformidade de produtos.

O pequeno campo crítico não tornou o X.509 infalível. Ele fez algo mais limitado e duradouro: permitiu acrescentar significados sem confundir “o software não sabe” com “a regra foi satisfeita”.