Resumo

  • O RFC 10007 altera o processamento de CRL do RFC 5280: um certificado v3 do emissor precisa conter keyUsage e afirmar cRLSign.
  • Nome do sujeito, caminho até a mesma âncora e assinatura válida não transferem para uma segunda chave a finalidade certificada da primeira.
  • A regra pode expor certificados legados emitidos para CRL sem a extensão; a CA corrige a origem e a parte confiadora controla teste, ativação, exceção e prova de cobertura.

A rotação que preservou o nome e perdeu a finalidade

O exemplo do RFC 10007 coloca duas chaves sob o sujeito X. A chave A recebe um certificado com keyUsage e cRLSign. A chave B recebe outro certificado, para um uso comum, com o mesmo sujeito e sem keyUsage.

Certificados dependentes apontam X como emissor indireto de CRL. Se X assinar a lista com B, o nome confere, a cadeia de B pode chegar à mesma âncora e a assinatura pode ser matematicamente correta. O que não confere é a autorização daquela chave específica.

A ficha do RFC 10007 registra a publicação em junho de 2026 e a atualização do RFC 5280. O texto anterior do RFC 5280 mandava verificar cRLSign se keyUsage estivesse presente. A ausência da extensão podia eliminar o teste. A ficha do RFC 5280 acompanha um perfil que já exigia a extensão quando a chave fosse usada para verificar certificados ou CRL.

O novo passo alinha emissão e consumo: em v3, verificar presença e bit. Certificados v1 e v2 não possuem campo de extensões, por isso ficam fora dessa verificação específica.

Mesmo sujeito não significa mesma chave

Não é preciso que X seja falso. X pode controlar legitimamente A e B. O erro nasce quando identidade vira autorização para qualquer finalidade.

O RFC 4514 define como representar nomes distintos em LDAP; sua ficha não transforma o DN em impressão digital de chave. Certificados de e-mail, documento, autenticação e revogação podem compartilhar o nome e continuar separados.

O RFC 5280 dá funções próprias a digitalSignature, keyCertSign e cRLSign. Este último cobre verificação de assinaturas de CRL, delta CRL e listas de revogação de autoridade. Uma chave capaz de assinar bits não está automaticamente certificada para emitir estado de revogação.

O RFC 10007 no Datatracker, o histórico do documento, a carta do LAMPS e o histórico do grupo comprovam o processo. Não medem suporte de produto nem adoção por CA.

A lista indireta combina várias provas

Em uma CRL indireta, o emissor da lista pode ser diferente da CA do certificado avaliado. O ponto de distribuição do certificado nomeia um cRLIssuer; a extensão crítica issuingDistributionPoint da lista afirma indirectCRL e limita escopo.

A parte confiadora precisa alinhar nome, papel indireto, escopo, caminho, âncora, assinatura, finalidade, tempo e motivos cobertos. O RFC 10007 conserta a finalidade. Um cRLSign correto não prova conteúdo, atualidade, completude ou disponibilidade.

O RFC 3647 separa CA, autoridade de registro, repositório, assinante e parte confiadora, além de política, prática, auditoria e serviço de status. Sua ficha ajuda a atribuir responsabilidades que um único teste criptográfico não pode absorver.

A correção pode interromper a evidência antiga

O RFC 10007 avisa que uma aplicação atualizada não verificará uma CRL assinada por um certificado v3 que pretendia servir a esse fim, mas omitiu keyUsage. O emissor legado pode ter sido operacionalmente aceito durante anos e ainda assim estar mal formado para a finalidade.

A CA deve inventariar, corrigir o perfil, reemitir, manter sobreposição e retirar a chave antiga com evidência. Se o perfil realmente não puder mudar, a autoridade de política deve usar DNs diferentes para finalidades diferentes. Esse recurso reduz a colisão; não substitui finalidade explícita, custódia, escopo e frescor.

Rejeitar uma CRL não prova revogação. A prova falhou e o estado pode ser indeterminado. Mapear tudo para “bom” destrói o controle; mapear tudo para “revogado” bloqueia sem base.

OCSP tem delegação própria. O RFC 6960 prevê assinatura pela CA, configuração local ou certificado delegado com id-kp-OCSPSigning sob condições definidas; sua ficha descreve outro protocolo. O RFC 6818 e sua ficha registram manutenção anterior do RFC 5280. Nenhum documento prova implantação automática.

Regra comum estreita, decisão operacional local

A primazia do código em execução de Lu Heng separa publicação de realidade. Seu modelo de especificação mínima, decisão localizada e adoção voluntária reserva ao plano comum invariantes determinísticos e deixa a sequência com quem opera.

Exigir cRLSign em v3 é um invariante localmente verificável. O documento não reemite certificados nem escolhe a janela de mudança. A implantação só se torna real quando CA e partes confiadoras produzem evidência de funcionamento.

Fontes