Kvalifikované certifikáty na dvě věci - II.

V pondělí jsem zde na Lupě psal o kvalifikovaných certifikátech od I.CA, které nejdou použít pro podepisování zpráv v poštovních klientech firmy Microsoft. V závěru jsem uvedl, že věc není tak jednoznačná, jak by se na první pohled mohlo zdát, a že i I.CA má pro původně zvolené řešení oporu ve standardech (byť se zřejmě nenamáhala ověřit si funkčnost svých certifikátů v nejpoužívanějších programech). Slíbil jsem to rozvést v dalším článku.

Než se ale pustíme do standardů, zmíním se o posledním vývoji. Již v pondělí, kdy první článek vyšel, vydala I.CA novou verzi své certifikační politiky pro kvalifikované certifikáty. V ní sice ponechala původní dikci odstavce 1.4.5 o použitelnosti certifikátů (jen pro ověřování a neodmítnutelnost), ale již připustila volitelné nastavení rozšiřující položky Key Usage i na hodnoty digitalSignature, keyEncipherment a dataEncipherment. To snad již bude celý problém řešit, byť jde jen o volitelné položky a zájemci o vystavení certifikátu si tak zřejmě budou muset vybírat mezi několika variantami s různou použitelností.

Je na vině Microsoft?

Jak jsem se již zmiňoval v pondělním článku, I.CA signalizovala že svým klientům nabídne vydání "opraveného" certifikátu, který bude použitelný i v produktech Microsoftu. Rozesílala mail následující obsahu:

Vážený kliente,
jsme nuceni konstatovat, že Vámi definovaný stav je způsoben chybou v e-mail aplikaci společnosti Microsoft v rámci použití "kritických položek" certifikátů, které jsou v rozporu s mezinárodními standardy a doporučeními pro kvalifikované certifikáty. Tato skutečnost je nám známa, avšak vzhledem k tomu, že není úkolem poskytovatelů certifikačních služeb zajištění kompatibility s aplikacemi, které tuto technologii používají, tento stav bohužel nastal.
Přesto bychom Vám rádi pomohli s řešením Vašeho problému. Jediný způsob, jak Vaši situaci vyřešit, je vydání nového certifikátu, který bude příslušně upraven. V tomto směru Vám nabízíme dvě možnosti (… vydání tzv. následného certifikátu či zcela nového certifikátu, obojí zdarma ….)

Kdo tedy celý problém způsobil? Jsou na vině produkty Microsoftu? Pojďme se raději seznámit s tím, co říkají příslušné standardy a doporučení.

Rozšiřující položky certifikátů

Jak jsem již popisoval v pondělním článku, certifikát je v zásadě spojení dvou hlavních údajů:

• veřejného klíče
• údajů o identitě vlastníka veřejného klíče

přičemž toto jejich spojení je "fixováno" a stvrzeno elektronickým podpisem certifikační autority, která certifikát vydala (zde I.CA).

Ve skutečnost obsahuje certifikát i některé další povinné údaje (například do kdy je certifikát platný atd.), a také údaje které již povinné obecně nejsou a mají charakter rozšíření. Jedním z takovýchto údajů je položka (údaj) Key Usage, která může nabývat jako své hodnoty libovolné kombinace z hodnot

• digitalSignature (0),
• nonRepudiation (1),
• keyEncipherment (2),
• dataEncipherment (3),
• keyAgreement (4),
• keyCertSign (5),
• cRLSign (6),
• encipherOnly (7),
• decipherOnly (8)

(jde v zásadě o bitový řetězec, a každý bit s výše uvedeným významem může být nastaven nebo naopak nemusí být nastaven). Kromě toho k této položce přísluší i příznak "critical", který upravuje význam celé položky.

Problém je ale s tím, jak správně nastavovat tuto položku a její "kritický příznak", a následně jak takovéto nastavení interpretovat. Právě zde je bohužel prostor pro nejednoznačnosti, které způsobily celý problém s nefunkčností kvalifikovaných certifikátů od I.CA v produktech Microsoftu.

Obecně se většina standardů a doporučení shoduje v tom, že pokud rozšiřující položka Key Usage vůbec není v certifikátu obsažena, nejsou na použití certifikátu jako takového kladena žádná konkrétní omezení.

Standard X.509, ze kterého dnes používané certifikáty vychází, předpokládá použití položky Key Usage pro výběr v situaci, kdy je k dispozici více certifikátů. Přednost by pak měl mít ten, který má v příslušném bitu položky Key Usage explicitně nastavenu možnost použití pro požadovaný účel (například oproti certifikátu, který rozšiřující položku Key Usage vůbec nemá a je tedy v principu použitelný také). Jde tedy v zásadě o jakési "doporučení vhodného použití", o kterém ale odborné prameny (například známá X.509 Style Guide) uvádí že mnohdy nebývá vůbec respektováno.

Příznak "critical", kterým lze položku Key usage opatřit, pak má obecně za cíl zakázat jakákoli jiná použití, než která jsou v položce Key Usage explicitně povolena.

Co říká RFC 2459?

Internetový standard RFC 2459 (z ledna 1999) upřesňuje doporučení X.509 (jako tzv. profil) pro potřeby použití v Internetu. Týká se obecně všech certifikátů, nikoli jen kvalifikovaných.

Vychází z obecné představy X.509 naznačené výše a o položce Key Usage říká, že má definovat účel použití klíče, obsaženého v certifikátu:

• bit "digitalSignature" definuje tak, že "má být nastaven, má-li být příslušný veřejný klíč použit v rámci mechanismu digitálního podpisu k zajištění zabezpečovacích služeb jiných než je neodmítnutelnost (bit 1), podpis certifikátů (bit 5) či podpis revokačních informací (bit 6). Mechanismy digitálního podpisu jsou obvykle používány pro autentizaci a zajištění integrity".
• bit "nonRepudiation" má být nastaven, pokud má být příslušný veřejný klíč "používán k ověřování digitálních podpisů používaných pro zajištění neodmítnutelnosti, chránící proti tomu aby podepisující subjekt neprávem popřel některou svou aktivitu …."

Z definice těchto dvou bitů mi vychází potřeba jejich současného nastavení, protože elektronický podpis by měl obecně zajišťovat jak autentizaci a integritu (bit DigitalSignature), tak i nepopiratelnost (bit nonRepudiation). Současné nastavení obou bitů připouští i příklad explicitně citovaný přímo v tomto standardu:

"Například, má-li být klíč použit pouze pro podepisování, měly by být nastaveny bity digitalSignature a/nebo nonRepudiation".

Povšimněte si dobře vazby "a/nebo", která je na standard dosti neobvyklá - připouští i nastavení jednoho z obou bitů, čímž vytváří značný prostor pro neurčitost a různé výklady.

Microsoft ve svých dokumentech (např. zde ) deklaruje že pro podepisování koncovými uživateli očekává nastavený bit Digital Signature.

Co říká RFC 3039?

Vedle RFC 2459 existuje také RFC 3039 (z ledna 2001), které na předchozí RFC navazuje a zabývá se kvalifikovanými certifikáty (které definuje tak, že mají nějaký specifický statut v rámci platných zákonů).

Tento standard již celkem jednoznačně říká, že rozšiřující položka Key Usage má být použita. Dále říká, že pokud je nastaven bit nonRepudiation, neměl by být kombinován s žádným jiným nastavením dané položky (tj. pokud je nastaven, musí být nastaven jako jediný bit). Celá položka pak může být prohlášena za kritickou. Standard dále říká, že současné nastavení bitu NonRepudiation a jiných bitů může mít bezpečnostní důsledky a standard před touto možností varuje (aniž ale upřesňuje, o jaká rizika jde).

Původní řešení, které zvolila I.CA (když nastavila právě a pouze bit nonRepudiation) tedy očividně odpovídá tomuto standardu.

Povšimněte si ale dobře, že ani tento standard nevyžaduje (kategoricky), že má být nastaven právě bit nonRepudiation (neodmítnutelnost). Říká pouze to, že je-li tento bit nastaven, pak už by neměl být nastaven žádný další bit v položce Key Usage. To připouští i další možná řešení, která také budou vyhovovat tomuto standardu. Třeba nastavení bitu digitalSignature (bez současného nastavení bitu nonRepudiation).

A proč vlastně tento standard (RFC 3039) trvá na tom, že neodmítnutelnost (nonRepudiation) nesmí být kombinována s jinými bity, a tím i s jinými účely, resp. úkoly? Jak jsem již naznačoval výše, elektronický podpis by kromě neodmítnutelnosti měl zajistit i identifikaci a autentizaci, a také integritu (neporušenost dat, resp. možnost rozpoznat jakoukoli změnu od podepsání). Náš zákon o elektronickém podpisu integritu explicitně požaduje v paragrafu 4, ale tato integrita (aspoň podle mého názoru) spadá "do kompetence" bitu digitalSignature (viz jeho definice v RFC 2459), a nikoli do působnosti bitu nonRepudiation.