Podepisujeme se s eliptickými certifikáty, část II: proč to někde ještě drhne?
Adobe Acrobat a Reader si nově již dokáží poradit s „eliptickými“ certifikáty od I.CA. Ale Windows jako takové ještě nikoli. K zařazení do Trusted Root Programu Microsoftu ještě nedošlo.V prvním dílu tohoto malého letního seriálu jsme si ukázali, že už i v ČR se začaly vydávat certifikáty, využívající kryptografii eliptických křivek. Přišla s nimi I.CA, která začala vydávat jak kvalifikované certifikáty pro elektronické podepisování a pečetění, tak i (osobní) komerční certifikáty a technologické serverové (nikoli SSL) certifikáty.
Stejně tak jsme si v předchozím článku ukázali, že s novými „eliptickými“ certifikáty jsou v praxi stále určité problémy. Část z nich může pramenit již z toho, že použité nástroje, utility, komponenty, ovladače, zařízení či další prvky ještě nepočítají s kryptografií eliptických křivek. Pak pomůže jen jejich modernizace, resp. výměna či update/upgrade.
Další problémy pak způsobuje to, že některé nástroje (aplikace, programy) si nedokáží ověřit důvěryhodnost nových „eliptických“ certifikátů. Dnes si řekneme, co je toho příčinou a kdy asi může přijít náprava.
K jedné významné změně přitom došlo už v mezidobí od vydání prvního dílu tohoto malého seriálu – Adobe Acrobat a Reader dnes už dokáží správně rozpoznat kvalifikovaný elektronický podpis, založený na novém „eliptickém“ certifikátu (zatímco v prvním dílu jsem popisoval, jak to ještě neumí).
Na ECC certifikáty s novou „eliptickou“ autoritou
Abychom si mohli vysvětlit, k jaké změně došlo od minulého článku, musíme si nejprve přidat do celé mozaiky jeden další důležitý kamínek.
Na vydávání certifikátů, využívajících kryptografii eliptických křivek, si jejich vydavatel musí vytvořit novou certifikační autoritu (v technickém slova smyslu). Pokud pracuje s hierarchickou strukturou svých autorit, což dnes dělá jak I.CA, tak i PostSignum a eIdentity, musí si nejprve vystavit nový kořenový certifikát (již s využití kryptografie eliptických křivek) a s jeho využitím si vystavit nejméně další dva „eliptické“ certifikáty – jeden pro dceřinou autoritu vydávající kvalifikované certifikáty a druhý pro dceřinou autoritu vydávající ostatní (komerční) certifikáty.
I.CA toto již udělala:
- pro novou kořenovou autoritu si vydala nový (kořenový) certifikát s CN = „I.CA Root CA/ECC 12/2016“, s řádnou dobou platnosti od 7. 12. 2016 do 7. 12. 2041. Ten pak použila k vydání nových certifikátů pro obě dceřiné autority:
- pro kvalifikovanou dceřinou autoritu certifikát s CN = „I.CA Qualified 2 CA/ECC 06/2019“, s platností od 19. 6. 2019 do 16. 9. 2029
- pro komerční dceřinou autoritu certifikát s CN = „I.CA Public CA/ECC 12/2016“, s platností od 7. 12. 2016 do 5. 12. 2026
Teprve pak může vydavatel začít skutečně vydávat nové (koncové) certifikáty svým zákazníkům: ty kvalifikované podepisuje (pečetí) certifikátem své kvalifikované dceřiné autority (ve skutečnosti samozřejmě odpovídajícím soukromým klíčem) a ty komerční pak certifikátem své komerční dceřiné autority.
Ilustruje to následující obrázek, na kterém jsou vidět tzv. certifikační cesty obou mých nových „eliptických“ certifikátů (kvalifikovaný je vlevo, komerční vpravo).
Stejně tomu bude i u ostatních vydavatelů (kvalifikovaných poskytovatelů), až začnou vydávat koncové certifikáty s kryptografií eliptických křivek – také na to budou potřebovat nové certifikační autority, ve výše uvedeném (technickém, nikoli „podnikatelském“) smyslu. Ostatně, vyjádření PostSignum, citované v prvním dílu, to explicitně zmiňuje.
Mimochodem, jak naznačují řádné doby platnosti výše uvedených certifikátů nových autorit, I.CA zřejmě plánovala vydávání komerčních certifikátů již na přelomu let 2016 a 2017 a zmiňovala se o nich již v roce 2015, když přecházela z plošné na hierarchickou strukturu svých autorit. Ale reálně je začala využívat až nyní.
Ovšem: vytvořit nové autority je pouze první krok. Dalším nezbytným krokem je „dát najevo programům“, že takovéto autority existují a že se na ně lze spoléhat. I jaké certifikáty vydávají.
A právě zde se liší řešení používaná pro MS Windows a pro programy Adobe.
Kdy budou nové certifikáty v Trusted Root Programu od Microsoftu?
V případě operačního systému Windows je možné, aby o důvěryhodnosti certifikátu rozhodoval „ručně“ sám uživatel. To by ale měl dělat jen někdo, kdo opravdu dobře ví, co dělá – a tak to zde raději nebudu dále rozvádět.
Jinak (pokud si důvěru neřeší sama aplikace) rozhoduje tvůrce operačního systému, společnost Microsoft: ta má svůj vlastní seznam důvěryhodných certifikátů (vytvářený v rámci programu Microsoft Trusted Root Program), kterým se řídí jednotlivé instalace operačního systému Windows.
Na tento svůj seznam společnost Microsoft sama, podle svých kritérií, zařazuje certifikáty certifikačních autorit, vydávajících certifikáty koncovým uživatelům. Protože jak již tušíme z prvního dílu, důvěra v tyto „koncové“ certifikáty se odvozuje od důvěry v jejich vydavatele (a způsobu jejich vydávání).
Za zmínku stojí to, že samotné Windows nevyhodnocují druh elektronického podpisu, a tudíž se nestarají o to, zda se podpis opírá o kvalifikovaný certifikát, nebo o takový, který kvalifikovaný není. Vlastně ani neznají koncept kvalifikovaných certifikátů a podpisů, tak jak s nimi pracuje nařízení eIDAS. Chtějí vědět jen ANO/NE – zda certifikátu mohou, či nemohou důvěřovat. Z pohledu naší právní úpravy tak „vnímají“ jen zaručené elektronické podpisy a už nezkoumají, zda nejde současně o uznávaný, případně o kvalifikovaný elektronický podpis.
Operační systém Windows proto až tolik nezajímá, zda podpisový certifikát vydala nová kvalifikovaná, či nová komerční dceřiná autorita. Potřebuje vědět, že to byla „některá z dceřiných autorit“ nové kořenové autority a že této kořenové autoritě (i tím pádem i všem jejích dcerám) a jím vydávaným certifikátům může důvěřovat.
Jinými slovy: na seznam Microsoftu (resp. do programu Microsoft Trusted Root Program) by měl být zařazen kořenový certifikát nové certifikační autority. Tedy certifikát s CN = „I.CA Root CA/ECC 12/2016“. Nikoli certifikáty dceřiných autorit. Ostatně, proto je také v názvu celého programu/seznamu společnosti Microsoft „Trusted Root“, doslova „důvěryhodný kořen“.
Jenže zařazení nového certifikátu do takovéhoto programu (seznamu) není úplně jednoduché. Společnost I.CA mi k tomu sdělila toto:
V trusted root programu Microsoftu zatím kořenový certifikát pro ECC (I.CA Root CA/ECC 12/2016) nemáme. Před jeho přidáním bude nejprve nutné provést audit nové služby (pro ECC používáme samostatné certifikační politiky).
K tomu jsme zatím nepřistoupili, protože aktuálně předpokládáme zájem o nové certifikáty pouze v jednotkách kusů. Audit pro ECC plánujeme spojit s dalším ročním auditem, který bude v květnu 2020.
V případě většího zájmu samozřejmě provedeme audit dříve.
Unijní seznam důvěryhodných seznamů (LOTL)
V případě programů Adobe Acrobat a Acrobat Reader je také možné nastavit důvěryhodnost konkrétním certifikátům „ručně“ (opět vhodná jen pro dostatečně znalé uživatele, s důsledky, které si ještě rozebereme). Stejně tak má společnost Adobe vlastní seznam důvěryhodných (hlavně kořenových) certifikátů: Adobe Approved Trusted List, zkratkou AATL.
Odlišností je ale to, že programy Acrobat a Acrobat Reader (na rozdíl od operačního systému Windows jako takového) znají unijní nařízení eIDAS a zajímají se nejenom o celkovou důvěryhodnost certifikátu, ale také o druh certifikátu, o který se nějaký podpis (či pečeť) opírá. V závislosti na tom pak tyto programy dokáží poznat, kdy jde o kvalifikovaný elektronický podpis (ve smyslu nařízení) a kdy o jiný druh elektronického podpisu.
Jenže: aby Acrobat či Reader – stejně jako kterýkoli jiný program, který chce fungovat obdobně – dokázal spolehlivě určit, že podpisový certifikát je kvalifikovaný, potřebuje další informace z dostatečně spolehlivého zdroje.
Dnes, díky unijnímu nařízení eIDAS (a jeho článku 22) je takovýmto zdrojem tzv. seznam důvěryhodných seznamů (List of Trusted Lists, zkratkou LOTL). Ten zastřešuje národní seznamy, ve kterých jednotlivé členské země zveřejňují informace o „svých“ kvalifikovaných poskytovatelích a jimi poskytovaných kvalifikovaných službách. Připomeňme si, že díky nařízení eIDAS mají takovéto seznamy konstitutivní, a nikoli jen deklarativní charakter: služba či poskytovatel se stávají kvalifikovanými tím, že jsou jako takoví zveřejněni na seznamu.
Zajímavou odlišností (oproti seznamu Microsoftu) je ale to, jaké certifikáty se na seznam LOTL zařazují. Také to musí být certifikát autority (nikoli certifikát podepisujícího se uživatele). Jenže: zatímco na seznam společnosti Microsoft se umisťují kořenové certifikáty příslušných autorit, na unijní seznam LOTL se umisťují certifikáty dceřiných autorit, které poskytují kvalifikované služby (konkrétně: vydávají kvalifikované certifikáty).
Připomeňme si a zdůrazněme, že unijní seznam LOTL se týká pouze kvalifikovaných poskytovatelů a jejich kvalifikovaných služeb. Ovšem kvalifikovaní poskytovatelé služeb, kteří fungují jako certifikační autority (tj. vydávají certifikáty), snad nikdy nevydávají pouze kvalifikované certifikáty, protože to by se asi neuživili. Nehledě na to, že kvalifikované certifikáty jsou určeny pouze pro podepisování (v právním slova smyslu) a nemají se (resp. přímo nesmí, kvůli pravidlům v rámci certifikačních politik) používat pro jiné účely, jako například pro přihlašování, šifrování atd.
Certifikační autority proto obvykle vydávají celou širokou škálu certifikátů, zahrnující jak certifikáty kvalifikované, tak i ty bez kvalifikovaného statutu (obecně označované jako komerční). S tím pak souvisí i to, že k vydávání různých druhů certifikátů používají samostatné certifikační autority (v technickém, nikoli „podnikatelském“ slova smyslu), specializované právě na příslušný druh certifikátu. Pokud jde o hierarchickou strukturu autorit, která dnes převažuje, jde o různé dceřiné autority, zřízené jednou kořenovou autoritou.
Například I.CA má podle této „Informace pro uživatele“ (kap. 3.1.) dnes celkem 6 dceřiných autorit pro vydávání „klasických“ certifikátů, zastřešených jednou „klasickou“ kořenovou autoritou (s CN = I.CA Root CA/RSA), a dvě (výše zmiňované) dceřiné autority pro vydávání nových „eliptických“ certifikátů (zastřešené novou „eliptickou“ kořenovou autoritou s CN= I.CA Root CA/ECC 12/2016).
Na národní důvěryhodné seznamy (a tím i na unijní seznam LOTL) se při takovéto hierarchické struktuře autorit umisťují certifikáty těch dceřiných autorit, které vydávají kvalifikované certifikáty. Nikoli certifikáty jejich kořenových autorit.
V daném případě nových „eliptických“ certifikátů od I.CA jde tedy o to, zda na unijním seznamu LOTL je, či není uveden certifikát nové „eliptické“ dceřiné autority (tj. s CN= I.CA Qualified 2 CA/ECC 06/2019). Protože právě to rozhoduje o výsledku ověření prostřednictvím nástrojů a služeb, které s unijním seznamem LOTL pracují a řídí se jeho obsahem. Mimochodem, konkrétně programy Adobe Acrobat a Acrobat Reader to dělají již od října 2015.
Na unijním seznamu LOTL nový certifikát již je
Jak si skrze tento prohlížeč unijního seznamu LOTL můžeme snadno ukázat, certifikát nové (kvalifikované) dceřiné autority, používaný pro vydávání koncových certifikátů využívajících kryptografii eliptických křivek, byl na příslušný národní seznam zařazen 12. července 2019, a ihned se promítl do zastřešujícího unijního seznamu LOTL.
Díky tomu mohly elektronické podpisy, založené na nových „eliptických“ kvalifikovaných certifikátech, správně ověřovat kvalifikované služby pro ověřování platnosti elektronických podpisů (jako je I.CA QVerify či SecuSign) – jak jsme si ukazovali v prvním dílu tohoto malého seriálu.
Jenže jak jsme si také v onom prvním dílu ukazovali, Adobe Reader DC ještě takovýto podpis ověřit neuměl – a to právě proto, že neznal jeho vydavatele, ačkoli se seznamem LOTL jinak řádně pracuje. Očividně na něm tedy ještě nedokázal najít certifikát nové „eliptické“ autority. Připomeňme si to na následujícím obrázku.
Nicméně, jak už jsem naznačoval v úvodu tohoto článku, od sepsání a vydání prvního dílu se situace změnila, a nejpozději od čtvrtka (22. 8. 2019) už Adobe Reader DC umí stejný podpis na testovacím dokumentu správně ověřit. Kdy přesně ke změně došlo (ani čí zásluhou se tak stalo), nevím – ale hlavní je, že došlo k nápravě.
Adobe EUTL v. LOTL
Jak je ale možné, že kvalifikované služby díky seznamu LOTL uspěly, zatímco program Adobe Acrobat Reader to původně ještě nedokázal?
Odpověď je zřejmě nutné hledat ve skutečnosti, že Adobe Acrobat a Acrobat Reader nepracují přímo se seznamem LOTL, ale s určitou jeho „podmnožinou“, kterou si vytváří a vede společnost Adobe, pod označením Adobe EUTL (od: EU Trusted List).
Všimněme si toho na předchozím obrázku, který ukazuje výsledek – nyní již správného – ověření kvalifikovaného „eliptického“ elektronického podpisu, konkrétně pokud jde o čerpání důvěry: není zde zmiňován seznam LOTL, ale seznam EUTL (plným jménem Adobe EUTL), viz červený rámeček.
Důvodem celého popisovaného problému pak zřejmě bylo nějaké „zadrhnutí“ synchronizace mezi oběma seznamy: nový „eliptický“ certifikát kvalifikované dceřiné autority I.CA již byl na unijním seznamu LOTL, ale ještě nebyl na seznamu Adobe EUTL.
O důvodech toho, proč Adobe pracuje s vlastním seznamem EUTL coby „podmnožinou“ unijního seznamu LOTL, a ne přímo s unijním seznamem, mohu jen spekulovat. Předpokládám ale, že to souvisí i s tím, že na seznamu LOTL jsou všechny kvalifikované služby podle nařízení eIDAS a jejich poskytovatelé, zatímco pro potřeby ověřování elektronických podpisů jsou relevantní jen ty z nich, které se týkají vydávání certifikátů.
Další důvody pak mohou být technické, resp. provozní: jednotlivé instance programů Acrobat a Acrobat Reader si musí příslušný seznam odněkud stahovat a společnost Adobe určitě chce mít příslušné servery pod svou kontrolou.
Mimochodem, aktualizace seznamu EUTL mezi jednotlivými instancemi Readeru a servery Adobe podle mých zkušeností nefunguje úplně automaticky: pokud by vám i nyní nešel „eliptický“ podpis na testovacím dokumentu ověřit, vynuťte si potřebnou aktualizaci ručně, podle následujícího obrázku.
EUTL a uznávané elektronické podpisy
Když už jsme narazili na seznam Adobe EUTL, využijme toho a řekněme si ještě o jedné věci, velmi důležité pro běžnou praxi. Zejména pak pro práci s naší národní specialitou, kterou jsou uznávané elektronické podpisy.
Připomeňme si, že pojem „uznávaný elektronický podpis“ je díky § 6 odst. 2 zákona č. 297/2016 Sb. legislativní zkratkou pro dva různé druhy elektronických podpisů:
- kvalifikovaný elektronický podpis, a
- zaručený elektronický podpis, založený na kvalifikovaném certifikátu
Faktický rozdíl mezi nimi je pak ten, že kvalifikovaný elektronický podpis vyžaduje – kromě kvalifikovaného certifikátu – také umístění odpovídajícího soukromého klíče na kvalifikovaném prostředku pro vytváření elektronických podpisů (zkratkou QSCD, od Qualified Signature Creation Device).
Stejně tak si můžeme stručně připomenout, že veřejná správa se musí podepisovat formou kvalifikovaných elektronických podpisů (viz § 5), a musí tedy používat ony kvalifikované prostředky (v praxi certifikované čipové karty či USB tokeny), zatímco fyzickým a právnickým osobám (při jednání vůči veřejné správě) stačí ony zaručené elektronické podpisy, založené jen na kvalifikovaném certifikátu (viz § 6 odst. 1) a nevyžadující ony kvalifikované prostředky.
Unijní nařízení eIDAS, které tuto naši národní specialitu nezná, pracuje hlavně s kvalifikovanými elektronickými podpisy – a tak je „znají“ i programy Adobe Acrobat a Acrobat Reader. Když na ně narazí, jasně to vyznačí, a ještě to zdůrazní evropskou značkou důvěry (oním zámečkem se hvězdičkami, viz levá část následujícího obrázku v zeleném rámečku).
Jak ale rozumět tomu, když Reader sice napíše, že důvěru čerpal ze seznamu EUTL, ale současně nenapíše, že jde o kvalifikovaný elektronický podpis (jako na pravé části následujícího obrázku)?
Nabízela by se totiž možnost, že tato varianta (s „čerpáním důvěry z EUTL“, současně bez konstatování o kvalifikovaném podpisu) znamená, že jde o onu druhou variantu našeho uznávaného elektronického podpisu. Tedy o zaručený elektronický podpis, založený na kvalifikovaném certifikátu.
Bylo to logické vzhledem k tomu, že seznam EUTL (čerpající z unijního seznamu LOTL) se týká kvalifikovaných služeb a kvalifikovaných certifikátů – takže zmínka o čerpání důvěry by mohla znamenat, že je podpis založen na kvalifikovaném certifikátu. A absence zmínky o tom, že jde o kvalifikovaný podpis, by měla znamenat to, že odpovídající soukromý klíč není umístěn na kvalifikovaném prostředku (QSCD).
Bohužel tomu tak není a tato premisa neplatí. Zdůrazněme si to: i když vám Adobe Reader napíše, že důvěru čerpá ze seznamu EUTL, ještě to nemusí znamenat, že jde skutečně o uznávaný elektronický podpis (ve variantě: zaručený elektronický podpis, založený na kvalifikovaném certifikátu).
Dokládá to následující obrázek: v jeho levé části je uznávaný podpis (zaručený, založený na kvalifikovaném certifikátu), zatímco v jeho pravé části je pouze zaručený podpis (založený na takovém certifikátu, který není kvalifikovaný).
V obou případech ale Adobe Reader (v horních částech obou příkladů) uvádí, že důvěru čerpá ze seznamu EUTL. Ale teprve pohledem do detailů certifikátu, o který se podpis opírá, se dozvíme, zda skutečně jde o kvalifikovaný certifikát (vlevo), nebo o certifikát, který kvalifikovaný není (vpravo).
Jak je to ale možné?
Vysvětlení je takové, že o kvalifikovaném statutu konkrétního držitele nerozhoduje pouze to, kdo ho vydal, ale současně také to, v rámci jaké služby (podle jaké certifikační politiky) – což se promítá do nastavení příslušných příznaků v rámci položky QCStatement v certifikátu.
Pravdou je, že ve většině případů konkrétní vydavatel (obvykle dceřiná autorita) vydává vždy buď jen kvalifikované, nebo naopak nekvalifikované certifikáty. Pokud by toto skutečně platilo striktně a vždy, pak by pro určení našeho „zaručeného elektronického podpisu, založeného na kvalifikovaném certifikátu“ skutečně stačilo jen ono konstatování o čerpání důvěry ze seznamu Adobe EUTL.
Jak ale dokumentuje příklad v pravé části předchozího obrázku, některé (dceřiné) certifikační autority mohou vydávat jak kvalifikované, tak i nekvalifikované certifikáty. Zde konkrétně je to (neeliptická) kvalifikovaná dceřiná autorita I.CA (CN = I.CA Qualified 2 CA/RSA 02/2016), která kromě kvalifikovaných certifikátů vydává i (komerční) systémové certifikáty podle této certifikační politiky.
Proto je třeba (pro správné rozpoznání našich uznávaných elektronických podpisů a obdobně pro pečeti) se v programu Adobe Acrobat Reader dívat i do detailů příslušného certifikátu. Rozlišení ukazuje následující obrázek:
- vlevo je certifikát, který je kvalifikovaný, a současně je odpovídající soukromý klíč umístěn na kvalifikovaném prostředku (QSCD). Příslušný podpis je tedy kvalifikovaným elektronickým podpisem (resp. jde o uznávaný elektronický podpis ve variantě kvalifikovaného elektronického podpisu)
- uprostřed je certifikát, který je kvalifikovaný, ale odpovídající soukromý klíč není umístěn na kvalifikovaném prostředku (QSCD). Příslušný podpis je tedy pouze „českým“ uznávaným elektronickým podpisem (přesněji: uznávaným elektronickým podpisem ve variantě zaručeného elektronického podpisu, založeného na kvalifikovaném certifikátu)
- vpravo je certifikát, který není kvalifikovaný. Příslušný podpis je tedy pouze zaručeným elektronickým podpisem.
Ještě si připomeňme a upřesněme, že potřeba „rozkliknout“ detaily certifikátu se týká pouze situace, kdy Reader hlásí, že čerpá důvěru ze seznamu EUTL, a současně nehlásí, že jde o kvalifikovaný elektronický podpis. Pak je třeba jít do detailů certifikátu a zkoumat, zda jde o „český“ uznávaný podpis, nebo jen o zaručený elektronický podpis. Tedy rozlišit varianty, které jsou na obrázku uprostřed a vpravo.
Jaké důsledky mělo ruční přidání certifikátu autority?
Když už jsme u obecnějších ponaučení a rad, řekněme si alespoň stručně ještě o jednom dalším zajímavém a důležitém aspektu.
Někteří čtenáři po přečtení prvního dílu tohoto článku a po zjištění, že certifikát nové „eliptické“ dceřiné autority I.CA ještě není na seznamu EUTL, možná přistoupili k řešení vlastními silami – a tento certifikát (s CN = „I.CA Qualified 2 CA/ECC 06/2019“) si sami přidali mezi ty, které má Reader považovat za důvěryhodné.
To způsobilo, že Reader už dokázal vyhodnotit „eliptický“ podpis na testovacím dokumentu celkově jako platný. Stále ale nedokázal konstatovat, že se jedná o kvalifikovaný elektronický podpis. Ani že je založen na kvalifikovaném certifikátu. Vyhodnotil jej tedy jen jako zaručený elektronický podpis.
Ilustruje to následující obrázek, resp. jeho levá část, ukazující vyhodnocení „eliptického“ podpisu na testovacím dokumentu po ručním zařazení certifikátu dceřiné autority mezi důvěryhodné. Pro srovnání je v pravé části výsledek ověření téhož, ale již po zařazení certifikátu dceřiné autority na seznam Adobe EUTL.
Povšimněte si hlavně oné červeně zvýrazněné zmínky o čerpání důvěry z ručně importované identity (resp. certifikátu autority). Reader tím dává najevo nejenom způsob přidání certifikátu autority, ale současně i míru důvěry, kterou k takto přidanému certifikátu má: stačí na to, aby podpis vyhodnotil celkově jako platný. Ale už nestačí na to, aby důvěřoval i obsahu certifikátu.
To je důležité: jde o stejný podpis na stejném dokumentu a je založen na stejném certifikátu. Ten má ve svých příznacích (v položce QCStatements) uvedeno jak to, že se jedná o kvalifikovaný certifikát, tak i to, že jde o kvalifikovaný certifikát pro elektronický podpis – i to, že odpovídající soukromý klíč je umístěn na kvalifikovaném prostředku (QSCD).
Ovšem takovéto nastavení příznaků by si mohl v nějakém „vlastním“ certifikátu (vystaveném vlastními silami) nastavit kdokoli – a pak Readeru říci, že má takovémuto certifikátu důvěřovat (tj. „ručně“ ho importovat mezi důvěryhodné certifikáty). Měl by pak Reader věřit tomu, že jde skutečně o kvalifikovaný certifikát? A že soukromý klíč je umístěn na kvalifikovaném prostředku a celkově pak jde o kvalifikovaný elektronický podpis?
Je správné, že tomu nevěří – a k tomu, aby důvěřoval obsahu certifikátu a odvozoval z něj další závěry, potřebuje nějaké další ověření, resp. spolehlivější zdroj důvěry, než je pouhé vyjádření uživatele (skrze import mezi důvěryhodné certifikáty). V daném případě potřebuje seznam Adobe EUTL, čerpající z unijního LOTL.
Ilustruje to i následující obrázek ukazující, jak Reader hodnotí detaily stejného (mého nového „eliptického“) certifikátu: vlevo v době, kdy certifikát vydávající autority ještě nebyl na seznamu EUTL (a byl „ručně“ importován), vpravo pak již v době, kdy na seznamu EUTL byl.
Hlavní rozdíl je v celkovém hodnocení toho, zda jde o kvalifikovaný certifikát (jen v pravé části obrázku).
Zajímavé přitom je, že v levé části obrázku Reader přeci jen zmiňuje nastavení příznaku o umístění na bezpečném prostředku SSCD (Secure Signature Creation Device). To není úplně správně již jen kvůli terminologii: s termínem „bezpečný prostředek“ (SSCD) pracovala původní unijní směrnice 1999/93/ES, kterou nařízení eIDAS nahradilo (a místo o „bezpečných“ prostředcích hovoří ve stejném smyslu o „kvalifikovaných“ prostředcích. Podle mého názoru jde o chybu.
Platnost není to samé co pravost
V souvislosti s tím, co právě zaznělo, si ještě připomeňme podstatu zaručených elektronických podpisů: u těch není kladen žádný požadavek na certifikát, o který se opírají. Nemusí to tedy být kvalifikovaný certifikát, u kterého jeho vydavatel ručí za správnost obsahu. Může to být opravdu jakýkoli certifikát, včetně různých testovacích certifikátů, jejichž obsah vůbec nemusí odpovídat pravdě.
Pokud ale certifikát není kvalifikovaný, Reader nemá možnost poznat, zda jeho obsah odpovídá pravdě, či nikoli. Ani to ostatně neposuzuje – a svému uživateli pouze vypíše obsah relevantních položek tak, jak je sám uvnitř certifikátu najde. Jde například (ale ne jenom) o údaje popisující držitele. Nutně tak nechává na uživateli, aby tyto údaje posoudil on a sám se rozhodl, nakolik jim bude důvěřovat, či nikoli.
Netýká se to ani kvalifikovaných elektronických podpisů, ani těch „českých“ uznávaných – protože obě tyto varianty jsou založeny na kvalifikovaných certifikátech. U nich se tedy můžeme spoléhat na údaj o držiteli certifikátu (a tím i na identitu podepsané osoby) i na další obsah certifikátu. Ale jde o zaručené elektronické podpisy, u kterých se na identitu podepsané osoby obecně spoléhat nemůžeme.
Obvykle to ilustruji na příkladu zaručeného elektronického podpisu literární postavy Josefa Švejka, viz následující obrázek: je založen na testovacím certifikátu, který jsem si sám vyrobil a do něj napsal něco, co není pravdou (že držitelem certifikátu je Josef Švejk). Mimochodem, kvalifikovaný certifikát by literární postavě Josefa Švejka žádná autorita nevystavila již jen proto, že se nemůže osobně dostavit a prokázat dostatečným počtem platných osobních dokladů. Ale testovacích certifikátů na tuto literární postavu (či na kohokoli jiného, existujícího či neexistujícího) si mohu vyrobit, kolik jen chci.
Následně jsem programu Adobe Acrobat Reader „ručně“ sdělil, že má tomuto certifikátu důvěřovat. Pak příslušný podpis celkově vyhodnotil jako platný.
Mimochodem, i na tomto příkladu je dobře patrný rozdíl mezi (technickým) pojmem „platnost“ a (právním) pojmem „pravost“: platností elektronického podpisu se rozumí splnění určitých technických podmínek (není porušena integrita, certifikát ještě neexpiroval a nebyl revokován), zatímco „pravostí“ podpisu právo rozumí to, že jej skutečně vytvořil ten, kdo je prezentován jako podepsaná osoba.
Programy jako Adobe Reader vždy vyhodnocují platnost podpisu – což také řádně uvádí, když o podpisu konstatují, zda je, či není platný (nebo je jeho platnost neznámá). Pravost si pak musí dovodit sám uživatel podle toho, o jaký druh elektronického podpisu jde:
- pokud je podpis založen na kvalifikovaném certifikátu, lze z technické platnosti presumovat (dovozovat) právní pravost
- pokud je podpis založen na jiném než kvalifikovaném certifikátu, nelze z platnosti obecně presumovat (dovozovat) pravost – a je nutné dále zkoumat to, jak moc lze obsahu certifikátu věřit.
Proto je tak důležité, aby uživatelé (v roli spoléhajících se osob) dokázali správně rozpoznat druh elektronického podpisu a věděli, kdy mohou zobrazovaným údajů věřit. A tím i kdy z technické platnosti mohou dovozovat právní pravost.
Výše uvedený příklad se zaručeným elektronickým podpisem literární postavy Josefa Švejka je příkladem takového elektronického podpisu, u kterého z (technické) platnosti nelze dovozovat (právní) pravost. Je tedy platný, ale není pravý (nevytvořila ho ta osoba, která je uváděna jako podepsaná). Vytvořil jsem ho já, právě pro takovéto demonstrační účely.
V třetím a závěrečném dílu tohoto malého letního seriálu si konečně řekneme to, čím jsme asi správně měli začít – co jsou vlastně zač ony eliptické křivky a jaké mají výhody.
