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 2.3.6.
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.
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 http://www.cs.mfcr.cz/schemas/EcrObalka/V_2.0
2.1. 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.
-
Uvolněna sekce Ucastnici tak, aby mohl být počet účastníků větší než doposud podporovaní 3.
Volitelný [1]
Volitelný [1]
Element obsahuje XML data v otevřeném tvaru.
Volitelný [1]
Element obsahuje XML data v šifrovaném tvaru dle doporučení W3C - XML encryption.
Volitelný [1]
Umístění informací o elektronickém podpisu dle doporučení W3C XML signature.
Volitelný [1]
Element pro umístění přenášené binární zprávy kódované jako base64
Volitelný [1]
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".
Volitelný [1]
Element
Volitelný [1]
Element
Volitelný [1]
Element
Atribut
Volitelný [1]
Element pro umístění přenášené zprávy v XML formátu.
Volitelný [1]
Volitelný [1]
Element
Atribut
Volitelný [1]
Element pro umístění přenášené zprávy v SMIME formátu.
string[15]
Volitelný [1]
Data
Element
EncryptedData
Signature
Chyba
string
Volitelný [1]
Element obsahuje binární data v kódování base64.
Volitelný [1]
Element obsahuje binární data v šifrovaném tvaru dle doporučení W3C - XML encryption.
Volitelný [1]
Umístění informací o elektronickém podpisu dle doporučení W3C XML signature.
Nesmí být
Volitelný [1]
Pokud při zpracování došlo k chybě, budou zde umístěny příslušné informace.
Nesmí být
Povinný
Číselný kód chyby.
Volitelný
Obsahuje GUID původní obálky, ke které se chyba vztahuje, pokud jí je možné načíst.
Povinný
Označení typu chyby, resp. zdroje chyby.
Volitelný
Popis chyby.
Volitelný [1]
Pokud je to k popisu chyby nutné, jsou zde uvedena data chyby.
Volitelný [1]
Umístění informací o elektronickém podpisu dle doporučení W3C XML signature pro element hlášené chyby
Volitelný [1]
Volitelný [1]
Element
Volitelný [1]
Element
Element
PopisChyby Kod
GuidPuvodniObalky
Atribut
Atribut
int
UUID
Nesmí být
TypChyby
Atribut
string[20]
Popis
Atribut
string[256] Nesmí být
Data
Signature
Element
Element
string
Nesmí být
Nesmí být
Nesmí být
2.3.1. 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 „Verze“
2.3.2. 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“.
2.3.3. 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.
2.3.4. 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.
2.3.5. 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.
2.3.5.1. 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.
2.3.5.2. 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 3.
2.3.5.3. 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 3.
2.3.6. 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 2.3.5. 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 3.2.2. Seznam chyb, které může ECR brána aktuálně vracet, je uveden v kapitole 4.
3. Formáty zabezpečení dat ECR obálky 3.1. Šifrování Šifrování v ECR obálce se plně (http://www.w3.org/TR/xmlenc-core/).
ří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="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256cbc" /> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <X509Data> <X509IssuerSerial> <X509IssuerName>CN=VM-BTS CA, OU=Technologie, O=Aquasoft s.r.o., L=Prague, S=Czech Republic, C=CZ <X509SerialNumber>290779403689187849797704 RkSilm7TlI2Nzc+Y+OVm+2KT0WoQtB7wky+aAtfowWxecq+9jV /huXTQ80DdMhT9OOvuEh1Uja1Oa1noRRzstA==Yg82r6P+QvWTYhujTR0NWm4AoRvbXEi6Oc6pTw+4zFM3c0MeA hZ+ ……. AD7GHNDIgMPVS6fqfwkUifoEgJgmJFrVEcc27I3fQvYj7p5Z99iOV7GaYVVJes +GrO/UbaIQ==
3.2. Zaručený elektronický podpis Zaručený elektronický podpis se v ECR obálce plně řídí doporučením W3C XML Signature (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/). 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 (SHA5 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:
3.2.1. 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> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> 59vhtCKrP1oxMOgWl+YOMexcOwQ=
3.2.2. 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. <XmlZprava> 08CZ1761003JZUV4J2D17 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1" /> <XPath xmlns:parns="http://www.cs.mfcr.cz/schemas/EcrObalka/V_2.0">ancesto
3.2.3. Typ Enveloped, mimo zprávu, SignatureContext = ”datacontent” Princip tohoto podpisu je stejný jako v případě 3.2.2 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">…
3.2.4. 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> 08CZ1761003JZUV4J2D17 <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsasha1" />
3.2.5. Typ Enveloped, uvnitř zprávy, SignatureContext = ”datacontent” Princip tohoto podpisu je stejný jako v případě 3.2.4 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">…
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.
4. Příloha A – číselník chyb odesílaných ECR bránou Kód
Text chyby
0
Invalid incomming XML
1
Internal server error
2
Invalid incomming XML message type
3
Message domain is not valid
4
ID for declarant is unknown
5
VAN operator $ is not allowed for domain $
6
At least primary or secondary identifier have to be filled in
7
Message $ is not allowed to pass through in the domain $
11
Load from MIME failed in the $ phase.
12
Decrypt SMIME/XML failed with: $
13
Verify sign SMIME/XML failed due to an incorrect sign format with: $
14
Verify sign SMIME/XML failed due to message changes
15
Verify sign SMIME/XML failed due to the incorrect certificate chain or certificate revocation. Certificate number: $
16
Verify sign SMIME/XML failed due to the unauthorized certificate. Certificate number: $
17
Decoding base64 in MIME failed in the $ phase.
18
Incorrect data security found: $
53
XML schema general validation error
54
Invalid child element
55
Incomplete content
56
Value too short
57
Value too long
58
Invalid datatype
59
Pattern constraint failed
60
Attribute missing
70
Primary identifier is not equal to inner message
71
Secondary identifier is not equal to inner message
72
Message type is not equal to inner message
73
Unable to perform inner XML controls in order to incomplete inner message
