Názory k článku Datové schránky: první praktická zkušenost

Moje Windows for Workgroups and Symbian S60 taky podporovany nejsou. Hruza!

Tváří v tvář povoleným formátům by mě zajímalo, jaký způsobem bud prováděna zákonem stanovená konverze u formátů
wav, mp2,mp3? To je bude uřednice na Czech Point poslouchat do sluchátek a přepisovat jako písařka? A co mpeg soubory?
A vůbec, vyplývá z toho, že já smím poslat státní správě, místo napsané žádosti, například ústní žádost, namluvenou do mikrofonu, a nebo dokonce do kamery????

Upřesňuji poslední větu: namísto "porušoval tento úřad zákon", patří správně "porušoval tento úřad obecně závazný předpis", protože v daném případě povinného formátu pro spisovou službu jde o prováděcí vyhlášku č. 191/2009 Sb.

ona "pravnicka osoba" muze by klido firma o jednom cloveku, ktera ani nema PC, protoze jej na nic nepotrebuje. Znam nemalo srocek ktere takto funguji. IMo by byla zajimava zaloba vuci statu o poskytnuti prislusnych $ na nakup prislusne techniky. Ono tech +- 100k (HW + licence + prace s instalaci a konfiguraci toho vseho) x pocet pravnickych osob by byla vcelku zajimava suma.

Ostatne i tadu v diskusich se objevily reakce ve smyslu mame PC, ale na vsech x64 tuxe.

Omyl, pokud mate aktivni DS, tak dostanete prdlajs, je vasi povinosti si to cist z ni. Na druhou stranu jsou uradny poviny do ni zasilat, ale vzhledem k nulove odpovednosti a nulovym sankcim vam to papirove poslat muzou. Vy jim ovsem ne.

Mě jde o to samé, co Vám. Pokud používám podmiňovací způsob, používám jej na základě toho, jak znějí prováděcí vyhlášky, přičemž do toho implementuji svůj názor, který je mým názorem právě proto, že obecně závazné právní předpisy nejsou zcela jednoznačně napsané či některé otázky neřeší, či k závěru lze dojít teprve na základě posouzení více právních norem, a to ne ještě na základě přesné specifikace pojmů, ale na základě toho, jak bude probíhat praktická činnost s přihlédnutím k "ideálům" průhledné veřejné správy a její efektivity. To je ona složitost otázky, že je potřeba přihlédnout k více právním normám, na což upozorňuji (ani ne tak Vás, jako spíše OVM), kdežto pokud OVM na tuto provázanost zapomenou a budou se řídit pouze výčtem přípustných formátů podle jedné vyhlášky, je pravděpodobné očekávat právě ten stav, který se Vám i mě nelíbí.

Podepsat PDF dokument jako celek lze i mimo nadefinované pole formuláře, prostředky pro to existují (např. FreePDFSign). Prostředí OpenOffice umožňuje přímo zvolit, kolika certifikáty bude Open Document podepsán, jsou-li nainstalovány. Jinak ne vše musí být upraveno legislativou do všech podrobností, já osobně nejsem přítelem nadbytečné reglementace, i když tam, kde platí "vorsghrift und befehl", je to jistě na místě ve formě prováděcí vyhlášky nebo přinejmenším metodického pokynu, které mohou být zrušeny poté, co se nějaký postup stane obecnou praxí.

pardon, typo error: vorschrift und befehl

SW prostředky, které umožňují podepisování svých formátů (i když je konkrétně pro podpis použit třeba SW třetí strany) umožňují při prohlížení nebo otevření tyto podpisy také zobrazit a ověřit platnost. Protože jsou formáty dány vyhláškou, musí se IT útvary OVM postarat o to, aby alespoň pracoviště, které nakládá s e-podatelnou či spisovou službou mělo příslušný SW k dispozici a bylo ve směru ověřování platnosti kvalifikovaných certifikátů zaškoleno (když už se o takový SW, který by pracoval s definovanými přípustnými formáty nepostaral stát, který to nařídil). Protože zákon o elektronickém podpisu definuje, kdo je certifikační autoritou, je vhodné mít kořenové certifikáty všech státem uznávaných certifikačních autorit lokálně stažené a pak proti těmto certifikátům nebude problém platnost el. podpisu ověřit. To, že ověřování platnosti kvalifikovaných podpisů nebude žádná sranda je jasné a dokonce o tomto ověření jsou povinny OVM vést zvláštní evidenci. Jinak sofistikovanější spisovky by měly být pro takové ověření vybaveny včetně případných evidenčních záznamů.

Omlouvám se za mystifikaci - za tvrzení v mém příspěvku shora že "o tomto ověření jsou povinny OVM vést zvláštní evidenci". Ne, pouze musí výsledek ověření připojit k dokumentu v digitální podobě, jehož se ověření týká.

"A kolik si takových prostředků má OVMko koupit a kdo mu to zintegruje do jednoho sw."

Nemusí všechno kupovat, Adobe Reader a OpenOffice jsou zdarma pro všechny platformy. 602 XML Filler na fo/zfo formát je zdarma (pravda, jeho tvrzená multiplatformnost je poněkud problematická). Prohlížeč na isdoc/isdocx je zdarma, zatím jen pro jednu platformu. Integrace pro účel ověřování certifikátů do jednoho SW je příležitost pro SW firmy a jistě se toho ujmou. Do té doby je třeba zajistit, aby byly nainstalovány aplikace, které certifikáty pro jednotlivé formáty dokáží ověřit. Není jich zase tak mnoho. Stejně není tak mnoho státem uznaných certifikačních autorit, takže ověření zneplatněných certifikátů v jejich databázi nebude nepřekonatelný problém.

"kde žijete, že všechny OVMka mají IT oddělení!"

Já jsem nemluvil o odděleních, ale zcela záměrně jsem použil pojem "útvar", což může být odbor, oddělení, referát, 1 osoba popř. pracovník zabezpečující IT v kumulaci s dalším agendami. Znám situaci na mnoha OVM a jestliže posledně jmenovaný (onen kumulovaný) příklad je schopen zabezpečit pro podatelnu OVM ověřování certifikátů jak SW tak procesně popisem úkonů, nečeká na integrovaný SW a řeší situaci podle toho, co mu ukládá zákon, není důvod se domnívat, že by to "nadupanější" IT pracoviště nezvládly. Bude-li k dispozici integrovaný SW, tím lépe.

Jinak nevím, proč se stále odkazujete na outlook (myslíte MS Outlook nebo Outlook Express?), je to jen jedna aplikace a je to jeden z mnoha možných poštovních klientů a mnohé jiné řeší podporu certifikátů lépe, protože dávají na výběr, které certifikáty si do aplikace zavedete, včetně tzv. důvěryhodných. Outlook Express vám bude maximálně řešit přílohy e-mailové pošty, nevím jak je to u MS Outlook, jestli naimportované certifikáty jsou použity jako úložiště např. pro MS Word. V tomto směru omluvte mou neznalost, s MS Office nekamarádím už hodně dlouho (a jsou OVM, která jsou na tom podobně).

Problém chápu, očekávám proto, že s ohledem na už vzniklou legislativu a nastavení tvrdých podmínek (když už to tak předkladatelé zákonů a současně tvůrci vyhlášek na poli eGov tak zvoslili), bude vyvinuta příslušná podpora z úrovně původce těchto jobovek. Co vím, už někdejší Ministertvo informatiky svého času laškovalo s aplikací na vícenásobné podepisování dokumentů, ale tam byl výsledek v podobě java aplikace, která nezajišťovala přímé podepsání dokumentu, ale jeho zabalení do XML datové obálky, kde byly naládovány binární veřejné klíče podpisů, čili něco, co se podobá dnešním obálkám datových zpráv v DS. MVČR se dalo do vytváření free spisové služby, kterou chce poskytnout OVM a doufám, že všechny ty pumprnágle obsažené v právních předpisech do spisovky zapracuje, a doufejme v krátké době. Měli by si být vědomi, co nadrobili a posílit tým pro spisovku několikanásobně oproti stavu, který jsem znal na začátku tohoto roku. Zatím je náběh provozu DS posunut (většina OVM se iniciativně do problémů nehrne, proč také, aby riskovali problémy?) a na nějakou obvyklou kvantitu to bude ještě nějakou dobu najíždět. Myslím, že by OVM ve vlastním zájmu měly vytvořit pracovní skupinu (nebo lobby ;-) ), která by tlačila na ústřední orgán, aby pro nastavené mantinely zajistil odpovídající prostředky, jinak lze v celkovém všeobecném průměru očekávat dosti paskvilní výsledek, což plyne i z Vašich námitek a námětů.

K Vaší otázce k ISDS - "Dovede systém ISDS přenést elektronicky podepsaný dokument i s vlastním podpisem, pokud ten je v extra souboru?" mohu říci jen to, co plyne z příslušné vyhlášky: bude-li to přípustný formát (například to bude XML soubor s binárním obsahem a bude zveřejněno XSD schéma, pak to ISDS přenese, problém bude, jak si dá na druhé straně adresát ty dva soubory dohromady. Bude-li to XML, kde bude binárka PDF dokumentu a binárka podpisu (podpisů), pak to na straně adresáta vyleze jako jeden datový soubor. Problém bude zase, jak to otevřít.

Pole je nezorané a čeká na oráče.

Abych to trochu vizuálně oddělil pro přehlednost, nechal jsem jednu z otázek zvlášť:

"Dovedou ty openprohlížeče udělat automaticky protokol o kontrole e-podpisu? Čili další ruční práce. Berte to tak, že úředník není líný, a ani není blbý aby nepochopil, že mu vlastně nový systém jen přidělal další práci."

Nedovedou, protože taková potřeba obecně nikde nevznikla a je "českou národní specifikou". Ale protože OpenOffice umožnuje použít rozšíření podpobně jako FF nebo Thunderbird, je možno takovou funkčnost naprogramovat (OOBasic, Python, BeanShell, JavaScript). V tomto směru ale vidím problém v samotné vyhlášce 191/2009 Sb., kde se v § 4 odst. 5 říká, že "výsledek oveření platnosti uznávaného el.podpisu, značky nebo časového razítka původce (zde OVM) připojí k dokumentu v digitální podobě, jehož se ověřování týká" a v § 4 odst. 7 se říká, že "Doručený dokument v digitální podobě , který neobsahuje škodlivý kód, se v nezměněné podobě uloží v úložišti doručených datových zpráv, zavede se do elektronického systému spisové služby a označí se jednoznačným identifikátorem". Protože není v odst. 7 odkázáno na výjimku z nezměnitelnosti dokumentu podle odst. 4, vzniká otázka, jak to vyřešit. Jediná možnost, která mě momentálně napadá je použít "osvědčený" systém DS, tj. XML obálku, v níž bude zabalen "nezměněný" dokument a "výsledek ověření". Pravda, vzniká otázka, co vyhláškodárce tím "původce připojí k dokumentu v digitální podobě" vlasně myslel, každopádně se v dané souvislosti měl vyjádřit mnohem přesněji, ve skutečnosti se při použítí mnou avizované možnosti jedná o obrácený postup s ohledem na odst. 7, a to připojení dokumentu k výsledku ověření - vznikne tak nový XML dokument s daty o ověření a originální původní dokument je v něm zachován "i s chlupama". Vlk se tak nažere a koza zůstane celá ;-)

Ne, to moc dobře nechápete. DS by měly odmítnout pouze soubory obsahující škodlivý kód, pokud prostředky, na nichž jsou DS provozovány takový kód detekují. Přípustné formáty stanoví vyhl. č. 194/2009 Sb.: PDF, PDF/A, XML (jen s podmínkou veřejně dostupného XSD schématu), 602 XML FO/ZFO, HTM/HTML (zapomněli na XHTML, které není podmnožinou HTM/HTML), ODT, ODS, ODP, TXT, RTF, DOC, XLS, PPT, JPG, PNG, TIFF, GIF, MPEG1/MPEG2, VAW, MP2/MP3, ISDOC/ISDOCX. Jmenované formáty musí orgán veřejné moci (OVM) vždy přijmout a zpracovat. Neznamená to tedy, že je fyzická osoba povinna posílat pouze PDF, PDF/A formát. Co by se však mělo objevovat na straně OVM, tedy v jejich odpovědích nebo vůbec v případě zaslání jakékoli zprávy, je poněkud složitější otázka. Pro OVM by mělo platit, že jejich datové zprávy budou ve formátech, které budou vždy čitelné ze samotné povahy formátu (TXT) nebo jsou standardem (skutečným, nikoli "de facto") s veřejně dostupnou specifikací a vyhlášeny jako standard příslušnou uznávanou mezinárodní organizací nebo jako národní standard.

Celá věc je ještě na straně OVM komplikována dalšími právními předpisy, zejména vyhl. č. 193/2009 Sb., o stanovení podrobností provádění autorizované konverze dokumentů, kde je jako vstupní formát konverze určen PDF 1.3 a vyšší nebo PDF/A, tzn. jiný formát nelze autorizovaně konvertovat, jako výstupní formát pouze PDF 1.7. V podstatě jiné formáty než PDF nelze autorizovaně konvertovat. OVM by tedy v případě nějakých prostých sdělení, nesouvisejících přímo s výkonem jejich činnosti, pro které byly zřízeny, tj. zejména v případech, kdy jako OVM nevystupují, měly ve vlastním zájmu používat formáty otevřené, pokud možno co nejjednodužší (třeba právě TXT). V ostatních případech, tj. týká-li se věc jejich vlastní činnosti, by měly použít formát PDF a to minimálně ve verzi 1.3 a navíc ve verzi, která umožňuje podepsání dokumentu kvalifikovaným elektronickým podpisem. Jestliže by autor článku například o informace požádal podle zákona č. 106/99 Sb., o svobodném přístupu k informacím, úkon odpovědi ombudsmana by měl již jinou povahu úředního úkonu orgánu, kde ještě navíc kontrola dodržování tohoto zákona je jednou z hlavních náplní činnosti. Kdyby takový úkon nebyl proveden ve formátu umožňujícím autorizovanou konverzi, byl by takový úkon vadný, neboť by znemožnil dotčené osobě o takovou konverzi požádat. Tedy kromě informací např. "Potvrzuji schůzku k projednání návrhu smlouvy na 5.1.2010 11:00" by všechny úkony měly být prováděny ve formátu umožňujícím autorizovanou konverzi.

S tím souvisí i předpisy na úseku archivní a spisové služby, kdy povinným formátem, v němž se na OVM digitální dokumenty povahy statický text nebo statický text kombinovaný s obrázky do elektronických spisových služeb ukládají, je PDF/A. Pokud to spisová služba provozovaná úřadem ombudsmana nemá implementováno (tedy pokud elektronickou spisovku má tento úřad zavedenu, předpokládám, že takový úřad nejpravděpodobněji ano, že nebude k DS přistupovat přes obecné rozhraní), již by v případě, že by šlo o dokument, který má číslo jednací a spis. značku a tedy prošel spisovkou a nebyl do spisovky uložen v PDF/A formátu, porušoval tento úřad zákon.

Normalni lidi si trebas chteji precist zpravu ze sveho PDA/mobilu/v kavarne/na letisti/..... jakpak to asi udelaji, kdyz ji neotevrou, ale za prectenou se povazovat bude ? Jakpak asi stihnou v zakone lhute reagovat, kdyz si zpravu otevrou, ale neprectou ?

Já bych takovou situaci řešil tak, že bych úřadu (popř. jinému odesílateli) zaslal zpětně zprávu, třeba na e-mail, se žádostí o zaslání dokumentu v plaintextu, protože nemám aktuálně možnost si ji přečíst v původně zaslaném formátu. Problém je, že se úřad na to může vykašlat. Mělo by se tlačit na legislativu, aby taková žádost byla povinně vyřízena.