No, kdyz se do diskuse neprida nikdo jiny, je zapotrebi polemizovat sam se sebou ... ;-)
Pripoustim, ze se mi podarilo prijit (byl jsem prijden) na pripady, kdy to asi nepujde jinak nez aby privatni klic vznikal mimo ruce budouciho opravneneho vlastnika - vesmes jde o pripady, kdy je klic soucasti nejakeho hardwaroveho zarizeni a je technicky nebo ekonomicky nemozne aby kazdy budouci drzitel vlastnil potrebnou technologii pro vyrobu nebo i jen inicializaci takoveho zarizeni. Tzn. plamenna rec, kterou jsem tu drzel, ma sve opodstatneni pro softwarove generovane klice, obecne se to vsak asi opravdu dodrzet neda.
Ad 3) - osobne povazuji za spise mene pravdepodobne, ze budou certifikovana ciste "softwarova" reseni (i kdyz, mozna se mylim). Samotnou certifikaci by mel provadet spise hardwarovy black-box, ktery nikdy nevyda privatni klic, kterym se certifikuje a tak zabrani jeho moznemu zneuziti. Samozrejme, ze i ten bude nejspis vnitrne rizen nejakym softwarem, ten vsak nebude samostatnou soucasti dodavky a tak nebude mozne rict, zda je "zadarmo" nebo "nezadarmo".
Jen na okraj a pro vasi informaci podotykam, ze OpenSSL neni GNU licenci kontaminovan. Je distribuovano pod daleko volnejsi BSD-style licensi. Doufam, ze pripadni obdivovatele GNU license nehodlaji na tomto miste rozpoutat flamewar, ktera by se naprosto netykala tematu puvodniho clanku. Pojem "GNU" neni doplnkem pojmu "placeny software", jak se pravdepodobne nespravne domnivate.
"tree of trust" vs. "web of trust"
Nejen to, protoze vim, ze nad PGP se ruzne skupiny lidi pokouseji budovat jakesi hybridni "pseudoCA" (napriklad Humboldt-University, Berlin). Dalsim bolavym bodem PGP je (pokud se nemylim) vyplneni neceho, cemu se rika v PKIX "X.509v3 certificate extensions". Doufam, ze provadeci predpisy stanovi dodatecne presneji napriklad, k cemu smi byt certifikat vyuzit a co smi/nesmi obsahovat.
Revokace a cas
zakon se take pokousi osetrit revokovani certifikatu, ale nezabyva se napriklad problemem, kdy v pripade PKIX revokace muze znemoznit overeni (u zasifrovanych zprav pristup) ke zpravam odeslanym jiz pred okamzikem revokace.
Neresi take otazku, jak casto je prijemce povinen obnovovat informaci o revokovanych certifikatech (Bude jednou povinny OCSP?) Na druhou stranu zakon dba peclive na informaci o zrejmem case revokace, ale vubec pritom neuvazuje o moznosti antidatace podpisu prostym pretocenim hodin v pocitaci pred okamzik revokace. Protoze ovsem ne vsechny podepisovaci systemy umeji pracovat s casovym razitkem v podpisu, bude i toto zaludny problem, ktery bych nechtel resit.
Kdo vyda soukromy klic?
Jde take o to, zdali se uzivatel bude citit bezpecny, pokud bude vedet, ze jeho soukromy klic se nachazel (a mozna stale jeste nachazi) v serveru CA.
Z bezpecnostniho hlediska je zcela neprijatelne, aby privatni klic byl v jakykoliv okamzik mimo vylucnou kontrolu sveho drzitele, protoze prave on je za jakekoliv pouziti tohoto klice plne odpovedny. Takze, IMHO, CA MUZE nabidnout klientovi, aby si klic i zadost kompletne vygeneroval u ni a jejimi prostredky (a to v ramci pridruzenych sluzeb poskytovanych autoritou), povazoval bych ale za velice nestastne aby vazala certifikaci zadosti na povinost prijmout tuto sluzbu.
Pokud drzitel privatniho klice pripusti, aby se ho zmocnila cizi osoba jde o jeho nedbalost a je v daleko vetsim nebezpeci nez ze si tato osoba "jen" necha jeho privatni klic znovu ocertifikovat.
Snazit se ochranit drzitele privatniho klice pred jeho vlastni nedbalosti za cenu nebezpeci, ze tento klic ziska a zneuzije naprosto jina osoba nebo organizace (a ten clovek pritom za toto zneuziti ponese plnou odpovednost) by bylo vyhaneni certika poradnym dablem.
> KTERA TECHNOLOGIE?
> Zduvodneni soucasneho zakona sice uvadi,
> ze zakon neuprednostnuje zadnou technologii,
> myslim vsak, ze zakon nastesti) predstavuje
> vitezstvi podpisu pomoci S/MIME/PKIX nad PGP.
> Co o tom soudite?
mate zrejme na mysli principy "tree of trust" vs. "web of trust". V tomto smyslu skutecne zakon dava prednost principu "tree of trust" (s CA a s jejich usporadanim do stromu)
> JAK GENEROVAT PKIX POZADAVEK NA CERTIFIKAT?
> Jako uzivatel pri pripravach na el. podpis
> pri pouziti PKIX byste radeji preferovali
> vygenerovani soukromeho klice i certifikatu
> primo u CA (zjednoduseni procesu a jiste
> spravne nastaveni udaju v pozadavku za cenu
> ohrozeni bezpecnosti soukromeho klice) nebo
> vygenerovani soukromeho klice ve svem pocitaci
> a odeslani pouze zadosti o certifikat do CA
> (tak to autori zamysleli, je to bezpecnejsi,
> ale mene pohodlne)?
tohle je prave jedna z otazek, ktere je treba rozhodnout a osetrit v provadecich vyhlaskach (treba i v tom smyslu, ze bude ponechano na CA jakou variantu zvoli). Zakladnim vychodiskem musi byt to, ze CA potrebuje mit jistotu, ze zadatel je vlastnikem (spravneho) privatniho klice, aby si treba nekoho nenechal vystavit certifikat na verejny klic nekoho jineho. Jak se to zajisti, je sice "technicky detail", ale nesmirne dulezity ....
KTERA TECHNOLOGIE?
Zduvodneni soucasneho zakona sice uvadi, ze zakon neuprednostnuje zadnou technologii, myslim vsak, ze zakon (nastesti) predstavuje vitezstvi podpisu pomoci S/MIME / PKIX nad PGP. Co o tom soudite?
JAK GENEROVAT PKIX POZADAVEK NA CERTIFIKAT?
Jako uzivatel pri pripravach na el. podpis pri pouziti PKIX byste radeji preferovali vygenerovani soukromeho klice i certifikatu primo u CA (zjednoduseni procesu a jiste spravne nastaveni udaju v pozadavku za cenu ohrozeni bezpecnosti soukromeho klice) nebo vygenerovani soukromeho klice ve svem pocitaci a odeslani pouze zadosti o certifikat do CA (tak to autori zamysleli, je to bezpecnejsi, ale mene pohodlne)?
GNU OpenSSL CI PLACENY SOFTWARE?
Docela by mne zajimalo, kolik PKIX certifikacnich autorit se pokusi pouzivat vyse zminenou knihovnu a kolik jich da prednost koupi SW pro CA "na klic" a od jake firmy (mimochodem, minimalne jeden komercni produkt stoji na teto GNU knihovne). Pokud ctou pracovnici nejake CA tento prispevek, budou ochotni sem pripsat informaci o tom, s jakym SW pracuji?
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).
