Signer un PDF avec une signature PAdES de base (déplacé)
Ce recipe a été déplacé
Section intitulée « Ce recipe a été déplacé »La procédure de signature que cette page décrivait auparavant est désormais remplacée. Utilise plutôt le recipe canonique :
Pourquoi cette page a changé (erratum)
Section intitulée « Pourquoi cette page a changé (erratum) »Une version antérieure de cette page affirmait que le raccord de haut niveau Document::setSignature() → save() n’était pas câblé et qu’il levait NotImplementedException. Ce n’est plus le cas. Le raccord de haut niveau génère désormais une vraie signature.
Document::setSignature($cert, SignatureLevel::PAdES_B_B)->save() (et les équivalents output() / getPdfData()) écrivent un champ /Sig avec un /ByteRange et un objet CMS SignedData encodé en DER dans l’entrée Contents du dictionnaire de signature — la structure spécifiée par ISO 32000-2 §12.8 pour le sous-filtre ETSI.CAdES.detached SubFilter. Le résultat est vérifiable par CMS : un vérificateur CMS/PKCS#7 standard peut l’analyser et le contrôler.
- B-B — le niveau Core — est produit directement par ce raccord.
- B-T ajoute un signature-time-stamp RFC 3161 en passant un
TsaClientau même appel. - B-LT / B-LTA sont accessibles via le même raccord de haut niveau (
setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()) lorsque les packages Pro et Enterprise sont installés. Sans eux, l’appel échoue de manière sûre au lieu d’écrire une révision à long terme partielle. Les documents chiffrés échouent eux aussi de manière sûre pour B-LT/B-LTA.
Le chemin de plus bas niveau NextPDF\Security\Signature\DigitalSigner reste pris en charge, et c’est celui que le recipe canonique ci-dessous parcourt de bout en bout ; le raccord de haut niveau n’est qu’une couche de commodité légère au-dessus du même moteur de signature. La suite d’intégration couvre les deux et produit un objet CMS réel et analysable.
Mise en garde U-1 (portée de l’affirmation). « vérifiable par CMS » signifie que l’objet produit est un objet CMS
SignedDatabien formé selon RFC 5652 et ISO 32000-2 §12.8 — ce n’est pas une affirmation de conformité au profil de base ETSI EN 319 142-1, ni de validité juridique. La partie de cette norme qui traite des niveaux de base ne figure pas dans le corpus de vérification ; l’exigence de B-T en matière designature-time-stampa été contrôlée au regard d’ETSI EN 319 122-1 §5.3 avec RFC 3161, RFC 5652, RFC 5816 et ISO 32000-2 §12.8. B-LT/B-LTA produisent la structure de validation à long terme (un DSS dictionnaire plus une révision DocTimeStamp) ; elles ne sont pas présentées comme testées pour la conformité au profil. La détermination de la conformité et de la validité juridique relève d’un validateur indépendant.
Ce qui a été repris sans changement
Section intitulée « Ce qui a été repris sans changement »Les faits structurels que l’ancienne page affirmait sur l’artefact sur disque restent corrects. Le recipe de remplacement les réénonce avec les preuves correspondantes :
- La valeur de la signature est stockée dans l’entrée
Contentsdu dictionnaire de signature (ISO 32000-2 §12.8.1). - Le condensat est calculé sur le
ByteRangeet exclut la valeur de la signature elle-même (ISO 32000-2 §12.8.1).
Cette page n’affirme pas qu’une signature ainsi obtenue est juridiquement valide. Cela dépend du certificat, de son ancre de confiance et de la politique du vérificateur, qui relèvent tous d’éléments extérieurs à cette bibliothèque.