O panorama dos padrões

Spec Spec: ISO 32000-2 ISO 32000-2 Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 Spec Spec: RFC 3161 RFC 3161 Spec Spec: WCAG 2.2 WCAG 2.2 Evidence § Standard-backed Evidence: Standard-backed

Visão geral

Um mecanismo de PDF não responde a um único documento. Ele responde a uma pequena federação de padrões, escritos por organismos diferentes e referenciados entre si. Esta página mapeia essa federação como o NextPDF a acompanha. Ela também mostra o caminho que uma cláusula percorre desde “um padrão diz isso” até “o mecanismo faz isso, e um teste prova.”

Ela foi escrita para um engenheiro sênior que precisa saber qual documento rege um comportamento antes de decidir se a leitura que o NextPDF faz dele é uma interpretação que você consegue defender.

Por que isso importa

“Suporte a PDF” é uma afirmação que esconde uma pergunta: suporte a quê, exatamente? A sintaxe central é da ISO 32000-2. As assinaturas passam pela ETSI. Os carimbos de tempo dependem de um protocolo da IETF. O HTML e o CSS que o mecanismo renderiza são do W3C. A criptografia por baixo vem do NIST. A acessibilidade da saída é, de novo, do W3C.

Se uma biblioteca trata tudo isso como um único bloco indiferenciado, você não consegue raciocinar sobre uma falha. Quando um validador rejeita uma fatura assinada, a primeira pergunta útil não é “o PDF está corrompido?” É “qual cláusula de qual padrão não foi atendida, e em que lado?” Para fazer essa pergunta, você precisa de um mapa que nomeie os organismos e de um relato honesto de como uma cláusula se transforma em comportamento.

A versão resumida

• O NextPDF acompanha cinco organismos de padronização. A ISO responde pelo formato. A ETSI responde pelos perfis europeus de assinatura. A IETF responde pelos protocolos de transporte (carimbos de tempo, primitivas criptográficas por referência). O W3C responde pelo HTML, pelo CSS e pelos critérios de acessibilidade. O NIST responde pelos algoritmos criptográficos aprovados.
• Esses documentos formam trilhas, não uma lista: uma única funcionalidade de PDF assinado percorre ISO → ETSI → IETF → NIST, cada camada referenciando normativamente a seguinte.
• Uma cláusula não se torna comportamento por ser lida. Ela se torna comportamento por ser parafraseada e citada, mapeada para um requisito, implementada e fixada por um teste. A página que descreve o comportamento o declara por meio do seu nível de evidência.
• Quando uma cláusula é obrigatória, ela carrega uma palavra-chave normativa (um shall, um must). O NextPDF trata essas palavras-chave como o contrato. Um should é uma recomendação que ele documenta como tal, não como uma garantia.

Como o NextPDF aborda isso

A federação, não um bloco único

A ISO 32000-2 é o centro. Ela define o que é um arquivo conforme. Um arquivo conforme deve aderir a todos os requisitos do documento, embora tenha liberdade para omitir qualquer recurso que o documento não exija explicitamente Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 . Ela também estabelece a obrigação de quem escreve: tudo o que o NextPDF cria ou altera em um arquivo deve estar conforme o formato e permanecer consistente com os elementos já presentes Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6 . É essa cláusula específica que faz o mecanismo recusar a emissão de uma atualização incremental estruturalmente inconsistente. Não é uma preferência do NextPDF. É a regra do próprio formato.

A partir desse centro, a ISO 32000-2 aponta para fora. Seu tratamento de assinaturas é definido “por meio de referência” à série ETSI EN 319 142 para o PAdES. A ETSI, por sua vez, referencia a RFC 3161 da IETF para o token de carimbo de tempo e a série FIPS do NIST para os algoritmos de hash e de assinatura. Uma funcionalidade é, portanto, um caminho que atravessa vários documentos, cada um normativo para a sua própria camada.

1. Step 1 of 5: ISO 32000-2 §12.8 signatures ISO 32000-2 §12.8 signatures
2. Step 2 of 5: ETSI EN 319 142-1 PAdES baseline ETSI EN 319 142-1 PAdES baseline
3. Step 3 of 5: RFC 3161 timestamp token RFC 3161 timestamp token
4. Step 4 of 5: NIST FIPS 180-4 hash strength NIST FIPS 180-4 hash strength
5. Step 5 of 5: WCAG 2.2 tagged output WCAG 2.2 tagged output

A trilha de padrões que um único PDF assinado validável a longo prazo atravessa: a ISO define o contêiner e aponta para a ETSI quanto ao perfil de assinatura; a ETSI exige um carimbo de tempo da IETF; as primitivas criptográficas são aprovadas pelo NIST; a saída renderizada é submetida à acessibilidade do W3C. Cada seta é uma referência normativa, não uma associação solta.

Como uma cláusula se torna comportamento

A versão perigosa do trabalho com padrões é ler uma cláusula e depois escrever código de memória. O caminho do NextPDF é deliberadamente mais longo, porque o caminho mais longo é o que você consegue auditar:

1. Retrieve The clause is read from the standard, not from memory.
2. Cite It is paraphrased and pinned with a chunk digest, never quoted.
3. Classify Its keyword (shall / should / may) sets whether it is a contract or a recommendation.
4. Map The obligation becomes a concrete engine requirement.
5. Implement The requirement is built into the pipeline.
6. Pin A test holds the behaviour against drift.
7. Tag The page that describes it declares its evidence level.

O caminho de uma cláusula normativa até um comportamento testado do mecanismo: recupere e cite a cláusula, classifique a sua obrigação pela palavra-chave normativa, mapeie-a para um requisito do mecanismo, implemente-a, fixe-a com um teste e marque a página que a documenta com a sua base de evidência. Uma cláusula que para antes do teste é uma afirmação, não um comportamento.

É na etapa “classificar” que a maior parte da ambiguidade é resolvida. As especificações codificam seus níveis de requisito em palavras-chave: a conhecida família MUST, SHALL, SHOULD, MAY. O significado dessas palavras-chave é fixado pela convenção de palavras-chave de requisito da IETF, atualizada para esclarecer que apenas as formas em maiúsculas são normativas, e então aplicado sobre a prosa descritiva de cada especificação Spec Spec: RFC 2119 RFC 2119 Spec Spec: RFC 8174 RFC 8174 . O NextPDF lê um shall como um limite rígido que o mecanismo não ultrapassa, e um should como uma recomendação que ele segue e documenta como recomendação — nunca como uma promessa. Essa distinção é a diferença entre uma declaração de funcionalidade honesta e um exagero.

A conformidade é graduada, não binária

“Conforme” raramente é um único bit. Os padrões de assinatura têm níveis — o perfil europeu de longo prazo com arquivamento, por exemplo, existe especificamente para adicionar tokens de carimbo de tempo que mantêm uma assinatura validável muito tempo depois de ela ter sido criada Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6 . Essa é uma afirmação estritamente mais forte do que uma assinatura baseline simples. O padrão de acessibilidade segue a mesma forma: um nível de conformidade só é alcançado quando todos os critérios de sucesso daquele nível são satisfeitos, e uma afirmação declara o nível que de fato foi alcançado Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1 . O NextPDF declara, portanto, o perfil e o nível, não um “em conformidade” sem qualificação.

Human-factors note: Human-factors note

A trilha de padrões é renderizada como uma figura ordenada e legendada, não como um gráfico decorativo, porque quem lê precisa conseguir seguir as referências em sequência, e um leitor de tela precisa anunciá-las nessa mesma ordem. As setas entre as especificações são decorativas. O significado é transmitido inteiramente pelos nomes das especificações e pela legenda, que é o equivalente textual da trilha. Esse é o mesmo raciocínio que rege todos os diagramas no Insider_: ordem e significado ficam na marcação, nunca na cor ou no conector.

O que a evidência diz

Esta página é Evidence § Standard-backed Evidence: Standard-backed : cada afirmação é ancorada em uma cláusula, parafraseada e citada com um digest, para que o próximo revisor possa reverificá-la na fonte.

Camada	Organismo	Cláusula âncora (parafraseada)	O que ela rege no NextPDF
Formato	ISO	Os elementos criados ou alterados por quem escreve devem estar conformes e permanecer consistentes Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	O PDF que o mecanismo emite
Conformidade	ISO	Um arquivo conforme atende a todos os requisitos; recursos adicionais são opcionais Spec Spec: ISO 32000-2, §6 ISO 32000-2 §6	O que significa “saída válida”
Perfil de assinatura	ETSI	O nível de longo prazo com arquivamento adiciona carimbos de tempo para validação posterior Spec Spec: ETSI EN 319 122-1, §6 ETSI EN 319 122-1 §6	O perfil PAdES que uma assinatura tem como alvo
Tempo confiável	IETF	Um serviço de carimbo de tempo prova que um dado existia antes de um determinado momento Spec Spec: RFC 3161, §2 RFC 3161 §2	O token de carimbo de tempo do documento
Criptografia	NIST	Os hashes aprovados diferem na força de segurança que conferem Spec Spec: NIST FIPS 180-4, §1 NIST FIPS 180-4 §1	O algoritmo de digest sob uma assinatura
Acesso à saída	W3C	Um nível de conformidade exige todos os critérios daquele nível Spec Spec: WCAG 2.2, §5.2.1 WCAG 2.2 §5.2.1	Afirmações de acessibilidade sobre PDFs renderizados

Os digests citados são registrados no frontmatter citations desta página. Nenhum texto dos padrões é reproduzido aqui. A regra que rege essa escolha é, ela própria, uma página. Consulte Disciplina de citação.

Exemplo prático

Você não executa o panorama dos padrões; você o lê para decidir o que pedir ao mecanismo. Na prática, uma chamada de assinatura validável a longo prazo é uma declaração sobre qual ponto da trilha você precisa:

examples/36-sign-pades-b-b-and-b-t.php

<?php

declare(strict_types=1);

use NextPDF\Core\Document;
use NextPDF\Security\Signature\CertificateInfo;
use NextPDF\Security\Signature\DigitalSigner;
use NextPDF\Security\Signature\SignatureLevel;

// The signature level is a coordinate on the ISO -> ETSI -> RFC trail.
// PAdES B-B is the ETSI baseline CMS SignedData the Core engine produces;
// B-T adds an RFC 3161 timestamp, and B-LT/B-LTA add the DSS and document
// timestamps that keep a signature validatable after the certificate
// expires. The level you name is the point on the trail you are asking for.
$certInfo = CertificateInfo::fromFiles(
    certPath: 'signer-cert.pem',
    keyPath: 'signer-key.pem',
);

// The functional signing path is the direct two-phase signing engine.
// (Document::setSignature() records intent but its writer seam is not yet
// wired and fail-fasts on output — see the PadesOrchestrator docblock.)
$signer = new DigitalSigner(
    certInfo: $certInfo,
    level: SignatureLevel::PAdES_B_B,
);

$result = $signer->sign(file_get_contents('agreement.pdf'));

printf(
    "PAdES %s CMS: %d bytes, timestamp=%s\n",
    SignatureLevel::PAdES_B_B->value,
    $result->getSize(),
    $result->hasTimestamp() ? 'yes' : 'no',
);

Nomear PAdES_B_LTA em vez de uma baseline simples não é uma opção de desempenho. É uma decisão sobre até onde, na trilha de padrões, a obrigação chega. O B-LT e o B-LTA trazem as camadas de DSS e de carimbo de tempo de arquivamento e exigem o pacote enterprise de LTV em tempo de execução. Em vez de degradar silenciosamente, o mecanismo se recusa a fingir que um nível inferior entrega um superior.

Equívoco comum

A armadilha é ler “o NextPDF está em conformidade com os padrões” como uma garantia única e absoluta. Não é, e nenhum mecanismo honesto oferece uma. A conformidade é por padrão, por cláusula e por nível. O NextPDF tem como alvo o baseline do PDF 2.0, perfis PAdES nomeados e níveis de acessibilidade declarados — cada um delimitado, cada um citado. Uma afirmação sem uma cláusula e um nível por trás dela é marketing, e o Insider_ não a publica.

A segunda armadilha, mais sutil, é supor que um should normativo é uma promessa. É uma recomendação. O NextPDF documenta recomendações como recomendações. As garantias do mecanismo são construídas a partir das cláusulas shall, e a diferença é estrutural.

Limites e fronteiras

Esta página é o mapa, não o território. Ela não enumera todas as cláusulas que o NextPDF implementa e não é um certificado de conformidade. A prova por comportamento reside na página de tópico responsável pelo comportamento, com o nível de evidência próprio daquela página — por exemplo PDF 2.0: o que mudou para o delta de formato.

O panorama dos padrões também se move. Novas edições são lançadas. As referências são atualizadas. Uma cláusula citada aqui é fixada ao snapshot do corpus registrado no citations desta página. Quando um padrão upstream é revisado, a citação é revalidada contra a nova cláusula, e não se presume que ela continue válida. Quando esta página nomeia uma funcionalidade de nível Premium, ela o faz no nível de qual padrão ela atende, nunca no nível do mecanismo interno.

Documentos relacionados

• PDF 2.0: o que mudou — o delta concreto da ISO 32000-2 para o qual a camada de formato deste mapa aponta.
• Documentação como produto — por que a disciplina de mapear cláusulas em comportamento é tratada como engenharia.
• Disciplina de citação — a regra que decide como uma cláusula é citada aqui, e o que um nível de evidência significa.

Glossário

• Organismo de padronização — uma organização que publica uma especificação (ISO, ETSI, IETF, W3C, NIST). Cada um responde por uma camada diferente da pilha do PDF.
• Cláusula normativa — um requisito em um padrão, identificado pela sua palavra-chave (shall/must para obrigatório, should para recomendado, may para opcional).
• Trilha de padrões — uma cadeia ordenada de especificações que uma única funcionalidade atravessa, em que cada documento referencia normativamente o seguinte.
• Nível de conformidade — um escalão graduado de conformidade (um perfil baseline da ETSI, um nível WCAG). Uma afirmação declara o nível efetivamente alcançado, não um “em conformidade” sem qualificação.
• PAdES — PDF Advanced Electronic Signatures, a família ETSI EN 319 142 de perfis de assinatura que a ISO 32000-2 referencia para a assinatura de PDF.