Horodatages de signature Windows

L'opération de signature Windows peut demander un véritable horodatage RFC3161 via un callback applicatif synchrone et publier le PDF uniquement après authentification de la réponse

Options de signature

{"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 vaut false par défaut ; une valeur true exige le callback de transport applicatif et un timestampTrustedCAFile explicite contenant des racines de certificats PEM de trust

digestMethod sélectionne le digest CMS réel du document et l'algorithme d'empreinte d'horodatage parmi SHA256, SHA384 ou SHA512 ; le messageImprint hache les octets de la signature CMS réelle exactement une fois

timestampTrustedCRLFile fournit optionnellement des CRL PEM ; requireTimestampRevocation exige ce fichier et active les vérifications de CRL d'émetteur et de certificats, y compris les certificats révoqués et les preuves expirées

Les fichiers d'entrée de trust restent ouverts avec le partage en écriture refusé pendant la signature et leur taille combinée est limitée à un huitième de memoryBytes avant que OpenSSL ne les charge

Chaque requête contient un nonce cryptographique frais et demande les certificats TSA ; la validation de réponse authentifie le nonce de requête, l'empreinte, la signature CMS complète, la liaison de certificat signataire ESS, la chaîne de certificats et l'EKU d'horodatage critique

Transport C ABI

Passez hpdf_signing_operation_v1 à hpdf_document_execute_json_v1, réglez operation.struct_size à sizeof(hpdf_signing_operation_v1) et fournissez timestamp_transport et timestamp_user_data

Le préfixe d'opération conserve le layout hpdf_operation_v1 existant et la version de l'ABI ; les opérations ordinaires continuent d'utiliser la structure d'origine

Le callback reçoit le TimeStampReq DER complet et un response_io emprunté ; écrivez le TimeStampResp DER complet via response_io.write et retournez un hpdf_status

Le callback s'exécute sur le thread appelant, et les pointeurs IO de requête et de réponse ne restent valides que pendant cet appel ; l'application possède le transport réseau, l'authentification, le timeout et la politique de connexion

response_io.is_cancelled interroge les callbacks d'annulation d'entrée, de sortie et de résultat de l'opération ; les écritures de réponses appliquent un maximum de 16 Mio en outre plafonné à un huitième de memoryBytes avant la copie de la mémoire du callback

Un échec d'écriture de réponse ou d'annulation reste actif pour l'opération même quand le callback retourne ensuite un succès ; des réponses en échec ne peuvent pas publier d'octets PDF

Point d'entrée de service Pascal

THPDFJobProcessor.ExecuteLoadedSigningOperation accepte le document chargé, l'objet JSON d'opération, le stream de sortie, le checkpoint, le callback THPDFHeadlessTimestampTransport et le contexte de callback opaque

Le transport Pascal reçoit le DER de requête et retourne le DER de réponse ; une signature synchrone imbriquée restaure le contexte de callback englobant quand l'opération interne retourne

Valeurs de seed et provenance

Une contrainte SV TimeStamp requise est satisfaite par une véritable réponse authentifiée ; quand le dictionnaire TimeStamp requis spécifie une URL, timestampURL doit correspondre à cette valeur

timestampURL est une provenance de transport affirmée par l'application ; comparer l'URL déclarée n'établit pas l'identité du serveur HTTPS, et l'application doit authentifier son endpoint sélectionné

Les file jobs autonomes sans callback applicatif ne peuvent pas effectuer de requête d'horodatage ; une simple chaîne d'URL ne peut pas satisfaire un horodatage requis

Voir la signature PFX incrémentale et la vérification RFC3161 native