Timestamps de assinatura em Windows

A operação de assinatura de Windows pode pedir um timestamp RFC3161 genuíno através de um callback síncrono de aplicações e publicar o PDF apenas depois de autenticar a resposta

Opções de assinatura

{"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 tem por defeito false; um valor true exige o callback de transports da aplicação e um timestampTrustedCAFile explícito contendo raízes fidedignas de certificados PEM

digestMethod seleciona o digest real CMS do documento e o algoritmo do imprint de timestamps de SHA256, SHA384 ou SHA512; o messageImprint calcula o hash dos octetos reais da assinatura CMS exatamente uma vez

timestampTrustedCRLFile fornece opcionalmente CRLs PEM; requireTimestampRevocation exige esse ficheiro e ativa verificações de emissores e de CRLs de certificados, incluindo certificados revogados e evidência expirada

Ficheiros de entrada de confiança permanecem abertos com partilha de escrita negada durante a assinatura, e o tamanho combinado deles é limitado a um oitavo de memoryBytes antes de o OpenSSL os carregar

Cada pedido contém um nonce criptográfico fresco e pede certificados TSA; a validação de respostas autentica o nonce do pedido, o imprint, a assinatura CMS completa, o binding ESS signing-certificate, a cadeia de certificados e o EKU crítico de timestamps

Transport da ABI C

Passe hpdf_signing_operation_v1 a hpdf_document_execute_json_v1, defina operation.struct_size como sizeof(hpdf_signing_operation_v1) e forneça timestamp_transport e timestamp_user_data

O prefixo da operação mantém o layout existente de hpdf_operation_v1 e a versão da ABI dele; operações ordinárias continuam a usar a estrutura original

O callback recebe o TimeStampReq DER completo e um response_io emprestado; escreva o TimeStampResp DER completo através de response_io.write e devolva um hpdf_status

O callback corre na thread chamadora, e os ponteiros de IO de pedidos e de respostas permanecem válidos apenas durante essa invocação; a aplicação é dona da política dela de transports de rede, autenticação, timeouts e ligações

response_io.is_cancelled consulta os callbacks de cancelamento da operação de entrada, de saída e de resultados; escritas de respostas impõem um máximo de 16 MiB adicionalmente limitado a um oitavo de memoryBytes antes de copiar memória de callbacks

Uma falha de escrita de respostas ou de cancelamento permanece ativa para a operação mesmo quando o callback devolve depois sucesso; respostas falhadas não podem publicar bytes PDF

Ponto de entrada de serviços Pascal

THPDFJobProcessor.ExecuteLoadedSigningOperation aceita o documento carregado, o objeto JSON de operações, a stream de saída, o checkpoint, o callback THPDFHeadlessTimestampTransport e o contexto opaco de callbacks

O transport Pascal recebe DER de pedidos e devolve DER de respostas; assinatura síncrona aninhada restaura o contexto envolvente de callbacks quando a operação interior devolve

Valores de seeds e proveniência

Uma restrição exigida de SV TimeStamp é satisfeita por uma resposta real autenticada; quando o dicionário exigido de TimeStamp especifica um URL, timestampURL tem de corresponder a esse valor

timestampURL é proveniência de transports afirmada pela aplicação; comparar o URL declarado não estabelece a identidade do servidor HTTPS, e a aplicação tem de autenticar o endpoint selecionado por ela

Trabalhos autónomos de ficheiros sem um callback de aplicações não podem realizar um pedido de timestamps; uma string de URL isolada não pode satisfazer um timestamp exigido

Veja a assinatura PFX incremental e a verificação nativa RFC3161