Signers primarios múltiples en CMS

HotPDF puede crear un contenedor RFC 5652 SignedData con hasta 256 registros SignerInfo primarios independientes

Solicitudes de construcción

Cada THPDFCMSPrimarySignerRequest aporta su propio certificado y key material, digest del documento, THPDFCMSSignOptions, un THPDFSignatureProvider opcional y el key identifier del provider

HPDFCMSBuildMultiSignedData valida todas las solicitudes antes de invocar cualquier clave nativa, callback externo, callback de timestamp, callback de PDF MAC o provider, evitando que una solicitud posterior inválida genere trabajo de firma remota parcial evitable

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

Mezcla determinista

HPDFCMSMergeSignedData combina contenedores CMS ya construidos para flujos de firma asíncronos o distribuidos, sin repetir operaciones de clave privada

Cada entrada debe usar envoltorios y conjuntos signedData de longitud definida, debe declarar cada algoritmo de digest que usen sus signers primarios y debe llevar un encapContentInfo idéntico byte a byte; los algoritmos de digest declarados adicionales siguen estando permitidos

El contenedor mezclado deduplica algoritmos de digest, certificados y valores de revocación, ordena todos los valores SET OF por orden de bytes DER, conserva cada signer primario y eleva la versión externa al requisito de entrada válido más alto

El orden de las solicitudes no es observable a propósito después de la codificación porque signerInfos es un SET OF DER; por eso el parseo y los resultados de verificación usan el orden DER, no el orden de solicitud

Una construcción de un solo signer y una mezcla de un solo contenedor conservan los bytes CMS existentes exactamente

Validación independiente

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx y HPDFVerifyCMSSignerReport devuelven un resultado independiente para cada signer primario, incluyendo sus atributos, política de digest y firma, certificado coincidente, timestamps, counter-signatures y estado de fallo

Un signer malformado o criptográficamente inválido no borra el resultado válido de un signer hermano, mientras que el resultado booleano agregado es falso a menos que todos los signers primarios tengan éxito

Dimensionamiento del placeholder

HPDFCMSEstimateMultiSignerPlaceholder deriva la longitud de cada firma sin firmar, construye la forma estática exacta del contenedor deduplicado con valores de firma sintéticos, suma las reservas de callbacks dinámicos y aplica una sola vez el margen de seguridad global, la alineación, el mínimo y el máximo configurados

THPDFCMSPlaceholderEstimateInfo.SignatureBytes reporta la suma de todos los signers primarios y cpesMixed identifica un resultado cuyos signers usaron fuentes de estimación distintas

Límite del flujo PDF

Las APIs multi-signer exponen funcionalidad CMS genérica para aplicaciones cuyo perfil de consumo permite varios signers primarios en un contenedor

Muchos flujos de firma PDF y PAdES modelan un signer primario por diccionario de firma, así que use campos de firma PDF separados a menos que el perfil del destinatario acepte explícitamente CMS multi-signer

Consulte los signers CMS SubjectKeyIdentifier, la consistencia de algoritmos de digest CMS y el auto-dimensionamiento de placeholders CMS