For CSNBKGN2 the doc says I can specify KEY_TYPE_ 1 as CIPHER, EXPORTER, IMPORTER etc.Table 77 says I can use CIPHER DKYGENKY.. (and does not mention EXPORTER or IMPORTER)I can only get CIPHER to work, and not EXPORTER or IMPORTER; I get reason code 155 if I try to use them.
Should I be able to specify EXPORTER and IMPORTER? Ive tried combinations of OP,IM and EX.
I've tried using a skeleton and specifying TOKEN, but it fails the same way.Colin
Eric,Thank you for you comments, very useful, Ive managed to generate an IMPORTER and EXPORTER.The fog in my head is clearing... but I have some questions.. Below is what I picture.. is this correct?
After a lot of head scratching and experimenting, Im still struggling with some concept level stuff, and going round in circlesFrom the 10,000 ft level, why would I want to use exporter and importer keys. (Can you point me to any existing documentation on this - I haven't found any)
I can set up a symmetric key pair on each system using private and public keys and DH. If I wanted multiple keys I could just change the "party" information and rerun the programs.Using E&I keys require me to have a DH key to be able generate my first E&I key (in CSNBKGN2). So some extra work just to get started.I also had another step or two of having to send the key to the remote system.So overall using DH to generate my keys seems much easier and is less work than using Exporter and Importer keys.I also see more admin work to look after the E&I keys, for example how can I tell if the data set with the exported key still matches the key in the keystore?. It is easy with the DH. I just recreate the key by running the job, and I know I have the current version of the key. With E&I I have to write things down.If I want to export a cipher key I can use RSA public or an Exporter key.Hence my question, why do I need Exporter and Importer keys.
Some possible answers I came up with E&I are more secureThey are architecturally betterIt is the way it was coded.I feel the ICSF product needs an ICSF 101 - which "sells the product" and covers a lot of the concepts of the product without going into technical detail, giving the background and reasons, rather than the technical details. Consider the manager of the z/OS system programmers team. They need a document/presentation which explains to them why they should get their team to install and use it. I'm happy to come up with some chapter headings for you if you would find this usefulregardsColin
------------------------------Colin PaiceOriginal Message:Sent: Tue September 21, 2021 09:09 AMFrom: Eric RossmanSubject: I'm trying to understand CSNBKGN2Setting up ICSF for the first time, the first thing I need to do is set up a DH key on each system, so I have my EXPORTER on one system, and importer on the other system.That is certainly a workable solution.I could use this key as my KEK for all my keys (CIPHER,MAC), but best practice says I should have a different KEK for each type - so a KEK for CIPHER, and a KEK for MACIt depends. In many cases, having one KEK to exchange keys with another system is fine. However, in some cases, you will want different KEKs. It really depends on your security needs.I could set upa DH for CIPHER and a DH for MAC to provide isolation,or I could use CSNBKGN2 to create an EXPORTER key (and store it in my CKDS), and and have the IMPORTER encrypted with the DH, written to a dataset and send it to the remote site. Is there any guidance on the best way of doing this? Using DH for each type sounds much simpler to implement.Normally, you would set up 2 shared keys (EXPORTER_A/IMPORTER_B on one side, EXPORTER_B/IMPORTER_A on the other side) and then use that to exchange future keys. EC-DH allows for shared party data that can cause derivation of different key material by using different shared party data (see party_identifier parameter). There's also no problem with just creating unique EC-DH key pairs for each kind of key you want to derive.I could recreate the exporter and importer keys every week if I wanted to... they are just used to get the key to the other system.Sure.I do not want to recreate a cipher key as it would mean dataset already encrypted with it would be unreadable.Correct.As you said I do not need to use CSNBKTB2 to create a skeleton for importer and exporter.Yep.However I do need to use CSNBKTB2 if I am using CIPHER because it needs a rule including "XPRTCPAC","ANY-MODE"Right. I was speaking only of the EXPORTER, IMPORTER key types.------------------------------Eric RossmanOriginal Message:Sent: Tue September 21, 2021 08:18 AMFrom: Colin PaiceSubject: I'm trying to understand CSNBKGN2