Tekninen artikkeli: PAdES Digital Signatures in Delphi with PDFlibPas suomeksi

Tämä lokalisoitu versio keskittyy aiheeseen PAdES Digital Signatures in Delphi: Signing and Validation with PDFlibPas ja käyttää päivitettyä englanninkielistä artikkelia teknisenä perustana Delphi-, PDF- ja dokumenttiohjelmistotiimeille

Sivu muuntaa päivitetyn pohja-artikkelin konkreettisiksi tarkistuspisteiksi suunnittelua, toteutusta ja validointia varten

Mitä englanninkielisestä artikkelista synkronoitiin

Englanninkielistä pohja-artikkelia on laajennettu käytännön kontekstilla, teknisillä päätöksillä ja konkreettisilla esimerkeillä, joten tätä sivua kannattaa lukea työohjeena eikä lyhyenä yhteenvetona

Päivitetyn pohja-artikkelin tärkeät osat:

Käytä ensin pieniä toistettavia syötetiedostoja
Pidä tuotenimet, API-nimet, tiedostonimet ja literal-arvot muuttumattomina
Tallenna validatorin tuloste ja versiotiedot luodun esimerkkitiedoston kanssa

Käytännön toteutusvalinnat

Aloita tiedostotyypistä, odotetusta tuloksesta ja virhetilasta, jonka käyttäjän pitää nähdä. Sido sen jälkeen jokainen API-kutsu tarkistettavaan tulokseen, jotta validointi, lokitus ja tuki voivat toistaa asiakkaan tilanteen

Käytä ensin pieniä toistettavia syötetiedostoja
Pidä tuotenimet, API-nimet, tiedostonimet ja literal-arvot muuttumattomina
Tallenna validatorin tuloste ja versiotiedot luodun esimerkkitiedoston kanssa

Koodi ja API-kohdat

Koodiesimerkit säilytetään muuttumattomina, jotta kehittäjä voi verrata niitä suoraan Delphi-, C++Builder- ja Lazarus/FPC-projekteihin

var
  Pdf: TPDFlib;
  SignId: Integer;
begin
  Pdf := TPDFlib.Create;
  try
    SignId := Pdf.NewSignProcessFromFile('invoice.pdf', '');
    if SignId = 0 then
      raise Exception.Create('cannot open source PDF');
    Pdf.SetSignProcessField(SignId, 'Sig1');
    Pdf.SetSignProcessPFXFromFile(SignId, 'company.pfx', PfxPassword);
    Pdf.SetSignProcessInfo(SignId, 'Approved', 'Vienna', 'billing@example.com');
    Pdf.SetSignProcessCustomSubFilter(SignId, 'ETSI.CAdES.detached');
    Pdf.SetSignProcessDigestAlgorithm(SignId, 2);          // SHA-256
    Pdf.SetSignProcessReserveContentsBytes(SignId, 8192);  // room for a timestamp later
    Pdf.EndSignProcessToFile(SignId, 'invoice-signed.pdf');
    if Pdf.GetSignProcessResult(SignId) <> 1 then
      raise Exception.CreateFmt('signing failed, code %d',
        [Pdf.GetSignProcessResult(SignId)]);
    Pdf.ReleaseSignProcess(SignId);
  finally
    Pdf.Free;
  end;
end;

var
  Pdf: TPDFlib;
  StsId: Integer;
  HashHex, TstDer, TsAttr, AugmentedCms: AnsiString;
begin
  Pdf := TPDFlib.Create;
  try
    StsId := Pdf.NewPAdESSignatureTimeStampProcessFromFile('invoice-signed.pdf', '');
    Pdf.SetPAdESSignatureTimeStampField(StsId, 'Sig1');
    Pdf.SetPAdESSignatureTimeStampDigestAlgorithm(StsId, 2);
    HashHex := Pdf.GetPAdESSignatureValueHashHex(StsId);
    // both calls below are application code: an HTTP POST to your TSA,
    // and a CMS re-encode that attaches the token as an unsigned attribute
    TstDer := RequestTimeStampToken(HashHex);
    TsAttr := Pdf.BuildPAdESSignatureTimeStampAttribute(TstDer);
    AugmentedCms := AttachUnsignedAttribute(Pdf.GetPAdESSignatureCMSBytes(StsId), TsAttr);
    Pdf.SetPAdESSignatureCMSBytes(StsId, AugmentedCms);
    Pdf.EndPAdESSignatureTimeStampProcessToFile(StsId, 'invoice-bt.pdf');
    if Pdf.GetPAdESSignatureTimeStampProcessResult(StsId) <> 1 then
      raise Exception.Create('timestamp embedding failed');
    Pdf.ReleasePAdESSignatureTimeStampProcess(StsId);
  finally
    Pdf.Free;
  end;
end;

var
  Doc: TPDFlibSignDoc;
  Names: TStringList;
  I: Integer;
  B0, B1, B2, B3, FileSize: Int64;
begin
  FileSize := TFile.GetSize('invoice-bt.pdf');  // before Open: SignDoc holds a share lock
  Doc := TPDFlibSignDoc.Create;
  try
    if not Doc.Open('invoice-bt.pdf', '', False) then
      raise Exception.Create('cannot open for audit');
    Names := TStringList.Create;
    try
      Doc.GetSignatureFieldNames(Names);
      for I := 0 to Names.Count - 1 do
        if Doc.GetSignatureValueObjNum(Names[I]) > 0 then   // >0 means actually signed
        begin
          B0 := StrToInt64(string(Doc.GetSignatureValueByName(Names[I], 11)));
          B1 := StrToInt64(string(Doc.GetSignatureValueByName(Names[I], 12)));
          B2 := StrToInt64(string(Doc.GetSignatureValueByName(Names[I], 13)));
          B3 := StrToInt64(string(Doc.GetSignatureValueByName(Names[I], 14)));
          if (B0 = 0) and (B2 + B3 = FileSize) then
            Writeln(Names[I], ': covers the file to EOF')
          else
            Writeln(Names[I], ': earlier revision, or unexpected ByteRange layout');
        end;
    finally
      Names.Free;
    end;
    Doc.Close;
  finally
    Doc.Free;
  end;
end;

Tarkistus ennen julkaisua

Tarkista tulostiedosto samoilla työkaluilla, joita asiakas tai arkisto käyttää. Kirjaa komponenttiversio, testidata, validatorin versio ja havaittu tulos, jotta myöhempi regressio voidaan jäljittää täsmällisesti

Täydentävä tekninen tarkastelu

Tämä laajennettu osio liittyy artikkeliin Tekninen artikkeli: PAdES Digital Signatures in Delphi with PDFlibPas suomeksi ja avaa saman työketjun siltä kannalta, että tiimin pitää voida jäljittää myöhemmin sekä generoinnin, validoinnin että lokituksen päätökset. Linkitetyn sivun englanninkielinen perusartikkeli hreflangin kautta näyttää, miksi pelkkä otsikoiden kääntäminen ei riitä; olennaista on selittää, miksi asiakirja on valmis vasta silloin, kun säännöt, tulos ja tarkastusjäljet on oikeasti sovitettu yhteen

Toteutusta käsittelevissä artikkeleissa on hyödyllistä erottaa suunnittelu ja tarkistus toisistaan. Ensin määritetään tiedostotyyppi, odotettu tulos ja käyttäjän näkemä virhetila, ja sen jälkeen jokainen API-kutsu sidotaan tulokseen, jonka voi toistaa samassa skenaariossa. Tämä pätee sekä PDF- että taulukkolaskentatyöhön: koodiesimerkit säilyvät muuttumattomina, mutta ympäröivän tekstin pitää selittää, miksi komponenttiversio, mallin tunnus, syötedata ja validointitila kannattaa kirjata yhteen

Yhtä tärkeää on säilyttää tuotenimet, API-nimet, tiedostonimet ja literal-arvot täsmälleen kuten englanninkielisessä lähteessä. Se pitää kehityksen, tuen ja laadunvarmistuksen yhteisen viitekehyksen kasassa ja vähentää riskiä siitä, että paikallisesta versiosta tulee vain vapaa parafraasi ilman täsmällistä teknistä sisältöä. Jos artikkelissa on koodia, kommenttien ja tokenien tulee pysyä koskemattomina, koska juuri ne yhdistävät tekstin todelliseen projektiin

Kun sivua luetaan julkaisun jälkeen, siitä kannattaa ajatella jäljitettävää ketjua. Hyvä validointimerkintä kuvaa, mitä testattiin, millä työkalulla tulos arvioitiin, mitkä versiot olivat mukana ja minne todiste onnistumisesta tai epäonnistumisesta on tallennettu. Kun myöhemmin ilmenee regressio, arkistoitu raportti ja siihen liittyvä syötetiedosto ovat paljon arvokkaampia kuin pelkkä muisto siitä, että "se meni silloin läpi"

Tälle lokalisoidulle haaralle pätee siis yksinkertainen sääntö: pidä keskeiset päätökset, tarkistuspisteet ja koodin konteksti yhdessä, jotta artikkeli on hyödyllinen paitsi ensimmäisellä lukukerralla myös myöhemmässä virheenjäljityksessä, auditoinnissa ja versioiden vertailussa. Se on ero lyhyen yhteenvedon ja työasiakirjan välillä, jolla on arvoa vielä useiden julkaisutusten jälkeen.

Käytä ensin pieniä toistettavia syötetiedostoja
Pidä tuotenimet, API-nimet, tiedostonimet ja literal-arvot muuttumattomina
Tallenna komponenttiversio, validatorin tulos ja syötetiedot yhdessä
Säilytä koodilohkot ja kommentit täsmälleen kuten lähteessä