CMS meerdere primaire ondertekenaars

HotPDF kan één RFC-5652-SignedData-container maken die maximaal 256 onafhankelijke primaire SignerInfo-records bevat

Aanvragen opbouwen

Elke THPDFCMSPrimarySignerRequest levert zijn eigen certificaat- en sleutelmateriaal, document-digest, THPDFCMSSignOptions, optionele THPDFSignatureProvider en provider-sleutelidentificatie

HPDFCMSBuildMultiSignedData valideert elke aanvraag vóór het aanroepen van enige native sleutel, externe callback, tijdsvariantecallback, PDF-MAC-callback of provider, waardoor een ongeldige latere aanvraag geen vermijdbare gedeeltelijke externe ondertekeningsarbeid veroorzaakt

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 samenvoeging

HPDFCMSMergeSignedData combineert reeds opgebouwde CMS-containers voor asynchrone of gedistribueerde ondertekeningswerkstromen zonder privé-sleutelbewerkingen te herhalen

Elke invoer moet definoorspronkelijke-lengte-signedData-enveloppen en -verzamelingen gebruiken, elk digestalgoritme declareren dat door de primaire ondertekenaars wordt gebruikt en byte-identieke encapContentInfo dragen; extra gedeclareerde digestalgoritmen blijven toegestaan

De samengevoegde container verwijdert dubbele digestalgoritmen, certificaten en herroepingswaarden, sorteert alle SET OF-waarden op DER-bytevolgorde, behoudt elke primaire ondertekenaar en verhoogt de buitenste versie naar de hoogste geldige invoervereiste

Aanvraagvolgorde is na codering bewust niet waarneembaar omdat signerInfos een DER-SET OF is; parse- en verificatieresultaten gebruiken daarom DER-volgorde in plaats van aanvraagvolgorde

Een één-ondertekenaar-opbouw en een één-container-samenvoeging behouden de bestaande CMS-bytes exact

Onafhankelijke validatie

HPDFParseCMSSignatures, HPDFVerifyCMSSignaturesEx en HPDFVerifyCMSSignerReport retourneren een onafhankelijk resultaat voor elke primaire ondertekenaar, inclusief de attributen, digest- en handtekeningbeleid, overeenkomend certificaat, tijdstempels, meervoudige handtekeningen en faalstatus

Een verkeerd gevormde of cryptografisch ongeldige ondertekenaar wist geen geldig siblingresultaat, terwijl het geaggregeerde booleaanse resultaat onwaar is tenzij elke primaire ondertekenaar slaagt

Plaatsaanduiding-formaat

HPDFCMSEstimateMultiSignerPlaceholder leidt elke handtekeninglengte af zonder te ondertekenen, bouwt de exacte gedupliceerde statische containervorm met synthetische handtekeningwaarden, sommeert dynamische callback-reserves en past de geconfigureerde wereldwijde veiligheidsmarge, uitlijning, minimum en maximum één keer toe

THPDFCMSPlaceholderEstimateInfo.SignatureBytes rapporteert de som voor alle primaire ondertekenaars en cpesMixed identificeert een resultaat waarvan de ondertekenaars verschillende geschatte bronnen gebruikten

PDF-werkstroomgrens

De multi-ondertekenaar-API's bieden generieke CMS-functionaliteit voor toepassingen waarvan het consumerende profiel meerdere primaire ondertekenaars in één container toestaat

Veel PDF-handtekening- en PAdES-werkstromen modelleren één primaire ondertekenaar per handtekeningwoordenlijst, dus gebruik afzonderlijke PDF-handtekeningvelden tenzij het ontvangstprofiel expliciet multi-ondertekenaar-CMS accepteert

Zie CMS-SubjectKeyIdentifier-ondertekenaars, CMS-digestalgoritme-consistentie en CMS-plaatsaanduiding-autoformaat