Description:
A virtual keyring allows System SSL to automatically check all CERTAUTH or SITECERT certificates in an
ESM keystore when verifying a certificate that was received during the SSL handshake. A virtual keyring
can be used by FTP/TLS by specifying:
KEYRING *AUTH*/*
or
KEYRING *SITE*/*
ACF2 supports virtual Keyrings. With Virtual Keyrings all CERTAUTH certificates (ie CERTAUTH.suffix) will
be returned with the KEYRING from the R_datalib calls. When referencing the virtual Keyring the
application/server's parameter file should specify *AUTH*/* or *SITE*/* to point to the CERTAUTH or SITE
virtual Keyring. With Virtual Keyrings all valid (not expired) CERTAUTH/SITECERT certificates (i.e. CERTAUTH.suffix
or SITECERT.suffix) will be returned with the KEYRING from the R_datalib calls.
Details on Keyrings can be found in the CA ACF2 for z/OS documentation in section 'KEYRING Profile Data Records'.
https://docops.ca.com/ca-acf2-for-z-os/16-0/en/administrating/administer-records/user-profile-records/keyring-profile-data-records
Note: it is not necessary to create a physical keyring in the ACF2 database.
ACF2 Virtual Keyring Authorization
There are two ways of authority checking for the R_datalib callable service:
global profile checking in the FACILITY class and ring-specific profile checking
in the RDATALIB class.
With Global profile checking a resource with the format IRR.DIGTCERT.<function>
is used. For the Keyring owner READ authority is required to the Resource class
FACILITY resource: IRR.DIGTCERT.LISTRING. For other's Keyring UPDATE authority
is required to the Resource class FACILITY resource: IRR.DIGTCERT.LISTRING.
For example:
$KEY(IRR.DIGTCERT.LISTRING) TYPE(FAC)
UID(serverUID) SERVICE(READ) ALLOW <-gives access to Owner
UID(serverUID) SERVICE(UPDATE) ALLOW <-gives access to Other's
With ring-specific profile checking, a resource with the format
<ringOwner>.<ringName>.LST is used to provide access control to a specific Keyring
on R_datalib READ functions, that are, DataGetFirst, DataGetNext, and GetUpdateCode.
For virtual keyrings the ring owner user IDs for the certificates under CERTAUTH
and SITE are in the form of *AUTH* and *SITE*. READ authority to Resource class
FACILITY resource: SITECERT.IRR_VIRTUAL_KEYRING.LST for SITECERT or
CERTAUTH.IRR_VIRTUAL_KEYRING.LST for CERTAUTH.
For example:
$KEYSITECERT.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
UID(serverUID) SERVICE(READ) ALLOW
$KEY(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
UID(serverUID) SERVICE(READ) ALLOW
Note: If a certauth certificate with a PRIVATE KEY is in the ACF2 database it wil be validatied for DELETE authority against CERTAUTH.IRR_VIRTUAL_KEYRING.LST
instead of READ authority due to the power of having a private key.