Mehrere primäre CMS-Signierer

HotPDF kann einen RFC-5652-SignedData-Container erzeugen, der bis zu 256 unabhängige primäre SignerInfo-Datensätze enthält

Build-Anforderungen

Jede THPDFCMSPrimarySignerRequest liefert ihr eigenes Zertifikat- und Schlüsselmaterial, den Dokument-Digest, THPDFCMSSignOptions, den optionalen THPDFSignatureProvider und die Provider-Schlüsselkennung

HPDFCMSBuildMultiSignedData validiert jede Anforderung, bevor ein nativer Schlüssel, ein externer Callback, ein Zeitstempel-Callback, ein PDF-MAC-Callback oder ein Provider aufgerufen wird, und verhindert so, dass eine ungültige spätere Anforderung unnötige partielle Remote-Signierarbeit verursacht

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

Deterministische Zusammenführung

HPDFCMSMergeSignedData kombiniert bereits gebaute CMS-Container für asynchrone oder verteilte Signier-Workflows, ohne Private-Key-Operationen zu wiederholen

Jede Eingabe muss Envelopes und Mengen von signedData mit definierter Länge verwenden, jeden von ihren primären Signierern verwendeten Digest-Algorithmus deklarieren und ein byteidentisches encapContentInfo mitführen; zusätzliche deklarierte Digest-Algorithmen bleiben erlaubt

Der zusammengeführte Container dedupliziert Digest-Algorithmen, Zertifikate und Sperrinformationen, sortiert alle SET OF-Werte nach DER-Bytereihenfolge, bewahrt jeden primären Signierer und hebt die äußere Version auf die höchste gültige Anforderung der Eingaben an

Die Anforderungsreihenfolge ist nach der Codierung absichtlich nicht beobachtbar, weil signerInfos ein DER-SET OF ist; Parsing- und Verifikationsergebnisse verwenden daher die DER-Reihenfolge statt der Anforderungsreihenfolge

Ein Build mit einem Signierer und eine Zusammenführung mit einem Container bewahren die vorhandenen CMS-Bytes exakt

Unabhängige Validierung

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx und HPDFVerifyCMSSignerReport liefern für jeden primären Signierer ein unabhängiges Ergebnis, einschließlich seiner Attribute, Digest- und Signatur-Policy, passenden Zertifikats, Zeitstempel, Gegen-Signaturen und Fehlerstatus

Ein fehlerhafter oder kryptografisch ungültiger Signierer löscht kein gültiges Ergebnis eines Geschwistersignierers, während das aggregierte Boolean-Ergebnis nur dann falsch ist, wenn nicht jeder primäre Signierer erfolgreich ist

Bemessung des Platzhalters

HPDFCMSEstimateMultiSignerPlaceholder leitet jede Signaturlänge ohne zu signieren ab, baut die exakte deduplizierte statische Containerform mit synthetischen Signaturwerten auf, summiert die dynamischen Callback-Reserven und wendet die konfigurierte globale Sicherheitsmarge, Ausrichtung, Minimum und Maximum einmal an

THPDFCMSPlaceholderEstimateInfo.SignatureBytes meldet die Summe für alle primären Signierer und cpesMixed kennzeichnet ein Ergebnis, dessen Signierer unterschiedliche Schätzquellen verwendeten

Grenze des PDF-Workflows

Die Multi-Signierer-APIs stellen generische CMS-Funktionalität für Anwendungen bereit, deren verarbeitendes Profil mehrere primäre Signierer in einem Container zulässt

Viele PDF-Signatur- und PAdES-Workflows modellieren einen primären Signierer pro Signaturwörterbuch; verwenden Sie daher separate PDF-Signaturfelder, sofern das Empfängerprofil Multi-Signierer-CMS nicht ausdrücklich akzeptiert

Siehe CMS-Signierer mit SubjectKeyIdentifier, CMS-Digest-Algorithmus-Konsistenz und automatische CMS-Platzhalterbemessung