Česká národní banka (ČNB)                                 Jaroslav Zatloukal
Verze: 0.9.20180504                                                      ČNB
Nahrazuje: N/A                                                 listopad 2017
Kategorie: Uživatelská příručka


                 Příručka uživatele SFTP serveru HUB.CNB.CZ


Status

   Tento dokument obsahuje informace pro uživatele, kteří zvažují zasílání
   obsahů předepsaných MiFID/MiFIR prostřednictvím SFTP serveru NCA ČNB.


Shrnutí

   Tento dokument obsahuje uživatelskou příručku klienta serveru HUB.CNB.CZ
   (dále jen server). Server zahrnuje několik oddělených prostředí určených
   pro výměnu zabezpečených obsahů (respektive souborů) mezi klientem a
   aplikacemi na straně NCA.

   Server poskytuje obecné rozhraní pro vzájemné předávání souborů. Cílem
   jeho nasazení bylo doplnit do portfolia stávajících sběrných kanálů,
   kterými ČNB v současnosti disponuje, kanál splňující požadavky kladené
   na NCA specifikacemi ESMA.


Zkratky

   BAH    business application header (ESMA)
   CPoK   cryptographic pair of keys
   DNS    domain name system
   ESMA   European Security and Markets Authority
   FIRDS  Financial Instrument Reference Data System
   IPv4   Internet protocol version 4
   MiFID  Markets in Financial Instruments Directive
   MiFIR  Markets in Financial Instruments Regulation
   N/A    not applicable
   NCA    national competent authority
   OS     operational system
   RHEL   Red Hat Enterprise Linux
   RVC    revocation certificat
   SFTP   secure file transfer protocol
   SSH    secure shell
   TCP    transmission control protocol
   URC    unique registration code
   XML    extensible markup language


Pojmy

   E-MAIL
      registrovaný kontaktní e-mail

   server
      SFTP server HUB.CNB.CZ

   správa [serveru]
      skupina správců serveru pracujících pod společnou adresou

   XML Schema
      https://www.w3.org/XML/Schema

   ZIP
      formát obsahu souboru zahrnující datovou kompresi a případně
      zabezpečení (šifrování)


Obsah

           Úvod
   1       Přístup k serveru
   1.1     Příprava na připojení
   1.1.1   Úvodní kontakt se správou
   1.1.2   Vytvoření kryptografického páru klíčů
   1.1.3   Předání veřejného klíče správě
   1.1.4   Převzetí veřejného klíče správy
   1.1.5   Převzetí jména a hesla k účtu
   1.1.6   Předání IPv4 adres správě
   1.1.7   Převzetí IPv4 adres serveru
   1.1.8   Převzetí veřejných SSH klíčů serveru
   1.1.9   Vytvoření revokačního certifikátu
   1.1.10  Předání revokačního certifikátu správě
   1.2     Připojování
   1.2.1   Úvodní připojení
   1.2.2   Následná připojení
   2       Uživatelský účet
   2.1     Domovský adresář
   2.2     Adresářový strom
   2.3     Soubory
   2.3.1   Jmenná konvence
   2.3.2   Odesílání souboru - hlášení
   2.3.3   Přijímání souboru - odezva
   2.3.4   Formální chyby při komunikaci
   3       Podpora komunikace v rámci MiFID/MiFIR
   3.1     Specifikace ESMA a metodiky ČNB
   3.2     Zásady pro zpracování obsahů
   3.3     Specifický obsah BAH
           Reference
           Kontakt na správu
   A       Parametry serveru
   B       Formáty, rozsahy a limity
   C       Dodatečné ověření identity {přechodné}


Úvod

   Tento dokument popisuje jak provozovat uživatelskou komunikaci jako
   klient SFTP serveru HUB.CNB.CZ. Tento dokument má tři cíle:

   1.  Poskytnout popis funkčnosti serveru dostatečný k vědomému a
       bezpečnému používání uživatelského účtu klientem.

   2.  Řadou příkladů a podrobně popsaných postupů umožnit uživateli
       používat tento dokument jako příruční návod, kde bez obšírných
       úvodů nalezne klient konkrétní řešení.

   3.  Díky verzování a tím umožněné plné historizaci obsahu jak dokumentu
       samého tak i odkazovaných zdrojů poskytovat soustavně úplné
       informace o celém životním cyklu předkládaného řešení.

   Tento dokument je rozdělen do tří částí. První popisuje přístup k
   serveru, a to od úvodního kontaktu se správou až po přechod do rutinního
   provozu. Druhá kapitola popisuje prostředí uživatelského účtu na serveru,
   a to jak strukturálně (adresářový strom), tak procesně (práce se
   soubory). Třetí kapitola popisuje podporu, kterou server poskytuje
   konkrétním implementacím definovaným v rámci MiFID/MiFIR.

   Celý text je formálně upraven tak, aby veškeré konkrétní informace
   nebyly explicitně uvedeny v textu, ale byly z textu pouze odkazovány do
   dodatků.

   Příklady použité v tomto dokumentu byly vytvořeny v prostředí operačního
   systému RHEL 6. Použité programy pocházení z rodiny svobodného software a
   jsou dostupné pro i ostatní běžné OS.


1  Přístup k serveru

   Tato kapitola popisuje přístup k serveru z pohledu klienta. Její první
   podkapitola popisuje přípravu klienta na připojení. V této fázi klient
   komunikuje se správou. Postupně tak dojde ke vzájemné výměně informací
   potřebných pro zajištění bezpečnosti další komunikace. Druhá podkapitola
   popisuje vlastní připojování uživatele k serveru pomocí SFTP klienta.


1.1  Příprava na připojení

   Tato kapitola popisuje přípravu klienta na připojení. Její první
   podkapitola popisuje úvodní kontakt klienta se správou, druhá vytvoření
   kryptografického páru klíčů klienta, třetí předání veřejného klíče
   klienta správě, čtvrtá převzetí veřejného klíče správy klientem, pátá
   převzetí jména a hesla k účtu na serveru klientem, šestá předání
   klientských IPv4 adres správě, sedmá převzetí IPv4 adres serveru klientem
   osmá převzetí veřejných SSH klíčů serveru klientem, devátá vytvoření
   revokačního certifikátu klienta a desátá předání revokačního certifikátu
   správě.

   Komunikace mezi klientem a správou probíhá elektronickou poštou. Zprávy
   by měly být ve formátu prostého textu (plain text). Struktura zpráv je
   striktně předepsaná, uvádění jiných informací, než těch, které jsou
   výslovně požadovány v postupech uváděných dále, může vést k prodloužení
   doby zpracování příslušných požadavků. Obě strany využívají své E-MAILy.
   (Je-li E-MAIL zapsán kapitálkami, jde o registrovaný kontaktní e-mail.)
   Iniciátor komunikace uvede do předmětu zprávy strukturovaný text, který
   je příjemcem interpretován jako příkaz s případnými argumenty. Příjemce
   požadavek odbaví a zasilateli odpoví opět strukturovaným textem v
   předmětu. V některých případech je obdobně využíváno i tělo zprávy.


1.1.1  Úvodní kontakt se správou

   Tato kapitola popisuje úvodní kontakt klienta se správou serveru. Klient
   touto cestou předá správě LEI a E-MAIL vykazujícího subjektu. Pokud je
   E-MAIL shodný s adresou odesílatele, neuvádí se v příkazu. Správa odpoví
   (na adresu odesílatele příkazu) URC, který je s tímto LEI, v evidenci
   správy, trvale spojen. Pokud není odesílatel příkazu shodný s E-MAILem,
   uvede správa v odezvě za URC i E-MAIL.

   1.  Klient zašle správě příkaz "LEI[ E-MAIL] ? urc", kde za LEI a
       případně i E-MAIL dosadí.

   2.  Správa příkaz odbaví odezvou "LEI ? urc URC[ E-MAIL]", kde za URC a
       případně i E-MAIL dosadí.

   Pokud je LEI hlášeno poprvé, dojde k jeho zaevidování společně s
   poskytnutým E-MAILem. Tomuto LEI správa přidělí nové URC.

   Pokud je hlášeno LEI již zaevidované, vrátí správa jeho URC a případně i
   E-MAIL.

   URC viz Dodatek B.

   Příklad 1.1.1.x1: Ukázky úvodních kontaktů se správou:

   o  Zpráva obsahující příkaz:

----------------------------------------------------------------------------
From: admin@company.com
To: hub@cnb.cz
Subject: 549300DS86PEHLIYB473 contact@company.com ? urc 
----------------------------------------------------------------------------

   o  Zpráva obsahující odezvu:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: admin@company.com
Subject: 549300DS86PEHLIYB473 ? urc 3F7 contact@company.com
----------------------------------------------------------------------------

   Příklad 1.1.1.x2:

   o  Zpráva obsahující příkaz:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: 549300DS86PEHLIYB473 ? urc 
----------------------------------------------------------------------------

   o  Zpráva obsahující odezvu:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: 549300DS86PEHLIYB473 ? urc 3F7
----------------------------------------------------------------------------


1.1.2  Vytvoření kryptografického páru klíčů

   Tato kapitola popisuje postup vytvoření CPoK klienta ve standardu OpenPGP
   [1]. Tento CPoK je určen zejména k zabezpečení obsahu souborů, se kterými
   bude klient pracovat na serveru. Předpokladem pro vytvoření CPoK je
   dostupnost příslušného programu [2]. Technicky bude výsledkem činnosti,
   popisované dále v této kapitole, množina diskových souborů, které program
   uloží do domovského adresáře určeného uživatelem programu. Je nezbytné
   tento adresář přechovávat v bezpečném úložišti, protože obsahuje také
   soukromý klíč klienta. Tento klíč je sice chráněn (je doporučeno silným)
   heslem, ale samo odcizení tohoto klíče již znamená určité riziko. V
   případě, že má klient podezření na zneužití CPoK třetí stranou, měl by o
   tom informovat správu.

   Parametry CPoK:

   1.  Podepisování: algoritmus RSA, velikost klíče 2048.

   2.  Šifrování: algoritmus RSA, velikost klíče 2048.

   3.  Platnost CPoK by měla z organizačních důvodů pokrývat jeden
       kalendářní rok.

       Začátek platnosti CPoK je dán technicky, a to okamžikem jeho
       vytvoření. Typicky bude klient CPoK vytvářet ve třech případech:
 
       o  Příprava na zahájení vykazování.
 
       o  Kompromitace nebo vypršení platnosti.

       o  Pravidelná příprava na další kalendářní rok.
 
       V první a druhém případě není možno datum zahájení platnosti nijak
       předurčovat, klient vytvoří CPoK v okamžiku, kdy jej bude potřebovat.
       Ve třetím případě by klient měl CPoK vytvářet v posledním čtvrtletí
       před začátkem kalendářního roku, pro který je CPoK určen.
 
       Konec platnosti je organizačně stanoven na 31. ledna roku, který
       následuje po kalendářním roce, pro který je CPoK určen.
 
       Pokud klient vytváří CPoK dříve než v posledním čtvrtletí roku, měl
       by jeho platnost ukončit 31. ledna příštího roku. CPoK tak pokryje
       období do pravidelné roční obnovy.
 
       Pokud klient vytváří CPoK v rámci pravidelné roční obnovy, tedy v
       posledním čtvrtletí roku, měl by jeho platnost nastavit do 31. ledna
       přespříštího roku.
 
       Platnost CPoK se do programu zadává jako počet dnů od okamžiku jeho
       vytvoření. Pro účel výpočtu neuvažujeme čas v rámci dne.

   Příklad 1.1.2.x1: Pro CPoK na rok 2018 vytvářený dne 4. října 2017
   spočteme počet dnů platnosti jako rozdíl mezi 31. lednem 2019 a tímto
   datem. Vyjde nám 484 kalendářních dnů, které můžeme zadat na výzvu do
   programu.

   4.  CPoK je pro uživatele popsán identifikátorem, který je složen z
       těchto částí:

       o  Název (Real name) musí odpovídat masce "AAA_KEYENC_PUB_BBBBBB_CC",
          kde jednotlivé segmenty mají tento význam:

          AAA
             URC

          KEYENC
             kód pro soubor obsahující (z pohledu správy) šifrovací klíč,
             konstanta

          PUB
             kód pro soubor obsahující (z pohledu správy) veřejný klíč,
             konstanta

          BBBBBB
             pořadové číslo CPoK v rámci kalendářního roku, sekvence v
             rozsahu 000001 až 999999

          CC
             poslední dvojčíslí letopočtu, pro který je CPoK určen

       o  E-MAIL (Email address).

       o  Komentář (Comment) musí obsahovat kód typu prostředí (viz Dodatek
          A) následovaný mezerou (" ") a URC.

   5.  Zabezpečení CPoK, respektive jeho soukromého klíče, provede uživatel
       heslem dostatečné robustnosti. K zadání tohoto hesla vyzve uživatele
       program.

   Příklad 1.1.2.x2: Vytvoření CPoK na rok 2018 v programu GnuPG pro
   testovacího uživatele s URC "FFF" (výpis byl formátován a zkrácen):

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg --gen-key
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 465
Key expires at Thu 31 Jan 2019 01:59:38 PM CET
Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: FFF_KEYENC_PUB_000001_18
Email address: contact@company.com
Comment: TEST FFF
You selected this USER-ID:
    "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

gpg: /home/u03740/doc/hub/FFF/.gnupg/trustdb.gpg: trustdb created
gpg: key EB869180 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2019-01-31
pub   2048R/EB869180 2017-10-23 [expires: 2019-01-31]
      Key fingerprint = 2F8C BE62 F475 A6AA 265F  A358 FA85 7B7D EB86 9180
uid                FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>
sub   2048R/2742359D 2017-10-23 [expires: 2019-01-31]

$
----------------------------------------------------------------------------


1.1.3  Předání veřejného klíče správě
  
   Tato kapitola popisuje předání veřejného klíče klienta správě.

   1.  Klient vyexportuje veřejný klíč z úložiště jako prostý text.

   Příklad 1.1.3.x1: Export veřejného klíče na rok 2018 testovacího
   uživatele s URC "FFF" pomocí programu GnuPG:

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg --armor \
> --export FFF_KEYENC_PUB_000001_18
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)

mQENBFnt6AcBCADTeBzkwI6Ps++hcm+sKddzyc8eNadaTWFkDKrr8xu9cI2bE0aX
SmDvebziMwH2x0OhFIjMyF+pUc9WR11DocdpIkkMF7SVmrwA+YrdXYyuLM1baxIt
qnyLpQUch9x/gAGWDIJi6RGgSi4KPjqapsgbV0Rjqovwcbfg+XXYSfJm5zAhrSlO
syn05klJwgIcNZXlJCmZRJpntE9zY1/56FliBo87axpDjXJCneDBZ26HLW62wgfC
hIv4d7Ea6rLJg1tJm7m2murPc8GrixTCnBRIlvCL08kpKpgPd9++rWqKpWlPlaop
w8NQp1g57hj3dL/KKn8Q4HMFRq9xA5vZq8wNABEBAAG0OUZGRl9LRVlFTkNfUFVC
XzAwMDAwMV8xOCAoVEVTVCBGRkYpIDxjb250YWN0QGNvbXBhbnkuY29tPokBPgQT
AQIAKAUCWe3oBwIbAwUJAmUJgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ
+oV7feuGkYAV3AgAkwEHUEWdopwii0swDqr24l3Xx8TwfKu5UnIjodtfNrOa7v02
MyRkOh9SCkZ0vr/qy1DWzsrMulnC24usITe3nC/x1DlKKOFVCR2iTJwoy1LAVgSe
UouV3zy6EenjVmE1X71DOeafFJJQe129RBtdGW7W/bq7yGODEqlvCd41i1QiyVvp
lzHcdfSSYguC2quOQ5ECmMGrVexw0tZqMh95SWlpIDrZmQvA1yAv+SfeIu67XuyM
UbyOG8MqKMPaoB5S3CtSRofX21d8fitbi5SRq7JxFV0rtzNH930V2QnS0XEH6mfx
bDCm0y9teEIY2Octqerqd0OAXzGVjua1OLYKGrkBDQRZ7egHAQgAwJ3DN4yZppF5
BJATs7rpZqQIArUz0WNXNU46yJPrjWUJNaFB/cELqL/lJa4YLJvcPatJ+oWamEH4
7aCZqRlYf0UUXkX5CfZ3NN2uEmupWy5ODi7HdN7f4FMHOrI17i4E0ahq42/6Z1ZS
iVcQV9SFjV4aiJCS0WtJjGXVmnPkkfmMJAKpLHY4YNehT1hAP5Idpl/j2x4lTiK+
g3hCqbUZJpi9IZ8le/bigYN2pripR1UdN0HPie5zsobmwUMZp6P9kA3HfrqrRy6o
4mFpVQuliKajxyJDcky89pbebSzdNNjg1pTMdGwpLoagLbWrSNpiX2D9yrsGEAd8
hYkWvLyFswARAQABiQElBBgBAgAPBQJZ7egHAhsMBQkCZQmAAAoJEPqFe33rhpGA
4+sH/3a74mxJSO50tDvArrNEk6wqTzdAxy1cM1j0VvZXUxJylS+Rd1mpBm/a90HP
kz1JM0ujLROAerXQmEhIWSLfF2GVaIuypkUZxvXTBU+S7xPsMVJY1kcpFmkZijzj
X759difviFKm1b9cecDS5PNF5tqB8F5OfK1OUAyqpzAUCn++48bQVBCdAmoO9eOW
xDvGfWwSIgiv3PwE7zuxIFYFlXo9020L/HKBORK4+CayviBJo3AC6kM9NYzN+F1N
LX2n6ppBRHRIxbWRr6Vdd92q5fX+tSRcgBTrl2Udphk+2vuLfupIlEpKiC+5BoDm
+B4wel60mA/acCXP9su30oW7kr4=
=qm8A
-----END PGP PUBLIC KEY BLOCK-----
$
----------------------------------------------------------------------------

   2.  Klient zašle správě příkaz "KEY ! key", kde za KEY dosadí komentář
       (Comment) zadaný při vytváření CPoK. Do těla zprávy pak okopíruje
       připravený výpis veřejného klíče. Odesílatelem musí být E-MAIL URC.

   Příklad 1.1.3.x2: Zpráva s příkazem k převzetí veřejného klíče dle
   předchozího příkladu:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! key

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)

mQENBFnt6AcBCADTeBzkwI6Ps++hcm+sKddzyc8eNadaTWFkDKrr8xu9cI2bE0aX
SmDvebziMwH2x0OhFIjMyF+pUc9WR11DocdpIkkMF7SVmrwA+YrdXYyuLM1baxIt
qnyLpQUch9x/gAGWDIJi6RGgSi4KPjqapsgbV0Rjqovwcbfg+XXYSfJm5zAhrSlO
syn05klJwgIcNZXlJCmZRJpntE9zY1/56FliBo87axpDjXJCneDBZ26HLW62wgfC
hIv4d7Ea6rLJg1tJm7m2murPc8GrixTCnBRIlvCL08kpKpgPd9++rWqKpWlPlaop
w8NQp1g57hj3dL/KKn8Q4HMFRq9xA5vZq8wNABEBAAG0OUZGRl9LRVlFTkNfUFVC
XzAwMDAwMV8xOCAoVEVTVCBGRkYpIDxjb250YWN0QGNvbXBhbnkuY29tPokBPgQT
AQIAKAUCWe3oBwIbAwUJAmUJgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQ
+oV7feuGkYAV3AgAkwEHUEWdopwii0swDqr24l3Xx8TwfKu5UnIjodtfNrOa7v02
MyRkOh9SCkZ0vr/qy1DWzsrMulnC24usITe3nC/x1DlKKOFVCR2iTJwoy1LAVgSe
UouV3zy6EenjVmE1X71DOeafFJJQe129RBtdGW7W/bq7yGODEqlvCd41i1QiyVvp
lzHcdfSSYguC2quOQ5ECmMGrVexw0tZqMh95SWlpIDrZmQvA1yAv+SfeIu67XuyM
UbyOG8MqKMPaoB5S3CtSRofX21d8fitbi5SRq7JxFV0rtzNH930V2QnS0XEH6mfx
bDCm0y9teEIY2Octqerqd0OAXzGVjua1OLYKGrkBDQRZ7egHAQgAwJ3DN4yZppF5
BJATs7rpZqQIArUz0WNXNU46yJPrjWUJNaFB/cELqL/lJa4YLJvcPatJ+oWamEH4
7aCZqRlYf0UUXkX5CfZ3NN2uEmupWy5ODi7HdN7f4FMHOrI17i4E0ahq42/6Z1ZS
iVcQV9SFjV4aiJCS0WtJjGXVmnPkkfmMJAKpLHY4YNehT1hAP5Idpl/j2x4lTiK+
g3hCqbUZJpi9IZ8le/bigYN2pripR1UdN0HPie5zsobmwUMZp6P9kA3HfrqrRy6o
4mFpVQuliKajxyJDcky89pbebSzdNNjg1pTMdGwpLoagLbWrSNpiX2D9yrsGEAd8
hYkWvLyFswARAQABiQElBBgBAgAPBQJZ7egHAhsMBQkCZQmAAAoJEPqFe33rhpGA
4+sH/3a74mxJSO50tDvArrNEk6wqTzdAxy1cM1j0VvZXUxJylS+Rd1mpBm/a90HP
kz1JM0ujLROAerXQmEhIWSLfF2GVaIuypkUZxvXTBU+S7xPsMVJY1kcpFmkZijzj
X759difviFKm1b9cecDS5PNF5tqB8F5OfK1OUAyqpzAUCn++48bQVBCdAmoO9eOW
xDvGfWwSIgiv3PwE7zuxIFYFlXo9020L/HKBORK4+CayviBJo3AC6kM9NYzN+F1N
LX2n6ppBRHRIxbWRr6Vdd92q5fX+tSRcgBTrl2Udphk+2vuLfupIlEpKiC+5BoDm
+B4wel60mA/acCXP9su30oW7kr4=
=qm8A
-----END PGP PUBLIC KEY BLOCK-----
----------------------------------------------------------------------------

   3.  Správa příkaz odbaví odezvou "KEY ! key ? fp STAMP TIME", kde za KEY
       dosadí podle textu příkazu. Připojením "? fp" požádá správa klienta o
       zaslání signatury (fingerprint) předávaného klíče. Za STAMP správa
       dosadí pseudonáhodnou sekvenci osmi alfanumerických znaků a za TIME
       pak časovou značku (formát viz Dodatek B).

   4.  Správa může do těla zprávy vložit jednu nebo i několik instrukcí za
       účelem zvýšení pravděpodobnosti správného rozpoznání identity
       klienta.

   Příklad 1.1.3.x3: Zpráva s výzvou k zaslání signatury veřejného klíče
   dle předchozího příkladu:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key ? fp G7GO49mp 20171005123456

Uveďte, prosím, kolik jednotlivých LEI v naší evidenci aktuálně zastupujete?
----------------------------------------------------------------------------

   5.  Klient si vypíše programem požadovanou signaturu (fingerprint) a
       případně připraví obsah odpovědi dle instrukcí od správy.

   Příklad 1.1.3.x4: Výpis signatury klíče dle předchozího příkladu:

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg --fingerprint FFF_KEYENC_PUB_000001_18
pub   2048R/EB869180 2017-10-23 [expires: 2019-01-31]
      Key fingerprint = 2F8C BE62 F475 A6AA 265F  A358 FA85 7B7D EB86 9180
uid                FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>
sub   2048R/2742359D 2017-10-23 [expires: 2019-01-31]
$
----------------------------------------------------------------------------

   6.  Klient odbaví výzvu odezvou "KEY ! key ? fp STAMP TIME", kde přesně
       zopakuje předmět výzvy a na první řádek těla zprávy zapíše samostatně
       signaturu.

   7.  Od druhého řádku dále pak může klient zapsat případně odpovědi na
       instrukce od správy.

   Příklad 1.1.3.x5: Zpráva s odezvou na výzvu k zaslání signatury
   veřejného klíče dle předchozího příkladu:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! key ? fp G7GO49mp 20171005123456

2F8C BE62 F475 A6AA 265F  A358 FA85 7B7D EB86 9180
1
----------------------------------------------------------------------------

   8.  Správa ověří shodu předmětu odezvy s výzvou a dále shodu doručené
       signatury se signaturou přikázaného veřejného klíče.

   9.  Správa odpoví odezvou "KEY ! key RESULT[ ERROR]", kde za KEY dosadí
       komentář (Comment) CPoK. Pokud jsou všechny kontrolované znaky
       (předměty zpráv, signatury klíčů a E-MAIL) shodné, pak správa klíč
       zaeviduje a za RESULT dosadí "0". Jinak dosadí hodnotu větší než "0"
       a za ERROR pak případně informaci o chybě.

   Příklad 1.1.3.x6: Zpráva uzavírající komunikaci:

   o  varianta - vše je v pořádku:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key 0
----------------------------------------------------------------------------

   o  varianta - chyba: použit neregistrovaný E-MAIL:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key 1 unregistered E-MAIL
----------------------------------------------------------------------------


1.1.4  Převzetí veřejného klíče správy

   Tato kapitola popisuje postup převzetí veřejného klíče správy do
   prostředí klienta. Podobně jako klient používá pro každý typ prostředí
   samostatný CPoK, používá samostatné CPoK i správa serveru. Veřejné klíče
   pro jednotlivá prostředí a roky viz Dodatek A.

   1.  Podle typu prostředí zvolí klient veřejný klíč správy. Veřejné klíče
       jsou dostupné ve formě prostého textu, který klient okopíruje do
       souboru.

   2.  Připravený soubor klient importuje programem do svého úložiště klíčů.

   Příklad 1.1.4.x1: Import veřejného klíče správy do úložiště testovacího
   uživatele s URC "FFF" pomocí programu GnuPG (výpis byl formátově
   upraven):

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg --import CNB_KEYENC_PUB_000001_18.gpg
gpg: key EE21B738: public key "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.
cz>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
$
----------------------------------------------------------------------------

   3.  Autenticitu importovaného veřejného klíče ověří klient srovnáním
       signatury s předlohou uvedenou v Dodatku A.

   Příklad 1.1.4.x2: Výpis signatury pro klíč správy serveru pomocí
   programu GnuPG:

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg --fingerprint CNB_KEYENC_PUB_000001_18
pub   2048R/EE21B738 2017-10-23 [expires: 2019-01-31]
      Key fingerprint = C389 BF2D 258E E3B0 A1F2  4013 D745 6B16 EE21 B738
uid                  CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>
sub   2048R/74B6BC6D 2017-10-23 [expires: 2019-01-31]

$
----------------------------------------------------------------------------

   4.  Po ověření shody signatur může klient podepsat veřejný klíč správy 
       svým CPoK a prohlásit tak tento klíč za validní. Explicitní validita
       klíče zvyšuje produktivitu jeho používání.

   Příklad 1.1.4.x3: Postup podepsání klíče správy pomocí CPoK klienta
   pomocí programu GnuPG. Klient kromě výchozího volání musí dále zadat v
   promptu programu postupně příkaz "sign", potvrdit úmysl "y", zadat heslo
   CPoK a program ukončit příkazem "save". Před podpisem má klíč vlastnost
   "validity: unknown". Podepsáním se vlastnost změní "validity: full".
   (výpis byl formátově upraven):

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --default-key FFF_KEYENC_PUB_000001_18 \
> --edit-key CNB_KEYENC_PUB_000001_18
pub  2048R/EE21B738  created: 2017-10-23  expires: 2019-01-31  usage: SC
                     trust: unknown       validity: unknown
sub  2048R/74B6BC6D  created: 2017-10-23  expires: 2019-01-31  usage: E
[ unknown] (1). CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>

Command> sign

pub  2048R/EE21B738  created: 2017-10-23  expires: 2019-01-31  usage: SC
                     trust: unknown       validity: unknown
 Primary key fingerprint: C389 BF2D 258E E3B0 A1F2  4013 D745 6B16 EE21 B738

     CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>

This key is due to expire on 2019-01-31.
Are you sure that you want to sign this key with your
key "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>" (EB869180)

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID EB869180, created 2017-10-23

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

Command> save
$ gpg --homedir ~/doc/hub/FFF/.gnupg --edit-key CNB_KEYENC_PUB_000001_18
pub  2048R/EE21B738  created: 2017-10-23  expires: 2019-01-31  usage: SC
                     trust: unknown       validity: full
sub  2048R/74B6BC6D  created: 2017-10-23  expires: 2019-01-31  usage: E
[  full  ] (1). CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>

Command> quit
$
----------------------------------------------------------------------------


1.1.5  Převzetí jména a hesla k účtu

   Tato kapitola popisuje postupu převzetí jména a hesla k účtu na serveru.
   Postup je určen jak pro prvotní, tak pro každé případné následující
   převzetí těchto přístupových informací.

   1.  Klient zašle správě příkaz "KEY ? passwd", kde za KEY dosadí komentář
       (Comment) CPoK.

   2.  Správa příkaz odbaví odezvou "KEY ? passwd RESULT[ ERROR]", kde KEY
       převezme z příkazu. Pokud je odesílatelem příkazu E-MAIL příslušný k
       zaslanému KEY, pak správa za RESULT dosadí "0" a v těle zprávy zašle
       požadované informace v zabezpečené podobě. Jinak dosadí hodnotu větší
       než "0" a za ERROR pak případně informaci o chybě.

   Příklad 1.1.5.x1:

   o  Zpráva obsahující příkaz:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ? passwd
----------------------------------------------------------------------------

   o  Zpráva obsahující odezvu:

      *  varianta: vše v pořádku - zpráva obsahuje šifrovanou/podepsanou
         přílohu s požadovanými informacemi:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ? passwd 0
Attachment: TEST_FFF_20171005123456
----------------------------------------------------------------------------

      *  varianta: chyba - veřejný klíč klienta není registrován, správa
         nemůže požadované informace zašifrovat, přílohu nelze odeslat:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ? key 1 unregistered public key, encryption imposible
----------------------------------------------------------------------------

   3.  Přístupové informace klienta jsou uživatelské jméno a heslo.

      o  Každé jméno je jednoznačně a trvale spojeno s unikátním URC. Jméno
         začíná prefixem dle typu prostředí (viz Dodatek A) a končí URC
         klienta. Používají se jen malá písmena a číslice.

      o  Heslo generuje správa jako pseudonáhodnou sekvenci alfanumerických
         (a případně i speciálních) znaků. Každé zaslání příkazu vyvolá
         vygenerování a nasazení nového hesla. Hesla se nikdy neopakují.

   4.  Připravené přístupové informace zapíše správa do textového souboru:

----------------------------------------------------------------------------
login LOGIN
password PASSWORD
----------------------------------------------------------------------------

       Kde za LOGIN dosadí jméno a za PASSWORD heslo uživatele.

   Příklad 1.1.5.x2: Přístupové informace pro testovacího uživatele s URC
   "FFF" zapsané do souboru:

----------------------------------------------------------------------------
login hbtfff
password 57Gx39tZ
----------------------------------------------------------------------------

   5.  Správa vytvoří jméno textového souboru pomocí masky "KEY_TIME.txt",
       kde za KEY dosadí komentář CPoK a za TIME pak časovou značku (formát
       viz Dodatek B). Všechny mezery (" "), případně se vyskytující v KEY,
       budou nahrazeny podtržítky ("_").

   6.  Připravený textový soubor správa zašifruje veřejným klíčem klienta a
       podepíše vlastním CPoK.

   7.  Klient přijme zabezpečený soubor, rozšifruje jej a získá požadované
       informace.

   Příklad 1.1.5.x3: Rozšifrování a kontrola podpisu zabezpečeného souboru
   (výpis byl formátově upraven):

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --output TEST_FFF_20171005123456.txt
> --decrypt TEST_FFF_20171005123456

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID 2742359D, created 2017-10-23 (main key ID EB869180)

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

gpg: encrypted with 2048-bit RSA key, ID 2742359D, created 2017-10-23
      "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
gpg: Signature made Thu 26 Oct 2017 06:55:50 PM CEST using RSA key ID EE21B7
38
gpg: Good signature from "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>"
$
----------------------------------------------------------------------------


1.1.6  Předání IPv4 adres správě

   Tato kapitola popisuje předání IPv4 adres, ze kterých bude klient k
   serveru přistupovat.

   1.  Klient zašle správě příkaz "KEY ! ip", kde za KEY dosadí komentář
       (Comment) CPoK. Do těla zprávy pak vloží jeden nebo více příkazů typu
       "IP +|-", a to každý příkaz na samostatný řádek. Příkazy budou
       provedeny v pořadí, jak budou zapsány. Příkazy jsou na sobě
       nezávislé, výsledek jednoho příkazu neovlivňuje způsob provedení
       dalších.

       Každý příkaz v těle zprávy představuje jeden požadavek na nastavení
       pravidla na IPv4 filtru serveru. Pokud klient požaduje konkrétní
       adresu povolit, pak za ni uvede znak plus ("+"). Pokud požaduje
       povolení ukončit, uvede za ni znak mínus ("-").

   2.  Správa příkaz odbaví odezvou "KEY ! ip RESULT", kde KEY převezme z
       příkazu. Pokud odbaví všechny požadavky uvedené v těle příkazu tak,
       že klient bude uspokojen, pak za RESULT dosadí číslo "0". Jinak
       dosadí hodnotu větší než "0" a konkrétní chyby pak klient nalezne ve
       výsledcích zpracování jednotlivých příkazů v těle zprávy.

       Každý příkaz v těle zprávy je odbaven samostatně a výsledek jeho
       pracování je správou uveden na řádku za příkazem. Pro řádek se
       použije maska "IP +|- RESULT[ ERROR]", kde část odpovídající příkazu
       se převezme ze zprávy příkazce. Pokud je IPv4 adresa formálně správná
       a nastavení se podaří provést, pak se za RESULT dosadí "0". Jinak
       se dosadí hodnota větší než "0" a za ERROR pak případně informace o
       chybě.

   Příklad 1.1.6.x1: Přidání IPv4 adresy 193.85.3.250 do seznamu
   oprávněných k přístupu do testovacího prostředí:

   o  Zpráva obsahující příkaz:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! ip

193.85.3.250 +
----------------------------------------------------------------------------

    o  Zpráva obsahující odezvu:

       *  varianta: vše v pořádku:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! ip 0

193.85.3.250 + 1 rule already exists
----------------------------------------------------------------------------

       Komentář: Přesto, že zpracování požadavku neskončilo bez upozornění
                 (RESULT větší než "0"), došlo k uspokojení všech požadavků
                 klienta, a proto je výsledný RESULT "0".

      *  varianta: chyba - adresa nalezena v seznamu nebezpečných adres:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! ip 2

193.85.3.250 + 2 found in blacklist
----------------------------------------------------------------------------


1.1.7  Převzetí IPv4 adres serveru

   Tato kapitola popisuje postup převzetí IPv4 adres serveru klientem. Pro
   každý typ prostředí může správa použít samostatnou IPv4 adresu. Aktuální
   IPv4 adresy serveru viz Dodatek A.

   1.  Klient zvolí, na základě požadovaného typu prostředí, příslušnou IPv4
       adresu. 


1.1.8  Převzetí veřejných SSH klíčů serveru

   Tato kapitola popisuje postup převzetí veřejných SSH klíčů serveru
   klientem.

   Server poskytuje možnost připojení různým typům klientských programů.
   Programy mohou při navazování spojení používat různé typy veřejných SSH
   klíčů. Volbu konkrétního veřejného SSH klíče provádí klientský program
   automaticky. Signatury veřejných SSH klíčů serveru v závislosti na typu
   prostředí viz Dodatek A.

   1.  Klient zvolí, na základě požadovaného typu prostředí, skupinu
       veřejných SSH klíčů. Signatury pak použije k ověření autenticity
       serveru při úvodním připojení ke svému účtu.


1.1.9  Vytvoření revokačního certifikátu

   Tato kapitola popisuje vytvoření RVC k CPoK. RVC je třeba vytvořit
   bezprostředně po vytvoření CPoK.

   Parametry RVC:

   1.  Název RVC bude obdobný názvu CPoK, zamění se pouze typ souboru z
       KEYENC na KEYERV.

   2.  Důvod revokace se použije nespecifický ("0 = No reason specified").

   3.  Do popisu RVC se uvede komentář (Comment) CPoK.

   4.  Bezprostředně před vytvořením RVC se program dotáže na heslo k CPoK.

   Výstupem programu je RVC ve formátu prostého textu, který se obvykle
   ukládá do souboru s názvem CPoK a příponou ".gpg".

   Příklad 1.1.9.x1: Vytvoření RVC pro CPoK na rok 2018 testovacího
   uživatele s URC "FFF" v programu GnuPG (výpis byl formátově upraven):

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --output FFF_KEYERV_PUB_000001_18.gpg \
> --gen-revoke FFF_KEYENC_PUB_000001_18

sec  2048R/EB869180 2017-10-23 FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@
company.com>

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 0
Enter an optional description; end it with an empty line:
> TEST FFF
>
Reason for revocation: No reason specified
TEST FFF
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID EB869180, created 2017-10-23

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!
$
----------------------------------------------------------------------------


1.1.10 Předání revokačního certifikátu správě

   Tato kapitola popisuje předání RVC klienta správě.

   1.  Klient zašifruje a podepíše RVC. Šifrovat bude pomocí veřejného klíče
       správy. Podepisovat nejlépe CPoK příslušného RVC. Výstupem bude
       zabezpečený soubor stejného názvu jako původní soubor s RVC (formát
       prostý text, přípona ".gpg"), ovšem bez přípony.

   Příklad 1.1.10.x1: Zašifrování RVC z předchozího přikladu:

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --default-key FFF_KEYENC_PUB_000001_18 \
> --output FFF_KEYERV_PUB_000001_18 \
> --sign --encrypt --recipient CNB_KEYENC_PUB_000001_18 \
> FFF_KEYERV_PUB_000001_18.gpg

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID EB869180, created 2017-10-23

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

----------------------------------------------------------------------------

   2.  Klient zašle správě příkaz "KEY ! rvc", kde za KEY dosadí komentář
       (Comment) CPoK. Klient přiloží připravený zabezpečený soubor s RVC.

   3.  Správa příkaz odbaví odezvou "KEY ! rvc RESULT[ ERROR]", kde KEY
       převezme z příkazu. Pokud je odesílatelem příkazu E-MAIL příslušný k
       zaslanému KEY a zabezpečení souboru RVC odpovídá KEY, pak správa za
       RESULT dosadí "0". Jinak dosadí hodnotu větší než "0" a za ERROR pak
       případně informaci o chybě.

   4.  Validní RVC správa zaeviduje k CPoK.

   Příklad 1.1.10.x1:

   o  Zpráva obsahující příkaz:

----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! rvc
Attachment: FFF_KEYERV_PUB_000001_18
----------------------------------------------------------------------------

   o  Zpráva obsahující odezvu:

----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! rvc 0
----------------------------------------------------------------------------


1.2  Připojování

   Tato kapitola popisuje způsoby připojování klienta k serveru. První
   podkapitola popisuje úvodní připojení, druhá pak připojování následná.

   Odlišnost úvodního od následných připojení spočívá v tom, že při úvodním
   připojení nemá klient uložen veřejný klíč serveru potřebný k zahájení SSH
   spojení. Proto je velmi doporučeno, aby klient v rámci úvodního připojení
   pečlivě překontroloval, že signatura, kterou mu (v tom okamžiku naprosto
   neznámý) server na základně jeho pokusu o SSH připojení nabídne, je
   skutečně registrovanou signaturou zamýšleného hostitele (serveru). Na
   základě úspěchu takové kontroly je pak možno příslušnému serveru
   důvěřovat a jeho veřejný klíč nechat klienta uložit do interního seznamu
   důvěryhodných SSH serverů.

   Následná připojení pak při řešení důvěryhodnosti hostitele mohou uvedený
   interní seznam využívat místo dotazování se uživatele.

   Poznámka: Klientský program připouští takové nastavení, při kterém nejsou
             signatury ověřovány a automaticky se jim důvěřuje. Před takovým
             nastavením správa serveru však důrazně varuje!

   K připojování potřebuje uživatel program, SFTP klienta [3]. Programu je
   třeba vždy zadat argumenty sloužící pro identifikaci komunikujících
   stran:

   o  Hostname
         IPv4 adresa nebo DNS SFTP serveru. Hodnoty v závislosti na typu
         prostředí viz Dodatek A.

   o  Port
         TCP port na kterém SFTP server očekává připojení klienta. Hodnoty
         viz Dodatek A.

   o  User
         Uživatelské jméno klienta viz kapitola 1.1.5.


1.2.1  Úvodní připojení

   Tato kapitola popisuje úvodní připojení klienta k serveru. Za úvodní se
   připojení považuje vždy, když signatura poskytnutá ze serveru neodpovídá
   signatuře očekávané klientem. Klient buď signaturu pro server zatím nemá
   nebo na serveru došlo ke změně příslušného veřejného SSH klíče anebo se
   klient připojuje k hostiteli, který se za server pouze vydává.

   1.  Klient zahájí připojování pomocí programu, kde kromě stálých
       argumentů uvede navíc argument "StrictHostKeyChecking=ask", který
       zajistí, že pokud server poskytne dosud neevidovaný veřejný klíč, pak
       program vyzve uživatele k validaci jeho signatury. Validní veřejné
       klíče uloží program do seznamu a připojování dokončí.

   Příklad 1.2.1.x1: Zahájení připojování pomocí programu sftp (výpis byl
   formátově upraven):

----------------------------------------------------------------------------
$ sftp -oPort=6710 -oUser=hbtfff -oStrictHostKeyChecking=ask hub-t.cnb.cz
The authenticity of host 'hub-t.cnb.cz (193.84.159.120)' can't be establishe
d.
RSA key fingerprint is 41:82:f9:64:62:c7:b6:0e:3c:89:60:8f:8c:ad:89:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'hub-t.cnb.cz' (RSA) to the list of known hosts.
hbtfff@hub-t.cnb.cz's password:
sftp>
----------------------------------------------------------------------------


1.2.2  Následná připojení

   Tato kapitola popisuje následná připojování klienta k serveru. Za
   následné se připojení považuje vždy, když signatura poskytnutá ze serveru
   odpovídá signatuře očekávané klientem. Klient pak přímo použije veřejný
   klíč k připojení a nevyžaduje žádnou interakci od uživatele.

   1.  Klient se připojí pomocí programu, kde uvede jen identifikační
       argumenty.

   Příklad 1.2.1.x2: Připojení pomocí programu sftp (výpis byl formátově
   upraven):

----------------------------------------------------------------------------
$ sftp -oPort=6710 -oUser=hbtfff hub-t.cnb.cz
hbtfff@hub-t.cnb.cz's password:
sftp>
----------------------------------------------------------------------------


2  Uživatelský účet

   Tato kapitola popisuje uživatelský účet klienta na SFTP serveru. První
   podkapitola popisuje domovský adresář uživatele, druhá adresářový strom
   nalézající se v tomto adresáři a třetí pak soubory, které může klient na
   serveru ukládat anebo si z něj kopírovat.


2.1  Domovský adresář

   Tato kapitola popisuje domovský adresář uživatele. Domovský adresář je
   výchozím adresářem po přihlášení uživatele. Každý domovský adresář je
   dedikován právě jednomu uživateli. Oprávnění jsou nastavena tak, aby
   domovský adresář (včetně všeho co obsahuje) nebyl přístupný jinému
   uživateli, a to žádným způsobem. Cílem je úplná vzájemná izolace
   jednotlivých uživatelů. Domovský adresář a jeho obsah jsou určeny jen
   pro čtení.

   Příklad 2.1.x1: Výpis cesty k domovskému adresáři:

----------------------------------------------------------------------------
sftp> pwd
Remote working directory: /
sftp>
----------------------------------------------------------------------------


2.2  Adresářový strom

   Tato kapitola popisuje adresářový strom, který má kořen v domovském
   adresáři uživatele.

   Adresářový strom každého uživatele vypadá takto:

      /
      ├── archive
      │   ├── incoming
      │   └── outgoing
      ├── incoming
      ├── outgoing
      └── public

   Jednotlivé adresáře a podadresáře mají tento význam:

   o  archive
         neobsahuje žádné soubory, obsahuje dva podadresáře, jeho účelem
         je krátkodobé (nízké desítky dnů) ukládání kopií souborů, pro
         které je uživatel příjemcem nebo odesílatelem.

   o  archive/incoming
         obsahuje kopie souborů, pro které je uživatel příjemcem.

   o  archive/outgoing
         obsahuje kopie souborů, pro které je uživatel odesílatelem.

   o  incoming
         obsahuje soubory, pro které je uživatel příjemcem.

   o  outgoing
         obsahuje soubory, pro které je uživatel odesílatelem.

   o  public
         obsahuje soubory zveřejněné správou.


2.3  Soubory

   Tato kapitola popisuje soubory používané pro komunikaci mezi klientem
   a správou (serverem). První podkapitola popisuje jmennou konvenci
   zavedenou pro názvy souborů, druhá postup přípravy a odeslání souboru,
   třetí postup příjmu a zpracování souboru a čtvrtá pak formální chyby,
   které mohou při komunikaci vzniknout.


2.3.1  Jmenná konvence

   Tato kapitola popisuje jmennou konvenci zavedenou pro zapisování názvů
   souborů. Konvence je závazná pro všechny soubory, které se na serveru,
   respektive na uživatelském účtu nacházejí. V případě adresáře "public"
   je případná změna, po oznámení uživatelům, vyhrazena.

   Maska souboru "AAA_BBBBBB_CCC_DDDDDD_EE[_FFFFFFFFFFFFFF].zip" obsahuje
   základní masku (tedy segmenty "A" až "E") a rozšíření (segment "F")
   poskytované serverem k vyznačování okamžiku, kdy byl soubor na serveru
   zaznamenán. Segmenty mohou obsahovat jen písmena velké abecedy bez
   diakritiky a číslice. Přípona ".zip" je implicitní pro zabezpečené
   a/nebo komprimované soubory. Přípona ".xml" je pak implicitní pro
   otevřené formy těchto souborů. Jednotlivé segmenty masky mají tento
   význam:

      AAA
         URC odesílatele

      BBBBBB
         kód typu obsahu souboru viz kapitola 3.1

      CCC
         URC příjemce

      DDDDDD
         pořadové číslo souboru v rámci aktuálního kalendářního roku,
         sekvence v rozsahu 000001 až 999999

      CC
         poslední dvojčíslí aktuálního letopočtu

      FFFFFFFFFFFFFF
         časová značka (formát viz Dodatek B)


2.3.2  Odesílání souboru - hlášení

   Tato kapitola popisuje postup přípravy a odeslání souboru. Soubor
   odesílaný uživatelem na server se také nazývá hlášení.

   1.  Klient připraví soubor s obsahem, který odpovídá některému z typů
       předepsaných k odesílání a pojmenuje jej v souladu se jmennou
       konvencí (použije základní masku). Soubor bude vytvářen v otevřené
       formě, a proto bude mít příponu ".xml".

   2.  Hotový soubor klient zašifruje pro příjemce a podepíše za
       odesílatele. Jméno souboru zůstane stejné, změní se pouze přípona na
       ".zip".

   Příklad 2.3.2.x1: Příprava souboru dat typu "DATT10", odesílatel "FFF",
   příjemce "CNB", jde o soubor s pořadovým číslem 54 v rámci roku 2018.
   Byl použit program GnuPG:

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --default-key FFF_KEYENC_PUB_000001_18 \
> --output FFF_DATT10_CNB_000054_18.zip \
> --sign --encrypt --recipient CNB_KEYENC_PUB_000001_18 \
> FFF_DATT10_CNB_000054_18.xml

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID EB869180, created 2017-10-23

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

----------------------------------------------------------------------------

   3.  Zabezpečený soubor klient uloží do adresáře "outgoing" na svém
       uživatelském účtu na serveru.

   Příklad 2.3.2.x2: Odeslání souboru připraveného v předchozím příkladu.
   V příkladu bude použito testovací prostředí, účet uživatele "FFF" bude
   tedy "hbtfff@hub-t.cnb.cz". Byl použit program sftp:

----------------------------------------------------------------------------
sftp> put FFF_DATT10_CNB_000054_18.zip outgoing/
sftp>
----------------------------------------------------------------------------

   4.  Po dokončení ukládání souboru jej server přejmenuje (doplní časovou
       značku) a přenese do adresáře "archive/outgoing".

   Příklad 2.3.2.x3: Uložení souboru z předchozího příkladu do archivu:

----------------------------------------------------------------------------
sftp> ls archive/outgoing/
archive/outgoing/FFF_DATT10_CNB_000054_18_20171031130354.zip
sftp>
----------------------------------------------------------------------------

   5.  Obsah adresáře "archive/"outgoing" pravidelně kontroluje program
       běžící v interním prostředí ČNB. Nově nalezené soubory kopíruje
       do zabezpečeného interního prostředí, kde dále proběhne jejich
       zpracování. Výsledek zpracování je pro klienta zapsán do souboru
       odezvy. Tento soubor je vytvářen ve formátu prostého textu, použije
       se přípona ".xml". Následuje zabezpečení souboru šifrou pro klienta a
       vlastním podpisem, použije se přípona ".zip". Nakonec je do názvu
       souboru připojena časová značka (formát viz Dodatek B). Zabezpečený
       soubor program překopíruje do adresářů "incoming" a
       "archive/incoming".


2.3.3  Přijímání souboru - odezva

   Tato kapitola popisuje postup příjmu a otevření zabezpečeného souboru.
   Soubor přijímaný uživatelem prostřednictvím serveru se také nazývá
   odezva.

   1.  Klient nalezne zabezpečený soubor v adresáři "incoming". Technicky
       použije běžný výpis adresáře.

   Příklad 2.3.2.x1: Výpis adresáře "incoming":

----------------------------------------------------------------------------
sftp> ls incoming/
incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip
sftp>
----------------------------------------------------------------------------

   2.  Klient okopíruje soubor z adresáře "incoming" na serveru do svého
       prostředí. Ukončení kopírování detekuje program a automaticky soubor
       z adresáře "incoming" odstraní. Soubor je pak i nadále k dispozici v
       adresáři "archive/incoming".

   Příklad 2.3.2.x2: Kopírování souboru z adresáře "incoming" (výpis byl
   formátově upraven):

----------------------------------------------------------------------------
sftp> get incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip
Fetching /incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip to CNB_FDBT10
_FFF_000054_18_20171031162459.zip
/incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip 100% 980 9.8MB/s 00:00
sftp>
----------------------------------------------------------------------------

   3.  Klient na zabezpečeném souboru může zkontrolovat podpis odesílatele,
       a to v rámci operace rozšifrování, jejímž výstupem je soubor s
       odezvou v otevřené podobě.

   Příklad 2.3.2.x3: Rozšifrování odezvy pomocí programu GnuPG. Program
   při "otevírání" souboru vypíše jak veřejný klíč, který byl odesílatelem
   použit k zabezpečení diskrétnosti obsahu (obsah může takto otevřít jen
   držitel příslušného CPoK), tak CPoK, který odesílatel použil k podepsání.
   Pokud by signatura nepocházela z nevalidního nebo neznámého CPoK,
   program by o této věci vypsal pro příjemce varování. Odezvu v otevřeném
   tvaru program zapíše do souboru s příponou ".xml":

----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --decrypt CNB_FDBT10_FFF_000054_18_20171031162459.zip \
> --output CNB_FDBT10_FFF_000054_18.xml

You need a passphrase to unlock the secret key for
user: "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
2048-bit RSA key, ID 2742359D, created 2017-10-23 (main key ID EB869180)

------------------- Zde očekávejte výzvu k zadání hesla. -------------------

gpg: encrypted with 2048-bit RSA key, ID 2742359D, created 2017-10-23
      "FFF_KEYENC_PUB_000001_18 (TEST FFF) <contact@company.com>"
gpg: Signature made Thu 26 Oct 2017 06:55:50 PM CEST using RSA key ID EE21B7
38
gpg: Good signature from "CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>"
$
----------------------------------------------------------------------------


2.3.4  Formální chyby při komunikaci

   Tato kapitola popisuje formální chyby při komunikaci. Za formální chyby
   při komunikaci se považují:

   o  nedodržení jmenné konvence, viz kapitola 2.3.1:

      *  HUB-001
            chyba ve struktuře názvu, nesprávný počet nebo délka
            jednotlivých segmentů názvu.

      *  HUB-002
            chybný odesílatel, URC nesouhlasí s názvem klientského účtem.

      *  HUB-003
            chybný příjemce, musí být "CNB"

      *  HUB-005
            chybný kód typu obsahu souboru, viz kapitola 3.1.

   o  HUB-006
         překročení maximální velikosti souboru, viz Dodatek B.

   o  HUB-007
         překročení kvóty klientského účtu, viz Dodatek B.

   Nedodržení těchto pravidel blokuje normální zpracování souboru. Program
   v takovém případě vygeneruje soubor s typem obsahu "FBDHUB", odesílatel
   "CNB", příjemce určí na základě domovského adresáře, kde soubor získal,
   pořadové číslo souboru odezvy v rámci roku a letopočet pak vygeneruje.
   Do souboru zapíše zjištěné chyby. Struktura souboru odpovídá XML Schema
   [4].

   Poznámka: Kódy HUB-XXX uvedené v seznamu výše odpovídají kódům, které v
   rámci systému HUB používá ESMA.


3  Podpora komunikace v rámci MiFID/MiFIR

   Tato kapitola popisuje způsob podpory komunikace v rámci MiFID/MiFIR.
   První podkapitola popisuje podporované specifikace ESMA a metodiky ČNB,
   druhá zásady pro zpracování obsahů, třetí pak předepsaný obsah BAH.


3.1  Specifikace ESMA a metodiky ČNB

   Tato kapitola popisuje specifikace ESMA a metodiky ČNB, které definují
   obsahy souborů podporovaných aktuální implementací serveru. V
   následujícím seznamu jsou pro každý obsah kromě základních
   identifikačních údajů uvedeny kódy typů souborů pro hlášení i odezvy a
   předepsané zabezpečení:

   o  Hlášení souhrnných pozic v komoditních derivátech, povolenkách na
      emise a jejich derivátech

      *  Specifikace ESMA: [4]

      *  Metodika ČNB: MKT20180103/KOMFIM10/KOM (ČNB) 10-52

      *  Kód typu obsahu souboru hlášení/odezvy: DATK10/FDBK10

      *  Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem

   o  Informace o obchodech s investičními nástroji podle čl. 26 MiFIR

      *  Specifikace ESMA: ESMA/2016/1521 Technical Reporting Instructions,
         MiFIR Transaction Reporting [4]

      *  Metodika ČNB: MKT20180103/TRAFIM10/FIM (ČNB) 10-97

      *  K typu obsahu souboru hlášení/odezvy: DATT10/FDBT10

      *  Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem

   o  Informace o uzavřených, vypořádaných a zrušených obchodech a převodech

      *  Specifikace ESMA: N/A

      *  Metodika ČNB: MKT20180103/TRAFIM20/FIM (ČNB) 20-97

      *  K typu obsahu souboru hlášení/odezvy: DATT20/FDBT20

      *  Zabezpečení: šifrováno pro příjemce, podepsáno odesílatelem


3.2  Zásady pro zpracování obsahů

   Tato kapitola popisuje zásady pro zpracování obsahů. Zpracováním obsahů
   se v případě hlášení rozumí provedení veškerých úkonů po technickém
   otevření zabezpečeného souboru. V případě odezvy jsou to veškeré úkony
   před technickým zabezpečením souboru.

   Obsahy jsou z pohledu serveru nedostupné, vlastní otevření/zabezpečení
   provádí programy umístěné v zabezpečeném interním prostředí ČNB. Mimo
   tento perimetr není otevřený obsah přípustný.

   Interní programy pak zpracování obsahů zahajují jejich zafrontováním,
   a to primárně vždy podle kódu typu obsahu a sekundárně podle časové
   značky přidělené souboru při jeho ukládání klientem na server.

   Vlastní zpracování obsahu sestává typicky z těchto kroků:

   1.  Kontrola obsahu vůči XML Schema.

   2.  Uložení obsahu do databáze.

   3.  Provedení vstupních/synchronních kontrol dle specifikace/metodiky.

   4.  Nastavení stavových příznaků na jednotlivých řádcích i souboru.
       Stavový příznak definuje následující operace aplikovatelné na
       předmětné řádky či soubor.

   5.  Vyzvednutí výsledků asynchronních kontrol pro soubory stejného
       klienta doručené v předchozích dnech.

   6.  Spojení výsledků obou typů kontrol do společného obsahu jedné odezvy.

   Úspěšné dokončení každého kroku je nutnou podmínkou k zahájení kroku
   následujícího. Pokud obsah neprojde testem vůči XML Schema, pak obsah
   nelze uložit do databáze a jeho zpracování tak vlastně končí. Pokračuje
   se pak až sestavováním odezvy.

   Kromě uvedeného synchronního zpracování existuje také zpracování
   asynchronní, které provádí program v závislosti na splnění jiných
   podmínek automaticky. Jde například o validace nástrojů vůči FIRDS.


3.3  Specifický obsah BAH

   Tato kapitola popisuje obsah BAH, jehož stanovení spadá do kompetence
   národního regulátora. Doporučení pro definování předpisu plnění viz
   ESMA/2016/1521 [4], kapitola "6.4 Business Application Header".

   Předpisy plnění pro jednotlivé elementy jsou zde:

   o  Business Message Identifier "BizMsgIdr"
         bude sestaven z části názvu souboru odpovídající podle jmenné
         konvence (viz kapitola 2.3.1) segmentům "A" až "E". Pokud nastane
         situace, kdy bude k jednomu hlášení nutno vytvořit postupně více
         odezev (jde konkrétně o vývoj stavu řádku v kontextu opakujících
         se (asynchronních) kontrol nástrojů vůči FIRDS) aniž by bylo v
         daném čase k dispozici jiné hlášení, které by poskytlo svoji odezvu
         jako obálku pro obsah této odezvy, pak bude shora popisovaný
         element, z důvodu zachování své (globální) unikátnosti, sufixován
         vždy jedním znakem z posloupnosti "0" až "9" a pak "A" až "Z".

   Příklad 3.3.x1: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro
   hlášení:

   <BizMsgIdr>FFF_DATT10_CNB_000054_18</BizMsgIdr>

   Příklad 3.3.x2: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro
   odezvu:

   <BizMsgIdr>CNB_FBDT10_FFF_000054_18</BizMsgIdr>

   Příklad 3.3.x3: Ukázka elementu "BizData/Hdr/AppHdr/BizMsgIdr" pro
   případnou první navazující odezvu:

   <BizMsgIdr>CNB_FBDT10_FFF_000054_180</BizMsgIdr>

   o  Message Definition Identifier "MsgDefIdr"
         bude odpovídat výchozímu schématu pro daný typ obsahu, jak jej
         definují příslušné specifikace ESMA [4]. Žádná specifická XML
         Schema nebudou zavedena.


Reference

   [1]  http://openpgp.org/

   [2]  http://gnupg.org/download  verze>=2.0

   [3]  https://www.openssh.com/

   [4]  https://www.esma.europa.eu/policy-rules/mifid-ii-and-mifir/
        /mifir-reporting-instructions


Kontakt na správu

   hub@cnb.cz
   www.cnb.cz


Dodatek A.  Parametry serveru

   1.  Značení prostředí:

       Prostředí Kód  Prefix
       --------- ---- ------
       produkční PROD hb
       testovací TEST hbt

   2.  Veřejné klíče a signatury podle prostředí a letopočtu:

      o  produkční:

         *  2018

$ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_18
pub   2048R/A936795A 2017-11-05 [expires: 2019-01-31]
      Key fingerprint = CD87 AF4F E7C2 1330 A168  6429 1265 9EA8 A936 795A
uid                  CNB_KEYENC_PUB_000001_18 (PROD CNB) <hub@cnb.cz>
sub   2048R/07E8D48D 2017-11-05 [expires: 2019-01-31]

$ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_18
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)

mQENBFn/dCYBCADKEYO4tNtyMzTl9+j5qZmCViUDMwHemJI5gD7vc4Cy9p6XGYBz
E/Cl4tCp1IHCqHBCzuJXYwGTxPWqejBtY0H+Yfmn9hq/UqC2IqCD53URfq+YTWwj
u97K5CjTYJnTpNtKhwiwjnS6EmER1LCO3mcuJcQta13hONc3yO0PcQdzb+AI/UJU
X48kNsb3c8IV/zXLOwJWfNocYQhTb8JMhYATIbPwPND6v3PUu+3IV4l6w0RpaiBN
ssc7cT/aNsMEApnGHeuuTkk8vHORy6d/hSB8Bgwh3Y1x8pEYcfPIbnLeJ/ZzfJSB
Lg241GHgcNfWPwaqeQr8gWmX6NF1ApJMjfIXABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8xOCAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPgQTAQIAKAUCWf90
JgIbAwUJAlPmAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQEmWeqKk2eVr6
dwgAisvTexaHzNTq/aRiSLNcdfflxpv9w0QwzTzaKQLGo9oqXlAWsXa7RWdInZED
qcc/8zRoV/Oa7IId3Q+K5f5OngQlvtBns4GQHmFugyoja0lne78GgG8ttMp1OMPy
u8I/GYwWSXUozHe3oi1OPAtovlNLH8tUOdZTHE0nkOJE1klUX/7n0CDn4EptuJh/
8/VCX2Xp1sTsslmJd5ExmwOjr+xsdoV7YGVgwGs+Ugo8LQ7NyYEcrxXBYPv0cuoU
7lAZ+72KtW08XoOJ5NXd5v68r+mCIg8AfL+F38UgnPUxxat2VylAaSTG+yTLKGsc
UX8lYr15pGDk1TfE85lnjNrKS7kBDQRZ/3QmAQgAuVIh9N0Jm0tpXmfhGMqKKICx
42Qcz8d3vwSBWSiTSlGMRlufO9cAZxpajx56Gd2RTO8Fup3FJrY6Yt9NLoDtCjg2
w2+MU/Oxw368WHHTWJFdONtsTeVVHGM1VSC6tXdU0fNwdYDdQOBJJl6f2pB1OM01
qmGlVH+PUH3F2UJmUWTO8wx/lvbkT9ZwP/a9YDPP/9qibJxFWrMjukdm2n2MVHsn
wgWYlAdeh4qflSX3/8gTkd8f/csBga//2IGBAGk9XW97RHtRgk6hgIUgaeveIQlw
yTh0NvX+Wd7vyZJGyd4fP/sUJKiYDhhS8XMog4SUGxYo49nUxmCFgPf1FVctmQAR
AQABiQElBBgBAgAPBQJZ/3QmAhsMBQkCU+YAAAoJEBJlnqipNnlajDYIALYF+FWJ
jF+BezoTK7sEATFTcCJV2T6RUweMBI+q/vc3/NgM8LOu874tYLvlSgWUNA3vEdRE
9diB1hOnMwXdXdAHmkBeCp3/m4vKAIebceEUVLFsAKjg82LlI/CjKnL+g/pLU6uM
Fury4HJyUVtxBtNK9FPK399wsEYrS5I1AiNP4e7kXJ8ltud4lTbWiQNO+Nk8G9wE
uhFzY4Dy89YYtTLquPNQt8jLqLoGURxYBl3ewh9evK97YJUAZ6jNpOZ1K87ubbsq
5ht9LtKpiBD2VbFjlwLrZT75Yn8EUK6gu1Qzg14/98ECcE/M9wiViN9GQUy4LKdg
y5DGtkR/Fs6E4ZE=
=47mr
-----END PGP PUBLIC KEY BLOCK-----
$ 

      o  testovací:

         *  2018

$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_18
pub   2048R/7BC65C25 2017-11-05 [expires: 2019-01-31]
      Key fingerprint = E7AB EE78 0A71 B510 9AB4  CE6D 125D DDAE 7BC6 5C25
uid                  CNB_KEYENC_PUB_000001_18 (TEST CNB) <hub@cnb.cz>
sub   2048R/EC0B70CB 2017-11-05 [expires: 2019-01-31]

$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_18
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.14 (GNU/Linux)

mQENBFn/fGIBCADACyoW2/zFd97aUIzk7M41dxjbYUbehKnljRY5m6B4fRVAd+aQ
OukF41ENPi33b1YxU7kxMtvZp945a6qojxVSCeFFUG/oN3Kpm1wMkJhC8D2PRTqc
aZHA4lF8TBkD58Qhmp2N7+pVgVBS9f9OQZEvrN/2Pl1oy3YQtLa1V6m4ITO5ArCf
EDDH5zVr1AjvKcIDNi2qzIqSF901N1s/7b8+xLT+C2bxBdFgkWcdsZEPQnapgFR1
hGBTGT+QtpLiHV/bEKS64/ytnhjMOzR3oW3KwO4f0W5f0kihA3gI1xc8O+dfn3X/
TkVMFXtpUI/xFD/wkZtKwlWOZMawPaQdfZJTABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8xOCAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPgQTAQIAKAUCWf98
YgIbAwUJAlPmAAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQEl3drnvGXCVp
Jwf8DzAb5BQ28d0pwfPdYSJTd4av9Fd+XeYd0XfSA+QTrG6xXhOC3820ophPVq5Z
fBS7k0RmaYIFTiogC91N+Ymabmj6qgc/OjmTK74RYnviTiRLeE7iXlbjdZ39IonJ
URWdwcR/uL9bwOTUUh3CmZYaZ+HU5VC0hbb/qq8NbbQCtk3UPCw38XyUePCDrzHY
jcu7p0Qb91EjCwVBaoQjYPeJIc1lEfcsf19R6ClFsvgSQlldQLV8NeqKv/sW9fV9
TP1SojjQCHL0bFsRC36NeeRNBbPWaWL0K2dp+5sQgTryZ636kSABPV9CKlMfz+RY
M4XboceE3f3Y2MsxupkBfeFDlrkBDQRZ/3xiAQgAtVptFY+ug22nBdHkNl145Yxw
ktIFsUgT0ApDi7zKolJU7Ef3DcnxuPcWgiTBHT2XUiKc52UG9Dl/Ls+LNZIn7snM
jhDiip7Mb7FjxbD12HZktcfJMBs732bFXwDnZ0NAD4zFUyaolFOeAPToPf/kBaN2
t0if0dMFkTX+SARoTpyWBaV36RkaZSKU2AkZPncmdGaDCxQPothxuwGsIwonMjO3
uE/dxqkjCrF4DD8CzJJjAseZo/EGGjN4QWuUAH/vTqiqR6GdZPF53BRPNppTdzkF
vyU3zrKOh18sI9ISscu/GcqBfi+2NphccejdhXr0Od0dhxfLUU1UV/9ZNakN0wAR
AQABiQElBBgBAgAPBQJZ/3xiAhsMBQkCU+YAAAoJEBJd3a57xlwl5bgH/1QT0YwJ
sf+C5cnJBw4ROz/fbExXDYurSnWnRIMcbL6IxqePPn1yItnhKZZYDVjv+5cBW5pP
bQGVRqMVw8Ikh0PUba5J39IMcQKfr9/Mowo0DyqsszQXfqYd9adW5bqEUsgCg2Lf
gMRTXfpJBm+qSlGJVAWDnT3Sac8TyQIcURm/WVcRlAlpcXzP+Vl6M7flHgbrMrbO
lJPsXif7N74L4kGXMlIR+35nQf56y3RVhZuVwcQU/1WvNVqAGXtAz04b5Lfu5vGw
BVGacbnk2Iv3w5WxZ1ryYOd5C9YDTnBzw0SI3PuxwTOg92gJVwT1+hgqLBdw5rax
iPZpNGDOH9BsfJM=
=yRYI
-----END PGP PUBLIC KEY BLOCK-----

   3.  IPv4 adresy/hostname a TCP porty podle prostředí:

      o  produkční: hub.cnb.cz(193.84.159.117):6710

      o  testovací: hub-t.cnb.cz(193.84.159.118):6710

   4.  Signatury SSH veřejných klíčů serveru:

      o  uzel 0:

         *  256 MD5:6e:07:41:73:91:b8:b9:e8:54:8a:5e:65:29:e0:33:d6
            (ECDSA)

         *  256 MD5:15:b3:8a:4f:88:f9:cf:28:34:bc:c2:7f:35:a1:61:0c
            (ED25519)

         *  2048 MD5:60:8c:6e:2c:ae:d2:fe:ee:8e:7b:ff:5d:48:ab:09:13
            (RSA)

      o  uzel 1:

         *  256 MD5:3a:03:79:02:4e:72:f0:60:b5:50:46:a3:71:44:9d:1c
            (ECDSA)

         *  256 MD5:ab:a6:1a:3e:a2:9b:eb:c1:f9:da:45:b7:3a:a3:cf:ad
            (ED25519)

         *  2048 MD5:9b:fa:ae:89:f6:ac:f6:ad:75:fd:3c:18:f2:c7:ef:97
            (RSA)


Dodatek B.  Formáty, rozsahy a limity

   1.  Formát časové značky (POSIX): %Y%m%d%H%M%S. Například datum a čas
       "5. října 2017 12:34:56" budou zapsány takto: 20171005123456.

   2.  URC je technicky trojmístné hexadecimální číslo. Může nabývat 4096
       různých hodnot, z toho rozsahy "000" až "A00" a "FF0" až "FFF" jsou
       reservovány pro správu. Zbývající hodnoty v rozsahu "A01" až "FEF"
       jsou k dispozici pro klienty.

   3.  Maximální velikost souboru na SFTP serveru je stanovena na 50MB.

   4.  Kvóta klientského účtu je stanovena na 10GB.


Dodatek C.  Dodatečné ověření identity {přechodné}

   Tento dodatek popisuje dodatečné ověření identity klienta správou. Tento
   postup je předepsán pro klienty, kteří zasílají data dle kapitoly 3.1
   prostřednictvím SDNS a zároveň chtějí zpětně odbírat datové soubory z
   těchto dat sestavené, a to ve formátu dle specifikace uvedené v kapitole
   3.1.

   Poznámka: Požadavek na získávání dat ze serveru je zásadně odlišný od
             původního záměru, kdy klient zabezpečené datové soubory na svůj
             účet ukládal sám a měl tak nad jejich obsahem výhradní
             kontrolu. Nově je požadováno poskytnout klientovi datový
             soubor, jehož obsah nebyl pořízen klientem serveru. Proto je
             třeba ověřit, že klient je oprávněn k takovým datům
             přistupovat.

   Předpokladem pro zahájení dodatečného ověření identity klienta je úspěšné
   získání přístupu k serveru (viz kapitola 1).

   1.  Klient oznámí správě záměr využívat možnost zpětného odběru datových
       souborů. Forma oznámení není stanovena.

   2.  Správa předá věcně příslušnému správci sběru (dále VS) LEI zájemce.

   3.  VS vyzve zájemce prostřednictvím jiného kontaktu k předání signatur
       CPoK všech klíčů, které chce klient ověřit. Typicky jde o aktuální
       CPoK do testovacího a produkčního prostředí.

   4.  Dodané signatury předá VS správě serveru, která zajistí jejich
       ověření a o výsledku informuje VS.

   5.  Pro účty používající ověřené signatury správa nastaví automatický
       zpětný odběr souborů.