> 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/definitions-and-screens/association-of-own-rsa-keys-administration-export-and-sending.md). # Association of own RSA keys (administration, export and sending) To access this option, it is necessary that there be an appropriate RSA registry (option 1) of own keys. It is accessed with option 2 and the following panel is displayed:
The meaning of the fields is as follows: * **Option**. Mandatory field. * **Subsystem**. Accepts values A-Z and 0-9. It is the RSA subsystem of own keys that we are going to associate with a certain remote entity. It is the name of the RSA subsystem that we will notify the remote side about so that it registers it as a “remote subsystem” and under that name incorporates the key we will send it. * **Local environment**. Main local environment Editran code. * **Remote environmen**o. Editran code of the remote entity. The option to export and send keys “associates” the active key that exists in the RSA own-keys registry for the subsystem with a certain remote entity and creates a file with the corresponding local public key (it will be signed if there has been any successful RSA key exchange with that remote). This file will be sent automatically by the application if so indicated. If a record is selected, or if the selection was specific from the previous menu, the following map is displayed (some fields may appear differently depending on the access option, add-delete-export, modification, or query):
In the case of query: Vers Gen. Date-Time Modif. Date-Time Status Sel(PUBLIC KEY) \--— ------------------- ------------------- ------------ --- 01 20050220-160044 20050301-124518 4 ACTIVE 02 20050217-160044 20050218-130015 3 OPERATIVE 03 20050218-175626 20050220-105545 3 OPERATIVE In the case of modification: Vers. Creation Date-Time Modif. Date-Time Status A/C(ACTIVE/CANCEL KEY ) ----- ----------------— ------------------ ------------ --- 01 20050220-160044 20050301-124518 4 ACTIVE 02 20050217-160044 20050218-130015 3 OPERATIVE 03 20050218-175626 20050220-105545 3 OPERATIVE As we are in RSA, when registering a subsystem, it will probably serve us for several remote entities. The requested data are: * **Local description** * **Editran/P application**, by which we are going to send our public key to the remote side. * **Private and public label**. They are protected. They are those of the subsystem's own RSA registry that matches. * **RSA subsystem for signing**. It may be the same one (if keys have been exchanged through it) or different (if keys have been exchanged through another). If no keys have been exchanged with the remote entity, this field does not need to be filled in. Next, come the versions for which a key pair has been generated, and their status (active, cancelled or operative). Only one can be “active”. When new keys are generated, they become active and if there was an active one, it becomes operative. In the case of query, if a version (S) has been selected, the public key is shown in hexadecimal (the selected version is included in the label).
In the case of export-sending, an intermediate confirmation screen is shown. If they confirm, the process will be launched that associates the selected subsystem's active own key with the remote one:
If it is exported, the status of the associated key version changes to *generated*, if it is sent to *sent*. It will only change to active status when a confirmation file is received from the remote entity, or otherwise, if we activate it manually. --- # 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/definitions-and-screens/association-of-own-rsa-keys-administration-export-and-sending.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.