Signataires primaires multiples CMS

HotPDF peut créer un conteneur SignedData RFC 5652 contenant jusqu'à 256 enregistrements SignerInfo primaires indépendants

Demandes de construction

Chaque THPDFCMSPrimarySignerRequest fournit son propre certificat et matériel de clé, le condensat de document, les THPDFCMSSignOptions, un THPDFSignatureProvider facultatif et un identifiant de clé de fournisseur

HPDFCMSBuildMultiSignedData valide chaque demande avant d'invoquer ne serait-ce qu'une clé native, un callback externe, un callback d'horodatage, un callback MAC PDF ou un fournisseur, empêchant ainsi qu'une demande invalide ultérieure provoque inutilement un travail partiel de signature distante

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

Fusion déterministe

HPDFCMSMergeSignedData combine des conteneurs CMS déjà construits pour des flux de travail de signature asynchrones ou distribués sans répéter les opérations de clé privée

Chaque entrée doit utiliser des enveloppes signedData et des ensembles de longueur définie, doit déclarer chaque algorithme de condensat utilisé par ses signataires primaires, et doit porter un encapContentInfo identique octet par octet ; des algorithmes de condensat supplémentaires déclarés restent autorisés

Le conteneur fusionné déduplique les algorithmes de condensat, les certificats et les valeurs de révocation, trie toutes les valeurs SET OF par ordre d'octets DER, préserve chaque signataire primaire et fait passer la version externe au plus haut besoin d'entrée valide

L'ordre des demandes n'est volontairement pas observable après l'encodage car signerInfos est un SET OF DER ; les résultats d'analyse et de vérification utilisent donc l'ordre DER plutôt que l'ordre des demandes

Une construction à un signataire et une fusion à un conteneur conservent exactement les octets CMS existants

Validation indépendante

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx et HPDFVerifyCMSSignerReport renvoient un résultat indépendant pour chaque signataire primaire, y compris ses attributs, sa politique de condensat et de signature, le certificat correspondant, les horodatages, les contre-signatures et le statut d'échec

Un signataire mal formé ou cryptographiquement invalide n'efface pas un résultat frère valide, tandis que le résultat booléen agrégé est faux à moins que chaque signataire primaire ne réussisse

Dimensionnement du placeholder

HPDFCMSEstimateMultiSignerPlaceholder déduit chaque longueur de signature sans signer, construit la forme exacte du conteneur statique dédupliqué avec des valeurs de signature synthétiques, additionne les réserves dynamiques des callbacks et applique une seule fois la marge de sécurité globale, l'alignement, le minimum et le maximum configurés

THPDFCMSPlaceholderEstimateInfo.SignatureBytes rapporte la somme pour tous les signataires primaires et cpesMixed identifie un résultat dont les signataires ont utilisé des sources d'estimation différentes

Limite du flux de travail PDF

Les API multi-signataires exposent des fonctionnalités CMS génériques pour les applications dont le profil consommateur autorise plusieurs signataires primaires dans un conteneur

De nombreux flux de travail de signature PDF et PAdES modélisent un signataire primaire par dictionnaire de signature, utilisez donc des champs de signature PDF distincts à moins que le profil du destinataire n'accepte explicitement le CMS multi-signataires

Voir signataires CMS SubjectKeyIdentifier, cohérence des algorithmes de condensat CMS, et dimensionnement automatique du placeholder CMS