Timestamps de assinatura no Windows

A operação sign do Windows pode solicitar um timestamp RFC3161 genuíno através de um callback síncrono da aplicação e publicar o PDF somente 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 default false; um valor true exige o callback de transporte da aplicação e um timestampTrustedCAFile explícito contendo roots PEM confiáveis de certificados

digestMethod seleciona o algoritmo real de digest do CMS do documento e do imprint do timestamp entre SHA256, SHA384 ou SHA512; o messageImprint faz o hash dos octets reais da assinatura CMS exatamente uma vez

timestampTrustedCRLFile opcionalmente fornece CRLs PEM; requireTimestampRevocation exige aquele arquivo e habilita checagens de CRLs de issuers e certificados, incluindo certificados revogados e evidências expiradas

Arquivos de entrada de confiança permanecem abertos com compartilhamento de gravação negado durante a assinatura, e seu tamanho combinado é limitado a um oitavo de memoryBytes antes de o OpenSSL carregá-los

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

Transporte da C ABI

Passe hpdf_signing_operation_v1 para 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 retém o layout hpdf_operation_v1 e a versão da ABI existentes; operações comuns continuam usando a estrutura original

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

O callback roda na thread chamadora, e os ponteiros de IO de requisição e resposta permanecem válidos apenas durante aquela invocação; a aplicação é dona do transporte de rede, autenticação, timeout e política de conexões

response_io.is_cancelled faz polling dos callbacks de cancelamento de entrada, saída e resultado da operação; as gravações de resposta aplicam um máximo de 16 MiB, adicionalmente limitado a um oitavo de memoryBytes, antes de copiar memória do callback

Uma falha de gravação ou cancelamento de resposta permanece ativa para a operação mesmo que o callback retorne sucesso depois; respostas com falha não podem publicar bytes PDF

Entry point de serviço Pascal

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

O transporte Pascal recebe o DER da requisição e retorna o DER da resposta; assinatura síncrona aninhada restaura o contexto envolvente de callbacks quando a operação interna retorna

Valores de seed e proveniência

Uma constraint SV TimeStamp obrigatória é satisfeita por uma resposta real autenticada; quando o dicionário TimeStamp obrigatório especifica uma URL, timestampURL precisa corresponder àquele valor

timestampURL é proveniência de transporte asserida pela aplicação; comparar a URL declarada não estabelece a identidade do servidor HTTPS, e a aplicação precisa autenticar o endpoint que selecionou

File jobs independentes sem um callback da aplicação não conseguem fazer uma requisição de timestamp; uma string de URL sozinha não pode satisfazer um timestamp obrigatório

Veja assinatura PFX incremental e verificação RFC3161 nativa