Verificação de assinatura: AdES / PAdES no lado de verificação criptográfica

Visão geral

NextPDF Enterprise verifica assinaturas digitais criptograficamente. O lado verificador lê do PDF o Cryptographic Message Syntax (CMS) SignedData ou um token de carimbo de tempo Request for Comments (RFC) 3161, recalcula os digests, confere as assinaturas, vincula cada assinatura ao respectivo certificado de assinatura e valida a cadeia de certificados, incluindo o processamento de políticas de certificado, contra um armazenamento de âncoras de confiança fornecido pelo chamador. Esta página descreve o comportamento. Ela declara o que é verificado, o que é rejeitado de forma fail-closed, quais algoritmos são suportados e onde está a fronteira de confiança.

Isso é distinto de Validação, que executa verificações de política estruturais e de somente leitura, deliberadamente sem realizar criptografia. Também é a contraparte, no lado verificador, do produtor de assinaturas, que grava estruturas PDF Advanced Electronic Signatures (PAdES) B-LT / B-LTA.

Instalação

composer require nextpdf/enterprise:^3

Visão geral conceitual

A verificação se baseia em evidências e é fail-closed: uma verificação que não pode ser estabelecida positivamente não produz resultado positivo. Os componentes abaixo compõem um único resultado carregado por um ValidationReport.

Verificação criptográfica de CMS / token de carimbo de tempo. Uma pilha DER estrita, autocontida e de comprimento definido analisa o CMS SignedData e o token de carimbo de tempo RFC 3161. Um token é aceito somente quando carrega exatamente um SignerInfo, seus atributos assinados são analisados de forma estrita, o certificado do signatário é resolvido, o atributo message-digest coincide com o digest recalculado, o vínculo obrigatório com o certificado de assinatura (ESS signing-certificate-v2) é confirmado, e a assinatura do SignerInfo é verificada sobre os atributos assinados re-etiquetados. A regra de correspondência do digest segue o modelo de verificação do RFC 5652 §5.6 / §5.4: o destinatário recalcula o message digest do conteúdo, e a assinatura só é válida quando esse valor é igual ao atributo assinado messageDigest. Um verificador nunca confia em um digest fornecido pelo produtor.

Validação do certificado da TSA no genTime. O genTime do carimbo de tempo é o instante UTC em que o token foi criado (RFC 3161 §2.4.2). O certificado de assinatura da TSA é validado naquele instante, não no “agora”: seu uso estendido de chave deve ser um único id-kp-timeStamping crítico (RFC 3161 §2.3), e sua janela de validade, cadeia, procedência da âncora de confiança e revogação são avaliadas em relação ao genTime. Uma cadeia estruturalmente bem formada que não alcança uma âncora de confiança configurada nunca pode sustentar um resultado positivo.

Assinaturas de documento básicas PAdES destacadas. Um extrator concreto realiza a verificação básica real de Advanced Electronic Signatures (AdES) / PAdES para uma assinatura de documento destacada: o message digest é recalculado sobre o intervalo de bytes assinado e comparado, a assinatura é verificada, e o vínculo com o certificado de assinatura é obrigatório. Isso substitui o fallback somente estrutural anterior. O verificador de carimbo de tempo e o extrator de assinatura de documento compartilham um único validador ESS de emissor e número de série, de modo que a análise do vínculo de certificado não pode divergir.

Cadeia de cobertura DocTimeStamp de arquivamento. O validateArchivalTimestampChain() valida uma cadeia de tokens DocTimeStamp confiáveis sobre os intervalos de bytes do PDF como evidência de arquivamento B-LTA. A impressão (imprint) de cada token é vinculada aos bytes reais do ByteRange que ele cobre, a cadeia segue a ordenação estrita da ETSI, a cadeia TSA de cada token é ancorada em confiança, e a cadeia deve cobrir o arquivo até seu marcador de fim de arquivo. O resultado só é totalmente aprovado para uma cadeia completa, ancorada em confiança e que cobre até o EOF.

Processamento de políticas de certificado (RFC 5280 §6.1.4). A validação de caminho aplica o processamento completo de políticas de certificado: uma árvore de políticas estruturada em nós, mapeamento de políticas com fallback anyPolicy e dobramento de policyConstraints / inhibitAnyPolicy, com apoio de um leitor DER fail-closed para extensões de política. As variáveis de estado do processamento de caminho explicit_policy e inhibit_anyPolicy (RFC 5280 §6.1.2) determinam se uma árvore de políticas válidas não vazia é exigida; a etapa de encerramento faz a interseção da árvore de políticas válidas com o user-initial-policy-set (RFC 5280 §6.1.4). Sem políticas exigidas e com anyPolicy aceito, o processamento é irrestrito; esse é o padrão e não muda em relação ao comportamento anterior.

Algoritmos suportados

O lado verificador aceita o conjunto de algoritmos abaixo e falha em modo fail-closed para qualquer coisa fora dele: um algoritmo não suportado é uma verificação rejeitada, nunca uma aprovação silenciosa.

Família	Suportado	Notas
RSA (PKCS#1 v1.5)	`rsaEncryption` com SHA-2, e os `sha*WithRSAEncryption` OIDs	Aceito
ECDSA	curvas P-256, P-384, P-521	Aceito
RSASSA-PSS	—	Não suportado → fail-closed
EdDSA	—	Não suportado → fail-closed
Digests SHA-3	—	Não suportado → fail-closed
SHA-1	—	Fraco: uma assinatura básica que verifica sob SHA-1 é rebaixada para uma falha de crypto-constraints, não uma aprovação

Superfície de API

Você usa o lado verificador por meio do engine público e dos contratos Core / Pki. As classes de estratégia concretas são internas.

Tipo	Categoria	Função
`AdESValidationEngine`	classe	O ponto de entrada do lado verificador: validação de assinatura e de cadeia de arquivamento.
`AdESValidationEngine::validateArchivalTimestampChain()`	método	Valida uma cadeia de cobertura DocTimeStamp confiável sobre os intervalos de bytes do PDF.
`ValidationReport`	resultado	O resultado estruturado: status geral mais constatações por verificação.
`PathValidatorInterface`	interface (`NextPDF\…\Pki`)	A SPI de validação de caminho de certificação da qual o engine depende.
`PathValidationOptions`	objeto de valor	Controles de processamento de políticas: `requireExplicitPolicy`, `inhibitAnyPolicy`, `inhibitPolicyMapping`, `maxPolicyFanout`.
`TrustAnchorStoreInterface`	interface	O conjunto de âncoras confiáveis fornecido pelo chamador contra o qual a cadeia é avaliada.

O método de cadeia de arquivamento tem esta assinatura:

public function validateArchivalTimestampChain(
    string $pdfBytes,
    array $dssData = [],
    ?TrustAnchorStoreInterface $anchors = null,
): ValidationReport;

O método alcança um resultado totalmente aprovado somente quando a cadeia DocTimeStamp é completamente verificada, ancorada em confiança e cobre o arquivo até seu marcador EOF.

CertificateChainValidator::validate() recebe um conjunto de políticas iniciais (o RFC 5280 user-initial-policy-set). O padrão é anyPolicy, que é irrestrito, de modo que uma cadeia comum não é afetada. Passe um conjunto explícito ou defina requireExplicitPolicy para exigir uma árvore de políticas válidas não vazia.

Exemplo de código — Início rápido

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;

$report = $engine->validateArchivalTimestampChain($pdfBytes, [], $trustAnchors);

if ($report->isTotalPassed()) {
    // A complete, trust-anchored, EOF-covering DocTimeStamp chain.
}

Exemplo de código — Produção

use NextPDF\Enterprise\Security\Validation\AdESValidationEngine;
use Psr\Log\LoggerInterface;

final readonly class ArchivalEvidenceCheck
{
    public function __construct(
        private AdESValidationEngine $engine,
        private LoggerInterface $logger,
    ) {}

    public function check(string $pdfBytes, TrustAnchorStoreInterface $anchors): bool
    {
        $report = $this->engine->validateArchivalTimestampChain($pdfBytes, [], $anchors);

        foreach ($report->findings as $finding) {
            $this->logger->info('archival.finding', [
                'check'  => $finding->checkId,
                'status' => $finding->status->value,
            ]);
        }

        // A positive result proves byte-range coverage by a trusted timestamp
        // chain — it is one input to your decision, not a legal conclusion.
        return $report->isTotalPassed();
    }
}

Mudanças de comportamento e notas de atualização

O lado verificador passou da aceitação estrutural / temporal para a verificação criptográfica completa. Se você depende do comportamento anterior, mais permissivo, revise estas mudanças.

Fail-closed em um carimbo de tempo reconhecível-mas-inverificável. Um DocTimeStamp ou token de arquivamento que anteriormente era aprovado por motivos estruturais e temporais agora exige verificação criptográfica completa: assinatura, message-digest e o vínculo com o certificado de assinatura. Um token que não é verificado deixa de produzir uma prova-de-existência positiva; ele mapeia para um resultado indeterminado ou falho.
Assinaturas básicas SHA-1 são rebaixadas, não aprovadas. Uma assinatura de documento básica que é verificada, mas usa SHA-1, é reportada como uma falha de crypto-constraints em vez de uma aprovação completa.
O processamento de políticas de certificado do RFC 5280 §6.1.4 é imposto. Uma cadeia cujo explicit_policy chega a zero com uma árvore de políticas válidas vazia agora falha, inclusive quando um policyConstraints requireExplicitPolicy interno à cadeia o exige. Cadeias padrão, irrestritas (sem políticas exigidas, anyPolicy aceito) não são afetadas.
Mudança na assinatura do construtor (quebra de compatibilidade). O AdESValidationEngine::__construct() agora declara o tipo do parâmetro $chainValidator como a SPI Pki\PathValidatorInterface, com padrão definido sob demanda como Pki\CertificateChainValidator::withDefaults(). Anteriormente, era a classe concreta Ltv\CertificateChainValidator. Um chamador que injetava o validador LTV concreto deve injetar a implementação da SPI Pki em vez disso. O validador Pki encapsula o mesmo engine estrutural de caminho e adiciona restrições de nome e processamento de políticas; é um no-op para entradas padrão conformes.

Casos extremos e pegadinhas

Algoritmo não suportado ≠ inconclusivo. RSASSA-PSS, EdDSA e SHA-3 são rejeitados de forma fail-closed, não adiados. Se seus signatários os usam, este lado verificador não retornará um resultado positivo.
A confiança é relativa à âncora. A verificação é sempre relativa ao armazenamento de âncoras de confiança que você fornece. Um conjunto de âncoras vazio ou errado produz um resultado não confiável, independentemente da correção criptográfica.
genTime, não agora. O certificado da TSA é julgado no genTime do token. Um certificado de TSA que desde então expirou ainda pode sustentar um token criado enquanto ele era válido; um certificado ainda não válido no genTime não pode.
Cobertura até o EOF. A cadeia de arquivamento deve cobrir o documento até seu marcador EOF. Um carimbo de tempo que cobre apenas um prefixo do arquivo não estabelece cobertura do documento inteiro.
Não comprovadamente revogado não é Good. Um veredito Valid exige um status conclusivamente não revogado. Se tanto OCSP quanto CRL retornarem Unknown ou Unavailable, até mesmo uma assinatura criptograficamente sólida, com cadeia válida e ancorada em confiança, resolve para Indeterminate. Forneça material Good OCSP/CRL embutido para que a validação do certificado do signatário alcance Valid.

Desempenho

A verificação é executada em processo sobre os bytes do PDF fornecidos e o material de validação embutido; o custo escala com o comprimento da cadeia e o número de carimbos de tempo. A verificação não faz nenhum round trip de rede. O material de revogação e de confiança vem do que o chamador fornece ou do que está embutido no documento. A verificação é determinística: as mesmas entradas e as mesmas âncoras de confiança produzem o mesmo relatório.

Notas de segurança

Fail-closed é o padrão. Toda etapa de aceitação recusa material que não pode ser verificado positivamente. Isso impede que um documento anuncie uma validade que o engine nunca estabeleceu.
Append-após-carimbo-de-tempo é neutralizado pela cobertura até o EOF. Como a impressão (imprint) de cada carimbo de tempo de arquivamento é vinculada aos bytes reais do ByteRange e a cadeia deve alcançar o EOF, o conteúdo anexado após um carimbo de tempo não é coberto por ele e não ganha seu peso probatório.
Trate a entrada como hostil. Bytes de PDF, CMS embutido e tokens de carimbo de tempo de fontes não confiáveis são analisados por um leitor DER estrito de comprimento definido que rejeita codificações malformadas ou de comprimento indefinido.

Residência de dados e mitigações de PII

A verificação é local e em processo, sem nenhuma E/S de rede. Certificados e assinaturas carregam a identidade do sujeito; aplique seus próprios controles de retenção e minimização aos relatórios e a quaisquer dados de certificado extraídos.

Telemetria segura e limpeza de logs

As constatações carregam identificadores de verificação e status. Alguns diagnósticos podem repetir nomes de sujeito de certificado ou números de série; limpe ou redija esses campos antes de encaminhar logs para destinos compartilhados.

Fronteiras de escopo

Declare estas fronteiras na saída voltada ao usuário para que um resultado positivo não seja lido em excesso.

O validateArchivalTimestampChain() prova cobertura de intervalo de bytes, não alcançabilidade de xref. Ele estabelece que uma cadeia de carimbo de tempo confiável cobre criptograficamente os intervalos de bytes do documento até o EOF. Ele não realiza análise de alcançabilidade de objetos em nível de xref ou startxref; isso está fora de escopo por design. A regra de cobertura até o EOF, junto com a ancoragem de confiança, neutraliza ataques de append-após-carimbo-de-tempo, não a análise de grafo de objetos.
Fora de escopo por design. Registros de Evidência (RFC 4998 / RFC 6283); verificação de tokens de carimbo de tempo RSASSA-PSS, EdDSA ou SHA-3; integração com lista confiável (TSL) e TSA qualificada; e busca online de revogação de TSA não são fornecidos por este lado verificador. A revogação é avaliada a partir de material já disponível para o verificador.

Conformidade

Comportamento	Referência	Status
Valor da assinatura / token de carimbo de tempo armazenado em DER em `/Contents`	ISO 32000-2 §12.8.1	Analisado e verificado
Dicionário de carimbo de tempo de documento	ISO 32000-2 §12.8.5	Lido para a cadeia de arquivamento
O destinatário recalcula o digest do conteúdo; ele deve ser igual ao atributo messageDigest	RFC 5652 §5.6 / §5.4	Imposto
TSA carrega um único `id-kp-timeStamping` EKU crítico	RFC 3161 §2.3	Verificado no genTime
genTime é o instante UTC de criação	RFC 3161 §2.4.2	Usado como o instante de validação
Variáveis de estado do processamento de políticas (`explicit_policy`, `inhibit_anyPolicy`)	RFC 5280 §6.1.2	Processado
O encerramento intersecta a árvore de políticas válidas com o user-initial-policy-set	RFC 5280 §6.1.4	Imposto
DSS entradas e carimbos de tempo de documento para assinaturas de longo prazo	ETSI EN 319 142-2 §5.5	Validado como evidência de arquivamento

Todas as cláusulas são parafraseadas. NextPDF não reproduz texto normativo; consulte os padrões publicados para a redação oficial. O NextPDF não faz nenhuma reivindicação de certificação AdES / PAdES. O lado verificador implementa as verificações criptográficas descritas pelas especificações citadas; ele não é um serviço de validação certificado e não produz nenhuma atestação de terceiros.

Comportamento no modo FIPS

Quando o perfil FIPS do Enterprise está ativo, a restrição se aplica aos algoritmos de digest e de assinatura que o verificador aceita. A lógica de verificação, incluindo o recálculo de digest, as verificações de assinatura, o vínculo de certificado e a validação de caminho, é inalterada.

Modelo de ameaças

Ativo	Adversário	Risco	Mitigação
Token de carimbo de tempo	Token forjado ou alterado	Uma prova-de-existência falsa	Verificação criptográfica completa; fail-closed em qualquer coisa inverificável
Certificado da TSA	Emissor não confiável	Confiança aparente que o verificador não deveria afirmar	Cadeia validada até uma âncora fornecida pelo chamador no genTime; cadeia não confiável nunca é aprovada
Bytes do documento	Append-após-carimbo-de-tempo	O conteúdo ganha o peso de um carimbo de tempo sem cobertura	Impressão (imprint) vinculada aos bytes reais do ByteRange + regra de cobertura até o EOF
Algoritmo fraco	Rebaixamento para SHA-1 / esquema não suportado	Uma assinatura fraca interpretada como válida	SHA-1 rebaixado; RSASSA-PSS / EdDSA / SHA-3 fail-closed

Gate de edição

Este lado verificador é uma capacidade do Enterprise e é distribuído no pacote nextpdf/enterprise. NextPDF Core detecta a presença de assinatura e produz assinaturas B-B / B-T, mas não fornece este lado verificador criptográfico. Obtenha uma licença.

Flag de recurso de licença

O lado verificador é restrito à edição Enterprise (license_feature_flag: enterprise). Ele é resolvido por meio dos contratos Core e Pki; a interface pública de programação de aplicações (API) não muda em uma atualização de edição.

Contrato de comportamento

Um CMS ou token de carimbo de tempo é aceito somente com exatamente um SignerInfo, atributos assinados analisados de forma estrita, um certificado do signatário resolvido, um message-digest coincidente, o vínculo obrigatório com o certificado de assinatura e uma assinatura SignerInfo que verifica.
O certificado da TSA é validado no genTime do token: um único id-kp-timeStamping EKU crítico, janela de validade, cadeia ancorada em confiança e revogação.
Um veredito Valid exige adicionalmente um status conclusivamente não revogado: ao menos um Good autoritativo (uma resposta OCSP verificada como Good, ou uma CRL recente que deixe o número de série fora de uma lista não expirada). Um status meramente não comprovadamente revogado, em que OCSP e CRL são ambos Unknown ou Unavailable, resolve para Indeterminate, nunca Valid (ETSI EN 319 102-1: status de revogação indisponível → INDETERMINATE). Como o caminho de fallback de CRL atesta apenas a atualidade da lista e não a revogação por número de série, uma cadeia somente-CRL sem um OCSP Good é comumente Indeterminate.
validateArchivalTimestampChain() alcança um resultado totalmente aprovado somente para uma cadeia DocTimeStamp completa, ancorada em confiança e que cobre até o EOF; ele prova cobertura de intervalo de bytes, não alcançabilidade de xref.
O processamento de políticas de certificado segue o RFC 5280 §6.1.4; cadeias padrão irrestritas não são afetadas.
Os algoritmos suportados são RSA (PKCS#1 v1.5 com SHA-2) e ECDSA (P-256/384/521); RSASSA-PSS, EdDSA e SHA-3 falham em modo fail-closed; SHA-1 é rebaixado.

Status da varredura de NDA

Esta página pública descreve apenas o comportamento externamente observável do lado verificador. Ela nomeia o engine público, os contratos Pki / âncora-de-confiança e o método validateArchivalTimestampChain() por meio da superfície suportada. Os componentes internos concretos de DER, CMS, processador de políticas e validador de caminho estão na referência profunda restrita, sob o acordo de não divulgação (NDA).

Fallback do Core

NextPDF Core detecta a presença de uma assinatura e produz assinaturas B-B / B-T, mas não verifica criptograficamente CMS ou tokens de carimbo de tempo, não valida uma cadeia de arquivamento nem executa o processamento de políticas do RFC 5280 §6.1.4. Uma implantação somente-Core não tem lado verificador equivalente; consulte Segurança / Assinatura (Core).

Fallback do Pro

NextPDF Pro adiciona estratégias de assinatura e tratamento de e-invoice, mas não fornece este lado verificador criptográfico; a validação de cadeia de arquivamento e o processamento de políticas de certificado são distribuídos apenas no nextpdf/enterprise.

Nota de fronteira do Enterprise

O lado verificador é descrito no nível de comportamento. A pilha DER estrita, o analisador CMS, o processador de políticas e os componentes internos do validador de caminho estão fora de escopo para a superfície pública e não são reproduzidos aqui.

Fronteira de implantação

A verificação depende do armazenamento de âncoras de confiança e de qualquer material de revogação que o chamador fornece ou que esteja embutido no documento. NextPDF Enterprise avalia esse material; ele não opera uma lista de confiança, uma TSA nem um serviço de revogação. O operador é responsável pela seleção de âncoras e pela atualidade do material de revogação embutido.

Fronteira de conformidade legal

Esta página está marcada como export_control_class: legal-review-required; ela diz respeito à verificação criptográfica. A aprovação jurídica é necessária antes que o flag publish seja definido. Um resultado de verificação positivo é uma afirmação criptográfica sobre as assinaturas e os carimbos de tempo do documento. Ele não é um parecer jurídico, uma determinação de qualificação eIDAS nem uma certificação. O NextPDF não faz nenhuma reivindicação de certificação AdES / PAdES. Consulte seus próprios assessores de conformidade e jurídicos para suas obrigações regulatórias.

Veja também

Assinatura: produtor PAdES B-LT / B-LTA — o lado produtor.
Validação — verificações de política estruturais em processo (sem criptografia).
Arquivo: DSS, VRI, saúde de LTV — arquivamento de longo prazo e saúde de LTV.
Segurança / Assinatura (Core) — CMS, RFC 3161, RFC 5280 validação de caminho, OCSP/CRL.
PAdES mapeamento baseline — B-B, B-T, B-LT, B-LTA entre edições.
PAdES · DSS · LTV — termos do glossário.