> 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-iseries-en/gestor-de-claves/operation-example/association-and-sending-of-own-rsa-keys.md). # Association and sending of own RSA keys The local entity administrator 000099920 associates the keys created in subsystem P, version 01 (active), with remote 000099940 and sends it the public key. To do this, registers remote 000099940 with subsystem P (for the moment, nothing is entered in the signing subsystem, since the remote has not yet received any public key). Then, in the same option, exports the created public key to the remote's record, loads it, and sends it: As a result of this, option 7.3 of entity 100099940 APPEARS: KEY LIST \---------------------- Vers Gen. Date-Time Modif. Date-Time Status Sel(PUBLIC KEY) \---- --------------- --------------- ------------ --- 01 20050217-160044 20050301-124518 2 GENERATED A procedure has been launched, which exports the subsystem P public key, version 01, to the remote's record, loads it, (in clear text, for the moment), into the buffer and sends it to the remote. When entity 000099920 sends the file, it launches the process that updates the status (generated to sent). On the remote end, the procedure has been launched that verifies that there is a remote RSA record with subsystem P, from entity 000099920, and incorporates the remote public key into FICHKSRA (received status). In turn, if everything is correct, it generates a file with confirmation that everything has gone well, and sends it to entity 000099920. When entity 000099940 receives the file, it launches the process that updates the status (sent to active). When entity 000099940 sends the confirmation, it launches the process that updates the status (received to active). If transmission of the response fails, the corresponding record can be activated “manually” in both entities. The administrator of entity 000099940 repeats the entire previous process with its public key from subsystem D. In the end, both ends have exchanged the public key: In option 2 of entity 000099920, if we enter by query: Vers Gen. Date-Time Modif. Date-Time Status Sel(PUBLIC KEY) \---- --------------- --------------- ------------ --- 01 20050217-160044 20050301-124518 4 ACTIVE In option 4 of entity 000099940, if we enter by query KEY LIST \--------------------- Vers Gen. Date-Time Modif. Date-Time Status Sel(PUBLIC KEY) \---- --------------- --------------- ------------ --- 01 20050217-160044 20050301-124518 4 ACTIVE The result of both queries (the module and exponent of the public key is the same). This serves, if desired, to “verify that the sending is appropriate”; with this, we have verified that the public key sent to 000099940 is correct. In the case of the remote, the same would be done. At this point, we can already apply RSA encryption with the active keys to other sessions that we have defined between entities 000099920 and 000099940. For this, it is encoded in Editran profiles: In entity 000099920: \_\_\_\_\_ Cryptography (Y/N) ..: Y \_\_\_\_\_ Cryptographic Version .....: **400** Editran-GC (Y/N) .: Y Confidentiality Algorithm.: **AES3** Authentication Algorithm .....: **RSA4** Local Subsystem: P Remote Subsystem: D In entity 000099940: \_\_\_\_\_ Cryptography (Y/N) ..: **Y** \_\_\_\_\_ Cryptographic Version .....: **400** Editran-GC (Y/N) .: **Y** Confidentiality Algorithm.:**AES3** Authentication Algorithm .....: **RSA4** Local Subsystem: D Remote Subsystem: P From this point on, if new RSA versions are exported it is necessary to SEND THEM SIGNED, since an exchange process has already taken place. It is not necessarily the case that the next version of the same subsystem associated with the remote will be 02. If we generate version 02 and associate it with other different remotes and then generate version 03 for remote 000099940, in this case it will only know version labels 01 and 03. --- # 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-iseries-en/gestor-de-claves/operation-example/association-and-sending-of-own-rsa-keys.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.