PAdES LTV-todisteet ja seed-arvot HotPDF:ssä

Juuri allekirjoittamasi PDF on B-B-allekirjoitus eikä mitään muuta. Se todistaa, kuka allekirjoitti ja että tavut eivät ole liikkuneet, mutta se ei kanna näyttöä siitä, että allekirjoittajan sertifikaatti oli pätevä allekirjoitushetkellä, joten validoijan vuosien päästä on etsittävä peruutustietoja, joita ei välttämättä enää ole olemassa. Sen aukon sulkeminen tarkoittaa OCSP-vastausten ja CRL:ien kirjoittamista dokumenttitason Document Security Storeen, ja HotPDF:ssä se on yksi kutsu: PopulatePAdESLTVEvidence käy jokaisen ladatun allekirjoituksen läpi, johtaa peruutuspyynnöt sertifikaattijoukosta, suorittaa ne toimittamasi kuljetuksen kautta ja kirjoittaa haetun materiaalin sekä CMS-ketjun DSS:ään. Se palauttaa niiden allekirjoitusten lukumäärän, joiden todisteet osuivat maaliin, tai miinuksen ykkösen, kun dokumentissa ei ole lainkaan allekirjoituskenttää

Suunnittelupäätös, joka kannattaa ymmärtää ennen käyttämistä, on se, ettei kirjasto koskaan avaa sokettia. Jokainen verkosta saapuva tavu saapuu kirjoittamasi callbackin kautta. Tuo ei ole varovaisuutta itsensä vuoksi; se on ainoa tapa, jolla tämä ominaisuus voi toimia niissä ympäristöissä, jotka todella vaativat pitkän aikavälin validointia

Miksi kirjasto kieltäytyy tekemästä omaa HTTP:tään?

Koska paikat, jotka vaativat B-LT-allekirjoituksia, ovat paikkoja, joissa kirjastoon ei voi luottaa verkon suhteen. Allekirjoituspalvelut toimivat autentikoivien proxypalvelinten takana yrityksen omilla luottamusjuurilla. Ilmajohdatetut allekirjoitustasot eivät näe reittiä vastaajalle ja ne pitää ruokkia välimuistitetuilla todisteilla. Auditointijärjestelmät vaativat, että jokainen lähtevä pyyntö lokitetaan sovelluksessa, ei haudata riippuvuuteen. Ja testisarjat tarvitsevat deterministisiä vastauksia, mikä on mahdotonta, jos kirjasto soittaa ulos omatoimisesti

Kuljetus on tavallinen funktioviittaus kiinteällä muodolla, joten politiikka pysyy sinun. HotPDF ojittaa sinulle pyyntötietueen, joka kuvaa täsmälleen, mitä hakea, sisältäen sisältötyypin ja vastauksen kokokaton, ja sinä palautat tavut plus tilan

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 kertoo, onko kyseessä OCSP POST vai CRL GET;
    // Request.ContentType ja Request.Body ovat jo valmisteltuja,
    // ja Request.MaxResponseBytes on katto, jota sinun on noudatettava
    Response := HttpExchange(Request.URI, Request.ContentType,
      Request.Body, Request.MaxResponseBytes);
    Result := setsSucceeded;
  except
    on E: Exception do
    begin
      ErrorMessage := E.Message;
      // setsRetry antaa uudelleenyrityspolitiikan vetäytyä; käytä
      // setsPermanentFailure-koodia 404:lle tai huonolle URL:lle
      Result := setsRetry;
    end;
  end;
end;

// Yhden kutsun päivitys B-B:stä B-LT:hen jokaiselle ladatun
// tiedoston allekirjoitukselle
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
      // Vain liittävä tallennus: olemassa olevien allekirjoitusten
      // kattamat tavut säilytetään sanatarkasti
      Pdf.SaveIncrementalUpdate('signed-lt.pdf');
  finally
    Pdf.Free;
  end;
end;

Viat ovat allekirjoituskohtaisia, eivät dokumenttikohtaisia. Vastaaja, joka saa aikakatkaisun yhdelle allekirjoittajalle, ohittaa kyseisen allekirjoittajan materiaalin ja jättää ajon loput ehjiksi, mikä on käyttäytyminen, jota haluat eräajossa: osittainen todiste lyö keskeytetyn ajon, ja paluuarvo kertoo, montako allekirjoitusta oikeasti parani

Ketju, jonka CMS unohti sisällyttää

Peruutuksen tarkistus tarvitsee myöntäjäsertifikaatin, ja yllättävän moni allekirjoituspino jättää välisertifikaatit pois CMS-säiliöstä. Palautusreitti on Authority Information Access -laajennus, käyttötapa 1.3.6.1.5.5.7.48.2, joka ilmoittaa URL:n, josta myöntäjäsertifikaatin voi ladata. HPDFFetchAIAIntermediates käy kyseiset URL:t saman kuljetuksen kautta, jäsentää DER:n jokaisesta vastauksesta ja palauttaa vain ne sertifikaatit, joita CMS ei jo kantanut, avattuna DER-hajautuksella, joten kahdennukset ja silmukat eivät voi pyöriä

Kaksi yksityiskohtaa päättää, toimiiko tämä todellisia sertifikaattiviranomaisia vastaan. Ensimmäinen on koodaus: CA-päätepisteet tarjoilevat sertifikaatin bare-DER:nä yhtä usein kuin PEM-panssaroituna, eikä ole luotettavaa sisältötyyppiä niiden erottamiseen. Vankka koetus on tekstuaalinen ja sitten rakenteellinen. Etsi -----BEGIN CERTIFICATE------merkki, kuori panssari ja dekoodaa base64, jos se on läsnä, ja kummassakin polussa vahvista, että tuloksen ensimmäinen tavu on $30, DER-tagi SEQUENCE:lle. Toinen on syvyys: haettu välisertifikaatti voi itse ilmoittaa AIA-URL:n omalle myöntäjälleen, joten kulku liittää uusia ehdokkaita jonoon ja täydentää ketjut, joista puuttuu kaksi tai kolme hyppyä. Se on rajoitettava, ja siihen on MaxFetch-parametri

Mitä on allekirjoituksen seed-arvo, ja miksi se epäonnistuu hiljaa?

Seed-arvo on rajoitus, jonka dokumentin tekijä liittää allekirjoituskenttään kertoakseen allekirjoittajalle, millainen allekirjoitus on hyväksyttävä: mikä SubFilter, mikä tiivistysalgoritmi, mitkä syyt, mikä vähimmäis-PDF-versio, tuleeko peruutustieto upottaa. Se asuu kentän /SV-sanakirjassa ja se on määritelty ISO 32000-1 §12.7.5.5:ssä. HotPDF kirjoittaa sen funktiolla AttachPAdESSeedValue ja tarkistaa sen funktiolla CheckLoadedSignatureSeedValue, joka palauttaa arvon True, kun kenttä on rajoittamaton tai jokainen läsnä oleva rajoitus läpäisee, ja arvolla False nimeää ensimmäisen epäonnistuvan rajoituksen tulostusparametrin kautta, jonka voi laittaa suoraan virheviestiin

Mekanismi, joka tekee seed-arvoista helppoja saada väärin, on §12.7.5.5.3:ssa kuvattu /Ff-lippumerkintä. Asetettu bitti merkitsee rajoituksensa pakolliseksi: ero on virhe, ja allekirjoittajan on kieltäydyttävä. Tyhjä bitti merkitsee saman rajoituksen mieltymykseksi: arvo suodattaa, mitä käyttöliittymän pitäisi tarjota, eikä muuta. Siitä seuraa kaksi ansaa. Ensinnäkin /Ff asuu /SV-sanakirjan sisällä, ei widget-annotaatiolla, joten koodi, joka lukee kenttätason /Ff:n, saa tyhjän vastauksen ikuisesti ja päättelee, ettei mitään ole pakotettu. Toiseksi bittimääritykset eivät ole yksinkertainen jakso yksi, kaksi, neljä, kahdeksan; HotPDF:ssä kirjoittaja emittoi arvon 2 SubFilterille, 4 MinVersionille, 32 AddRevInfolle ja 64 DigestMethodille. Lukija, joka olettaa peräkkäiset bitit, dekoodaa jokaisen rajoituksen valinnaiseksi ja läpäisee jokaisen testin paitsi sen, joka merkitsee

var
  Violation: AnsiString;
begin
  // Kysy kentältä, onko profiili, jolla olemme allekirjoittamassa, sallittu
  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));
  // Rajoitus täyttyi: jatka allekirjoitusajoa
end;

Testi, joka paljasti alkuperäisen jäsennysvirheen, ei ollut positiivinen testi. Se oli assertio siitä, että pakotettu ero on hylättävä, ja se on ainoa testilaji, joka voi napata tämän virheluokan: dekoodaaja, joka lukee väärää sanakirjaa tai vääriä bittikohtia, tuottaa tuloksen ”ei rajoituksia rikottu” jokaiselle syötteelle, mikä näyttää täsmälleen oikealta käyttäytymiseltä, kunnes tarkoituksella rikot yhden

Missä tämä sijaitsee LTV-tikapuissa

Neljä askelmaa, ja jokainen tarvitsee sitä alemman. B-B on paljas allekirjoitus. B-T lisää luotetun aikaleiman, mikä lukitsee allekirjoitusajan, joten validoija tietää, mitä hetkeä vasten peruutus arvioidaan. B-LT lisää peruutustodisteet DSS:ään, minkä PopulatePAdESLTVEvidence automatisoi. B-LTA lisää dokumentin aikaleimat, jotka uusitaan ennen kuin edellinen heikkenee, laajentaen pätevyyttä loputtomiin; HotPDF paljastaa sen funktiona RenewPAdESLTATimestamp, joka liittää uuden aikaleiman inkrementaalisena revisiona ja säilyttää jokaisen aiemman allekirjoituksen, aikaleiman ja DSS-merkinnän koskemattomina

Inkrementaalisen päivityksen malli on ainoa oikea tapa lisätä todisteita allekirjoitettuun dokumenttiin, koska tiedoston uudelleenkirjoittaminen rikkoisi tavualueet, joita olemassa olevat allekirjoitukset kattavat. Jos sinun on pääteltävä, mitä revisioiden välillä muuttui, ja ovatko nuo muutokset sellaisia, joita allekirjoitus sallii, kyseinen analyysi käsitellään erikseen artikkelissa DocMDP- ja FieldMDP-revisioanalyysi. Itse allekirjoitusputki, mukaan lukien sertifikaattilähteet ja tavujärjestysansat, on artikkelissa PAdES-allekirjoituksen läpikäynti, ja validointipuoli on artikkelissa allekirjoitusten tarkistaminen ladatuista dokumenteista

Yksi käytännön varoitus järjestyksestä. Kerää todisteet mahdollisimman pian allekirjoittamisen jälkeen, mieluiten samassa työssä. Vastaajat, jotka voivat vastata sertifikaatista, ovat verkossa sillä aikaa, kun sertifikaatti on voimassa, ja poistuneita vuosien päästä, joten dokumentti, joka lähtee putkestasi B-B:nä, ei välttämättä ole koskaan enää päivitettävissä. HotPDF toimii natiivina VCL-komponenttina Delphille ja C++Builderille, ja koko todisteajo on prosessinsisäinen paitsi oma kuljetuksesi; tuetut profiilit on lueteltu HotPDF Delphi PDF -komponentin tuotesivulla