Múltiplos signatários primários CMS

O HotPDF pode criar um único contêiner SignedData RFC 5652 com até 256 registros SignerInfo primários independentes

Solicitações de construção

Cada THPDFCMSPrimarySignerRequest fornece seu próprio certificado e material de chave, digest do documento, THPDFCMSSignOptions, THPDFSignatureProvider opcional e identificador de chave do provedor

HPDFCMSBuildMultiSignedData valida todas as solicitações antes de invocar qualquer chave nativa, callback externo, callback de carimbo de tempo, callback de PDF MAC ou provedor, evitando que uma solicitação inválida posterior gere trabalho parcial evitável de assinatura remota

SetLength(Signers, 2);
Signers[0].KeyMaterial := FirstKey;
Signers[0].DocumentDigest := HPDFCMSDigestBytes(DocumentBytes, cmsdaSHA256);
Signers[0].Options := FirstOptions;

Signers[1].KeyMaterial := SecondKey;
Signers[1].DocumentDigest := HPDFCMSDigestBytes(DocumentBytes, cmsdaSHA384);
Signers[1].Options := SecondOptions;
Signers[1].Provider := RemoteProvider;
Signers[1].KeyIdentifier := 'approval-key';

CMS := HPDFCMSBuildMultiSignedData(Signers);

Mesclagem determinística

HPDFCMSMergeSignedData combina contêineres CMS já construídos para workflows de assinatura assíncronos ou distribuídos, sem repetir operações de chave privada

Cada entrada deve usar envelopes e conjuntos signedData de comprimento definido, deve declarar todo algoritmo de digest usado por seus signatários primários e deve transportar encapContentInfo byte-idêntico; algoritmos de digest adicionais declarados continuam permitidos

O contêiner mesclado deduplica algoritmos de digest, certificados e valores de revogação, ordena todos os valores SET OF pela ordem de bytes DER, preserva cada signatário primário e eleva a versão externa ao requisito válido mais alto entre as entradas

A ordem das solicitações intencionalmente não é observável após a codificação, porque signerInfos é um SET OF DER; por isso os resultados de análise e verificação usam a ordem DER, e não a ordem das solicitações

Uma construção com um único signatário e uma mesclagem de um único contêiner preservam exatamente os bytes CMS existentes

Validação independente

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx e HPDFVerifyCMSSignerReport retornam um resultado independente para cada signatário primário, incluindo seus atributos, política de digest e assinatura, certificado correspondente, carimbos de tempo, contra-assinaturas e status de falha

Um signatário malformado ou criptograficamente inválido não apaga o resultado válido de um irmão, enquanto o resultado booleano agregado é false a menos que todos os signatários primários tenham sucesso

Dimensionamento de placeholder

HPDFCMSEstimateMultiSignerPlaceholder deriva o comprimento de cada assinatura sem assinar, constrói a forma exata do contêiner estático deduplicado com valores de assinatura sintéticos, soma as reservas dinâmicas de callback e aplica uma única vez a margem de segurança global, o alinhamento, o mínimo e o máximo configurados

THPDFCMSPlaceholderEstimateInfo.SignatureBytes informa a soma de todos os signatários primários, e cpesMixed identifica um resultado cujos signatários usaram fontes de estimativa diferentes

Limite do workflow PDF

As APIs multi-signer expõem funcionalidade CMS genérica para aplicativos cujo perfil consumidor permite vários signatários primários em um contêiner

Muitos workflows de assinatura PDF e PAdES modelam um signatário primário por dicionário de assinatura, então use campos de assinatura PDF separados, a menos que o perfil do destinatário aceite explicitamente CMS multi-signer

Veja CMS SubjectKeyIdentifier signers, CMS digest-algorithm consistency e CMS placeholder auto-sizing