Does ACF2 support virtual Keyrings?

Products

• ACF2
• ACF2 - DB2 Option
• ACF2 - z/OS
• ACF2 - MISC

Issue/Introduction

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: 16.0

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 User Profile 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.
- 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:

$KEY(SITECERT.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 will be validated for DELETE authority against CERTAUTH.IRR_VIRTUAL_KEYRING.LST instead of READ authority due to the power of having a private key.