Resumo

  • Clientes novos do perfil leve no RFC 9919 devem usar SHA-256 nos hashes do nome e da chave do emissor em CertID; clientes antigos compatíveis com o RFC 5019 devem migrar de SHA-1 assim que for viável.
  • Um respondedor pode combinar SingleResponse com CertID SHA-1 e SHA-256 durante a transição. O algoritmo visto nas solicitações pode orientar a retirada da variante antiga.
  • O log do respondedor só vê o tráfego que o alcança. Cache no cliente e em proxies, respostas pré-produzidas, stapling, outras instâncias e acordos fora de banda podem manter dependências fora do contador.
  • O hash de CertID identifica o contexto do emissor do certificado consultado; ele não é o algoritmo de assinatura da resposta OCSP.
  • O encerramento precisa registrar pontos de observação, denominador, política dual, critério de parada, dono da decisão, canário, fallback, vencimento da exceção e resultado pós-corte.

O zero certo para a pergunta errada

É possível medir com precisão e concluir demais. Se nenhuma solicitação SHA-1 chegou a um endpoint por trinta dias, o resultado descreve aquele endpoint e aquele intervalo. Não demonstra, por si só, que todo cliente capaz de depender da compatibilidade teve uma oportunidade observável de aparecer.

O perfil de alto volume reduz deliberadamente os acessos de origem. Respostas OCSP podem ser produzidas antecipadamente. Clientes guardam respostas autoritativas; proxies HTTP reutilizam objetos; o servidor distribui material em cache. Com stapling ou piggybacking, o cliente recebe a resposta dentro de outra troca e nem abre uma sessão HTTP separada com o respondedor. Menos hits é uma propriedade desejada, mas enfraquece a ideia de usar hits como censo.

Há ainda rotas paralelas. Instâncias regionais, failover, redes privadas e famílias distintas de certificados podem produzir populações diferentes. Como o protocolo não anuncia a capacidade do respondedor, acordos operacionais fora de banda podem definir qual profile se aplica. Um painel isolado não contém esse inventário.

Assim, a queda pode vir de upgrade, de maior duração da resposta, de cache mais eficiente, da adoção de stapling ou de mudança de roteamento. A métrica só ganha autoridade quando essas hipóteses aparecem no recibo.

A mudança de algoritmo em seu lugar correto

O RFC 5019 exigia SHA-1 em issuerNameHash e issuerKeyHash. O RFC 9919 torna SHA-256 obrigatório para clientes do novo perfil e manda os clientes antigos migrarem assim que possível. A ponte de compatibilidade é explícita: embora uma resposta deva normalmente trazer um SingleResponse, elementos extras são permitidos para pré-produção, eficiência de cache e compatibilidade. O exemplo traz um CertID SHA-1 e outro SHA-256.

Quando nenhum cliente precisar de SHA-1, o respondedor não deve continuar distribuindo essa forma. O RFC permite considerar logs do algoritmo solicitado para informar a decisão. Ele não fornece prazo universal, porcentagem máxima nem denominador de clientes. A aprovação continua sendo local.

O nome do campo importa. Conforme o RFC 6960, CertID.hashAlgorithm governa os hashes do nome distinto e da chave pública do emissor; o serial identifica o certificado. O algoritmo da assinatura aparece separadamente em BasicOCSPResponse.signatureAlgorithm. O RFC 9919 também delimita o risco: SHA-1 nesse cálculo de CertID não é, em si, uma preocupação criptográfica; o custo é manter suporte, complexidade e potencial superfície de ataque.

Retirar essa compatibilidade pode simplificar software. Não autoriza um relatório a dizer que a assinatura OCSP em SHA-1 foi retirada sem verificar outro campo.

Contar quem poderia ter sido contado

O denominador começa com todas as instâncias e rotas relevantes, regiões, hostnames, famílias de certificados e grupos de clientes. Para cada grupo, registrar se sua dependência aparece em solicitação direta, revalidação, telemetria de proxy, stapling, uso offline ou fallback. O estado “não observado” deve sobreviver à análise.

A janela deve atravessar os ciclos de vida das respostas. Um cliente antigo com resposta ainda válida pode ficar silencioso até o próximo refresh. Dispositivos com janelas raras de atualização e PKIs fechadas precisam de verificação própria. O canário deve representar os caminhos materiais, não apenas o tráfego mais visível.

Exclusões são aceitáveis quando nomeadas, atribuídas e datadas. Sem isso, a planilha transforma desconhecidos em migrados e transfere a perda para quem não estava no painel.

O recibo que encerra a compatibilidade

O documento final une escopo e owner; pontos de observação e denominador; inventário de exceções; política de resposta única ou dual; cobertura de cache e stapling; intervalo e critério de parada. Define população e duração do canário, condição de rollback, fallback e data de expiração da exceção.

Depois do corte, acrescenta solicitações SHA-1 reaparecidas, erros do respondedor, falhas de validação, uso de fallback, certificados afetados e consequência para o serviço. Esse retorno transforma autorização em resultado verificável.

O IETF define a interoperabilidade, mas não assume a operação de cada ambiente. A equipe que controla a mudança e sua consequência deve responder pela prova. O legado não deve durar por abandono; tampouco deve ser apagado por uma métrica sem alcance declarado.

Fontes