Jak na digitální kontinuitu (11): k jakému časovému okamžiku se mají ověřovat elektronické podpisy?
Zatímco při posuzování vlastnoručních podpisů čas nehraje až tak velkou roli, u elektronických podpisů může jít i o minuty a sekundy. Jak ale postupovat, když právo a technické standardy říkají každý něco jiného?
V minulém dílu tohoto seriálu jsme si popsali princip revokace certifikátů, který je obdobou blokování platebních karet: pokud přijdete o svůj soukromý klíč (ke kterému byl certifikát vystaven), nebo pokud jej už nebudete dále používat, měli byste jej nechat revokovat, alias odvolat či předčasně zneplatnit. Také jsme si popsali důsledky, které revokace má na již podepsané elektronické dokumenty: pokud podpis prokazatelně vznikl ještě před revokací (což se nejsnáze prokazuje pomocí časového razítka), nijak to nebrání možnosti ověřit podpis jako platný.
Nicméně stejně jako u platebních karet je důležitá časová souslednost: k čemu došlo dříve a k čemu později. Právě tomu, tedy otázkám času a posuzování časových sousledností, se dnes budeme věnovat podrobněji. Zejména pak tomu, k jakému okamžiku máme ověřovat platnost elektronických podpisů a pečetí.
Proč u elektronických podpisů potřebujeme znát údaje o čase?
Již z této krátké rekapitulace předchozího dílu vyplývá jedna zásadní odlišnost práce s elektronickými podpisy (ale i pečetěmi a časovými razítky) oproti práci s vlastnoručními podpisy: pokud necháme stranou takové věci, jako je blednutí inkoustu či změny rukopisu v důsledku stárnutí podepisující osoby, je posuzování vlastnoručních podpisů obecně nezávislé na čase. Proto nás u listinných dokumentů až tak netrápí otázka, kdy konkrétně byl nějaký podpis vytvořen. A pokud v obsahu samotného dokumentu někdo uvede (deklaruje, tvrdí) nějaké datum, případně i čas, jeho přesnost a správnost není (pro posuzování samotných vlastnoručních podpisů) relevantní.
Ovšem u elektronických podpisů, pečetí i časových razítek na čase záleží zcela zásadně. Může jít i o minuty, či dokonce sekundy.
Důvodem je už samotná skutečnost, že certifikáty mají jen omezenou dobu řádné platnosti (počítanou na minuty a sekundy). Proto je součástí postupného procesu ověřování platnosti elektronického podpisu (či pečeti nebo časového razítka) také kontrola toho, zda tato řádná doba platnosti stále trvá.
Stejně tak je tomu v případě revokace, podrobněji popisované v minulém dílu. Zde musíme při zkoumání časové souslednosti brát v úvahu i to, kdy nastaly účinky revokace. Protože, jak už jsme si řekli v závěru minulého dílu, i samotná revokace je ve skutečnosti určitý postupný proces: v určitém okamžiku je podána žádost o revokaci, následně je posuzována její oprávněnost, a pokud je přijata, v nějakém dalším okamžiku nastávají účinky revokace (opět s přesností na minuty a sekundy). A jak praví nařízení eIDAS, revokace „nabývá účinku okamžitě po zveřejnění“.
Stejně tak je ale třeba přesně znát i časový okamžik, pro který budeme posuzovat časovou souslednost: zda předchází účinkům revokace, nebo zda je tomu naopak. Tedy okamžik, ke kterému budeme rozhodovat, zda je konkrétní „časově závislá“ podmínka splněna. Říkejme tomuto okamžiku pracovně rozhodný okamžik.
Prověřuj, a teprve pak důvěřuj
Mimochodem, když už jsme u rozdílů mezi vlastnoručními a elektronickými podpisy, řekněme si ještě o jednom významném rozdílu: příjemce podepsaného listinného dokumentu jeho vlastnoruční podpis obvykle nijak nekontroluje. Většinou ani nemá podle čeho (nemá k dispozici žádný podpisový vzor). A i kdyby měl, sám nejspíše není písmoznalcem, takže by se stejně jednalo jen o orientační laické posouzení shody s nějakým podpisovým vzorem.
Skutečné posouzení – a to písmoznalcem, jehož práce něco stojí a nějakou dobu trvá – se proto dělá až dodatečně, v případě nějakého sporu. A může se dělat jen tehdy, pokud je s čím porovnávat (pokud jsou k dispozici další vzory podpisů příslušné osoby). Jinými slovy: u vlastnoručních podpisů se postupuje stylem „důvěřuj, a teprve v případě sporu prověřuj“. Je to možné i díky tomu, že u vlastnoručních podpisů žádná možnost revokace neexistuje a časový faktor zde prakticky nehraje roli (ve výše popisovaném smyslu).
To u elektronických podpisů jejich ověřování není drahou a pomalou „ruční prací“, ale může být velmi rychlou a levnou „prací strojů“ (programů). Proto se může a má postupovat opačně, na principu „prověřuj, a teprve pak důvěřuj“.
Zjednodušeně: platnost podpisu (či pečeti a časových razítek) se má ověřovat ještě dříve, než se s nimi začne pracovat (spoléhat se na jejich obsah a jednat podle toho). Ostatně, ukládají to i konkrétní právní předpisy. A v předchozí právní úpravě (v zákoně č. 227/2000 Sb., o elektronickém podpisu) bylo dokonce explicitně pamatováno na případ, že by někdo požadovanou souslednost nedodržel (a spoléhal se na podpis i přesto, že neprovedl jeho řádné a úplné ověření). Pokud by kvůli tomu vznikla nějaká škoda, šla by za ním.
Čas je potřeba znát nejenom přesně, ale také spolehlivě
Vraťme se ale zpět k časovému faktoru při ověřování platnosti elektronických podpisů, pečetí i časových razítek. Důležité je, že všechny časové okamžiky – čas účinků případné revokace i rozhodný okamžik – potřebujeme znát nejenom přesně, ale také spolehlivě. Tedy tak, abychom se na ně mohli (v dostatečné míře) spoléhat. Obdobně pro začátek a konec řádné doby platnosti certifikátu.
Pokud bychom připustili, že s údaji o těchto okamžicích v čase může někdo manipulovat (nastavit je tak, jak potřebuje), pak bychom tím celý princip revokace, coby ochrany proti zneužití soukromého klíče, postavili na hlavu. U příměru s platebními kartami by to odpovídalo možnosti antedatovat požadavek na transakci a tím úplně obejít její blokaci: pokud by někdo někomu ukradl jeho platební kartu, která by ihned byla zablokována, stačilo by mu požadavek na transakci jakoby „posunout v čase zpět“, ještě před dobu zablokování. Stejně tak bychom tím postavili na hlavu i časově omezenou platnost certifikátů.
U platebních transakcí, které probíhají v reálném čase, naštěstí žádné „posouvání času“ z principu není možné. Ale u elektronických podpisů se vychází ze zaznamenaných údajů o čase, kdy se něco mělo odehrát. A zde už je nějaké ovlivnění těchto záznamů možné. Ostatně, v 7. dílu jsme si to už jednou ukazovali, na příkladu podpisu, který měl vzniknout v budoucnosti. Následující obrázek ukazuje obě možnosti: posunutí času do minulosti i do budoucnosti.
Připomeňme si, co na tomto obrázku vidíme: je to deklarovaný čas podepsání (vzniku podpisu), který se bere ze systémových hodin počítače, kde podpis vzniká. A tyto systémové hodiny lze libovolně přetáčet dopředu i dozadu. Takže na tento údaj (o deklarovaném času podepsání) se nemůžeme spoléhat. Je to v zásadě to samé jako datum a čas napsané na listinném dokumentu. Může to být správně, ale také nemusí. Někdy to můžeme poznat snadno a hned, jako třeba u 30. února 2023 na dnešním prvním obrázku. Jindy nemusíme mít reálnou šanci odhalit nesprávnost.
PoE aneb Důkaz o existenci (v čase)
Logickým řešením pro volbu rozhodného okamžiku je vycházet z takového údaje o čase, na který se již můžeme (v dostatečné míře) spoléhat. A to typicky není onen deklarovaný (tvrzený) čas, kdy podpis měl vzniknout – ale čas získaný z něčeho, co dokazuje, kdy podpis již existoval. Tedy nějaké jeho „ukotvení v čase“. V angličtině se pro to používá zkratka PoE, od Proof of Existence. Doslova důkaz o existenci (myšleno v čase).
A aby se mohlo jednat o důkaz o existenci určitého konkrétní obsahu (podpisu na dokumentu) v čase, musí příslušné „ukotvení“ fixovat jak čas, tak i samotný obsah, z pohledu jeho změny. Přesněji: umožňovat detekci jakékoli změny, resp. rozpoznání toho, zda se stále jedná o stejný původní obsah (podepsaný dokument), nebo již o nějaký jiný (pozměněný). Takže jde vlastně o to, co jsme si v sedmém dílu tohoto seriálu popisovali jako „plombu“.
A jak jsme si v sedmém dílu také již uvedli, ideálním příkladem takovéto „plomby“, resp. důkazu o existenci v čase (PoE), je platné kvalifikované elektronické časové razítko – ať již přímo u podpisu či pečeti (jako podpisové časové razítko), či na dokumentu (jako dokumentové razítko), případně na nějakém obalu (kontejneru, datové zprávě). Proto je také dobrou praxí (a pro veřejnoprávní podepisující i povinností) přidávat k podpisům i pečetím časová razítka.
Stupně volnosti při ověřování platnosti
Důkazem o existenci v čase (PoE) ale mohou být i jiné věci. Například záznam vlastní podatelny o tom, kdy jí byl podepsaný dokument dodán. Či záznam v nějakém transakčním protokolu či jiná digitální stopa, pokud je dostatečně spolehlivá.
Stejně tak je ale možné, že v konkrétních případech lze důvěřovat i deklarovanému času podepsání. Například pokud zdroj tohoto časového údaje máme (coby ověřující strana) pod vlastní kontrolou.
Nehledě na to, že v rámci celého procesu ověřování platnosti podpisů, pečetí (a časových razítek) může existovat celá řada dalších „stupňů volnosti“: věcí, které lze nějakým způsobem ovlivnit. Ať již povolit, či zakázat, nastavit na nějakou konkrétní hodnotu, zvolit jednu z více variant apod. Obecně tzv. parametrizovat.
Technické standardy pro ověřování proto popisují základní principy ověřování platnosti, ale vedle toho ponechávají poměrně značný prostor pro to, aby konkrétní nástroje a služby používaly řadu vlastních nastavení, omezení a parametrů, či přijímaly vlastní rozhodnutí o tom, čemu ještě budou důvěřovat a co budou ještě ochotny akceptovat a co již nikoli.
Podrobnější popis by šel již nad rámec tohoto článku, proto jen několik konkrétních příkladů, na které jsme už v nějaké podobě narazili. Jde třeba o způsob volby onoho rozhodného okamžiku, který si záhy rozvedeme na konkrétních příkladech.
Dalším příkladem mohou být „zastaralé“ hashovací funkce, konkrétně třeba SHA-1 (podrobněji viz 8. díl seriálu): např. Adobe Reader, služba SecuSign, úschovna Czech POINTu či podatelny soudů s nimi nemají žádný problém (tj. jsou ochotny se na ně nadále spoléhat a nejsou pro ně překážkou k ověření platnosti). Dokonce jim nevadí ani ještě starší hashovací funkce MD5 a RIPEMD160. Naproti tomu třeba unijní služba DSS či slovenský validátor společnosti DiSig je už nepovažují za důvěryhodné a nejsou ochotny ověřit jako platný takový podpis, pečeť či razítko, které využívají tyto starší hashovací funkce. Příklad vidíte na následujícím obrázku, na kterém je výsledek ověření podpisu i časového razítka, které (oba) využívají hashovací funkci SHA-1.
Jiným „stupněm volnosti“ může být formát podpisů a pečetí. Opět bez zacházení do větších podrobností si můžeme říci, že existují dvě základní varianty, které se dají označit jako „referenční“ a „nereferenční“. Ty „referenční“ jsou novější a obecně bezpečnější – a některé nástroje a služby již odmítají pracovat s těmi „nereferenčními“ (jako např. slovenský validátor DiSig v levé části následujícího obrázku). Jiné služby, jako např. služba SecuSign, před nereferenčním formátem (CMS/PKCS#7, resp. PAdES Basic) varují s tím, že orgány veřejné moci nemají povinnost je přijímat (viz pravá část obrázku).
V neposlední řadě jde také o to, které certifikáty budou ten který nástroj či služba „znát“ a důvěřovat jim – aby podle nich vůbec mohly provést ověření platnosti a dospět k výsledku „platný“. Zde velmi pomohlo nařízení eIDAS, které zdárně vyřešilo způsob rozpoznávání kvalifikovaných certifikátů a dovozování důvěry v ně, a to v rámci celé EU. Podrobnější popis (celé koncepce tzv. důvěryhodných seznamů) by si ale zasloužil samostatný díl tohoto seriálu. A tak si jen řekněme, že problém může přetrvávat tam, kde se nejedná o kvalifikované certifikáty. Například služba DSS (na následujícím obrázku vlevo) nezná komerční certifikáty I.CA, PostSignum ani eIdentity. To Adobe Reader (vpravo) „zná“ komerční certifikáty od I.CA a PostSignum (díky zařazení jejich vydavatelů do vlastního důvěryhodného seznamu AATL společnosti Adobe), ale nezná komerční certifikáty od společnosti eIdentity.
Validační politiky
Důležitý pak je celkový závěr (z existence oněch „stupňů volnosti“): výsledek ověření stejného dokumentu (resp. jeho podpisů, pečetí a časových razítek) se může lišit podle toho, jaký nástroj (či služba) je k ověření použit, a dokonce i podle toho, jak je nastaven. Proto je dobré vědět, jak takové nástroje a služby pro ověřování fungují, co a jak se u nich dá nastavit, a jimi poskytované výsledky hodnotit v tomto kontextu.
Kvalifikované služby pro ověřování platnosti by o způsobu svého fungování měly řádně a plně informovat, skrze svou tzv. validační politiku. Příkladem může být podrobná validační politika Národní certifikační autority (NCA), vztahující se k její službě NCA QVerify. Poněkud odlišně (a stručněji) jsou koncipovány jiné (o něco starší) validační politiky, např. pro služby SecuSign, Obelisk Validator QTS či QVerify od I.CA.
Zájemcům o detailnější informace bych ale doporučil nejspíše popis „validačního algoritmu“ unijní služby DSS. Ta sice sama nemá statut kvalifikované služby a nehraje si na závazný výklad pravidel ověřování (jde jen o „demonstrační verzi“ referenční implementace celého frameworku), ale je základem, na kterém je vybudována řada již kvalifikovaných služeb, včetně některých tuzemských.
Horší je to v praxi s takovými nástroji a službami, které nejsou kvalifikovanými a nemají povinnost popisovat své konkrétní fungování. Pokud jej pak přeci jen popisují, mohou tak činit v rozsahu a způsobem, který si samy zvolí. Příkladem může být popis ověřování v Adobe Acrobatu i Readeru.
Co je „okamžik podpisu“ a co „nejlepší okamžik podpisu“?
Po tomto krátkém exkurzu do obecnějších souvislostí se již můžeme vrátit k hlavnímu tématu dnešního dílu: k otázce toho, k jakému časovému okamžiku má být ověřována platnost elektronického podpisu (či pečeti nebo časového razítka). Tedy jak má být zvolen onen rozhodný okamžik – ke kterému jsou vyhodnocovány příslušné podmínky. Hlavně to, zda tento okamžik spadá do doby řádné platnosti certifikátu a zda předchází okamžiku účinků případné revokace.
Nejprve si řekněme, že nařízení eIDAS hovoří obecně (především v článku 32) o tom, že příslušné podmínky by měly být posuzovány k „okamžiku podpisu“ (v anglické verzi „time of signing“). Co je ale takovýmto „okamžikem podpisu“? Jak tento právní pojem vykládat? Měl by to být onen deklarovaný čas podepsání, který se bere ze systémových hodin počítače a na který se (obecně) nemůžeme spoléhat?
Již jednou zmiňovaný technický standard ETSI pro ověřování deklarovanému času podepsání také moc nevěří, když jej ve svých definicích vykládá tak, že jde o „čas tvrzený podepisující osobou, který sám o sobě neposkytuje nezávislý důkaz skutečného času podepsání“. Připouští ale jeho využití tam, kde existuje nějaký dostatečně pádný důvod domnívat se, že přeci jen jde o skutečný čas podepsání.
Proto technický standard při formulaci konkrétních postupů ověřování pracuje s jinak vymezeným časovým okamžikem (v roli „rozhodného okamžiku“), kterému říká best signature time (doslova nejlepší okamžik podpisu). A ten definuje tak, že jde o nejranější okamžik, ke kterému se algoritmus ověřování může spoléhat, že podpis již existoval. A to buď díky tomu, že to prokazuje nějaký „důkaz o existenci v čase“ (nějaké PoE, viz výše), nebo proto, že jde o okamžik, který vyplývá z validační politiky či který algoritmu direktivně určil „někdo shůry“ (zjednodušeně: správce či uživatel, resp. jím vytvořené nastavení, nebo nějaká nadřazená aplikace). Což nakonec může být i onen deklarovaný čas podepsání nebo nějaký jiný čas, který si uživatel zvolí. Například okamžik, kdy byl podepsaný dokument doručen na jeho podatelnu.
Jak vybírá rozhodný okamžik služba DSS?
Ukažme si vše na konkrétním příkladu fungování služby DSS. Připomeňme si, že jde o veřejně dostupnou („demonstrační“ a referenční) implementaci programového nástroje, resp. knihovny (frameworku), který pro EU vyvinula lucemburská společnost Nowina. Dnes je na tomto základě postavena řada kvalifikovaných služeb pro ověřování platnosti elektronických podpisů a pečetí po celé EU.
V již jednou zmiňovaném popisu algoritmu, podle kterého služba při ověřování postupuje, se dočteme, že onen „okamžik podpisu“ (time of signing), ke kterému provádí ověření, si také vykládá ve smyslu „nejlepšího okamžiku“ a volí jej jako nejranější okamžik, ke kterému existuje důkaz o existenci v čase (PoE) v podobě (platného) časového razítka. A pokud žádný takový k dispozici nemá, zůstává u aktuálního času (jako výchozí varianty / defaultu).
Příklad můžeme vidět na následujícím obrázku. Jde o podpis s deklarovaným časem podepsání dne 1. 8. 2022 (což vzniklo přetočením hodin) a s (platným kvalifikovaným elektronickým) časovým razítkem s datem připojení 18. 5. 2023. Jelikož zde služba DSS našla důkaz o existenci v čase (PoE) v podobě časového razítka, mohla jako „best signature time“ (nejlepší okamžik podpisu) zvolit právě čas časového razítka a k němu také ověřovat platnost podpisu. Jiným slovy, rozhodným okamžikem zde byl čas připojení časového razítka. Nikoli deklarovaný čas podepsání převzatý z přetočených systémových hodin.
Pro srovnání je v pravé části obrázku stejný podpis na dokumentu, ale v Adobe Acrobat Readeru: červeně je vyznačen deklarovaný čas podepsání, zeleně čas časového razítka a modře zvolený rozhodný okamžik (resp. best signature time). Číselný rozdíl dvou hodin zde jde na vrub rozdílným časovým pásmům, ke kterým jsou údaje o čase vztaženy.
Nicméně i službě DSS můžeme jako uživatelé přikázat, aby nehledala žádné důkazy o existenci v čase (PoE) a jako rozhodný okamžik zvolila „natvrdo“ aktuální čas. Tedy aby fakticky ignorovala časová razítka, pokud jsou na dokumentu přítomna. Lze toho dosáhnout skrze volbu některého ze tří tzv. „validačních procesů“, se kterými počítá i technický standard pro ověřování (na následujícím obrázku v oranžovém a fialovém rámečku v horní části).
Konkrétní příklad vidíte na následujícím obrázku: jde o podpis založený na certifikátu, který byl revokován dne 17. 5. 2023 ve 22:52 našeho času, resp. 20:52:03 (koordinovaného světového času, UTC). Nicméně podpis vznikl ještě před revokací, což dokládá (kvalifikované elektronické) časové razítko připojené 17. 5. 2023 ve 20:34:27 našeho času (resp. 18:34:27 UTC).
V levé části obrázku je výsledek ověření při standardním nastavení služby DSS (konkrétně je nastaven doporučený „validační proces pro podpisy poskytující dlouhodobou dostupnost a integritu validačních dat“, viz oranžový rámeček). Při tomto nastavení služba hledá všechny důkazy o existenci v čase (PoE), tj. vyhodnocuje i časová razítka a bere je v úvahu. Proto zde mohla vyhodnotit podpis jako platný (protože našla důkaz, že existoval ještě před revokací).
Naopak v pravé části obrázku byl zvolen „validační proces pro základní podpisy“, který si nevšímá časových razítek a ověřuje „natvrdo“ k aktuálnímu času (zde 20. 5. 2023, kdy byl obrázek nasnímán). To už ale bylo po revokaci certifikátu a službě DSS se podařilo získat relevantní revokační informace a podle nich zjistit, že certifikát byl již revokován.
Nicméně služba DSS neměla jistotu, kdy podpis vznikl (resp. již existoval), zda již před revokací, či po ní – což sama indikuje příznakem (sub-indication) „REVOKED_NO_POE“. To právě proto, že si při zvoleném „validačním procesu“ nevšímala časových razítek a měla k dispozici jen deklarovaný čas podepsání. Ten sice signalizuje, že podpis měl vzniknout ještě před revokací, ale jelikož služba DSS bere tento údaj jako nespolehlivý, zachovala se tak, jako kdyby o čase podepsání nic nevěděla – a proto skončila pokrčením rameny a konstatováním, že platnost podpisu je neznámá.
Má smysl ověřovat k nějakému pozdějšímu časovému okamžiku?
K tomu ještě jedna důležitá poznámka: ověřování k nějakému pozdějšímu časovému okamžiku (oproti „správnému“ času) nemůže vést k nesprávnému závěru, že podpis je platný. Protože pokud podpis lze (stále ještě) ověřit jako platný k pozdějšímu časovému okamžiku, musely být všechny příslušné podmínky splněny i k předchozímu „správnému“ časovému okamžiku (který neznáme, nebo si jím nejsme jisti). Samozřejmě pod jednou důležitou podmínkou: že certifikační autority nevydávají své certifikáty „dopředu“ (ale jen tak, že okamžik vydání certifikátu nepředchází začátku jeho řádné doby platnosti). Zjednodušeně: pokud podpis nemohl vzniknout před začátkem řádné doby platnosti certifikátu. Splnění této podmínky ale předpokládají relevantní technické standardy.
Jinými slovy: když neznáme čas, kdy podpis skutečně vznikl, nebo se na něj jen nemůžeme spoléhat, má smysl pokoušet se ověřit podpis k nějakému pozdějšímu okamžiku. Buď k tomu, o kterém máme jistotu, že podpis již existoval, či k aktuálnímu času (viz výše). Protože pokud je výsledkem tohoto ověření konstatování, že podpis je platný, můžeme z toho dovozovat, že by stejný výsledek platil i v případě ověřování k okamžiku, kdy podpis skutečně vznikl (za splnění oné podmínky, že nemůže vzniknout „dopředu“, před začátkem platnosti certifikátu).
Opačně to samozřejmě neplatí: pokud ověřujeme k nějakému pozdějšímu okamžiku, mohlo se stát, že v mezidobí jsme o možnost ověřit podpis jako platný již přišli. Buď proto, že již skončila řádná doba platnosti certifikátu, nebo proto, že nastaly účinky revokace. Nebo se nám ověření nedaří proto, že již nejsou dostupné nezbytné revokační informace.
Připomeňme si ale to, co jsme si kladli na srdce ve druhém dílu tohoto seriálu: že ověření platnosti elektronického podpisu či pečeti není samo o sobě cílem, ale prostředkem – k tomu, abychom o podepsaném dokumentu mohli dovozovat jeho „právní“ vlastnosti: jeho autenticitu a pravost. Pokud se nám podaří ověřit uznávaný či kvalifikovaný podpis jako platný (třeba i k nějakému pozdějšímu okamžiku), můžeme z toho autenticitu i pravost dokumentu dovozovat přímo.
Pokud se nám to nepodaří (a ověřování platnosti skončí oním pokrčením rameny), ještě to nijak nepopírá autenticitu či pravost dokumentu. Ten stále může být autentický i pravý – jen to nemůžeme dovozovat přímo ze samotného podpisu. Potřebujeme k tomu něco dalšího, případně úplně jiného.
Jak se volí rozhodný okamžik v Adobe Readeru?
Ukažme si ještě, jak je to se stanovením rozhodného okamžiku u aplikace Adobe Acrobat Reader. Ta nabízí hned tři varianty toho, jak má být rozhodný okamžik určen. Nastavují se v Předvolbách programu, v sekci věnované podpisům, a jsou prezentovány jako možnosti ověřovat podpisy s využitím:
- (deklarovaného) času vytvoření podpisu,
- času časového razítka,
- aktuálního času.
Na rozdíl od služby DSS je zde tedy možnost vycházet z deklarovaného času podepsání. Dokonce je to výrobcem nastavená možnost (tzv. default), která na první pohled vypadá velmi nesprávně. Nicméně je potřeba vědět, jak tato varianta doopravdy funguje: deklarovaný čas podepsání program použije jako rozhodný okamžik pouze tehdy, pokud nemá nic „lepšího“. Jen tehdy, pokud podpis není opatřen (platným) časovým razítkem.
Pokud ale podpis je opatřen časovým razítkem, a to je programem ověřeno jako platné, Reader jako rozhodný okamžik, ke kterému posuzuje platnost podpisu, použije tento čas. Postupuje tedy vlastně tak, jak by se dalo očekávat od druhé varianty.
Příklad ukazuje následující obrázek: vlevo je podpis bez časového razítka (PAdES B-B) a jeho platnost Reader skutečně ověřoval k deklarovanému času podepsání. Vpravo je příklad podpisu s časovým razítkem (PAdES B-T) a jeho platnost Reader (při stejném nastavení na „čas vytvoření podpisu“) již ověřoval k času časového razítka.
V případě druhé varianty postupuje Reader tak, že se řídí časem platného časového razítka (viz pravá část následujícího obrázku). Pokud ale toto razítko není ověřeno jako platné nebo pokud u podpisu vůbec není, Reader jako rozhodný okamžik použije aktuální čas a platnost ověřuje k tomuto času. Ukazuje to levá část následujícího obrázku, na které jsou stejné dokumenty jako na předchozím obrázku (a jiné je jen nastavení Readeru).
Konečně v případě třetí varianty Adobe Acrobat Reader nastaví rozhodný okamžik vždy na aktuální čas a k němu také platnost ověřuje. A to bez ohledu na to, zda je u podpisu časové razítko.
Defaultní nastavení Adobe Acrobat Readeru (i samotného Acrobatu) na první popisovanou variantu tedy není úplně správné (když při absenci časového razítka důvěřuje deklarovanému času podepsání). Bezpečnější je druhá varianta, kdy rozhodným okamžikem je buď čas časového razítka, nebo aktuální čas. Což mimochodem odpovídá i možnostem, které nabízí služba DSS.
Ještě větším problémem Readeru je ale to, že každý podpis, pečeť či (dokumentové) časové razítko ověřuje samostatně, bez ohledu na případnou přítomnost dalších podpisů, pečetí a (dokumentových) časových razítek. To vadí hlavně u dokumentů, ke kterým přidáváme další (dokumentová) časová razítka, abychom udrželi jejich aktuální digitální kontinuitu (a povyšujeme tak úroveň podpisu na LTA). Reader ale jejich efekt nedokáže využít: čas připojení (dokumentového) časového razítka nepoužije jako rozhodný okamžik pro ověření předchozího podpisu a jeho (podpisového) časového razítka.
Jak je to s úrovněmi podpisů (B, T, LT a LTA), jak pomáhají aktuální digitální kontinuitě i jak by mělo probíhat jejich ověřování, si ale již necháme na příště.
