Resumo

  • O RFC 9654 exige que um solicitante moderno produza nonce de pelo menos 32 octetos com gerador pseudoaleatório criptograficamente forte; o eco exato liga a resposta àquela requisição.
  • O vínculo reduz replay, mas não comprova sozinho a ingestão mais recente de revogação, a autoridade do signatário, o CertID correto, a janela temporal aceitável nem a autorização final do aplicativo.
  • Operação segura separa recibos de geração, codificação, transporte, eco, assinatura, delegação, identidade do certificado, tempos assinados, marca d’água da fonte e resultado da sessão.

Duas necessidades legítimas, um limite explícito

O problema não é escolher entre segurança e escala em abstrato. É registrar qual propriedade cada arquitetura entrega. Um nonce único por requisição dificulta que uma resposta anterior seja apresentada como a atual. Respostas pré-produzidas permitem cache, distribuição e capacidade previsível.

RFC 9654 define o primeiro mecanismo. O cliente inclui um nonce em requestExtensions; o respondente pode devolvê-lo em responseExtensions. Quando a resposta validada contém exatamente o mesmo valor imprevisível, ela fica criptograficamente ligada àquela pergunta.

O RFC 5019 organiza o segundo modelo para ambientes de grande volume. Ele desencoraja extensões por requisição quando elas impedem pré-produção e cache. Um respondente pode omitir o nonce, e um cliente sem prova de que o servidor o suporta não deve rejeitar apenas pela ausência; precisa aplicar o caminho de frescor temporal assinado.

Esses dois caminhos não devem ser mascarados por uma única métrica “OCSP OK”. Correspondência, ausência com fallback, divergência e mensagem malformada carregam garantias diferentes.

A faixa sintática não é a faixa obrigatória

O tipo Nonce admite de 1 a 128 octetos. O solicitante que implementa o RFC 9654 deve usar pelo menos 32. Um respondente que suporta a extensão deve aceitar entre 16 e 32. Para valores de 1 a 15 ou de 33 a 128, pode responder sem nonce. Zero ou mais de 128 exige malformedRequest.

A ampliação existe porque alguns algoritmos geram valores acima de 32 octetos. Ela não torna 128 a escolha universal. Implementações compatíveis apenas com o RFC 8954, cujo teto era 32, podem não processar valores maiores.

Uma matriz de teste séria inclui 16, 32, 33 e 128 octetos, além de zero e 129. Mede aceite com eco, aceite sem eco e rejeição. Assim, uma equipe sabe se depende da faixa interoperável ou de comportamento opcional.

O valor está dentro de outro valor

O RFC 9654 esclarece a codificação: o extnValue externo é um OCTET STRING que encapsula o Nonce, também OCTET STRING. O exemplo de 32 octetos mostra ambas as camadas. O OID é 1.3.6.1.5.5.7.48.1.2.

Essa distinção alcança o código. Uma biblioteca pode reconhecer o OID e comparar o contêiner com o conteúdo. Um log pode reter apenas uma representação parcial. Uma normalização textual pode esconder diferença nos octetos originais.

O recibo conserva DER completo da requisição e da resposta, seus hashes, posição da extensão, comprimentos externo e interno e igualdade byte a byte. O registro da IANA para módulos PKIX contém os identificadores 111 e 112 do RFC 9654; ele coordena a gramática, não atesta o parser carregado.

Sem imprevisibilidade, a igualdade engana

O nonce deve nascer de gerador pseudoaleatório criptograficamente forte, conforme RFC 4086. Se o próximo valor puder ser previsto, um adversário pode obter antes uma resposta com ele. Se o espaço for pequeno, pode pré-calcular respostas para todas as possibilidades.

Depois, a comparação ainda retorna verdadeiro. O que morreu foi a propriedade de desafio novo. Por isso, monitoramento começa antes do envio: classe e saúde do gerador, momento da geração, comprimento, repetição entre processos, estado após reinício e proteção do valor.

“Usamos 32 bytes” é evidência de formato. “Geramos valor novo e imprevisível para esta requisição” é evidência de segurança. A primazia do código em execução obriga a provar a segunda no sistema real.

A resposta nova pode carregar uma visão atrasada

O RFC 9654 afirma que o nonce devolvido assegura a resposta mais recente do servidor, e não uma cópia antiga. Isso descreve a relação com o servidor contatado. Não descreve automaticamente a idade da informação que chegou a ele.

O RFC 6960 separa producedAt, thisUpdate, nextUpdate e revocationTime. A assinatura pode ter sido criada agora enquanto o estado subjacente veio de uma réplica atrasada. O CertID ainda precisa corresponder ao emissor e ao serial do certificado pretendido.

Se uma CA publica revogação às 09:00 e a réplica OCSP recebe às 09:06, uma resposta dinâmica das 09:03 pode ecoar nonce novo, ter assinatura íntegra e expressar o estado que o servidor possui. A troca é nova; a fonte está atrasada. Provar atualidade da fonte exige cursor de ingestão, versão de lote, horário de aplicação ou recibo equivalente.

A assinatura também exige autoridade. Conforme RFC 6960, o signatário precisa ser a CA emissora, um respondente confiado diretamente ou um delegado autorizado com certificado apropriado. O nonce não cria essa delegação. O status good tampouco prova emissão, validade do certificado, identidade do serviço ou permissão de negócio.

O fallback precisa aparecer

Quando o nonce vem ausente, o cliente pode entrar no caminho temporal. O RFC 9654 reconhece que um atacante em rota pode devolver uma resposta anterior do servidor sem nonce. Uma janela curta entre thisUpdate e nextUpdate reduz o período útil do replay.

Isso não torna o fallback inválido por definição. Torna sua prova diferente. Ele depende de assinatura, autoridade, CertID, tempos assinados, relógio local e política de tolerância. Um sistema que oculta a troca de caminho impede o analista de saber qual controle estava ativo.

Relatórios devem separar: eco exato; ausência permitida e fallback aprovado; nonce diferente; erro de codificação ou tamanho. Cada classe continua até a decisão do aplicativo. Uma melhora na taxa global pode, na verdade, refletir mais fallback e menos vínculo.

Um recibo para cada realidade

Comece com impressão digital, serial e hashes do emissor do certificado alvo. Grave bytes da requisição, gerador, tempo, comprimento e hash protegido do nonce, além do destino. Na resposta, preserve bytes, estado geral, identificador do respondente, cadeia, autoridade e assinatura.

Em seguida, registre presença e igualdade do nonce, CertID, status e tempos. Quando possível, acrescente a marca d’água do feed de revogação. O cliente inclui relógio, incerteza, tolerância, versão do validador e política. O aplicativo encerra com caminho, identidade, admissão ou recusa e ação de sessão.

As camadas de realidade mantêm geração, transporte, vínculo, afirmação assinada, fonte, decisão local e efeito como fatos conectados, não substitutos. A especificação inicial mínima compartilha somente regras determinísticas indispensáveis, preservando escolhas de capacidade e risco com responsáveis visíveis.

Fontes