Vážený pane Peterko, děkuji za skvělý článek, který pochopitelnou formou dává přehled o stavu eIDAS u nás.
Velmi rád bych si od vás přečetl obdobný článek shrnující aktuální stav elektronické identity (eOP, uznávání jiných eID u nás (slovenský eOP, estonská e-Residency ID apod.) a v jakém stavu je projekt STORK.
Je už to tak obsáhlá oblast, navíc různě "zamotaná" národními, unijními předpisy, že by to stálo za článek pro laickou veřejnost. Děkuji.
> Kvalifikovaný el. podpis je významově i užitím totožný s legislativní zkratkou
> nazvanou Uznávaný el. podpis
není totožný, protože ta leg. zkratka zahrnuje dva různé podpisy, které nejsou stejné a liší se v požadavku na kvalifikovaný prostředek (certifikovanou čipovou kartu/USB token): jeden druh podpisu (ten kvalifikovaný) ho vyžaduje, druhý nikoli. Dnes si OVM ještě mohou vybrat, kterým z těchto dvou podpisů se chtějí podepisovat. Od 19.9.2018 už nebudou mít možnost výběru a budou muset používat pouze kvalifikovaný el. podpis.
> kdy identifikace osoby je založena na kvalifikovaném certifikátu,
> který obsahuje IK MPSV a je vydán certifikační autoritou,
> která má akreditaci od Ministerstva vnitra.
akreditace dnes už nejsou, viz článek. IK MPSV dnes již není povinnou součástí kvalifikovaného certifikátu (může v něm být, obvykle také je/bude, ale nesmí to být vyžadováno).
certifikáty, určené k podepisování (tj. kvalifikované) se nezálohují. Pokud o takový přijdete, jednoduše si pořídíte nový (v případě ztráty či kompromitace atd. necháte ten starý ihned revokovat), a podepisujete se už pomocí nového. Podobně, jako třeba při ztrátě/zničení platební karty.
Zálohování má smysl u certifikátů používaných pro šifrování, abyste se i později dostal k tomu, co bylo zašifrováno. Což je mj. důvod, proč by se nemělo (a nesmí) šifrovat kvalifikovanými certifikáty (správně: příslušnými klíči).
dobrý den,
správný dotaz, měl jsem to rozebrat v článku, ale už jsem ho nechtěl dále zvětšovat.
Pojem "uznávaný el. podpis" je naše národní specialita, kterou unijní legislativa nezná. Souvisí s naší výjimkou (že nemusíme používat bezpečné/kvalifikované prostředky).
Dobry den, jak ziskat resp vubec existuje kvalifikovaný prostředek pro vytváření el. podpisů kompatibilni taky s OS Linux(Ubuntu, Mint atd...). Jde o to kdyz OVM zakoupi trebars USB zarizeni anebo ctecky karet ktere pojedou jenom na Windowsech a v buducnu pracuje s alternativou prechodu z OS Windows na OS bezici na Linuxu, neni to diskriminace z pohledu dodrzovani zakona ohledne el.podpisu? Zakon nelze dodrzovat v jinim OS nez Windows??????? Dekuji za odpoved.
Dobrý den.
Chtěl bych se zeptat, zda je změna v názvosloví nebo ve významu. Pokud vím, tak se dosud rozlišoval zaručený a uznávaný el, podpis. V článku je ale důsledně používán pojem kvalifikovaný el. podpis. Je to významově jiný podpis (čl. 25 eIDAS mu přiznává účinky vlastnoručního podpisu) a pojem uznávaný el. podpis přestává výt aktuální nebo je rovnocenný dosud používanému uznávanému?
Mám v tom trochu chaos.
Děkuji za případné vysvětlení.
Kejkle se servisním klíčem (dvojitý podpis žádosti o certifikát, vázanost na jediného držitele), jak jsou popsány v návodu k TokenME, jsou specialita autority PostSignum, nebo se jedná o obecný princip pro kvalifikované prostředky (QSCD)?
Ve druhém případě to znamená, že končí svoboda výběru kryptografických prostředků, protože každá autorita bude vydávat certifikáty jen proti svým vlastním prostředkům. Tedy uživatel si již nebude moci zakoupit token od jedné autority nebo dokonce výrobce a certifikáty se nechat vydávat od jiné autority.
obávám se, že jde o obecný princip: autorita musí "znát" konkrétní prostředek a jeho fungování, aby měla jistotu, že soukromý klíč vzniká uvnitř prostředku a nejde ho exportovat. Na druhou stranu se nedomnívám, že je nutná ona vázanost na jediného držitele - jeden kval. prostředek by principiálně mohl sloužit více držitelům současně. To asi nastane u služeb charakteru server signing, které eIDAS připouští, u klasické varianty (podepisuji se sám) to moc smyslu nedává.
Děkuji za odpověď. Pokud si to pro sebe krátce shnu:
Zaručený el. podpis - slouží např. pro interní potřeby jako je přihlášení do domény, podepisování interních písemností apod. a je založen na certifikátu vydaném např. zaměstnavatelem. Nelze ho použít pro komunikaci s orgány veřejné moci (i když např. naše daňová správa používá matoucí zkratku ZAREP pro kvalifikovaný podpis).
Kvalifikovaný el. podpis je významově i užitím totožný s legislativní zkratkou nazvanou Uznávaný el. podpis a je roven vlastnoručnímu podpisu, kdy identifikace osoby je založena na kvalifikovaném certifikátu, který obsahuje IK MPSV a je vydán certifikační autoritou, která má akreditaci od Ministerstva vnitra.
Platí to?
aky kvalifikivany prostriedok sa pouzije pri autorizovani kvalifikovanou pecatou, bude to cipova karta/usb, ktora bude vydana zamestnancovi a na tejto cipovej karte/usb bude umiestnena kvalifikivana pecat pravnickej osoby/ OVM?
alebo to bude hardver/softver, ku ktoremu sa budu tieto osoby autentifikovat svojim autentifikacnym certifikatom s pouzitim pinu alebo biometrie?
v paragrafe 8 mala byt prva veta suvetia uplne vypustena, takto by OVM museli vsetky dokumenty opatrovat peciatkou. zamestnanci OVM su takto nepriamo nuteni podpisovat za OVM, svojim certifikatom kryt integritu uradneho dokumentu a nesu zodpovednost za kompromitaciu certifikatu a teda aj samotneho dokumentu napriklad rozhodnutia. eidas definuje, ze podpis je jedinecne spojeny s fyzickou osobou. pecat je jedinecne spojena s pravnickou osobou. spravne by zodpovednost za kompromitaciu mala znasat PO.
Co je na tom neprirozeneho?
Na destopu se da pouzit wine, ale v blizke budounosti bude nutno pouzivat i peceti zalozene na kvalifikovanem certifikatu - a spektrum OS na serverech je znacne siroke. Namatkou Linux, Solaris, AIX, ... a ano, i Windows. Menit masinu za par mega kvuli krabicce na par stovek ... jeee, to by zase bylo clanku o plytvani ...
Dobrý den,
dovoluji si zareagovat na Váš dotaz ohledně projektu STORK, resp. STORK 2.0. Realizace tohoto projektu byla sice ukončena v roce 2015, ale v CZ.NIC stále provozujeme PEPS vybudovaný v tomto projektu, přes který se dá přihlásit k autentizační službě Evropské komise (ECAS).
Na základě zkušeností získaných v průběhu projektu STORK 2.0 pak budujeme národní uzel CZ.PEPS, který by měl fungovat jako tzv. eIDAS uzel (eIDAS node) již dle nařízení eIDAS a být integrován s Národní identitní autoritou (NIA).
Moc by mě zajímalo, jak je ověření původu klíče technicky zajištěno. Nedovedu si představit, jak jinak než přesunutím celého procesu odesílání žádosti dovnitř prostředku toho docílit.
Moje spekulace je, že aplikace iSignum určená k podání žádosti o certifikát prostě nechá vygenerovat klíč uživatele, jím nechá podepsat žádost o certifikát, poté vytvoří HTTPS spojení do PostSigna, kde použije právě onen servisní klíč k autentizaci HTTPS spojení, a sestaveným spojením odešle žádost o certifikát. Důkaz, že klíč uživatele vznikl na prostředku, veskrze žádný. Pouze to, že prostředek byl použit k odeslání žádosti.
V politice pro vydávání prostředků PostSignum tvrdí, že prostředek (nebo autorita?) není kompatibilní s jinými autoritami, pokud se s nimi výslovně nedohodne.