Ein PDF mit PAdES-Baseline-Signatur signieren (verschoben)
Dieses Recipe wurde verschoben
Abschnitt betitelt „Dieses Recipe wurde verschoben“Die Signaturanleitung, die diese Seite früher enthielt, ist jetzt abgelöst. Verwenden Sie stattdessen das kanonische Recipe:
Ein PDF mit PAdES B-B signieren und dann auf PAdES B-T erweitern
Warum diese Seite geändert wurde (Erratum)
Abschnitt betitelt „Warum diese Seite geändert wurde (Erratum)“Eine frühere Version dieser Seite besagte, dass die High-Level-Naht Document::setSignature() → save() nicht verdrahtet sei und dass sie NotImplementedException werfe. Das ist nicht mehr der Fall. Die High-Level-Naht erzeugt jetzt eine echte Signatur.
Document::setSignature($cert, SignatureLevel::PAdES_B_B)->save() (und die entsprechenden output() / getPdfData()) schreiben ein /Sig-Feld mit einer /ByteRange sowie ein DER-kodiertes CMS-SignedData-Objekt in den Contents-Eintrag des Signatur-Dictionaries — genau die Struktur, die ISO 32000-2 §12.8 für den ETSI.CAdES.detached-SubFilter vorschreibt. Das Ergebnis ist CMS-prüfbar: Ein standardkonformer CMS/PKCS#7-Prüfer kann es parsen und verifizieren.
- B-B — das Core-Level — wird direkt über diese Naht erzeugt.
- B-T fügt einen RFC 3161-signature-time-stamp hinzu, indem im selben Aufruf ein
TsaClientübergeben wird. - B-LT / B-LTA sind über die gleiche High-Level-Naht erreichbar (
setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save()), wenn die Pro- und Enterprise-Pakete installiert sind; ohne sie bricht der Aufruf ab (fail-closed), anstatt eine unvollständige Langzeit-Revision zu schreiben. Für verschlüsselte Dokumente bricht B-LT/B-LTA ebenfalls fail-closed ab.
Der tiefer liegende NextPDF\Security\Signature\DigitalSigner-Pfad wird weiterhin unterstützt und ist der Weg, den das kanonische Recipe unten von Anfang bis Ende durchgeht; die High-Level-Naht ist eine dünne Komfortschicht über derselben Signatur-Engine. Die Integrations-Suite deckt beide Wege ab und erzeugt ein echtes, parsbares CMS-Objekt.
U-1-Vorbehalt (Geltungsbereich der Aussage). „CMS-prüfbar“ bedeutet, dass das erzeugte Objekt ein wohlgeformtes CMS-Objekt vom Typ
SignedDatagemäß RFC 5652 und ISO 32000-2 §12.8 ist — es ist keine Zusicherung einer ETSI EN 319 142-1-Baseline-Profil-Konformität und auch keine Zusicherung der Rechtsgültigkeit. Der Teil dieses Standards zu den Baseline Levels ist nicht im Verifikations-Korpus enthalten; die B-T-signature-time-stamp-Anforderung wurde geprüft gegen ETSI EN 319 122-1 §5.3 mit RFC 3161, RFC 5652, RFC 5816 und ISO 32000-2 §12.8. B-LT/B-LTA erzeugen die Struktur für die Langzeitvalidierung (ein DSS Dictionary plus eine DocTimeStamp-Revision); sie werden nicht als auf Profil-Konformität getestet beworben. Ein unabhängiger Validator nimmt die Konformitäts- und Rechtsgültigkeits-Feststellung vor.
Was unverändert übernommen wurde
Abschnitt betitelt „Was unverändert übernommen wurde“Die strukturellen Fakten, die die alte Seite über das auf der Festplatte gespeicherte Artefakt nannte, bleiben korrekt. Das Ersatz-Recipe wiederholt sie einschließlich der Belege:
- Der Signaturwert wird im
Contents-Eintrag des Signatur-Dictionaries gespeichert (ISO 32000-2 §12.8.1). - Der Digest wird über die
ByteRangeberechnet; der Signaturwert selbst bleibt dabei ausgeschlossen (ISO 32000-2 §12.8.1).
Diese Seite behauptet nicht, dass eine so erzeugte Signatur rechtsgültig ist. Das hängt vom Zertifikat, seinem Trust-Anchor und der Richtlinie des Prüfers ab — all das wird von dieser Bibliothek nicht abgedeckt.