Previous topic |
Next topic |
Contents |
Index |
Contact z/OS |
Library |
PDF
Usage Notes z/OS Cryptographic Services ICSF Application Programmer's Guide SA22-7522-16 |
|||||||||||||||
SAF may be invoked to verify the caller is authorized to use this callable service, the key label, or internal secure key tokens that are stored in the CKDS or PKDS. You can generate the verification pattern for a key when you generate the key. You can distribute the pattern with the key and it can be verified at the receiving node. In this way, users can ensure using the same key at the sending and receiving locations. You can generate and verify keys of any combination of key forms, that is, clear, operational or external. The parity of the key is not tested. With a PCIXCC, CEX2C, or CEX3C, there is support for the generation and verification of single, double and triple-length keys for the ENC-ZERO verification process. For triple-length keys, use KEY-ENC or KEY-ENCD with ENC-ZERO. Clear triple-length keys are not supported. In the Transaction Security System, KEY-ENC and KEY-ENCD both support enciphered single-length and double-length keys. They use the key-form bits in byte 5 of CV to determine the length of the key. To be consistent, in ICSF, both KEY-ENC and KEY-ENCD handle single- and double-length keys. Both products effectively ignore the keywords, which are supplied only for compatibility reasons. The access control point in the ICSF role that controls the function of this service is Key Test and Key Test 2. This access control point cannot be disabled. It is required for ICSF master key validation. This table lists the required cryptographic hardware for each server type and describes restrictions for this callable service.
|
Copyright IBM Corporation 1990, 2014
|