Validação de assinaturas em lote

Visão geral

O NextPDF Enterprise valida assinaturas digitais em muitos documentos PDF em uma única chamada. NextPDF\Enterprise\Signature\BatchSignatureValidator::validate() recebe uma lista de documentos e retorna um BatchValidationReport. Cada assinatura passa pelo mesmo pipeline fail-closed: autenticação criptográfica CMS sobre o intervalo de bytes assinado, validação da cadeia de certificados ancorada em confiança e verificação de revogação OCSP/CRL. O relatório carrega detalhes por documento e por assinatura — CertChainStatus, RevocationStatus, TimestampStatus — para que as ferramentas de conformidade possam re-derivar cada veredicto a partir das evidências registradas.

O modelo de veredicto é deliberadamente rigoroso. Uma assinatura é Valid somente quando toda evidência é estabelecida de forma afirmativa. Evidência de revogação ausente resulta em Indeterminate, nunca em Valid. Esta página cobre o orquestrador de lote e seus tipos de resultado. O lado de verificação AdES de documento único está documentado em Verificação de assinaturas. A incorporação de material de validação de longo prazo está documentada em Arquivamento.

Disponibilidade e licenciamento

Este recurso é entregue no NextPDF Enterprise (nextpdf/enterprise) e é ativado com um envelope de licença de nível Enterprise. Uma implantação sem esse direito não carrega as classes do recurso. Compare as edições e obtenha uma licença.

Instalação

composer require nextpdf/enterprise

O metapacote nextpdf/premium também resolve o pacote Enterprise. A ativação usa o seu envelope de licença Enterprise; consulte Licenciamento e ativação. Os tipos de lote fazem autoload sob NextPDF\Enterprise\Signature. Nenhuma extensão PHP além da linha de base do engine é necessária.

Visão conceitual

Uma chamada a validate() processa uma lista de valores DocumentSignatureInput. Cada entrada carrega um identificador de documento, os bytes brutos do PDF e âncoras de confiança opcionais codificadas em PEM. O validador extrai os dicionários de assinatura de cada documento e executa três estágios por assinatura.

Estágio 1 — autenticação criptográfica. O blob CMS/PKCS#7 destacado de /Contents é verificado sobre os bytes que /ByteRange cobre. O verificador recomputa ele próprio o digest do conteúdo e o compara com o atributo assinado messageDigest. Ele nunca confia em um digest fornecido pelo produtor (RFC 5652 §5.6). O valor da assinatura precisa verificar, e o certificado de assinatura precisa estar vinculado ao CMS. /Contents ou /ByteRange ausentes ou malformados, um CMS não analisável, uma divergência de digest ou uma verificação de assinatura falha resultam todos em fail closed. Uma assinatura que verifica sob SHA-1 é tratada como fraca e nunca é uma aprovação completa.

Estágio 2 — validação da cadeia e ancoragem de confiança. A cadeia do signatário recuperada do CMS é validada como o caminho de certificação prospectivo. Os trustedCerts que você fornece são a entrada de âncora de confiança, no sentido do RFC 5280 §6.1.1: o término da cadeia precisa corresponder a uma âncora fornecida pela impressão digital DER SHA-256. Uma cadeia estruturalmente consistente cujo término não é uma âncora configurada nunca é reportada como confiável. Sem âncoras utilizáveis, apenas o veredicto estrutural é reportado, e CertChainStatus::$trusted permanece false.

Estágio 3 — revogação. A revogação é executada sobre a cadeia recuperada após a autenticação, espelhando o modelo do ETSI EN 319 102-1 em que a verificação de revogação segue a validação de caminho bem-sucedida (cláusula 5.2.6.2). O OCSP é primário: somente uma resposta verificada criptograficamente conta, como Good ou Revoked. O caminho da CRL é o fallback e atesta a atualidade da lista. Quando nenhum cliente está configurado, o status é unavailable.

O veredicto por assinatura é um SignatureValidationStatus. A taxonomia espelha o modelo de status do ETSI EN 319 102-1 (TOTAL-PASSED / TOTAL-FAILED / INDETERMINATE) na granularidade por assinatura:

Evidência	Veredicto
Certificado confirmado como revogado	Invalid (decisivo, independentemente de outras verificações)
Autenticação CMS falhou, nenhum material do signatário recuperado	Error
Autenticação CMS falhou, material do signatário presente	Invalid
Autenticado, mas a cadeia não valida	Invalid (ou Error sem cadeia)
Autenticado e cadeia válida, mas sem âncora de confiança confirmada	Indeterminate
Autenticado, cadeia válida, confiável, mas sem não-revogação conclusiva	Indeterminate
Tudo o que precede estabelecido de forma afirmativa	Valid

A regra da não-revogação conclusiva. “Não provado como revogado” não é o mesmo que “provado como não revogado”. Um veredicto Valid requer ao menos um resultado de revogação Good. Uma resposta OCSP verificada como boa é a forma conclusiva: ela atesta o status do próprio certificado do signatário. Uma CRL aceita criptograficamente e atualizada também satisfaz o portão nesta implementação, mas apenas como um atestado de atualidade e integridade — o caminho não analisa entradas por número de série, então não fornece garantia de revogação por número de série e nunca um veredicto positivo de revoked. Configure OCSP onde quer que a detecção positiva de revogação importe: uma implantação apenas com CRL não sinalizará um certificado revogado como Invalid. Quando ambos os resultados OCSP e CRL são Unknown ou Unavailable, o status de revogação é indeterminado, e o veredicto é Indeterminate. Isso segue o ETSI EN 319 102-1: informação de status de revogação indisponível resulta em INDETERMINATE, nunca em uma aprovação (cláusula 5.1.3, TRY_LATER). Este é um endurecimento de comportamento na 3.1.0 com impacto na compatibilidade retroativa: versões anteriores podiam reportar Valid sem evidência de revogação conclusiva. Implantações que não configuram nenhum cliente OCSP ou CRL agora veem comumente Indeterminate onde antes viam Valid.

Dois limites enquadram este recurso honestamente. Primeiro, o validador de lote não avalia tokens de carimbo de tempo incorporados: TimestampStatus em resultados de lote é sempre o estado ausente. A avaliação de carimbo de tempo RFC 3161 pertence ao lado de verificação de documento único; consulte Verificação de assinaturas. Segundo, esta página trata de validação somente leitura. A incorporação de material DSS/VRI para validade de longo prazo é o recurso de Arquivamento.

Por que funciona desta forma

A decisão de sustentação é um produtor de veredicto fail-closed. Valid é emitido somente a partir de evidência afirmativa em todos os três eixos: autenticação criptográfica, uma cadeia ancorada em confiança e não-revogação conclusiva. Qualquer coisa não estabelecida rebaixa para Indeterminate em vez de assumir por padrão uma aprovação, que é a postura do EN 319 102-1 para material de revogação ausente. A taxa de processamento em lote nunca recompra rigor: a camada de lote é orquestração sobre o mesmo verificador CMS auditado usado para um único documento, portanto uma execução de 1.000 documentos aplica criptografia idêntica. O relatório também separa evidência de veredicto — CertChainStatus e RevocationStatus registram as entradas sobre as quais cada veredicto se apoia, para que um auditor possa re-derivá-lo depois.

Contexto de projeto: Assinatura em escala, sem concessões.

Superfície da API

Todos os símbolos abaixo são API pública em nextpdf/enterprise 3.1.0.

BatchSignatureValidator

final class BatchSignatureValidator
{
    public function __construct(
        ?SignatureExtractor $extractor = null,
        ?CertificateChainValidator $chainValidator = null,
        private readonly ?OcspClient $ocspClient = null,
        private readonly ?CrlFetcher $crlFetcher = null,
        ?CmsSignatureDataExtractor $cmsExtractor = null,
        private readonly ClockInterface $clock = new SystemClock(),
    )

    public function validate(array $inputs): BatchValidationReport
}

Lança ou falha com: validate() lança \InvalidArgumentException se a lista de entrada estiver vazia, e \OverflowException quando o lote excede 1.000 documentos. Um documento que não é um PDF analisável não lança; ele se torna um resultado Error por documento. O $clock é um Psr\Clock\ClockInterface PSR-20 usado para a decisão de atualidade da CRL, de modo que os veredictos são determinísticos sob um relógio de teste congelado.

DocumentSignatureInput

final readonly class DocumentSignatureInput
{
    public string $documentId;

    public function __construct(
        string $documentId,
        public string $pdfData,
        public array $trustedCerts = [],
    )
}

Lança ou falha com: \InvalidArgumentException se $documentId for uma string vazia. $trustedCerts é uma lista de certificados de âncora de confiança codificados em PEM.

BatchValidationReport

final readonly class BatchValidationReport
{
    public function __construct(
        public array $documents,
        public int $totalDocuments,
        public int $totalSignatures,
        public int $totalValid,
        public int $totalInvalid,
        public float $durationMs,
    )

    public function allValid(): bool

    public function hasDocumentsWithoutSignatures(): bool

    public function toJson(?CertPiiGuard $piiGuard = null): string
}

Lança ou falha com: toJson() lança \JsonException se a codificação falhar. allValid() é true somente quando há assinaturas e nenhuma é não-válida. Por padrão, toJson() aplica um NextPDF\Enterprise\Signature\Eidas\CertPiiGuard com privacidade por padrão, que mascara o nome do signatário, o emissor raiz, o nome da TSA e os diagnósticos de problemas da cadeia; consulte Níveis de garantia eIDAS para a API do guard.

DocumentValidationResult e DocumentValidationStatus

final readonly class DocumentValidationResult
{
    public function __construct(
        public string $documentId,
        public DocumentValidationStatus $status,
        public array $signatures,
        public int $validCount,
        public int $invalidCount,
    )

    public function hasSignatures(): bool

    public function totalSignatures(): int
}

enum DocumentValidationStatus: string
{
    case AllValid = 'all_valid';
    case SomeInvalid = 'some_invalid';
    case AllInvalid = 'all_invalid';
    case NoSignatures = 'no_signatures';
    case Error = 'error';
}

Lança ou falha com: nada. Objeto de valor imutável e enum apoiado.

SignatureValidationResult e SignatureValidationStatus

final readonly class SignatureValidationResult
{
    public function __construct(
        public SignatureValidationStatus $status,
        public CertChainStatus $certChain,
        public TimestampStatus $timestamp,
        public RevocationStatus $revocation,
        public string $signer,
        public string $level = '',
        public string $subFilter = '',
        public string $reason = '',
    )

    public function isValid(): bool
}

enum SignatureValidationStatus: string
{
    case Valid = 'valid';
    case Invalid = 'invalid';
    case Indeterminate = 'indeterminate';
    case Error = 'error';
}

Lança ou falha com: nada. $signer é o assunto do certificado verificado pelo CMS quando a autenticação passou, caso contrário a string vazia. $level é um rótulo derivado do SubFilter (por exemplo B-B para ETSI.CAdES.detached), não uma determinação de conformidade AdES.

CertChainStatus

final readonly class CertChainStatus
{
    public function __construct(
        public bool $valid,
        public bool $trusted,
        public int $chainLength,
        public string $rootIssuer,
        public array $issues = [],
    )

    public function hasIssues(): bool
}

Lança ou falha com: nada. $trusted é definido somente em um acerto confirmado de pertencimento a âncora de confiança, nunca a partir da não-vacuidade da lista de âncoras.

RevocationStatus e RevocationCheckResult

final readonly class RevocationStatus
{
    public function __construct(
        public RevocationCheckResult $ocspStatus,
        public RevocationCheckResult $crlStatus,
        public bool $isRevoked,
        public ?DateTimeImmutable $revocationDate = null,
    )

    public static function unavailable(): self

    public function hasConclusiveGood(): bool
}

enum RevocationCheckResult: string
{
    case Good = 'good';
    case Revoked = 'revoked';
    case Unknown = 'unknown';
    case Unavailable = 'unavailable';
}

Lança ou falha com: nada dos membros mostrados. A classe também expõe fábricas estáticas verificadas por evidência (good(), revoked(), fromResults()), que lançam \InvalidArgumentException quando o status alegado contradiz a evidência OCSP/CRL — um resultado revogado nunca pode ser emitido como não-revogado, ou vice-versa. hasConclusiveGood() é true somente para um status não-revogado em que ao menos uma verificação é Good.

TimestampStatus

final readonly class TimestampStatus
{
    public function __construct(
        public bool $present,
        public bool $valid,
        public ?DateTimeImmutable $timestampTime = null,
        public string $tsaName = '',
        public array $issues = [],
    )

    public static function absent(): self
}

Lança ou falha com: nada. Em resultados de lote este é sempre o estado absent(); consulte Casos-limite e armadilhas.

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

Valide um documento e leia o relatório. Este exemplo usa um PDF não assinado, de modo que a saída é determinística.

batch-quick-start.php

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;

// A minimal, unsigned PDF: the validator reports it as no_signatures.
$unsigned = "%PDF-1.7\n1 0 obj\n<< /Type /Catalog >>\nendobj\ntrailer\n<< /Root 1 0 R >>\n%%EOF\n";

$validator = new BatchSignatureValidator();

try {
    $report = $validator->validate([
        new DocumentSignatureInput(documentId: 'doc-001', pdfData: $unsigned),
    ]);
} catch (\InvalidArgumentException $e) {
    // Empty input list, or an empty documentId.
    echo 'Rejected: ' . $e->getMessage() . "\n";
    exit(1);
}

echo 'Documents: ' . $report->totalDocuments . "\n";
echo 'Signatures: ' . $report->totalSignatures . "\n";

foreach ($report->documents as $doc) {
    echo $doc->documentId . ': ' . $doc->status->value . "\n";
}

echo 'All valid: ' . ($report->allValid() ? 'yes' : 'no') . "\n";
echo 'Unsigned documents: ' . ($report->hasDocumentsWithoutSignatures() ? 'yes' : 'no') . "\n";

Saída esperada:

Documents: 1
Signatures: 0
doc-001: no_signatures
All valid: no
Unsigned documents: yes

Observe que allValid() reporta no aqui: ele requer ao menos uma assinatura e nenhum resultado não-válido, então um conjunto de assinaturas vazio nunca passa silenciosamente.

Exemplo de código — Produção

Valide um diretório de contratos assinados com clientes de revogação, âncoras de confiança, fragmentação de lote e um relatório JSON com proteção de PII.

batch-validate-contracts.php

<?php

declare(strict_types=1);

require __DIR__ . '/vendor/autoload.php';

use NextPDF\Enterprise\Security\Ltv\CrlFetcher;
use NextPDF\Enterprise\Security\Ltv\OcspClient;
use NextPDF\Enterprise\Security\Ltv\OcspResponseCache;
use NextPDF\Enterprise\Signature\BatchSignatureValidator;
use NextPDF\Enterprise\Signature\DocumentSignatureInput;
use NextPDF\Enterprise\Signature\SignatureValidationStatus;

// Any PSR-18 client works; Guzzle shown here.
$httpClient = new \GuzzleHttp\Client(['timeout' => 10]);

// Revocation clients make a conclusive non-revoked (Good) result reachable.
// Without them, every verdict tops out at Indeterminate. The response cache
// lets repeat signers across the batch resolve without extra network calls.
$validator = new BatchSignatureValidator(
    ocspClient: new OcspClient($httpClient, cache: new OcspResponseCache()),
    crlFetcher: new CrlFetcher($httpClient),
);

// Trust anchors are an input: the chain terminus must match one of these.
$anchors = [(string) file_get_contents('/etc/nextpdf/trust/enterprise-root.pem')];

$inputs = [];
foreach (glob('/var/contracts/signed/*.pdf') ?: [] as $path) {
    $inputs[] = new DocumentSignatureInput(
        documentId: basename($path),
        pdfData: (string) file_get_contents($path),
        trustedCerts: $anchors,
    );
}

$exit = 0;

// One call is capped at 1,000 documents; chunk larger runs.
foreach (array_chunk($inputs, 1000) as $batch) {
    try {
        $report = $validator->validate($batch);
        // Signer PII is redacted by default in the serialized report.
        file_put_contents('/var/log/nextpdf/batch-report.jsonl', $report->toJson() . PHP_EOL, FILE_APPEND); // one JSON document per line
    } catch (\InvalidArgumentException | \OverflowException $e) {
        fwrite(STDERR, 'Batch rejected: ' . $e->getMessage() . "\n");
        exit(2);
    } catch (\JsonException $e) {
        fwrite(STDERR, 'Report encoding failed: ' . $e->getMessage() . "\n");
        exit(3);
    }

    foreach ($report->documents as $doc) {
        foreach ($doc->signatures as $sig) {
            if ($sig->status !== SignatureValidationStatus::Valid) {
                $exit = 1;
                fwrite(STDERR, sprintf(
                    "%s: %s (chain trusted: %s, revoked: %s)\n",
                    $doc->documentId,
                    $sig->status->value,
                    $sig->certChain->trusted ? 'yes' : 'no',
                    $sig->revocation->isRevoked ? 'yes' : 'no',
                ));
            }
        }
    }
}

exit($exit);

Saída esperada (stderr, para um documento cuja evidência de revogação estava indisponível; outras linhas variam com as suas entradas):

contract-0042.pdf: indeterminate (chain trusted: yes, revoked: no)

O relatório JSON serializa os campos de identidade do signatário através do CertPiiGuard padrão, então uma entrada por assinatura fica assim (trecho, ilustrativo):

{
    "status": "indeterminate",
    "signer": "[REDACTED]",
    "level": "B-B",
    "subFilter": "ETSI.CAdES.detached"
}

Casos-limite e armadilhas

• Uma lista de entrada vazia lança \InvalidArgumentException; mais de 1.000 documentos em uma chamada lança \OverflowException. Fragmente execuções maiores, como no exemplo de produção.
• Atualizando de versões anteriores: sem nenhum cliente OCSP ou CRL configurado, a revogação é unavailable, então nenhuma assinatura pode alcançar Valid. Versões anteriores reportavam Valid aqui; a 3.1.0 reporta Indeterminate (consulte Visão conceitual).
• Os contadores no nível do documento são rigorosos: somente Valid incrementa validCount. Invalid, Indeterminate e Error incrementam todos invalidCount. Um documento cuja única assinatura é Indeterminate portanto reporta all_invalid. Baseie-se no status por assinatura quando a distinção importar.
• A verificação OCSP é executada somente quando a cadeia recuperada tem ao menos dois certificados, porque a consulta precisa do emissor. Uma cadeia de certificado único cai para o caminho da CRL ou para unavailable.
• crlStatus nunca reporta revoked em resultados de lote. O fallback da CRL atesta apenas a atualidade da lista; um resultado revogado autoritativo vem do OCSP.
• timestamp é sempre absent() em resultados de lote. O validador de lote não avalia tokens RFC 3161 incorporados; use Verificação de assinaturas para avaliação de carimbo de tempo.
• signer está vazio quando a autenticação falhou. Quando definido, é o CN (ou O) do assunto do certificado verificado pelo CMS — nunca a string /Name não autenticada do dicionário de assinatura.
• As entradas de trustedCerts precisam ser certificados PEM. Uma lista de âncoras vazia ou malformada gera um veredicto de cadeia apenas estrutural com trusted: false, limitando o veredicto a Indeterminate.
• Bytes que não começam com um cabeçalho PDF produzem um status error por documento com zero assinaturas — sem exceção.
• toJson() oculta PII por padrão. Passe new CertPiiGuard(disclosePii: true) somente onde você detém uma base legal documentada para processar a identidade do signatário.

Notas de segurança

• Produtor de veredicto fail-closed. Valid requer todos os seguintes: autenticação CMS verificada sobre o digest de /ByteRange, uma cadeia válida, pertencimento confirmado a âncora de confiança e um status conclusivo de não-revogado. Cada verificação não estabelecida rebaixa o veredicto; nada assume por padrão uma aprovação.
• Sem lavagem de identidade. O signatário reportado é o assunto do certificado vinculado criptograficamente. A entrada /Name é metadado controlado pelo atacante e nunca é apresentada como o signatário.
• Algoritmos fracos nunca passam. Uma assinatura SHA-1 que verifica ainda é reportada como não-válida; a validade criptográfica sob um digest fraco não é lavada para uma aprovação completa.
• Confiança é uma entrada, não uma inferência. As âncoras que você fornece são comparadas ao término da cadeia pela impressão digital DER SHA-256 (RFC 5280 §6.1.1). A autoconsistência de uma cadeia, ou uma lista de âncoras não vazia por si só, nunca estabelece confiança.
• Revogação é decisiva. Uma declaração de revogado verificada força Invalid independentemente de qualquer outra verificação; evidência indisponível força Indeterminate.
• Privacidade por padrão na saída serializada. toJson() mascara o CN do signatário, o DN do emissor raiz, o nome da TSA e os diagnósticos de problemas da cadeia a menos que você opte por sair, implementando a minimização de dados do Artigo 5(1)(c) do GDPR no limite de serialização.
• Tempo determinístico. A decisão de atualidade da CRL lê o relógio PSR-20 injetado, não o relógio de parede do host, de modo que os veredictos de revogação são reproduzíveis sob teste.

Conformidade

O NextPDF Enterprise implementa comportamento informado pelo ETSI EN 319 102-1 (o modelo de status de validação de três valores e a regra de que informação de revogação indisponível resulta em INDETERMINATE), pelo RFC 5652 §5.6 (recomputação de digest do lado do verificador) e pelo RFC 5280 §6.1 (âncoras de confiança como entradas da parte confiante para a validação de caminho). Suporte não é conformidade, e conformidade não é certificação. O NextPDF não detém nenhuma certificação e não concede nenhuma. O validador de lote não é um serviço de validação qualificado, e seus status são veredictos de engenharia alinhados à taxonomia do EN 319 102-1 — não indicações TOTAL-PASSED/TOTAL-FAILED/INDETERMINATE de um processo de validação completo da cláusula 5. Em particular, o modo de lote não realiza nenhum processamento de prova de existência ou de carimbo de tempo; o lado de verificação de documento único cobre esse terreno.

Comportamento no modo FIPS

O validador de lote não consulta nenhuma política de modo FIPS, e habilitar o modo FIPS não altera os veredictos de lote. Seu tratamento de algoritmos do lado de verificação é fixo e fail-closed: assinaturas fracas (SHA-1) nunca são reportadas como Valid, com ou sem modo FIPS. A política de modo FIPS do Enterprise gere o lado de assinatura/geração, documentado em FIPS 140 — Referência aprofundada. O suporte a FIPS 140 é uma declaração de capacidade, não uma alegação de validação ou certificação.

Contrato de comportamento

• validate() lança \InvalidArgumentException para uma lista vazia e \OverflowException acima de 1.000 documentos. Documentos malformados nunca lançam; eles produzem resultados error por documento.
• Valid requer a conjunção: CMS verificado criptograficamente, cadeia válida, pertencimento a âncora de confiança confirmado e RevocationStatus::hasConclusiveGood() verdadeiro.
• Um certificado confirmado como revogado é decisivo: o veredicto é Invalid independentemente de toda outra evidência.
• Ambas as verificações de revogação Unknown/Unavailable significam Indeterminate, nunca Valid (endurecimento da 3.1.0, impacto na compatibilidade retroativa).
• Uma assinatura autenticada e com cadeia válida sem uma âncora de confiança confirmada é Indeterminate — autêntica, confiança não estabelecida.
• signer é o assunto verificado pelo CMS ou a string vazia; a entrada /Name nunca é usada.
• timestamp é sempre o estado ausente em resultados de lote.
• validCount conta apenas Valid; todos os outros status contam em invalidCount, e o status do documento agrega a partir desses contadores.
• toJson() aplica o CertPiiGuard com privacidade por padrão a menos que um guard seja passado explicitamente.
• Os totais do relatório são somas exatas sobre os resultados por documento; durationMs é o tempo de parede medido para o lote.

Alternativa no Core

O módulo Segurança / Assinatura do NextPDF Core é o lado produtor: ele cria assinaturas CMS, aplica carimbos de tempo RFC 3161 e valida cadeias e revogação para o material que incorpora no momento da assinatura. O Core não entrega nenhum orquestrador de lote do lado de verificação: nenhum relatório multi-documento, nenhuma taxonomia de status agregada, nenhum veredicto de revogação OCSP/CRL para documentos de terceiros e nenhuma serialização de relatório com proteção de PII. Apenas no Core, você extrairia e verificaria cada assinatura por conta própria e construiria seu próprio relatório. O lado de verificação de documento único do Enterprise (Verificação de assinaturas) e este orquestrador de lote fornecem essa camada.

Limite de publicação

Esta página documenta apenas o comportamento externamente observável e a superfície de API pública suportada. Caminhos de namespace internos, classes auxiliares, tabelas de mecanismos, nomes de arquivos de runbook e prefixos de tickets estão fora de escopo.

Veja também

• Verificação de assinaturas — o lado de verificação criptográfica AdES/PAdES de documento único, incluindo validação de carimbo de tempo e de cadeia de arquivamento
• Arquivamento — incorporação de material DSS/VRI e carimbos de tempo de documento para validade de longo prazo
• Validação — verificações de política estrutural somente leitura, sem criptografia
• Assinatura — Referência aprofundada — a referência aprofundada do módulo Signature
• Níveis de garantia eIDAS — API do CertPiiGuard e mapeamento de níveis de garantia
• Assinatura em escala, sem concessões — ensaio Insider sobre design de assinatura e validação de alto volume
• Validando uma assinatura corretamente — ensaio Insider sobre por que a validação fail-closed importa