CMS con Più Firmatari Primari

HotPDF può creare un unico contenitore SignedData RFC 5652 con fino a 256 record SignerInfo primari indipendenti

Richieste di costruzione

Ogni THPDFCMSPrimarySignerRequest fornisce il proprio certificato e materiale chiave, il digest del documento, un THPDFCMSSignOptions, un THPDFSignatureProvider opzionale e l'identificatore di chiave del provider

HPDFCMSBuildMultiSignedData valida ogni richiesta prima di invocare una chiave nativa, una callback esterna, una callback di timestamp, una callback del PDF MAC o un provider, impedendo che una richiesta successiva non valida causi lavoro di firma remota parziale evitabile

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

Unione deterministica

HPDFCMSMergeSignedData combina contenitori CMS già costruiti per workflow di firma asincroni o distribuiti, senza ripetere le operazioni con chiave privata

Ogni input deve usare buste e insiemi signedData a lunghezza definita, deve dichiarare ogni algoritmo di digest usato dai suoi firmatari primari e deve riportare un encapContentInfo byte-identico; gli algoritmi di digest dichiarati in più restano permessi

Il contenitore unito deduplica algoritmi di digest, certificati e valori di revoca, ordina tutti i valori SET OF per ordine dei byte DER, preserva ogni firmatario primario e porta la versione esterna al più alto requisito valido tra gli input

L'ordine delle richieste non è osservabile dopo la codifica, perché signerInfos è un SET OF DER; i risultati di parsing e verifica usano quindi l'ordine DER e non quello delle richieste

Una costruzione con un solo firmatario e un'unione di un solo contenitore preservano esattamente i byte CMS esistenti

Validazione indipendente

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx e HPDFVerifyCMSSignerReport restituiscono un risultato indipendente per ogni firmatario primario, inclusi attributi, politica di digest e firma, certificato corrispondente, timestamp, controfirme e stato di fallimento

Un firmatario malformato o crittograficamente non valido non cancella il risultato valido di un firmatario adiacente, mentre il risultato booleano aggregato è false a meno che ogni firmatario primario abbia successo

Dimensionamento dei placeholder

HPDFCMSEstimateMultiSignerPlaceholder ricava la lunghezza di ogni firma senza firmare, costruisce la forma statica esatta e deduplicata del contenitore con valori di firma sintetici, somma le riserve dinamiche delle callback e applica una sola volta margine di sicurezza, allineamento, minimo e massimo configurati globalmente

THPDFCMSPlaceholderEstimateInfo.SignatureBytes riporta la somma per tutti i firmatari primari e cpesMixed identifica un risultato i cui firmatari hanno usato sorgenti di stima diverse

Confine con il workflow PDF

Le API multi-signer espongono funzionalità CMS generiche per le applicazioni il cui profilo di consumo ammette più firmatari primari in un solo contenitore

Molti workflow di firma PDF e PAdES modellano un firmatario primario per dizionario di firma, quindi usare campi di firma PDF separati a meno che il profilo del destinatario non accetti esplicitamente CMS multi-signer

Vedere firmatari CMS SubjectKeyIdentifier, coerenza degli algoritmi di digest CMS e auto-dimensionamento dei placeholder CMS