Does ACF2 support virtual Keyrings?

Document ID : KB000018198
Last Modified Date : 15/05/2018
Show Technical Document Details
Introduction:

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*/*

The following sample commands can be used to create a virtual Keyring from TSO, ACF.

ACF
SET PROFILE(USER) DIV(KEYRING)
insert *auth* ringname(*)   
KEYRING / *AUTH* LAST CHANGED BY USER02 ON 06/24/14-11:16    
                      DEFAULT() RINGNAME(*)  

Solution:

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) and certificates defined with USAGE=CERTAUTH/SITECERT will be returned with the KEYRING
from the R_datalib calls. 

Details on Keyrings can be found in the CA ACF2 for z/OS Administration Guide r15, Chapter 3: Maintaining
Logonid Records, section 'KEYRING Profile Data Records'.

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: *SITE*.IRR_VIRTUAL_KEYRING.LST for SITE or
*AUTH*.IRR_VIRTUAL_KEYRING.LST for CERTAUTH. 

For example:

$KEY(*SITE*.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
 UID(serverUID) SERVICE(READ) ALLOW

$KEY(*AUTH*.IRR_VIRTUAL_KEYRING.LST) TYPE(RDA)
 UID(serverUID) SERVICE(READ) ALLOW

 

Instructions:
Please Update This Required Field