Resumo

  • RFC 9919 exige nextUpdate; uma resposta sem esse campo ou usada depois do prazo assinado deve ser rejeitada.
  • A assinatura comprova integridade e autoria autorizada da resposta OCSP, mas não prolonga o estado good nem protege os cabeçalhos HTTP ao redor.
  • A auditoria precisa ligar os bytes assinados ao relógio, à tolerância, ao caminho de cache, à política do validador e à ação final da aplicação.

O objeto ainda era autêntico, mas a decisão já não cabia nele

Uma resposta OCSP armazenada pode atravessar clientes, proxies e sessões sem sofrer alteração. A assinatura confere. O campo de estado diz good. Mesmo assim, depois de nextUpdate, ela deixou de ter autoridade para uma nova decisão.

RFC 9919 trata de PKIs com altíssimo volume e de ambientes em que banda ou processamento são escassos. O perfil permite produzir respostas antecipadamente, diminuir mensagens, usar cache local e intermediário e transportar o estado dentro de outra troca, como o TLS. O objetivo é evitar que cada conexão dependa de uma geração em tempo real pelo respondedor.

A resposta portátil carrega seus próprios limites. thisUpdate marca o momento mais recente em que o estado era conhecido como correto. producedAt marca a assinatura. nextUpdate indica quando informação mais nova estará disponível. No perfil, este último campo é obrigatório. Sua ausência leva à rejeição; ultrapassá-lo também.

É uma separação de autoridade, não apenas de formato. A assinatura pode continuar matematicamente correta muito depois. Ela não transforma uma observação passada em autorização permanente. Entre a produção e a reutilização, o certificado pode ter sido revogado e outra resposta pode registrar a mudança.

good responde a uma pergunta estreita

RFC 6960 define good, revoked e unknown. O mínimo afirmado por good é que o respondedor não conhece como revogado um certificado com o número de série consultado e dentro do período de validade. Isso não prova necessariamente que o certificado foi emitido, nem resolve validade temporal do certificado, caminho de confiança, nome do serviço ou autorização da aplicação.

O cliente precisa correlacionar a resposta com o certificado certo, verificar a assinatura, confirmar que o assinante está autorizado pela CA relevante e avaliar a atualidade dos tempos assinados. Só depois o resultado entra na validação maior.

Um painel que resume tudo como “OCSP OK” apaga esses limites. Serviço disponível, resposta definitiva, assinatura válida, signatário autorizado, prazo vigente, certificado aceito e sessão aberta são eventos separados. Sem essa distinção, um incidente deixa de indicar qual controle realmente falhou.

O relógio do cliente passa a integrar a prova

Um nonce por solicitação atrapalha respostas pré-produzidas e cache compartilhado. Por isso RFC 9919 orienta que clientes não incluam normalmente extensões de pedido. Se um nonce for enviado e não voltar, o cliente em geral recorre à validação por tempo em vez de rejeitar apenas pela ausência, salvo quando sabe que o respondedor suporta nonce.

O cliente então deve dispor de hora precisa e garantir que o instante atual esteja entre thisUpdate e nextUpdate. Pode haver uma pequena tolerância para diferenças de relógio, escolhida conforme precisão e incerteza reais. Não existe uma margem universal gratuita.

Relógio adiantado rejeita cedo e causa indisponibilidade. Relógio atrasado pode aceitar um good vencido depois de uma revogação. O monitoramento deve registrar o tempo efetivamente usado pelo processo, sua fonte, deslocamento ou incerteza, a tolerância e saltos recentes. Saber que um daemon de sincronização está ativo não reproduz a decisão.

Cache HTTP e validade OCSP são dois controles

Solicitações pequenas usam GET para habilitar cache. O respondedor inclui Date, Last-Modified, Expires, ETag e Cache-Control. max-age ajuda a espalhar atualizações antes do nextUpdate; must-revalidate impede que um cache escolha servir conteúdo velho sem revalidar.

Esses cabeçalhos não estão cobertos pela assinatura OCSP. Eles orientam entrega e reutilização. A validade da afirmação sobre o certificado vem dos valores assinados. Um Expires posterior não estende nextUpdate, e uma classificação HTTP de “fresco” não substitui o teste feito pela aplicação.

Se um intermediário persistir em fornecer conteúdo vencido, o cliente pode repetir a consulta pedindo que o cache seja ignorado. O novo objeto ainda precisa passar por identificação, autorização do signatário, assinatura, estado e tempo. A origem da entrega não concede validade.

No stapling TLS, o servidor leva a resposta até o cliente e economiza uma conexão. Ele não vira autor do status. O cliente conserva o dever de verificar o prazo assinado.

SHA-256 é uma migração necessária, não uma absolvição

RFC 9919 substitui RFC 5019 e exige SHA-256 nos hashes do nome e da chave do emissor em CertID para clientes conformes. A retirada gradual de SHA-1 reduz complexidade de compatibilidade e superfície de implementação.

Mas um CertID com SHA-256 ainda pode acompanhar uma resposta vencida. Uma assinatura forte pode pertencer a um respondedor sem mandato para aquela CA. Uma distribuição correta pode chegar a um cliente com hora errada. A modernização do algoritmo precisa ser provada como etapa própria, não apresentada como aprovação da cadeia inteira.

Preservar um recibo reproduzível

O registro deve guardar impressão digital e serial do certificado, hashes de nome e chave do emissor e algoritmos, bytes exatos e hash da resposta, identificador do respondedor, cadeia e autorização do assinante, producedAt, thisUpdate, nextUpdate, status e campos de revogação.

Também deve guardar a hora local usada, fonte e incerteza, tolerância, tratamento do nonce, versão e política do validador, motivo de aceitar ou rejeitar e ação posterior da aplicação. Nó de cache, Age, ETag, Expires, tentativa sem cache e resultado pertencem ao histórico de entrega, não à afirmação assinada.

Assim, cada camada preserva seu papel: HTTP mostra a chegada; OCSP assinado mostra o que um respondedor autorizado afirmou e por quanto tempo; o log local mostra a decisão; a aplicação mostra o efeito. Um contador de sucesso não prova nenhuma dessas ligações sozinho.

Fontes