Vyšlo na Lupě, 08.08.2016
Vytištěno z adresy: http://www.earchiv.cz/b16/b0808001.php3

eIDAS a el. podpisy (7): jak poznáme, o jaký podpis jde?

Většina konkrétních produktů a služeb zatím není příliš připravena na nové nařízení. Ten, kdo se chce na „nové“ elektronické podpisy spoléhat, si tak mnohdy musí poradit sám. Ale jak?

V dnešním závěrečném dílu tohoto letního seriálu o novém unijním nařízení č. 910/2014 (eIDAS) se dostaneme k tomu asi nejpodstatnějšímu: jak ten, kdo má před sebou nějaký (platný) elektronický podpis (neboli: spoléhající se strana) pozná, o jaký druh podpisu jde? Či zda jde o značku nebo pečeť? Aby dokázal zhodnotit, zda splňuje požadavky, které na konkrétní úkon (právní jednání) klade samotné nařízení eIDAS či další právní předpisy (náš zákon o službách vytvářejících důvěru, další zákony a prováděcí předpisy, různé interní směrnice apod.).

Zajímavé a podstatné je, že definitivní podoba nového nařízení je na světě již nějaký ten pátek, a stejně tak i relevantní technické standardy, o které se opírají i prováděcí předpisy nového nařízení. Bylo by tedy logické očekávat, že nejrůznější programy a služby pro práci s elektronickými dokumenty a podpisy jsou na požadavky (i třeba terminologii) nového nařízení již připraveny.

Nehledě na to, že by už mohly existovat i (kvalifikované) služby pro ověřování platnosti (kvalifikovaných) elektronických podpisů, s jejichž existencí počítá článek 33 nového nařízení.

Jak si ale ukážeme, pravý opak je pravdou. Připraveno je minimum produktů a služeb. O to větší nároky to klade na uživatele v roli spoléhající se strany, protože ten si musí nějak poradit i tam, kde mu jím používané nástroje nijak nepomohou. A k tomu nutně potřebuje určité znalosti.

Co všechno potřebujeme zkoumat?

Aby spoléhající se strana mohla vyhovět všem požadavkům, které na ní mohou být kladeny, potřebuje znát odpovědi ze tří různých okruhů otázek:

  • zda jde o elektronický podpis, elektronickou značku či elektronickou pečeť.
  • o jaký druh elektronického podpisu jde: zda o kvalifikovaný el. podpis, uznávaný el. podpis, zaručený el. podpis či jiný druh podpisu. Obdobně pro značky a pečetě.
  • jaký je formát elektronického podpisu (značky, pečetě): zda jde o úroveň B, T, LT či LTA, případně o podpis na „kontejneru“, nebo o jiný formát.

Pojďme si nyní stručně říci něco o každé z těchto oblastí. Současně s tím si budeme ukazovat, jak nám v tom pomohou (či naopak nepomohou) některé námi používané programy a služby.

Podpisy, značky a pečetě

Připomeňme si, že nové nařízení eIDAS rozlišuje mezi elektronickými podpisy, které mohou vytvářet (právě a pouze) fyzické osoby, a elektronickými pečetěmi, které mohou vytvářet (právě a pouze) právnické osoby (zahrnující i organizační složky státu). A zatímco el. podpis je chápán jako projev vůle fyzické osoby vůči jakémukoli dokumentu (tj. podepsat lze i cizí dokument), v případě elektronické značky nejde o projev vůle, ale o vyjádření původu (el. značku lze přidat jen na něco vlastního, čeho je právnická osoba původcem).

Kromě toho náš adaptační zákon po přechodnou dobu (2 let) zachovává ještě možnost použití dosavadních elektronických značek. Viz předchozí díly.

Podle čeho se ale pozná, zda v konkrétním případě jde o podpis, značku či pečeť?

V prvním přiblížení by odpověď mohla znít tak, že se to odvíjí od druhu certifikátu: elektronické podpisy jsou založeny na certifikátech pro elektronický podpis, elektronické pečetě na certifikátech pro elektronické pečeti, a dožívající elektronické značky na systémových certifikátech. A že každý certifikát má v sobě uvedeno, co je zač.

Ve skutečnosti to tak jednoduché není. Třeba proto, že „prosté“ elektronické podpisy a „prosté“ elektronické pečeti vůbec nemusí být založeny na certifikátech a kryptografických technikách. Jen pro připomenutí, z třetího dílu tohoto seriálu: prostým elektronickým podpisem může být úplně cokoli, co někdo použije jako svůj podpis. Třeba nějaký text, nebo jen jediné slovo, i jen písmenko, znaménko, či obrázek, ikona, smajlík apod.

Další problém pak je v tom, že nové nařízení sice požaduje, aby certifikát sám o sobě říkal, že je certifikátem pro elektronický podpis či pro elektronickou pečeť – ale požaduje to jen po těch certifikátech, které jsou kvalifikované. Jen ty musí povinně obsahovat „označení, alespoň ve formě vhodné pro automatické zpracování, že se certifikát vydává jako kvalifikovaný certifikát pro elektronický podpis“ (viz příloha I nového nařízení), a obdobně pro pečeti (příloha III). Jak konkrétně to vypadá, si ukážeme dále.

Povšimněte si ale onoho „alespoň ve formě vhodné pro automatické zpracování“: takže alespoň programy by měly mít šanci (pro sebe srozumitelným způsobem) poznat, o jaký druh certifikátu jde. Pro člověka už to tak snadné být nemusí, jak ostatně záhy poznáme.

Na druhou stranu dosavadní praxe našich certifikačních autorit je taková, že do kvalifikovaných certifikátů přeci jen dávají také informaci v podobě srozumitelné i pro člověka (který se umí „podívat  dovnitř“ certifikátu). Byť tato informace není „tou rozhodující“, jak svého času ukázal problém, který mělo naše PostSignum (když tuto „lidsky čitelnou“ informaci uvádělo nesprávně).

Příklad vidíte na obrázku (vlevo je pohled na konkrétní kvalifikovaný certifikát pro elektronický podpis pomocí utilit operačního systému Windows, vpravo pohledem programu Adobe Acrobat Reader DC).

 
Lidsky čitelná informace o tom, že certifkát je kvalifikovaný
 

Kvalifikované, uznávané a zaručené podpisy a pečetě

Pokud už víme, že něco je elektronickým podpisem, pečetí (či značkou), mělo by nás zajímat, o jaký druh elektronického podpisu jde (a obdobně u pečetí a značek).

Připomeňme si, jaké možnosti připadají v úvahu dnes, již za účinnosti nového nařízení eIDAS a s předpokládanou účinností nového adaptačního zákona (byť je teprve na cestě mezi Sněmovnou a Senátem). Nejprve pro elektronické podpisy (a to od nejvyšší formy el. podpisu po nejnižší):

  • kvalifikovaný elektronický podpis (QES, Qualified Electronic Signature): po „technické“ stránce musí jít o zaručený elektronický podpis (AdES, Advanced Electronic Signature), musí být založen na kvalifikovaném certifikátu pro elektronický podpis a musí být vytvořen pomocí kvalifikovaného (dříve, podle původní terminologie: bezpečného) prostředku pro vytváření elektronických podpisů. Tak se říká čipovým kartám a USB tokenům, které prošly potřebnou certifikací.
  • zaručený elektronický podpis, založený na kvalifikovaném certifikátu: liší se od kvalifikovaného el. podpisu absencí požadavku na použití kvalifikovaného prostředku (čipové karty/tokenu). Stále tedy musí jít o zaručený elektronický podpis, a musí být založený na kvalifikovaném certifikátu. V praxi: k jeho vytvoření není nutný kvalifikovaný prostředek (certifikovaná čipová karta/token).
  • zaručený elektronický podpis (AdES, Advanced Electronic Signature): na certifikát, na kterém je založen, nejsou kladeny žádné požadavky. Může to tedy být jakýkoli certifikát, třeba i testovací (který si může vyrobit kdokoli, a napsat si do něj cokoli chce). 
  • „prostý“ elektronický podpis (též: elektronický podpis bez přívlastku, anglicky: ES, Electronic Signature): takovýmto podpisem může být cokoli, co má elektronickou podobu a co někdo použije jako svůj podpis.

Po terminologické stránce je důležité, že náš (dosud stále připravovaný) adaptační zákon, tedy budoucí „Zákon o službách vytvářejících důvěru“, zachovává dosud používaný pojem uznávaný elektronický podpis, ale dává mu jiný obsah a význam, než jaký měl dosud: nově jde o jakousi legislativní zkratku za dva různé druhy elektronických podpisů: za kvalifikovaný el. podpis, a za zaručený podpis, založený na kvalifikovaném certifikátu pro elektronický podpis (viz odst. 2 §6 navrhovaného zákona).

Obdobně je tomu i pro elektronické pečeti: uznávanou elektronickou pečetí může být jak kvalifikovaná elektronická pečeť, tak zaručená elektronická pečeť, založená na kvalifikovaném certifikátu pro elektronické pečeti (odst. 2 §9).

Přitom existují, resp. budou existovat situace, kdy bude nutné rozlišovat i „v rámci uznávaných podpisů“, zda jde o kvalifikovaný el. podpis, nebo jen o zaručený podpis, založený na kvalifikovaném certifikátu. Třeba u jakékoli autorizované konverze, provedené po účinnosti změnového zákona (tzv. „tlusťocha) bude konverzní doložka muset být podepsána kvalifikovaným el. podpisem toho, kdo konverzi provedl (a nebude tedy stačit jakýkoli uznávaný el. podpis). Po skončení dvouleté výjimky bude totéž platit pro cokoli, co vyprodukují orgány veřejné moci (v rámci své působnosti).

Jak se pozná, že byl použit kvalifikovaný prostředek?

Jak se ale v praxi pozná, že nějaký konkrétní elektronický podpis je skutečně kvalifikovaným elektronickým podpisem, a nikoli pouze zaručeným el. podpisem, založeným na kvalifikovaném certifikátu? Rozlišujícím kritériem je to, zda při vytváření podpisu byl či nebyl použit kvalifikovaný prostředek (certifikovaná čipová karta či token).

Určitě se ale nedá požadovat, aby každé podepisující straně vždy někdo koukal přes rameno a díval se, jaký prostředek právě používá. Takové řešení samozřejmě nepřipadá v úvahu. Dá se to ale zařídit jinak.

Požadavku na použití kvalifikovaného prostředku pro vytváření el. podpisů se dá vyhovět tak, že soukromý klíč bude uložen v onom prostředku pro vytváření elektronických podpisů (certifikované čipové kartě či tokenu), a nebude možné ho „dostat ho ven“ (tj. nebude existovat možnost exportu soukromého klíče). To je totiž jednou z podstatných vlastností kvalifikovaných prostředků (že neumožňují export soukromých klíčů). Současně to znamená, že soukromý klíč musel už vzniknout (být vygenerován) přímo v takovémto prostředku. A stejně tak to znamená, že samotné podepisování (jako operace s daty, zahrnující samotný soukromý klíč) probíhá uvnitř kvalifikovaného prostředku (uvnitř čipové karty či USB tokenu).

Obě tyto podmínky (generování klíče a nemožnost jeho exportu) se dají rozpoznat v okamžiku generování žádosti o vydání certifikátu: příslušný program (či applet), který je k tomuto účelu používán, musí „znát“ čipovou kartu či token, se kterou právě pracuje. Musí vědět, že párová data (soukromý i veřejný klíč) jsou generována přímo v této čipové kartě, a soukromý klíč se „nemůže dostat ven“ (nemůže být exportován).

 
Volba úložiště pro generování párových dat (soukromého a veřejého klíče)
 

Pokud tomu tak je, může program generující žádost „dát své dobrozdání“ certifikační autoritě, která certifikát vystavuje – a ta zapíše do vystavovaného certifikátu poznámku o tom, že příslušný klíč je umístěn v kvalifikovaném prostředku pro vytváření elektronických prostředků.

Konkrétně ji zapíše do rozšiřující položky certifikátu s názvem QcStatements (resp. Qualified Certificate Statements), kde mohou být (resp. jsou) umisťovány i další údaje, týkající se kvalifikovaného statusu certifikátu. Na následujícím obrázku vidíte, jak obsah této položky zobrazuje prohlížeč certifikátů, zabudovaný v Adobe Readeru (resp. dnes již Adobe Acrobat Readeru DC), včetně nepříliš vhodného českého překladu názvu položky: Výpisy QC. Proto je na obrázku raději i anglická verze:

 
Zobrazení obsahu položky QcStatements
 

To prohlížeč certifikátů, zabudovaný přímo do operačního systému MS Windows, překládá název položky QcStatements lépe, jako „Prohlášení kvalifikovaného certifikátu“. Jenže se zase nenamáhá převést jeho obsah do lidsky čitelné podoby, viz další obrázek (na kterém je stejný „nový“ certifikát jako na předchozím obrázku, vydaný jako kvalifikovaný certifikát pro elektronický podpis již podle nového nařízení eIDAS).

 
Obsah položky QcStatements, tak jak jej zobrazuje standardní prohlížec v MS Windows
 

Připomeňme si, že podle nového nařízení se prostředek pro vytváření elektronických podpisů, splňující všechny požadavky zákona a řádně certifikovaný, označuje jako „kvalifikovaný“, a používá se pro něj anglická zkratka QSCD (od: Qualified Signature Creation Device). Dříve, ještě podle již zrušené směrnice 1999/93/ES, se označoval jako „bezpečný“, a používala se pro něj zkratka SSCD (Secure Signature Creation Device).

 
Příklad kvalifikovaného certifikátu, vydanéno ještě podle původní směrnice
 

Jde o kvalifikovaný elektronický podpis?

Programy, které uživatelé používají pro práci s elektronickými podpisy, mohou vycházet z obsahu rozšiřující položky QcStatement, a podle toho hodnotit jak samotný certifikát, tak i konkrétní podpis, který je na certifikátu založen. Samozřejmě: pokud to takovéto programy umí a ví, kam a po čem se mají dívat, i jak a co hodnotit.

Například oblíbené prohlížeče Adobe Reader (resp. Adobe Acrobat Reader DC) s obsahem položky QcStatements určitým způsobem pracovat umí. Na následujícím obrázku vidíte, jak Reader zobrazuje a jak interpretuje obsah položky QcStatements u „staršího“ certifikátu (z let 2011/2012): správně rozpozná, že jde o kvalifikovaný certifikát, vydaný ještě podle původní směrnice 1999/93/ES. Stejně tak Reader správně rozpoznal, že odpovídající soukromý klíč je (resp. byl) umístěn v bezpečném zařízení pro vytváření elektronických podpisů (SSCD).

 
Adobe Reader správně interpretuje obsah položky QcStatements
 

Konkrétní elektronický podpis, založený na takovémto certifikátu, pak Reader dokáže správně vyhodnotit jako kvalifikovaný el. podpis (s odkazem na to, že jde o kvalifikovaný podpis dle původní směrnice 1999/93/ES). Viz příklad na následujícím obrázku.

 
Adobe Reader správně vyhodnotil druh elektronického podpisu
 

Ovšem když jsem stejnému Adobe Acrobat Readeru DC (v nejaktuálnější verzi) předložil el. podpis, založený na „novém“ kvalifikovaném certifikátu od I.CA (vydaném již dle nového nařízení) a vytvořený s využitím kvalifikovaného prostředku (QSCD, Qualified Signature Creation Device), již to tak dobře nedopadlo.

Program sice správně vypsal obsah položky QcStatements, ale už jej nedokázal správně interpretovat – nepoznal ani to, že jde o kvalifikovaný certifikát. Pak ani nemohl dojít k závěru, že jde o kvalifikovaný podpis.

 
Adobe Reader nesprávně interpretuje obsah položky QcStatements
 

Obdobný problém se nejspíše bude týkat většiny aktuálně dostupných programů, které ještě nejsou připraveny na nové nařízení č. 910/2014 (eIDAS), nedokáží správně rozpoznat kvalifikované certifikáty, a pak ani kvalifikované podpisy. Snad to zvládnou alespoň jejich novější (aktualizované) verze.

Stejné to nejspíše bude s nejrůznějšími spisovými službami a dalšími informačními systémy, které také nějakým způsobem pracují s elektronickými podpisy (ale i pečetěmi a značkami), a mají v sobě zabudovány prostředky pro rozpoznávání toho, o jaký druh elektronického podpisu/pečetě/značky se jedná. I zde bude nutná jejich aktualizace, pokud ještě nebyla provedena.

Jak poznat kvalifikovaný podpis „ručně“?

Jak ale postupovat v situaci, kdy potřebujete rozpoznat kvalifikovaný elektronický podpis (či elektronickou pečeť), ale vámi používaný program to ještě neumí?

Odpověď je taková, že si musíte pomoci sami: podívat se do výše popisované položky QcStatements a orientovat se podle jejího obsahu. Ten definují technické standardy, na které se odkazují i prováděcí předpisy k nařízení eIDAS.

Obecně lze v rozšiřující položce QcStatements najít až čtyři kategorie informací:

  • zda jde o kvalifikovaný certifikát dle unijní legislativy - dle již zrušené směrnice 1999/93/ES, nebo dle nového nařízení 910/2014 (eIDAS)
  • zda je soukromý klíč uložen v kvalifikovaném prostředku (dříve: bezpečném prostředku)
  • odkaz na informace od certifikační autority pro uživatele 
  • upřesnění konkrétního typu kvalifikovaného certifikátu

Drobný technický problém je v tom, že obsah položky QcStatements je určitým způsobem zakódován, takže není jednoduše srozumitelný pro člověka. Ostatně, samotné nařízení eIDAS nejspíše nepočítá s tím, že by s obsahem této položky lidé pracovali nějak přímo, a nikoli skrze vhodné programy. A tak požaduje pouze „strojově čitelnou“ podobu příslušných údajů.

Pokud se tedy nechcete „hrabat v hexa kódu“, standardní prohlížeč certifikátů z OS Windows vám nepomůže (viz výše). Ale prohlížeč certifikátů z Adobe Readeru již ano (opět viz výše).

Velmi detailní „rozpis“ obsahu položky QcStatements pak může poskytnout třeba utilita Certutil, která je standardní součástí operačního systému Windows. Ta vám názorně rozepíše, co a jak je v položce QcStatements uvedeno. Příklad vidíte na následujícím obrázku.

 
Textový výpis obsahu položky QcStatements, pomocí utility Certutil z MS Windows
 

Povšimněte si prvního údaje (OID s hodnotou 0.4.0.1862.1.1, resp. hexadecimálně 04 00 8e 46 01 01). Jeho přítomnost udává právě to, že jde o kvalifikovaný certifikát podle evropské legislativy, ať již původní směrnice 1999/93/ES, nebo nového nařízení 910/2014 (eIDAS). Tento údaj by v položce QcStatements měly mít (a mají) všechny certifikáty vydané jako kvalifikované – ať již jde o certifikáty pro elektronický podpis, systémové certifikáty pro dosavadní elektronické značky, či certifikáty pro budoucí el. pečeti.

Druhý údaj (OID s hodnotou 0.4.0.1862.1.4, resp. hexadecimálně 04 00 8e 46 01 04) zase vypovídá o tom, že příslušný soukromý klíč je umístěn v bezpečném (resp. dnes: kvalifikovaném) prostředku pro vytváření el. podpisů, ev. pečetí. Právě z přítomnosti či absence tohoto údaje v certifikátu je pak třeba vycházet při „ručním“ posuzování toho, zda konkrétní el. podpis (či pečeť) byl či nebyl vytvořen pomocí kvalifikovaného (dříve: bezpečného) prostředku, a je tedy (či není) kvalifikovaným elektronickým podpisem (pečetí).

Pokud opravdu nemáte jinou možnost (než standardní prohlížeč certifikátů z OS Windows, který nerozepisuje obsah položky QcStatements do lidsky čitelné podoby), můžete jako opravdu nouzové řešení hledat v této položce alespoň příslušné hexadecimální hodnoty:

  • 30 08 06 06 04 00 8e 46 01 01 pro kvalifikovaný certifikát
  • 30 08 06 06 04 00 8e 46 01 04 pro použití kvalifikovaného/bezpečného prostředku (skrze umístění soukromého klíče)

Několik příkladů ukazuje následující obrázek. Červeně podtržené jsou hodnoty, udávající že jde o kvalifikovaný certifikát dle unijní legislativy. Zeleně podtržené hodnoty udávají, že soukromý klíč je umístěn v kvalifikovaném (bezpečném) prostředku.

 
Jaké hexadecimální hodnoty hledat v položce QcStatements?
 

Jak lze z obrázku dovodit, certifikát nejvíce vlevo je kvalifikovaný certifikát bez umístění soukromého klíče v kvalifikovaném prostředku. Zbývající dva již mají soukromý klíč umístěný v kvalifikovaném prostředku: prostřední certifikát byl vydán jako kvalifikovaný ještě před účinností současného nařízení, a tedy dle původní směrnice, resp. dosavadního zákona č. 227/2000 Sb. o elektronickém podpisu. Certifikát nejvíce vpravo pak byl vydán již podle nového nařízení.

Jaký formát má elektronický podpis?

Další věcí, kterou je dobré umět rozpoznat u konkrétních elektronických podpisů (a pečetí), je jejich formát. Nejenom proto, že jen některé formáty jsou vhodné pro dlouhodobější využití (a udržování tzv. digitální kontinuity).

Podstatné je také to, že nové nařízení vychází z předpokladu, že určité „hlavní“ formáty by měl umět ověřit každý (v roli příjemce, resp. spoléhající se strany). A pokud někdo nějaký podpis vytváří (tj. je podepisující se stranou), měl by používat právě takovéto formáty podpisů. Není to ale bezpodmínečně nutné – pokud přeci jen použije nějaký jiný formát, může tak udělat, ale musí příjemci (obecně komukoli) zpřístupnit nástroj pro okamžité, jednoduché a samozřejmě i správné ověření platnosti takového podpisu. Tedy vhodný validátor, resp. validační službu.

Jde přitom o princip, který není nikterak nový: v roce 2011 jej zavedlo Rozhodnutí Komise 2011/130/ES, které ony „hlavní“ formáty pojmenovalo jako referenční – a vymezilo je podle tehdy platných technických norem ETSI. Bez zacházení do technických detailů si řekněme, že jde o takové formáty, které (oproti dříve používaným) formátům zahrnují do dat, chráněných proti změně samotným podpisem, také podpisový certifikát a údaj o okamžiku vzniku podpisu (byť pouze ten „tvrzený“, který je přebírán ze systémových hodin počítače, a na jehož správnost se tedy nelze spoléhat). Dále tyto „referenční“ formáty umožňují přidávání dalších informací (zejména revokačních informací a dokumentových/archivních časových razítek), pro potřeby zajišťování digitální kontinuity.

Původní referenční formáty, stanovené v Rozhodnutí komise z roku 2011, vycházely z tehdejších norem ETSI. Jednalo se konkrétně o formáty, zakončené koncovkami BES (od: Basic Electronic Signature) a EPES (Explicit Policy Electronic Signatures). Takže třeba předepsané referenční formáty podpisů na PDF dokumentech byly formáty PAdES-BES a PAdES-EPES. Pro dlouhodobější využití pak sloužily formáty úrovně LTV (například: PAdES-LTV), zahrnující také potřebné revokační informace.

A třeba oblíbené Adobe Readery dokáží rozpoznat, zda je podpis na úrovni LTV (tj. umožňující dlouhodobé ověření). Viz obrázek.

 
Adobe Reader rozpoznává podpis ve formátu LT, resp. LTV
 

Záhy se ale technické standardy poněkud změnily: struktura formátů se zjednodušila a převedla do „základních úrovní“ (baseline levels). Jde konkrétně o tyto úrovně:

  • úroveň B (B-level, od: Basic): jde o výchozí úroveň, bez časového razítka
  • úroveň T (T-level, od: Time, resp. Timestam): jde o úroveň B, rozšířenou o časové razítko
  • úroveň LT (LT-level, od: Long Term): jde o úroveň T, doplněnou o revokační informace (CRL seznam či odpověď OCSP serveru)
  • úroveň LTA (LTA-level, od: Long Term Archiving): jde o úroveň LT, doplněnou o dokumentové (tzv. archivní) časové razítko.

Proto bylo v roce 2014 původní rozhodnutí nahrazeno novým Prováděcím rozhodnutím Komise 2014/148/EU, které se již přímo odvolává na příslušné (novější) technické standardy z roku 2013, a hlavně rozšiřuje svůj „záběr“ na všechny výše vyjmenované „baseline“ úrovně (tj. B, T, LT i LTA).

V zásadě totéž nyní dělá jeden z již přijatých prováděcích předpisů již k novému nařízení eIDAS (Prováděcí rozhodnutí Komise (EU) 2015/1506), z 8. září 2015. Přeci jen ale přichází s jednou podstatnou výjimkou: vynechává nejvyšší úroveň (LTA), určenou k dlouhodobé péči o elektronické dokumenty.

Zdůvodňuje to tím, že v současné době probíhá revize představ o tom, jak vlastně se o elektronické dokumenty a jejich podpisy a pečeti v dlouhodobějším výhledu starat:

Vzhledem k tomu, že normalizační subjekty právě provádějí revizi formulářů pro dlouhodobou archivaci určených pro uvedené formáty, nejsou normy pro dlouhodobou archivaci zahrnuty do oblasti působnosti tohoto rozhodnutí. Jakmile bude k dispozici nová verze uvedených norem, budou odkazy na normy a právní ustanovení týkající se dlouhodobé archivace revidovány.

Pravdou je, že také samotné nařízení jako takové dlouhodobější péči o podepsané elektronické dokumenty (jejich „elektronickou archivaci“) nijak neřeší. Jak jsem rozebíral již v předchozích dílech tohoto seriálu, pamatuje jen na „udržování ověřitelnosti“ elektronických podpisů (preservation), což může fungovat jen po omezenou dobu. Konkrétně do oslabení dnes používaných kryptografických algoritmů, zejména pro vytváření otisků (hash-ů) podepisovaných dokumentů. V praxi: do přechodu od dnes používané hashovací funkce SHA-2 k „silnější“ SHA-3.

Jinými slovy: ani samotné nařízení neřeší časovanou bombu v podobě dalších a dalších elektronických dokumentů, které dnes a denně vznikají, a které bude třeba udržovat v „použitelném stavu“ (s možností řádného ověření, i zajištění jejich integrity) po přeci jen delší dobu (než je doba „výdrže“ současné SHA-2).

Ale to by bylo na jiné povídání. Včetně toho, že již zmiňované prováděcí rozhodnutí (ze září 2015) ohledně formátů el. podpisů nejspíše záhy dozná dalších změn, protože v mezidobí vyšly nové verze technických standardů ETSI (ETSI EN 319 1x2). A ty mj. přejmenovávají výše zmiňované úrovně formátů na B-B, B-T, B-LT a B-LTA.

Jak poznáme formát podpisu?

Pojďme si ještě, na samotný závěr tohoto seriálu, trochu rozebrat možnosti rozpoznávání formátu konkrétního elektronického podpisu. Tedy „vlastními silami“, a nikoli v rámci různých spisových služeb a dalších informačních systémů (které to snad budou časem umět také).

Opět to ale nebude moc přímočaré, ani snadné – a to ani když se omezíme jen na nejpoužívanější PDF dokumenty a jejich (zaručené) elektronické podpisy (PAdES: PDF Advanced Electronic Signature). Protože většina dostupných programů a služeb ještě není na eIDAS zcela připravena.

Tak třeba oblíbený Adobe Acrobat Reader DC: ten vám vůbec neřekne, zda jde o novější formáty (PAdES Enhanced a vyšší), nebo ještě o starší (PAdES Basic). Poznali byste to jedině díky tomu, že novější formáty PAdES podporují produkty Adobe až od verze 10. Takže pokud je předhodíte nějaké starší verzi, vyhodnotí to jako neznámý druh podpisu.

 
Adobe Acrobat starší verze (9.X) nedokáže pracovat s novějšími formáty el. podpisů
 

Ovšem než shánět nějakou dostatečně starou verzi Adobe Readeru, je určitě jednodušší zeptat se unijní služby DSS (Digital Signature Service). Jde sice jen o „pracovní“ (demo) verzi, která je navíc stále ve vývoji a nejnovější standardy také ještě nepodporuje – ale s rozpoznáním PAdES podpisů si poradí celkem spolehlivě. Očekává totiž jen novější formáty podpisů – a tak když jí předložíte nějaký podpis ve starším formátu (Basic, resp. CMS), hodnotí to jako chybu ve formátu podpisu. Jak vidíte na následujícím obrázku, jde konkrétně o to, že podpisový certifikát není u starších formátů mezi daty, která jsou chráněna proti změně samotným podpisem (která jsou podepsána).

 
Služba DSS hodnotíá starší verze podpisů jako chybu formátu
 

Tam, kde již jde o novější formáty podpisů, tato služba již celkem spolehlivě pozná jejich úroveň, viz následující obrázky. Stejně tak dokáže detekovat i kvalifikovaný el. podpis (který označuje jako QES), zaručený podpis založený na kvalifikovaném certifikátu (AdESQC), i „pouhý“ zaručený podpis (u kterého ale obvykle narazí na to, že nedokáže posoudit důvěryhodnost podpisového certifikátu, protože nemá z čeho ji odvodit).

Následující obrázek ukazuje vyhodnocení kvalifikovaného el. podpisu úrovně LTA, tedy včetně archivního (dokumentového) razítka.

 
Služba DSS dokáže správně rozpoznat formát úrovně LTA
 

Pro srovnání: jak Adobe Acrobat Reader DC, tak i český Signer si neumí „dát dohromady“ samotný podpis s archivním časovým razítkem, a hodnotí vše samostatně, jako dva objekty (podpis a razítko).

 
Adobe Reader i český Signer interpretují podpis a samostatné časové razítko jako dva objekty
 

Na dalším obrázku vidíte, jak služba DSS vyhodnotila kvalifikovaný el. podpis (QES) úrovně LT (horní část obrázku). Ve spodní části obrázku pak je příklad úrovně T a zaručeného el. podpisu, založeného na kvalifikovaném certifikátu (AdESqc).

 
Služba DSS správně hodnotí úrovně LT i T
 

Povšimněte si poznámky o tom, že „certifikát není podporován bezpečným prostředkem“ (SSCD). I to naznačuje, že služba DSS není ještě připravena na nové nařízení eIDAS (které přejmenovalo „bezpečný“ prostředek na „kvalifikovaný“, a zkratku SSCD nahradilo zkratkou QSCD).

Pokud jde o český Signer (Long-Term Document Signer od Software602), ten se v nedávných dnech naučil rozpoznávat kvalifikované el. podpisy i zaručené podpisy, založené na kvalifikovaném certifikátu.

 
Český Signer již umí vyhodnotit kvalifikovaný elektronický podpis
 
 
Český Signer již umí vyhodnotit i zaručený elektronický podpis, založený na kvalifikovaném certifikátu
 

Svou ověřovací doložku již také přizpůsobil nové terminologii z nařízení eIDAS, i když jazykově ne zcela správně: dříve akreditované certifikační autority dnes nejsou „poskytovatelem služby vytvářejícím důvěru“, ale „poskytovatelem služeb vytvářejících důvěru“. Protože to nejsou přímo ony (autority), kdo vytváří důvěru – ale jsou to teprve jejich služby a produkty (např. certifikáty), na kterých někdo může zakládat svou důvěru v něco/někoho jiného.

Ještě by to ale chtělo aktualizovat také terminologii, týkající se formátů elektronických podpisů a jejich úrovní. Dnes už to není BES/EPES, ale úroveň B (dle nejnovější verze standardů B-B, zřejmě od Baseline-B) – a vyšší (T, LT a LTA).