Inkrementella PFX-signeringsjobb

Signeringsoperationen stöder en validerad inkrementell profil som bevarar exakt den ursprungliga PDF-revisionen och varje befintlig kryptografisk signatur, samtidigt som den returnerar en separat signerad artefakt

Välj en profil

{"schemaVersion":1,"type":"sign","profile":"pfx-incremental-document",
 "pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
 "fieldName":"ApprovalTwo","existingField":true,
 "budget":{"memoryBytes":268435456,"outputBytes":134217728,
           "resultBytes":16777216,"timeMilliseconds":60000,
           "objectCount":1000000,"pageCount":1024}}

Standardprofilen pfx-unsigned-document behåller det ursprungliga beteendet och accepterar källor utan några signaturfält; den skapar ett nytt fält med page, x1, y1, x2 och y2 och återställer källgrafen före publiceringen

pfx-incremental-document väljer den nya profilen; incremental: true är en likvärdig väljare när profile utelämnas, och krockar med en explicit annorlunda profil

existingField: true fyller det namngivna tomma signaturfältet utan att lägga till ytterligare ett fält; annars skapar operationen ett nytt fält, och page samt rektangeln identifierar dess widget

Standardvärdet för fieldName är Signature1 och det accepterar 1 till 1024 UTF-8-byte; existingField kräver en inkrementell profil, ett matchande signaturfält och ett frånvarande eller null V-värde

Read-only Ff-bit 1 samt felformade eller utanför intervallet liggande heltalsflaggor avvisas före förberedelsen; ärvda SV- och Lock-dictionaries slås fast med unika semantiska PDF-namn och avgränsad föräldertraversering

Seed-värden och fältlås

digestMethod väljer det verkliga SHA256-, SHA384- eller SHA512-CMS-sammandraget; SHA256 är standard, medan cades: true väljer ETSI.CAdES.detached och inkluderar attributet signing-certificate-v2 som binder det verkliga signeringscertifikatet

reason, location och contactName är UTF-8 JSON-strängar som skrivs som PDF Unicode-textsträngar; obligatoriska seed-skäl jämför sina Unicode-värden, inklusive det speciella enkla punktvärdet som kräver att reason utelämnas

Obligatoriska SV-villkor kontrollerar den verkliga hanteraren, CMS SubFilter, stödd signeringsversion, sammandrag, skäl, certifieringsbehörighet, juridiskt intygande och LockDocument-läge; en obligatorisk tidsstämpel använder applikationstransporten och det explicita tillitsarbetsflödet som beskrivs i Windows-signeringstidsstämplar, obligatoriska signerade återkallningsbelägg använder autentiserad CRL- och OCSP-signering, och obligatoriska namngivna appearances använder verkligt genererade signaturappearance-förinställningar

Obligatoriska SVCert-egenskaper validerar det verkliga PFX-bladcertifikatet och den inkluderade utfärdarkedjan, tillåtna certifikatbyte, certifikatpolicy-OID:er, key usage-bitar och Unicode-subjekt-DN-attribut före signeringen

credentialSourceURL tillhandahåller applikationshävdad legitimationsproveniens för en obligatorisk SVCert-URL; biblioteket jämför den deklarerade URL:en och den stödda URLType:n utan att öppna den endpointen eller autentisera en transportidentitet

Fältlås av typerna All, Include och Exclude skrivs som en indirekt SigFieldLock-dictionary och en matchande FieldMDP-referens bunden till dokumentets Catalog; fältnamn använder PDF Unicode-textsträngar och förblir krypterade i krypterade dokument

Ett signerat Lock P-värde begränsar senare revisioner via den ursprungliga signerade fältpolicyn, oberoende av eventuella DocMDP-behörigheter; tillåtna andrasignaturer bevarar exakt den tidigare revisionen och CMS:en, medan ett låst fält eller en P1-ändring avvisas före publiceringen

Policyuppslag avkodar PDF-name-escapes exakt en gång, inklusive ärvda Parent-namn; dictionaries med duplicerade semantiska namn och ogiltiga eller cykliska föräldrar avvisas före publiceringen, medan giltiga escapade namn behåller sina källbyte

contentsBytes blir 16384 som standard och accepterar 1024 till 1048576; reason, location och contactName fyller den nya signaturdictionaryn

Certifiering och juridiska intyganden

certificationPermission blir 0 som standard för godkännandesignering; 1, 2 eller 3 skapar en certifieringssignatur med den begärda DocMDP-behörigheten, binder Catalog Perms DocMDP till den verkliga indirekta signaturdictionaryn och behåller en eventuell fristående FieldMDP-transform

Certifiering måste vara den första signaturen, och ett dokument kan bara innehålla en certifieringssignatur; felformade Catalog-behörigheter, olösta referenser och DocMDP-värden utan en original signerad fältbindning avvisas

legalAttestation är en valfri Unicode-sträng för certifieringssignering och skrivs till Catalog Legal Attestation; en obligatorisk SV LegalAttestation-lista måste innehålla den valda texten, medan en tom obligatorisk lista kräver att den utelämnas

Befintliga P2- och P3-certifieringssignaturer tillåter senare godkännandesignering när fältlås och revisionspolicy tillåter det; P1-signaturer och låsta fält avvisar ändringar före den binära publiceringen

Källkontrakt

Den inkrementella jobbprofilen accepterar en kvarhållen originalkälla, inklusive stödda krypterade PDF-filer, och en omodifierad laddad objektgraf; ange password i signoperationen för en krypterad källa, skilt från pfxPassword

Källlösenordet autentiserar en fristående rå ögonblicksbild, initierar den ursprungliga krypteringskontexten och öppnar den signerade kandidaten igen; den resulterande inkrementella revisionen bevarar det ursprungliga chiffertextprefixet, security-dictionaryn och permanenta dokument-ID

Dekryptering kan internt markera objekt som dirty eller ta bort en security-dictionary ur den dekrypterade grafen; operationen jämför dessa tillstånd och avgränsade objektserialiseringar mot en färsk autentiserad källbaslinje, medan den avvisar verkliga grafändringar och alla spolade objekttilstånd

För ett användarlösenord kräver ett befintligt signaturfält form-fill- eller annoteringsbehörighet, och en ny signaturwidget kräver annoteringsbehörighet; ett autentiserat ägarlösenord auktoriserar båda operationerna, med befintliga signaturpolicyer som ram

SaveLoadedDocumentToStream kan ändra serialiseringstillståndet; vid signering av en sparad eller redigerad graf, ladda om de sparade byten i ett nytt handle och signera den revisionen

Håll originalkällans lagring stabil under handlens livstid; filjobb nekar delad skrivning medan de läser in och förbereder sin ögonblicksbild

Originalhandeln behåller sina fältantal, befintlig fältidentitet, formulärvärden, källbyte samt tidigare launch- och avkodningsinställningar; varje signeringsframgång returnerar documentUpdated: false, och signeringsfel lämnar handeln tillgänglig för frågning, sparning eller en senare giltig begäran

Filjobb avvisar en utdatasökväg som är lika med eller aliasar indatafilen, inklusive hårdlänkar; direkta ström-API:er avvisar igenkännbara källström- och källfilalias, och anropare måste dessutom hålla opak callback-utdatalagring skild från indatalagringen

Förberedelse och validering

Operationen kopierar råa källbyte till en exklusivt skapad tillfällig ögonblicksbild, öppnar en fristående inkrementell klon, lägger till platshållaren via avgränsad SaveIncrementalUpdate och fyller den fristående CMS:en via den native PFX-strömsigneraren

PFX:en förblir öppen med nekad delad skrivning från storleksförkontroll till signering; temporära filer använder CREATE_NEW och tas bara bort när operationen äger deras skapande

Den signerade kandidaten måste innehålla exakt källbyteprefixet och förväntade antal formulär- och signaturfält; den nya signaturen måste verifieras i sitt valda fält, varje tidigare ifylld signatur måste fortfarande verifieras, och varje gammal signaturs revisionsanalys måste acceptera DocMDP-, FieldMDP-, användningsrätts- och identitetsvillkor

Oifyllda gamla fält behålls utan att räknas som preservedSignatures; felformade, ogiltiga eller policybrytande befintliga signaturer ger avvisning före den binära publiceringen

Verifiering av befintliga signaturer kontrollerar CMS-integritet mot signerade byte och native revisionspolicy; när tidsstämpel begärs för den nya signaturen validerar dess svar separat explicit TSA-tillit och konfigurerade återkallningsbelägg före publiceringen

Budgeter och publicering

Den effektiva utdatagränsen är min(outputBytes, memoryBytes / 8) och omfattar hela källprefixet, tillagda objekt, xref och signaturreserveringen; effectiveOutputLimit redovisar den tillämpade gränsen

Den osignerade kandidaten och signerade utdata begränsas separat av den gränsen, PFX-byte takas vid memoryBytes / 8, och budgeter för källbaslinje-, klon- och kandidatavkodning takas separat vid memoryBytes / 8 med filspillingtrösklar på högst 1 MiB

Detta är operations- och buffertbudgeter snarare än en strikt garanti för processens RSS; krypto, objektmetadata, revisionsanalys och anroparens redan laddade källa kan kräva ytterligare resident minne

Kontroller av avbrott och förfluten tid gäller källkopiering, deltaserialisering och -kopiering, kandidatläsningar, signaturverifieringsläsningar, revisionsanalysläsningar och callback-publicering; fastnat native strömfel behåller sin budget- eller avbrottskategori vid jobbgränsen

Binär utdata etableras och valideras före första utdata-callbacket, och resultat-JSON:ens storlek kontrolleras före den binära publiceringen; callback-utdata är i sig inte atomär, så ett misslyckat binärt eller resultat-callback kan lämna byte som anroparen måste förkasta

Filjobb skriver till en egen kandidat i samma katalog, spolar den, stänger käll- och utdatahandles och byter atomärt ett distinkt mål efter godkänd validering; fel bevarar en befintlig destination

Framgång returnerar mediaType: application/pdf, fieldName, profile, incremental, existingField, certificationPermission, revocationInfo, appearanceProfile, preservedSignatures, effectiveOutputLimit, outputBytes och documentUpdated: false

Replay-acceptans

$env:HOTPDF_SUPPRESS_AUTO_LAUNCH = '1'
./Tests/CABI/Run-IncrementalSigningAcceptance.ps1 -BuildDLL -CheckFPC

Runner:n hittar RAD Studio via dess registernyckel RootDir, accepterar åsidosättningarna RADStudioRoot och PythonExecutable och använder det konfigurerade FPC-verktygskedjan när CheckFPC är valt; FPCOnly spelar bara upp de native målen, medan OpenSSLWin32Library och OpenSSLWin64Library väljer matchande runtime-bibliotek per arkitektur

Den icke-GUI-baserade runner:n kontrollerar både Win32- och Win64-native-API:er och verkliga C ABI-DLL:er med partiella callbacks, befintliga tomma fält, tidigare signaturer, obligatoriska seed-värden, verklig SHA384- och SHA512-CAdES, Unicode-metadata, tillåtna och låsta andrasignaturer, verkliga PFX-certifikategenskaper, AES-128- och AES-256-fältlåstransformeringar, behörighetsbegränsningar och ägarlegitimation, felaktiga lösenord, dirty dekrypterade grafer, exakta krypterade källögonblicksbilder, krypterad in-place-skrivaråterhämtning, riktiga DocMDP P1- och P2-CMS-fixtures, budgeter, avbrott, callbackfel och källåteranvändning efter fel

Fristående pypdf-, MuPDF- och OpenSSL-kontroller bevisar exakta tidigare prefix och byteintervall, oförändrad kryptering och permanenta ID:n, sökbar originaltext, giltiga gamla och nya CMS-värden, signaturens Contents-krypteringsundantag och avvisning av ändrat signerat innehåll; independent-proof.json registrerar byteintervallen och bevisresultaten

Relaterade ämnen

Dokumentoperationer, CopyLoadedSourceToStream, SaveIncrementalUpdate, EHPDFIncrementalOutputBudget