Inkrementelle PFX-Signierjobs

Die sign-Operation unterstützt ein validiertes inkrementelles Profil, das die exakte ursprüngliche PDF-Revision und jede vorhandene kryptografische Signatur bewahrt und zugleich ein separat signiertes Artefakt zurückgibt

Profil wählen

{"schemaVersion":1,"type":"sign","profile":"pfx-incremental-document",
 "pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
 "fieldName":"ApprovalTwo","existingField":true,
 "budget":{"memoryBytes":268435456,"outputBytes":134217728,
           "resultBytes":16777216,"timeMilliseconds":60000,
           "objectCount":1000000,"pageCount":1024}}

Das Standardprofil pfx-unsigned-document behält das ursprüngliche Verhalten bei und akzeptiert Quellen ohne jegliche Signaturfelder; es erzeugt ein neues Feld über page, x1, y1, x2 und y2 und rollt den Quellgraphen vor der Veröffentlichung zurück

pfx-incremental-document wählt das neue Profil; incremental: true ist ein gleichwertiger Selektor, wenn profile fehlt, und kollidiert mit einem explizit abweichenden Profil

existingField: true füllt das benannte leere Signaturfeld, ohne ein weiteres Feld anzulegen; andernfalls erzeugt die Operation ein neues Feld, und page und Rechteck identifizieren sein Widget

Der Default für fieldName ist Signature1 und akzeptiert 1 bis 1024 UTF-8-Bytes; existingField verlangt ein inkrementelles Profil, ein passendes Signaturfeld und einen fehlenden oder nullen V-Wert

Das Read-only-Bit 1 in Ff sowie fehlerhafte oder außerhalb des Bereichs liegende Integer-Flags werden vor der Vorbereitung abgelehnt; geerbte SV- und Lock-Dictionaries werden über eindeutige semantische PDF-Namen mit begrenzter Eltern-Traversierung aufgelöst

Seed-Werte und Feldsperren

digestMethod wählt den tatsächlichen SHA256-, SHA384- oder SHA512-CMS-Digest; SHA256 ist der Default, während cades: true ETSI.CAdES.detached wählt und das Attribut signing-certificate-v2 einschließt, das das tatsächliche Signaturzertifikat bindet

reason, location und contactName sind UTF-8-JSON-Strings, die als PDF-Unicode-Textstrings geschrieben werden; erforderliche Seed-Reasons vergleichen ihre Unicode-Werte, einschließlich des speziellen Ein-Punkt-Werts, der ein Weglassen der Reason verlangt

Erforderliche SV-Constraints prüfen den tatsächlichen Handler, den CMS-SubFilter, die unterstützte Signierversion, Digest, Reason, Zertifizierungsberechtigung, juristische Attestierung und den LockDocument-Modus; ein erforderlicher Timestamp nutzt den in Windows-Signatur-Timestamps beschriebenen Anwendungs-Transport und expliziten Trust-Workflow, erforderliche signierte Widerrufsnachweise nutzen authentifiziertes CRL- und OCSP-Signieren, und erforderliche benannte Appearances nutzen tatsächlich erzeugte Signatur-Appearance-Presets

Erforderliche SVCert-Eigenschaften validieren vor dem Signieren das tatsächliche PFX-Leaf-Zertifikat und die enthaltene Ausstellerkette, erlaubte Zertifikatsbytes, Certificate-Policy-OIDs, Key-Usage-Bits und Unicode-Subject-DN-Attribute

credentialSourceURL liefert eine von der Anwendung behauptete Credential-Herkunft für eine erforderliche SVCert-URL; die Bibliothek vergleicht die deklarierte URL und den unterstützten URLType, ohne diesen Endpunkt zu öffnen oder eine Transport-Identität zu authentifizieren

All-, Include- und Exclude-Feldsperren werden als indirektes SigFieldLock-Dictionary und eine passende, an den Dokumentkatalog gebundene FieldMDP-Referenz geschrieben; Feldnamen verwenden PDF-Unicode-Textstrings und bleiben in verschlüsselten Dokumenten verschlüsselt

Ein signierter Lock-P-Wert begrenzt spätere Revisionen über die ursprünglich signierte Feldpolicy, unabhängig von jeglicher DocMDP-Berechtigung; erlaubte zweite Signaturen bewahren die exakte vorherige Revision und das CMS, während ein gesperrtes Feld oder eine P1-Änderung vor der Veröffentlichung abgelehnt wird

Die Policy-Suche dekodiert PDF-Name-Escapes genau einmal, einschließlich geerbter Parent-Namen; Dictionaries mit doppelten semantischen Namen sowie ungültige oder zyklische Eltern werden vor der Veröffentlichung abgelehnt, während gültige Escape-Namen ihre Quellbytes behalten

contentsBytes hat den Default 16384 und akzeptiert 1024 bis 1048576; reason, location und contactName füllen das neue Signaturdictionary

Zertifizierung und juristische Attestierungen

certificationPermission hat den Default 0 für Zustimmungssignaturen; 1, 2 oder 3 erzeugt eine Zertifizierungssignatur mit der angeforderten DocMDP-Berechtigung, bindet Catalog Perms DocMDP an das tatsächliche indirekte Signaturdictionary und behält jede unabhängige FieldMDP-Transformation

Die Zertifizierung muss die erste Signatur sein, und ein Dokument kann nur eine Zertifizierungssignatur enthalten; fehlerhafte Catalog-Berechtigungen, unaufgelöste Referenzen und DocMDP-Werte ohne ursprüngliche signierte Feldbindung werden abgelehnt

legalAttestation ist ein optionaler Unicode-String für das Zertifizierungssignieren und wird in Catalog Legal Attestation geschrieben; eine erforderliche SV-LegalAttestation-Liste muss den gewählten Text enthalten, während eine leere Pflichtliste das Weglassen verlangt

Vorhandene P2- und P3-Zertifizierungssignaturen erlauben späteres Zustimmungssignieren, wenn Feldsperren und Revisionspolicy es zulassen; P1-Signaturen und gesperrte Felder lehnen Änderungen vor der Binärveröffentlichung ab

Quellbedingungen

Das inkrementelle Jobprofil akzeptiert eine zurückgehaltene Originalquelle, einschließlich unterstützter verschlüsselter PDFs, und einen unveränderten geladenen Objektgraphen; geben Sie password in der sign-Operation für eine verschlüsselte Quelle an, getrennt von pfxPassword

Das Quellpasswort authentifiziert einen unabhängigen Roh-Snapshot, initialisiert den ursprünglichen Verschlüsselungskontext und öffnet den signierten Kandidaten erneut; die entstehende inkrementelle Revision bewahrt das ursprüngliche Ciphertext-Präfix, das Security-Dictionary und die permanente Dokument-ID

Entschlüsselung kann intern Objekte als dirty markieren oder ein Security-Dictionary aus dem entschlüsselten Graphen entfernen; die Operation vergleicht diese Zustände und begrenzte Objektserialisierungen gegen eine frisch authentifizierte Quellbaseline und lehnt tatsächliche Graphänderungen sowie alle geflushten Objektzustände ab

Bei einem Benutzerpasswort braucht ein vorhandenes Signaturfeld die Formularfüll- oder Anmerkungs-Berechtigung, und ein neues Signaturwidget braucht die Anmerkungs-Berechtigung; ein authentifiziertes Owner-Passwort autorisiert beide Operationen, vorbehaltlich vorhandener Signaturpolicies

SaveLoadedDocumentToStream kann den Serialisierungszustand ändern; wenn Sie einen gespeicherten oder bearbeiteten Graphen signieren, laden Sie die gespeicherten Bytes in ein neues Handle und signieren Sie diese Revision

Halten Sie den ursprünglichen Quellspeicher über die Handle-Lebensdauer stabil; Dateijobs verweigern Write-Sharing, während sie ihren Snapshot laden und vorbereiten

Das ursprüngliche Handle behält seine Feldzähler, die Identität vorhandener Felder, Formularwerte, Quellbytes und die bisherigen Launch- und Decode-Einstellungen; jeder Signiererfolg liefert documentUpdated: false, und Signierfehler lassen das Handle für Abfragen, Speichern oder einen späteren gültigen Request verfügbar

Dateijobs lehnen einen Ausgabepfad ab, der gleich der Eingabedatei ist oder Alias dazu, einschließlich Hard Links; direkte Stream-APIs lehnen erkennbare Quellstream- und Quelldatei-Aliase ab, und Aufrufer müssen zudem opaken Callback-Ausgabespeicher vom Eingabespeicher getrennt halten

Vorbereitung und Validierung

Die Operation kopiert rohe Quellbytes in einen exklusiv erzeugten temporären Snapshot, öffnet einen unabhängigen inkrementellen Klon, hängt den Platzhalter über das begrenzte SaveIncrementalUpdate an und füllt das detachierte CMS über den nativen PFX-Stream-Signer

Die PFX bleibt geöffnet, mit verweigertem Write-Sharing vom Größen-Preflight bis zum Signieren; temporäre Dateien verwenden CREATE_NEW und werden nur entfernt, wenn die Operation ihre Erzeugung selbst veranlasst hat

Der signierte Kandidat muss das exakte Quellbyte-Präfix und die erwarteten Formular- und Signaturfeldzähler enthalten; die neue Signatur muss in ihrem gewählten Feld verifizieren, jede zuvor gesetzte Signatur muss weiterhin verifizieren, und die Revisionsanalyse jeder alten Signatur muss DocMDP-, FieldMDP-, Nutzungsrechts- und Identitäts-Constraints akzeptieren

Nicht gesetzte alte Felder bleiben erhalten, ohne als preservedSignatures gezählt zu werden; fehlerhafte, ungültige oder policyverletzende vorhandene Signaturen führen zur Ablehnung vor der Binärveröffentlichung

Die Verifikation vorhandener Signaturen prüft die CMS-Integrität gegen signierte Bytes und die native Revisionspolicy; wenn für die neue Signatur ein Timestamp angefordert wird, validiert seine Antwort gesondert explizites TSA-Vertrauen und konfigurierte Widerrufsnachweise vor der Veröffentlichung

Budgets und Veröffentlichung

Die effektive Ausgabegrenze ist min(outputBytes, memoryBytes / 8) und umfasst das gesamte Quellpräfix, angehängte Objekte, xref und die Signaturreservierung; effectiveOutputLimit meldet die angewandte Grenze

Der unsignierte Kandidat und die signierte Ausgabe sind jeweils durch diese Grenze begrenzt, PFX-Bytes sind auf memoryBytes / 8 gedeckelt, und die Decode-Budgets für Quellbaseline, Klon und Kandidat sind separat auf memoryBytes / 8 begrenzt, mit File-Spilling-Schwellen von höchstens 1 MiB

Das sind Operations- und Pufferbudgets, keine strikte Prozess-RSS-Garantie; Kryptografie, Objektmetadaten, Revisionsanalyse und die bereits geladene Quelle des Aufrufers können zusätzlichen residenten Speicher benötigen

Abbruch- und Ablaufzeit-Prüfungen greifen bei Quellkopie, Delta-Serialisierung und -kopie, Kandidaten-Lesevorgängen, Signaturverifikations-Lesevorgängen, Revisionsanalyse-Lesevorgängen und der Callback-Veröffentlichung; hartnäckige native Stream-Fehler behalten ihre Budget- oder Abbruchkategorie an der Jobgrenze

Die Binärausgabe wird vor dem ersten Output-Callback gestuft und validiert, und die Größe des Ergebnis-JSON wird vor der Binärveröffentlichung geprüft; das Callback-Output selbst ist nicht atomar, daher kann ein fehlgeschlagener Binär- oder Ergebnis-Callback Bytes hinterlassen, die der Aufrufer verwerfen muss

Dateijobs schreiben in einen eigenen Kandidaten im selben Verzeichnis, flushen ihn, schließen Quell- und Ausgabe-Handles und ersetzen ein davon getrenntes Ziel atomar nach erfolgreicher Validierung; Fehler bewahren ein vorhandenes Ziel

Erfolg liefert mediaType: application/pdf, fieldName, profile, incremental, existingField, certificationPermission, revocationInfo, appearanceProfile, preservedSignatures, effectiveOutputLimit, outputBytes und documentUpdated: false

Replay-Abnahme

$env:HOTPDF_SUPPRESS_AUTO_LAUNCH = '1'
./Tests/CABI/Run-IncrementalSigningAcceptance.ps1 -BuildDLL -CheckFPC

Der Runner findet RAD Studio über dessen Registry-RootDir, akzeptiert RADStudioRoot- und PythonExecutable-Overrides und nutzt die konfigurierte FPC-Toolchain, wenn CheckFPC gewählt ist; FPCOnly spielt nur diese nativen Ziele erneut, während OpenSSLWin32Library und OpenSSLWin64Library passende Laufzeitbibliotheken je Architektur wählen

Der nicht-GUI-Runner prüft sowohl die Win32- als auch die Win64-nativen APIs und echte C-ABI-DLLs mit partiellen Callbacks, vorhandenen leeren Feldern, früheren Signaturen, erforderlichen Seed-Werten, echtem SHA384- und SHA512-CAdES, Unicode-Metadaten, erlaubten und gesperrten zweiten Signaturen, echten PFX-Zertifikatseigenschaften, AES-128- und AES-256-Feldsperren-Transformationen, Berechtigungsbeschränkungen und Owner-Credentials, falschen Passwörtern, dirty entschlüsselten Graphen, exakten verschlüsselten Quell-Snapshots, verschlüsselter In-Place-Writer-Wiederherstellung, echten DocMDP-P1- und P2-CMS-Fixtures, Budgets, Abbruch, Callback-Fehlern und Quellwiederverwendung nach Fehlern

Unabhängige pypdf-, MuPDF- und OpenSSL-Prüfungen belegen exakte frühere Präfixe und Bytebereiche, unveränderte Verschlüsselung und permanente IDs, durchsuchbaren Originaltext, gültige alte und neue CMS-Werte, die Contents-Verschlüsselungsausnahme der Signatur und die Zurückweisung veränderten signierten Inhalts; independent-proof.json hält die Bytebereiche und Nachweisergebnisse fest