Does ACF2 support virtual Keyrings?

Products

• CA ACF2
• CA ACF2 - DB2 Option
• CA ACF2 for zVM
• CA ACF2 - z/OS
• CA ACF2 - MISC
• CA PanApt
• CA PanAudit

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

 

Environment

Release: ACF2..001AO-15-ACF2
Component:

Resolution

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.