Zadania przyrostowego podpisywania PFX

Operacja sign wspiera zwalidowany profil przyrostowy, który zachowuje dokładnie oryginalną rewizję PDF i każdy istniejący podpis kryptograficzny, zwracając osobno podpisany artefakt

Wybór profilu

{"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}}

Domyślny profil pfx-unsigned-document zachowuje oryginalne zachowanie i przyjmuje źródła bez żadnych pól podpisów; tworzy nowe pole używając page, x1, y1, x2 i y2 oraz przywraca graf źródła przed publikacją

pfx-incremental-document wybiera nowy profil; incremental: true to równoważny selektor, gdy profile jest pominięte, i koliduje z jawnie innym profilem

existingField: true wypełnia nazwane puste pole podpisu bez dodawania kolejnego pola; w przeciwnym razie operacja tworzy nowe pole, a page i prostokąt identyfikują jego widget

Domyślna fieldName to Signature1 i przyjmuje od 1 do 1024 bajtów UTF-8; existingField wymaga profilu przyrostowego, pasującego pola podpisu i nieobecnej albo null wartości V

Bit 1 Ff tylko do odczytu i zniekształcone albo poza zakresem flagi całkowite są odrzucane przed przygotowaniem; dziedziczone słowniki SV i Lock są rozwiązywane unikalnymi semantycznymi nazwami PDF i ograniczonym przechodzeniem rodziców

Wartości seed i blokady pól

digestMethod wybiera rzeczywisty digest CMS SHA256, SHA384 albo SHA512; SHA256 jest domyślny, a cades: true wybiera ETSI.CAdES.detached i zawiera atrybut signing-certificate-v2 wiążący rzeczywisty certyfikat podpisujący

reason, location i contactName to łańcuchy JSON UTF-8 zapisywane jako tekstowe łańcuchy PDF Unicode; wymagane powody seed porównują swoje wartości Unicode, włącznie ze specjalną wartością pojedynczej kropki wymagającą pominiętego powodu

Wymagane ograniczenia SV sprawdzają rzeczywisty handler, SubFilter CMS, wspieraną wersję podpisywania, digest, powód, uprawnienie certyfikacji, atestację prawną i tryb LockDocument; wymagany znacznik czasu używa transportu aplikacji i jawnego workflow zaufania opisanego w znacznikach czasu podpisywania Windows, wymagane podpisane dowody odwołań używają uwierzytelnionego podpisywania CRL i OCSP, a wymagane nazwane wyglądy rzeczywistych wygenerowanych presetów wyglądów podpisów

Wymagane właściwości SVCert walidują rzeczywisty certyfikat liścia PFX i dołączony łańcuch wystawców, dozwolone bajty certyfikatów, OID-y polityk certyfikatów, bity key usage i atrybuty DN podmiotu Unicode przed podpisaniem

credentialSourceURL dostarcza pochodzenie poświadczeń deklarowane przez aplikację dla wymaganego URL SVCert; biblioteka porównuje zadeklarowany URL i wspierany URLType bez otwierania tego punktu końcowego ani uwierzytelniania tożsamości transportu

Blokady pól All, Include i Exclude są zapisywane jako pośredni słownik SigFieldLock i pasująca referencja FieldMDP związana z Catalog dokumentu; nazwy pól używają tekstowych łańcuchów PDF Unicode i pozostają zaszyfrowane w dokumentach zaszyfrowanych

Podpisane Lock P ogranicza późniejsze rewizje oryginalną podpisaną polityką pól, niezależnie od uprawnienia DocMDP; dozwolone drugie podpisy zachowują dokładnie poprzednią rewizję i CMS, podczas gdy zablokowane pole albo zmiana P1 jest odrzucana przed publikacją

Wyszukiwanie polityk dekoduje eskapy nazw PDF dokładnie raz, włącznie z dziedziczonymi nazwami Parent; słowniki z zduplikowanymi semantycznymi nazwami i niepoprawne albo cykliczne rodzice są odrzucane przed publikacją, podczas gdy poprawne eskapowane nazwy zachowują swoje bajty źródła

contentsBytes domyślnie 16384 i przyjmuje od 1024 do 1048576; reason, location i contactName wypełniają nowy słownik podpisu

Certyfikacja i atestacje prawne

certificationPermission domyślnie 0 dla podpisywania zatwierdzenia; 1, 2 albo 3 tworzy podpis certyfikacji z żądanym uprawnieniem DocMDP, binduje Catalog Perms DocMDP do rzeczywistego pośredniego słownika podpisu i zachowuje niezależną transformację FieldMDP

Certyfikacja musi być pierwszym podpisem, a dokument może zawierać tylko jeden podpis certyfikacji; zniekształcone uprawnienia Catalog, nierozwiązane referencje i wartości DocMDP bez oryginalnego bindowania podpisanego pola są odrzucane

legalAttestation to opcjonalny łańcuch Unicode dla podpisywania certyfikacji i jest zapisywany do Catalog Legal Attestation; wymagana lista SV LegalAttestation musi zawierać wybrany tekst, a pusta wymagana lista wymaga pominięcia

Istniejące podpisy certyfikacji P2 i P3 pozwalają na późiejsze podpisywanie zatwierdzenia, gdy blokady pól i polityka rewizji na to pozwalają; podpisy P1 i zablokowane pola odrzucają zmiany przed publikacją binarną

Kontrakt źródła

Profil przyrostowego zadania przyjmuje zachowane oryginalne źródło, włącznie ze wspieranymi zaszyfrowanymi PDF-ami, i niemodyfikowany wczytany graf obiektów; dostarcz password w operacji sign dla zaszyfrowanego źródła, osobno od pfxPassword

Hasło źródła uwierzytelnia niezależny surowy snapshot, inicjalizuje oryginalny kontekst szyfrowania i ponownie otwiera podpisanego kandydata; wynikowa rewizja przyrostowa zachowuje oryginalny prefiks szyfrogramu, słownik bezpieczeństwa i trwały ID dokumentu

Deszyfrowanie może wewnętrznie oznaczać obiekty jako brudne albo usunąć słownik bezpieczeństwa z odszyfrowanego grafu; operacja porównuje te stany i ograniczone serializacje obiektów względem świeżeo uwierzytelnionej linii bazowej źródła, odrzucając rzeczywiste zmiany grafu i wszystkie stany wypłukanych obiektów

Dla hasła użytkownika istniejące pole podpisu wymaga uprawnienia wypełniania formularzy albo adnotacji, a nowy widget podpisu wymaga uprawnienia adnotacji; uwierzytelnione hasło właściciela autoryzuje obie operacje, podlega ono istniejącym politykom podpisów

SaveLoadedDocumentToStream może zmienić stan serializacji; przy podpisywaniu zapisanego albo edytowanego grafu przeładuj zapisane bajty do nowego uchwytu i podpisz tę rewizję

Utrzymuj przechowywanie oryginalnego źródła stabilnym przez czas życia uchwytu; joby plikowe odmawiają współdzielenia zapisu podczas wczytywania i przygotowywania swojego snapshotu

Oryginalny uchwyt zachowuje liczniki pól, tożsamość istniejących pól, wartości formularzy, bajty źródła i wcześniejsze ustawienia uruchamiania i dekodowania; każdy sukces podpisywania zwraca documentUpdated: false, a niepowodzenia podpisywania pozostawiają uchwyt dostępny do odpytywania, zapisu albo późniejszego poprawnego żądania

Joby plikowe odrzucają ścieżkę wyjścia równą albo będącą aliasem pliku wejściowego, włącznie z twardymi dowiązaniami; bezpośrednie API strumieni odrzucają rozpoznawalne aliasy strumienia źródła i pliku źródła, a wywołujący muszą tež utrzymać nieprzezroczyste przechowywanie wyjścia callbacka odrębne od przechowywania wejścia

Przygotowanie i walidacja

Operacja kopiuje surowe bajty źródła do wyłącznie utworzonego snapshotu tymczasowego, otwiera niezależny przyrostowy klon, dokleja placeholder przez ograniczony SaveIncrementalUpdate i wypełnia odłączone CMS przez natywnego podpisującego strumień PFX

PFX pozostaje otwarty z odmową współdzielenia zapisu od preflight rozmiaru do podpisania; pliki tymczasowe używają CREATE_NEW i są usuwane tylko, gdy operacja jest właścicielem ich utworzenia

Podpisany kandydat musi zawierać dokładny prefiks bajtów źródła i oczekiwane liczniki pól formularza i podpisów; nowy podpis musi się weryfikować w wybranym polu, każdy wcześniej wypełniony podpis musi nadal się weryfikować, a analiza rewizji każdego starego podpisu musi akceptować ograniczenia DocMDP, FieldMDP, praw użycia i tożsamości

Niewypełnione stare pola są zachowywane bez liczenia ich jako preservedSignatures; zniekształcone, niepoprawne albo naruszające politykę istniejące podpisy powodują odrzucenie przed publikacją binarną

Weryfikacja istniejących podpisów sprawdza integralność CMS względem podpisanych bajtów i natywnej polityki rewizji; gdy znacznik czasu jest żądany dla nowego podpisu, jego odpowiedź osobno waliduje jawne zaufanie TSA i skonfigurowane dowody odwołań przed publikacją

Budżety i publikacja

Efektywny limit wyjścia to min(outputBytes, memoryBytes / 8) i obejmuje kompletny prefiks źródła, doklejane obiekty, xref i rezerwację podpisu; effectiveOutputLimit raportuje zastosowany limit

Niepodpisany kandydat i podpisane wyjście są osobno ograniczone tym limitem, bajty PFX są ograniczone do memoryBytes / 8, a budżety dekodowania linii bazowej źródła, klonu i kandydata są osobno ograniczone do memoryBytes / 8 z progami zrzutu do pliku nie wyższymi niż 1 MiB

To budżety operacji i buforów, a nie ścisła gwarancja RSS procesu; kryptografia, metadane obiektów, analiza rewizji i już wczytane źródło wywołującego mogą wymagać dodatkowej pamięci rezydentnej

Kontrole anulowania i czasu stosują się do kopii źródła, serializacji i kopii delty, odczytów kandydata, odczytów weryfikacji podpisu, odczytów analizy rewizji i publikacji callbacków; lepkie niepowodzenia natywnych strumieni zachowują swoją kategorię budżetu albo anulowania na granicy zadania

Wyjście binarne jest etapowane i walidowane przed pierwszym callbackiem wyjścia, a rozmiar wyniku JSON jest sprawdzany przed publikacją binarną; samo wyjście callbacka nie jest atomowe, więc nieudany callback binarny albo wyniku może zostawić bajty, które wywołujący musi wyrzucić

Joby plikowe zapisują do posiadanego kandydata w tym samym katalogu, flushują go, zamykają uchwyty źródła i wyjścia i atomowo podmieniają odrębny cel po udanej walidacji; niepowodzenia zachowują istniejący cel

Sukces zwraca mediaType: application/pdf, fieldName, profile, incremental, existingField, certificationPermission, revocationInfo, appearanceProfile, preservedSignatures, effectiveOutputLimit, outputBytes i documentUpdated: false

Akceptacja replay

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

Runner odkrywa RAD Studio przez jego rejestrowe RootDir, przyjmuje nadpisania RADStudioRoot i PythonExecutable i używa skonfigurowanej toolchainy FPC, gdy wybrany jest CheckFPC; FPCOnly odtwarza tylko te natywne cele, a OpenSSLWin32Library i OpenSSLWin64Library wybierają pasujące biblioteki runtime dla każdej architektury

Runner nie-GUI sprawdza oba natywne API Win32 i Win64 i rzeczywiste DLL C ABI używając częściowych callbacków, istniejących pustych pól, wcześniejszych podpisów, wymaganych wartości seed, rzeczywistych CAdES SHA384 i SHA512, metadanych Unicode, dozwolonych i zablokowanych drugich podpisów, rzeczywistych właściwości certyfikatów PFX, transformacji blokad pól AES-128 i AES-256, ograniczeń uprawnień i poświadczeń właściciela, niepoprawnych haseł, brudnych odszyfrowanych grafów, dokładnych zaszyfrowanych snapshotów źródła, odzyskiwania writera szyfrowanego w miejscu, rzeczywistych fiksatur CMS DocMDP P1 i P2, budżetów, anulowania, niepowodzeń callbacków i ponownego użycia źródła po niepowodzeniach

Niezależne kontrole pypdf, MuPDF i OpenSSL dowodzą dokładnych wcześniejszych prefiksów i zakresów bajtów, niezmienionego szyfrowania i trwałych ID, przeszukiwalnego oryginalnego tekstu, poprawnych starych i nowych wartości CMS, wyjątku szyfrowania Contents podpisu i odrzucania zmodyfikowanej podpisanej zawartości; independent-proof.json zapisuje zakresy bajtów i wyniki dowodów

Powiązane tematy

Operacje dokumentów, CopyLoadedSourceToStream, SaveIncrementalUpdate, EHPDFIncrementalOutputBudget