Resumo

  • O perfil da RFC 5280 já exigia keyUsage e cRLSign para uma chave que valida assinaturas de CRLs; o algoritmo, porém, dizia para conferir o bit somente se a extensão estivesse presente.
  • A RFC 10007 transforma presença e valor em dois testes obrigatórios para certificados v3. DN, caminho e assinatura corretos não concedem a finalidade que o certificado não declarou.
  • O recibo de validação conserva versão e chave, extensão, escopo e atualidade da CRL, caminho, assinatura, resultado do serial e exceção legada em campos independentes.

Uma PKI pode ter duas chaves perfeitamente válidas para o mesmo sujeito. Essa redundância parece rotineira até que uma autorização destinada a uma delas seja emprestada à outra.

Na situação descrita pela RFC 10007, uma autoridade certificadora delega a emissão de CRLs indiretas ao sujeito X. A chave A recebe um certificado com keyUsage e cRLSign. Certificados cobertos apontam para o DN de X no campo cRLIssuer dos pontos de distribuição.

A CA também certifica a chave B para X. B foi criada para outra finalidade, e seu certificado não traz keyUsage. O nome continua X e o caminho de certificação de B pode chegar à mesma âncora. Se X assinar uma CRL com B, a assinatura pode verificar e o DN pode coincidir. O que falta é o ato de certificar B para assinar CRLs.

Corey Bonnell, Tadahiko Ito e Tomofumi Okubo registraram a correção na RFC 10007, publicada em junho de 2026 no Standards Track e atualizando a RFC 5280. Bonnell aparece primeiro entre os três autores. Atribuir essa contribuição não transforma o trabalho coletivo do IETF em invenção individual nem em controle sobre implementações.

Certificar uma identidade não certifica todos os usos

Uma assinatura válida liga bytes a uma chave privada. Um caminho válido liga a chave pública, sob determinadas regras, a um sujeito e a uma âncora. O uso autorizado vem de outra parte do certificado.

A seção 4.2.1.3 da RFC 5280 manda incluir keyUsage, como critical, quando o certificado valida assinaturas de certificados ou CRLs. O bit cRLSign marca especificamente a verificação de assinaturas de listas de revogação.

O algoritmo antigo da seção 6.3.3 trazia uma condição: se a extensão estivesse presente, verificar o bit. Um programa literal rejeitaria keyUsage presente sem cRLSign, mas poderia pular tudo quando a extensão faltasse. O vazio ficava mais permissivo que uma restrição explícita.

Esse defeito é maior que a frase que o contém. Automação de segurança frequentemente valida o conteúdo de um campo sem validar sua presença obrigatória. A interface exibe sucesso porque não houve valor proibido, quando na verdade não houve evidência de permissão.

A RFC 10007 muda o passo para certificados v3: verificar a presença de keyUsage e verificar cRLSign. Logs devem guardar as duas respostas. Ausência da extensão sugere perfil inadequado ou certificado errado; bit desativado declara finalidade incompatível. A correção operacional depende dessa diferença.

O caso legado tem versão e dono

Certificados X.509 v1 e v2 não possuem campo de extensões. Por isso a nova verificação de presença não se aplica a eles. A exceção é uma limitação de representação, não uma permissão geral para omitir a extensão em v3.

Uma migração pode revelar certificados v3 antigos, usados para CRL, mas sem keyUsage. Validadores anteriores aceitam as listas; versões que implementam a RFC 10007 rejeitam os mesmos bytes. Não é a matemática que mudou. A implementação passou a exigir que a finalidade estivesse certificada.

A norma recomenda que CAs incluam a extensão nos certificados usados para verificação de CRL. Se não for possível alterar o perfil, a autoridade de política da PKI deve exigir DNs únicos para certificados de finalidades diferentes. Nomes separados reduzem o risco de escolher outra chave do mesmo sujeito, mas não reemitem o certificado nem definem o fim da exceção.

O relatório deve evitar dois exageros. A rejeição após upgrade não prova que o software novo estragou a revogação; pode ter exposto dívida de perfil. Também não prova exploração, falsificação ou furto de chave. O fato sustentado é mais estreito: a autorização exigida não está representada no certificado v3 escolhido.

Uma porta de autorização não é o edifício inteiro

Passar em cRLSign não encerra a validação. Ainda é preciso selecionar emissor e CRL corretos, formar o caminho, avaliar algoritmo e assinatura, processar distribution point e issuing distribution point, CRL indireta e extensões críticas, e verificar thisUpdate e nextUpdate.

Quando há CRL completa e delta, a relação precisa ser coerente. Depois, o serial do certificado-alvo é procurado, com data e motivo quando revogado. Uma CRL autorizada pode estar vencida ou fora de escopo. Uma CRL válida pode dizer que o alvo foi revogado.

Cada resultado deve manter seu alcance. “Assinante autorizado” não quer dizer “certificado confiável”. “Autorização ausente” não quer dizer “ataque confirmado”. Essa disciplina impede que um indicador técnico assuma o papel de uma conclusão operacional maior.

Pela lente de agency de Heng Lu, autores definem a gramática; a CA define o perfil; o fornecedor escreve o running code; a autoridade de política aceita exceções; o serviço sofre as consequências. A especificação mínima coordena a verificação, enquanto implantação e prazo continuam decisões locais. Nenhum agente pode emprestar sua autoridade sem registro.

Um recibo com todas as junções

Preservar certificado-alvo, âncora, URI e hash da CRL, instante de coleta, thisUpdate, nextUpdate, algoritmo e versão do validador. Identificar o certificado emissor por serial, Subject Key Identifier, Authority Key Identifier relevante, DN e versão.

Registrar separadamente: caminho, assinatura, condição v3, presença e criticality de keyUsage, cRLSign. Para v1/v2, anexar política, responsável, população e data de revisão.

Em outro bloco, guardar distribution point, cRLIssuer, estado de CRL indireta, issuing distribution point, razões cobertas e relação completa/delta. Por fim, serial-alvo, presença, data e motivo de revogação, evidência ausente ou vencida e decisão da aplicação.

Quando duas versões discordarem, esse recibo mostra se uma omitiu o teste, escolheu outro certificado ou falhou em outra etapa. Um único status vermelho cria uma interrupção sem diagnóstico; os campos unidos apontam a fronteira da migração.

A conclusão responsável é específica: determinado validador processou uma CRL exata com um certificado v3 identificado; encontrou keyUsage e cRLSign; caminho, assinatura, escopo, atualidade e serial produziram seus próprios resultados. Segurança confiável não elimina as etapas. Torna cada uma demonstrável.

Fontes