> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-cics-en/key-manager/appendix/key-exchange-application.md). # Key exchange application The TELEGC application is proposed for exchanging keys (it is not mandatory; there can even be one application for one direction and another for the other). If TELEGC is used, the presentation session and the associated transmission session are defined at both ends. In this application, encryption can be used, but the sent/received keys are already encrypted, so its use is not very useful. If TELEGC is used in both directions, different processes will occur: 1. PROCESS 1 - The local end sends out a local key (before sending and after sending). The remote end receives it (after reception, before sending the confirmation). 2. PROCESS 2 - The remote end sends the confirmation that it has processed it (after sending). The local end receives it (after reception) 3. PROCESS 3 - The remote end sends out a remote key (before sending and after sending). The local end receives it (after reception, before sending the confirmation). 4. PROCESS 4 - The local end sends the confirmation that it has processed it (after sending). The local end receives it (after reception). 5. PROCESS 5 - Additionally, each time RSA keys (private and public) are generated, although they are not transmitted to the remote side, the procedure specified in the Key Management profile is triggered. The EDITRAN session profile would be as follows: * Do not put an application file in the presentation session. * Procedure before sending, before receiving, state modification, and exception. Use the EDITRAN standard (ZTBGP1C, ZTBGP2C, ZTBGP6C, ZTBGP5C). Note: From the exchange key management, if keys are to be sent, a different before-sending procedure will be launched (ZTBGP1GC). The reason is explained a little later. * After-sending procedure: ZTBGP3GC. * After-reception procedure: ZTBGP4GC. The provided procedures work as follows: 1. Before sending. ZTBGP1GC. This procedure has 2 steps STEP001 and A1P (before sending). It is used for several things: > * To generate your own pair of RSA keys (PROCESS 5). In this case STEP001 ends with rc=00 and step A1P is not executed. > * To send keys: PROCESS 1 at the local end or PROCESS 3 at the remote end. In both cases, the corresponding operator, from option 6.3 or 6.4, will associate (RSA), generate (DES), and load the buffer, and will send it at that moment or not, depending on what is wanted. Therefore, STEP001 ends with rc=01 (to differentiate it from the situation of generating your own pair of keys) and step A1P is executed and must end with rc=00 (with function 01 it loads and with function 03 it sends). Note: The reason that in the EDITRAN profiles the standard before-sending procedure is ZTBGP1C instead of ZTBGP1GC is that if you do not want to send, and later it is sent from the presentation operator, ZTBGP1C will be launched, which will find the buffer loaded and will send normally. 2. After sending. ZTBGP3GC. This procedure has several steps: the after-sending step itself, the file listing step, and STEP003. This STEP003 can end with the following values: > * In the case of PROCESS 1 (enters at the local end when sending a local key) or PROCESS 3 (enters at the remote end when sending its local key), it ends with rc=304. The reason is that the state of the sent key will not be updated until confirmation of it is received (ZTBGP4GC, after reception at the end that receives the confirmation or after sending at the end that sends the confirmation). > * In the case of PROCESS 2 (enters at the remote end when sending confirmation of a key received from local) or PROCESS 4 (enters at the local end when sending confirmation of a key received from remote), it ends with rc=00, updating the key state from RECEIVED to ACTIVE. 3. After reception. ZTBGP4GC. This procedure has several steps: the after-reception step itself, the file listing step, STEP003, and then a BEFORE-SENDING command (A1P), to send the automatic confirmation in some cases. This STEP003 or the A1P step can end with the following values: > * STEP003 in the case of PROCESS 2 (local end receives the confirmation) or PROCESS 4 (remote end receives the confirmation) ends with rc=00. In both cases, step A1P is NOT EXECUTED. > * STEP003 in the case of PROCESS 1 (remote end receives local key) or PROCESS 3 (local end receives remote key) ends with rc=01. In both cases, the A1P step that is executed next to send the confirmation must end with rc=00. At both ends, no sending application file is placed: * When the key is to be sent (PROCESS 1 or 3), STEP001 (rc=01) creates a file list whose content is the name of the file to be loaded in the next step A1P (parameter LF=S, File list = 'S'). * When the confirmation is loaded (PROCESS 1 or 3), STEP003 does the same. In summary: **Procedures that are entered depending on the end that sends/receives.**
EndProcedure

Before issuance

(ZTBGP1GC) STEP001 + A1P

After transmission

(ZTBGP3GC) A3P +STEP003

After reception + Before sending (ZTBGP4C) A4P +STEP003+A1P

Key sender and

Confirmation receiver

Case 1: Generate own RSA keys:

STEP001 rc=00

A1P FLUSH

A3P rc=00

STEP3 rc=304

A4P rc=00

STEP003 rc =00

A1P = FLUSH

Case 2: Send key

STEP001 rc= 01

A1P (LF=S) rc=00

Key receiver and confirmation senderDoes not enter.

A3P rc=00

STEP3 rc=00

A4P rc=00

STEP003 rc =01

A1P (LF=S) rc = 00

**State changes of the sent/received keys according to the end that sends/receives.**
EndProcedure

Before issuance

(ZTBGP1GC) STEP001 + A1P

After transmission

(ZTBGP3GC) A3P +STEP003

After reception + Before sending (ZTBGP4C) A4P +STEP003+A1P

Key sender and

Confirmation receiver

Case 1: Generate own RSA keys:

STEP001 ACTIVE

 STEP003 ACTIVE

Case 2: Send key

STEP001 SENT

Key receiver and confirmation senderDoes not enter.STEP3 ACTIVESTEP003 RECEIVED
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.editran.onesait.com/documentacion-editran/ibm-editran-v5.3-cics-en/key-manager/appendix/key-exchange-application.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.