Hlavní navigace

Kvalifikovaný certifikát na dvě věci II.

Jiří Peterka

I.CA v pondělí vydala novou verzi své certifikační politiky, která by již měla řešit problém s nepoužitelností kvalifikovaných certifikátů v produktech firmy Microsoft. I původní řešení se však opíralo o platné standardy. Byla tedy chyba na straně Microsoftu? Nebo je problém v nejednoznačnosti standardů?

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 jeho funkčnost 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 jejich použitelnosti (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í kvalifikovaného 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 společnosti Microsoft. Rozesílala mail následujícího 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 firmy Microsoft? 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
  • a ú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čnosti obsahuje certifikát i některé další povinné údaje (například do kdy je platný atd.), a také data, která již obecně povinná nejsou a mají charakter rozšíření. Jedním z takovýchto údajů je položka 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 nebo naopak nemusí být nastaven). Kromě toho k této položce přísluší i příznak „critical“, který upravuje její význam.

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

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

Standard X.509, z ně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 explicitně nastavenu možnost využ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 proto v zásadě o jakési „doporučení vhodného použití“, o ně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“, jímž lze položku Key Usage opatřit, pak má obecně za cíl zakázat jakákoli jiná použití, než která jsou zde 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á specifikovat úč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á konfigurace 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 (jež 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 uvádí, ž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. Norma 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á této normě.

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 této normě vyhovovat. 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.

Anketa

Chystáte se pořídit si kvalifikovaný certifikát?

Našli jste v článku chybu?

29. 4. 2002 14:25

David Rohleder (neregistrovaný)
Vy jste opravdu nejaky chytry. Co kdybych k vam prisel a usekl vam ruku, kterou podepisu nejakou smlouvu? Bude vlastnorucne podepsana a tedy platna.

To je asi tak uroven vasi argumentace.

29. 4. 2002 9:07

Petr Ptáček (neregistrovaný)
Ale pánové, vy pořád nechápete že neexistuje způsob jak by někdo mohl DOKÁZAT že někdo nesplnil svůj díl odpovědnosti za svůj klíč.

U elektronického podpisu prostě vždy chybí onen akt použití vlastní ruky k vlastnoručnímu podpisu. Chybí též jakákoliv možnost ověřit zda k podpisu klíčem vůbec skutečně došlo. A ono je, popravdě, jedno zda vědomě či nevědome.

To že na něčem je jakýsi shluk binárních dat nazkládá právní podklad čehokoliv.

Bude stačit první soudní spor na toto…



Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

DigiZone.cz: Perspektivy TV v roce 1939 podle časopisu Life

Perspektivy TV v roce 1939 podle časopisu Life

Vitalia.cz: Vychytané vály a válečky na vánoční cukroví

Vychytané vály a válečky na vánoční cukroví

Měšec.cz: Vklad na cizí účet je draze zpoplatněn (přehled)

Vklad na cizí účet je draze zpoplatněn (přehled)

Root.cz: Mirai má nový cíl 5 milionů routerů

Mirai má nový cíl 5 milionů routerů

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Podnikatel.cz: Daňové úlevy s EET nestačí. Budou zdražovat

Daňové úlevy s EET nestačí. Budou zdražovat

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Root.cz: Kamery Sony se dají ovládnout na dálku

Kamery Sony se dají ovládnout na dálku

Root.cz: Telegram spustil anonymní blog Telegraph

Telegram spustil anonymní blog Telegraph

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Vitalia.cz: Analýza letáků: Na co lákají do prodejen?

Analýza letáků: Na co lákají do prodejen?

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Vitalia.cz: To nejhorší při horečce u dětí: Febrilní křeče

To nejhorší při horečce u dětí: Febrilní křeče

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

Vitalia.cz: Když přijdete o oko, přijdete na rok o řidičák

Když přijdete o oko, přijdete na rok o řidičák