> 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/introduction/subsystems.-concept-identification-and-types.md). # Subsystems. Concept, identification and types All key management is structured into subsystems. A subsystem is a set of keys of the same type. We can also define it as a group of keys exchanged for a certain remote, group of remotes, or applications. The subsystem is identified (or defined): * By an alphanumeric character (A-Z and 0-9) * By whether it is a proprietary subsystem (we generated it) or an external one (it was generated by the remote code yyyyyyyy). * By the code of the local entity xxxxxxxxx (remember that you can have several local codes in your license, if you work with a multi-environment setup). * By the remote entity or zeros if it is a generic proprietary subsystem * If it is zeros, the subsystem is RSA and also PROPRIETARY. * If it is not zeros, the subsystem may be proprietary or external Example: Suppose I am entity 4444 and I want to define a subsystem or set of my RSA production keys, against a certain remote (9999), whose key-change periodicity is annual, and based on that we decide to call it “A”. In the “key set” (or subsystem) identified as A-RSA-PROPIO-4444-9999, we will store the PROPRIETARY RSA production keys between my local code 4444 and 9999. Think that there could be, between that local and that remote with PROPRIETARY RSA keys, other “key sets” (or subsystems) B, C, 4, K, which, instead of storing production keys, would store test-environment keys. The alphanumeric character that defines that “key set” (or subsystem) is what we can define for tests, production, biweekly key changes, applications, remotes, etc.; that is, with that character we must find the “set we want to exchange”. Usually, only “one key set” will be exchanged with an entity, but being able to have several allows us to further divide the exchanges we make with a remote or group of remotes. Within the above combinations, we find 3 TYPES OF SUBSYSTEMS or 3 totally different types of sets: 1. TYPE 1: RSA PROPRIETARY subsystems with local code xxxxxxxxx + remote code zeros. In these, proprietary local RSA keys are GENERATED. For each subsystem of this type, with remote code set to zeros, there will be as many proprietary subsystems with local code xxxxxxxxx + remote code yyyyyyyyy as remote codes we want to associate with it. 2. TYPE 2: PROPRIETARY subsystems with local code xxxxxxxxx + remote code yyyyyyyyy. 3. Keys generated from the above are EXPORTED. The keys exported to these are SENT to the specified remote yyyyyyyyy. 4. TYPE 3: EXTERNAL subsystems (RSA) with local code xxxxxxxxx + remote code yyyyyyyyy. In these, the keys received from that remote entity yyyyyyyyy are IMPORTED. Within each of the above TYPES, obviously we can differentiate N different subsystems. The following considerations can be made regarding the above types: 1. If you have a multi-entity license, you will have several different local codes. For each local code you can have the 3 previous types. If you only have one local code, you can only have the 3 previous types. 2. There are no EXTERNAL subsystems with remote code zeros (TYPE 1), since in these we do not generate, export, or send remote keys. A given remote gives us its keys (we IMPORT), and therefore that remote code is not zeros. 3. There are PROPRIETARY RSA subsystems with remote code set to zeros (TYPE 1). This is because in RSA we will export and send only the public key to the remotes, so the same key will serve to send to different remotes (since it is public). 4. When we generate a key in a PROPRIETARY RSA subsystem, with remote code zeros (TYPE 1), and we export it to several remotes (PROPRIETARY RSA subsystems, remote code (xxx, yyyy, zzzz)) (TYPE 2.1), what we actually do is copy the same key from one to the others. In short, the concept of TYPE 1 has been included because it serves to EXPORT keys from that “set” to the different TYPE 2.1 “sets”. This only happens with RSA PUBLIC keys, since the same key can be sent to several remotes, hence its public nature. ## RSA Subsystems The following example shows the 3 RSA subsystems that are created in each of the 2 entities (A=1234 and B=6789), when they have exchanged keys.
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789, Subsystems

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

GENERATES RSA KEY

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

EXPORT key from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B -----------> ENTITY B IMPORTS it into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

GENERATES RSA KEY

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 0000

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

ENTITY A IMPORTS it into its EXTERNAL subsystem<-----------EXPORT key from Z-Proprietary-RSA-6789-0000 and SEND to ENTITY A

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

In the previous example, each entity has generated a PROPRIETARY subsystem with a different letter from the remote PROPRIETARY subsystem (X and Z). This is not a limitation; each entity in the previous example can generate PROPRIETARY subsystems with the same letters generated at the remote end (for example, PROPRIETARY SUBSYSTEM X at both ends). ## Several subsystems between 2 entities Two entities can have several exchanged subsystems depending on the type of application to be used. For example, suppose they are going to work with RSA exchanges, and that the transmission applications AAAAA1 and AAAAA2 want ANNUAL key exchanges (subsystems A at both ends), while the rest of the applications are satisfied with TRIENNIAL key exchanges (subsystems X and Z):
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789, Subsystems

Subsystem A, RSA Proprietary Type

Local code 1234, Remote code 0000

GENERATES RSA KEY for applications AAAAA1 and AAAAA2

Subsystem A, RSA Proprietary Type

Local code 1234, Remote code 6789

EXPORT key from A-Proprietary-RSA-1234-0000 and SEND to ENTITY B -----------> ENTITY B IMPORTS it into its EXTERNAL subsystem

Subsystem A, RSA External Type

Local code 6789, Remote code 1234

GENERATES RSA KEY for applications AAAAA1 and AAAAA2

Subsystem A, RSA Proprietary Type

Local code 6789, Remote code 0000

Subsystem A, RSA External Type

Local code 1234, Remote code 6789

ENTITY A IMPORTS it into its EXTERNAL subsystem<-----------EXPORT key from A-Proprietary-RSA-6789-0000 and SEND to ENTITY A

Subsystem A, RSA Proprietary Type

Local code 6789, Remote code 1234

It can now work with applications AAAAA1 and AAAAA2 It can now work with applications AAAAA1 and AAAAA2

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

GENERATES RSA KEY for the rest of the applications

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

EXPORT key from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B -----------> ENTITY B IMPORTS it into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

GENERATES RSA KEY for the rest of the applications

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 0000

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

ENTITY A IMPORTS it into its EXTERNAL subsystem<-----------EXPORT key from Z-Proprietary-RSA-6789-0000 and SEND to ENTITY A

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

It can now work with the rest of the applications It can now work with the rest of the applications
As for the editran parameterization, we would indicate that the transmission applications AAAAA1 and AAAAA2 work with subsystems A, while the rest of the applications would work with subsystems X and Z: AAAAA1 and AAAA2: LOCAL SUBSYSTEM: A, EXTERNAL SUBSYSTEM: A Rest: LOCAL SUBSYSTEM: X, EXTERNAL SUBSYSTEM: Z ## Share 1 RSA subsystem for several remotes When it comes to RSA keys, we have said that usually the keys of a PROPRIETARY RSA subsystem (with remote code set to zeros) are used to send to several remotes. Thus, for example, and continuing with the previous examples, suppose entity A (1234) generates, exports, and sends to remotes 6789 and 9876 keys from its subsystem M, and receives from remote 6789 keys from subsystem N and from remote 9876 keys from subsystem N (it does not have to be the same as that of remote 6789). We will have:
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789 and C=9876, Subsystems

Subsystem M RSA Proprietary Type

Local code 1234, Remote code 0000

GENERATES RSA KEY

Subsystem M, RSA Proprietary Type

Local code 1234, Remote code 6789

EXPORT key from M-Proprietary-RSA-1234-0000 and SEND to ENTITY 6789----------->ENTITY B=6789 IMPORTS it into its EXTERNAL subsystem

ENTITY B=6789

Subsystem M, RSA External Type

Local code 6789, Remote code 1234

Subsystem M, RSA Proprietary Type

Local code 1234, Remote code 9876

EXPORT key from M-Proprietary-RSA-1234-0000 and SEND to ENTITY 9876 ----------->ENTITY C=9876 IMPORTS it into its EXTERNAL subsystem

ENTITY C=9876

Subsystem M, RSA External Type

Local code 9876, Remote code 1234

GENERATES RSA KEY

ENTITY B=6789

Subsystem N, RSA Proprietary Type

Local code 6789, Remote code 0000

Subsystem N, RSA External Type

Local code 1234, Remote code 6789

ENTITY A IMPORTS it into its EXTERNAL subsystem<-----------EXPORT key from N-Proprietary-RSA-6789-0000 and SEND to ENTITY A

ENTITY B=6789

Subsystem N, RSA Proprietary Type

Local code 6789, Remote code 1234

GENERATES RSA KEY

ENTITY C=9876

Subsystem N, RSA Proprietary Type

Local code 9876, Remote code 0000

Subsystem N, RSA External Type

Local code 1234, Remote code 9876

ENTITY A IMPORTS it into its EXTERNAL subsystem<-----------EXPORT key from N-Proprietary-RSA-9876-0000 and SEND to ENTITY A

ENTITY C=9876

Subsystem N, RSA Proprietary Type

Local code 9876, Remote code 1234

In the previous example, 11 subsystems have therefore been created: 1. At entity A (1234): > * A proprietary M-RSA subsystem, local code 1234, remote code zeros (TYPE 1). > * A proprietary M-RSA subsystem, local code 1234, remote code 6789 (TYPE 2). > * A proprietary M-RSA subsystem, local code 1234, remote code 9876 (TYPE 2). > * An N-RSA external subsystem, local code 1234, remote code 6789 (TYPE 3). > * An N-RSA external subsystem, local code 1234, remote code 9876 (TYPE 3). 2. At entity B (6789) > * A proprietary N-RSA subsystem, local code 6789, remote code zeros (TYPE 1). > * A proprietary N-RSA subsystem, local code 6789, remote code 1234 (TYPE 2). > * An M-RSA external subsystem, local code 6789, remote code 1234 (TYPE 3). 3. At entity C (9876) > * A proprietary N-RSA subsystem, local code 9876, remote code zeros (TYPE 1). > * A proprietary N-RSA subsystem, local code 9876, remote code 1234 (TYPE 2). > * An M-RSA external subsystem, local code 9876, remote code 1234 (TYPE 3). ## Subsystem content: Keys and versions Within each of the subsystems, we find keys (actually, their labels) and the state they are in. We will have the following keys within a subsystem: 1. Pairs of RSA keys, with different versions (v01 to v99, wrapping around when they reach that value). * When we generate RSA keys (proprietary subsystem with remote code zeros), we increase the version value of the newly contained key (V2, V3, and so on). * Proprietary subsystems with remote code xxxx: * When, from the previous proprietary subsystem with remote code zeros, we EXPORT the key we want (it can be all the previous ones or only some) to one or several proprietary subsystems with remote code(s) xxxx, yyyy, zzzz, what we do is copy the version (key) we want from one to the other(s). In short, we generate a key from the previous one and export the same key to several remotes. * When a remote sends us a key with version x, we IMPORT it (incorporate it) into an EXTERNAL subsystem. If it sends us several of the same type and of the same subsystem, we will therefore have several keys from that remote in that subsystem. 2. Within the management of a subsystem, the last 3 keys entered are kept, so that we can manually, if necessary, choose between 3 possible keys for operation against a remote entity. If we have entered more than 3, the trace of the one before the third-to-last is lost. They are not physically lost (since they are kept in the corresponding key file), at least until they are overwritten by wrapping around, but from a management point of view they have been lost. ## State of the keys within a subsystem Each key in a subsystem is identified, in addition to the version, by the state it is in. We will have: * When we generate a key (RSA proprietary subsystem with remote code zeros), with a certain version (the previous generated version + 1), the state of the newly generated key becomes ACTIVE. The previous one that was in ACTIVE state becomes OPERATIONAL. If there were 3 or more keys and we generate a new key, the trace of the third-to-last one is lost. In zos, all this is done in option 6.2 (proprietary RSA key management, generation and administration). * Other proprietary subsystems: * In RSA: That same end exports, to the remote registry (proprietary subsystems with local code xxxxxxxxx + remote code yyyyyyyyy), that key through a procedure. Once the key has been exported, it appears in this last subsystem already with the corresponding version and in GENERATED state. The last exchanged key remains in ACTIVE state and the trace of the key that was 3 versions earlier is lost. When we send it to the remote, GENERATED becomes SENT. When the remote end sends us confirmation that it has been received, SENT becomes ACTIVE. The one that was previously active becomes OPERATIONAL. In z/OS, this is done in option 6.3 (association of proprietary RSA keys, administration, export and sending). * When an end receives a key, it accesses the EXTERNAL subsystem, local code xxxxxxxxx, remote code yyyyyyyyy, and incorporates the key with the version that comes from the remote. This key is incorporated in RECEIVED state. The last exchanged received key remains in ACTIVE state and the trace of the key that was 3 versions earlier is lost. When we send the remote a file confirming receipt of the received one, RECEIVED becomes ACTIVE. The one that was previously active becomes OPERATIONAL. In z/OS, this is done in option 6.4 (association of RSA remote keys, administration). There is also the CANCELLED state, when a key is manually taken and moved to that state. * Manually, we can also set a key to ACTIVE and therefore the one that was as such would become OPERATIONAL. ## Processes for sending a key from a subsystem In exchange key management, an editran session can be used, which is responsible for transmitting the keys. Usually the TELEGC session is used. A key-sending process consists of 2 transmissions: 1. Sending by entity A to B, of a file containing the key itself, where the generated version and the PROPRIETARY subsystem are also indicated. (When that file reaches B, it incorporates that key with the indicated version into the indicated EXTERNAL subsystem (it matches the PROPRIETARY one it receives). On end A, the key remains in SENT state and on end B, the key remains in RECEIVED state. 2. Sending by entity B to A, of a file whose content is a confirmation that the key has been received correctly. Once this transmission is completed, the key remains in ACTIVE state at both ends. ## Key changes in a subsystem. Continuing with the initial example, if 2 entities A=1234 and B=5678 first exchange one key, but then entity A changes its key 3 more times against that remote B (note that V4 was generated, but not exported):
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789, Subsystems

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V1=ACTIVE

GENERATES RSA KEY V1

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-GENERATED, SENT

EXPORT key V1 from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B

ENTITY B IMPORTS V1 into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-RECEIVED

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-ACTIVE

Receives confirmation file----------->
<-----------		Sends confirmation file

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-ACTIVE

GENERATES RSA KEY V1

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 0000

V1-ACTIVE

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

V1-RECEIVED

ENTITY A IMPORTS V1 into its EXTERNAL subsystem<-----------EXPORT key V1 from Z-Proprietary-RSA-6789-0000 and SEND to ENTITY A

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

V1-GENERATED, SENT

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

V1-ACTIVE

Sends confirmation file----------->Receives confirmation file

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

V1-ACTIVE

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V1-OPERATIONAL

V2=ACTIVE

GENERATES RSA KEY V2

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-ACTIVE

V2-GENERATED, SENT

EXPORT key V2 from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B----------->

ENTITY B IMPORTS V2 into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-ACTIVE

V2-RECEIVED

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-OPERATIONAL

V2-ACTIVE

Receives confirmation file<-----------Sends confirmation file

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-OPERATIONAL

V2-ACTIVE

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V1-OPERATIONAL

V2-OPERATIONAL

V3=ACTIVE

GENERATES RSA KEY V3

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-OPERATIONAL

V2-ACTIVE

V3-GENERATED, SENT

EXPORT key V3 from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B----------->

ENTITY B IMPORTS V3 into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-OPERATIONAL

V2-ACTIVE

V3-RECEIVED

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1-OPERATIONAL

V2-OPERATIVE

V3-ACTIVE

Receives confirmation file<-----------Sends confirmation file

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1-OPERATIONAL

V2-OPERATIVE

V3-ACTIVE

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V1- (lost)

V2-OPERATIONAL

V3-OPERATIONAL

V4=ACTIVE

GENERATES RSA KEY V4

(NOTE, IT IS NOT EXPORTED)

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V2- (lost)

V3-OPERATIONAL

V4-OPERATIONAL

V5=ACTIVE

GENERATES RSA KEY V5

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V1- (lost)

V2-OPERATIONAL

V3-ACTIVE

V5-GENERATED, SENT

EXPORT key V5 from X-Proprietary-RSA-1234-0000 and SEND to ENTITY B----------->

ENTITY B IMPORTS V5 into its EXTERNAL subsystem

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V1- (lost)

V2-OPERATIONAL

V3-ACTIVE

V5-RECEIVED

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V2-OPERATIONAL

V3-OPERATIVE

V5- ACTIVE

Receives confirmation file<-----------Sends confirmation file

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V2-OPERATIONAL

V3-OPERATIVE

V5- ACTIVE

Note that the keys in X-PROPRIETARY-RSA-1234-0000 are not the same as in X-PROPRIETARY-RSA-1234-6789. In the first one there would be V3-V4-V5 and in the second V2-V3-V5 Note that, if entity C had existed, we could have exported V4 to that entity C (9876), so the subsystems X-PROPRIETARY-RSA-1234-6789 and X-PROPRIETARY-RSA-1234-9876 would not have the same keys. In the first one there would be V2-V3-V5 and in the second V3-V4-V5. ## Manual operations on keys The graphical interface for exchange key management makes it possible to access any subsystem and change the state of the keys it contains. All this can be done in any of the main menu options (6.2, 6.3 and 6.4). If, for example, we have generated in subsystem X 5 RSA keys against a remote 6789, and that remote has only generated in its subsystem Z 3 keys, we will have:
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789, Subsystems

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 0000

V3-OPERATIONAL

V4-OPERATIVE

V5- ACTIVE

Subsystem X, RSA Proprietary Type

Local code 1234, Remote code 6789

V3-OPERATIONAL

V4-OPERATIVE

V5- ACTIVE

Subsystem X, RSA External Type

Local code 6789, Remote code 1234

V3-OPERATIONAL

V4-OPERATIVE

V5- ACTIVE

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 0000

V1-OPERATIONAL

V2-OPERATIVE

V3-ACTIVE

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

V1-OPERATIONAL

V2-OPERATIVE

V3-ACTIVE

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

V1-OPERATIONAL

V2-OPERATIVE

V3-ACTIVE

At this point, we will operate with the V5 of subsystem X, and with the V3 of Z. If, for example, we do not want to exchange keys, and we do not trust that key V3 of subsystem Z is good, we can manually activate key V3 of subsystem Z, in which case the previous line would become:
Entity A=1234, SubsystemsOperationNetworkOperationEntity B=6789, Subsystems

Subsystem Z, RSA External Type

Local code 1234, Remote code 6789

V1-OPERATIONAL

V2-ACTIVE

V3-OPERATIVE

Subsystem Z, RSA Proprietary Type

Local code 6789, Remote code 1234

V1-OPERATIONAL

V2-ACTIVE

V3-OPERATIVE

We could also have set V3 to CANCELLED, instead of keeping it operative. --- # 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/introduction/subsystems.-concept-identification-and-types.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.