Kvalifikovaný certifikát na dvě věci

Pořídil jsem si kvalifikovaný certifikát od nedávno akreditované I.CA. Nainstalovat šel bez problémů, ale pak se projevila jedna jeho specifická vlastnost: nejde použít k elektronickému podepisování. Dokonce k tomu ani není určen. Jak je to možné? Kde se stala chyba?

Počátkem dubna jsem zde na Lupě psal o tom, jak první poskytovatel certifikačních služeb (konkrétně I.CA, coby dceřinný podnik PVT, a.s.) úspěšně prošel akreditací a začal vydávat tzv. kvalifikované certifikáty. Pro úplnost připomínám, že právě takovéto kvalifikované certifikáty, od poskytovatele který je akreditován, jsou nutné v situaci, kdy občan chce komunikovat elektronickou cestou s orgány veřejné moci.

Záhy poté jsem si sám zažádal o vystavení takovéhoto kvalifikovaného certifikátu, a na druhý pokus jsem uspěl a certifikát mi byl vystaven (k příčinám prvního neúspěchu se vrátím v dalších článcích). Ihned poté jsem si certifikát úspěšně nainstaloval - na stejný počítač kde jsem generoval žádost o jeho vystavení - a všechno se zdálo být tak jak jsem očekával. K tomu, abych mohl poslat první emailovou zprávu podepsanou s využitím tohoto certifikátu, zbýval jen jeden jediný krok: v poštovním programu (v mém případě MS Outlook XP) zvolit příslušný certifikát a přiřadit jej ke konkrétnímu poštovnímu účtu. Právě zde jsem ale narazil na celý problém: ani MS Outlook, ani následně zkoušený Outlook Express, nebyl ochoten použít právě nainstalovaný certifikát (ve standardním uložišti). Oba programy se svorně tvářily, jako kdyby můj kvalifikovaný certifikát vůbec neviděly. Když jsem se dostal do menu, kde jsem měl certifikát vybrat, zmíněný kvalifikovaný certifikát tam nebyl uveden. Naopak jiné programy od Microsoftu, konkrétně MS Word a PowerPoint (oba v provedení XP) kvalifikovaný certifikát "viděly" a byly schopné jej použít pro podepsání dokumentu, resp. prezentace.

Pro jistotu, ve snaze odhalit kde dělám chybu, jsem si nechal vystavit od I.CA testovací certifikát. S ním proběhlo vše tak jak mělo a oba programy (Outlook i Outlook Express) s ním pracovaly tak, jak jsem očekával.

O svůj problém jsem se podělil i s několika kolegy, kteří si také nechali vystavit kvalifikovaný certifikát u I.CA. Zjistil jsem, že všichni dopadli přesně stejně: že certifikát jde řádně a bez problémů nainstalovat, ale v emailových klientech od Microsoftu nejde použít.

Začal jsem tedy hledat příčinu.

Kde je chyba?

Po letmém srovnání obsahu testovacího certifikátu (který fungoval tak jak měl) a certifikátu kvalifikovaného, jsem zjistil že se liší mj. v nastavení položky příznačně nazvané "Key Usage" (doslova: použití klíče). Zatímco testovací certifikát zde měl uvedeno:

Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment

pak kvalifikovaný certifikát měl ve stejné položce uvedeno pouze

Non-Repudiation

a navíc byla tato rozšiřující položka Key Usage prohlášena za tzv. kritickou. Jak jsem si následně zjistil, I.CA vydává ještě tzv. komerční certifikáty a ty mají položku Key Usage nastavenu stejně jako testovací certifikát.

Hned mne napadlo, že rozdíl v nastavení položky Key Usage by mohl vysvětlovat to, čeho jsem byl svědkem: že emailový klient od Microsoftu byl ochoten pracovat (pro potřeby podepisování odcházejících zpráv) s testovacím certifikátem, ale nebyl ochoten pracovat s certifikátem kvalifikovaným (který má uvedenou použitelnost pouze pro non-repudiation, čili pro tzv. neodmítnutelnost, ale nikoli pro vytváření elektronických podpisů, případně pro šifrování).

Co mi ale nebylo jasné je to, jak mohla I.CA vydat takový certifikát, který není určen pro elektronické podepisování. Navíc po čtyřměsíčním procesu akreditace ze strany UOOU ….

Co říká certifikační politika?

Ústředním (ale nikoli jediným) dokumentem, který určuje jak poskytovatel certifikačních služeb funguje, je jeho certifikační politika. To je veřejný dokument, a vřele doporučuji každému zájemci o vydání kvalifikovaného certifikátu aby si jej přečetl dopředu, ještě dříve než si půjde nechat vystavit svůj první certifikát (pozor jen na to, že jde o certifikační politiku vztahující se ke kvalifikovaným certifikátům, obecně ke každému druhu certifikátů může být jiná).

V této certifikační politice se v relevantním odstavci říká:

1.4.5. Použitelnost

Párová data související s osobními certifikáty, které vydává I.CA klientům, mohou být používány v aplikacích pro následující účely:

pro ověřování elektronických podpisů

pro bezpečné ověřování elektronických podpisů

zajištění neodmítnutelnosti odpovědnosti

K jiným než výše uvedeným aplikacím není osobní kvalifikovaný certifikát určen.

Pro srovnání jsem si našel srovnatelnou pasáž certifikační politiky týkající se komerčních certifikátů. Zde se praví:

Certifikáty, které vydává I.CA klientům, mohou být používány v aplikacích pro následující účely:

Zajištění integrity

Zajištění neodmítnutelnosti odpovědnosti

Zajištění důvěrnosti dat

Ustanovení sdíleného tajemství (klíče) v rámci protokolu pro bezpečnou výměnu dat

Přímé šifrování a dešifrování dat

Přímé podepisování dat

Zajímavý rozdíl je také v samotné definici produktu (certifikátu), který I.CA vydává. V případě komerčních certifikátů je příslušná certifikační politika definuje takto:

Standardní osobní certifikáty - certifikáty určené jako osobní pro použití v oblasti elektronické pošty, vytváření podpisu a/nebo šifrování, pro klientskou autentizaci v rámci zabezpečených protokolů.

Ovšem certifikační politika příslušející ke kvalifikovaným certifikátům definuje produkt (certifikát) takto:

Osobní kvalifikované certifikáty - kvalifikované certifikáty určené jako osobní pro ověřování podpisů (např. v rámci elektronické pošty).

Kde je problém?

Až sem tedy vše do sebe logicky zapadá: komerční certifikáty (i certifikáty testovací) jsou podle své certifikační politiky určeny nejenom k zajištění neodmítnutelnosti (non-repudiation), ale také ke tvorbě samotných elektronických podpisů, k šifrování atd. Naopak kvalifikované certifikáty jsou určeny jen k ověřování podpisů a k zajištění neodmítnutelnosti. No a chování emailových klientů tomu odpovídá.

Z formálního hlediska se tedy kolem kvalifikovaných certifikátů zdá být vše v pořádku. Klient, který si nechal vystavit kvalifikovaný certifikát, podepisuje že souhlasí s příslušnou certifikační politikou, podle které je mu certifikát vystaven - a v té se skutečně o možnosti využití pro samotné podepisování nic neříká. Takže zákazník dostal přesně to, co si objednal a svým podpisem stvrdil, že právě to chce.

Napadá mne analogie s prodejem aut: prodejce nabízí auto, které je podle kupní smlouvy určeno ke stání a je garantována jeho schopnost zastavit. S možností rozjet se a s jízdou se ale nepočítá.

První reakce I.CA

Když jsem se na celý problém dotazoval přímo v I.CA, první reakce která mi přišla se skutečně nesla v duchu toho, že žádný problém s certifikační politikou vlastně neexistuje:

Dobrý den,
certifikační politika je plně v pořádku, neboť certifikát je opravdu určen pouze k účelům, které tam jsou uvedeny.
Pro digitální podpis dat je třeba použít soukromého klíče (dat pro tvorbu elektronického podpisu) nikoliv certifikátu.

S pozdravem ….

Pro lepší pochopení podstaty věci si dovolím velmi stručně připomenout, že elektronický podpis skutečně vzniká s použitím soukromého klíče, zatímco v certifikátu je obsažen pouze odpovídající veřejný klíč, a je zde také uvedena identita osoby, které dvojice párových dat (tj. dvojice soukromý a veřejný klíč) patří.

Když někdo chce používat elektronický podpis, musí si nejprve nechat vystavit svůj certifikát. Přitom postupuje v principu takto:

vygeneruje si svá párová data, tj. dvojici soukromý klíč a veřejný klíč (v mém případě skrze aplikaci poskytnutou od I.CA a zpřístupněnou přes její WWW stránky)
soukromý klíč si uživatel ponechá (v mém případě přímo na tom počítači, kde jsem generoval svá párová data)
s veřejným klíčem jde uživatel za certifikační autoritou (jeho žádost je podepsána soukromým klíčem, aby bylo jisté že uživatel má i příslušný soukromý klíč)
certifikační autorita si ověří identitu žadatele a vystaví mu certifikát. Do něj vloží žadatelův soukromý klíč, údaje o jeho identitě plus další údaje, a vše podepíše svým elektronickým podpisem. V případě kvalifikovaného certifikátu od I.CA obsahuje tento certifikát položku Key Usage nastavenou (pouze) na Non-repudiation.
uživatel jde zpět na místo kde zůstal bezpečně uložen jeho soukromý klíč a zde si instaluje svůj nový certifikát (obvykle do standardního uložiště certifikátů). Příslušná párová data (samostatně uložený soukromý klíč a v certifikátu obsažený veřejný klíč) stále logicky "patří k sobě".

Když potom uživatel chce fakticky vytvářet elektronické podpisy, využije k tomu schopností příslušných aplikací (v mém případě MS Outlook, resp. Outlook Express). Jde -li o vytvoření podpisu (podepsání), aplikace skutečně použije příslušný soukromý klíč a nikoli klíč veřejný, obsažený v certifikátu (ten by využila až na straně příjemce k ověření podpisu). Přitom se ale tato aplikace zajímá o to, zda soukromý klíč lze nebo naopak nelze použít pro daný účel. Ale kde takovéto informace najde? Nikoli přímo u soukromého klíče - najde jej "přiložené" k veřejnému klíči, který je s daným soukromým klíčem "do páru". Tedy v příslušném certifikátu, konkrétně v nastavení jeho položky Key Usage.

Je tedy pravda, že certifikát jako takový sám k vytváření elektronického podpisu neslouží (a ani sloužit nemůže, když je veřejný, viz dále) . Věta "Pro digitální podpis dat je třeba použít soukromého klíče (dat pro tvorbu elektronického podpisu) nikoliv certifikátu" je tedy v zásadě pravdivá. Zbývá k ní ale dodat, že faktická použitelnost soukromého klíče je dána tím, co je uvedeno v certifikátu.

Znovu: kde je problém?

Ještě pro další upřesnění a dokreslení podstaty věci: certifikáty, které certifikační autority vydávají, jsou obecně veřejné a jsou také skutečně zveřejňovány (všechny dosud vydané kvalifikované certifikáty od I.CA najdete zde). Důvodem je to, aby si kdokoli v roli příjemce podepsané zprávy či dokumentu mohl ověřit elektronický podpis odesilatele resp. autora. K tomu plně postačuje veřejný klíč, obsažený přímo v certifikátu - a certifikační autorita svým podpisem pod tímto certifikátem stvrzuje, že příslušný veřejný klíč skutečně patří té osobě, která je v certifikátu uvedena jako vlastník veřejného klíče.

Z pohledu příjemce podepsaných zpráv či dokumentů je tedy správný princip "tento certifikát slouží pouze potřebám ověřování elektronického podpisu a zajištění neodmítnutelnosti". Tento princip také přesně odpovídá tomu, co říká příslušná certifikační politika I.CA, týkající se kvalifikovaných certifikátů.

Dokonce, pokud si člověk vezme k ruce platný zákon o el. podpisu (č.227/2000 Sb.):, najde zde v §3, odst. 2:

(2) Použití zaručeného elektronického podpisu založeného na použití kvalifikovaného certifikátu a vytvořeného pomocí prostředku pro bezpečné vytváření podpisu umožňuje ověřit, že datovou zprávu podepsala osoba uvedená na tomto kvalifikovaném certifikátu.

což opět odpovídá zmiňovanému principu (že certifikát slouží pro ověřování podpisu na straně příjemce). V mé následné korespondenci s I.CA se tato pasáž zákona také skutečně objevila jako argument pro řešení, které I.CA zvolila.

To si ale v I.CA nikdo neuvědomil, že kromě příjemců elektronicky podepsaných zpráv či nejrůznějších dokumentů musí existovat také ti, kteří je podepisují? Tedy lidé, kterým jsou certifikáty vystavovány a kteří vlastní k ním příslušející soukromé klíče? Proč na ně nepamatuje certifikační politika kvalifikovaných certifikátů, s možností vytvářet elektronické podpisy? Odpověď by mohla být přesně taková, jakou jsem dostal z I.CA - že pro tvorbu samotného podpisu se používá soukromý klíč a ne certifikát.

To by ale mohla být pravda pouze tehdy, pokud by nastavení certifikátu (konkrétně položky Key Usage) nemělo žádný omezující vliv na možnost použití soukromého klíče. Ale to podle relevantních standardů má, a dokonce to říká i sama certifikační politika I.CA, když ve svém již jednou citovaném odstavci 1.4.5. (Použitelnost) říká:

Párová data související s osobními certifikáty, které vydává I.CA klientům, mohou být používány v aplikacích pro následující účely:

pro ověřování elektronických podpisů

pro bezpečné ověřování elektronických podpisů

zajištění neodmítnutelnosti odpovědnosti

Všimněte si dobře, že se zde nehovoří o certifikátu, ale o "párových datech", tedy o dvojici soukromý a veřejný klíč. Takže když můj emailový klient nechtěl použít příslušný soukromý klíč pro vytvoření elektronického podpisu, vlastně tím jen důsledně naplnil dikci certifikační politiky (nebo alespoň toho, jak ji interpretuji já, ve smyslu který jsem právě popsal).

Kde se stala chyba?

Opravdu ale v I.CA zapomněli na to, že elektronické podpisy se nejen ověřují, ale také vytváří? Opravdu chtěli ve své certifikační politice zakázat majitelům soukromých klíčů možnost jejich použití (a učinili tak skrze nastavení položek Key Usage)? Nebo jenom chybně interpretuji obsah příslušného odstavce (1.4.5. Použitelnost) a záměr byl jiný?

Nebo je chyba v aplikacích Microsoftu, které si špatně vykládají význam položky Key Usage v certifikátech? Právě to je nyní zřejmě hlavní argument I.CA, od které jsem dostal další vyjádření právě v tomto smyslu (s nabídkou na vystavení "opraveného certifikátu"), s upřesněním že "není úkolem poskytovatelů certifikačních služeb zajištění kompatibility s aplikacemi, které tuto technologii používají".

Abych z toho ale nedělal laciný bulvár a z lidí z I.CA úplné hlupáky: v relevantních standardech existuje možnost dvojího výkladu toho, jak má být nastavena položka Key Usage a jaký to má mít praktický význam. Jeden výklad dává za pravdu tomu, jak se chovají emailoví klienti Microsoftu, a druhý zase dává za pravdu nastavení položky Key Usage tak, jak to dělá I.CA. V odborné komunitě je přitom tento problém dobře a dlouho znám (a i přímo z I.CA mne na tyto možnosti dvojího výkladu odkázali). Podrobněji bych se tomu rád věnoval v navazujícím článku zde na Lupě.

V tomto článku jsem se snažil popsat podstatu problému a nastínit svůj pohled na něj. Mimo jiné jsem se snažil vyjádřit svůj názor, že primární chyba není ani tak technická (v nastavení položky Key Usage) jako logická, obsažená již v samotné certifikační politice, která hovoří o omezení použitelnosti párových dat (tudíž i soukromého klíče) a nikoli pouze samotného certifikátu. K nejednoznačnosti standardů i k reakcím I.CA se vrátím v pokračování tohoto článku ….