Pular para o conteúdo

Assine um PDF com uma assinatura PAdES baseline (receita movida)

O passo a passo de assinatura que ficava nesta página foi substituído. Use a receita canônica no lugar dele:

Assine um PDF com PAdES B-B e depois estenda para PAdES B-T

Uma versão anterior desta página afirmava que o caminho de alto nível Document::setSignature()save() não estava conectado e lançava NotImplementedException. Isso não é mais verdade. O caminho de alto nível agora grava uma assinatura real.

Document::setSignature($cert, SignatureLevel::PAdES_B_B)->save() (e o equivalente output() / getPdfData()) grava um campo /Sig com um /ByteRange e um objeto Cryptographic Message Syntax (CMS) SignedData codificado segundo Distinguished Encoding Rules (DER) na entrada Contents do dicionário de assinatura. Essa é a estrutura que a ISO 32000-2 §12.8 especifica para o ETSI.CAdES.detached SubFilter. O resultado é verificável por CMS: um verificador padrão de CMS/PKCS#7 (Public-Key Cryptography Standards #7) faz o parsing e a checagem desse objeto.

  • B-B — o nível Core — é produzido diretamente por esse caminho.
  • B-T adiciona um RFC 3161 signature-time-stamp quando você passa um TsaClient na mesma chamada.
  • B-LT / B-LTA podem ser obtidos pelo mesmo caminho de alto nível (setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()) quando os pacotes Pro e Enterprise estão instalados; sem eles, a chamada falha de forma fechada em vez de gravar uma revisão de longo prazo parcial. Documentos criptografados também falham de forma fechada para B-LT/B-LTA.

O caminho de nível mais baixo NextPDF\Security\Signature\DigitalSigner continua sendo suportado. A receita canônica abaixo percorre esse caminho de ponta a ponta. O caminho de alto nível é uma camada fina de conveniência sobre o mesmo mecanismo de assinatura. A suíte de integração exercita os dois caminhos e produz um objeto CMS real e analisável.

Ressalva U-1 (escopo da afirmação). “Verificável por CMS” significa que o objeto produzido é um CMS SignedData bem formado conforme a RFC 5652 e a ISO 32000-2 §12.8. Isso não é uma afirmação de conformidade com o perfil baseline da ETSI EN 319 142-1 nem de validade jurídica. A seção sobre os níveis baseline desse padrão não está no corpus de verificação; o requisito de signature-time-stamp do B-T foi verificado em relação à ETSI EN 319 122-1 §5.3 com RFC 3161, RFC 5652, RFC 5816 e ISO 32000-2 §12.8. B-LT/B-LTA produzem a estrutura de validação de longo prazo (um dicionário DSS mais uma revisão DocTimeStamp); elas não são apresentadas como testadas quanto à conformidade de perfil. Um validador independente determina a conformidade e a validade jurídica.

Os fatos estruturais que a página antiga afirmava sobre o artefato em disco continuam corretos. A receita substituta reafirma esses pontos com evidências:

  • O valor da assinatura é armazenado na entrada Contents do dicionário de assinatura (ISO 32000-2 §12.8.1).
  • O digest é calculado sobre o ByteRange e exclui o próprio valor da assinatura (ISO 32000-2 §12.8.1).

Esta página não faz nenhuma afirmação de que qualquer assinatura resultante seja juridicamente válida. A validade jurídica depende do certificado, da âncora de confiança dele e da política do verificador. Todos esses fatores ficam fora desta biblioteca.