Resumo

  • A RFC 9608 define noRevAvail para declarar que a autoridade certificadora não publicará informação de revogação para um certificado de entidade final. A validação pula essa etapa; não recebe uma confirmação de estado bom.
  • Certificados curtos e certas identidades de dispositivo muito longas podem justificar a escolha, mas a extensão não mede detecção, bloqueio local, troca de chave ou retirada de autoridade.
  • Um recibo local e mínimo do ciclo de vida sem revogação pode ligar o motivo do perfil, a admissão, os sinais alternativos e a saída. Trata-se de uma proposta editorial de Daniel Kade, não de uma nova extensão nem de uma obrigação da IETF.

A automação consegue transformar a emissão em uma rotina quase invisível. O cliente solicita, prova controle, recebe, instala e agenda a renovação. Quando cada certificado dura poucas horas, parece razoável concluir que o tempo resolverá qualquer problema antes de uma CRL ou resposta OCSP fazer diferença.

Essa conclusão só vale se a expiração vencer a corrida contra o dano. Uma chave furtada pode continuar ativa até o fim da validade. Pode manter sessões abertas. Pode pedir renovação. Pode estar ligada a uma conta que ainda não foi desabilitada. Uma sequência rápida de certificados não é necessariamente uma sequência rápida de reavaliações de autoridade.

Publicada em junho de 2024 como Proposed Standard da IETF, a RFC 9608 atualiza a RFC 5280. Ela define noRevAvail como uma declaração de que a CA não disponibilizará informação de revogação para aquele certificado. A extensão tem valor NULL, é não crítica, serve a certificados de chave pública de entidade final e não pode aparecer em certificados de CA.

O significado limitado é uma virtude. Um software não precisa tentar uma fonte que o emissor avisou que não existirá. O problema aparece quando o resultado “não consultar” é convertido em “continuar confiando”. O primeiro pertence ao processamento do caminho. O segundo pertence ao serviço que concede acesso e precisa continuar observando o mundo.

Uma etapa pulada não devolve “bom”

O processamento de caminho da RFC 5280 normalmente inclui determinar que o certificado não foi revogado. A RFC 9608 altera esse ramo: com noRevAvail, a determinação é omitida. O mesmo ocorre no caso específico de ocsp-nocheck para certificados de respondedor OCSP, embora cada extensão tenha finalidade própria.

Uma resposta OCSP positiva seria uma afirmação de status feita sob regras e tempo definidos. Uma CRL permitiria verificar uma lista publicada. noRevAvail informa outra coisa: não haverá objeto de status para consultar. A máquina conhece uma propriedade do perfil de emissão, não a condição atual da chave.

A RFC impede mensagens contraditórias. Um certificado com noRevAvail não pode trazer CRL Distribution Points, Freshest CRL nem método OCSP em Authority Information Access. Se trouxer, deve ser considerado inválido. Não cabe ao validador escolher entre “não haverá revogação” e “consulte a revogação aqui”.

A política da aplicação precisa ter a mesma clareza. Se o serviço exige informação de revogação, um caminho criptograficamente válido não autoriza abrir uma exceção silenciosa. O serviço pode rejeitar a classe ou aprová-la sob controles alternativos explícitos. O que não pode fazer é deixar um padrão de interface reescrever sua política.

Um painel correto mostraria estados separados: caminho válido, etapa de revogação omitida por perfil, admissão local ativa, data de revisão e condição dos controles alternativos. Um único selo verde faz caber decisões de donos diferentes em um resultado que parece permanente.

Certificado curto exige relógio completo

A justificativa para uma credencial curta compara validade com detecção, comunicação, decisão e distribuição da resposta. Se todo esse processo demora dez horas e o certificado vence em uma, a publicação de revogação talvez chegue tarde. A expiração pode limitar melhor a exposição e reduzir uma dependência operacional.

Mas “curto” não é uma unidade técnica fixa. Uma hora pode autorizar milhares de operações irreversíveis. Um dia pode ser menor que o intervalo de conexão de um equipamento isolado. A RFC 9608 alerta que um período inadequadamente curto cria uma janela para o atacante, sem fingir que existe um número universal.

ACME automatiza obtenção e renovação, não a decisão inteira de confiança. É preciso saber se a renovação exige uma nova prova de autoridade, se força uma nova chave, se consulta o estado local do principal e se pode ser interrompida rapidamente. Uma chave roubada que renova em silêncio transforma credenciais breves em acesso persistente.

Também importam o tempo restante quando o alarme se torna acionável, o cache dos serviços, a duração das sessões, a sobreposição entre certificado antigo e novo e a propagação de listas locais de bloqueio. A expiração gravada no certificado é apenas um dos relógios.

Por isso, um programa maduro mede o caminho de retirada de ponta a ponta. Detecta uma anomalia, confirma o incidente, bloqueia novas emissões, desativa a identidade local, gera outra chave, implanta a substituição, remove a associação antiga e observa que o tráfego normal migrou. Se uma etapa demora mais que a validade prometida, essa diferença deve aparecer na decisão.

Identidades longas transferem o peso aos controles locais

A RFC 9608 também contempla certificados longos, como identidades instaladas em fábrica. Alguns dispositivos não têm fim de vida bem definido e podem usar um notAfter muito distante. A data representa um modelo operacional; não é evidência empírica de que dispositivo, dono, firmware, algoritmo e chave permanecerão seguros.

O emissor talvez não disponha de canal para um futuro proprietário relatar comprometimento do material instalado. Não consegue, portanto, publicar status individual útil. Declarar a ausência é mais honesto do que fornecer um endpoint fictício, mas desloca a resposta para outras camadas.

Um dispositivo pode ser vendido, perder suporte, mudar de operador ou assumir outro uso. A chave pode ser extraída. O serviço pode retirar a aprovação daquela classe. O objeto X.509 continua verificável enquanto a autorização real termina. Não há contradição: sintaxe e autoridade presente são proposições diferentes.

Os controles alternativos precisam ser nomeados. Remover o vínculo entre certificado e papel, desativar conta, quarentenar dispositivo, parar carga de trabalho ou negar uma impressão digital são ações locais. Não são revogação X.509 e não criam efeito global. Chamá-las de contenção local permite testar exatamente onde funcionam.

A substituição também é um estado independente. Emitir outro certificado para a mesma chave comprometida não repara custódia. Criar nova chave sem remover a autorização antiga deixa dois caminhos. O corte só termina quando a nova identidade opera e a antiga deixa de ser aceita nos serviços previstos.

Revogar uma CA mostra o tamanho da falha

As considerações de segurança da RFC 9608 apontam uma consequência severa. Uso indevido ou configuração errada pode levar partes dependentes a continuar confiando em um certificado comprometido. Ao descobrir esse uso indevido, a única remediação possível no nível da PKI mencionada pelo texto é revogar a CA.

Não se trata de um botão equivalente à revogação individual. Uma CA pode sustentar muitos certificados corretos. Sua retirada alcança serviços sem relação com o primeiro incidente, depende de atualização de lojas de confiança e chega tarde a sistemas offline. A frase revela que uma escolha de perfil pode concentrar risco institucional.

Por isso, a confiança inclui as operações, os controles e a resposta a incidentes do emissor. A RFC 3647 separa Certificate Policy, que apresenta requisitos de uma classe, de Certification Practice Statement, que descreve como a CA executa suas práticas. noRevAvail não transporta esse histórico institucional.

A parte dependente deve ligar a admissão a versões específicas do perfil, CP e CPS. Qual motivo tornou a classe elegível? A validade é curta perante quais tempos medidos? A identidade longa tem qual mecanismo de troca? Quais aplicações aceitam e quais recusam? Quem reabre a decisão diante de aviso do emissor ou mudança de algoritmo?

Confiança operacional não é licença eterna. Perfis mudam, controles degradam, organizações se fundem, incidentes aparecem. O serviço deve poder retirar admissão enquanto o certificado ainda está dentro da validade e sua assinatura continua correta. Isso atualiza uma decisão local; não reescreve o passado criptográfico.

Validade de caminho não é autoridade atual

Um caminho válido prova relações delimitadas: assinaturas, cadeia de emissores, restrições, período e políticas aplicáveis. Com noRevAvail, prova também que o ramo de revogação foi corretamente omitido. Não prova que o sujeito continua empregado, que o dispositivo pertence ao mesmo dono, que a carga ainda é aprovada ou que a chave nunca foi copiada.

Não se deve culpar X.509 por não conhecer um registro de ativos ou um contrato de trabalho. A falha ocorre quando uma aplicação transforma uma resposta de protocolo em substituto para todas as outras evidências. Sem revogação individual, essa compressão fica ainda mais perigosa.

A doutrina de Heng Lu distingue especificação mínima, decisão localizada, adoção voluntária, código em execução e resultado observado. A RFC fornece uma linguagem comum para a ausência. A aplicação decide se adota essa classe. A operação produz sinais. Os sinais podem mudar a decisão futura. Nenhuma camada monopoliza toda a autoridade.

Assim, um certificado pode continuar tecnicamente válido depois que a permissão local termina. Também pode ser aceito sem revogação quando exposição, monitoramento e recuperação estão bem limitados. A governança não impõe a mesma resposta a todos; exige que a resposta tenha dono, justificativa e possibilidade de correção.

Recibo do ciclo de vida sem revogação

A proposta editorial é um recibo local, minimizado e ligado por hashes. Na admissão, ele registra certificado e emissor, perfil, versões de CP/CPS, razão de noRevAvail, modelo de validade, aplicação, regra e responsável pela decisão. Confirma a ausência dos ponteiros proibidos e o ramo exato que o validador pulou.

Durante a execução, aponta para sinais alternativos de comprometimento, custódia da chave, estado do dispositivo ou workload, avisos do emissor e relógio de revisão. Não copia chaves privadas, todo o conjunto de dados do sujeito, topologia proprietária nem detalhes de incidente sem necessidade. Referências, tempos e conclusões restritas diminuem a exposição.

Para a saída, nomeia desativação local, quarentena, nova chave, nova inscrição, remoção da associação antiga, escalada ao emissor e contingência de CA ou âncora. O encerramento verifica se a autoridade anterior deixou de funcionar, e não apenas se surgiu outro certificado.

O recibo não é CRL, resposta OCSP, extensão X.509 ou regra da IETF. Não cria status global nem inventário público de dispositivos. Apenas demonstra que a ausência de uma via foi aceita dentro de limites, com sinais de revisão e uma saída que pode ser executada.

A RFC 9608 torna a ausência explícita. Governança é resistir à vontade de preencher essa ausência com uma garantia imaginária. Não haver rota de revogação significa que esse mecanismo não estará disponível. Não significa que nenhum acontecimento possa justificar retirar a confiança.

Fontes