PAdES na Prática: Como a Assinatura Digital Vive Dentro do PDF

PAdES é o nome do conjunto de regras que define como uma assinatura digital mora dentro de um arquivo PDF. Não é um formato de arquivo novo, não é um contêiner separado e não é um selo visual: é a especificação de onde a assinatura fica, o que ela cobre e como um leitor de PDF deve verificá-la sem precisar consultar ninguém.

Quem trabalha com documentos no Brasil encontra o PAdES em toda parte — é o formato do PDF assinado com e-CPF, do contrato que volta do jurídico com o cadeado no Adobe Reader, do arquivo que o Validador do ITI abre e classifica. E é também o formato onde mais gente se perde, porque a mesma palavra cobre duas gerações de especificação, dois valores de SubFilter e uma lista de níveis que nem sempre significa o que o nome sugere.

Este guia é o mergulho técnico. Anatomia da assinatura dentro do PDF, o que é DocMDP e por que ele importa mais do que parece, como múltiplas assinaturas convivem no mesmo arquivo, o que a ICP-Brasil exige por cima do padrão internacional e como validar o resultado. Para a visão comparativa entre os padrões, comece por PKCS#7, CMS, PAdES e CAdES.

O problema que o PAdES resolve

Uma assinatura CMS comum resolve o problema criptográfico: prova que uma chave privada assinou um conjunto de bytes. O que ela não resolve é o problema documental — o arquivo assinado e a assinatura viram duas coisas separadas, que alguém precisa manter juntas, na ordem certa, para sempre.

O PDF já tinha uma estrutura para isso. A especificação ISO 32000-1 prevê um dicionário de assinatura dentro do próprio documento, e o PAdES, descrito pela ETSI, define como preencher esse dicionário de modo que a assinatura sirva como prova de longo prazo. O DOC-ICP-15 do ITI descreve a mecânica em uma frase: "Um CMS detached é inserido dentro da estrutura de dados do PDF. O conteúdo assinado pelo CMS deve ser todos os bytes do PDF, menos o bloco de bytes do próprio CMS."

Isso tem três consequências práticas que definem tudo o mais:

• O arquivo é autossuficiente. Quem recebe o PDF recebe a assinatura junto. Não há um segundo arquivo para perder.
• A assinatura cobre o documento inteiro, menos o espaço reservado para ela própria. Qualquer byte alterado depois quebra a verificação.
• A verificação é local. Um leitor de PDF aderente faz a conta sozinho, offline, sem consultar a plataforma que gerou o documento.

Anatomia: o que existe dentro de um PDF assinado

Abrir um PDF assinado em um editor de texto revela a estrutura. O que importa está no dicionário de assinatura:

Campo a campo:

• /ByteRange — o coração da coisa. São quatro números: início e comprimento do primeiro trecho, início e comprimento do segundo. Juntos cobrem todo o arquivo exceto o bloco onde a assinatura está gravada. É sobre esses bytes que o hash é calculado.
• /Contents — o contêiner CMS em hexadecimal, gravado dentro de um espaço reservado de tamanho fixo. É o "buraco" que o /ByteRange pula.
• /SubFilter — declara qual convenção a assinatura segue. Voltaremos a ele no próximo bloco, porque é onde mora a confusão mais comum.
• /M — o instante declarado pelo signatário. O ITI é explícito sobre a duplicidade: como o PDF tem a entrada M e o CMS tem o atributo signing-time carregando a mesma informação, o perfil ICP-Brasil orienta codificar a entrada M e não o atributo. É o tipo de detalhe que só aparece quando um validador rígido reclama.
• /Name, /Reason, /Location — metadados declarativos, úteis para leitura humana, sem peso probatório próprio.

A assinatura entra por atualização incremental: o PDF original é preservado byte a byte e os objetos novos são acrescentados no fim do arquivo, com uma nova tabela de referências cruzadas. É isso que permite assinar sem reescrever o documento — e é isso que explica por que "salvar como" em um editor qualquer costuma destruir uma assinatura: reescrever o arquivo muda os bytes que o /ByteRange cobria.

Os dois SubFilters, e por que existem

Essa é a distinção que mais gera dúvida em validação:

DocMDP: a parte que quase ninguém configura e todo mundo precisa

Há dois papéis para uma assinatura em PDF, e o padrão os trata de forma diferente:

• Assinatura de certificação — é a primeira, e declara o que pode mudar no documento depois dela. Fica registrada na entrada /Perms /DocMDP do catálogo do PDF.
• Assinatura de aprovação — todas as demais. Atestam concordância, sem redefinir as permissões.

A assinatura de certificação carrega um parâmetro /P dentro de TransformParams, com três níveis possíveis:

Escolher errado aqui produz um sintoma clássico: o primeiro signatário assina com /P 1, o segundo assina normalmente e o Adobe Reader passa a exibir que o documento foi alterado depois da certificação. Nada quebrou criptograficamente — o documento apenas declarou que ninguém mais poderia tocá-lo, e alguém tocou.

No SignDocs Brasil o nível é derivado do envelope: a primeira assinatura certifica com /P 1 quando há um único signatário e com /P 2 quando há mais de um; as seguintes entram como assinaturas de aprovação, sem novo DocMDP.

Várias assinaturas no mesmo PDF: série, não paralelo

Aqui está uma diferença estrutural entre o PAdES e os outros padrões, e o DOC-ICP-15 é categórico sobre ela. Em CAdES e XAdES existem três arranjos: assinatura simples, coassinatura (assinaturas paralelas e independentes sobre o mesmo conteúdo) e contra-assinatura (assinatura sobre a assinatura anterior). Em PDF, não: existem assinatura simples e assinatura serial.

Assinatura serial, nas palavras do documento do ITI, é aquela em que "uma assinatura digital é realizada sobre toda a estrutura do documento assinado, inclusive assinaturas anteriores, quando houver". Cada signatário assina o PDF como ele está — com as assinaturas de quem veio antes já dentro dele.

Níveis do PAdES e as políticas da ICP-Brasil

As duas escalas existem em paralelo e não são sinônimos.

Do lado internacional, o PAdES organiza-se em níveis de linha de base: a assinatura básica; o acréscimo de um carimbo do tempo sobre a assinatura; a inclusão dos dados de validação — cadeia de certificados, listas de revogação, respostas OCSP — dentro do próprio arquivo; e, por fim, o encadeamento de carimbos que permite preservar a verificabilidade por décadas.

Do lado brasileiro, o ITI define cinco políticas de assinatura, todas listadas no repositório oficial:

Uma assinatura só é PAdES-ICP-Brasil quando, além de atender aos requisitos de assinatura digital ICP-Brasil, carrega um identificador de política pertencente ao conjunto aprovado conforme o DOC-ICP-15.03. E a validação, diz o mesmo documento, deve exigir que a assinatura esteja de acordo com uma das políticas aprovadas.

Se o seu contrato, edital ou norma setorial especifica uma dessas políticas nominalmente, trate isso como requisito técnico explícito e leve ao time comercial antes de fechar o desenho — não é uma configuração que se liga em um painel.

O selo visual não é a assinatura

Vale dizer com todas as letras, porque é a origem de boa parte dos mal-entendidos com clientes e contrapartes. O PAdES permite que a assinatura tenha representação visual na página, e o DOC-ICP-15 é direto: essa visualização "não substitui a validação da assinatura nem acrescenta segurança ao processo", e a imagem exibida pode não ter vínculo algum com o assinante.

Em outras palavras: um carimbo bonito no rodapé não prova nada, e a ausência dele não tira valor de coisa alguma. O que prova é o /ByteRange conferindo, a cadeia subindo até a raiz da ICP-Brasil e o certificado válido à época da aposição.

Como o SignDocs Brasil gera a assinatura PAdES

O caminho é o mesmo no fluxo hospedado e na API, com o perfil de política DIGITAL_CERTIFICATE:

1. O PDF recebe, por atualização incremental, um espaço reservado para a assinatura, o dicionário com /ByteRange, /SubFilter /adbe.pkcs7.detached e a entrada /M, mais o DocMDP quando é a assinatura de certificação.
2. O servidor calcula o SHA-256 sobre os trechos cobertos pelo /ByteRange e monta os atributos autenticados, incluindo o signingCertificateV2 — a referência ESS que amarra a assinatura ao certificado exato do signatário — e o CMSAlgorithmProtection, que protege a declaração dos algoritmos contra troca.
3. O hash desses atributos é devolvido para assinatura. Com A1, a chave privada assina no navegador do signatário; com A3, no token, via SignDocsBrasil Assinador falando PKCS#11.
4. O servidor monta o CMS com a cadeia do signatário e grava o contêiner no espaço reservado. Algoritmos: SHA-256 com RSA.

Os atributos autenticados são construídos em DER byte a byte, sem passar por uma rodada de reserialização. Isso não é preciosismo: reserializar um DER pode produzir bytes sutilmente diferentes dos que foram assinados, e o sintoma no Validador do ITI é a reprovação da cifra assimétrica em uma assinatura que, do ponto de vista da chave, está perfeita.

Detalhes do fluxo com certificado estão em assinatura com A1 e A3 na Assinatura Expressa e em assinar PDF com e-CPF ou e-CNPJ.

Como validar, e o que costuma dar errado

Três caminhos independentes, e é bom que sejam três:

• Leitor de PDF. Adobe Reader e equivalentes mostram o painel de assinaturas, o status de cada uma e se houve alteração depois da certificação.
• Validador do ITI. Verifica a aderência ao perfil ICP-Brasil, não apenas a matemática.
• Verificação programática. A API de verificação de PDF detecta assinaturas embutidas pelo /ByteRange e reporta o SubFilter encontrado; o verificador público abre a trilha de auditoria pelo identificador da evidência.

As falhas recorrentes, em ordem de frequência:

1. O arquivo foi reaberto e salvo por outro programa. Otimizar, linearizar ou "salvar como" reescreve bytes cobertos pelo /ByteRange.
2. Certificado vencido ou revogado. A validação exige certificado válido à época da aposição; cadeia incompleta ou raiz ausente no validador dá o mesmo sintoma.
3. DocMDP restritivo demais. Certificar com /P 1 um documento que ainda vai receber assinaturas produz o aviso de alteração posterior.
4. Versão do PDF. O ITI observa que o arquivo precisa estar na versão 1.7 para que todas as características do PAdES funcionem em um leitor aderente ao ISO 32000-1.
5. Confundir assinatura embutida com página de evidências. Uma página de auditoria anexada ao fim do PDF é registro, não assinatura criptográfica. As duas coisas podem coexistir, e coexistem no SignDocs Brasil, mas não se substituem.

Quando o documento não é PDF, a resposta não é converter à força: é o CAdES, que assina o arquivo como ele é. Para XML, o padrão irmão é o XAdES. E a visão de conjunto está na Central de Assinatura Digital.

Perguntas Frequentes