Source: https://platforma.slovensko.digital/t/pouzivanie-zepf-kontajnera-v-roku-2017/3281
Timestamp: 2017-06-28 21:05:49+00:00
Document Index: 10981529

Matched Legal Cases: ['§ 14', 'čl. 27', '§ 14', 'čl. 37', '§ 14', '§ 14', '§57', '§57']

2017-02-15 23:11:53 UTC
Z postu, ktory dnes @jsuchal zverejnil na svojom FB profile usudzujem, ze zivnostensky register mu poslal elektronicky podpisane rozhodnutie, ktore nevedel jednoducho otvorit na Linuxe, pretoze podpisany dokument je ulozeny v ZEPf kontajneri (je to subor s priponou .zep). Osobne zastavam nazor, ze OVM by dnes uz ZEPf kontajner nemali pouzivat, pretoze existuje medzinarodne uznavana a standardizovana alternativa v podobe ASiC kontajneru a tiez preto, ze im za to podla mna hrozi pokuta zo strany NBU. Co si treba uvedomit skor nez budete citat dalej: To, ze ten subor ma priponu .zep ani to, ze ZIP archiv s podpisanym dokumentom sa technicky nazyva ZEPf kontajner vobec, ale NAOZAJ VOBEC neznamena, ze by podpis vytvoreny zivnostenskym registrom nutne musel byt nejaky "stary" ZEP a teda by to nebol nejaky "novy" KEP. Podpisovu strukturu ani jej format tu vobec neriesme. Riesme len format ZIP archivu, v ktorom je ulozeny podpisany dokument (.rtf subor) a podpis (.p7s).
Co je to ZEPf kontajner:
ZEPf kontajner (.zep subor) je ZIP archiv, ktory sa pouziva na spojenie suboru s podpisanym dokumentom (.rtf .pdf .txt alebo cokolvek ine) a suboru s elektronickym podpisom (.p7s subor). Tento format je definovany v informativnej prilohe standardu Formáty zaručených elektronických podpisov, ktory vydalo NBU SR. Jedna sa teda o cisto slovensky format, v ktorom je skrytych viacero technickych prekvapeni, no napriek tomu bol v slovenskej statnej sprave hojne pouzivany.
Cvicenie pre technicky zvedavych: Pripravil som priklad .zep suboru, v ktorom som zamerne invalidoval podpis vymazanim rodneho cisla z certifikatu. Zmente si koncovku suboru na .zip a skuste v archive najst podpisany dokument hello.txt. Good luck! Hint: Jano popisal postup na svojom FB profile.
Co je to ASiC kontajner:
ASiC kontajner (moze mat koncovky .asice .sce .asics .scs alebo .zip) je ZIP archiv, ktory sa tiez pouziva na spojenie suboru s podpisanym dokumentom a suboru s elektronickym podpisom - teda na to iste, na co sa pouziva slovensky ZEPf kontajner. Definuje ho specifikacia ETSI TS 102 918 vydana europskym institutom ETSI a je pouzivany vo viacerych krajinach EU. Z technickeho pohladu tiez nie je uplne idealny (tiez ma par prekvapeni), ale dovolim si tvrdit, ze oproti ZEPf kontajneru je lepsi.
Cvicenie pre technicky zvedavych: Pripravil som priklad .asice suboru, v ktorom som zamerne invalidoval podpis vymazanim rodneho cisla z certifikatu. Zmente si koncovku suboru na .zip a skuste v archive najst podpisany dokument hello.txt. Ovela lahsie, ze?
Preco by OVM nemali pouzivat ZEPf kontajner:
Používanie elektronického podpisu od 1.7.2016 upravuje na európskej úrovni Nariadenie Európskeho parlamentu a Rady č. 910/2014 z 23. júla 2014 (ďalej len eIDAS), z ktorého vychádza slovenský Zákon č. 272/2016 Z.z. o dôveryhodných službách (ďalej len zákon). Zákon v § 14 ods. 4 obsahuje nasledujuci text:
Laicky to chapem tak, ze ak OVM podpisuje v inom formate nez povoluje eIDAS, tak sa dopusta spravneho deliktu, ktory by mal riesit NBU. Podme sa teda pozriet na odkazovane casti eIDAS a overit si, ci schvaluju ZEPf kontajner.
eIDAS v čl. 27 ods. 5 odkazovanom z § 14 ods. 4 nasho zakona obsahuje nasledujuci text:
Komisia do 18. septembra 2015 prostredníctvom vykonávacích aktov vymedzí referenčné formáty zdokonalených elektronických podpisov alebo referenčné metódy pre prípady, keď sa používajú alternatívne formáty, pričom zohľadní existujúcu prax, normy a právne akty Únie. Uvedené vykonávacie akty sa prijmú v súlade s postupom preskúmania uvedeným v článku 48 ods. 2
V čl. 37 ods. 5 tiez odkazovanom z § 14 ods. 4 nasho zakona obsahuje nasledujuci text:
Komisia do 18. septembra 2015 vymedzí prostredníctvom vykonávacích aktov referenčné formáty zdokonalených elektronických pečatí alebo referenčné metódy pre prípady, keď sa používajú alternatívne formáty, pričom zohľadní existujúcu prax, normy a právne akty Únie. Uvedené vykonávacie akty sa prijmú v súlade s postupom preskúmania uvedeným v článku 48 ods. 2
eIDAS teda formaty priamo nedefinuje, ale odvolava sa nejaky vykonavaci akt, ktorym je podla mna Vykonávacie rozhodnutie Komisie (EÚ) 2015/1506 z 8. septembra 2015. To obsahuje odkazy na technicke normy:
Základný profil XAdES podla ETSI TS 103171 v.2.1.1
Základný profil CAdES podla ETSI TS 103173 v.2.2.1
Základný profil PAdES podla ETSI TS 103172 v.2.2.2
Základný profil podpisového kontajnera vo formáte ASiC podla ETSI TS 103174 v.2.2.1
ZEPf kontajner som tam nikde uvedeny nenasiel.
Bolo by super, ak by sa niekomu chcelo mnou popisany pohlad na vec verifikovat a ak je nespravny, tak ho opravit. Mozno som si nieco nevsimol, mozno neviem o nejakej uprave, prechodnom obdobi alebo niecom podobnom.
Nie som v tychto veciach zbehly a nie som ani pravnik, takze neviem aky je spravny postup, ale napadlo mi, ze by Jano ako prijemca v uvode spominaneho dokumentu podpisaneho OVM mohol podat podnet na NBU (dokument samozrejme prilozit ako dokaz), aby zacalo vytvorenie podpisu zivnostenskym registrom riesit v zmysle § 14 ods. 4 zakona 272/2016 Z.z. o doveryhodnych sluzbach ako spravny delikt. Podla mna by z toho mohlo vzist oficialne stanovisko upravujuce dalsie pouzivanei ZEPf kontajnera.
2017-02-16 00:00:11 UTC
Pokiaľ ide o ZEPf, vidím to jednoducho:podľa výnosu MF SR o štandardoch pre ISVS §57c sa môže pri vytváraní podpisu použiť iba jeden z tam určených formátov (s výnimkou "ak sa na tom všetky strany príslušnej komunikácie dohodnú, s vedomím možných škôd a nezrovnalostí v ďalšom konaní vyplývajúcich z takého postupu"). Podľa §57b.a má byť použitý ASiC kontajner. ZEPf štruktúrou nezodpovedá ASiC kontajneru, teda povolený nie je.Vo vnútri tento kontajner môže obsahovať opäť iba objekty podľa výnosu.Formát dokumentu RTF povolený nie je.
Už dosť dlho teda je bez pochyby jasné, že ZEPf podpisy sú vytvárané v rozpore s platnými pravidlami. MF SR o tom vedelo, malo možnosť kontrolovať a sankcionovať, nič. ÚPVII o tom vie a má možnosť sankcionovať, nič. Tento nový pokus s NBÚ určite stojí za to, @jsuchal go! (Zatiaľ každý podpis vytvorený OVM čo poznám nezodpovedal platným štandardom.)
Mimochodom, Hello world!
2017-02-16 05:46:26 UTC
Vnútroštátna úprava musí byť už dnes súladná s nariadením a vykonávacími predpísmi komisie. Ak OVM vytvára podpis alebo pečať, musí byť vytvorený podľa nariadenia eIDAS. Ak sa vydáva certifikát, tento musí byť vydaný v súlade s eIDAS.
Najzábavnejšie je, že originály súdnych rozhodnutí vznikajú mimo nariadnia eIDAS.
2017-02-16 08:20:24 UTC
Naše štandardy, viď. to čo píšem, sú ešte "prísnejšie", resp. konkrétnejšie ako eIDAS.
2017-02-16 08:54:36 UTC
tak co ... bude reportaz ? alebo zaloba ? .... alebo sa s tym zmierime ? ... jsuchal
2017-02-16 09:12:06 UTC
Ja to v pohode podam. Len teda to potrebujem naformulovat a hlavne by som domyslel, ze co bude vlastne vysledkom. Ak bude vysledok to, ze to sposobi X change requestov na Y systemov, tak mam velke nutkanie toto neurobit.
2017-02-16 09:17:35 UTC
Ono, vo verejnej sprave je zauzivane "neuznavanie", resp. uplna ignoracia medzinarodnych standardov. Napr. nedavno, pri dotaze na format uchovavanych lekarskych zaznamov mi bolo oznamene, ze sa nebudu pouzivat univerzalne a medzinarodne uznavane, ale nieco proprietarne duro
2017-02-16 09:47:58 UTC
Treba si uvedomit, ze aj OVM, ktore dokazu generovat ine vystupy, musia brat ohlad na prakticke pouzitie sluzieb a kompatibilitu. V podstate su postavene pred volbu:
nebudem v sulade a dokonca sa vystavim hrozbe pokuty, ale sluzba bude pouzitelna (t.j. vystavim ,,starsi'' format ale prijimatelia ho budu vediet spracovat)
budem v sulade, ale kedze niektori prijimatelia na to nie su pripraveni, tak tu sluzbu pre nich prakticky odstavim. Naco som elektronizoval sluzbu, ak prepnutim formatu na svojej strane znemoznim alebo vyrazne obmedzim jej pouzitie. Prepnem to, a teraz budem mesiace cakat, kym si druha strana spravi domacu ulohu a vratim sa do stavu pred elektronizaciou? Kto spravi take rozhodnutie so vsetkymi dopadmi, ktore to ma?
Problem je ten (a je si toho vedomy aj UPVII a ma sa to riesit), ze tuto aktivitu mal niekto skoordinovat, a nie len publikovat poziadavku a termin.
2017-02-16 10:06:11 UTC
Lenže deje sa iná habaďúra, fédrujeme technické riešenia, ktoré nie sú suladné s nariadením a jeho vykonavacími predpismi. Napr. Súdne alebo úradné rozhodnutie v originálne bude v štandarde, ktorý nariadenie nepozná. Pritom mali sme od roku 2015 dostatok času prispôsobiť systémy. Takže teraz vychŕlime stovky tisíc rozhodnutí, pričom aj tak budeme musieť prispôsobiť systém nariadeniu. Ľuďom na eID nahrávame certifikáty, ktoré idu podľa starej právnej úpravy, napriek tomu, že už neplatí.
2017-02-16 10:14:43 UTC
Aj tak sa systémy musia prispôsobiť nariadeniu. Právne účinky úradných elektronických dokumentov, ktoré nie sú súladné s nariadením sú nulitné, lebo OVM sú povinne komunikovať v štandardoch a technických normách podľa nariadnia.
2017-02-16 10:20:22 UTC
Samozrejme, ze bolo dost casu prisposobit systemy. Ale ak si producent system prisposobil a konzumenti nie, co ma chudak producent robit? a) Moze si povedat, ze on si svoje povinnosti splnil, kaslat na ostatnych a nechat system vybuchnut.b) Z vlastneho rozpoctu uhradi upravy systemov a procesov tak, aby to jednemu generoval tak a druhemu onak a zabezpecil kontinuitu sluzby aj pre tych, ktori si nespravili domacu ulohu. De facto je tak trestany za to, ze on si domacu ulohu spravil, nehovoriac o nezmyselnosti takehoto vydavku.c) Spolahne sa na prislub od UPVII, ze to niekto dodatocne skoordinuje (co sa malo stat hned nazaciatku) a dufat, ze nebude trestany za stav, ktory nesposobil.
2017-02-16 16:31:54 UTC
Ak by všetci dodržali 1., nebol by problém s postupným prechodom na nové formáty. Lenže nie, tu ešte treba nejako detailne koordinovať...
2017-02-16 17:42:45 UTC
2017-02-17 07:24:05 UTC
Mozem vediet na zaklade coho si napisal "Ľuďom na eID nahrávame certifikáty, ktoré idu podľa starej právnej úpravy, napriek tomu, že už neplatí.". Si si isty, ze je to tak?
2017-02-20 16:13:59 UTC
2017-02-22 17:05:52 UTC
do 14.10.2015 (iné sa môžu používať len ak sa zasielateľ dohodne s prijímateľom, s vedomím možných škôd a nezrovnalostí v ďalšom konaní vyplývajúcich z takého postupu) 2.-3. žiaľ, v pracovnej skupine a komisii pre štandardizáciu sa síce v roku 2014 odsúhlasilo znenie s viacročnými prechodnými obdobiami na prijímanie a dočasné vytváranie starých formátov, avšak toto sa nepremietlo do finálnej legislatívy. Túto tému, rovnako ako ďalšie súvisiace s formátmi používanými pri podpisovaní, určite budeme riešiť aj v pracovných skupinách Komisie pre štandardizáciu pre informačné systémy verejnej správy, ktorá sa presunula z MF SR do ÚPPVII a má nový štatút od 1.1.2017. Experti z danej oblasti môžu byť prizvaní na rokovanie, prípadne môžu byť nominovaní niektorým z členov komisie. Je mi jasné, že sa problém s nedodržiavaním povinných formátov nevyrieši sám od seba, keďže niektoré inštitúcie majú obavu spustiť vytváranie ASiC kvôli možnej neschopnosti iných strán ASiC spracovať a preto používajú ZEPf prípadne XZEP. Niektoré inštitúcie v ostrej prevádzke používajú PAdES. Poznámka: Zachytil som v rámci rôznych diskusií už aj taký názor, že pokiaľ je v súlade s eIDAS externý podpis CAdES alebo (detached) XAdES a sú spolu s podpísaným dokumentom len vložené v nejakej "ľahko rozbaliteľnej obálke" (typu .eml, .zip a podobne), tak by sa v zmysle eIDAS mali povinne prijímať. Samozrejme vytvárať by verejná správa mala tie, ktoré predpisuje Výnos o štandardoch č. 55/2014 Z.z.
2017-02-22 19:47:10 UTC
Originály rozsudkov súdov sú dnes vo formáte, ktorý nie je súladný s Nariadením. Aký to má dosah na udržiavanie týchto rozsudkov niekoľko desiatok rokov? Dokonca nemáme rozbehnutú zaručenú konverziu.
2017-02-23 04:28:53 UTC