Lista de Revogação de Certificados (CRL)

Na arquitetura X.509, a CRL ocupa o caminho entre a emissão e o vencimento. Um certificado pode precisar ser invalidado porque a chave privada foi comprometida, o dispositivo foi perdido, a autorização terminou ou os dados mudaram. A autoridade certificadora publica uma lista assinada com entradas por número de série. A RFC 5280 define o perfil. A CRL contém issuer, `thisUpdate`, `nextUpdate`, algoritmo de assinatura, extensões e certificados revogados. Cada entrada pode ter `revocationDate`, reason code e invalidity date. O cliente obtém a URL pela extensão CRL Distribution Points do certificado ou por configuração. Depois verifica a assinatura com a chave da CA emissora, a validade temporal e se o número de série está presente. Se está, rejeita. Se não está, considera não revogado apenas até o limite da política. Uma CRL antiga além de `nextUpdate` não deve ser tratada como atual. O comportamento em falha precisa ser definido. Fail-open mantém disponibilidade, mas aceita certificado possivelmente revogado. Fail-closed aumenta segurança e pode derrubar serviço por indisponibilidade do repositório. Em sistemas de acesso físico, uma cópia local é necessária para operação offline. O controlador baixa quando conectado e mantém até a próxima atualização. A assinatura permite distribuir por HTTP sem depender de TLS para autenticidade, embora TLS proteja transporte e privacidade. O relógio é requisito. A consequência para o morador é que um celular ou gateway perdido pode ter certificado revogado sem trocar credenciais de todos.

Uma CRL completa enumera todas as revogações aplicáveis que ainda precisam ser consideradas. Em uma CA com milhões de certificados, pode crescer para megabytes e consumir banda e memória. Delta CRLs carregam apenas mudanças desde uma base, identificadas por Base CRL Number. O cliente precisa da base e das deltas corretas. A complexidade aumenta e o suporte varia. CRL Number permite ordenar e detectar rollback. Freshest CRL indica deltas. CRLs indiretas podem ser emitidas por uma autoridade diferente da emissora dos certificados, com indicação de issuer por entrada. Isso permite delegar, mas torna validação mais complexa. Em casa inteligente, uma PKI privada pequena normalmente usa CRL completa curta. Se certificados têm validade de 24 horas ou 7 dias, pode ser mais simples não revogar individualmente e depender de expiração, desde que o risco aceite. Para identidades de anos, CRL é necessária. O período de publicação define janela de exposição. Uma CRL a cada 24 horas significa que um certificado comprometido pode ser aceito até a próxima atualização e propagação. Publicar a cada 15 minutos reduz janela, aumenta carga. Emergency CRL pode ser emitida após incidente. O repositório usa alta disponibilidade e cache. CDN ajuda. Os clientes não devem baixar a cada handshake; fazem cache até `nextUpdate`. O servidor deve suportar ETag e escalabilidade, mas a validação criptográfica permanece.

Controladores de fechadura, portaria e gateways podem operar sem Internet. OCSP online pode ser inviável. Uma CRL pré-carregada ou sincronizada periodicamente oferece revogação offline. O dispositivo verifica assinaturas localmente. A CRL pode ser transportada por atualização do sistema, protocolo de gestão ou HTTP interno. A memória é limitada. Certificados por dispositivo e CRL pequena funcionam. Se há centenas de milhares, usar particionamento por Distribution Point ou certificados curtos. O firmware precisa implementar parser X.509 robusto; ASN.1 malformado é superfície. Bibliotecas atualizadas. O cliente deve validar issuer, AKI, assinatura, datas e escopo. Não basta procurar serial em arquivo não verificado. Números de série podem coincidir entre CAs, então o issuer importa. A revogação de uma CA intermediária é tratada pela CRL da CA superior, não pela sua própria lista. Cadeias precisam ser verificadas. Se a CRL não pode ser atualizada, o dispositivo deve entrar em estado definido. Uma fechadura não deve travar moradores automaticamente por queda da rede. Pode manter credenciais locais e bloquear novas concessões. A política de segurança física precisa diferenciar. O log registra versão da CRL e decisões. Quando volta, sincroniza. A CRL também não informa “good” em tempo real; apenas ausência na lista. Um certificado não listado ainda pode ter sido comprometido e não reportado.

CRL cobre revogações em lote e permite validação offline. Não fornece frescor por consulta. OCSP pergunta o status de um certificado e recebe `good`, `revoked` ou `unknown`, com resposta assinada. OCSP reduz download de listas grandes, mas cria dependência online e pode revelar ao responder quais certificados estão sendo usados. OCSP stapling transfere resposta pelo servidor. Certificados de curta duração reduzem dependência de revogação. Nenhum mecanismo é perfeito. CRLs podem ficar grandes, ser atrasadas, bloqueadas ou ignoradas por clientes. Muitos navegadores usam mecanismos próprios em vez de CRLs completas por desempenho. Em PKI privada, o administrador controla. Uma CRL não revoga uma chave por si; clientes precisam consultar e aplicar. Um erro comum é emitir CRL e não configurar Distribution Point, ou configurar URL inacessível aos dispositivos. Outro é colocar URL interna em certificado usado externamente. O desenho define. A CA precisa assinar CRLs com chave adequada e proteger. O repositório não deve permitir substituição, embora assinatura detecte. Ataque de rollback pode apresentar CRL antiga ainda dentro da validade; CRL Number e política ajudam. O intervalo deve ser menor que risco. Em uma casa, a simplicidade favorece certificados curtos para serviços efêmeros e CRL para dispositivos de longa vida que operam offline.