CMS Multiple Primary Signers

HotPDF kan oprette én RFC 5652 SignedData-container, der indeholder op til 256 uafhængige primære SignerInfo-poster

Build-anmodninger

Hvert THPDFCMSPrimarySignerRequest leverer sit eget certifikat- og nøglemateriale, dokument-digest, THPDFCMSSignOptions, valgfri THPDFSignatureProvider og udbyderens nøgleidentifikator

HPDFCMSBuildMultiSignedData validerer hver anmodning, før den påkalder en indbygget nøgle, ekstern callback, tidsstempel-callback, PDF-MAC-callback eller udbyder, hvilket forhindrer, at en ugyldig senere anmodning forårsager undgåeligt delvist eksternt signeringsarbejde

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

Deterministisk sammenlægning

HPDFCMSMergeSignedData kombinerer allerede byggede CMS-containere til asynkrone eller distribuerede signerings-workflows uden at gentage private-nøgle-operationer

Hver indgang skal bruge signedData-konvolutter og -mængder med fast længde, skal erklære enhver digest-algoritme, der bruges af dens primære underskrivere, og skal bære byte-identiske encapContentInfo; yderligere erklærede digest-algoritmer forbliver tilladt

Den sammenlagte container fjerner dubletter blandt digest-algoritmer, certifikater og tilbagekaldelsesværdier, sorterer alle SET OF-værdier efter DER-byterækkefølge, bevarer enhver primær underskriver og hæver den ydre version til det højeste gyldige krav fra en indgang

Anmodningsrækkefølgen er bevidst ikke observerbar efter kodning, fordi signerInfos er en DER SET OF; parse- og verifikationsresultater bruger derfor DER-rækkefølge frem for anmodningsrækkefølge

En build med én underskriver og en sammenlægning med én container bevarer de eksisterende CMS-bytes præcist

Uafhængig validering

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx og HPDFVerifyCMSSignerReport returnerer et uafhængigt resultat for hver primær underskriver, inklusive dens attributter, digest- og signaturpolitik, matchende certifikat, tidsstempler, kontrasignaturer og fejlstatus

En fejlbehæftet eller kryptografisk ugyldig underskriver sletter ikke et gyldigt søskenderesultat, mens det aggregerede boolske resultat er falsk, medmindre hver primær underskriver lykkes

Placeholder-dimenstering

HPDFCMSEstimateMultiSignerPlaceholder udleder hver signaturlængde uden at signere, bygger den præcise deduplikerede statiske containerform med syntetiske signaturværdier, summerer dynamiske callback-reserver og anvender den konfigurerede globale sikkerhedsmargin, justering, minimum og maksimum én gang

THPDFCMSPlaceholderEstimateInfo.SignatureBytes rapporterer summen for alle primære underskrivere, og cpesMixed identificerer et resultat, hvis underskrivere brugte forskellige estimatkilder

PDF-workflow-grænse

Multi-underskriver-API'erne frigiver generisk CMS-funktionalitet til programmer, hvis forbrugsprofil tillader flere primære underskrivere i én container

Mange PDF-signatur- og PAdES-workflows modellerer én primær underskriver pr. signaturobjekt, så brug separate PDF-signaturfelter, medmindre modtagerprofilen eksplicit accepterer CMS med flere underskrivere

Se CMS SubjectKeyIdentifier-underskrivere, CMS digest-algoritme-konsistens og CMS-placeholder-auto-dimenstering