certifikace klicu SSL

[Michal Muhlpachr]

Dobry den,
dovolim si take jeste reagovat. Pokud Vas nezajima problematika
certifikatu, preskocte to, je to dlouhe :-)

Dan Lukes wrote:

> Jednoznacnost certifikatu je samozrejme nutna podminka. Certifikaty
> tridy 1 a 2 se lisi prave mirou s jakou CA overila udaje dodan
> zadatelem. Nikoli mirou "jednoznacnosti", tam je pozadavek absolutni.
> Kdyby CA rucila JEN za jednoznacnost, nemelo by zadny smysl delit
> certifikaty do trid.

Ve tride 1 CA ruci skutecne jen za jednoznacnost - viz nejjednodussi
politiky CA. Smysl deleni do trid je prave v tom, k cemu ma byt
certifikat pouzit, coz se nejcasteji vztahuje k tomu, jakym zpusobem je
proverovana totoznost zadatele o certifikat.
Samozrejme nejsou jen tri tridy, ale existuje mnohem vice moznosti, tri
tridy slouzi jen jako nejhrubsi voditko. Pro jednotlive aplikace muze
mit take certifikat ruzne rozsireni (certifikaty X.509 v3) s ruznymi
procedurami jejich prirazovani ci overovani.

>>> V nasich podminkach je prinejmensim potreba, aby prislusna osoba
>>> uznala elektronicky podpis za zavazny a prislusna CA prislibila
>>> veskerou pomoc a spolupraci a poskytnuti prislusnych podkladu vcetne
>>> aktivni pomoci pri jejich ziskavani pri pripadnych soudnich sporech.
>>> Tuto cast problemu vsak embrionalni ceske CA prakticky zcela
>>> zanedbavaji.

>> Nechapu o jake soudni spory by melo jit. Soudit se s certifikacni
>> autoritou lze v podstate jen tehdy, kdyby vydala 2 ruzne certifikaty
>> stejne identifikace.

> Tady doslo k nepochopeni. Mluvim o soudnim sporu s uzivatelem
> certifikatu (nikoli s CA), ktery popira, ze data jeho certifikatem
> zabezpecene pochazi od nej. A tady je potreba aktivni pomoc CA (formou
> svedectvi), ktera se pak nesmi schovavat napr. za to, ze udaje o
> <cemkoliv co je pro takovy spor podstatne> jsou duverne. Tuto, podle
> meho nazoru nezanedbatelnou jistotu zatim zadna CA nezarucuje (byt
> treba jen formou verejneho prislibu).

Tak toto je ponekud problem. V legislative CR neni PRIMO zakotvena
moznost elektronickeho podpisu, proto pokud chteji dve strany el. podpis
uznavat jako ekvivalet na papire, musi k tomu mezi sebou uzavrit
smlouvu, ktera definuje, jak se takovy el. podpis bude delat, co je
zavazne, ... (u nekterych pravnich ukonu je to CR legislativou bohuzel
zatim primo vylouceno - musi byt papir s razitkem :-( )
Pro soud je potom prukazna smlouva, jeji podminky a dukazy (podepsane
prohlaseni osoby o jejim verejnem klici, podepsany dokument).
Jedine co muze dodat CA v pripade tridy 3 certifikatu je uzivatelem
podepsane prohlaseni o jeho verejem klici.
Toto samozrejme specialni CA PVT, ktera vydava certifikaty tridy 3 pro
specialni aplikace dela a je to primo ve smluvnich podminkach.
Kazda aplikace ale muze mit RUZNE naroky na overeni totoznosti ci
dalsich informaci uvedenych zadatelem.
Pro tridu 1 certifikatu neco takoveho nema smysl, protoze totoznost
zadatele se neoveruje.

>> Na to aby certifikat plne nahradil obcansky prukaz, tak na to je to
>> pravda. Avsak pro drtivou vetsinu komercnich aplikaci neni treba
>> zadny specialni zakon (ne v kazdem obchode po mne chteji obcansky
>> prukaz).

>     Jenze pro plne elektronicky styk potrebujete prave takovou
> identifikaci, ktera je ekvivalentni prukazu totoznosti (tam totiz
> neplatite, tak jak je tomu v obchode, okamzite na drevo). Jinak musite > identitu partnera overit (alespon poprve) z nejakeho duveryhodneho
> zdroje (u nas prave OP, nebo rekneme zapis v obchodnim rejstriku). To
> nevadi u *maleho* poctu relativne *stalych* zakazniku nejlepe ze
> *stejne zeme* jako jste vy. Pokud ale kterakoliv z podminek neplati,
> jiz je to neprijemna komplikace (nebo vy vite, jak jednoduse overit,
> ze londynska firma, ktera s vami chce obchodovat opravdu existuje ?).

Tomuto nazoru se budu snazit ponekud vice oponovat.
Pro platebni elektronicky styk se da pouzit nekolika mechanizmu (uvedu
nektere):
1. elektronicke mince (ekvivalent kovovych ci papirovych)
     Toto muze udelat jen emisni banka meny a neni k tomu potreba
     zadnych elektronickych OP ci jakychkoli identifikaci osob. Muze
to       fungovat zcela anonymne jako klasicke penize a
     lze s nimi platit primo na drevo.
     Je k tomu potreba jen technologie, kterou musi zastresovat emisni
     banka a ktera bude k dispozici pro placeni el. mincemi,
rozmenovani      el. minci, ...
2. kreditni zpusob placeni (pouzivaji napr. el. penezenky)
     - vystaveni elektronickeho seku na dorucitele
     - vystaveni elektronickeho seku na jmeno
     To se da doplnovat jeste mechanizmy nabijeni, ...
     Vetsinou je to v nasich sirkach realizvano autentizaci, idenfikaci
     i el. podpisem realizovanym pomoci symetricke sifry a sdileneho
     tajemstvi, ktere umi delat
     smartcard za mensi penize nez smartcard s asymetrickou
     kryptografii.
     - platebni protokol (pouziva platebni server, technologii u
     zakaznika, technologii u obchodnika)
3. debetni zpusob placeni

Nic z toho nevyzaduje ekvivalent prukazu totoznosti (el. mince mohou byt
zcela anonymni) a zalezi jen politice prislusneho penezniho ustavu, komu
umozni techto mechanizmu vyuzivat.

Dale nahradu OP ci vypisu s obchodniho rejstriku v elektronicke podobe
nemuze vydavat zadna komercni organizace. Pokud nejaka komercni
organizace neco takoveho dela, dela to prave jen pro specialni aplikace
(napr. obchodovani s akciemi) a nikdy to neni obecna
nahrada OP ci vypisu. Jiny subjekt totiz nemusi verit, ze to
skutecne ekvivalent je.
Identifikaci ekvivaletni prukazu totoznosti muze vydavat jen statni
instituce s prislusnou podporou legislativy.

Navic krizove certifikace umoznujici zjistei identity nekoho v jinem
state jsou v naprostych zacatcich. Ve statni sprave to nefungue nikde,
na akademicke pude existuje nekolik nezavyslych projektu a v komercni
sfere jsou zatim jen nesmele pokusy.

Plne elektronicky styk muze fungovat, az bude legislativne podporovan a
v CR standardizovan. Celni doklady napr. MUSEJI byt podle zakona na
papire s razitkem.
Ve standardech statniho informacniho systemu neni zatim ani navrzen
zadny mechanizmus el. podpisu :-(
To americane jsou na tom lepe - viz napr. http://www.nist.gov
http://csrc.nist.gov

>> Napr. i u nas se pouzivaji kreditni karty a lze se inspirovat
>> situaci u nich - problemy s jejich zneuzitim byly presunuty na
>> drzitele karty.

> Mate pravdu. Tak je to u nas. Ve svete jsou daleko casteji presunuty
> na vydavatele karty (tedy treba banku), ktery tak ma slusnou motivaci
> provest prislusne zabezpeceni. To ale jen tak mimochodem. Jinak jsou
> karty totiz

Toto je prave vec, ktera je zpusobena principielne JINOU legislativou.

>>> Mel jsem vsak z doslych prispevku pocit, ze dochazi k
>>> jistemu preceneni realneho vyznamu certifikatu.

>> Ja mam naopak pocit, ze se jejich vyznam silne nedocenuje.

> Ne, opravdu mam pocit, ze se jejich vyznam precenuje. Predpokladejme,
> ze (dobre) sifrovane spojeni je samozrejmost. Za takovych podminek se
> zakaznik smerem ke me muze identifikovat jakymkoliv jednoznacnym
> retezcem (tedy i heslem). Certifikat, vsak toho dokaze vic nez pouhe
> heslo a ma potencial byt pomerne duveryhodnym "prukazem" NEZNAME
> osoby. Toto vyuziti certifikatu, ktere je velmi zadouci pro nektere
> typy aplikaci (typicke je to u elektronickych obchodu) pak ale
> skutecne vyzaduje VELMI duveryhodnu CA. Tato duveryhodnost je zcela
> neporovnatelna s naroky na CA, ktera zajistuje "jen" jednoznacnost ...

Opet si dovolim nesouhlasit. Jak chcete dosahnout dobreho sifrovaneho
spojeni pro prenos e-mailu, pokud predpokladame zachovani mechanizmu
store and forward a navic e-mail chodi pres potencialne nepratelske
uzemi (mbox u inet providera)?
CA vydavajici certifikaty tridy 1 (bez overeni totoznosti) je vhodna
volba pro aplikaci bezenho bezpecneho e-mailu.
Tezko take hovorit o dobrem sifrovanem spojeni pri distribuci SW - opet
bezpecna distribuce SW je aplikace, ktera muze vyuzit certifikaty
tridy 1.

Certifikaty, kterou jsou pouzivany misto autentizace heslem maji take
sve vyhody. Pri jejich pouziti se ani provozovatel aplikace, ke ktere
uzivatel pristupuje nemuze autentizovat jako uzivatel. Navic umoznuji
vzajemnou identifikaci a autentizaci uzivatele proti sluzbe - tezko bude
uzivatel podle hesla, ktere mu sluzba posle kontrolovat, jestli skutecne
komunikuje s tou sluzbou, se kterou se domniva se komunikuje (pokud by
tomu tak nebylo mohl by uzivatel sdelit heslo byt sifrovanym kanalem
uplne nekomu jinemu nez chce a ten by si s tim heslem mohl delat co
chce, ze - treba se prihlasit na sluzbu k vam - sifrovanym kanalem - a
vydavat se za nekoho jineho). Umoznuji el. podepsane transakce, ...
Takze na zaver se priklanim k nazoru, ze vyznam certifikatu byt tridy 1
se silne nedocenuje a je to prave prvni krok k tomu, aby se lide
seznamili s tim, co je to certifikat, k cemu je certifikacni autorita,
jak se da pouzit, ze si musi chranit soukromy klic, ...


> Prosim, nevylozte si tento dopis jako utok na PVT a jeho sluzbu. To,
> co PVT dela dela pravdepodobne dobre. Ja jen uz v prvni reakci chtel
> rict, ze Internet by potreboval "jeste neco navic", ze uz nebude
> dlouho trvat nez to nekdo poskytovat zacne, a ze je skoda, ze u nas to
> bude trvat jeste dlouho.
> Ale treba se mylim.

Je dobre, ze se o techto blemech zacina mluvit a diskutovat, tak se
treba vice lidi o problematice dozvi a zacne ji studovat. Obecne
nejvetsim problemem v oblasti bezpecnosti informacnich systemu je podle
meho nazoru prave vzdelanost lidi v teto oblasti.

Nedomnivam se, ze by nas v brzku cekaly prekvapeni
v podobe legislativy ci standardu, vzdyt i EC ma v teto oblasti nemale
problemy - viz napr. http://www.ispo.cec.be/Ecommerce/

Elektronicke placeni v podobe existujich projektu elektronickych
penezenek Internetu asi take zadne vyhody neprinese, platebni server
pracujici v podminkach ceskeho bankovnictvi asi take nikdo nedela a SET
k nam diky stavu bankovniho sektoru v CR take v brzkem horizontu
nedorazi.
No treba nekdo pracuje na nejakem vhodnem platebnim protokolu :-)

Pravne zavazne el. podpisy jsou vazane na smluvni vztahy, takze
pokazde pujde o proprietalni reseni, ktere nebude legislativne
univerzalni.

> Dan Lukes, Patkova 3/A1703, Praha 8, Czech Republic
> tel +420-(2)-8551040 ext 330, E-Mail: dan at obluda.kolej.mff.cuni.cz,
> aka: LUKES(or Postmaster)@Menza.MFF.CUNI.CZ and others


S pozdravem

--

Michal Muhlpachr ________________________________
email: michalm at pvt.net  http://www.pvtnet.cz
tel:+420-5-4155 8424
PVT a.s., Veveri 102, 659 10 Brno, Czech Republic