Timestamps de firma en Windows

La operación sign de Windows puede solicitar un timestamp RFC3161 genuino a través de un callback síncrono de la aplicación y publicar el PDF solo después de autenticar la respuesta

Opciones de firma

{"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 tiene por defecto false; un valor true exige el callback de transporte de la aplicación y un timestampTrustedCAFile explícito que contenga raíces de certificados PEM confiables

digestMethod selecciona el digest CMS real del documento y el algoritmo de imprint del timestamp entre SHA256, SHA384 o SHA512; el messageImprint hashea los octetos de la firma CMS real exactamente una vez

timestampTrustedCRLFile suministra opcionalmente CRLs PEM; requireTimestampRevocation exige ese archivo y habilita las verificaciones de CRL de issuer y certificados, incluidos los certificados revocados y la evidencia vencida

Los archivos de entrada de trust permanecen abiertos con compartición de escritura denegada durante la firma, y su tamaño combinado se limita a un octavo de memoryBytes antes de que OpenSSL los cargue

Cada solicitud contiene un nonce criptográfico fresco y pide los certificados del TSA; la validación de la respuesta autentica el nonce de la solicitud, el imprint, la firma CMS completa, el binding ESS del certificado de firma, la cadena de certificados y el EKU crítico de timestamp

Transporte del C ABI

Pasa hpdf_signing_operation_v1 a hpdf_document_execute_json_v1, pon operation.struct_size en sizeof(hpdf_signing_operation_v1) y provee timestamp_transport y timestamp_user_data

El prefijo de la operación retiene el layout hpdf_operation_v1 existente y la versión del ABI; las operaciones ordinarias siguen usando la estructura original

El callback recibe el TimeStampReq DER completo y un response_io prestado; escribe el TimeStampResp DER completo a través de response_io.write y devuelve un hpdf_status

El callback se ejecuta en el thread llamador, y los punteros IO de solicitud y respuesta solo son válidos durante esa invocación; la aplicación es dueña del transporte de red, la autenticación, el timeout y la política de conexiones

response_io.is_cancelled consulta los callbacks de cancelación de entrada, salida y resultado de la operación; las escrituras de respuesta aplican un máximo de 16 MiB acotado además a un octavo de memoryBytes antes de copiar la memoria del callback

Un fallo de escritura de respuesta o de cancelación sigue activo para la operación incluso cuando el callback devuelve éxito después; las respuestas fallidas no pueden publicar bytes de PDF

Punto de entrada de servicio Pascal

THPDFJobProcessor.ExecuteLoadedSigningOperation acepta el documento cargado, el objeto JSON de la operación, el stream de salida, el checkpoint, el callback THPDFHeadlessTimestampTransport y el contexto opaco del callback

El transporte Pascal recibe el DER de la solicitud y devuelve el DER de la respuesta; la firma síncrona anidada restaura el contexto del callback envolvente cuando la operación interna retorna

Valores de seed y procedencia

Una restricción de SV TimeStamp requerida se satisface con una respuesta realmente autenticada; cuando el diccionario TimeStamp requerido especifica una URL, timestampURL debe coincidir con ese valor

timestampURL es procedencia de transporte afirmada por la aplicación; comparar la URL declarada no establece la identidad del servidor HTTPS, y la aplicación debe autenticar su endpoint seleccionado

Los file jobs independientes sin callback de aplicación no pueden realizar una solicitud de timestamp; un string de URL solo no puede satisfacer un timestamp requerido

Consulta la firma incremental con PFX y la verificación RFC3161 nativa