CMS 多重主要簽署器
HotPDF 可以建立一個 RFC 5652 SignedData 容器，內含最多 256 個彼此獨立的主要 SignerInfo 記錄
建置要求
每個 THPDFCMSPrimarySignerRequest 都提供自己的憑證與金鑰材料、文件摘要、THPDFCMSSignOptions、選用的 THPDFSignatureProvider 以及提供者金鑰識別碼
HPDFCMSBuildMultiSignedData 會在叫用任何原生金鑰、外部回呼、時間戳記回呼、PDF MAC 回呼或提供者之前先驗證每個要求，避免後面某個無效要求引發本可避免的部分遠端簽署工作
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);確定性合併
HPDFCMSMergeSignedData 針對非同步或分散式簽署工作流程合併已建置好的 CMS 容器，不必重複私密金鑰運算
每個輸入都必須使用定長的 signedData 信封與集合、必須宣告其主要簽署器用到的每個摘要演算法，而且必須帶有位元組完全相同的 encapContentInfo；額外宣告的摘要演算法仍然允許
合併後的容器會為摘要演算法、憑證與撤銷值去重、依 DER 位元組順序排序所有 SET OF 值、保留每個主要簽署器，並把外層版本提高到各輸入要求的最高有效版本
編碼之後刻意無法觀察要求順序，因為 signerInfos 是 DER SET OF；解析與驗證結果因此採用 DER 順序而非要求順序
單一簽署器的建置與單一容器的合併都會完全保留既有的 CMS 位元組
獨立驗證
HPDFParseCMSSignatures、HPDFVerifyCMSSignaturesEx 與 HPDFVerifyCMSSignerReport 為每個主要簽署器回傳獨立結果，包括其屬性、摘要與簽章原則、相符的憑證、時間戳記、反簽章與失敗狀態
格式錯誤或密碼學上無效的簽署器不會抹掉有效的兄弟結果；但只要有一個主要簽署器未成功，彙總布林結果就是 false
佔位符大小估算
HPDFCMSEstimateMultiSignerPlaceholder 在不實際簽署的情況下推導每個簽章長度、以合成簽章值建出精確的去重靜態容器形狀、加總動態回呼保留空間，然後一次性套用設定的全域安全邊際、對齊、最小值與最大值
THPDFCMSPlaceholderEstimateInfo.SignatureBytes 回報所有主要簽署器的總和，cpesMixed 則表示結果中各簽署器使用了不同的估算來源
PDF 工作流程邊界
多重簽署器 API 為消費設定檔允許單一容器內有多個主要簽署器的應用程式公開一般性的 CMS 功能
許多 PDF 簽章與 PAdES 工作流程在每個簽章字典只模型化一個主要簽署器，因此除非接收端設定檔明確接受多重簽署器 CMS，否則請使用分開的 PDF 簽章欄位