Czech National Bank (CNB) Jaroslav Zatloukal
Version: 0.9.20210111 CNB
Replaces: N/A November 2017
Category: User manual
Manual for users of SFTP server HUB.CNB.CZ
Status
This document contains information for users who are considering sending
content prescribed by MiFID/MiFIR through the SFTP server of the NCA CNB.
Summary
This document contains the user manual for the client of the server
HUB.CNB.CZ (hereinafter referred to as the "server"). The server contains
a number of separate environments meant for the exchange of secure
content (or files) between the client and applications on the side of the
NCA.
The server provides a general interface for the mutual transfer of files.
The goal of its implementation was to add a channel fulfilling the
requirements placed on the NCA by ESMA specifications to the portfolio of
existing collection channels that CNB currently has at its disposal.
Abbreviations
BAH business application header (ESMA)
CPoK cryptographic pair of keys
DNS domain name system
ESMA European Securities and Markets Authority
FIRDS Financial Instrument Reference Data System
IPv4 Internet protocol version 4
MiFID Markets in Financial Instruments Directive
MiFID Markets in Financial Instruments Regulation
N/A not applicable
NCA national competent authority
OS operating system
RHEL Red Hat Enterprise Linux
RVC revocation certificate
SFTP secure file transfer protocol
SSH secure shell
TCP transmission control protocol
URC unique registration code
XML extensible markup language
Terms
E-MAIL
registered contact e-mail
server
SFTP server HUB.CNB.CZ
admin [of server]
group of administrators working under a joint address
XML Schema
https://www.w3.org/XML/Schema
ZIP
file content format containing data compression and possibly security
(encryption)
Contents
Introduction
1 Access to server
1.1 Preparation for connection
1.1.1 Initial contact with admin
1.1.2 Creation of cryptographic pair of keys
1.1.3 Transmission of public key to admin
1.1.4 Receipt of public key from admin
1.1.5 Receipt of account usernames and passwords
1.1.6 Transmission of IPv4 address to admin
1.1.7 Receipt of server’s IPv4 address
1.1.8 Receipt of server’s public SSH keys
1.1.9 Creation of revocation certificate
1.1.10 Transmission of revocation certificate to admin
1.2 Connecting
1.2.1 Initial connection
1.2.2 Subsequent connections
2 User account
2.1 Home directory
2.2 Address tree
2.3 Files
2.3.1 Naming convention
2.3.2 Sending a file - report
2.3.3 Receiving a file - response
2.3.4 Formal errors during communication
3 Support of communication within MiFID/MiFIR
3.1 ESMA specifications and CNB methodology
3.2 Principles for preparing content
3.3 Specific BAH content
References
Contact to admin
A Server parameters
B Formats, scopes and limits
Introduction
This document describes how to operate user communication as a client of
the SFTP server HUB.CNB.CZ. This document has three goals:
1. To provide a description of the functionality of the server
sufficient for the deliberate and secure use of a user account by the
client.
2. Several examples and detailed procedure descriptions make it possible
for users to use this document as an instruction manual, where the
client can find a concrete solution without lengthy introductions.
3. To systematically provide complete information on the total life
cycle of the submitted solution thanks to the versioning, which
permits the full historization of the content as a document of itself
and of linked resources.
This document is divided into three parts. The first describes the access
to the server, from the initial contact with the admin to the transition
to routine operations. The second chapter describes the user account
interface on the server, both structurally (address tree), and
procedurally (work with files). The third chapter describes the support
that the server provides by the concrete implementation defined within
MiFID/MiFIR.
The entire text is formally arranged so that all the concrete information
is not explicitly specified in the text, but is only linked to the
appendices from the text.
The examples used in this document were created in the environment of the
RHEL 6 operating system. The programs used are from the family of open
source software and are available for other common OSs as well.
1 Access to server
This chapter describes the access to the server from the client’s
perspective. Its first sub-chapter describes the client’s preparation for
the connection. In this phase the client communicates with the
administration. Thus there is a mutual exchange of information necessary
for determining the security of further communication. The second
sub-chapter describes the user’s actual connection to the server using
the client’s SFTP.
1.1 Preparation for connection
This chapter describes the client’s preparation for the connection. Its
first sub-chapter describes the client’s initial contact with the admin,
the second the creation of the client’s cryptographic pair of keys, the
third the transmission of the client’s public key to the admin, the
fourth the client’s receipt of the admin’s public key, the fifth the
receipt of the usernames and passwords for the accounts on the client
server, the sixth the transmission of the client’s IPv4 address to the
admin, the seventh the client’s receipt of the server’s IPv4 address, the
eighth the client’s receipt of the server’s public SSH keys, the ninth
the creation of the client’s revocation certificate and the tenth the
transmission of the revocation certificate to the admin.
Communication between the client and the admin takes place by e-mail. The
messages should be in plain text format. The structure of the message is
strictly prescribed; giving other information than that which is
explicitly requested in the procedures below can lead to a delay in the
period for processing the relevant requests. Both sides use their E-MAILs
(if E-MAIL is written in capitals, it means the registered contact
e-mail). The initiator of the communication enters structured text into
the subject of the message, which is interpreted by the recipient as a
command with arguments, if necessary. The recipient processes the request
and responds to the sender with, once again, structured text in the
subject. In some cases the body of the message is used in a similar
manner.
1.1.1 Initial contact with admin
This chapter describes the client’s initial contact with the server
admin. In this manner the client submits the LEI and the E-MAIL of the
reporting subject to the admin. If the E-MAIL is identical to the
sender’s address, it is not given in the command. The admin responds (to
the address that sent the command) with the URC that is continually
connected to that LEI in the admin’s records. If the sender of the
command is not identical to the E-MAIL, the admin indicates the E-MAIL
in the response for the URC.
1. The client sends the admin the command "LEI [E-MAIL] ? urc", where
it inserts the LEI and, if necessary, the E-MAIL.
2. The admin processes the command with the response
"LEI ? urc URC [E-MAIL]", where it inserts the URC and, if necessary,
the E-MAIL.
If the LEI is reported for the first time, it is recorded together with
the provided E-MAIL. The admin assigns a new URC to this LEI.
If the reported LEI is already registered, the admin returns its URC and,
if necessary, the E-MAIL.
URC see Appendix B.
Example 1.1.1.x1: Examples of initial contacts with admin:
o Message containing command:
----------------------------------------------------------------------------
From: admin@company.com
To: hub@cnb.cz
Subject: 549300DS86PEHLIYB473 contact@company.com ? urc
----------------------------------------------------------------------------
o Message containing response:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: admin@company.com
Subject: 549300DS86PEHLIYB473 ? urc 3F7 contact@company.com
----------------------------------------------------------------------------
Example 1.1.1.x2:
o Message containing command:
----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: 549300DS86PEHLIYB473 ? urc
----------------------------------------------------------------------------
o Message containing response:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: 549300DS86PEHLIYB473 ? urc 3F7
----------------------------------------------------------------------------
1.1.2 Creation of cryptographic pair of keys
This chapter describes the creation of the client’s CPoK in OpenPGP
standard [1]. This CPoK is meant primarily to secure the content of the
files the client will be using on the server. The assumption for the
creation of the CPoK is the availability of the relevant program [2].
Technically, the result of the activity described later in this chapter
will be a set of disk files, which the program stores in the home
directory meant for the program user. It is necessary to store this
directory in a secure storage site, because it also contains the client’s
private key. Though this key is protected by a password (strong
protection is recommended), the theft of this key is a certain risk. If
the client is suspicious that the CPoK is being misused by a third party,
it should inform the admin of this.
CPoK parameters:
1. Signature: RSA algorithm, key size 2048.
2. Encryption: RSA algorithm, key size 2048.
3. For organizational reasons, the validity of the CPoK should cover one
calendar year.
The beginning of the validity of the CPoK is technically given at the
moment it is created. The client will typically create the CPoK in
three cases:
o Preparations to begin reporting.
o It is compromised or the validity expires.
o Regular preparation for the next calendar year.
In the first and second cases it is not possible to determine the
date the validity begins, the client creates the CPoK at the moment
it is needed. In the third case the client should create the CPoK in
the last quarter before the beginning of the calendar year for which
the CPoK is assigned.
The end of validity is organizationally set for 31 January of the
year that follows the calendar year for which the CPoK is assigned.
If the client creates the CPoK earlier than in the last quarter of
the year, it’s validity should expire on 31 January of the following
year. Thus the CPoK covers the period until the regular annual
renewal.
If the client creates the CPoK as part of the regular annual renewal,
i.e. in the last quarter of the year, its validity should be set for
31 January of the year after next.
The validity of the CPoK is entered in the program as the number of
days from the moment it is created. For the purpose of the
calculation we do not consider the time of day.
Example 1.1.2.x1: For a CPoK for the year 2018 created on 4 October 2017,
we calculate the number of days of validity as the difference between 31
January 2019 and this date. This give us 484 calendar days, which we
enter the program upon command.
4. The CPoK is described for the user by the identifier, which is
comprised from these parts:
o The real name must correspond to the mask
"AAA_KEYENC_PUB_BBBBBB_CC", where the individual segments have
these statuses:
AAA
The URC
KEYENC
the code for the file containing (from the admin’s perspective)
the encryption key, a constant
PUB
the code for the file containing (from the admin’s perspective)
the public key, a constant
BBBBBB
the sequence number of the CPoK within the calendar year, a
sequence in the range from 000001 to 999999
CC
The last two numbers of the year for which the CPoK is
designated.
o E-MAIL (Email address).
o The Comment must contain the environment type code (see Appendix
A) followed by a space (" ") and the URC.
5. The user provides the security of the CPoK, or its private key, with
a sufficiently robust password. The program calls upon the use to
enter this password.
Example 1.1.2.x2: The creation of the CPoK for the year 2018 in GnuPG for
a test user with the URC "FFF" (the statement was formatted and
abbreviated):
----------------------------------------------------------------------------
$ 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.
--------------- Expect a request to enter the password here. ---------------
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 Transmission of public key to admin
This chapter describes the transmission of the public key to the admin.
1. The client exports the public key from the storage as plain text.
Example 1.1.3.x1: Export of the test user’s public key for the year 2018
with the URC "FFF" using the GnuPG program:
----------------------------------------------------------------------------
$ 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. The client sends the admin the "KEY ! ip" command, where it inserts
the CPoK Comment for KEY. Copy the prepared public key report in the
body of the message. The sender must be the URC E-MAIL.
Example 1.1.3.x2: The report with the command for the receipt of the
public key according to the previous example:
----------------------------------------------------------------------------
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. The admin processes the command with the response
"KEY ! key ? fp STAMP TIME", where it enters the KEY according to the
text of the command. With the "? fp" connection, the admin asks the
client to send the signature (fingerprint) of the submitted key. The
admin enters a pseudo-random sequence of eight alphanumeric character
for STAMP and a timestamp for TIME (for the format see Appendix B).
4. The admin can insert one or more instructions in the body of the
message for the purpose of increasing the probability of the proper
identification of the client.
Example 1.1.3.x3: The message with the request to send the signature of
the public key according to the previous example:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key ? fp G7GO49mp 20171005123456
Please indicate how many LEIs you currently represent in our records.
----------------------------------------------------------------------------
5. The client enters the signature signature (fingerprint) requested by
the program and, if necessary, prepares the content of the response
according to the instructions from the admin.
Example 1.1.3.x4: Key signature report according to the previous example:
----------------------------------------------------------------------------
$ 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. The client processes the request with the response
"KEY ! key ? fp STAMP TIME", where it precisely repeats the subject
of the request and enters the signature separately on the first line
of the body of the message.
7. The client can then write any answers to the instructions from the
admin from the second line on.
Example 1.1.3.x5: Message with the response to the request to send the
public key signature according to the previous example:
----------------------------------------------------------------------------
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. The admin verifies the agreement of the subject of the response with
the request as well as the agreement of the delivered signature with
the signature of the assigned public key.
9. The admin responds with the response "KEY ! key RESULT[ ERROR]",
where it inserts the CPoK Comment for KEY. If all the controlled
characters (subject of the message, key signatures and E-MAIL) are
identical, then the Admin registers the key and enters "0" as the
RESULT. Otherwise the admin enters a value greater than "0" and then,
if necessary, information about the error in ERROR.
Example 1.1.3.x6: Message concluding communication:
o option - everything is all right:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key 0
----------------------------------------------------------------------------
o option - error: an unregistered E-MAIL used:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! key 1 unregistered E-MAIL
----------------------------------------------------------------------------
1.1.4 Receipt of public key from admin
This chapter describes the procedure for the receipt of the admin’s
public key to the client’s environment. Just like the client uses a
separate CPoK for each type of environment, the server admin also uses a
separate CPoK. See Appendix A for the public key for the individual
environments and years.
1. The client chooses the admin’s public key according to the type of
the environment. Public keys are available in the form of plain text,
which the client copies to a file.
2. The client imports the prepared file to its key storage through the
program.
Example 1.1.4.x1: The import of the admin’s public key to the test user’s
storage with the URC "FFF" using the GnuPG program (the statement was
formatted):
----------------------------------------------------------------------------
$ 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. The client verifies the authenticity of the imported public key by
comparing the signature with the template specified in Appendix A.
Example 1.1.4.x2: Server admin key signature report using GnuPG program:
----------------------------------------------------------------------------
$ 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. After verifying the agreement of the signatures, the client can sign
the admin’s public key with its CPoK and to declare this key is
valid. The key’s explicit validity increases the productivity of
its use.
Example 1.1.4.x3: The procedure for signing the admin’s keys using the
client’s CPoK through the GnuPG program. In addition to the default call,
the client must also enter, in the program prompt, the "sign" command,
confirm the "y" intention, enter the CPoK password and end the program
with the "save" command. Before the signing, the key has the property
"validity: unknown". By signing the property is changed to
"validity: full" (the statement was formatted):
----------------------------------------------------------------------------
$ 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
--------------- Expect a request to enter the password here. ---------------
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 Receipt of account usernames and passwords
This chapter describes the procedure for receiving the usernames and
passwords for the server account. The procedure is meant for both the
initial and for each subsequent receipt of this access information.
1. The client sends the admin the "KEY ! passwd" command, where it
inserts the CPoK Comment for KEY.
2. The admin processes the response "KEY ? passwd RESULT [ERROR]", where
it takes the KEY from the command. If the sender of the command is
the appropriate E-MAIL for the sent KEY, then the admin enters "0"
in RESULT and sends the requested information in secure form in the
body of the message. Otherwise it enters a value greater than "0"
and, if necessary, information about the error in the ERROR field.
Example 1.1.5.x1:
o Message containing command:
----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ? passwd
----------------------------------------------------------------------------
o Message containing response:
* option: everything is all right - the message contains an
encrypted/signed attachment with the requested information:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ? passwd 0
Attachment: TEST_FFF_20171005123456.zip
----------------------------------------------------------------------------
* option: error - the client’s public key is not registered, the
admin cannot encrypt the requested information, the attachment
cannot be sent:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ? key 1 unregistered public key, encryption impossible
----------------------------------------------------------------------------
3. The client’s access information is the username and password.
o Each username is clearly and permanently connected with a unique
URC. Name The username starts with a prefix according to the type
of environment (see Appendix A) and ends with the client’s URC.
Only lower-case alphanumeric characters are used.
o The admin creates the password as a pseudo-random sequence of
alphanumeric (and possibly also special) characters. Each sent
command elicits the generation and implementation of a new
password. The passwords are never repeated.
4. The admin writes the prepared access information in a text file:
----------------------------------------------------------------------------
login LOGIN
password PASSWORD
----------------------------------------------------------------------------
Where it inserts the username for LOGIN and the user’s password for
PASSWORD.
Example 1.1.5.x2: The access information for the test user with the URC
"FFF" written in a file:
----------------------------------------------------------------------------
login hbtfff
password 57Gx39tZ
----------------------------------------------------------------------------
5. The admin creates the name of the text file using the mask
"KEY_TIME.txt", where it inserts the CPoK comment for the KEY and the
timestamp for TIME (for the format see Appendix B). All of the spaces
(" ") that may be in the KEY field will be replaced by underscores
("_").
6. The admin encrypts the prepared text file with the client’s public
key and signs it with its own CPoK. The secured file will have the
".zip" extension.
7. The client receives the secure file, decrypts it and sends the
requested information.
Example 1.1.5.x3: The decryption and control of the secured file’s
signature (the statement was formatted):
----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --output TEST_FFF_20171005123456.txt
> --decrypt TEST_FFF_20171005123456.zip
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)
--------------- Expect a request to enter the password here. ---------------
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 Transmission of IPv4 address to admin
This chapter describes the transmission of the IPv4 address, from which
the client will access the server.
1. The client sends the admin the "KEY ! ip" command, where it inserts
the CPoK Comment for KEY. In the body of the message it then inserts
one or more commands of the type "IP +|-", with each command on a
separate line. The commands will be performed in the order in which
they are written. The commands are independent of each other, the
result of one command does not influence the method of performing the
others.
Each command in the body of the message represents one request for
the configuration of rules on the server’s IPv4 server. If the client
requests for a concrete address to be enabled, then it enters a plus
sign ("+") after it. If it requests for the authorization to be
canceled, then it enters a minus sign ("-") after it.
2. The admin processes the response "KEY ? ip RESULT", where it takes
the KEY from the command. If it processes all the requests given in
the body of the command so that the client will be satisfied, it
enters the numeral "0" in RESULT. Otherwise it inserts a value
greater than "0" and the client then finds the concrete errors in the
results of the processing of the individual commands in the body of
the message.
Each command in the body of the message is processed separately and
the admin enters the result of its processing on the line following
the command. The "IP +|- RESULT [ERROR]" mask is used for the row,
where the part corresponding to the command is taken from the command
message. If the IPv4 address is formally correct and the
configuration is successfully carried out, "0" is entered in RESULT.
Otherwise a value greater than "0" is entered in ERROR followed by
any information about the error.
Example 1.1.6.x1: Adding IPv4 address 193.85.3.250 to the list or
authorized addresses for access to the testing environment:
o Message containing command:
----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! ip
193.85.3.250 +
----------------------------------------------------------------------------
o Message containing response:
* option - everything is all right:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! ip 0
193.85.3.250 + 1 rule already exists
----------------------------------------------------------------------------
Commentary: Even though the processing of the request did not end
without a notification (RESULT is greater than "0"), all of the
client’s requests were satisfied, and thus the subsequent RESULT is
"0".
* option: error - the address was found in the list of dangerous
addresses:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! ip 2
193.85.3.250 + 2 found in blacklist
----------------------------------------------------------------------------
1.1.7 Receipt of server’s IPv4 address
This chapter describes the procedure for the client to receive the
servers IPv4 addresses. The admin can use a separate IPv4 address for
each environment type. For the server’s current IPv4 address, see
Appendix A.
1. The client chooses the relevant IPv4 address on the basis of the
requested environment type.
1.1.8 Receipt of server’s public SSH keys
This chapter describes the procedure for receiving the server’s public
SSH keys by the client.
The server provides the possibility of connecting various types of client
programs. The programs can use various types of public SSH keys when
making a connection. The client program performs the choice of the
specific public SSH keys automatically. The signatures of the server’s
public SSH keys depend on the environment type, see Appendix A.
1. The client chooses the group of public SSH keys on the basis of the
requested environment type. The client then uses the signatures to
verify the server authenticity during the initial connection to its
account.
1.1.9 Creation of revocation certificate
This chapter describes the creation of the RVC in the CPoK. The RVC must
be created immediately following the creation of the CPoK.
RVC parameters:
1. The RVC name will be similar to the CPoK name, only the type of the
server changes from KEYENC to KEYERV.
2. A non-specific reason is used for the revocation ("0 = No reason
specified").
3. the CPoK Comment is entered in the RVC description.
4. Immediately after creating the RVC, the program asks for the password
to CPoK.
The program output is the RVC in plain text format, which is usually
stored in a file with the name CPoK and the ".gpg" extension.
Example 1.1.9.x1: The creation of the test user’s RVC for the CPoK for
the year 2018 with the URC of "FFF" in the GnuPG program (the statement
was formatted):
----------------------------------------------------------------------------
$ 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
--------------- Expect a request to enter the password here. ---------------
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 Transmission of revocation certificate to admin
This chapter describes the client’s transmission of the RVC to the
admin.
1. The client encrypts and signs the RVC. The encryption will be done
using the admin’s public key. It is best to sign using the CPoK of
the relevant RVC. The output will be a secure file with the same name
as the original file with the RVC (plain text format, ".gpg"
extension), though with a ".zip" extension.
Example 1.1.10.x1: Encryption of the RVC from the previous example:
----------------------------------------------------------------------------
$ gpg --homedir ~/doc/hub/FFF/.gnupg \
> --default-key FFF_KEYENC_PUB_000001_18 \
> --output FFF_KEYERV_PUB_000001_18.zip \
> --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
--------------- Expect a request to enter the password here. ---------------
----------------------------------------------------------------------------
2. The client sends the admin the "KEY ! rvc" command, where it inserts
the CPoK Comment for KEY. The client attaches the prepared secure
file with the RVC.
3. The admin processes the response "KEY ? rvc RESULT [ERROR]", where it
takes the KEY from the command. If the sender of the command is the
appropriate E-MAIL for the sent KEY and secure RVC file, then the
admin enters "0" in RESULT. Otherwise it enters a value greater than
"0" and, if necessary, information about the error in the ERROR
field.
4. The admin records the valid RVC for the CPoK.
Example 1.1.10.x1:
o Message containing command:
----------------------------------------------------------------------------
From: contact@company.com
To: hub@cnb.cz
Subject: TEST FFF ! rvc
Attachment: FFF_KEYERV_PUB_000001_18.zip
----------------------------------------------------------------------------
o Message containing response:
----------------------------------------------------------------------------
From: hub@cnb.cz
To: contact@company.com
Subject: TEST FFF ! rvc 0
----------------------------------------------------------------------------
1.2 Connecting
This chapter describes the client’s methods for connecting to the server.
The first sub-chapter describes the initial connection, the second the
subsequent connections.
The difference between the initial and the subsequent connections
consists in the fact that during the initial connection the client does
not have stored the server’s public key required for the initialization
of the SSH connection. Thus it is highly recommended for the client to
carefully control, as part of the initial connection, that the signature
that the (at this time absolutely unknown) server offers it on the basis
of its attempt for a SSH connection is truly a registered signature of
the intended host (server). On the basis of the success of such a
control, it is then possible to trust the relevant server and to let the
client store its public key in the internal list of trustworthy SSH
servers.
The subsequent connections, when resolving the trustworthiness of the
host, can then use the aforementioned internal list instead of querying
the user.
Note: The client program permits such a setting, during which the
signatures are not verified and are automatically trusts them.
The server admin strongly warns against such settings!
The user needs a program to connect, the client’s SFTP [3]. The arguments
used to identify the communicating parties must always be entered in the
program:
o Hostname
The IPv4 address or DNS SFTP server. The values depending on the
environment type, see Appendix A.
o Port
The TCP port on which the SFTP server expects the client’s
connection. For values, see Appendix A.
o User
The client’s username, see Chapter 1.1.5.
1.2.1 Initial connection
This chapter describes the client’s initial connection to the server. The
connection is always considered to be an initial connection when the
signature provided from the server does not correspond to the signature
expected by the client. Either the client does not yet have a signature
for the server or there was a change to the relevant public SSH key on
the server or the client is connecting to a host that is only posing as
the server.
1. The client begins the connection using the program, where, in
addition to the constant arguments, it also gives the argument
"StrictHostKeyChecking=ask", which determines that if the server
provides an unrecorded public key, then the program calls upon the
use to validate its signature. The program stores the valid public
key in the list and terminates the connection.
Example 1.2.1.x1: The beginning of a connection using the sftp program
(the statement was formatted):
----------------------------------------------------------------------------
$ 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 Subsequent connections
This chapter describes the client’s subsequent connections to the server.
The connection is always considered to be a subsequent connection when
the signature provided from the server corresponds to the signature
expected by the client. The client them directly uses the public key for
the connection and does not request any interaction from the user.
1. The client connects using the program, where it gives only the
identification arguments.
Example 1.2.1.x2: The connection using the sftp program (the statement
was formatted):
----------------------------------------------------------------------------
$ sftp -oPort=6710 -oUser=hbtfff hub-t.cnb.cz
hbtfff@hub-t.cnb.cz's password:
sftp>
----------------------------------------------------------------------------
2 User account
This chapter describes the client’s user account on the SFTP server. The
first sub-chapter describes the user’s home directory, the second the
address tree found in this directory and the third the files that the
client can store on or copy from the server.
2.1 Home directory
This chapter describes the user’s home directory. The home directory is
the default directory for the user’s login. Each home directory is
dedicated to a single user. The authorizations are set so that the home
directory (including everything it contains) is not accessible by another
user in any manner. The goal is the complete mutual isolation of the
individual users. The home directory and its contents are meant to be
read-only.
Example 2.1.x1: Description of path to home directory:
----------------------------------------------------------------------------
sftp> pwd
Remote working directory: /
sftp>
----------------------------------------------------------------------------
2.2 Address tree
This chapter describes the address tree that has its root in the user’s
home directory.
The address tree of each user looks like this:
/
├── archive
│ ├── incoming
│ └── outgoing
├── incoming
├── outgoing
└── public
The individual directories and subdirectories have the following
meanings:
o archive
does not contain any files, contains two subdirectories, its
purpose is the short-term (less than dozens of days) storage of
copies of files, for which the user is the recipient or the sender.
o archive/incoming
contains copies of files, for which the user is the recipient.
o archive/outgoing
contains copies of files, for which the user is the sender.
o incoming
contains files, for which the user is the recipient.
o outgoing
contains files, for which the user is the sender.
o public
contains files published by the admin.
2.3 Files
This chapter describes the files used for communication between the
client and the (server) admin. The first sub-chapter describes the naming
convention introduced for naming files, the second the procedure for the
preparation and sending of a file, the third the procedure for receiving
and processing the a file and the fourth the formal errors that can arise
during communication.
2.3.1 Naming convention
This chapter describes the naming convention introduced for writing the
file names. The convention is binding for all files that are found on the
server or in the user account. In the case of the "public" directory, the
right to make changes is reserved, following the notification of the
users.
The file mask "AAA_BBBBBB_CCC_DDDDDD_EE[_FFFFFFFFFFFFFF].zip" contains
the basic mask (i.e segments "A" through "E") and an extension (segment
"F") provided by the server to indicate the moment when the file was
registered on the server. The segments can contain only capital letters
without diacritics or numerals. The ".zip" extension is implicit for
secure and/or compressed files. The ".xml" extension is implicit for
open forms of these files. The individual mask segments have the
following meanings:
AAA
URC of the sender
BBBBBB
file content type code, see chapter 3.1
CCC
URC of the recipient
DDDDDD
the sequence number of the file in the current calendar year, a
sequence ranging from 000001 to 999999
EE
the last two digits of the current year
FFFFFFFFFFFFFF
timestamp (for the format see Appendix B)
2.3.2 Sending a file - report
This chapter describes the procedure for preparing and sending a file. A
file sent by the user to the server is also called a report.
1. The client prepares a file with content that corresponds to one of
the types prescribed for sending and named in accordance with the
naming convention (using the basic mask). The file will be created in
open form and will thus have the ".xml" extension.
2. The client encrypts the prepared file for the recipient and signs it
on behalf of the sender. The name of the file remains the same, only
the extension is changed to ".zip".
Example 2.3.2.x1: The preparation of a data file of type "DATT10", the
sender "FFF", the recipient "CNB", with a sequence number of 54 within
the year 2018. The GnuPG program was used:
----------------------------------------------------------------------------
$ 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
--------------- Expect a request to enter the password here. ---------------
----------------------------------------------------------------------------
3. The client stores the secure file in the "outgoing" directory in its
user account on the server.
Example 2.3.2.x2: Sending the file prepared in the previous example. The
example uses the test environment, the user account "FFF" will thus be
"hbtfff@hub-t.cnb.cz". The sftp program was used:
----------------------------------------------------------------------------
sftp> put FFF_DATT10_CNB_000054_18.zip outgoing/
sftp>
----------------------------------------------------------------------------
4. After completing the storing of the file, the server renames it (adds
the timestamp) and moves it to the "archive/outgoing" directory.
Example 2.3.2.x3: Storing file from previous example in archive:
----------------------------------------------------------------------------
sftp> ls archive/outgoing/
archive/outgoing/FFF_DATT10_CNB_000054_18_20171031130354.zip
sftp>
----------------------------------------------------------------------------
5. The content of the "archive/outgoing" directory is regularly checked
by a program running in the CNB’s internal environment. It copies
newly-found files to a secure internal environment, where it
continues processing them. The result of the processing is written
into the response file for the client. This file is created in plain
text format, using the ".xml" extension. This is followed by the
securing of the file for the file using encryption and its own
signature, using the ".zip" extension. Finally, the timestamp (for
the format see Appendix B) is added to the filename. The program
copies the secure file to the "incoming" and "archive/incoming"
directories.
2.3.3 Receiving a file - response
This chapter describes the procedure for receiving and opening a secure
file. The file received by the user through the server is also called a
response.
1. The client finds the secure file in the "incoming" directory.
Technically, it uses the regular directory listing.
Example 2.3.2.x1: Listing of "incoming" directory.
----------------------------------------------------------------------------
sftp> ls incoming/
incoming/CNB_FDBT10_FFF_000054_18_20171031162459.zip
sftp>
----------------------------------------------------------------------------
2. The client copies the file from the "incoming" directory on the
server to its environment. The program detects the end of the copying
and automatically deletes the file from the "incoming" directory.
The file thus continues to be available in the "archive/incoming"
directory.
Example 2.3.2.x2: Copying the file from the "incoming" directory (the
statement was formatted):
----------------------------------------------------------------------------
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. The client can control the sender’s signature in the secure file as
part of the decryption operation, the output of which is the file with
the response in open form.
Example 2.3.2.x3: Decryption of response using GnuPG program. When opening
the file, the program writes both the public key, which was used by the
sender to secure the discreet nature of the content (only the holder of
the appropriate CPoK can open the content in this manner), and the CPoK
that the sender used for the signature. If the signature does not come
from an invalid or unknown CPoK, the program should write a warning to the
recipient about this. The program writes the response in open form to a
file with an ".xml" extension.
----------------------------------------------------------------------------
$ 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)
--------------- Expect a request to enter the password here. ---------------
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 Formal errors during communication
This chapter describes formal errors during communication. Formal errors
during communication are considered to be:
o non-adherence to the naming convention, see Chapter 2.3.1:
* HUB-001
an error in the structure of the name, the incorrect number or
length of the individual name segments.
* HUB-002
incorrect sender, the URC does not agree with the name of the
client account.
* HUB-003
incorrect recipient, it must be "CNB".
* HUB-005
incorrect file content type code, see chapter 3.1.
o HUB-006
exceeding maximum file size, see Appendix B.
o HUB-007
exceeding quota of client account, see Appendix B.
The non-adherence to this rules blocks the normal processing of the file.
In such a case, the program generates a file with a content type of
"FBDHUB", the sender "CNB", the recipient is determined on the basis of
the home directory, where it obtained the file, the sequence number of the
response in the framework of the year is then generated.
The ascertained errors are written in the file. The file structure
corresponds to the SML Schema [4].
Note: The HUB-XXX codes specified in the list above correspond to the
codes that ESMA uses in the HUB system.
3 Support of communication within MiFID/MiFIR
This chapter describes the communication support method within
MiFID/MiFIR. The first sub-chapter describes the supported ESMA
specifications and CNB methodology, the second the principles for
processing the content, the third the prescribed BAH content.
3.1 ESMA specifications and CNB methodology
This chapter describes the ESMA specifications and CNB methodology, which
define the content of the files supported by the current server
implementation. In the following list the file type codes for reports and
responses and the prescribed security are specified for all content except
for basic identification information:
o The report of aggregate positions in commodity derivatives, emission
allowances and their derivatives
* ESMA specifications: [4]
* CNB methodology: MKT20180103/KOMFIM10/KOM (ČNB) 10-52
* Report/response file content type code: DATK10/FDBK10
* Security: encryption for recipient, signed by sender
o Information on transactions with investment tools according to Article
26 of MiFIR
* ESMA specifications: ESMA/2016/1521 Technical Reporting
Instructions, MiFIR Transaction Reporting [4]
* CNB methodology: MKT20180103/TRAFIM10/FIM (ČNB) 10-97
* Report/response file content type code: DATT10/FDBT10
* Security: encryption for recipient, signed by sender
o Information on concluded, settled and canceled transactions and
transfers
* ESMA specifications: N/A
* CNB methodology: MKT20180103/TRAFIM20/FIM (ČNB) 20-97
* Report/response file content type code: DATT20/FDBT20
* Security: encryption for recipient, signed by sender
3.2 Principles for preparing content
This chapter describes the principles for the processing of the content.
The processing of the content in the case of a report is understood to be
the performance of all the activities for technically opening a secure
file. In the case of a response, it is all the activities before the
technical securing of the file.
The content is inaccessible from the server’s perspective, the actual
opening/securing is performed by programs located in CNB’s secure internal
environment. Open content is not permitted outside of this perimeter.
Internal programs then place the processed content into a queue, always
primarily according to the content type code and secondarily according to
the timestamp assigned to the file for its storage by the client on the
server.
The actual processing of the content is typically comprised of these
steps:
1. Control of content against XML Schema.
2. Storing of content in database.
3. Performance of entry/synchronous control according to
specifications/methodology.
4. Setting of status indicators on individual lines and in individual
files. The status indicator defines the following operations
applicable to the lines or files in question.
5. Collecting the results of the asynchronous control for the files of
the same client delivered in the previous days.
6. The connection of the results of both types of controls into the joint
content of a single response.
The successful completion of each step is a necessary condition to begin
the following step. If the content does not undergo a test against the XML
Schema, the content cannot be stored in the database and thus its
processing is finished. The creation of the response then continues.
Apart from the aforementioned synchronous processing, there is also
asynchronous processing, which is performed automatically by the program
depending on the fulfillment of other conditions. This includes, for
example, the validation of the tools against FIRDS.
3.3 Specific BAH content
This chapter describes the BAH content, whose specification falls under
the competence of the national regulator. For recommendations for defining
the regulation, see ESMA/2016/1521 [4], chapter "6.4 Business Application
Header".
The regulations for the individual elements are here:
o Business Message Identifier "BizMsgIdr"
will be created from parts of the filename corresponding to the
naming convention (see Chapter 2.3.1) of segments "A" to "E". If a
situation arises, where it will be necessary to gradually create
multiple responses for one report (this specifically applies to the
development of the line statuses in the context of the repeated
(asynchronous) control of tools against FIRDS) without another
report being available at the given time to provide its response as
an envelope for the content of this response, then the
aforementioned element, in order to preserve its (global)
uniqueness, will always be suffixed with a single character ranging
from "0" to "9" and then "A" to "Z".
Example 3.3.x1: Example of element "BizData/Hdr/AppHdr/BizMsgIdr" for
response:
<BizMsgIdr>FFF_DATT10_CNB_000054_18</BizMsgIdr>
Example 3.3.x2: Example of element "BizData/Hdr/AppHdr/BizMsgIdr" for
response:
<BizMsgIdr>CNB_FBDT10_FFF_000054_18</BizMsgIdr>
Example 3.3.x3: Example of element "BizData/Hdr/AppHdr/BizMsgIdr" for
response:
<BizMsgIdr>CNB_FBDT10_FFF_000054_180</BizMsgIdr>
o Message Definition Identifier "MsgDefIdr"
will correspond to the default schema for the given type of content,
as it is defined by the relevant ESMA specifications [4]. No extra
XML Schema specifications will be introduced.
References
[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
Contact to admin
hub@cnb.cz
www.cnb.cz
Appendix A. Server parameters
1. Designation of environment:
Environment Code Prefix
--------- ---- ------
production PROD hb
test TEST hbt
2. Public keys and signatures according to environment and year:
o production:
* 2021/2022
$ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_21
pub 2048R/156C0D96 2021-01-12 [expires: 2023-01-31]
Key fingerprint = 4F23 8820 5426 743F 465D 23AF 762D 1B69 156C 0D96
uid CNB_KEYENC_PUB_000001_21 (PROD CNB) <hub@cnb.cz>
sub 2048R/62E56D62 2021-01-12 [expires: 2023-01-31]
$ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_21
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBF/89ToBCADdQdEVShW20KH8X18zb42wnHT8XIqmgrRmcnE8oWmJpqHMLyW1
nfU3/xD+taloa0Uz5/nsGfM8Ja95ArD+L8Z/jPIDjdMclF+bIXtmOjskFZdvFumk
1FK8zlR+JhlLJ6oELfDUzWAdlHNueuol8jcAD60dc94PGhVD224/ZBlQ4G8eOAn8
65+71f6HGT1QZi0NltfFIGeoogmzXCzRWRNB7zwhgfy/ZInDklNTrbCoafJsfOXE
F7OYGY/n0W6b1l7PtsF+67N9z0kiSv/Ivo8jNaTdaBSUDXH2BO989qAS8VqU6FqN
zWhjTPbuJ7WnaKIMSEz+LmWbORxP9R46HxHfABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8yMSAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCX/z1
OgIbAwUJA9tzgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEHYtG2kVbA2W
nvMH/iSEaXch/FSDU5q4/frkME19yIH1Hzv6K/OqpJbecbbxFoasuJz5+lgLWvVD
dMlOI1mdRRWoY1M0U99MBxTgHmrLyfzm+ykQUxFt69OZHqGp7EXm3iSc53TFXjsA
HZawurGr+PkbWwrL4T1XQ5rheJ6IRDlN/k1N0WY3Z4xykbdSRRDFfGLQs2WqM+6X
FSu66cwdWNFso5X6diuRhkaHh6WctDdgbkeeE9RjvTi2h1RiDng7hfnRs9OjIkM7
Fj/Kbdidzbrl90l+zsDN4qZ/50A82XeLIabJZ8lhw3Kg6E3edlm0WJno9+xIwnUU
vl/31UiAoAidhtV8kpaCNjuNQGq5AQ0EX/z1OgEIAKf4+Tu6SihAUUd0e4bdktvE
ZXT53vs9rzXINep4MIHpiGrwFIo9RvNQWEkuqBZJ0/cqkHDIrLj3tE/rt0sLyw5g
VGAL6ucSWvoIDCoZ2BIrrPZIZmcsxm8RCQdBWkA3umqESL9QHxk4n5km3qybcPKE
wSYXiWJZm9cJlHBzMYWpwG5hdHDDAR4W1C5HKTZ/RVNbT68uSqh47tql3s/KkBIB
A10zE/95W3CL0JOn80OgpMUayGFlaV0qNcJAIC5bETore9lwuCsovak9b1Yb8XaD
JyGD76VQQeP65ZS+zW2q9RBR3ziHZga+J55CuW+/ZE/20R1nwStQIDjXDFdEyC0A
EQEAAYkBJQQYAQIADwUCX/z1OgIbDAUJA9tzgAAKCRB2LRtpFWwNllCAB/9G5Fb3
Zb1Zr9dtjwCrZaB9HVi9hHGlwGj6y3ObbZUB9LcKyn3QwUHL9k/UnEZbWYQHWQZt
aZL9M7L3lkgp+dYYYz/ReNofTJkjEIr2A3ZeK2UhIhBwlY6LoL1DkdjwnZfMoa6+
8AQCBMB+qFx1eV/K0Q24Sce19kFIQv7zmcATZDHrUUPfW9vQPEIV/MCiXpl0V28A
PdvSvw12K+so/mgR8l3W4B9NtboAsySrX72BmEnjM48XqggFG4nimzyg3HQSiaoF
4TmT132f/pw9rQcG4AnqHBj3dRckiZGLkw5HVEH0NrCxaC9+5esCs7kXQKogYjBi
NdE8NMrpYf0W8bd/
=IyTc
-----END PGP PUBLIC KEY BLOCK-----
* 2020
$ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_20
pub 2048R/18F8F65A 2020-01-07 [expires: 2021-01-31]
Key fingerprint = 7DAB 5259 74AE 17A2 B31B 4199 04FD 0CF9 18F8 F65A
uid CNB_KEYENC_PUB_000001_20 (PROD CNB) <hub@cnb.cz>
sub 2048R/481B358A 2020-01-07 [expires: 2021-01-31]
$ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBF4UR5UBCAC4IqIWJAP+i0AUmOj+h1yJdfqZjdLuY1VwVDLuYpyfSXUxBJ29
dodCrZ72k/YwtMjS+MgvTAHDE6LOzvN96pPMVELOhDHnKbgYsAffiQvdwcBFmmuN
u5ndPFFPj823lrWtZyA7pCl4w1t1fB4obql4qG4tEn54lyryRmOVZZOZwDLcSQ9X
3FDL3ty18XZ6ENxVUrjniAFu0/OsRmZ1kEhrom9Ie0hEsD8IreeXANIK1Sv3kfhI
RsAsnlK9b0RfrU4tmMU5xVzaN0jcHS7q5N6eqwsdcILyrDtHQnZ5QFcealnHyLKl
udrsMFBU/8usulJo68K3t0Wkwju6BN0WMglBABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8yMCAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXhRH
lQIbAwUJAgIpAAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEAT9DPkY+PZa
RT0H+wcnGLeJH7dy9CsgLypFhNiskD1cimgv3KJ2yDaEJQNsZzmtFPUzdzhQdZPb
0l1cl5WSJvL2Xhl2qhLcCTqCA4esK7DX5rLTnuZXbTiApT6UhzgbBU0dLHs4Odzc
Ck6OJXyPdhb2k5ESSa6u+q3bTGb49P8LMIkIfHzZUW0XP/iEVIN/CNhH+7eamWgX
cmiN6INNDUEC/b3BotZaX0TLnzubt8aO5Yma1cKoAorEEWYnW3IwpdCeGEAgUuy1
AB3ECVe/ePyHP3qcKgxj5OmVnSdoktYqftt440dqMR+9VY2xzN0vbC5WHjBDm9HG
RDMZuTaDtlMUOQDGEH+pJekmGh25AQ0EXhRHlQEIANIeIQYtKso6OnlxWjMehkzj
Inn0ndlTlJpxSV1+va3bJ7o/3AmjZVXZ5crTsjCy3x0AvPCaq+32UrC3QzOfzDuM
HXnRYVXGuvlk+jyy/uS/MzEcYHD4qoHqEwZ5Z2BSwSy7r3G/U2VXLLndT1bTeBGw
SewjV5eOTOZcljuPtLCK7kt7QAFfFSSz1PenrnfIWphG24VHqVy4VEg6zcF9grlM
EWjF50/Mr42Cbf8Gq84RzdQ0i5uIKkXbvjbNAPF+Z6daM3tKePJ4EASrfRaZVpJ6
MDWHHZoLnfuCy9fAEpijE0YQocq3kXY5ESB7eOSKbjj5onzcEev58q02/E2MdVEA
EQEAAYkBJQQYAQIADwUCXhRHlQIbDAUJAgIpAAAKCRAE/Qz5GPj2Wt1KCACgZtjd
abm2EeUtrq/N9tBNDzux+1p9CJ0G1hqZL4xSj+2NAyVwkgDoBqYr38QmWsrkrVi8
+qmmujyXL5Nmny1/gyyyM/qk2eN964V03yoxpihLY2JUckGpZc1pznrZthB+1UDD
g0bWC/4Zsew/Q17+DffG71cfJU6hmNNFxC7D1I45tNe2GHG71GNz2iDVKeEklNAl
BkaWbKoE5l39YRViGw4Zy22R35gLBG6MVqYds1OkFEThvaObUKoiSDI9Z6dLETQp
Fwl42Eij+SJ5tAYUYfbAM0bl9y+IwjX9cOzVkZZEwEPYQ6OP++g2H3qVE3qKmBrw
hpjlu13aQtKo4+d2
=XB31
-----END PGP PUBLIC KEY BLOCK-----
* 2019
$ gpg --homedir ~/doc/hub/HUB/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_19
pub 2048R/729243CD 2019-01-09 [expires: 2020-01-31]
Key fingerprint = 14AD A954 0CFF 0EB1 1FB8 4C21 498C 8D8D 7292 43CD
uid CNB_KEYENC_PUB_000001_19 (PROD CNB) <hub@cnb.cz>
sub 2048R/1BC67BF2 2019-01-09 [expires: 2020-01-31]
$ gpg --homedir ~/doc/hub/HUB/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_19
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBFw2SxsBCACdxMzydeB1n2O9BVVglQlL3TA7+9L2RIDcXrGOSHtH5PyGYZ0T
/cNFWAEUBGpsMaA0BvG+Mlooi9UgagFQZ8VyoTkmD58ZzqK2FuvnXFZQr+UpuzBm
GLAintPbi1WIZ5HIpzyeapoh5E5KIxL43lggfdGjrh7vbPWhishPvomRNMDDZobR
dkPVT2xHEpq8UwX86TWXu9vmFeV+EdPpkaVrfTpWPEQTJJVciXQMaVuw5MxXikMm
lyYpztPZeMRfNv9E6fdj4QdvdliFKw72nv62WKAPmH5M3mCFWNUuM6/dlCuKMREz
Qs47xK0ZDRrggeyM8uA5msO8cUA50wFJ8lrlABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8xOSAoUFJPRCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXDZL
GwIbAwUJAf40gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEEmMjY1ykkPN
d1MH/Rl40weqdcaJurDob1LyNEmBPJg1ibnek5w0OxuIAVHOaCD0k+B8uuob9Ddv
+P5xazgh+l7riqvQHl/c79sphARwBJk6pSSuS3OPzdMVyl1OYkU3zn37BcecYQcE
9u0Zt/JaA8mCw8BT37Z4y3wW8fKnnRzyefcIlc0S5ztsr8xNY2jVICtI8tMm+yWE
q8FCAIfmGkxVuWRdeVoLgR3tBMINPGu9KUIyTqJdDUqNdzJvn+RyTiDI7tARXKwp
gO/5IzHaO9VJnN0e2JKxYUPfC7FCC5mhAmITIO2UUwrYofijeIyNBxA9HymK6ELf
MGbEVuJBYAw4kA3zVDIIOkJDpcm5AQ0EXDZLGwEIALupAKbdA/R8zjtKHHtlK/oB
sE867P+64FkfdtQBaNWEBW7PdzzDrKDGaRW071OJthPwAOkcnzzfW7vMGfQsYKqi
I+boKBhXHJR/gGuGJWuXHXV1zwxNTtc/o9pqlVOQDHQ2P7ykO9QAtWnqXBFknO46
TxbFKKRuAkxAxpjKmt49zF3maY4Vsr7YAIeTwD0l1J/yS6/3BpgnKQgD1hRPiOnC
qhzHFsi9qEF4URo/lg05Xlkbq4Kr3PitKSL5oM6QPwuWEU74v7woqDLDJyQ7q4l5
Q0JoyeT7D2sefaTsErsZ4qoZ7I76LO+bqpEVFSuo41YiaymZTsvueGJd1doY9IEA
EQEAAYkBJQQYAQIADwUCXDZLGwIbDAUJAf40gAAKCRBJjI2NcpJDzdXSB/92v25D
lK05JR3bhCYvaz2crAkYFnnGi7ISSv5xqH8aNSBHblHPoyCWJKHJ/CQfB2LxJKhi
9IBSY1NBZmjsWY0Bq7XVAk/CqekBhZDvUIOdmM5DcEeMt+w57KKgDuomMr33NcU3
E0wAIiySqg/v0JZoK6oaM7euwqBqpzpTy6eIMwntim41ugNUg5D12eKhkYrrXA4i
bZuThUeOzEHXL0uPZKvqa7EmsNdaJqhFCqJztaBWQvGV5VeTJmdsXOW3H75ZQudN
xespN2PorAhUex63Dnh+2bjp37XmqYnMelKIDMCnAuDlJzL70DyQjyj18zbU6KL4
zoGL/lUYs0Pe1YFr
=Kd2V
-----END PGP PUBLIC KEY BLOCK-----
* 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 test:
* 2021/2022
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_21
pub 2048R/5CD486FC 2021-01-11 [expires: 2023-01-31]
Key fingerprint = EA95 0763 005B 53EE EB90 509A 55C6 02D9 5CD4 86FC
uid CNB_KEYENC_PUB_000001_21 (TEST CNB) <hub@cnb.cz>
sub 2048R/AA507CCF 2021-01-11 [expires: 2023-01-31]
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_21
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBF/8w4gBCADuQWUFrMgWolxSojY9DhONLUjLAq8o3IEjGpiC9hBEIyfnScr9
cFX7Bf1SYzRXG0btmjsOKvjFqxojX91UwyK1hmfe4JoQZP79zaq4YdW1i9huX19H
VU3xRncgqZYa6kuo/yX8yKo6Zs4qN7cI/7PE1z/2L7WW4tS56YZ+hMSsyQ4rxTFf
NbODLjcxtcM1/pcQGB6n94MaCPMe7uYbXWFiQKNoibsWuTUj9kurnx6EXmZXbBcY
ldGlqEc5w5B4Zbpd2tgIDNIVTmFqsYwuEm3JlY3Z4Yh2Vv5Eb2tNJLuC/yghpUN/
KvF0soaNo4n+t0G2Zhh0CLFGY61RUuERN5alABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8yMSAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCX/zD
iAIbAwUJA9zFAAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEFXGAtlc1Ib8
1AwIAM+34q1ESnzmddfH5y8izDlPnCV06qIJ30AlbSed1Uehbmtg8NPQagPxyD0t
Hji6QsoJKmJ6w9sqrvMk0O6yUToqC0rmakCZ09XZUXZY1uB+cVknW0z23eqQDaUS
GBIoN3vDaws25rhLUAkRXRClrsRmtaX2/tVUv08/CJNPx06vB8JrHIW0k3SM/ViA
Vih0qaoRpyyHh15KhUk+a1HlL4M1BiXqDLrgyUltz3xIXgyPzYv7s4aau9aVnD/o
Fs+9EcoNaNE211uaRZTTsDVOSWWHH9bm888f6eXVInqDO5sFcIhdVU26q5WJNJur
vP7GCduDC1tQEHj9uXfwpdijFBi5AQ0EX/zDiAEIAL0Lfax2Z6hLL9u0lxDgrjDf
/GfXXisvq5nVzttHSMheM2Mhg+gtKudTP0AvfC4BHBnD19dp4mgjSAs+LXpnKwbH
2p529D5ykwbTfbrdRWn5qRyZYR5Qta9cil2Bd7T0MhP7voE/IDi+9ccG24SzRZ1H
m7vieRb+/AneBtf99o6sjQeMxhkVBki51B4cIJWt9o3rJl3xLu8RxQ/Xc4od9pf6
K2KHBSfOsV5lVeSLxx71iG2aZ6cy+yNyokcPZki7BAyfqPGXYRyvqKALSE5DJX/W
N2iLSB/mPCbq3Qx1RD6+4xXyTq7u0XhihsnIv3JF2JKmdv4YIGhWtj5fN6pSe6EA
EQEAAYkBJQQYAQIADwUCX/zDiAIbDAUJA9zFAAAKCRBVxgLZXNSG/EGBB/9GEYJC
SjFJ04xLOC78a5n1uuUKBo1KsPvO1WqAOVPuX7s85kt+JotChm5KOhsXI/3osqtL
txJG2+AQBMTw7ERr8JH51bdxFAa3rBXxn1YAcq42w9sOnzd159FAMlo3m9ANZ8GF
vLIBSNhTeNx+0KsEQYw2O1xpJHR5GW95Y+QLudqXi+enKgEdilowKDfsOvP2tJCL
bn2yla6rIoTgn6e8E1T/m2KYbMUPz3KafHlnOvOSmKTf5UY4tEcm2DWF5Iwf5/h8
1tMIi+9WGVv0mgUFDp3aCZYQUIdFsm4qShdQRlqjvoQ5kHsurNdeDIdPqPFM2oM0
JK0+Q3s3UY+5lf4M
=BnPe
-----END PGP PUBLIC KEY BLOCK-----
* 2020
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_20
pub 2048R/D4F8A092 2020-01-16 [expires: 2021-01-31]
Key fingerprint = F7D4 81D8 E19A D546 DA79 41EC C108 E10D D4F8 A092
uid CNB_KEYENC_PUB_000001_20 (TEST CNB) <hub@cnb.cz>
sub 2048R/A628FC21 2020-01-16 [expires: 2021-01-31]
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_20
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBF4gJTABCACs4+Pogcqv6Rxj9IICS6VpVwpOqLTjiYe+Y8+MbmW4wO9l8uTo
OsKUFsHVJBQUcrJ6/XP4hjzlu6AwdBXLHjMvAApnm2bevEA+pzewTwSzYw58W5be
M0XFuBYncY/vNlL7CXtKgWHax2f7YLljRTY56EV/Z8SM8BoCbxGA7KSylTMj9P23
OmYKLBgKMNjxB6MpTDtvrQfURqK1wP2QHoT7XYxy5eegfHjInywliVmx5PiBZrVy
CHA4w8vyTtL5KYIGgGbGyEk6Mc+P1SqMD5FIT6JTMY9etRq77l2Pq6jms//gulVt
CjrNC+67rgXsss6Nthe+od9kJjXEckBqVsSvABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8yMCAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXiAl
MAIbAwUJAfZLgAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMEI4Q3U+KCS
e0YH/3cb75o3sn02Cs1glOPQxwnONDFe6FTQGn8CiOabX6KzMSe36ivE1MReJ/E4
qJtqs125JZju3Ol5SbwGMvR5+4YitCcavbPfnp3s7EuHGmYNe6tcuJPDHN/1zRpW
/XykImb5NF8NGfZaFa+mswqL7UQ5+OrEGDFJgCPtMacciQSjeJ0DGNDY6g8T1WD+
mkJZYQeoA1LZZbka/3R6WjiNO7TPWVm0t+k1vTT+vASbzKRU4TYaGJ8hf+BHmQ7J
o35+iLopmhYnyjxVLEn5oTp/SVVjcjuuztwQeuxRRSef9fIEikRwnDNNqkxwS28U
V55wHetCUV7JKCdBPvlENSnYemi5AQ0EXiAlMAEIAM5OaDGByu8/t/6oV7R/qJ/Z
FApc3n43L2jHMrC5pv9Ab4kzWpUZq32AILOZljR2tMl3hx3F7LO0UqaQ9VhMzDSn
HQ4TUyod0XOXOEQK61/9P0E7J5HMAyWfSXwYztoukzA/Sc9ls1Ni8ClJiNQv/0de
GSxIlYV0Slt9AOT7G1qavXa3daDeT4kWBHdQRV+9/7rzutHv/J9yXe2cYSqT3rIO
MWXox4UY68V/edSn5Ew7wQNMFIRqzzNrQvLZbmH9MCsU7lfBXi5xjVJ2IT5rAdXW
VBCc4FsTgZsos3F8sucDCkvWc3E/hieWL8vR6j86Kg60YLE3IxubBW58GAx6XL0A
EQEAAYkBJQQYAQIADwUCXiAlMAIbDAUJAfZLgAAKCRDBCOEN1PigkmqLB/wIcvpI
ZzXcKLe9UWH4Iu98mer42wQWzAbe1TExgjg+YMdWYGnTRYOxFu0/TP0ynXxmZBFs
mtFObd1b56x0LaVKifNbqUIOQqTbzqx/P1M1ls/+5EqZyv5Upp3dKMnzXMGilJRJ
hVC53GiDvTBFALsnRppgKzaaTHPiy8hyRbyDTRjiLxJC+qoWqHRhqYf1Rcih7HRv
1ZEJcFn9kYDL3PZnS/koI5olkp9CDq36E1z47gRH1woBXBsaCiWi6Sw62m9KHT4g
WKgggGl9ALoWMc9Dcf7gMA94Su1+ia0dP02dfvRIDq97DpArtYlLm4Tb9vOFXWis
eSEz/lLNRgAjYQuL
=8FH7
-----END PGP PUBLIC KEY BLOCK-----
* 2019
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --fingerprint \
> CNB_KEYENC_PUB_000001_19
pub 2048R/91BB95D9 2019-01-09 [expires: 2020-01-31]
Key fingerprint = 80E4 D158 D249 CA95 992D D43E 9FD2 2EE3 91BB 95D9
uid CNB_KEYENC_PUB_000001_19 (TEST CNB) <hub@cnb.cz>
sub 2048R/C0C2B713 2019-01-09 [expires: 2020-01-31]
$ gpg --homedir ~/doc/hub/HUB-T/.gnupg --armor \
> --export CNB_KEYENC_PUB_000001_19
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)
mQENBFw1uy0BCAC4J4cHwtP0uyTqUIIZa/mKtYj6eptIBJ7eDx7NZT/F7ayzrXWK
JZAuU2uBN/LGrAMq0DinUq2RM2k++unobiCAjxXgatpo3dSI8J4EZGZqXihGLs3o
OiW23ZQZIdWvdyGlZvO//LiHKPdsGURJe93pCbxbuAEhn3NAJmxuPCtcCccOAJYE
FtiKrKLd3vpVsnMnsToYw1orFLlH6Y7t007I82Z0KSd57nxu0o9W36ZgvbsxbOhK
F5dY2sqG8SWn+OrX7NncgicT7QZI96r5I5ScRxNv2lGfHH5z8VetLGgLdJB5vM2m
yF+I6A/7ZKInQfJ0RQw3a1kt6WExc+Mp2mtxABEBAAG0MENOQl9LRVlFTkNfUFVC
XzAwMDAwMV8xOSAoVEVTVCBDTkIpIDxodWJAY25iLmN6PokBPwQTAQIAKQUCXDW7
LQIbAwUJAf40gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJ/SLuORu5XZ
xTYH/0UgGBLQ4ClsHO6J5jcqW4BKbbZinrJ35rlqCElil4NTFMy4RPSCKD4gP7k7
YntlQliSdWx/2qXAIymhTC1pTco6Gg5HVkJTrrT2+wLbWtcxyajHj3+fG9Rd99C1
k5ViVLkM3k4WduMRmUW0JCE3PHnGGpwN4MfNdmA18fsVvmdg3pRa7jSWcW5wZ3xL
F/k2pLKUBvPiwrtzCURIgfWVgngbUkn0Ld4z82jOOrxscxB2yaeT/lpU2qeWhYIQ
xuGsGQvfBLGN7LP5OsunbgN4d5pgI7eTjallUr+pwlzV2veUBFIoGmte/BVwW/9h
4TGkAPuOdGo1kBNgwac6mTZ1ejG5AQ0EXDW7LQEIAOCovSJDhi19JuquWcMkDFi6
KUyMgqsUPDheLKm0TTZ2htyTCSRx40x1lXfi4WpmXg64mgvn0Uv3wGYkPjaD4zty
zlGXzreqPPItV+90EPfHAuPMMLrFteItUA8+UgJrc6HX6OHtOqupNRMdbe6ebAGI
NDBcH95pygcnwyBA+atMHU7mjRUzWUouCB1wBgpLIfimPXoKjC3n/zjhG/4PTeBx
1bdEfke3zcZAdh1PdpOX9L6L95OeZEaRZ2XleWaUbVBh8beYoVE2GKURkM0AF4C1
VaO7uj/tUHJUPvMIwfhJgq/1H+jbB5TvbYCMfTMmqm1PLO2vDCUg6hoK/VttqFsA
EQEAAYkBJQQYAQIADwUCXDW7LQIbDAUJAf40gAAKCRCf0i7jkbuV2bCuCACIK7eg
rgdKaHIeiy77GV/dys5+dPEVc6wmx1U8g4OKJUEpq9k6fMucwGevhiyQD04Kg3DK
1ILr056/AwH1MAleV7uWbw44ACCJUTYereQ3DtSkQYq0NruQvVEomoXKCrcBtlfv
1tZxuoY4dfMofU+zdkZ76gIJMYeVPBAiy9Y6Dyi5hAGCBaynSoOWvzF6J0TeKDI+
BFfaC/SzzH1uo7kWMHle+vfNq806gGCTMO46emAgs/7faiL0gC2eU3FIopo8JlFc
4lsCagqppmTcuvjvOB3iwLibEFJq7dKUQCScrQA5LxdEvHD/kWqYHaLQ3kLEzLba
VCNdvQcvwp2QvrCl
=ItaM
-----END PGP PUBLIC KEY BLOCK-----
* 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 addresses/hostname and TCP ports according to environment:
o production: hub.cnb.cz(193.84.159.117):6710
o test: hub-t.cnb.cz(193.84.159.118):6710
4. Signatures of server’s public SSH keys:
o node 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 node 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)
Appendix B. Formats, scopes and limits
1. Timestamp format (POSIX): %Y%m%d%H%M%S. For example, the date and
time "5 October 2017 12:34:56" will be written as follows:
20171005123456.
2. The URC is technically a three-digit hexadecimal number. It can have
4096 various values, from which the range of from "000" to "A00" and
the range of from "FF0" to "FFF" are reserved for the admin. The
remaining values in the range from "A01" to "FEF" are available for
clients.
3. The maximum size of a file on the SFTP server is set at 50 MB.
4. The quota of a client account is set at 10 GB.
Appendix C. Subsequent verification of identity {temporary}
This appendix describes the subsequent verification of the client’s
identity by the admin. This procedure is prescribed for clients that send
data pursuant to chapter 3.1 through SDNS and also want to receive the
data file compiled from this data back in the format pursuant to the
specifications given in chapter 3.1.
Note: The request to receive data from the server is considerably
different from the original plan, where the client stored the
secure data files in his/her own account by himself, thereby having
sole control over their content. Now it is necessary to provide the
client with a data file, the contents of which has not been input
by the server client. Thus it is necessary to verify that the
client is authorised to access such data.
The assumption for beginning the subsequent verification of the client’s
identity is the successful acquisition of access to the server (see
chapter 1).
1. The client notifies the admin of the intention to use the possibility
to receive the data file back. The format for this notification has
not been set.
2. The admin will submit the interested client’s LEI to the responsible
collection administrator (hereinafter the CA).
3. The CA calls on the interested client through another contact to
submit the CPoK signatures of all the keys that the client wants to
verify. This is typically the current CPoK for the testing and
production environments.
4. The VS submits the supplied signatures to the server admin, who
ensures they are verified and informs the VS of the result.
5. For accounts using verified signatures, the admin sets the automatic
return of the files.