Windows-Signaturzeitstempel

Die Windows-sign-Operation kann einen echten RFC3161-Zeitstempel über einen synchronen Anwendungs-Callback anfordern und das PDF erst nach der Authentifizierung der Antwort veröffentlichen

Signaturoptionen

{"schemaVersion":1,"type":"sign","incremental":true,
 "existingField":true,"fieldName":"ApprovalOne",
 "pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
 "cades":true,"digestMethod":"SHA384","timestamp":true,
 "timestampURL":"https://tsa.example/service",
 "timestampTrustedCAFile":"C:/trust/tsa-roots.pem",
 "timestampTrustedCRLFile":"C:/trust/tsa-crls.pem",
 "requireTimestampRevocation":true}

timestamp hat den Default false; ein true-Wert erfordert den Anwendungs-Transport-Callback und eine explizite timestampTrustedCAFile mit vertrauenswürdigen PEM-Zertifikatsroots

digestMethod wählt den tatsächlichen Dokument-CMS-Digest und Zeitstempel-Imprint-Algorithmus aus SHA256, SHA384 oder SHA512; der messageImprint hasht die tatsächlichen CMS-Signatur-Oktette genau einmal

timestampTrustedCRLFile liefert optional PEM-CRLs; requireTimestampRevocation verlangt diese Datei und aktiviert Issuer- und Zertifikats-CRL-Prüfungen, einschließlich widerrufener Zertifikate und abgelaufener Evidence

Trust-Eingabedateien bleiben während des Signierens mit verweigertem Write-Sharing offen, und ihre kombinierte Größe ist vor dem Laden durch OpenSSL auf ein Achtel von memoryBytes begrenzt

Jede Anforderung enthält eine frische kryptografische Nonce und fordert TSA-Zertifikate an; die Antwortvalidierung authentifiziert die Anforderungs-Nonce, den Imprint, die vollständige CMS-Signatur, die ESS-Signaturzertifikats-Bindung, die Zertifikatskette und die kritische Zeitstempel-EKU

C-ABI-Transport

Übergib hpdf_signing_operation_v1 an hpdf_document_execute_json_v1, setze operation.struct_size auf sizeof(hpdf_signing_operation_v1) und liefere timestamp_transport und timestamp_user_data

Der Operations-Präfix behält das bestehende hpdf_operation_v1-Layout und die ABI-Version; gewöhnliche Operationen nutzen weiterhin die originale Struktur

Der Callback erhält die vollständige DER-TimeStampReq und ein geliehenes response_io; schreibe die vollständige DER-TimeStampResp über response_io.write und gib ein hpdf_status zurück

Der Callback läuft im aufrufenden Thread, und Anforderungs- und Antwort-IO-Zeiger bleiben nur während dieses Aufrufs gültig; die Anwendung besitzt Netzwerktransport, Authentifizierung, Timeout und Verbindungspolicy

response_io.is_cancelled pollt die Input-, Output- und Ergebnis-Abbruch-Callbacks der Operation; Antwort-Schreibzugriffe erzwingen ein Maximum von 16 MiB, zusätzlich gedeckelt auf ein Achtel von memoryBytes, bevor Callback-Speicher kopiert wird

Ein Antwort-Schreib- oder Abbruchfehler bleibt für die Operation aktiv, selbst wenn der Callback danach Erfolg zurückgibt; fehlgeschlagene Antworten können keine PDF-Bytes veröffentlichen

Pascal-Service-Einstieg

THPDFJobProcessor.ExecuteLoadedSigningOperation akzeptiert das geladene Dokument, das Operations-JSON-Objekt, den Output-Stream, den Checkpoint, den THPDFHeadlessTimestampTransport-Callback und einen opaken Callback-Kontext

Der Pascal-Transport erhält Anforderungs-DER und liefert Antwort-DER zurück; verschachteltes synchrones Signieren stellt den umgebenden Callback-Kontext wieder her, wenn die innere Operation zurückkehrt

Seed-Werte und Provenienz

Eine erforderliche SV-TimeStamp-Beschränkung wird durch eine echte authentifizierte Antwort erfüllt; wenn das erforderliche TimeStamp-Dictionary eine URL angibt, muss timestampURL diesem Wert entsprechen

timestampURL ist eine von der Anwendung behauptete Transport-Provenienz; der Vergleich der deklarierten URL begründet keine HTTPS-Server-Identität, und die Anwendung muss ihren gewählten Endpoint authentifizieren

Eigenständige File-Jobs ohne Anwendungs-Callback können keine Zeitstempelanforderung ausführen; ein URL-String allein kann einen erforderlichen Zeitstempel nicht erfüllen

Siehe inkrementelles PFX-Signieren und native RFC3161-Verifizierung