Windows Signed Revocation Information

Operacja podpisywania Windows może uwierzytelnić dowody CRL i OCSP, zawrzeć je w podpisanym atrybucie Adobe RevocationInfoArchival i opublikować PDF dopiero po walidacji rzeczywistego wygenerowanego CMS i osadzonych dowodów

Signing options

{"schemaVersion":1,"type":"sign","incremental":true,
 "existingField":true,"fieldName":"ApprovalOne",
 "pfxFile":"C:/keys/signer.pfx","pfxPassword":"password",
 "cades":true,"digestMethod":"SHA384",
 "revocationInfo":{"enabled":true,
   "trustedCAFile":"C:/trust/signing-roots.pem",
   "certificatesBase64":[],"ocspResponsesBase64":[],
   "crlsBase64":["BASE64_DER_CRL"],
   "requireTimestamp":false,"clockSkewSeconds":300,
   "maxOCSPAgeSeconds":86400}}

revocationInfo jest opcjonalne; enabled defaultowo true, gdy obiekt jest dostarczony, a wyłączone dowody nie mogą zawierać certyfikatów, odpowiedzi OCSP ani CRL

trustedCAFile jawnie identyfikuje korzenie zaufania PEM i pozostaje otwarty z odmową współdzielenia zapisu przez całe podpisywanie; walidacja nie ufa ciche certyfikatowi jedynie dlatego, że zawiera go PFX albo dowody

Tablice dowodów zawierają kanoniczne ciągi Base64 kodujące kompletne certyfikaty DER, CRL albo wartości OCSPResponse; co najmniej jedna CRL albo odpowiedź OCSP jest wymagana przy enabled

Standardowy podpisany atrybut zawiera CRL DER i wartości BasicOCSPResponse; kompletne wejścia OCSPResponse są normalizowane przed osadzeniem, a certyfikaty dostarczają dodatkowy materiał łańcucha walidacji

HPDFNormalizeHeadlessOCSPResponse w HPDFHeadlessRevocationInfo odsłania ograniczoną konwersję udanych odpowiedzi dla wywołujących Pascal; waliduje ramowanie DER i ekstrahuje BasicOCSPResponse, podczas gdy walidacja kryptograficzna i statusu pozostaje odpowiedzialnością weryfikatora podpisywania albo LTV

Authenticated evidence

Walidacja uwierzytelnia rzeczywisty podpis CMS, powiązanie certyfikatu podpisującego, jawne zaufanie certyfikatów, ważność certyfikatów, podpisy CRL i interwały ważności oraz podpisy OCSP, autoryzację respondenta, identyfikatory issuer, status odpowiedzi i czasy aktualizacji

Dowody muszą pokryć kompletny niebędący korzeniem łańcuch podpisującego; dowody revokowane, nieznane, wygasłe, niekompletne, nieautoryzowane, niezaufane albo wadliwe nie mogą opublikować PDF

requireTimestamp wymaga rzeczywistego znacznika czasu podpisu i uwierzytelnia dowody także dla swojego łańcucha TSA; użyj transportu aplikacji i odrębnych ustawień zaufania TSA opisanych w Windows signing timestamps

clockSkewSeconds akceptuje od 0 do 86400, a maxOCSPAgeSeconds musi być dodatnie; oba konfigurują walidację czasu dowodów, a nie zmianę zaufania certyfikatów

Seed values and publication

Wymagane ograniczenie SV AddRevInfo true wymaga tego walidowanego workflow podpisanych dowodów; wymagane false wymaga pominięcia atrybutu

Workflow wspiera istniejące i nowo utworzone pola podpisu, pierwsze podpisy certyfikacyjne, kolejne dozwolone podpisy zatwierdzeń, obsługiwane zaszyfrowane źródła i podpisywanie niepodpisanych dokumentów

Plik zaufania i zdekodowane dowody dzielą limit bajtów jednej ósmej memoryBytes; liczby obiektów dowodów są ograniczone mniejszą z objectCount i 4096 przed alokacją

Kanoniczny Base64, ramowanie DER, budżety, anulowanie, integralność CMS i poprawność dowodów są sprawdzane przed publikacją binarną; odrzucone dowody zachowują oryginalny handle dokumentu i nie publikują bajtów PDF, podczas gdy callbacki publikacji zachowują istniejącą semantykę awarii callbacków

Udany wynik raportuje revocationInfo: true dopiero po uwierzytelnieniu rzeczywistego podpisanego atrybutu; wyłączone albo pominięte dowody raportują false

Zobacz HPDFNormalizeHeadlessOCSPResponse po ograniczoną natywną konwersję z kompletnego OCSPResponse do BasicOCSPResponse DER

Zobacz inkrementalne podpisywanie PFX po snapshoty źródła, uprawnienia szyfrowania, wcześniejsze polityki podpisów, budżety wyjścia i semantykę publikacji callbacków