Tehnički članak

PAdES LTV dokazi i seed vrijednosti u HotPDF-u

PDF koji ste upravo potpisali B-B je potpis i ništa više. Dokazuje tko je potpisao i da se bajtovi nisu pomaknuli, ali ne nosi dokaz da je certifikat potpisnika bio valjan u trenutku potpisivanja, pa validator godinama kasnije mora potražiti podatke o opozivu koji možda više ne postoje. Zatvoriti taj jaz znači upisati OCSP odgovore i CRL-ove u sigurnosnu pohranu Document Security Store na razini dokumenta, a u HotPDF-u to je jedan poziv: PopulatePAdESLTVEvidence prelazi svaki učitani potpis, izvodi zahtjeve za opoziv iz skupa certifikata, izvršava ih kroz transport koji vi opskrbljujete i upisuje doneseni materijal plus CMS lanac u DSS. Vraća broj potpisa čiji su dokazi sletjeli, ili minus jedan kada dokument uopće nema polje potpisa

Dizajnerska odluka vrijedna razumijevanja prije uporabe jest da knjižnica nikad ne otvara utičnicu. Svaki bajt koji stigne iz mreže stiže kroz povratni poziv koji ste napisali. To nije oprez zarad opreza; to je jedini način da ova značajka radi unutar okruženja koja stvarno zahtijevaju dugotrajnu provjeru valjanosti

Zašto knjižnica odbija raditi vlastiti HTTP?

Zato što su mjesta koja zahtijevaju B-LT potpise mjesta gdje se knjižnici ne može vjerovati s mrežom. Servisi potpisivanja rade iza provjeravajućih posrednika s korporativnim korijenima. Potpisne razine odvojene od mreže nemaju put do odgovarača i moraju se hraniti predmemoriranim dokazima. Režimi revizije zahtijevaju da svaki odlazni zahtjev zabilježi aplikacija, a ne da bude zakopan u ovisnosti. I testni skupovi trebaju determinističke odgovore, što je nemoguće ako se knjižnica sama javlja van

Transport je obična referenca na funkciju fiksnog oblika, pa politika ostaje vaša. HotPDF vam predaje zapis zahtjeva koji opisuje točno što treba dohvatiti, uključujući tip sadržaja i gornju granicu veličine odgovora, a vi vraćate bajtove plus stanje

Tijek PopulatePAdESLTVEvidence u HotPDF-u: transport FetchEvidence koji dostavlja pozivatelj, polja zapisa zahtjeva i ishodi stanja po potpisu
Svaki mrežni bajt prolazi kroz vaš povratni poziv FetchEvidence, a svaki potpis dobiva vlastito stanje tako da jedan istek vremena nikad ne prekine prolaz
function FetchEvidence(const Request: THPDFSignatureEvidenceRequest;
  Attempt: Integer; CancellationToken: THPDFCancellationToken;
  out Response: TBytes; out RetryAfterMS: Cardinal;
  out ErrorMessage: UnicodeString): THPDFSignatureEvidenceTransportStatus;
begin
  RetryAfterMS := 0;
  try
    // Request.Kind govori je li ovo OCSP POST ili CRL GET;
    // Request.ContentType i Request.Body već su pripremljeni,
    // a Request.MaxResponseBytes je granica koju morate poštovati
    Response := HttpExchange(Request.URI, Request.ContentType,
      Request.Body, Request.MaxResponseBytes);
    Result := setsSucceeded;
  except
    on E: Exception do
    begin
      ErrorMessage := E.Message;
      // setsRetry dopušta politici ponavljanja da se povuče; koristite
      // setsPermanentFailure za 404 ili loš URL
      Result := setsRetry;
    end;
  end;
end;

// Nadogradnja B-B na B-LT jednim pozivom za svaki potpis u učitanom fajlu
var
  Pdf: THotPDF;
  Upgraded: Integer;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.BeginIncrementalUpdate('signed.pdf');
    Upgraded := Pdf.PopulatePAdESLTVEvidence(FetchEvidence,
      THPDFSignatureEvidenceRetryPolicy.Default);
    if Upgraded > 0 then
      // Spremanje samo uz dodavanje: bajtovi koje postojeći potpisi
      // pokrivaju čuvaju se riječ po riječ
      Pdf.SaveIncrementalUpdate('signed-lt.pdf');
  finally
    Pdf.Free;
  end;
end;

Neuspjesi su po potpisu, ne po dokumentu. Odgovarač koji istekne za jednog potpisnika preskače materijal tog potpisnika i ostavlja ostatak prolaza netaknutim, što je ponašanje koje želite u seriji: djelomični dokazi bolji su od prekinutog izvođenja, a povratna vrijednost vam govori koliko se potpisa stvarno poboljšalo

Lanac koji je CMS zaboravio uključiti

Provjera opoziva treba certifikat izdavatelja, a iznenađujuće mnogo potpisnih stogova izostavlja posrednike iz CMS spremnika. Put oporavka jest proširenje Authority Information Access, metoda pristupa 1.3.6.1.5.5.7.48.2, koje oglašava URL s kojeg se certifikat izdavatelja može preuzeti. HPDFFetchAIAIntermediates prelazi te URL-ove kroz isti transport, raščlanjuje DER iz svakog odgovora i vraća samo certifikate koje CMS već nije nosio, ključane DER sažetkom tako da se duplikati i petlje ne mogu vrtjeti

Dvije pojedinosti odlučuju radi li ovo u odnosu na stvarne ovlasti za izdavanje certifikata. Prva je kodiranje: CA krajnje točke poslužuju certifikat kao goli DER otprilike jednako često kao PEM oklopljen, i nema pouzdanog tipa sadržaja da ih se razlikuje. Robusna proba je tekstualna, zatim strukturna. Potražite oznaku -----BEGIN CERTIFICATE-----, skinite oklop i dekodirajte base64 ako je prisutan, i u oba puta potvrdite da je prvi bajt rezultata $30, DER oznaka za SEQUENCE. Druga je dubina: dohvaćeni posrednik može sam oglašavati AIA URL za svog izdavatelja, pa obilazak dodaje nove kandidate u red i dovršava lance kojima fale dva ili tri skoka. To se mora ograničiti, čemu služi parametar MaxFetch

Dijagram dovršetka AIA lanca za HotPDF: dohvat caIssuers URL-a, proba PEM u odnosu na DER, deduplikacija DER sažetkom i dubinska granica MaxFetch
HPDFFetchAIAIntermediates prelazi caIssuers URL-ove kroz isti transport, ispitujući PEM oklop i ograničavajući red s MaxFetch

Što je seed vrijednost potpisa i zašto tiho ne uspijeva?

Seed vrijednost jest ograničenje koje autor dokumenta kači na polje potpisa da bi rekao potpisniku kakav je potpis prihvatljiv: koji SubFilter, koji algoritam sažetka, koji razlozi, koja najmanja verzija PDF-a, mora li se informacija o opozivu ugraditi. Živi u rječniku /SV na polju i definirana je u ISO 32000-1 §12.7.5.5. HotPDF je piše s AttachPAdESSeedValue i provjerava s CheckLoadedSignatureSeedValue, koji vraća True kada je polje bez ograničenja ili kada svako prisutno ograničenje prolazi, a pri False imenuje prvo padajuće ograničenje kroz izlazni parametar koji možete staviti ravno u poruku pogreške

Mehanizam koji seed vrijednosti čini lako pogrešivima jest unos zastavica /Ff opisan u §12.7.5.5.3. Postavljeni bit označava svoje ograničenje kao obvezno: nepodudarnost jest pogreška i potpisnik mora odbiti. Obrisan bit označava isto ograničenje kao preferenciju: vrijednost filtrira što bi sučelje trebalo nuditi i ništa više. Iz toga slijede dvije zamke. Prvo, /Ff živi unutar rječnika /SV, a ne na widget napomeni, pa kôd koji čita /Ff na razini polja dobiva prazan odgovor zauvijek i zaključuje da ništa nije obvezno. Drugo, dodjele bitova nisu jednostavan niz jedan, dva, četiri, osam; u HotPDF-u pisac emitira 2 za SubFilter, 4 za MinVersion, 32 za AddRevInfo i 64 za DigestMethod. Čitač koji pretpostavlja uzastopne bitove dekodira svako ograničenje kao neobavezno i prolazi svaki test osim onog koji je važan

Tablica bitova zastavica seed vrijednosti za PAdES potpisivanje u HotPDF-u prikazuje bitove Ff 2, 4, 32 i 64 te rukovanje obveznim u odnosu na preferirano ograničenje
Unos /Ff živi unutar /SV, a svaki položaj bita odlučuje je li nepodudarnost tvrda odbitnica ili preferencija sučelja
var
  Violation: AnsiString;
begin
  // Pitajte polje je li profil kojim namjeravamo potpisati dopušten
  if not Pdf.CheckLoadedSignatureSeedValue(0, 'ETSI.CAdES.detached',
       'SHA256', 'Approved for payment', 1, Violation) then
    raise Exception.Create('Signature field rejects this profile: ' +
      String(Violation));
  // Ograničenje zadovoljeno: nastavite s prolazom potpisivanja
end;

Test koji je izložio izvornu grešku dekodiranja nije bio pozitivan test. Bila je to tvrdnja da prisiljena nepodudarnost mora biti odbijena, i to je jedina vrsta testa koja može uhvatiti ovu klasu defekata: dekoder koji čita pogrešan rječnik ili pogrešne položaje bitova proizvodi "nijedno ograničenje nije prekršeno" za svaki unos, što izgleda točno kao ispravno ponašanje dok jednog namjerno ne prekršite

Gdje se ovo nalazi na ljestvici LTV-a

Četiri praga, a svaki treba onaj ispod sebe. B-B je goli potpis. B-T dodaje pouzdano vremenski žig, koji fiksira vrijeme potpisivanja tako da validator zna u odnosu na koji trenutak procijeniti opoziv. B-LT dodaje dokaze o opozivu u DSS, što PopulatePAdESLTVEvidence automatizira. B-LTA dodaje vremenske žigove dokumenta koji se obnavljaju prije nego prethodni oslabi, produžujući valjanost neograničeno; HotPDF to izlaže kao RenewPAdESLTATimestamp, koji kači novi vremenski žig kao inkrementalnu reviziju i čuva svaki raniji potpis, vremenski žig i DSS unos netaknutima

Model inkrementalnog ažuriranja jedini je ispravan način dodavanja dokaza potpisanom dokumentu, jer bi preslikavanje datoteke prekrilo raspone bajtova koje postojeći potpisi pokrivaju. Ako trebate razmišljati o tome što se promijenilo između revizija i jesu li te promjene one koje potpis dopušta, ta se analiza pokriva odvojeno u analizi revizija DocMDP i FieldMDP. Cjevovod potpisivanja sam, uključujući izvore certifikata i zamke redoslijeda bajtova, opisan je u vodiču kroz PAdES potpisivanje, a strana provjere valjanosti je u provjeri potpisa na učitanim dokumentima

Jedno praktično upozorenje o redoslijedu. Prikupite dokaze što je moguće ranije nakon potpisivanja, po mogućnosti u istom poslu. Odgovarači koji mogu odgovoriti za certifikat na mreži su dok je certifikat važeći i nestaju godinama kasnije, pa dokument koji napusti vaš cjevovod kao B-B možda nikad više neće biti nadogradiv. HotPDF radi kao izvorna VCL komponenta za Delphi i C++Builder, a cijeli prolaz dokaza je unutar procesa osim vašeg vlastitog transporta; podržani profili navedeni su na stranici proizvoda HotPDF Delphi PDF component