Tehnički članak

PAdES LTV dokazi i seed vrednosti u HotPDF-u

PDF koji ste upravo potpisali je B-B potpis i ništa više. Dokazuje ko je potpisao i da se bajtovi nisu pomerili, ali ne nosi dokaz da je sertifikat potpisnika bio valjan u vreme potpisivanja, pa validator godinama kasnije mora tražiti podatke o opozivu koji možda više ne postoje. Zatvaranje tog jaza znači upisivanje OCSP odgovora i CRL-ova u nivo-dokumenta Document Security Store, i u HotPDF-u to je jedan poziv: PopulatePAdESLTVEvidence obilazi svaki učitani potpis, izvodi zahteve opoziva iz skupa sertifikata, izvršava ih kroz transport koji vi dostavite, i upisuje preuzeti materijal plus CMS lanac u DSS. Vraća broj potpisa čiji su dokazi sleteli, ili minus jedan kada dokument uopšte nema polje potpisa

Dizajnerska odluka vredna razumevanja pre upotrebe jeste da biblioteka nikad ne otvara soket. Svaki bajt koji stiže iz mreže stiže kroz callback koji ste napisali. To nije oprez radi samog opreza; to je jedini način da ova funkcija radi unutar okruženja koja zaista traže dugoročnu validaciju

Zašto biblioteka odbija da radi sopstveni HTTP?

Zato su mesta koja traže B-LT potpise mesta gde biblioteka ne može biti pouzdana sa mrežom. Servisi potpisivanja rade iza proveravajućih proksija sa korporativnim korenima. Air-gapped slojevi potpisivanja nemaju rutu do respondenta i moraju se hraniti keširanim dokazima. Režimi revizije traže da svaki odlazni zahtev evidentira aplikacija, a ne da bude zakopan u zavisnosti. I test skupovi traže determinističke odgovore, što je nemoguće ako biblioteka sama zove napolje

Transport je obična referenca funkcije fiksnog oblika, pa politika ostaje vaša. HotPDF vam predaje zapis zahteva koji opisuje tačno šta preuzeti, uključujući tip sadržaja i gornju granicu veličine odgovora, a vi vraćate bajtove plus status

Tok HotPDF PopulatePAdESLTVEvidence: transport FetchEvidence koji dostavlja pozivalac, polja zapisa zahteva i ishodi statusa po potpisu
Svaki mrežni bajt prolazi kroz vaš FetchEvidence callback, i svaki potpis dobija svoj status pa jedan istek vremena nikad ne prekida 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 kaže da li je 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čitanoj datoteci
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
      // Save samo-dodavanjem: bajtovi koje postojeći potpisi pokrivaju
      // čuvaju se doslovno
      Pdf.SaveIncrementalUpdate('signed-lt.pdf');
  finally
    Pdf.Free;
  end;
end;

Otkazivanja su po potpisu, ne po dokumentu. Respondent koji istekne vremenom za jednog potpisnika preskače materijal tog potpisnika i ostavlja ostatak prolaza netaknutim, što je ponašanje koje želite u seriji: delimični dokazi pobeđuju prekinuto pokretanje, a povratna vrednost vam govori koliko je potpisa stvarno unapređeno

Lanac koji je CMS zaboravio uključiti

Provera opoziva traži sertifikat izdavaoca, i iznenađujući broj paketa za potpisivanje izostavlja intermedijarne iz CMS kontejnera. Put oporavka je ekstenzija Authority Information Access, metoda pristupa 1.3.6.1.5.5.7.48.2, koja oglašava URL sa kojeg se sertifikat izdavaoca može preuzeti. HPDFFetchAIAIntermediates obilazi te URL-ove kroz isti transport, raščlanjuje DER iz svakog odgovora, i vraća samo sertifikate koje CMS već nije nosio, ključane DER hešom pa duplici i petlje ne mogu vrteti

Dva detalja odlučuju da li ovo radi protiv stvarnih sertifikatskih autoriteta. Prvi je kodiranje: CA krajnje tačke služe sertifikat kao goli DER otprilike jednako često kao što ga služe PEM oklopljenog, i nema pouzdanog tipa sadržaja da ih razlikuje. Robusna sonda je tekstualna, pa strukturna. Tražite marker -----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. Drugi je dubina: preuzeti intermedijaran može sam oglašavati AIA URL za svog izdavaoca, pa obilazak dodaje nove kandidate u red i dopunjuje lance kojima nedostaju dva ili tri skoka. To mora biti ograničeno, čemu služi parametar MaxFetch

Dijagram dopune AIA lanca za HotPDF: preuzimanje caIssuers URL-a, PEM naspram DER sonda, deduplikacija DER hešom i MaxFetch dubinska granica
HPDFFetchAIAIntermediates obilazi caIssuers URL-ove kroz isti transport, sondirajući PEM oklop i ograničavajući red sa MaxFetch

Šta je seed vrednost potpisa i zašto otkazuje tiho?

Seed vrednost je ograničenje koje autor dokumenta prikačuje polju potpisa da bi rekao potpisniku koja vrsta potpisa je prihvatljiva: koji SubFilter, koji algoritam sažetka, koji razlozi, koja najmanja PDF verzija, da li se informacija o opozivu mora ugraditi. Živi u /SV rečniku na polju i definisana je u ISO 32000-1 §12.7.5.5. HotPDF je piše sa AttachPAdESSeedValue i proverava sa CheckLoadedSignatureSeedValue, koja vraća True kada polje nije ograničeno ili svako prisutno ograničenje prolazi, a pri False imenuje prvo neuspešno ograničenje kroz izlazni parametar koji možete staviti pravo u poruku greške

Mehanizam koji čini seed vrednosti lakim za pogrešiti jeste unos zastavica /Ff opisan u §12.7.5.5.3. Postavljeni bit označava svoje ograničenje kao obavezno: neslaganje je greška i potpisnik mora odbiti. Obrisan bit označava isto ograničenje kao preferencu: vrednost filtrira šta bi sučelje trebalo nuditi i ništa više. Iz toga slede dve zamke. Prvo, /Ff živi unutar /SV rečnika, ne na widget anotaciji, pa kod koji čita nivo-polja /Ff dobija prazan odgovor zauvek i zaključuje da ništa nije prinudno. Drugo, dodele bitova nisu jednostavan niz jedan, dva, četiri, osam; u HotPDF-u pisac emituje 2 za SubFilter, 4 za MinVersion, 32 za AddRevInfo i 64 za DigestMethod. Čitač koji pretpostavlja uzastopne bitove dekoduje svako ograničenje kao opciono i prolazi svaki test osim onog koji je važan

Tabela bitova zastavica seed vrednosti za HotPDF PAdES potpisivanje prikazuje Ff bitove 2, 4, 32 i 64 i rukovanje obaveznim naspram preferiranih ograničenja
Unos /Ff živi unutar /SV, i svaka pozicija bita odlučuje da li je neslaganje čvrsto odbijanje ili preferenca sučelja
var
  Violation: AnsiString;
begin
  // Pitajte polje da li je profil kojim ćemo potpisati dozvoljen
  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 sa prolazom potpisivanja
end;

Test koji je izložio prvobitnu grešku dekodiranja nije bio pozitivan test. Bio je to tvrđenje da prinudno neslaganje mora biti odbijeno, i to je jedina vrsta testa koja može uhvatiti ovu klasu defekta: dekoder koji čita pogrešan rečnik ili pogrešne pozicije bitova proizvodi "nijedno ograničenje nije prekršeno" za svaki ulaz, što deluje tačno kao ispravno ponašanje dok namerno ne prekršite jedno

Gde ovo sedi na LTV lestvici

Četiri prečke, i svaka traži onu ispod. B-B je goli potpis. B-T dodaje poverljivu vremensku oznaku, koja fiksira vreme potpisivanja pa validator zna na koji trenutak oceniti opoziv. B-LT dodaje dokaze opoziva u DSS, što je ono što PopulatePAdESLTVEvidence automatizuje. B-LTA dodaje vremenske oznake dokumenta koje se obnavljaju pre nego što prethodna oslabi, produžavajući valjanost neograničeno; HotPDF to izlaže kao RenewPAdESLTATimestamp, koji dodaje novu vremensku oznaku kao inkrementalnu reviziju i čuva svaki raniji potpis, vremensku oznaku i DSS unos netaknutim

Model inkrementalnog ažuriranja jedini je ispravan način dodavanja dokaza potpisanom dokumentu, jer bi prepisivanje datoteke slomilo opsege bajtova koje postojeći potpisi pokrivaju. Ako treba rasuđivati o tome šta se promenilo između revizija, i da li su te izmene one vrste koju potpis dopušta, ta analiza pokrivena je odvojeno u DocMDP i FieldMDP analizi revizija. Sam pipeline potpisivanja, uključujući izvore sertifikata i zamke redosleda bajtova, nalazi se u objašnjenju PAdES potpisivanja, a strana validacije u verifikaciji potpisa na učitanim dokumentima

Jedno praktično upozorenje o redosledu. Prikupljajte dokaze što je moguće ranije posle potpisivanja, idealno u istom poslu. Respondenti koji mogu odgovoriti za sertifikat na mreži su dok je sertifikat tekući i nestaju godinama kasnije, pa dokument koji napusti vaš pipeline kao B-B možda nikad više neće biti nadogradiv. HotPDF radi kao nativna VCL komponenta za Delphi i C++Builder, i ceo prolaz dokaza je u procesu osim vašeg sopstvenog transporta; podržani profili navedeni su na stranici proizvoda HotPDF Delphi PDF component