Zprávy v datových schránkách se zvětší jen na 100 MB místo na původně plánovaný 1 GB

Agentura DIA již připravila novelu prováděcí vyhlášky, která by k 1. 1. 2024 měla zvětšit maximální velikost datových zpráv a zavést nové formáty příloh. Nechystá se ale využít příležitost k opravě dřívějších chyb, naopak se chystá k nim přidat další, nové chyby.

Po velkém třesku na přelomu loňského a letošního bylo kolem datových schránek delší dobu ticho. Jen drobně narušené zmínkou o dalším odkladu již dříve zveřejněného záměru: zvětšit maximální velikost datové zprávy a zavést nové formáty toho, co je možné vkládat do datových zpráv jako jejich přílohy. Nově byly změny odloženy až na přelom současného a nového roku, neboli k 1. 1. 2024.

Jaký je současný stav a co se má změnit?  

Dnes je pro celé datové zprávy, tedy včetně všech příloh, maximem 20 MB. Existují ale privilegované datové schránky (tzv. další DS OVM, zřizované na žádost), do kterých lze zasílat i datové zprávy do maximální velikosti 50 MB. 

To ale nemusí v některých případech stačit – a tak se již dříve zrodil záměr zvětšit maximální velikost až na 1 GB. S tím, že půjde o tzv. velkoobjemové zprávy (VoDZ), kterými mohou být jak veřejnoprávní datové zprávy, tak i ty soukromoprávní (poštovní).

Současně mělo dojít k rozšíření formátů možných příloh datových zpráv o „kontejnerové“ formáty ZIP a ASiC, které se dosud do datových zpráv vkládat nedají.

Jak se postupně odkládalo a měnilo

První zmínka o popisovaném záměru zazněla již na jaře roku 2021. V testovacím prostředí byly změny nasazeny již v roce 2022 a v ostrém (produkčním) prostředí se původně měly objevit již počátkem toku 2023. Jenže podmínkou bylo připravit návrh změny prováděcí vyhlášky (č. 194/2009 Sb.), ve které je vše zakotveno. Což se napoprvé nestihlo, a tak došlo k prvnímu odkladu celého záměru – na polovinu roku 2023.

Potřebný legislativní návrh na novelizaci prováděcí vyhlášky, ještě z dílny MV ČR, se objevil v eKlepu až počátkem roku 2023 a prošel i standardním připomínkovým řízením. V něm zazněly dvě hlavní skupiny připomínek: jedna argumentovala tím, že účinnost k 1. 7. 2023 nedává příjemcům dost času na to, aby své systémy stihli upravit na novou maximální velikost datových zpráv. Druhá poukazovala na to, že 1 GB je moc a že elektronické spisové služby na to nejsou připraveny:

Domníváme se, že změna z 20 MB na 1 GB je příliš velká. eSSl nejsou v současné době na takovou změnu přizpůsobené.

Nakonec byl přijat „kompromis“: změny se odloží o půl roku (k 1. 1. 2024) a z 1 GB se sleví na 100 MB. Aby bylo dost času přizpůsobit se i takto snížené laťce:

Účinnost vyhlášky bude odložena k datu 1. 1. 2024, které se jeví po projednání s dotčenými resorty a po modifikaci původního návrhu k implementaci dostatečné.

Takovéto změny v návrhu novely si ale vyžádaly její úplně nový návrh, nyní již z dílny agentury DIA. Ten se ve veřejném eKlepu nedávno (20. září) skutečně objevil. Pojďme se na něj podívat podrobněji.

Co všechno se má změnit?

Nový návrh, formálně: „Návrh vyhlášky, kterou se mění vyhláška č. 194/2009 Sb., o stanovení podrobností užívání a provozování informačního systému datových schránek, ve znění pozdějších předpisů“ skutečně počítá se zvětšením maximální velikosti datových zpráv jen na 100 MB místo původního 1 GB.

Jde přitom o velikost datových zpráv ve smyslu toho celku, který se skutečně přenáší mezi datovými schránkami, má (při stahování) formát ZFO a chová se jako přenosový kontejner, ve kterém je umístěna jedna, nebo více příloh. 

Je bohužel nutné to takto zdůraznit, protože samotná vyhláška (i její novela) používají pojem „datová zpráva“ jak v tomto smyslu, tak i ve smyslu příloh, vkládaných do skutečně přenášených datových zpráv (viz dále). Nejde tedy o maximální velikost jednotlivých příloh, ale o souhrnnou velikost všech příloh v jedné zprávě (a příslušné obálky).

Další změnou oproti původnímu návrhu je rozšíření výčtu nově přidávaných formátů příloh datových zpráv (nikoli datových zpráv samotných). Původně bylo navrhováno přidat jen dva „kontejnerové“ formáty, a to ZIP a ASiC.

Z připomínkového řízení k předchozímu návrhu vzešel požadavek na přidání formátu JSON. Byl akceptován a kromě něj mají přibýt i formáty MPEG-4 (audio i video) a také formát HEIF (High Efficiency Image File Format), který je v zásadě také kontejnerovým formátem. Nicméně novela jej za kontejnerový formát nepovažuje.

Kontejnery ano, ale…

To, zda prováděcí vyhláška považuje určitý formát přílohy jako kontejnerový, je relevantní kvůli dalším požadavkům, které jsou na kontejnerové formáty kladené. Tím hlavním je to, aby do kontejneru „bylo vidět“ a systém datových schránek se dostal k jeho obsahu a mohl kontrolovat jeho strukturu, počet objektů (souborů i adresářů) i jejich formát a detekovat případný malware. Kontejnery proto nesmí být zašifrované.

Po samotném obsahu kontejneru se pak požaduje, aby obsahoval alespoň jeden soubor v některém z „nekontejnerových“ formátů, explicitně uvedených ve vyhlášce, a naopak neobsahoval žádný soubor jiného formátu (než jsou ty „nekontejnerové“, uvedené přímo ve vyhlášce). 

Není tedy přípustné ani vnořování kontejnerů (vkládání jednoho kontejneru do druhého). Obsahem kontejneru navíc nesmí být více než 1000 souborů (a adresářů), maximální hloubka vnoření adresářů je 4 a po dekomprimaci nesmí mít obsah kontejneru více než 3 GB.  

Více možností pro vyloučení z přepravy

Další změnou, která souvisí se zabezpečením systému datových schránek, je možnost nepřijmout datovou zprávu k odeslání v případě hrozícího přetížení systému:

Cílem navrhované změny je tak poskytnout správci, resp. provozovateli ISDS funkční nástroj, jak adekvátně předcházet a reagovat na již vzniklé ohrožení bezpečnosti, dostupnosti a funkčnosti ISDS a jiných informačních systémů veřejné správy ze strany osob, které využívají datovou schránku k tzv. denial-of-service (DoS) útokům.

Konkrétní formulace je nejspíše záměrně velmi obecná a zahrnuje v sobě i detekci malwaru, který naopak jako samostatný bod mohl vypadnout.

Zajímavé je, že celé ustanovení je formulováno s ohledem na správce datových schránek, kterým je dnes agentura DIA. Jen té tak vyhláška dává popisovaná práva nepřijmout k odeslání konkrétní datové zprávy. Ve skutečnosti by toto právo asi potřeboval spíše provozovatel celého systému, kterým je Česká pošta.

Tím už se dostáváme k problematickým místům současné vyhlášky i její nově navrhované novely.

Přípony místo formátů

Přetrvávajícím problémem je, že stávající vyhláška i její novela specifikují přípustné formáty příloh nikoli jako takové, např. skrze jejich MIME typy, či alespoň odkazy na příslušné normy a standardy, nýbrž výčtem přípustných přípon souborů. To ale není jednoznačné: pro stejný formát se může používat více různých přípon, třeba i v závislosti na konkrétní systémové platformě, a někdy se stejné přípony používají pro různé formáty.

Příkladem mohou být videoformáty MPEG. Ve stávající verzi vyhlášky jsou přípustné formáty MPEG-1 a MPEG-2, ale určeny jsou jen dvěma možnými příponami: mpeg1 a mpeg2. Takže když bude mít soubor v takovémto formátu s příponu jen mpg (např. kvůli omezení délky přípony jen na tři písmena), již to není přípustný formát přílohy? A pro možnost přenosu je třeba změnit jeho příponu?

Tento konkrétní problém u formátů MPEG-1 a MPEG-2 bude novela částečně řešit připuštěním dalších dvou „zkrácených“ přípon: mpg a mpeg.

Přitom přípony mpg a mpeg jsou fakticky přípustné i dnes, a tak jde spíše o „dorovnání“ právní úpravy ke skutečnému stavu.

Nicméně samotný problém zůstává a bude pokračovat. Třeba u nově zaváděného formátu HEIF, pro který se také používá více různých přípon, podle toho, co je jeho obsahem.

Co třeba zkrácená třípísmenná přípona hif? Nebo proč zde nejsou uvedeny přípony heifs a heics, používané pro HEIF kontejnery se sekvencemi obrázků (místo s jednotlivými obrázky)?

Není datová zpráva jako její příloha

Na předchozím obrázku si můžete všimnout dalšího kuriózního problému: zatímco v reálném světě všechny „datové zprávy dodávané do datové schránky“ mají pevný formát (a po svém stažení příponu zfo), vyhláška říká, že „datové zprávy, dodávané do datové schránky“ mohou mít různé formáty, a vyjmenovává ty, které to mohou být, resp. které jsou přípustné. Nejsou to přitom jenom ty z předchozího obrázku, ale i celá řada dalších od PDF přes XML, DOC(X) až třeba po nově přidávané kontejnerové formáty ZIP a ASiC.

Pokud nad tím kroutíte hlavou, pak vězte, že chyba není tak úplně na straně autorů dosavadní vyhlášky. Chyba se stala už v zákoně (č. 300/2008 Sb.), který původně dával Ministerstvu vnitra zmocnění k vydání pouze takové vyhlášky, která by stanovovala přípustné formáty datové zprávy. Nikoli přípustné formáty příloh datové zprávy, k tom vnitro zmocněno nebylo.

A tak se to vyřešilo „jednoduše“: vyhláška byla vydána tak, aby sice specifikovala možné formáty (ve skutečnosti přípony) příloh, ale kvůli nesprávnému zmocnění je musela prezentovat jako možné formáty samotných datových zpráv. Naopak o formátu „skutečné“ datové zprávy se ve vyhlášce nic nedočtete.

Časem naštěstí došlo k úpravě zmocnění přímo v zákoně č. 300/2008 Sb., a to k 1. 2. 2022, skrze zákon DEPO (zákon č. 261/2021 Sb.). Ten rozšířil zmocnění tak, aby prováděcí vyhláška mohla specifikovat nejenom formát datové zprávy, ale také formát jejích příloh. V mezidobí (k 1. 4. 2023) pak celé zmocnění přešlo z vnitra na novou agenturu DIA.

Mohlo se tedy zdát, že je jen otázkou času, kdy dojde k úpravě nesmyslného znění vyhlášky, aby se věci již daly označovat pravými jmény. Aby výčet přípustných formátů mohl být prezentován správně jako výčet přípustných formátů příloh datových zpráv, a nikoli datových zpráv samotných.

Ideální příležitostí k tomu byla příprava novely celé prováděcí vyhlášky. Vlastně již té první zde popisované, z počátku letošního roku. Ta ale příležitosti nevyužila a setrvala na dosavadním přístupu „říkám sice A, ale myslím tím B“.

Bohužel ani nejnovější verze návrhu novely šanci k nápravě nevyužila a nadále setrvává v přístupu „říkám A, myslím B“. Dokonce by se dalo říci, že jej pozvedává na novou, ještě vyšší úroveň dokonalosti. Třeba když vznáší své požadavky na kontejnery (vkládané jako přílohy do datové zprávy), ale mluví o těchto kontejnerech jako o datové zprávě samotné a chce, aby její obsah nebyl zašifrovaný. 

Ve skutečnosti má na mysli to, aby nebyl zašifrován obsah kontejneru, a systém datových schránek tak mohl procházet jeho vnitřní strukturu a kontrolovat, zda jeho obsah splňuje jeho další požadavky (počet souborů a adresářů, hloubku vnoření, absenci škodlivého kódu).

Nebo když uvádí podmínku „datovou zprávu netvoří soubor v jiném formátu než ve formátu uvedeném v bodu I nebo II“ (což jsou nekontejnerové formáty). Má tím ale na mysli to, že obsahem kontejneru mohou být jen takové soubory, které by mohly být do datové zprávy vloženy jako přílohy přímo (a ne jako obsah kontejneru ZIP či ASiC). Přesněji: takové, které jsou ve vyhlášce vyjmenovány jako přípustné. V tom je totiž rozdíl, viz dále.

ASiC kontejner nepůjde podepsat

Jak jsme si již uvedli, v návrhu vyhlášky (konkrétně v bodě c) části V, viz předchozí obrázek) se explicitně říká, že obsahem kontejneru nesmí být soubor žádného formátu, který není ve vyhlášce uveden (mezi těmi nekontejnerovými).

To je ale problém: tvůrci vyhlášky, a to již té první a současné, stejně jako autoři nynější novely, totiž zapomněli na existenci externích elektronických podpisů a neuvedli je mezi přípustnými formáty příloh datových zpráv. A tak se to již kdysi dávno „překlenulo“ kreativním právním výkladem ve smyslu: zákonodárce přeci nechtěl zakázat externí podpisy, a tak musí být přípustné i jejich formáty.

Dodnes tak v Provozním řádu datových schránek najdeme, že formáty externích podpisů (uvedené na obrázku) jsou přípustnými formáty příloh datových zpráv, a to „z rozhodnutí správce“ (kterým bylo původně vnitro, dnes DIA).

Jenže: bude takovýto kreativní výklad možný i po tom, co prováděcí vyhláška „přitvrdí“ a řekne explicitně, že (byť jen v kontejneru) nesmí být nic v takovém formátu, který není ve vyhlášce uveden?

I když se tento explicitně formulovaný požadavek fakticky týká jen obsahu nově přípustných kontejnerů, i tak je to velký problém, a to pro kontejnery ASiC. Ty jsou totiž v zásadě řešením pro „zabalení“ podepsaného obsahu (kterým může být více jednotlivých souborů) a jeho externích podpisů do jednoho celku, navíc s popisem formátů a vzájemných vazeb (co je čím podepsáno atd.).

Standardy přitom počítají se dvěma hlavními druhy ASiC kontejnerů, podle toho, zda se v nich nachází externí podpisy ve formátu XAdES, nebo CAdES (a případně ještě samostatná časová razítka). Externí podpisy ve formátech XAdES jsou soubory s příponou .xml (a jsou to vlastně XML data), a jsou tedy mezi přípustnými formáty toho, co datové schránky připouští v ASiC kontejneru.

Jenže v případě CAdES podpisů uvnitř ASiC kontejnerů jde typicky o soubory s příponou p7s, které ve výčtu přípustných formátů ve vyhlášce nejsou – a jsou pouze mezi těmi, které jsou přípustné díky kreativnímu právnímu výkladu, viz výše.

Bude zajímavou otázkou, zda po přijetí popisované novely prováděcí vyhlášky ASiC kontejnery s CAdES podpisy projdou skrze datové schránky. Zda správce setrvá na svém výkladu o přípustnosti formátů externích podpisů (a časových razítek) i při novém znění vyhlášky.

A ještě jeden problém: pokud si u ASiC kontejneru necháte prodloužit jeho digitální kontinuitu (provést „uchování“, např. kvalifikovanou službou pro uchovávání), přibudou vám v ASiC kontejneru další soubory. Některé mají formát, resp. příponu, se kterým se v právním výkladu počítá (p7s, cer, tst). Ale jedním z nich budou i revokační informace, buď v podobě CRL seznamu (nejspíše s příponou crl), nebo v podobě odpovědi OCSP serveru (s příponou ors). A s těmi nepočítá ani onen kreativní právní výklad (původně z roku 2010).

Pak už nejspíše neprojde ani takto „uchovaný“ ASiC kontejner s XAdES podpisy. Například takový, jaký produkují notáři při elektronické legalizaci podpisů.