Timestamps de firma en Windows

La operación de firma de Windows puede solicitar un timestamp RFC3161 genuino mediante 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 toma por defecto false; un valor true exige el callback de transporte de la aplicación y un timestampTrustedCAFile explícito con raíces de certificados PEM confiables

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

timestampTrustedCRLFile suministra opcionalmente CRLs PEM; requireTimestampRevocation exige ese fichero y habilita las comprobaciones CRL de issuer y certificado, incluidos certificados revocados y evidencia caducada

Los ficheros de entrada de confianza permanecen abiertos con escritura compartida denegada durante la firma y su tamaño combinado se limita a un octavo de memoryBytes antes de que OpenSSL los cargue

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

Transporte del C ABI

Pasa hpdf_signing_operation_v1 a hpdf_document_execute_json_v1, establece operation.struct_size a sizeof(hpdf_signing_operation_v1) y proporciona timestamp_transport y timestamp_user_data

El prefijo de la operación conserva el layout hpdf_operation_v1 y la versión de ABI existentes; 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 hilo llamador, y los punteros IO de petición y respuesta solo son válidos durante esa invocación; la aplicación posee el 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 recortado además a un octavo de memoryBytes antes de copiar memoria del callback

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

Punto de entrada del 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 de callback

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

Valores de seed y procedencia

Una restricción SV TimeStamp obligatoria se satisface con una respuesta real autenticada; cuando el diccionario TimeStamp obligatorio 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 petición de timestamp; una cadena URL por sí sola no puede satisfacer un timestamp obligatorio

Consulta incremental PFX signing y verificación RFC3161 nativa