Top Secret Keyring specification format in API

Products

• Top Secret

Issue/Introduction

As per doc below:

API ML truststore and keystore#
A keystore is a repository of security certificates consisting of either authorization certificates or public key certificates with corresponding private keys (PK), used in TLS encryption. A keystore can be stored in Java specific format (JKS) or use the standard format (PKCS12). The Zowe API ML uses PKCS12 to enable the keystores to be used by other technologies in Zowe (Node.js).
API ML SAF Keyring#
As an alternative to using a keystore and truststore, API ML can read certificates from a SAF keyring. The user running the API ML must have rights to access the keyring. From the java perspective, the keyring behaves as the JCERACFKS keystore. The path to the keyring is specified as safkeyring:////user_id/key_ring_id. The content of SAF keyring is equivalent to the combined contents of the keystore and the truststore.
Note: When using JCERACFKS as the keystore type, ensure that you define the class to handle the RACF keyring using the -D options to specify the java.protocol.handler.pkgs property:

How should the application keyring be specified in the application?

Environment

Release : 16.0

Resolution

The path needs to be whatever the 3rd party application documentation requires.

Per the doc:

safkeyring:////acid/keyringname

is how the keyring should be specified in the application.

To create the keyring:

TSS ADD(acid) KEYRING(8-char-keyringname) LABLRING(ringname) 

NOTE:

LABLRING must match the 'keyringname' in the safkeyring specification. It must match exaclty including case.

If using a keystore versus a SAF keyring, then TSS, ACF2 or RACF is not involved, since the certificates are stored in a directory and not in security.