KGUP generates control information and key tokens for distribution to another site. For DES keys, this information can be used as input to KGUP to import the complementary key into the CKDS. For AES keys using the variable-length key token, KGUP cannot be used to import encrypted key values. Clear key values can be used with AES keys. To import a AES variable-length key token generated by KGUP, the receiving site must be sent the whole key token and must use the Symmetric Key Import2 callable service to import the key under the AES master key and use the CKDS Key Token Create2 service to store the key in the CKDS.
When you distribute keys or PINs, your system has one key, and the other system has the complementary key. For example, when your system sends a DATA key to another system, the importer and exporter key-encrypting keys at the systems complement each other. The DATA key is encrypted under an exporter key-encrypting key at your system. The DATA key is decrypted by the complementary importer key-encrypting key at the receiving system.
When KGUP generates a key, the other system involved in the key or PIN exchange needs the complement of the key. When KGUP generates a key, the program also generates a control statement to create the complement of the key. You send the control statement to the other system which uses the statement to create the complementary key.
For example, when you use KGUP to create an input PIN-encrypting key, KGUP also creates a control statement for the complementary output PIN-encrypting key. You send the control statement to another system. The other system uses the control statement to create the output PIN-encrypting key. Then your system can send PIN blocks to the other system.
For some key types, you can choose the output key type by specifying the OUTTYPE parameter on a KGUP ADD statement. For example, you can generate a CIPHER key for inclusion into the CKDS and export a copy of the key as either a CIPHER key or a CIPHERXL key. If you export the copy of the CIPHER key as a CIPHER key, the receiver of the key can use it to decipher data. If you export the copy of the CIPHER key as a CIPHERXL key, the receiver can use the key only in the Ciphertext Translate2 callable service to translate cipher text from one cipher translation key to another. The receiver of the CIPHERXL key cannot use the key to actually decipher the data.
KGUP stores the complementary key control statement in a data set. Because some cryptographic systems may not use KGUP control statements, KGUP also stores complementary key information as a record in a different data set. The information is not in the form of a control statement. You process and send the information to a system which creates the complementary key.
When KGUP generates a key, the program also generates information to create the complementary key. This information includes the complementary key value. The value is either a clear key value or encrypted key value. For an encrypted key value, the program encrypts the value under an exporter key. The importer key that complements this exporter key already exists at the other system. The importer key is one key in a complementary transport key pair that your system already established with the other system. The pair would be an importer key on the other system and an exporter key on your system. The other system reenciphers the value from under the importer key to under its master key to generate the complementary key.
Besides generating keys and complementary key information, KGUP imports key values that are sent from other systems. The program can receive a control statement to create a key that is the complement of a key on another system. The key value your KGUP receives may be encrypted under a transport key. The transport key would be one key of a complementary transport key pair that you already established with the other system. The pair would be an exporter key on the other system and an importer key on your system. KGUP reenciphers the complementary key from under the importer key to under the master key and places the key in the CKDS.
For KGUP to send or receive keys in a key exchange with another system, the systems must previously establish a pair of complementary transport keys. For example, KGUP on one system defines the pair and generates the importer key in the clear. KGUP on the other system uses this value to define a pair of keys that are complements of the keys at the original site. For an example of how two ICSF systems establish pairs of complementary transport keys for key exchange, see Scenario of Two ICSF Systems Establishing Initial Transport Keys.
When a transport key is used, the key value of the key being exported is encrypted by a variant of the transport key. This encrypted key value can be imported into any cryptographic product that supports CCA. However, systems with some cryptographic products do not recognize CCA control vectors. When you exchange keys with such a system, a key that you send or receive is enciphered under a transport key directly. You specify to KGUP a NOCV transport key and the key value will be encrypted by the transport key only.
You can define a pair of complementary transport keys with another system so your system and the other system can exchange keys without control vectors. You use a control statement to indicate to KGUP to produce these keys. Then send the clear value that KGUP produced to the PCF system so the system can generate the corresponding complementary pair of keys. Then you use the transport keys to exchange other keys. Refer to Scenario of an ICSF System and a PCF System Establishing Initial Transport Keys for an example of how to establish pairs of complementary transport keys for key exchange between an ICSF system and a PCF system.
You can also use KGUP to create complementary keys that are used by two different systems. Neither key would be operational on your system so KGUP would not update your CKDS. When KGUP generates the complementary key information, you send it to the two systems that need to share complementary keys.