EDITRAN/FF 5montilla.indra.es/EN/doc/CICS/actual/EFF52USUC_EN.pdf · 2019. 7. 19. · EDITRAN/FF...

EDITRAN/FF 5.2

Electronic Signature of MVS Files-Graphical Interface

CICS

User Manual

julio de 2019

EDITRAN/FF 5.2

CONTENTS

1. INTRODUCTION ...................................................................................................................................... 1

2. EDITRAN/FF REQUIREMENTS ............................................................................................................... 2

3. FILES, CICS RESOURCES. ....................................................................................................................... 2

4. GRAPHICAL INTERFACE ......................................................................................................................... 3

4.1. EDITRAN/P......................................................................................................................................................... 3

4.2. EDITRAN/G. ........................................................................................................................................................ 4

4.3. EDITRAN/FF ....................................................................................................................................................... 4 4.3.1. EDITRAN/FF LOCAL ENVIRONMENT. ................................................................................................................................................................................. 4 4.3.2. EDITRAN/FF LOCAL USERS. ................................................................................................................................................................................................... 5 4.3.3. EDITRAN/FF REMOTE USERS................................................................................................................................................................................................ 9 4.3.4. EDITRAN/FF PRESENTATION SESSION (GENERAL PARAMETERS). ...................................................................................................................10 4.3.5. GROUPS ASSOCIATED WITH EDITRAN/FF PRESENTATION SESSION. ..............................................................................................................13 4.3.6. USERS ASSOCIATED WITH EDITRAN/FF PRESENTATION SESSION. .................................................................................................................15

4.3.6.1. Local. ................................................................................................................................................................................................................................15 4.3.6.2. Remote. ..........................................................................................................................................................................................................................17

4.3.7. QUERY OF THE EDITRAN/FF PRESENTATION SESSION (SIGNATORIES). ........................................................................................................18 4.3.8. LOG EDITRAN/FF ......................................................................................................................................................................................................................22

5. EXAMPLE OF PROCEDURE AFTER RECEPTION .................................................................................. 23

6. EXAMPLE OF PROCEDURE BEFORE TRANSMISSION ........................................................................ 26

7. APPLICATION OUTPUT FILE. ............................................................................................................... 27

8. OTHER SITUATIONS. ............................................................................................................................ 29

9. ANNEX. ................................................................................................................................................. 30

9.1. HOW TO INCLUDE THE CN IF WE DON’T KNOW IT. ........................................................................................ 30

EDITRAN/FF 5.2 1

1.INTRODUCTION

1. INTRODUCTION

EDITRAN/FF is a software utility of EDITRAN that is implemented for the signing and

verification of Xades until the EPES protection level.

EDITRAN/FF is the client of EDITRAN/XAdES, a Java server that admits requests performed

from EDITRAN/FF for signing and verifying files with the XAdES-EPES signature.

EDITRAN/FF is an application that includes all the operations required for signing and

verifying the file signature before and after they are exchanged between two nodes. To this

end, it establishes a relationship between the files to be signed and the signatory users,

ensuring that all signatures have been completed at the transmission node, and the required

signatures have been received at the reception node.

The system is integrated by the following elements:

Application: presentation session in FF that is used to group a set of files to be

exchanged with a specific destination (EDITRAN remote node). It can be for

Transmission if it is used to process the files to be sent or for Reception if it is used

to process the files received.

User: an element associated with a natural person who is identified in the system by

means of a digital certificate. The Local Users correspond to the people who can

enter EDITRAN/FF and are the signatories of the files to be sent. Remote Users

correspond with persons belonging to the entity from which files are received

accompanied by the signatures generated by such Remote Users.

A relationship is established between each Application and the Users who must sign these

files, both in transmission and in reception, specifying, through the parameters / attributes of

these elements, the operating rules to be followed in each case.

EDITRAN/FF 5.2 2

2.EDITRAN/FF REQUIREMENTS

2. EDITRAN/FF REQUIREMENTS

1. To have EDITRAN 5.1 or a higher version available.

2. License. To have contracted the EDITRAN/FF product.

3. JAVA (see the installation manual of Xades ED XAdES-EPES USIA).

a. To have correctly installed Java 7 or a higher version.

b. To have the corresponding Java Cryptography Extension (JCE) Unlimited

Strength Jurisdiction Policy Files installed. Be careful every time Java is updated

because you can delete these files in the update process and have to install

them again.

c. In case of using EDITRAN/XAdES to sign, for each cryptographic card we want

to use, we must have installed the corresponding software (cryptographic

modules) of the different cards.

d. A TCP java server of the UNIX services, which must have an address and a port

to listen to the requests made from EDITRAN in MVS.

e. Access to the UNIX services of ZOS.

3. FILES, CICS RESOURCES.

EDITRAN/FF 5.2 3

4.GRAPHICAL INTERFACE

Two new files are created:

ZTBFFLO log of EDITRAN/FF

ZTBFFPE profiles specific for EDITRAN/FF that will be completed with the EDITRAN /FF

administrator described below.

You must define the ZTBFFLO and ZTBFFPE files to the CICS (see FCTCEDA member in the

JCLs library). In turn, you must initialize these files to the CICS (see ZTBFJILO and ZTBFJIPE

members in the JCLs library).

4. GRAPHICAL INTERFACE

4.1. EDITRAN/P.

EDITRAN/P transmission session.

EDITRAN/FF 5.2 4


In the EDITRAN/P transmission session, indicate:

If the session signs in transmission: Procedure before transmission: Indra provides a special

procedure for signing and uploading (or uploading and sending) ZTBFP1C.

If the session verifies in reception: Procedure after reception. Indra provides a special

procedure for downloading, verifying and extracting signatures, ZTBFP4C.

4.2. EDITRAN/G.

EDITRAN/G presentation session.

In the EDITRAN/G presentation session, it will be indicated:

If it is for transmission.

Indra provides a special procedure for signing, uploading and transmission, ZTBFP1C

If it is for reception:

Download file format = V. The file received is an XML binary, but we need to download

it as a variable.

Single file in Reception. If you are going to receive more than 1 file in the same

transmission, enter N. If you are going to receive only one file in each transmission, enter S

(YES).

Physical name of the reception application file. This is the name of the file with which

EDITRAN downloads XML ASCII base64 containing the signatures and the document.

Therefore, this file will not be processed by your application. Based on this, enter a

"temporary" name or do not enter anything, in which case, EDITRAN will create the default

values to create it. Check the EDITRAN documentation to see the parameterization options

for this field. In the following example, if more than 1 file is received, the variable %C (order

number of the file received) is added.

Procedure after reception: Indra provides a special procedure for downloading, verifying

and extracting signatures, ZTBFP4C

Translate in reception = N. It is not possible to translate when downloading the file, as it

would lose the validity of the signatures.

Conversion table in reception = spaces. A conversion table cannot be applied on

reception, as it would lose the validity of the signatures.

4.3. EDITRAN/FF

4.3.1. EDITRAN/FF LOCAL ENVIRONMENT.

EDITRAN/FF 5.2 5


It informs about:

o IP of the (listener) server where the java application of file signature resides. The

java application runs in the USS environment and requires booting a listener on a

specific ip and port.

o Port of the (listener) server where the java application of file signature resides.

The java application runs in the USS environment and requires booting a listener on

a specific ip and port.

o Server connection time. Time in seconds, during which the java application is

expected to return control, extracting the file from the XML and validating the

signatures.

Example. If the IP is the same as that of the IP stack serving the teleprocessing monitor,

enter 127.0.0.1 (loopback address). The port can be, for example, 7760 (reserve it in the IP

stack). The recommended time 60 seconds.

4.3.2. EDITRAN/FF LOCAL USERS.

Users in charge of signing the files to send.

EDITRAN/FF 5.2 6


We must enter:

o The option,

o The type of user (local, for our own users, or remote, for users from other entities)

o The entity code to which the user belongs (EDITRAN local code for local users, and

code of the remote entity for remote users)

o And the name or alias with which we will identify the user internally.

The username can be any character, uppercase or lowercase letters, or spaces.

In case of local user, the entity code indicated is the EDITRAN local code. If there are

several local codes or sub-environments, different users for each of the sub-environments can

be registered. A local user can only be used in EDITRAN transmissions of that local code. The

alias of the local users can be repeated in other local codes and they are considered as

different users.

In case of remote user, the entity code corresponds to the remote code of the EDITRAN

session. The alias of the remote users can be repeated in other entity codes.

The user's cancellation means that he/she is automatically removed from all the sessions in

which he/she is associated. Likewise, the user's modification is dragged to all the sessions in

which he/she appears.

EDITRAN/FF 5.2 7


The following is completed:

o The Keystore Path. Where the user’s certificate is located.

o The alias of the certificate. Alias with which the certificate is identified in the

Keystore.

o E-MAIL. The user's e-mail address will be indicated for future use.

This screen admits uppercase and lowercase letters.

EDITRAN/FF 5.2 8


If we press <PF5> in the user screen, we’ll be able to query the sessions to which the user

is associated and the groups in which he/she is included.

The fields for which the query is made appear in the header.

o TAX ID NR. (of header): In case of local user, the user entity will appear as a local

code; if it is remote, it will appear as a remote code.

o TYPE (of header): Local or remote type of the user in progress.

o ALIAS (of header): Username in progress.

The following will be displayed in the query lines.

o T: Local or Remote type of the user in progress.

o SESSION: Session to which the user is associated.

o TYPE: Local or remote type of the user in progress.

o GROUP: Group to which the user belongs or spaces if not belonging to a group.

o F: The user can sign.

o CF: The user requires countersigning.

EDITRAN/FF 5.2 9


4.3.3. EDITRAN/FF REMOTE USERS.

Users for verification of the signature in reception.

EDITRAN/FF 5.2 10


o DN: ‘Distinguished name’. It corresponds to the DN of the digital certificate with

which the files will be signed. It is one of the two ways to identify the certificate. If

we don't know the CN we can get it from the received XML file (see ANNEX).

o E-MAIL: The user's e-mail address will be indicated for future use.

4.3.4. EDITRAN/FF PRESENTATION SESSION (GENERAL PARAMETERS).

In option 7.2.3.1 we register the presentation (it must exist in EDITRAN/G).

o Application T.: it can be transmission, reception or both.

o Verify OCSP/CRL: verify whether certificates are revoked by access to OCSP server or

by CRL (revocation list).

o TEMPLATE FOR XAdES SIGNATURE: only for XAdES transmission applications. It

indicates which XAdES signature template will be applied to the signatures in this

application. If the template specifies a policy, the signatures generated will be XAdES -

EPES type; if the template does not indicate that feature, or if the template is not

indicated, the signature will be XAdES - BES type. (*)

o XAdES SIGNATURE VERIFICATION POLICY: only for XAdES reception applications. It

indicates the XML file that contains the policy with which the application's signatures

must be validated. If the signatures are specified they will be XAdES – EPES; otherwise,

they will be XAdES - BES. (*)

o NAME OR DIRECTORY OF THE SIGNATURE FILES: specifies the name of the HFS file

or USS directory that will contain the signatures. If the signature mode is Detached,

only the name of a directory can be specified; the signature file will be called (within

EDITRAN/FF 5.2 11


this directory) as the data file to be signed, plus the extension corresponding to the

type of signature, '.xsig' or'.p7b'. When the signature is attached, a file name (which

will contain the data and signatures) can be set according to the rules used in

EDITRAN/G (see point 4.5.5 of EG51USII); in this case, if a directory is set, it will

proceed as in the Detached mode.

It should be noted that the generated name must not exceed 44 characters to be sent

by EDITRAN if the node version is less than 5.2.

o SIGNATURE TYPE (P/X): indicates whether the signature follows the standard

PKCS#7 (Public-Key Cryptography Standards) or the standard XAdES (XML Advanced Electronic Signatures, up to the protection level XAdES - EPES).

o SIGNATURE MODE (A/D): allows choosing whether the signed data and the

signature will be in the same file or in separate files. With Attached format the

signature is contained in the signed file, with Detached the signature of each user

will be contained in a signature file.

o NR. OF SIGNATURES REC.: It is the total number of signatures that must be

included in the file (reception application).

(*) Only the name of the document that must reside on the "templates" /"policies"

directory of the USS installation is entered. These directories will be created when the

java server is installed and contains the documents that allow creating and verifying

signatures according to AGE (General State Administration) criteria.

We will include in these directories any other template/policy that we want to use.

The following parameters are only applied in the file reception.

o APPLICATION FILE PHYSICAL NAME (FORMATTED): (Only reception) This is the

name of the final target of the files received. Because the signed files cannot be

translated or formatted, a process after the signature verification will convert the

original file into a transformed one. The file name must match the one included in

the second EDITRAN/G session screen (option 2.3.4 from the general menu of

EDITRAN).

o DELETE FILE WHILE DOWNLOADING (S/N) (YES/NO): It allows deleting the

formatted file, if any.

o ADAPT RECEPTION FILE IN DOWNLOAD (S/N): It indicates that the received file

will be formatted after the signature verification.

o RECEPTION FILE FORMAT (Fixed/Variable/Expanded): The formatted file will

have a format of fixed, variable or variable expanded record (RECFM=FB, VB or VS).

o LENGTH OF RECEIVED REC. (1-32756): Size of the record of the formatted file.

o TRANSLATE IN RECEPTION (A/E/N): It indicates the alphabet in which we want to

have the formatted file, if translated.

o RECEPTION CONVERSION TABLE: It indicates the conversion table of EDITRAN

characters that is applied to the file once it is translated.

o REMOVE DELIMITERS (S/N) (YES/NO) FROM THE RECORD (HEXADECIMAL): It

allows removing the delimiters that the ASCII machines insert in the text files. It

indicates the hexadecimal values to be deleted. For a DOS file the delimiter is usually

x'0D0A' and for a UNIX file is x'0A'. The characters will be removed at any position in

EDITRAN/FF 5.2 12


the file because the filter is applied to a file without record formatting. It shouldn’t

be applied to non-text files. Once the sending of signed XML files takes effect, the

formatting parameters of the received files will not be necessary.

We will change the parameter ADAPT DOWNLOADED FILE (S/N) (YES/NO): N

EDITRAN/FF 5.2 13


4.3.5. GROUPS ASSOCIATED WITH EDITRAN/FF PRESENTATION SESSION.

Groups associated with the EDITRAN/FF presentation can be defined (e.g. MANAGEMENT

and INTERVENTION). We need 1 signature from each of the groups, and these groups can

have several components each.

EDITRAN/FF 5.2 14


The Mandatory signatures in the group are defined.

EDITRAN/FF 5.2 15


4.3.6. USERS ASSOCIATED WITH EDITRAN/FF PRESENTATION SESSION.

4.3.6.1. Local.

In case of local users, the screens can be individual users associated with the session:

EDITRAN/FF 5.2 16


We can also associate each local user with his/her group (option 7.2.3.3) and indicate that

the user can sign the transmission.

EDITRAN/FF 5.2 17


With PF4 we can see the local groups associated with the session.

4.3.6.2. Remote.

We can also associate each remote user with his/her group (option 7.2.3.3) and indicate

that the user can sign the transmission.

EDITRAN/FF 5.2 18


We repeat the operation with other possible signatories.

4.3.7. QUERY OF THE EDITRAN/FF PRESENTATION SESSION (SIGNATORIES).

In the FF presentation (option 7.2.3.1), we already have the signatories associated. If we

want to query or modify any parameter:

EDITRAN/FF 5.2 19


Once inside, we press PF4 (user-associated groups) to see the signatories.

If we do not indicate anything and we press ENTER, we see all the signatories, groups and

features:

In the MANAGEMENT group, the number of mandatory signatures is 1. All users in the

group will be able to sign.

EDITRAN/FF 5.2 20


In the INTERVENTION group, the number of mandatory signatures is 1. All users in the

group will be able to sign.

If we press PF5 (situation) on the first presentation screen, we see that there are 6 users,

2 remote groups, and we need 2 signatures. A name (Dolores) appears. This is so, because

alphabetically it is the first name of the first group.

EDITRAN/FF 5.2 21


In that screen, pressing PF4, SPECIFIC SITUATION OF GROUPS AND USERS, we confirm that

we have 2 groups for the reception, and we have the necessary signatories of each group (1),

since it indicates that there are no missing mandatory signatures.

EDITRAN/FF 5.2 22


4.3.8. LOG EDITRAN/FF

In the presentation session we have a log that we can query (option 7.1.1).

EDITRAN/FF 5.2 23

5.EXAMPLE OF PROCEDURE AFTER RECEPTION

5. EXAMPLE OF PROCEDURE AFTER RECEPTION

TGSS will be able to send n files to be processed in every transmission. Each of them is a

binary whose content is an XML with the document to be processed (in ASCII and base64),

and with 2 embedded signatures. It is only possible to translate and format it once the

signatures have been validated and the ASCII document has been extracted. Otherwise, the

verification option would be lost.

Each of these XML files contains 2 authorized signatures. It cannot contain more

signatures or less (unless TGSS indicates otherwise). One of them always belongs to the TGSS

Management group. The other always belongs to the TGSS Intervention group.

In turn, there are 3 possible signatories in each of the groups described.

In this context, unless otherwise notified by TGSS:

There cannot be only 1 signature in the XML file, or 3. There can only be two.

There cannot be 2 signatures in the XML file that, for example, belong to intervention or to

any other different group. One of them must belong to Management and the other to

Intervention.

There can be no signatories that we do not know of among the 3 possible signatories from

each group that TGSS has indicated.

In EDITRAN, it is therefore necessary to control the groups, the number of possible

signatories per group, possible users of each group, number of required signatures of each

group, etc.

We identify the possible users of each group by their own name and by their ID card (CN

field). These data are extracted from the Distinguished Name (DN). It has the two surnames

and the name of the signer, then there is a space, a hyphen, another space and the ID number

of the person, always written with 9 characters (8 digits + letter).

This field corresponds to the 'subject' in the 'certificate details' of that particular user. In

short, we must indicate the following characteristics:

The session requires 1 signature out of 3 possible signatures from the Management group.

The session requires 1 signature out of 3 possible signatures from the Intervention Group.

The "possible" signatories of the Management group are (for example): José Luis, María and

Manuel.

The "possible" signatories of the Intervention group are (for example): Antonio, Luisa and

Raquel.

The CNs for each of the above 6 (details of the certificate subject are: xxxx, yyyy, zzzzz,

aaaaa, bbbb, cccc).

Therefore, it is necessary to know the names and ID CARD of the signatories (CN), since

EDITRAN validates from this information who the signatories are. TGSS indicates that if the

signatories are not well entered, a confirmation file with control code 16 (Unauthorized

signatory(ies) in the account) will be sent. The standardized CNs of the signatories will be

needed to be included in the EDITRAN/FF profiles.

EDITRAN/FF 5.2 24


The names and ID Cards of the signatories should be provided by TGSS, but if this does not

occur, they can be seen from Windows Explorer.

Following the previous example, we will register the 6 possible signatories: José Luis, María,

Manuel, Antonio, Luisa and Raquel. In option 7.2.2 we proceed to register each of them as

remote TGSS users (8910).

In the signature verification example for TGSS, the final application file will be FB from

LRECL 600, and it will be translated to EBCDIC by removing the carriage returns x'0D0A'.

Please, note that the name of the downloaded file was the one that appeared in the

EDITRAN/G presentation session, if indicated in such a way. Now, it is convenient to enter

another name in the EDITRAN/G presentation session and move the name that was there

before to the EDITRAN/FF presentation session. In the example, we are identifying (in case

there is more than 1 file in the presentation), its number (%C), the download date (%A%M%D),

the download time (%H), the remote entity (8910) and the presentation application.

The following example shows the operation of the procedure after reception.

In the G presentation session we have:

DOWNLOAD FILE FORMAT (F/V/E): V, (TGSS should send by setting the EDITRAN/G

parameters in terms of their transmission application files: Format=B, Language=B,

Translate=N)

Single file in reception N.

Name of the downloaded file KI.TGSS.NORM34.N%C.

In the FF presentation session, we have:

PHYSICAL NAME APPLICATION FILE (FORMATTED):

KI.PMED.R8910.NORM34.F%A%M%D.H%H.N%C

DOWNLOAD FILE FORMAT (F-V-E): F

RECORD LENGTH (1-32756): 00072

TRANSLATE RECEPTION (A-E-N): E

DELETE CARRIAGE RETURNS (S/N) (YES/NO): S (YES)

RETURNS TO DELETE IN HEXADEC.: 0D0A

The procedure after reception, which will be used in sessions receiving files signed by

TGSS, ZTBFP4C, includes several steps:

A4P- Step that downloads the signed files sent by TGSS. If, for example, 2 files were

received in the same transmission, 2 VB files with the names KI.TGSS.NORM34.N01 and

KI.TGSS.NORM34.N02 would be downloaded. The contents of each of these files would

consist of:

The ASCII Base 64 document itself from the transmission application file

The signature of a TGSS user belonging to the MANAGEMENT group

The signature of a TGSS user belonging to the INTERVENTION group

EDITRAN/FF 5.2 25


If this step ends with a return other than zero (and it is not 01, due to not receiving the last

transmission of the presentation yet), it will be necessary to correct the error and restart it, or

to receive the presentation again.

ZTBEBA00. Only for those clients with Statistics and Alarms. This step is only included

when ABEND gives A4P. Correct the error and restart the procedure.

ZTBGLFE. Step that generates a file (ZTBGFLFE), whose content is the list of the received

files and their characteristics. This step is only included when the A4P step ends with return-

to-zero.

PASSORT. Step to sort the list of files created previously. The output is called ZTBFFLFT.

This step is only included when the step ZTBGGLFE ends with return-to-zero.

PASO01. This step is only included when the step ZTBGGLFE ends with return-to-zero. This

is the step for checking and extracting signatures from the files KI.TGSS.NORM34.N01 and

KI.TGSS.NORM34.N02. This step calls the application in the UNIX services via a TCP/IP

connection and it is in charge of the validation. A ZTBFLFE file is added with the list of

downloaded files to be processed. In turn, it creates 2 lists of output files ZTBFFSAL and

ZTBFFLF2. In addition, it creates 2 output files, with a default name, whose contents are the

ASCII application files (hereinafter the XML files) that were later signed in TGSS. In this step,

in the signature checks, the following situations can occur for each of the received files.

If this step ends with return-to-zero, it means that all the received files have been

successfully processed for signature verification.

If this step ends with return-to-01, it means that any (or all) the received files have been

processed and there is a problem with the signature verification.

If this step ends with another return code, it will be necessary to correct the error and re-

launch it.

The following steps become meaningless when the files that the TGSS signs to send are

XML.

The result of the signature verification will be the XML files (they will then be treated as

XML SEPA 34.14).

INBORR1. This step is only included when PAS001 ends with return < 02. It deletes the list

of ZTBGFLFE files.

PASO02. This step is only included when PAS001 ends with return < 02. Formats the 2 VB

ASCII files received to FB files of length 72 with translation to EBCDIC, so that 2 files will be

created (regardless of whether they will end with return 00 or 01 in previous steps).

KI.PMED.R8910.NORM34.F120410.H160000.N01, where the date is 12-04-10 and the

time is 16:00:00.

KI.PMED.R8910.NORM34.F120410.H160001.N02, the date being 12-04-10 and the time

being 16:00:01.

In addition, the step will process the file that will eventually be passed to the application

(ZTBFFSAL), whose format is specified in 5.1.1.

INBORR2. This step is only included when PAS002 ends with return 00. It deletes the list

of ZTBFFLF2 files.

EDITRAN/FF 5.2 26

6.EXAMPLE OF PROCEDURE BEFORE TRANSMISSION

From here, the user application collects the ZTBFFSAL file to see the dsname of the files

received, the Tax Id. Nr. of the signatories and the return signature validation. It builds a

positive or negative confirmation file:

If the return is not zero, it will generate a negative confirmation file with the returns given

by EDITRAN in the ZTBFFSAL file (returns 12 to 16).

If the return is zero, the application will continue its validations.

If the application's validations are positive, it will generate a positive confirmation file.

If the application's validations are negative, it will generate a negative confirmation file

(control codes 01 to 10). It may even be code 16, Unauthorized Signatory(ies) in the

account(s).

6. EXAMPLE OF PROCEDURE BEFORE TRANSMISSION

In EDITRAN with the Graphical Interface administrator, it is necessary to control the groups,

the number of possible signatories per group, possible users of each group, etc.

All the users defined in each group can sign. A relationship is established between each

Session and the Users who must sign the files, both in transmission and in reception,

specifying, through the parameters / attributes of these elements, the operating rules to be

followed in each case.

Therefore, it is necessary to have the signatories and their certificates defined, since

EDITRAN validates who the signatories are from this information. It is also necessary to have

the signature policy defined in the FF session (there will be a default one).

In the following example, the operation of the procedure after transmission is shown.

In the G presentation session we have:

The FF ZTBFP1C procedure

The procedure after transmission, which will be used in sessions where files are signed,

ZTBFP1C, has several steps:

PAS001- File signature step

This step calls the application in the UNIX services via a TCP/IP connection and it is in

charge of the signature. A ZTBGFCAR file is added with the list of files to be signed. In turn, it

creates 2 lists of output files ZTBFFSAL and ZTBGFCA2.

After this signature step there is the application file and its signatures and a list with the

names of these files that will be used by the step A1P to load (ZTBGFCA2).

ZTBEBA00. Only for those clients with Statistics and Alarms. This step is only included

when ABEND gives A1P. Correct the error and restart the procedure.

EDITRAN/FF 5.2 27

7.APPLICATION OUTPUT FILE.

7. APPLICATION OUTPUT FILE.

Creation of the file (ZTBFFSAL) FB of 300. It will indicate how the signature verification

was for each file received, as well as the characteristics of the signatures. It has 2 types of

records:

Level Name Length Format Description

1 ZTBFFSAL

Record

Alph. TYPE 01 Records.

2 Type of

records

2 Alph. 01-Records related to processed files and their

validation result

2 Two points 1 Alph. Value: ‘:’

2 Return code 4 Nr. 0000- Correct signature verification

0012- Invalid certification authority

0013- Revoked certificate(s)

0014- Expired certificate(s) (2)

0015- Modified document

0016- Unauthorized signer(s) on the account.

This is a further validation of the signature against

the EDITRAN/FF profiles


2 Final

formatted dsname

44 Alph. Dsname of the formatted and translated file, to

be processed by the application.


2 Dsname

downloaded ASCII

44 Alph. Dsname of the ASCII file, extracted from XML,

with the signatures also extracted.


2 Dsname

downloaded by

EDITRAN

44 Alph. Dsname of the file downloaded by EDITRAN,

whose content is the XML that has been processed.


2 Error message 80 Alph. Message

If rc=0000, correct signature process (without a

message)

If rc=xxxx, suitable error message

2 Reservation

area

77 Alph. Reservation area

EDITRAN/FF 5.2 28

7.APPLICATION OUTPUT FILE.

Level Name Length Format Description

1 ZTBFFSAL

Record

Alph. TYPE 02 records.

2 Type of

records

2 Alph. 02-Records related to signatories by file. For each

type 1 record, there shall be as many type 2 records as

there are signatories in the signed file.


2 Reservation

area

4 Alph.


2 Final

formatted dsname

44 Alph. Dsname of the formatted and translated file, to be

processed by the application


2 Data of the

signatory CN

138 Alph. CN= Surname and the name of the signatory, then

there is a space, a hyphen, another space and the ID

Card number of the person always written with 9

characters (8 digits + letter)

2 Filler 109 Alph. Reservation area

EDITRAN/FF 5.2 29

8.OTHER SITUATIONS.

8. OTHER SITUATIONS.

It seems that TGSS sends a single file per transmission. Note that all of the above is an

example, recommended for situations where multiple files are sent per transmission. In

addition, this allows you not to lose the TGSS file downloaded in the previous transmission.

However, if your application currently receives the application file with a fixed name,

please note that by removing that name from the G-profile and entering it in the FF-profile,

your application will continue to receive the same file.

If, for example, the procedure after reception starts a procedure in the application to

process the TGSS file, please, note that you can set variables, both in the FF-profile and in the

ZTBFFSAL itself, that could be passed via parm to your procedure.

EDITRAN/FF 5.2 30

9.ANNEX.

9. ANNEX.

9.1. HOW TO INCLUDE THE CN IF WE DON’T KNOW IT.

If we do not know the CN of the signatory, we must request it to TGSS. However, we can

also take the received XML file and perform the following operations:

Edit the received XML, with the browser (*.xml) and select the content among the first tags

<ds:x50S

Certificate> and ==</ds:x509Certificate>

Copy that content to a *txt file (notepad) that we will rename *.cer.

EDITRAN/FF 5.2 31

9.ANNEX.

Open the Windows explorer.

Go to the Details tab, and then Subject:

EDITRAN/FF 5.2 32

9.ANNEX.

We will take exactly the right CN and take it to the FF profile. (CN=FERNANDEZ

HERNANDEZ JOSE LUIS – 12345678X)

Contact

[email protected]

T +34 91 480 80 80

Avda. de Bruselas 35

28108 Alcobendas,

Madrid, España

T +34 91 480 50 00

F +34 91 480 50 80

www.minsait.com

mailto:[email protected]

EDITRAN/FF 5montilla.indra.es/EN/doc/CICS/actual/EFF52USUC_EN.pdf · 2019. 7. 19. · EDITRAN/FF...

Documents

Transcript of EDITRAN/FF 5montilla.indra.es/EN/doc/CICS/actual/EFF52USUC_EN.pdf · 2019. 7. 19. · EDITRAN/FF...