Wielu głównych podpisujących CMS

HotPDF potrafi utworzyć jeden kontener SignedData z RFC 5652 zawierający do 256 niezależnych głównych rekordów SignerInfo

Budowanie żądań

Każde THPDFCMSPrimarySignerRequest dostarcza własny certyfikat i materiał klucza, skrót dokumentu, THPDFCMSSignOptions, opcjonalnego THPDFSignatureProvider oraz identyfikator klucza dostawcy

HPDFCMSBuildMultiSignedData waliduje każde żądanie przed wywołaniem czegokolwiek: natywnego klucza, zewnętrznego wywołania zwrotnego, wywołania zwrotnego znacznika czasu, wywołania zwrotnego PDF MAC czy dostawcy — dzięki czemu późniejsze nieprawidłowe żądanie nie powoduje dającej się uniknąć częściowej zdalnej pracy podpisującej

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

Deterministyczne scalanie

HPDFCMSMergeSignedData łączy już zbudowane kontenery CMS dla asynchronicznych lub rozproszonych workflow podpisywania, bez powtarzania operacji klucza prywatnego

Każde wejście musi używać kopert i zestawów signedData o długości określonej, musi deklarować każdy algorytm skrótu używany przez swoje główne podpisujące i musi nieść bajtowo identyczne encapContentInfo; dodatkowe zadeklarowane algorytmy skrótów pozostają dozwolone

Scalony kontener deduplikuje algorytmy skrótów, certyfikaty i wartości unieważnienia, sortuje wszystkie wartości SET OF po kolejności bajtów DER, zachowuje każdego głównego podpisującego i podnosi wersję zewnętrzną do najwyższego wymagania poprawnego wejścia

Kolejność żądań jest celowo nieobserwowalna po zakodowaniu, bo signerInfos to DER SET OF; wyniki parsowania i weryfikacji używają zatem kolejności DER, a nie kolejności żądań

Budowa z jednym podpisującym i scalanie jednego kontenera zachowują istniejące bajty CMS co do bajta

Niezależna walidacja

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx i HPDFVerifyCMSSignerReport zwracają niezależny wynik dla każdego głównego podpisującego, wliczając jego atrybuty, politykę skrótu i podpisu, pasujący certyfikat, znaczniki czasu, kontrpodpisy i status awarii

Wadliwy lub kryptograficznie niepoprawny podpisujący nie kasuje poprawnego wyniku sąsiedniego, natomiast zagregowany wynik logiczny to false, chyba że każdy główny podpisujący się powiedzie

Wymiarowanie placeholderów

HPDFCMSEstimateMultiSignerPlaceholder wylicza długość każdego podpisu bez podpisywania, buduje dokładny zdeduplikowany kształt statycznego kontenera z syntetycznymi wartościami podpisów, sumuje dynamiczne rezerwy wywołań zwrotnych i jednorazowo stosuje skonfigurowany globalny margines bezpieczeństwa, wyrównanie, minimum i maksimum

THPDFCMSPlaceholderEstimateInfo.SignatureBytes raportuje sumę dla wszystkich głównych podpisujących, a cpesMixed identyfikuje wynik, którego podpisujący użyli różnych źródeł szacowania

Granica workflow PDF

API wielopodpisowe wystawiają ogólną funkcjonalność CMS dla aplikacji, których profil konsumujący dopuszcza kilku głównych podpisujących w jednym kontenerze

Wiele workflow podpisów PDF i PAdES modeluje jednego głównego podpisującego na słownik podpisu, więc używaj osobnych pól podpisu PDF, dopóki profil odbiorcy nie akceptuje wprost wielopodpisowego CMS

Zobacz podpisujących CMS SubjectKeyIdentifier, spójność algorytmów skrótów CMS i automatyczne wymiarowanie placeholderów CMS