Como validar uma assinatura corretamente

Spec: RFC 5280, §6 Spec: RFC 6960 Spec: RFC 5652 Evidence: Test-backed

Visão geral

“A assinatura é válida” geralmente significa que apenas uma coisa foi verificada: a conta fechou. Uma validação correta verifica pelo menos cinco aspectos independentes, e qualquer um deles pode falhar de um jeito que torna sem sentido um sinal verde de aprovação. Esta página apresenta o conjunto completo de verificações e explica por que uma resposta parcial é perigosa.

Por que isso importa

Um único booleano é a saída mais perigosa em todo este tópico. Ele leva o leitor a tratar “válida” como “confiável”, quando “válida” pode significar apenas que os bytes não foram alterados — assinados com a chave de um certificado que expirou há três anos, foi revogado mês passado e não encadeia até nenhuma autoridade que você reconheça. Cada uma dessas coisas é uma verificação separada. Um software que reporta um único booleano decidiu silenciosamente quais verificações importavam e tomou essa decisão por você. Em um contexto regulado ou contratual, “a ferramenta disse que era válida” não é uma defesa se a ferramenta só verificou a propriedade mais barata.

A versão resumida

Uma validação completa responde a cinco perguntas separadas. Elas são independentes — passar em uma não diz nada sobre as outras:

Integridade — os bytes assinados ainda produzem o hash daquilo que a assinatura cobre? (Recalcule o digest do intervalo de bytes e compare.)
Autenticidade — a assinatura criptográfica é verificada corretamente contra a chave pública do certificado de assinatura, sobre os atributos assinados?
Caminho de certificação — esse certificado encadeia até uma âncora de confiança que você escolheu, com todos os elos válidos?
Tempo — o certificado estava dentro da sua janela de validade no momento relevante, e esse momento é confiável em vez de autoafirmado?
Revogação — o certificado não estava revogado naquele momento, segundo evidências (OCSP/CRL) que você consiga de fato obter ou que estejam embutidas?

Um resultado “válida” que não executou todas as cinco verificações é uma resposta incompleta que parece completa.

Como o NextPDF aborda isso

A postura do NextPDF é que cada pergunta permanece separada e deve ser respondida explicitamente. Nenhuma pergunta é reduzida a um único sinalizador otimista, e nenhuma é pulada silenciosamente porque uma verificação era inconveniente. Isso é garantido por testes. É por isso que esta página é marcada como apoiada por testes em vez de apoiada por padrão: o comportamento é mantido pela suíte, não apenas defendido a partir de uma cláusula.

Integridade e autenticidade são testadas de ponta a ponta. Um certificado conhecido assina uma estrutura real de atributos assinados, e a suíte verifica a assinatura com a chave pública correspondente, em múltiplos vetores de tempo. Assim, uma mudança que quebra a estrutura canônica também quebra o teste. A validação do caminho de certificação é sustentada por testes que adulteram deliberadamente um byte da assinatura e afirmam que o resultado não é válido, com um motivo estruturado — não uma exceção descartada, mas uma falha explícita registrada. A verificação do token de carimbo de tempo é dividida em etapas distintas — decodificação, informações do signatário, atributos assinados, digest da mensagem, vínculo do certificado, uso da chave, assinatura, produced-at — e cada etapa é testada isoladamente, de modo que “o carimbo de tempo foi verificado” significa que cada etapa foi verificada. A falha branda de revogação (um respondedor inacessível) é distinguida, no código e nos testes, de um “revogado” definitivo. Os dois nunca são confundidos na mesma resposta.

Integrity Recompute the byte-range digest and compare it to the value the signature covers.
Authenticity Verify the cryptographic signature against the certificate’s public key, over the signed attributes — not the raw content.
Certificate path Build and validate the chain to a trust anchor you chose; every link’s signature, validity, and constraints must hold.
Time Confirm the certificate was valid at the relevant instant, and that the instant is trusted time, not the signer’s clock.
Revocation Confirm the certificate was not revoked at that time, using obtainable or embedded OCSP/CRL evidence.

As cinco perguntas independentes que uma validação correta de assinatura PDF responde, em ordem. Cada uma é separada: passar em uma não diz nada sobre as outras, e pular qualquer uma torna o resultado geral incompleto.

O que as evidências dizem

Evidence: Test-backed O comportamento é ancorado em testes, e esses testes implementam o que os padrões exigem.

Integridade é Spec: ISO 32000-2, §12.8.1 : o digest é recalculado sobre o intervalo de bytes e comparado ao valor armazenado, e qualquer diferença significa que a assinatura é inválida. A autenticidade sobre os atributos assinados é coberta por um teste de integração que assina um conjunto real de atributos assinados e verifica a assinatura com a chave pública correspondente em vários vetores de tempo. A questão do caminho de certificação vem de Spec: RFC 5280, §6.1 : caminhos válidos começam a partir de uma âncora de confiança, e Spec: RFC 5280, §6.2 estabelece que esse algoritmo define as condições mínimas para que um caminho seja válido — um teste unitário do validador de caminho afirma que uma assinatura adulterada produz valid = false com um motivo explícito, nunca uma aceitação silenciosa.

A ordem correta para revogação vem de Spec: RFC 6960, §3.2 : antes de um cliente aceitar uma resposta de revogação assinada como válida, ele DEVE (SHALL) confirmar que a própria assinatura da resposta é válida e que o signatário está atualmente autorizado — e Spec: RFC 6960, §4.2.2.2 define essa autorização como uma delegação id-kp-OCSPSigning emitida diretamente pela CA em questão. Assim, uma resposta de revogação que não foi validada contra um signatário autorizado e verificável não tem valor. A verificação do vínculo do certificado é Spec: RFC 5035, §5.4.2 : se o hash do certificado no atributo assinado signing-certificate-v2 não corresponder ao certificado usado para verificar a assinatura, a assinatura deve ser considerada inválida. Isso fecha a brecha de substituição, em que uma assinatura é verificada corretamente contra um certificado escolhido por um atacante. O próprio token do carimbo de tempo é verificado no estilo Spec: RFC 5652 como um objeto CMS, passo a passo, com cada passo testado isoladamente.

Exemplo prático

A parte instrutiva não é uma chamada de API. São as perguntas às quais você precisa conseguir responder antes de agir com base em um resultado. Trate isto como a lista de verificação que uma revisão vai cobrar de você.

<?php

declare(strict_types=1);

// A correct validation produces a structured outcome, not one boolean.
// Before you trust a signature, you must be able to answer ALL of these:
//
//   integrity   : Does the byte-range digest still match? (tamper check)
//   authenticity: Does the signature verify over the SIGNED ATTRIBUTES,
//                  not just the content?
//   path        : Does the certificate chain to a trust anchor YOU chose,
//                  with every link valid at the relevant time?
//   time        : Is the relevant time TRUSTED (a timestamp), or merely the
//                  signer's self-asserted clock?
//   revocation  : Was the certificate not revoked at that time, by evidence
//                  you obtained or that the document embedded?
//
// "valid: true" without an answer to every line above is an incomplete
// result. A path-validation outcome carries a `valid` flag AND a structured
// `reasons` list precisely so a failure says WHY — never a bare false.

Se alguma linha tiver como resposta “não sei”, o status honesto não é “válida”. É “ainda não determinada” — e tratar as duas como a mesma coisa é o erro que esta página existe para evitar.

Equívoco comum

A armadilha é equiparar “criptograficamente válida” a “confiável.” Integridade e autenticidade juntas provam apenas que estes bytes foram assinados pelo detentor desta chave. Elas não dizem nada sobre se o certificado da chave era confiável, vigente ou não revogado. Um documento assinado com um certificado autogerado pode ser “criptograficamente válido” e não ter valor algum. A armadilha inversa é tratar uma verificação de revogação indeterminada (respondedor offline) como uma aprovação — ou como uma reprovação. Não é nenhuma das duas. É um resultado desconhecido, e um validador correto o reporta como desconhecido em vez de presumir uma direção. Um sinal verde de aprovação que esconde qual das cinco verificações realmente foi executada não é um resultado de validação. É uma decisão que outra pessoa tomou em seu nome.

Limites e fronteiras

O NextPDF executa e testa as verificações estruturais e criptográficas. Ele não escolhe suas âncoras de confiança nem garante a política sobre elas. Em quais certificados você confia é uma decisão de implantação que o engine não pode tomar. Uma cadeia que valida até uma âncora em que você não deveria ter confiado ainda é uma validação na qual você não pode confiar. A evidência de revogação só pode ser verificada se puder ser obtida ou estiver embutida. Um respondedor offline produz “indeterminado”, e transformar isso em um veredito é uma escolha de política, não do engine. Esta página descreve o conjunto de verificações, não a suficiência jurídica. Se uma assinatura validada tem um efeito jurídico específico depende do certificado, do signatário, da jurisdição e da obrigação. Como a evidência embutida mantém estas verificações respondíveis ao longo do tempo é tratado em Validação de longo prazo; o mecanismo de intervalo de bytes por trás da verificação de integridade está em Como as assinaturas ficam em um PDF.

Disponibilidade por edição da superfície de validação:

Signature validation checks — edition availability
Edition	Availability
Core	Integridade e autenticidade sobre atributos assinados, além da validação de caminho de certificação RFC 5280 §6 contra uma âncora de confiança fornecida.
Pro	Adiciona a verificação de token de carimbo de tempo RFC 3161 — a questão do tempo confiável, decomposta em etapas verificadas de forma independente.
Enterprise	Adiciona avaliação de revogação (OCSP/CRL) e validação contra material embutido de longo prazo, com resultados indeterminados distinguidos dos definitivos.

Documentos relacionados

Validação de longo prazo — como a evidência embutida permite responder às verificações de tempo e revogação anos depois.
Como as assinaturas ficam em um PDF — o mecanismo de intervalo de bytes que a verificação de integridade recalcula.
Carimbos de tempo e tempo confiável — o que torna a questão do “tempo” respondível com algo diferente do relógio do signatário.

Glossário

Verificação de integridade — recalcular o digest do intervalo de bytes e compará-lo ao valor que a assinatura cobre.
Verificação de autenticidade — verificar a assinatura criptográfica contra a chave pública do certificado de assinatura, sobre os atributos assinados.
Atributos assinados — os atributos CMS autenticados (content-type, message-digest, signing-time, signing-certificate-v2) sobre os quais a assinatura é efetivamente computada.
Validação de caminho de certificação — construir e verificar a cadeia desde o certificado de assinatura até uma âncora de confiança escolhida (RFC 5280 §6).
Âncora de confiança — uma autoridade certificadora em que você decidiu confiar; a raiz de um caminho aceitável.
Verificação de revogação — determinar se um certificado foi revogado no momento relevante, via OCSP ou uma CRL.
Indeterminado — um resultado de revogação que não é nem “bom” nem “revogado” porque a evidência não pôde ser obtida; não é aprovação nem reprovação.