Resumo

  • O RFC 9919 permite pré-produzir e armazenar respostas OCSP em clientes, proxies e servidores, mas diz que cabeçalhos HTTP não são protegidos criptograficamente e servem apenas como orientação de cache.
  • A aceitação exige correspondência com o certificado, assinatura válida de respondedor autorizado e comparação de thisUpdate e nextUpdate assinados com um relógio local preciso.
  • Um good ainda fresco prova, de forma limitada, a ausência de revogação; não prova sozinho emissão, validade completa, permissão de aplicação nem resultado operacional.

Escala por repetição controlada

Em ambientes com milhões de certificados, gerar uma assinatura para cada cliente e cada consulta concentra custo no respondedor. O RFC 9919 substitui o RFC 5019 e formaliza a alternativa: respostas pré-produzidas, mensagens menores, GET para pedidos curtos e cache em várias camadas.

Essa arquitetura produz duas avaliações chamadas de “frescor”. O HTTP decide se uma representação guardada pode ser usada novamente. O OCSP decide se uma afirmação de status, feita por uma autoridade, continua dentro do intervalo assinado. Expires, ETag e Cache-Control são úteis para distribuir tráfego, porém não entram na assinatura OCSP.

O próprio RFC alerta que valores de cabeçalho podem ser alterados. O cliente deve usá-los para orientar o cache e, no fim, confiar nos valores da OCSPResponse assinada. Um cache hit só informa de onde vieram os bytes. Não prova que o estado foi consultado novamente naquele momento.

O status precisa de três tempos e de um quarto relógio

thisUpdate registra quando o respondedor sabia que o estado estava correto. nextUpdate marca quando, ou antes de quando, haverá informação nova. producedAt é a hora em que a resposta foi assinada. O quarto relógio é o do cliente, usado para decidir se o momento atual cabe entre as duas fronteiras.

Para o perfil leve, nextUpdate é obrigatório. Sem ele, o cliente rejeita. Depois dele, a resposta está velha. Uma tolerância pequena pode compensar diferenças de sincronização, mas ela precisa ser definida localmente com base na precisão disponível e registrada para auditoria.

Relógio adiantado fecha a janela cedo demais e causa indisponibilidade. Relógio atrasado mantém a janela aberta e pode aceitar um good expirado quando uma resposta mais nova já diria revoked. A assinatura continua íntegra nos dois casos. Integridade dos dados e correção da hora são controles diferentes.

O nonce pode ligar pedido e resposta contra replay. O perfil, entretanto, precisa funcionar com validação temporal e orienta o cliente a não rejeitar apenas porque o nonce esperado está ausente nas condições previstas. Hora, intervalo, tolerância e comportamento de nonce devem aparecer no mesmo recibo de decisão.

max-age antecipa a renovação; nextUpdate encerra a prova

O RFC 9919 posiciona o max-age depois de thisUpdate e antes de nextUpdate. Assim, clientes começam a buscar uma substituição antes do fim assinado, e o respondedor deve renovar a resposta antes desse ponto. A população não retorna toda no mesmo segundo.

Isso é controle de carga, não extensão de autoridade. Um proxy pode mudar o envelope HTTP sem mudar o objeto assinado. Nenhum cabeçalho permite usar a resposta depois de nextUpdate. Se um intermediário insiste em servir uma cópia vencida, o cliente pode fazer nova requisição ignorando o cache; ele procura outro objeto, não revalida o antigo.

O mesmo vale quando a resposta é grampeada ao TLS. Há menos round trips e o cliente pode não precisar falar com o respondedor, mas o handshake não renova a resposta. CertID, assinante, status e intervalo permanecem próprios do OCSP.

good não é um selo de validade geral

O successful superior informa que a infraestrutura tem registros autoritativos para responder. O resultado de cada certificado é good, revoked ou unknown. São camadas distintas.

Segundo o RFC 6960, good significa minimamente que nenhum certificado com o serial consultado, dentro do seu período de validade, está revogado. Isso não garante que o certificado tenha sido emitido nem que a resposta tenha sido produzida durante a validade dele. Verificação do caminho, identidade, finalidade e autorização de aplicação continuam fora desse campo.

Antes do uso, o cliente confirma a correspondência do CertID, verifica a assinatura e a autorização do respondedor. O registro reproduzível deve guardar hash da resposta, assinante e cadeia, algoritmo, status, producedAt, thisUpdate, nextUpdate, hora local, offset, tolerância e nonce. Em trilha separada, guarda age, max-age, Expires, ETag, revalidação e bypass. A decisão da aplicação e o efeito real vêm depois.

O RFC 9919 também exige SHA-256 para hashes do emissor no CertID. Clientes antigos podem usar SHA-1 durante compatibilidade com o RFC 5019, mas devem migrar. A contagem de SHA-1 mostra dependência legada, não a correção da janela de status.

Fontes