ECR brána - rozhraní ECR obálka 2.0

Rozměr: px
Začít zobrazení ze stránky:

Download "ECR brána - rozhraní ECR obálka 2.0"

Transkript

1 Zhotovil: Radek Častorál Datum vzniku: Jméno souboru: ECR brána - rozhraní ECR obálka 2.0 Počet stran: 19

2 Verze dokumentu Změny 1.0 Úvodní verze určená pro implementátory. 1.1 Popis ECR obálky v kapitole 2.3 v sekci Chyba opraven do souladu s XML schématem. V dokumentu nebyl popis chyby zanořen do elementu PopisChyby a nebyly popsány některé volitelné XML uzly. V souladu s tím doplněn text kapitoly V kapitole 3.2 změněny XML příklady algoritmus podpisu SHA-1 zaměněn za SHA-256. V kapitole 4 přidány české popisy chyb. 1.3 Upraveny kapitoly a přidáno omezení těchto typů podpisu jen na XML s elementem BinarniZprava. Upravena kapitola 4 přidán chybový kód 74. Strana 2 z 19

3 Obsah 1. Úvod Komunikační zpráva ECR obálka Změny proti verzi Systém kontrol ECR obálka Element Hlavicka Element Zprava Element RozsireneInformace Element Ucastnici Datový přenášený obsah Element SmimeZprava Element XmlZprava Element BinarniZprava Element Chyba Formáty zabezpečení dat ECR obálky Šifrování Zaručený elektronický podpis Typ Enveloping Typ Enveloped, mimo zprávu, SignatureContext = envelope Typ Enveloped, mimo zprávu, SignatureContext = datacontent Typ Enveloped, uvnitř zprávy, SignatureContext = envelope Typ Enveloped, uvnitř zprávy, SignatureContext = datacontent Kombinace zaručeného elektronického podpisu a šifrování Příloha A číselník chyb odesílaných ECR bránou Strana 3 z 19

4 1. Úvod ECR brána je systém, který od roku 2002 slouží ke komunikaci celní správy s externími subjekty, převážně s deklaranty. Systém byl průběžně rozšiřován a modernizován, aby pružně reagoval na potřeby celní správy. K jeho zásadní modernizaci došlo v průběhu roku 2008 s cílem použít novou integrační platformu a aplikovat dlouholeté zkušenosti s provozem do samotného jádra ECR brány. Součástí rozšíření byly i dvě podstatné úpravy, které rozšiřují možnosti funkce směrem k deklarantům. Jednou z nich je použití moderních a standardizovaných zabezpečovacích standardů XML signature a XML encryption a druhou úprava ECR obálky tak, aby snáze splňovala různorodé potřeby zastřešovaných celních agend. Těmto dvěma změnám je věnován tento dokument. Současně ale zůstávají v platnosti všechny předchozí dokumenty vztahující se k rozhraní ECR obálky 1.5 a k zabezpečení formou SMIME podepisování a šifrování. K existujícím agendám ECR brána plně podporuje pro zpětnou kompatibilitu rozhraní 1.5, ale u nově vznikajících agend už bude vyžadováno rozhraní 2.0. Stejná pravidla platí pro využívání mechanizmů zabezpečení datových výměn. Strana 4 z 19

5 2. Komunikační zpráva ECR obálka 2.0 ECR obálka je hlavní komunikační zpráva na ECR bráně 2.0 a slouží k zapouzdřování informací o přenášené zprávě, které jsou důležité pro její správné nasměrování na serverovou aplikaci, ověření zabezpečení a pro sledování jejího toku systémem. Veškerá data určená pro průchod ECR bránou musí být do této obálky zapouzdřena. Pro všechny elementy ECR obálky 2.0 je přiřazený jmenný prostor ZMĚNY PROTI VERZI 1.5 Hlavní zpráva používaná ECR bránou byla původně navržena pro použití ve dvou vybraných režimech. Obsahuje proto některé režimově specifické údaje a na druhou stranu neumožňuje případné rozšíření o elementy využitelné v agendách nově zaváděných. V rámci změn ECR brány se ukázalo jako maximálně účelné rozvinout definici rozhraní na novou obecnější verzi. Původní ECR brána informovala o chybových stavech pomocí dvou zpráv ChybaVAN a CZ907A. Důvody pro toto dvojí informování se postupně stíraly a v nové verzi je použit již jednotný způsob vracení chyby formou oddílu v ECR obálce. Pro zpětnou kompatibilitu je zajištěno generování původních zpráv. Hlavní změny ECR obálky proti verzi 1.5 jsou následující: - Odstraněny režimově vynucené atributy (např. JmenoSouboru pro ECRFTP) a nahrazeny volnější strukturou atributů zprávy. <Zprava><Atributy><Atribut Nazev="JmenoSouboru" Hodnota="soubor"/> - Uvolněna sekce Ucastnici tak, aby mohl být počet účastníků větší než doposud podporovaní 3. <Ucastnici><Ucastnik Role="deklarant" Identifikator="05CZ " GuidScenare="" DatumCas="" AplikaceID="dd" AplikaceVerze="1.0/> - Umožněno používání XML signature. - Umožněno používání XML encryption. - Lze přidat i atributy, které nejsou v době nynějšího návrhu známy. - Přidána část pro podporu hlášení o chybě. - Původní element <Zprava> rozdělen do dvou <Hlavicka> a <Zprava> podle toho, zda se informace týkají obálky nebo přenášené zprávy SYSTÉM KONTROL Na příchozí ECR obálku jsou aplikovány kontroly specifické dle komunikační domény. Patří mezi ně zejména: - Kontrola proti XML schématu ECR obálky pro konkrétní doménu. - Logická kontrola vyplňování ECR obálky proti přenášeným datům. - Logická kontrola vyplněných údajů proti registrům komunikačních subjektů. - Rozšifrování a ověření zaručeného elektronického podpisu. Dále popsaný způsob vyplňování je obecně platný, nicméně pro jednotlivé komunikační domény může být zúžen a zpřísněn. Strana 5 z 19

6 2.3. ECR OBÁLKA 2.0 Základní přehled o možných elementech ECR obálky dává následující tabulka. Název elementu XML typ Datový typ Povinnost vyplňování směrem do ECR brány Povinnost vyplňování směrem z ECR brány Hlavicka Element Povinný [1] Povinný [1] GuidObalky Atribut UUID Povinný Povinný VerzeObalky Atribut string[10] Povinný Povinný Domena Atribut string[20] Povinný Povinný Zprava Element Povinný [1] Povinný [1] Typ Atribut string[30] Povinný Povinný HlavniID Atribut string[40] Volitelný Volitelný VedlejsiID Atribut string[40] Volitelný Volitelný Atributy Element Volitelný [1] Volitelný [1] Popis Element s informacemi o obálce. Unikátní identifikátor jednoznačně určující právě jednu instanci ECR obálky. Označení verze ECR obálky. Jméno komunikační domény (agendy), pro kterou je určena datová výměna. Element s informacemi o přenášené zprávě. Jméno přenášené zprávy, typicky je jím kořenový element obalovaného XML. Hlavní identifikátor přenášené zprávy. Vedlejší identifikátor přenášené zprávy. Seznam doplňkových atributů. Atribut Element Volitelný [1- n] Volitelný [1- n] Doplňkový atribut. Nazev Atribut string[20] Povinný Povinný Hodnota Atribut string[256] Povinný Povinný RozsireneInformace Element Volitelný [1] Volitelný [1] Název doplňkového atributu. Hodnota doplňkového atributu. Místo, kam lze uložit další dodatečné informace. Atribut Element Volitelný [1- n] Volitelný [1- n] Doplňkový atribut. Nazev Atribut string[20] Povinný Povinný Hodnota Atribut string[256] Povinný Povinný Název doplňkového atributu. Hodnota doplňkového atributu. Strana 6 z 19

7 Ucastnici Element Povinný [1] Povinný [1] Ucastnik Element Povinný [1-n] Povinný [1-n] Role Atribut string[20] Povinný Povinný Identifikator Atribut string[40] Volitelný Volitelný GuidScenare Atribut UUID Volitelný Volitelný DatumCas Atribut datetime Volitelný Volitelný AplikaceID Atribut string[50] Volitelný Volitelný AplikaceVerze Atribut string[20] Volitelný Volitelný SMIMEZprava Element string Volitelný [1] Volitelný [1] XMLZprava Element Volitelný [1] Volitelný [1] SignatureContext Atribut string[15] Volitelný [1] Volitelný [1] Data Element Volitelný [1] Volitelný [1] Seznam stran, které se účastní datové výměny (např. deklarant, VAN operátor, GŘC atd.). Komunikační strana. Role komunikační strany (deklarant, VAN, zástupce, PVS, VVAN, GRC) v předem definovaných řetězcích. Jednoznačný identifikátor komunikující strany. Označení scénáře v rámci agendy komunikující strany. Datum a čas průchodu obálky agendou komunikující strany. Označení aplikace, která se o průchod komunikující stranou stará. Označení verze aplikace, která se o průchod komunikující stranou stará. Element pro umístění přenášené zprávy v SMIME formátu. Element pro umístění přenášené zprávy v XML formátu. Výčtový typ určující rozsah prováděného zaručeného elektronického podpisu. Může nabývat hodnot "envelope" (výchozí hodnota) a "datacontent". Element obsahuje XML data v otevřeném tvaru. Strana 7 z 19

8 EncryptedData Element Volitelný [1] Volitelný [1] Signature Element Volitelný [1] Volitelný [1] BinarníZprava Element Volitelný [1] Volitelný [1] SignatureContext Atribut string[15] Volitelný [1] Volitelný [1] Data Element string Volitelný [1] Volitelný [1] EncryptedData Element Volitelný [1] Volitelný [1] Signature Element Volitelný [1] Volitelný [1] Chyba Element Nesmí být Volitelný [1] PopisChyby Element obsahuje XML data v šifrovaném tvaru dle doporučení W3C - XML encryption. Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature. Element pro umístění přenášené binární zprávy kódované jako base64 Výčtový typ určující rozsah prováděného zaručeného elektronického podpisu. Může nabývat hodnot "envelope" (výchozí hodnota) a "datacontent". Element obsahuje binární data v kódování base64. Element obsahuje binární data v šifrovaném tvaru dle doporučení W3C - XML encryption. Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature. Pokud při zpracování došlo k chybě, budou zde umístěny příslušné informace. Kod Atribut int Nesmí být Povinný Číselný kód chyby. GuidPuvodniObalky Atribut UUID Nesmí být Volitelný TypChyby Atribut string[20] Nesmí být Povinný Obsahuje GUID původní obálky, ke které se chyba vztahuje, pokud jí je možné načíst. Označení typu chyby, resp. zdroje chyby. Popis Atribut string[256] Nesmí být Volitelný Popis chyby. Data Element string Nesmí být Volitelný [1] Pokud je to k popisu chyby nutné, jsou zde uvedena data chyby. Strana 8 z 19

9 Signature Element Nesmí být Volitelný [1] Umístění informací o elektronickém podpisu dle doporučení W3C - XML signature pro element hlášené chyby Element Hlavicka Tento element je povinný a obsahuje hlavní informace o agendě a datové výměně. Každá instance ECR obálky musí mít vygenerovaný unikátní GUID (UUID) identifikátor v atributu GuidObalky, uvedenou komunikační doménu v atributu Domena a uvedenou identifikaci verze obálky, což je v současné době konstanta 2.0 v atributu VerzeObalky Element Zprava Tento povinný element zapouzdřuje informace o konkrétní přenášené zprávě nebo datové výměně. Udává se Typ datové výměny, což je u XML komunikací zpravidla jméno kořenového elementu přenášené zprávy. Dále se uvádí volitelně až dva identifikátory z přenášené zprávy, které mohou mít význam pro směrování zprávy. Způsob vyplňování elementů HlavniID a VedlesiID je určen doménou a typem výměny, nicméně ve většině domén se požaduje uvedený alespoň jeden z těchto identifikátorů. V některých případech je nutné uvádět v obálce ještě další atributy a pro ně je určena volitelná struktura Atributy/Atribut Element RozsireneInformace Tento nepovinný element je v současné době nepoužíván a rezervován pro případná rozšíření ECR obálky v budoucích doménách Element Ucastnici Povinný element obsahuje informace o všech zúčastněných komunikačních partnerech. Každý zúčastněný komunikační partner musí pro průchodu zprávy jeho systémem přidat jeden podelement Ucastník a uvést svoji roli do atributu Role, svoji identifikaci do atributu Identifikator, datum a čas průchodu zprávy jeho systémem do atributu DatumCas a informace o programovém modulu, který obálku zpracovával, do atributů AplikaceID a AplikaceVerze. Tři nejčastější současné role jsou deklarant (vyplní deklarant, resp. jeho SW), operator (vyplní např. VAN operátor) a grc (vyplní ECR brána). Dále se dle komunikačních mechanizmů mohou vyskytnout i role vvan a pvs. Všechny role kromě grc musí povinně vyplnit všech 5 atributů kromě volitelného GuidScenare, což je GUID, u něhož ECR brána zaručuje, že ho v nezměněné podobě vrátí v odpovědi ve stejné sekci. ECR brána vyplňuje pouze roli a datum a čas a volitelně dle domény identifikaci scénáře. V odpovědi ECR brány se všechny sekce vracejí, neuvádí se však u nich zpravidla již informace o programovém modulu. Strana 9 z 19

10 Datový přenášený obsah Příchozí ECR obálka musí obsahovat právě jeden z elementů SmimeZprava, XmlZprava nebo BinarniZprava. V těchto elementech je samotný přenášený datový obsah ELEMENT SMIMEZPRAVA Je udržován pro zpětnou kompatibilitu a obsahuje stejný obsah jako v případě starší ECR obálky 1.5. Pro nové domény již není tento způsob komunikace podporován ELEMENT XMLZPRAVA Element se uvede, mají-li přenášená data formát XML. Ta jsou pak přímo vložena jako podelement elementu Data. Zde je důležité je oddělit jiným jmenným prostorem nebo uvedením prázdného, aby nebyla interpretována v kontextu jmenného prostoru ECR obálky. Mají-li být data šifrována, umístí se do struktury XML encryption do elementu EncryptedData. Do elementu Signature je možné uvést zaručený elektronický podpis. Obsah elementů EncryptedData a Signature je určen doporučeními W3C a popsán v kapitole ELEMENT BINARNIZPRAVA Element se uvede, mají-li přenášená data binární nebo jinou než XML povahu. Ta jsou pak přímo zakódovaná v base64 jako textová hodnota elementu Data. Mají-li být data šifrována, umístí se do struktury XML encryption do elementu EncryptedData. Do elementu Signature je možné uvést zaručený elektronický podpis. Obsah elementů EncryptedData a Signature je určen doporučeními W3C a popsán v kapitole Element Chyba Tento element nesmí být uveden v příchozí zprávě. Je vždy generován ECR bránou a informuje o některém z problémů, ke kterým může při příjmu, ověřování a kontrole zprávy dojít. Odpovídá-li ECR brána zprávou ECR obálka 2.0 s uvedeným elementem Chyba, není uveden žádný z datových elementů z kapitoly Element má vždy na svém podelementu PopisChyby uveden číselný Kod chyby a její zdroj TypChyby. Volitelně může být přítomen atribut GuidPuvodniObalky, jenž odkazuje na identifikaci ECR obálky, k níž je chyba hlášena. Rovněž volitelně je obsažen Popis chyby a u některých chyb i další doprovodná informace v podobě chybných dat v textovém elementu Data. U agend, které vyžadují opatření chybových zpráv zaručenou elektronickou značkou (chyba je právně závaznou zprávou), je tato značka přítomna v elementu Signature a strukturou odpovídá kapitole Seznam chyb, které může ECR brána aktuálně vracet, je uveden v kapitole 4. Strana 10 z 19

11 3. Formáty zabezpečení dat ECR obálky 3.1. ŠIFROVÁNÍ Šifrování v ECR obálce se plně řídí doporučením W3C XML Encryption ( Je-li datový obsah šifrován, použije se jako vstup pro XML encryption element Data. Ten je následně nahrazen elementem EncryptedData už ve jmenném prostoru příslušného W3C doporučení. Příklad použitého šifrování je na následujícím zkráceném XML fragmentu: <XmlZprava> <EncryptedData Type=" xmlns=" <EncryptionMethod Algorithm=" /> <KeyInfo xmlns=" <EncryptedKey xmlns=" <EncryptionMethod Algorithm=" /> <KeyInfo xmlns=" <X509Data> <X509IssuerSerial> <X509IssuerName>CN=VM-BTS CA, OU=Technologie, O=Aquasoft s.r.o., L=Prague, S=Czech Republic, C=CZ</X509IssuerName> <X509SerialNumber> </X509SerialNumber> </X509IssuerSerial> </X509Data> </KeyInfo> <CipherData> <CipherValue>RkSilm7TlI2Nzc+Y+OVm+2KT0WoQtB7wky+aAtfowWxecq+9jV/huXTQ80DdMhT9OOvuE h1uja1oa1norrzsta==</ciphervalue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>Yg82r6P+QvWTYhujTR0NWm4AoRvbXEi6Oc6pTw+4zFM3c0MeAhZ+. AD7GHNDIgMPVS6fqfwkUifoEgJgmJFrVEcc27I3fQvYj7p5Z99iOV7GaYVVJes+GrO/UbaIQ==</Cipher Value> </CipherData> </EncryptedData> </XmlZprava> Strana 11 z 19

12 3.2. ZARUČENÝ ELEKTRONICKÝ PODPIS Zaručený elektronický podpis se v ECR obálce plně řídí doporučením W3C XML Signature ( Použití zaručeného elektronického podpisu nad otevřeným XML přináší jako výhodu fakt, že - pokud nejsou šifrována jsou data čitelná. To usnadňuje případné dohledávání problémů. Při používání XML signature je nutné mít na paměti zejména následující fakta: 1) Je vždy nutné provést kánonizaci XML a uvést ji ve struktuře podpisu. 2) Předmětem podpisu je vždy element SignatureInfo, který obsahuje miniaturu (SHA2 hash) podepisovaného dokumentu. 3) Znaky typu mezera, tabulátor a formátování konce řádku jsou pro XML signature významnými znaky, kanonizace je neodstraňuje a jejich změna vede na porušení podpisu. Mezi procesem podepsání zprávy a ověření podpisu tedy nesmí dojít například k přeformátování XML. 4) Pojmenování jmenných prostorů a jejich hodnoty jsou pro XML signature významnými znaky, kánonizace s nimi nijak nepracuje a nesmí být měněny. Je také nutné vést v patrnosti, že přidání pojmenovaného jmenného prostoru se promítne v DOM reprezentaci do všech podřízených, které tento jmenný prostor zdědí, a to může narušit podpis, přestože nadřazený element nebyl předmětem podpisu. V ECR bráně je vždy předlohou pro výpočet miniatury samotná přenášená zpráva uvnitř elementu Data, nikoliv element Data samotný. Součástí zaručeného elektronického podpisu musí být i veřejná část certifikátu použitelná pro ověření. Z pohledu doporučení W3C podporuje ECR brána následující typy XML signature: Typ Enveloping Tento typ znamená, že přenášená zpráva není umístěna jako potomek elementu Data (ten zůstává prázdný), ale je obsažena přímo jako definovaný objekt uvnitř struktury Signature, která je potomkem elementu XmlZprava nebo BinarniZprava. Při tomto použití nemusí být předepsána žádná transformace, ale výsledek nelze šifrovat, protože došlo v přemístění dat. Příklad uvádí následující fragment: <XmlZprava> <Data /> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" /> <SignatureMethod Algorithm=" /> <Reference URI="#dataID"> <DigestMethod Algorithm=" /> <DigestValue>CChHPUGq/0VpQvZ4oTQTJQkv3a/mLuXGiQ6ieAcsS8Y=</DigestValue> </Reference> Strana 12 z 19

13 </SignedInfo> <SignatureValue>SUxkLyHkuiYi/im23PgdVt1NipupFHOvntkGr6ohjeW7AHCShPBA+8FJNPNC8mOHO8f FAdatQyntj59XBF7WEU6gYbcomhhTDpeXz3ZZU2jEC1v5Ji5wslHt9pUnb5BpYxXn8fUxlnbGU8H27PW nx/g6zo0ouy7w/fkldapwf81p/iwq4es31awyewuqgyc34fcbcvsuidfl2hd0rvg56czloqg4nkclefl ATNzU4KAujiquj0U4/DKUk40Fmidu/Mai8XYyGGToLpa0v3gfeL59p++h1kliIOEfzf1BwDZBgGkfGVySjG OOhA95kBDUgciiaj2Yxm3TYphokri+jg==</SignatureValue> <KeyInfo> <X509Data> <X509Certificate>MIIEPTCCA..+m2BYA21</X509Certificate> </X509Data> </KeyInfo> <Object Id="dataID"> <CZ384A xmlns=""> <AOSD> <AOSD01>08CZ JZUV4J2D17</AOSD01> </AOSD> </CZ384A> </Object> </Signature> </XmlZprava> Typ Enveloped, mimo zprávu, SignatureContext = envelope Tento typ znamená, že je podpis vytvořen v kontextu celé ECR obálky (v době podpisu již byla sestavena) a element Signature je umístěn jako potomek elementu XmlZprava nebo BinarniZprava. Vždy musí být uvedena transformace enveloped-signature a xpath, která určuje cestu k podepisovaným datům. Vzhledem k tomu, že použití xpath transformace je pro XML zprávy se složitější strukturou velmi výpočetně náročné, je tento typ podpisu striktně omezen jen na typ ECR obálky s elementem BinarniZprava. <BinarniZprava> <Data> </Data> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" <SignatureMethod Algorithm=" <Reference URI=""> <Transforms> <Transform Algorithm=" <Transform Algorithm=" Strana 13 z 19

14 <XPath xmlns:transns=" =.] </XPath> </Transform> </Transforms> <DigestMethod Algorithm=" <DigestValue>uES8qbp0Fejuq9JbOpyl1ik7xDQ23NNIWhR0McWUlyU=</DigestValue> </Reference> </SignedInfo> <SignatureValue> </SignatureValue> <KeyInfo> <X509Data> <X509Certificate> <X509Certificate> </X509Data> </KeyInfo> </Signature> </BinarniZprava> Typ Enveloped, mimo zprávu, SignatureContext = datacontent Princip tohoto podpisu je stejný jako v případě s tím rozdílem, že při podpis vznikl nad přenášenou zprávou, která nebyla ještě vložena do ECR obálky. Stejný postup se pak musí aplikovat při ověřování podpisu. Protože toto není výchozí nastavení atributu SignatureContent, musí být na elementu XmlZpráva uveden. <XmlZprava SignatureContext="datacontent"> </XmlZprava> Stejně jako u platí restrikce pouze na použití s elementem BinarniZprava Typ Enveloped, uvnitř zprávy, SignatureContext = envelope Tento typ znamená, že je podpis vytvořen v kontextu celé ECR obálky (v době podpisu již byla sestavena) a element Signature je umístěn jako potomek kořenového elementu podepisované zprávy. Vždy musí být uvedena transformace enveloped-signature. <XmlZprava> <Data> <CZ384A xmlns=""> <AOSD> <AOSD01>08CZ JZUV4J2D17</AOSD01> </AOSD> <Signature xmlns=" <SignedInfo> <CanonicalizationMethod Algorithm=" /> <SignatureMethod Algorithm=" /> Strana 14 z 19

15 <Reference URI=""> <Transforms> <Transform Algorithm=" /> </Transforms> <DigestMethod Algorithm=" /> <DigestValue>l8Xr8bXjaWCzqLY/nr8pRmlVxISa1T92onqlArTfm1A=</DigestValue> </Reference> </SignedInfo> <KeyInfo> <SignatureValue>UoaZzySMllvx3O9EY4GS/7XmyNHQSh4mQoWIOFmu7cOz6z7tdslpqHTckRp1qzTByH x8tkawx4qtqfdk3a9whviy614bxejnzu96npjy9wi6xygreo2lzqslqffrftndeqfxz9hkgawaau5tf8v CnsWyHamPDKBXhphU3PDcZmcJfmeItWh9d8z7RAlH3yXVSJ51BLyQ36qEQatPuyyTDarzCL1qBKMC/2 uuzwgfcgb5qgufdjtpcumgx7wgx2jsfkgkwbytgf9z8b0n4zgiexr4uustlqod7nysqv/zm407einq1b jizmne3lw6l2zcarprdqskxhzckdicxavmxw==</signaturevalue> <X509Data> <X509Certificate>MIIEPTCCAA..+m2BYA21</X509Certificate> </X509Data> </KeyInfo> </Signature> </CZ384A> </Data> </XmlZprava> Typ Enveloped, uvnitř zprávy, SignatureContext = datacontent Princip tohoto podpisu je stejný jako v případě s tím rozdílem, že při podpis vznikl nad přenášenou zprávou, která nebyla ještě vložena do ECR obálky. Stejný postup se pak musí aplikovat při ověřování podpisu. Protože toto není výchozí nastavení atributu SignatureContent, musí být na elementu XmlZpráva uveden. <XmlZprava SignatureContext="datacontent"> </XmlZprava> 3.3. KOMBINACE ZARUČENÉHO ELEKTRONICKÉHO PODPISU A ŠIFROVÁNÍ Při kombinaci obou zabezpečení se nejprve provede vytvoření zaručeného elektronického podpisu a následně se provede šifrování elementu Data. V tomto případě nelze použít typ XML Signature popsaný v kapitole 3.2.1, protože by data uvnitř elementu Signature ve výsledku nebyla zašifrována. Při zpracování příchozí zprávy se postupuje obráceně, nejprve se dešifruje a u výsledku ověří podpis. Strana 15 z 19

16 Strana 16 z 19

17 4. Příloha A číselník chyb odesílaných ECR bránou Kód Text chyby (anglicky) Popis chyby Invalid incoming XML Neplatné příchozí XML (zpráva není XML nebo neodpovídá schématu ECR obálka 2.0). Internal server error Vnitřní (blíže neurčená) chyba serveru. Invalid incoming XML message type Neznámý typ zprávy v příchozím XML. Message domain is not valid Doména uvedená v ECR obálce není známa. ID for declarant is unknown ID deklaranta není známo. Nejčastější příčinou tohoto stavu je, že deklarant nemá správně nastavené komunikační parametry v systému ZJP (např. ZJP obsahuje neplatný certifikát). VAN operator $ is not allowed for domain $ VAN operátor nemá povoleno posílat zprávy do této domény. At least primary or secondary identifier have to be filled in V ECR obálce je nutno uvést alespoň jeden identifikátor (primární nebo sekundární). Message $ is not allowed to pass through in the domain $ Zprávu daného typu nelze poslat do této domény. Load from MIME failed in the $ phase. Chyba při dekódování zprávy z formátu MIME zpráva nemá korektní MIME formát. Decrypt SMIME/XML failed with: $ Chyba při dešifrování zprávy ve formátu SMIME nebo XML Encryption. Verify sign SMIME/XML failed due to an incorrect sign format with: $ Chyba při ověření zprávy ve formátu SMIME nebo XML Signature. Verify sign SMIME/XML failed due to message changes Chyba při ověření zprávy ve formátu SMIME nebo XML Signature: zpráva byla po podpisu modifikována. Verify sign SMIME/XML failed due to the incorrect certificate chain or certificate revocation. Certificate number: $ Chyba při ověření podpisu zprávy. Certifikát použitý pro podpis je neplatný (nedůvěryhodný certifikát; certifikát, jemuž ještě nezačala/skončila platnost; certifikát je uveden v seznamu odvolaných certifikátů; ). Verify sign SMIME/XML failed due to the unauthorized certificate. Certificate number: $ Chyba při ověření podpisu zprávy. Certifikát použitý pro podpis není uveden v systému ZJP. Strana 17 z 19

18 Decoding base64 in MIME failed in the $ phase Chyba při dekódování base64 formátu SMIME zprávy - zpráva neobsahuje platný řetězec ve formátu base64. Incorrect data security found: $ Neplatné zabezpečení dat. Tato chyba vzniká například pokud je zaslaná zpráva pouze digitálně podepsána, ale pro tento druh komunikace je vyžadováno i šifrování zprávy. Více viz podrobnosti chyby. Incorrect data security found: MPSV identifier expected in sign certificate Neplatné zabezpečení dat. Certifikát použitý pro podepsání zprávy neobsahuje MPSV identifikátor, ačkoliv je pro danou doménu vyžadován. Strong RSA key (2048bit) and SHA2 digest required Je vyžadován podpis zprávy algoritmem rodiny SHA2 za použití certifikátu s minimální délkou klíče 2048 bitů. Invalid certificate asymmetric algorithm: $ Certifikát, jímž byla zpráva podepsána, používá nepovolený asymetrický algoritmus. Povolené algoritmy jsou RSA a DSA. Invalid certificate signature algorithm: $ Certifikát, jímž byla zpráva podepsána, byl certifikační autoritou podepsán nepovoleným algoritmem. Povolené algoritmy jsou SHA-256, SHA-384 a SHA-512. Cannot write binary data from SMIME to envelope Obsah binární zprávy zaslané pomocí SMIME formátu nelze po dešifrování/ověření podpisu zapsat do elementu BinarníZprava ECR obálky. Cannot write XML data from SMIME to envelope Obsah zprávy zaslaný ve formátu SMIME nelze po dešifrování/ověření podpisu transformovat do elementu Data ECR obálky. Nejčastější příčinou je neplatný formát XML obsaženého v SMIME zprávě nebo toto XML obsahuje znak neplatný pro kódování uvedené v XML deklaraci přenášené zprávy. Envelope is neither binary or xml ECR obálka neobsahuje ani element BinarniZprava ani element XmlZprava. XML schema general validation error Zaslané XML neodpovídá schématu EcrObalka 2.0. Invalid child element Element zaslané ECR obálky obsahuje nedovolený podelement. Incomplete content Element zaslané ECR obálky neobsahuje povinný podelement nebo atribut. Value too short Hodnota daného atributu v zaslané ECR obálce je příliš krátká. Value too long Hodnota daného atributu v zaslané ECR obálce je příliš dlouhá. Invalid datatype Hodnota daného atributu v zaslané ECR obálce je nesprávného typu. Strana 18 z 19

19 Pattern constraint failed Hodnota daného atributu v zaslané ECR obálce neodpovídá vzoru definovanému pro tento atribut. Attribute missing V zaslané ECR obálce chybí povinný atribut. Primary identifier is not equal to inner message Primární identifikátor v ECR obálce (HlavniID) neobsahuje stejnou hodnotu jako primární identifikátor v zaslané zprávě. Secondary identifier is not equal to inner message Sekundární identifikátor uvedený v ECR obálce (VedlejsiID) neobsahuje stejnou hodnotu jako sekundární identifikátor v zaslané zprávě. Message type is not equal to inner message Typ zprávy uvedený v ECR obálce není roven názvu kořenového elementu přenášené zprávy. Unable to perform inner XML controls in order to incomplete inner message Nelze provést kontrolu na shodu primárních nebo sekundárních identifikátorů v ECR obálce a v přenášené zprávě z důvodu nekompletní přenášené zprávy. Invalid use of XPath transformation XPath transformace není v tomto případě povolena (její použití je povoleno jen s elementem BinarniZprava) Strana 19 z 19

ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0. Verze dokumentu: 1.1 Datum vzniku: Počet stran: 16

ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0. Verze dokumentu: 1.1 Datum vzniku: Počet stran: 16 ECR BRÁNA - ROZHRANÍ ECR OBÁLKA 2.0 Zhotovil: Častorál Radek Verze dokumentu: 1.1 Datum vzniku: 18.8.2009 Počet stran: 16 Verze dokumentu Změny 1.0 Úvodní verze určená pro implementátory 1.1 Popis ECR

Více

Specifikace integračního rozhraní

Specifikace integračního rozhraní C E R T I C O N www.certicon.cz E V R O P S K Á 1 1, 1 6 0 0 0 P R A H A 6, CZ Specifikace integračního rozhraní aplikace ORO web klient Jan Chroustovský, Martin Falc, Kamil Matoušek Zadavatel: Generální

Více

Zabezpečená middleware komunikace

Zabezpečená middleware komunikace České vysoké učení technické v Praze F a k u l t a e l e k t r o t e c h n i c k á Zabezpečená middleware komunikace autor: František Hlavan vedoucí práce: Ing. Jan Kubr Katedra počítačů leden 211 Cíle

Více

XML Signatures. Autor

XML Signatures. Autor XML Signatures Autor Martin Lasoň Abstrakt Digitální podpisy zajišťují integritu, autenticitu a nepopiratelnost dat na Webu. Takové rysy jsou zvlášť důležité pro dokumenty, které reprezentují závazky jako

Více

Integrovaný informační systém Státní pokladny (IISSP) Dokumentace API - integrační dokumentace

Integrovaný informační systém Státní pokladny (IISSP) Dokumentace API - integrační dokumentace Česká republika Vlastník: Logica Czech Republic s.r.o. Page 1 of 10 Česká republika Obsah 1. Úvod...3 2. Východiska a postupy...4 2.1 Způsob dešifrování a ověření sady přístupových údajů...4 2.2 Způsob

Více

Další XML technologie

Další XML technologie XML teorie a praxe značkovacích jazyků (4IZ238) Jirka Kosek Poslední modifikace: $Date: 2012/05/17 18:58:55 $ Obsah Odkazy... 3 Odkazy v rámci jednoho dokumentu... 4 XLink (XML Linking Language)... 5 XLink

Více

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt.

Specifikace rozhraní. Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů. Martin Falc, SW architekt. C E R T I C O N www.certicon.cz V Á C L A V S K Á 1 2 1 2 0 0 0 P R A H A 2 Specifikace rozhraní Oznamovací povinnost podle zákona č. 307/2013 Sb., ve znění pozdějších předpisů Martin Falc, SW architekt

Více

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5

Funkční specifikace ABOKWS. Aplikační rozhraní elektronického bankovnictví ABO-K. Verze 0.5 Funkční specifikace ABOKWS Aplikační rozhraní elektronického bankovnictví ABO-K Verze 0.5 Přehled změn Verze Datum Změnil Popis 0.1 26.2.2013 MB Úvod, Osnova dokumentu, funkce ABOKWS 0.2 18.4.2014 MB Tabulky

Více

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz

Asymetrická kryptografie a elektronický podpis. Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Asymetrická kryptografie a elektronický podpis Ing. Mgr. Martin Henzl Mgr. Radim Janča ijanca@fit.vutbr.cz Obsah cvičení Asymetrická, symetrická a hybridní kryptografie Matematické problémy, na kterých

Více

Vykazování dat o poskytovaných sociálních službách

Vykazování dat o poskytovaných sociálních službách Vykazování dat o poskytovaných sociálních službách (verze dokumentu 1.4) Odpovědná osoba: Ing. Radomír Martinka V Praze dne: 24.4.2014 Klasifikace: CHRÁNĚNÉ OKsystem s.r.o. Na Pankráci 125, 140 21 Praha

Více

Projekt 2 - Nejčastější chyby. Ing. Dominik Breitenbacher

Projekt 2 - Nejčastější chyby. Ing. Dominik Breitenbacher Projekt 2 - Nejčastější chyby Ing. Dominik Breitenbacher ibreiten@fit.vutbr.cz Projekt 2 - Nejčastější chyby Překlepy a interpunkce Estetika Kvalita obrázků Zdrojové kódy v textu Text nebyl rozdělen na

Více

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Praha, Štěpánská 28 15. 1. 2018 Základní informace o projektu Gabriela Čížková, SPCSS Kritické chyby Propustné chyby Pravidla a doporučené

Více

Vykazování dat o poskytovaných sociálních službách

Vykazování dat o poskytovaných sociálních službách Vykazování dat o poskytovaných sociálních službách (verze dokumentu 1.2) Odpovědná osoba: Ing. Radomír Martinka V Praze dne: 18.4.2011 Klasifikace: CHRÁNĚNÉ OKsystem s.r.o. Na Pankráci 125, 140 21 Praha

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.0 Vydání certifikátu pro AIS Aby mohl AIS volat egon služby ISZR, musí mít povolen přístup k vnějšímu rozhraní ISZR. Přístup povoluje SZR na žádost OVM, který je správcem

Více

Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy

Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/ Digitální podpisy VY_32_INOVACE_BEZP_08 Projekt: 1.5, Registrační číslo: CZ.1.07/1.5.00/34.0304 Digitální podpisy Základní myšlenkou elektronického podpisu je obdoba klasického podpisu, jež má zaručit jednoznačnou identifikaci

Více

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML

2 PŘÍKLAD IMPORTU ZATÍŽENÍ Z XML ROZHRANÍ ESA XML Ing. Richard Vondráček SCIA CZ, s. r. o., Thákurova 3, 160 00 Praha 6 www.scia.cz 1 OTEVŘENÝ FORMÁT Jednou z mnoha užitečných vlastností programu ESA PT je podpora otevřeného rozhraní

Více

Robert Hernady, Regional Solution Architect, Microsoft

Robert Hernady, Regional Solution Architect, Microsoft Robert Hernady, Regional Solution Architect, Microsoft Agenda prezentace Seznámení s problematikou Principy elektronického podpisu Certifikáty Co je třeba změnit pro využití algoritmů SHA-2 Shrnutí nutných

Více

Vybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu

Vybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu Vybrané technické informace pro předávání účetních záznamů do centrálního systému účetních informací státu verze k 30.10.2009 1 OBSAH: A. Datové prvky a jejich struktura...4 Komunikační obálka...4 Význam

Více

A. Datové prvky a jejich struktura... 5. Identifikátory... 6. Identifikace ÚJ... 6. Identifikace ZO... 6. Identifikace CSÚIS... 6. Záhlaví...

A. Datové prvky a jejich struktura... 5. Identifikátory... 6. Identifikace ÚJ... 6. Identifikace ZO... 6. Identifikace CSÚIS... 6. Záhlaví... Technický manuál (Pracovní verze k 10.12.2009) Slovník pojmů... 5 A. Datové prvky a jejich struktura... 5 Struktura komunikační obálky... 6 Identifikátory... 6 Identifikátor přenosu... 6 Identifikace ÚJ...

Více

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci

l Kontakt s klientem SSP Popis automatizované komunikace s ÚP ČR v součinnosti a exekuci l Kontakt s klientem SSP automatizované komunikace s ÚP ČR v součinnosti a exekuci Obsah: 1. SEZNAM POUŽITÝCH ZKRATEK... 3 2. POPIS SLUŽBY... 4 2.1 Forma a struktura rozhraní... 4 2.2 Dostupnost služby...

Více

ISDOC 6.0.1 Národní standard pro elektronickou fakturaci

ISDOC 6.0.1 Národní standard pro elektronickou fakturaci Národní standard pro elektronickou fakturaci 26. května 2014 1. Úvod... 1 1.1. Konvence... 1 2. Shoda se standardem... 2 2.1. Typy dokumentů ISDOC... 2 2.2. Dokument ISDOC... 2 2.3. Konzument ISDOC...

Více

Popis egon služby. E04 - robautentizace. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Popis egon služby. E04 - robautentizace. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů Popis egon služby E04 - robautentizace Název dokumentu: Autor: Popis egon služeb Verze: 01.00 Datum aktualizace: 25. 12. 2016 Účel: Popis egon služeb v rámci základních registrů Počet stran: 9 Obsah 1

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.12 Vydávání certifikátů pro AIS pro produkční prostředí ISZR se řídí Certifikační politikou SZR pro certifikáty vydávané pro AIS uveřejněnou na webu SZR. Tento dokument

Více

[1] ICAReNewZEP v1.2 Uživatelská příručka

[1] ICAReNewZEP v1.2 Uživatelská příručka [1] ICAReNewZEP v1.2 Uživatelská příručka 06.10.2011 [2] Obsah 1 - ÚVOD... 3 2 - POUŽITÉ ZKRATKY... 3 3 POŽADAVKY... 4 3.1 POŽADAVKY PRO SPRÁVNÝ CHOD APLIKACE... 4 3.2 POŽADAVKY NA OBNOVOVANÝ CERTIFIKÁT...

Více

API pro volání služby kurzovního lístku KB

API pro volání služby kurzovního lístku KB OBSAH API pro volání služby Kurzovní lístek KB... 2 Poskytované informace... 2 Informace pro volání resource exchange-rates... 3 Příklady request / response z volání služby kurzovního lístku... 5 Způsoby

Více

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007

Kryptografie, elektronický podpis. Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptografie, elektronický podpis Ing. Miloslav Hub, Ph.D. 27. listopadu 2007 Kryptologie Kryptologie věda o šifrování, dělí se: Kryptografie nauka o metodách utajování smyslu zpráv převodem do podoby,

Více

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce

Elektronický podpis. Základní princip. Digitální podpis. Podpis vs. šifrování. Hashování. Jednosměrné funkce. Odesílatel. Příjemce Základní princip Elektronický podpis Odesílatel podepíše otevřený text vznikne digitálně podepsaný text Příjemce ověří zda podpis patří odesílateli uvěří v pravost podpisu ověří zda podpis a text k sobě

Více

Certifikační autorita EET. Veřejný souhrn certifikační politiky

Certifikační autorita EET. Veřejný souhrn certifikační politiky Certifikační autorita EET Veřejný souhrn certifikační politiky Verze 1.0, 1.9.2016 Vymezení obsahu dokumentu Tento dokument obsahuje informace o zásadách a postupech činnosti Certifikační autority EET,

Více

Popis B2B rozhraní pro elektronickou neschopenku

Popis B2B rozhraní pro elektronickou neschopenku Popis B2B rozhraní pro elektronickou neschopenku Historie dokumentu Verze Datum Změny 0.9 30. 4. 2019 Vytvoření dokumentu Obsah 1 Účel dokumentu... 3 2 Charakteristika rozhraní... 3 2.1 Způsob komunikace...

Více

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2

Obsah. Úroveň I - Přehled. Úroveň II - Principy. Kapitola 1. Kapitola 2 Úroveň I - Přehled Úroveň II - Principy Kapitola 1 Kapitola 2 1. Základní pojmy a souvislosti 27 1.1 Zpráva vs. dokument 27 1.2 Písemná, listinná a elektronická podoba dokumentu 27 1.3 Podpis, elektronický

Více

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S.

PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S. PODMÍNKY POSKYTOVÁNÍ PŘÍSTUPU K PORTÁLU NAMĚŘENÝCH DAT POMOCÍ WEBOVÝCH SLUŽEB SPOLEČNOSTI ČEZ DISTRIBUCE, A. S. 1 ÚVOD... 5 2 POPIS VÝMĚNY DAT... 6 2.1 KOMUNIKAČNÍ SCÉNÁŘE... 6 2.2 TECHNOLOGIE KOMUNIKACE...

Více

SPINEL. Komunikační protokol. Obecný popis. Verze 1.0

SPINEL. Komunikační protokol. Obecný popis. Verze 1.0 SPINEL Komunikační protokol Obecný popis Verze 1.0 OBSAH Obsah... 2 OBECNÝ POPIS PROTOKOLU SPINEL... 3 Obecný formát rámce pro ASCII kódování... 3 Obecný formát dat pro binární kódování... 3 Definované

Více

XML a bezpečnost. Dagmar BRECHLEROVÁ. KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz

XML a bezpečnost. Dagmar BRECHLEROVÁ. KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz XML a bezpečnost Dagmar BRECHLEROVÁ KIT PEF ČZU a EUROMISE, Praha Dagmar.Brechlerova@seznam.cz INFORUM 2006: 12. konference o profesionálních informačních zdrojích Praha, 23. - 25.5. 2006 Abstrakt. Webové

Více

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Praha, 16. 12. 2016 Základní Agenda informace semináře o projektu Zkušenosti z příjmu tržeb v pilotním i ostrém provozu Součty, tržby

Více

Komunikace MED. Popis komunikačního rozhraní s externími evidencemi. Autor analýzy: Zadavatel: Generální ředitelství cel. 140 96 Praha 4. ver.: 01.

Komunikace MED. Popis komunikačního rozhraní s externími evidencemi. Autor analýzy: Zadavatel: Generální ředitelství cel. 140 96 Praha 4. ver.: 01. Komunikace MED Popis komunikačního rozhraní s externími evidencemi ver.: 01.020 Autor analýzy: TranSoft a.s Vrbenská 2082 370 21 České Budějovice Zadavatel: Generální ředitelství cel Budějovická 7 140

Více

496/2004 Sb. VYHLÁŠKA Ministerstva informatiky ze dne 29. července 2004 o elektronických podatelnách

496/2004 Sb. VYHLÁŠKA Ministerstva informatiky ze dne 29. července 2004 o elektronických podatelnách 496/2004 Sb. VYHLÁŠKA Ministerstva informatiky ze dne 29. července 2004 o elektronických podatelnách Ministerstvo informatiky stanoví podle 20 odst. 4 zákona č. 227/2000 Sb., o elektronickém podpisu a

Více

Postup při registraci (autentizaci) OVM do informačního systému evidence přestupků (ISEP)

Postup při registraci (autentizaci) OVM do informačního systému evidence přestupků (ISEP) Postup při registraci (autentizaci) OVM do informačního systému evidence přestupků (ISEP) 0 K využívání webových služeb pro komunikaci s informačním systémem evidence přestupků (ISEP) Rejstříku trestů

Více

KVALIFIKOVANÉ CERTIFIKÁTY

KVALIFIKOVANÉ CERTIFIKÁTY Ondřej Ševeček PM Windows Server GOPAS a.s. MCM: Directory Services MVP: Enterprise Security ondrej@sevecek.com www.sevecek.com KVALIFIKOVANÉ CERTIFIKÁTY Slovníček Česky veřejný / soukromý klíč otisk podepsat

Více

České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů. Digitální důvěra. Jiří Smítka

České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů. Digitální důvěra. Jiří Smítka České vysoké učení technické v Praze FAKULTA INFORMAČNÍCH TECHNOLOGIÍ katedra počítačových systémů Digitální důvěra Jiří Smítka jiri.smitka@fit.cvut.cz 14.2.2011 1/17 Náplň přednášek Rychlé opakování pojmů

Více

JSON API pro zjišťování cen MtG karet

JSON API pro zjišťování cen MtG karet JSON API pro zjišťování cen MtG karet Autor: Ing. Jiří Bažant Verze: 1.0 Datum: 20.9.2014 Changelog Verze Datum Autor Poznámka 1.0 17.9.2014 Ing. Jiří Bažant 20.9.2014 Ing. Jiří Bažant Oprava příkladu

Více

Digitální podepisování pomocí asymetrické kryptografie

Digitální podepisování pomocí asymetrické kryptografie Digitální podepisování pomocí asymetrické kryptografie 11. dubna 2011 Trocha historie Asymetrické metody Historie Historie Vlastnosti Asymetrické šifrování 1976 Whitfield Diffie a Martin Hellman první

Více

Technický manuál Centrálního systému účetních informací státu

Technický manuál Centrálního systému účetních informací státu Integrovaný informační systém Státní pokladny (IISSP) Technický manuál Centrálního systému účetních informací státu Technické informace pro práci s Centrálním systémem účetních informací státu Obsah 1

Více

Výměnný formát XML DTM DMVS PK

Výměnný formát XML DTM DMVS PK Výměnný formát XML DTM DMVS PK Představení partnerským krajům Praha 8. 2. 2016 Krajský úřad Plzeňského kraje Odbor informatiky Koncept etapizace tvorby výměnného formátu XML aktualizačních zakázek Digitální

Více

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje:

Chybová hlášení METODIKA MET-01/2014. SZR-56-1/OPICT-2013 počet stran 28 přílohy 0. Nahrazuje: MET-01/2014 METODIKA SZR-56-1/OPICT-2013 počet stran 28 přílohy 0 Chybová hlášení Gestor, podpis: Ing. Radovan Pártl Zpracovatel, podpis: RNDr. Miroslav Šejdl Odborný garant, podpis: RNDr. Miroslav Šejdl

Více

Validace souborů DS3

Validace souborů DS3 Validace souborů DS3 Verze: 1.33 1. Rozsah...1 1.1 Identifikace systému...1 1.2 Přehled systému...1 2. Přehled verzí a změny v nich...1 3. Použité dokumenty...2 4. Shrnutí údajů o programovém vybavení...4

Více

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Praha, 31. 3. 2017 Základní Agenda informace semináře o projektu Příjem zpráv ve druhé vlně Kontroly datových zpráv, chyby a varování

Více

ERP-001, verze 2_10, platnost od

ERP-001, verze 2_10, platnost od ERP-001, verze 2_10, platnost od 2010.08.01. ELEKTRONICKÉ PŘEDEPISOVÁNÍ HUMÁNNÍCH LÉČIVÝCH PŘÍPRAVKŮ ERP-001.pdf (208,89 KB) Tímto technickým dokumentem jsou, v souladu s 80 zákona č. 378/2007 Sb., o léčivech

Více

Popis rozhraní eneschopenky pro zaměstnavatele

Popis rozhraní eneschopenky pro zaměstnavatele Popis rozhraní eneschopenky pro zaměstnavatele Historie dokumentu Verze Datum Změny 1.0 30. 7. 2019 Vytvoření dokumentu Obsah 1 Účel dokumentu... 3 2 Seznam provedených změn... 3 3 Popis služeb... 3 3.1

Více

XML terminologie a charakteristiky. Roman Malo

XML terminologie a charakteristiky. Roman Malo XML terminologie a charakteristiky Roman Malo XML extensible Markup Language (rozšiřitelný značkovací jazyk) Verze 1.0, 1.1 http://www.w3.org/xml Rozdíly v podpoře různých znakových sad a práci s řídícími

Více

Metodické pokyny a validační pravidla pro vyplnění formuláře. Žádost

Metodické pokyny a validační pravidla pro vyplnění formuláře. Žádost Metodické pokyny a validační pravidla pro vyplnění formuláře Žádost Vydání Schváleno Ministerstvem pro místní rozvoj České republiky dne 06.10.2016 Verze v0.1 Účinnost 07.10.2016 Formulář Žádost k uveřejnění

Více

V této příloze je podrobně popsána struktura XML dokumentu s mapou (viz kapitolu 5.3), příklad tohoto XML dokumentu je na přiloženém CD v souboru

V této příloze je podrobně popsána struktura XML dokumentu s mapou (viz kapitolu 5.3), příklad tohoto XML dokumentu je na přiloženém CD v souboru Příloha 1: Struktura XML dokumentu V této příloze je podrobně popsána struktura XML dokumentu s mapou (viz kapitolu 5.3), příklad tohoto XML dokumentu je na přiloženém CD v souboru /mapa/map.xml. Obsah

Více

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal

Databázové systémy. - SQL * definice dat * aktualizace * pohledy. Tomáš Skopal Databázové systémy - SQL * definice dat * aktualizace * pohledy Tomáš Skopal Osnova přednášky definice dat definice (schémat) tabulek a integritních omezení CREATE TABLE změna definice schématu ALTER TABLE

Více

Vytvoření certifikační autority v programu XCA

Vytvoření certifikační autority v programu XCA Příloha č. 1 Vytvoření certifikační autority v programu XCA 1 Cíl dokumentu Cílem tohoto dokumentu je popsat postup pro vytvoření certifikační autority v programu XCA (http://xca.sourceforge.net) a následné

Více

7) Integrace a rozhraní

7) Integrace a rozhraní 7) Integrace a rozhraní Číslo Otázka Odpověď 7.1 Kde je umístěna aktuální verze dokumentu Technický manuál? Aktuální verze dokumentu Technický manuál je umístěna na webových stránkách http://www.mvcr.cz/isoss

Více

Národní elektronický nástroj. Import profilu zadavatele do NEN

Národní elektronický nástroj. Import profilu zadavatele do NEN Národní elektronický nástroj Import profilu zadavatele do NEN V 1.2 2014 Obsah 1 Cíl...... 2 2 Nutné podmínky k umožnění importu profilu zadavatele...... 2 3 Povinnosti zadavatele dle metodiky k vyhlášce

Více

Dokumentace ke službě SMS Connect. www.smsbrana.cz

Dokumentace ke službě SMS Connect. www.smsbrana.cz Dokumentace ke službě SMS Connect www.smsbrana.cz Obsah 1 ZÁKLADNÍ INFORMACE... 3 1.1 Aktivace služby SMS Connect... 3 1.2 Přístupové údaje... 3 1.3 Přístupový bod služby URL adresa pro SMS Connect...

Více

Komentář k datovému standardu a automatizovaným kontrolám obsahu common.xsd

Komentář k datovému standardu a automatizovaným kontrolám obsahu common.xsd Komentář k datovému standardu a automatizovaným kontrolám obsahu common.xsd Ohlašovací povinnost: Definice common.xsd popisuje pole společná pro všechna hlášení Formulář: Všechny ohlašovací povinnosti

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním ICS 03.220.01; 35.240.60 materiálem o normě. Inteligentní dopravní systémy Požadavky na ITS centrální datové

Více

Elektronická evidence tržeb. P r a h a 2. srpna 2016

Elektronická evidence tržeb. P r a h a 2. srpna 2016 Elektronická evidence tržeb P r a h a 2. srpna 2016 Agenda 1. Úvod 2. Zákon o evidenci tržeb a prováděcí předpisy 3. Technická dokumentace 4. Testovací prostředí (Playground) 5. Diskuse Zákon o evidenci

Více

Přehled základních kontrol v ISoSS

Přehled základních kontrol v ISoSS Informační systém o státní službě (ISoSS) Název dokumentu: Verze dokumentu: 1.0 (z 17. 7. 2015) Strana: 1/7 Historie dokumentu Historie revizí Číslo Datum revize Popis revize Změny revize označeny 1. 0

Více

RESTful API TAMZ 1. Cvičení 11

RESTful API TAMZ 1. Cvičení 11 RESTful API TAMZ 1 Cvičení 11 REST Architektura rozhraní navržená pro distribuované prostředí Pojem REST byl představen v roce 2000 v disertační práci Roye Fieldinga, zkratka z Representional State Transfer

Více

Katalog egon služeb verze: 0.01

Katalog egon služeb verze: 0.01 Katalog egon služeb verze: 0.01 Historie verzí Verze Datum Popis 0.01 20.7.2011 egon služby prototypu OBSAH 1 Úvod... 5 1.1 Členění dokumentu... 5 1.2 Třídy služeb... 5 1.3 SLA služeb... 6 1.3.1 SLA-01...

Více

pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015

pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015 Lékařský email elektronická výměna dat ve zdravotnictví pomocí S/MIME ezprava.net s.r.o. 21. ledna 2015 Abstrakt Tento dokument popisuje technické požadavky nutné pro zabezpečenou výměnu dat ve zdravotnictví

Více

Požadavky pro výběrová řízení TerraBus ESB/G2x

Požadavky pro výběrová řízení TerraBus ESB/G2x Dokument: Převod dat TerraBus ESB/G2x Požadavky pro výběrová řízení TerraBus ESB/G2x Obsah 1. Účel dokumentu... 2 2. Použité termíny a zkratky... 2 3. Požadavky... 3 Účel dokumentu Účelem tohoto dokumentu

Více

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

NÁVOD NA ZPRACOVÁNÍ A ODESLÁNÍ

NÁVOD NA ZPRACOVÁNÍ A ODESLÁNÍ NÁVOD NA ZPRACOVÁNÍ A ODESLÁNÍ ELEKTRONICKÉHO FORMULÁŘE EVIDENČNÍHO LISTU VYSÍLACÍ STANICE BEZDRÁTOVÉHO MÍSTNÍHO INFORMAČNÍHO SYSTÉMU (BMIS) I. Zpracování elektronického formuláře Pro vyplňování formuláře

Více

- PC musí být připojené v lokální síti - je bezpodmínečně nutné, aby aplikace Outlook nebyla aktivní)

- PC musí být připojené v lokální síti - je bezpodmínečně nutné, aby aplikace Outlook nebyla aktivní) (CETIN) INSTALACE nové verze aplikace Entrust (ESP Entrust Security Provider) (určeno k šifrování souborů a podepisování souborů a zabezpečení e-mailu (šifrování, podpis), aplikace umožňuje současné použití

Více

Příloha 8: Zadávací dokumentace pro systém elektronických formulářů

Příloha 8: Zadávací dokumentace pro systém elektronických formulářů Příloha 8: Zadávací dokumentace pro systém elektronických formulářů Server bude serverová databázová aplikace, která umožňuje řídit oběh elektronických dokumentů po organizaci, a případně mimo ni. Umožní

Více

KSRZIS. Příručka pro externí žádost CHLAP. Projekt - ereg - Úprava rezortních registrů a konsolidace rezortních

KSRZIS. Příručka pro externí žádost CHLAP. Projekt - ereg - Úprava rezortních registrů a konsolidace rezortních Koordinační středisko pro resortní zdravotnické informační systémy Budějovická 15/743 140 00 Praha 4 Počet stran: 11 KSRZIS Příručka pro externí žádost CHLAP Projekt - ereg - Úprava rezortních registrů

Více

POPIS STANDARDU CEN TC278/WG4. 1 z 5. Oblast: TTI. Zkrácený název: Zprávy přes CN 4. Norma číslo:

POPIS STANDARDU CEN TC278/WG4. 1 z 5. Oblast: TTI. Zkrácený název: Zprávy přes CN 4. Norma číslo: POPIS STANDARDU CEN TC278/WG4 Oblast: TTI Zkrácený název: Zprávy přes CN 4 Norma číslo: 14821-4 Norma název (en): Traffic and Traveller Information (TTI) TTI messages via cellular networks Part 4: Service-independent

Více

24. XML. Aby se dokument XML vůbec zobrazil musí být well-formed (správně strukturovaný). To znamená, že splňuje formální požadavky specifikace XML.

24. XML. Aby se dokument XML vůbec zobrazil musí být well-formed (správně strukturovaný). To znamená, že splňuje formální požadavky specifikace XML. 24. XML Úvod Značkovací jazyk XML (extensible Markup Language) vznikl ze staršího a obecnějšího jazyku SGML (Standard Generalized Markup Language). XML byl vyvinut konsorciem W3C, aby poskytl standardní

Více

Popis egon služby. E93 - roszapispravnistav. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů

Popis egon služby. E93 - roszapispravnistav. Název dokumentu: Popis egon služeb Verze: Datum aktualizace: Správa základních registrů Popis egon služby E93 - roszapispravnistav Název dokumentu: Autor: Popis egon služeb Verze: 02.00 Správa základních registrů Datum aktualizace: 05.03.2017 Účel: Popis egon služeb v rámci základních registrů

Více

Elektronická evidence tržeb. Neprodukční prostředí (playground) Přístupové a provozní informace

Elektronická evidence tržeb. Neprodukční prostředí (playground) Přístupové a provozní informace Elektronická evidence tržeb Neprodukční prostředí (playground) Přístupové a provozní informace Verze 3.0 Datum poslední verze dokumentu: 15.8.2016 Vymezení obsahu dokumentu Dokument obsahuje doplňující

Více

Co nás čeká při skartačním řízení? Připravte se na změny balíčku SIP

Co nás čeká při skartačním řízení? Připravte se na změny balíčku SIP Co nás čeká při skartačním řízení? Připravte se na změny balíčku SIP ISSS 2017, Hradec Králové 3. dubna 2017 Ze světa... SIP (Submission Information Package) vychází z normy ISO 14721:2003 Space data and

Více

Popis struktury XML rozhraní pro elektronické podání hromadné žádosti. o obnovu oprávnění k činnosti

Popis struktury XML rozhraní pro elektronické podání hromadné žádosti. o obnovu oprávnění k činnosti NA PŘÍKOPĚ 28 115 03 PRAHA 1 Popis struktury XML rozhraní pro elektronické podání hromadné žádosti o obnovu oprávnění k činnosti Obsah Popis struktury XML rozhraní... 1 pro elektronické podání hromadné

Více

I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s

I.CA RemoteSeal. Ing. Filip Michl První certifikační autorita, a.s Technické řešení služby I.CA RemoteSeal Ing. Filip Michl První certifikační autorita, a.s. 5. 4. 2018 Agenda Úvod ARX CoSign vs. DocuSign Signature Appliance Architektura Zřízení služby Aktivace služby

Více

TRANSPORTY výbušnin (TranV)

TRANSPORTY výbušnin (TranV) TRANSPORTY výbušnin (TranV) Ze zákona vyplývá povinnost sledování přeprav výbušnin. Předpokladem zajištění provázanosti polohy vozidel v čase a PČR je poskytování polohy vozidla předepsaným způsobem. Komunikace

Více

EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI. Jan Tejchman Business Consultant

EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI. Jan Tejchman Business Consultant EIDAS, DIGITÁLNÍ DŮVĚRA A MODERNÍ PAPERLESS V PRAXI Jan Tejchman Business Consultant Digitální Evropa Digitální transformace Moderní paperless Právní validita Služby vytvářející důvěru Business aplikace

Více

I.CA SecureStore Uživatelská příručka

I.CA SecureStore Uživatelská příručka I.CA SecureStore Uživatelská příručka Verze 4.1 a vyšší První certifikační autorita, a.s. Verze 4.17 1 Obsah 1. Úvod... 3 2. Přístupové údaje ke kartě... 3 2.1. Inicializace karty... 3 3. Základní obrazovka...

Více

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů

Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Elektronická evidence tržeb Seminář pro vývojáře pokladních systémů Praha, Štěpánská 28 28. 6. 2017 Základní Agenda informace semináře o projektu Statistiky tržeb a evidujících poplatníků Používání certifikátů

Více

OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP)

OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP) OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP) Obsah Úvod...2 Co je ISDP...2 Jaké jsou funkce ISDP...2 Slovník pojmů...2 Dílčí DP...2 DS...2 ISDP...2

Více

dokumentaci Miloslav Špunda

dokumentaci Miloslav Špunda Možnosti elektronického podpisu ve zdravotnické dokumentaci Možnosti elektronického podpisu ve zdravotnické dokumentaci Miloslav Špunda Anotace Příspěvek se zabývá problematikou užití elektronického podpisu

Více

Michal Kolařík 18.1.2012. ISZR - Brána k základním registrům

Michal Kolařík 18.1.2012. ISZR - Brána k základním registrům Michal Kolařík 18.1.2012 ISZR - Brána k základním registrům Informační systém základních registrů Informační systém základních registrů Registrační číslo: CZ.1.06/1.1.00/03.05891 Projekt Informační systém

Více

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace

Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Příloha: Dodatečné informace, včetně přesného znění žádosti dodavatele o dodatečné informace Pořadové číslo dodatečných informací: 14. ČÁST 1: Přesné znění žádosti dodavatele o dodatečné informace Otázka

Více

Money S3 - Elektronická podání 1. Obsah

Money S3 - Elektronická podání 1. Obsah Elektronická podání Money S3 - Elektronická podání 1 Obsah Elektronická podání z Money S3...2 Seznam podporovaných elektronických písemností v Money S3...2 Možnosti komunikace s orgány státní správy...2

Více

Obsah prezentace. Co je to XML? Vlastnosti. Validita

Obsah prezentace. Co je to XML? Vlastnosti. Validita Obsah prezentace Co je to XML? Vlastnosti Validita Co je to XML? EXtensible Markup Language Účelem je usnadnit sdílení dat napříč informačními systémy Popis dokumentu z hlediska věcného obsahu Vyvinuto

Více

Certifikáty a jejich použití

Certifikáty a jejich použití Certifikáty a jejich použití Verze 1.17 Vydávání certifikátů pro AIS pro produkční prostředí ISZR se řídí Certifikační politikou SZR pro certifikáty vydávané pro AIS. Tato politika je uveřejněná na webu

Více

Popis struktury XML rozhraní pro hromadné hlášení změn pojišťovnami, pojišťovacími agenty (PA) a pojišťovacími makléři (PM)

Popis struktury XML rozhraní pro hromadné hlášení změn pojišťovnami, pojišťovacími agenty (PA) a pojišťovacími makléři (PM) NA PŘÍKOPĚ 28 115 03 PRAHA 1 Popis struktury XML rozhraní pro hromadné hlášení změn pojišťovnami, pojišťovacími agenty (PA) a pojišťovacími makléři (PM) Obsah Popis struktury XML rozhraní... 1 pro hromadné

Více

OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP)

OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP) OSOBA JEDNAJÍCÍ ZA SPRÁVCE ČÍSELNÍKU NÁVOD K OBSLUZE INFORMAČNÍHO SYSTÉMU O DATOVÝCH PRVCÍCH (ISDP) Obsah Úvod...2 Co je ISDP...2 Jaké jsou funkce ISDP...2 Slovník pojmů...2 Dílčí DP...2 DS...2 ISDP...2

Více

Podpora XML v.net. Podpora XML v.net. nezávislý publicista. Jirka Kosek. http://www.kosek

Podpora XML v.net. Podpora XML v.net. nezávislý publicista. Jirka Kosek. http://www.kosek Podpora XML v.net Podpora XML v.net Jirka Kosek nezávislý publicista http://www.kosek kosek.cz Co nás čeká? Co nás čeká?! podpora XML ve VisualStudio.NET! architektura System.Xml! čtení XML dokumentů!

Více

Oracle XML DB. Tomáš Nykodým

Oracle XML DB. Tomáš Nykodým Oracle XML DB Tomáš Nykodým xnykodym@fi.muni.cz Osnova Oracle XML DB Architektura Oracle XML DB Hlavní rysy Oracle XML DB Hlavní rysy Oracle XML DB - pokračování XMLType XML Repository Využívání databázových

Více