Múltiplos Assinantes Primários CMS

O HotPDF pode criar um contentor SignedData RFC 5652 com até 256 registos independentes de SignerInfo primário

Pedidos de construção

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

HPDFCMSBuildMultiSignedData valida todos os pedidos antes de invocar qualquer chave nativa, callback externo, callback de timestamp, callback de MAC de PDF ou provedor, evitando que um pedido inválido posterior provoque trabalho evitável de assinatura remota parcial

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);

Fusão determinística

HPDFCMSMergeSignedData combina contentores CMS já construídos para fluxos de trabalho de assinatura assíncronos ou distribuídos, sem repetir operações de chave privada

Cada entrada tem de usar envelopes e conjuntos signedData de comprimento definido, declarar todos os algoritmos de digest usados pelos seus assinantes primários e transportar um encapContentInfo byte-idêntico; algoritmos de digest extra declarados continuam permitidos

O contentor fundido elimina duplicados de algoritmos de digest, certificados e valores de revogação, ordena todos os valores SET OF por ordem de bytes DER, preserva todos os assinantes primários e eleva a versão externa ao requisito válido mais alto das entradas

A ordem dos pedidos não é intencionalmente observável após a codificação, porque signerInfos é um SET OF DER; os resultados de análise e verificação usam portanto a ordem DER em vez da ordem dos pedidos

Uma construção com um assinante e uma fusão com um contentor preservam exatamente os bytes CMS existentes

Validação independente

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx e HPDFVerifyCMSSignerReport devolvem um resultado independente para cada assinante primário, incluindo os seus atributos, política de digest e assinatura, certificado correspondente, timestamps, contrassignaturas e estado de falha

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

Dimensionamento de placeholders

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

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

Limite do fluxo de trabalho PDF

As APIs de múltiplos assinantes expõem funcionalidade CMS genérica para aplicações cujo perfil de consumo permite vários assinantes primários num único contentor

Muitos fluxos de trabalho de assinatura PDF e PAdES modelam um assinante primário por dicionário de assinatura, portanto use campos de assinatura PDF separados a menos que o perfil do destinatário aceite explicitamente CMS com múltiplos assinantes

Consulte assinantes CMS com SubjectKeyIdentifier, consistência do algoritmo de digest CMS e dimensionamento automático de placeholders CMS