How can the private key of a personal certificate be accessed by an ACF2 user that is not the owner of the certificate?

Release:
Component: ACF2MS

When R_datalib calls are made to retrieve certificates from a keyring, if the caller is the owner the private key will be returned. Also users that have access to the RDATALIB resource class resource <ringOwner>.<ringName>.LST or a user with SECURITY or NON-CNCL authority will be able to retrieve the private key of another user's certificate connected with usage PERSONAL.

The Resource class RDATALIB validation is used to check if a user(logonid) can access the Private Key of a Personal certificate when that user is not the owner of the certificate.

There are two checks that are done for Keyring access, Ring-specific profile checking and Global profile checking. Ring-specific profile checking uses the RDATALIB resource class resource <ringOwner>.<ringName>.LST. Global profile checking uses the FACILITY resource class resource IRR.DIGTCERT.LISTRING.

With ring-specific profile checking, a resource with the format <ringOwner>.<ringName>.LST is used to provide access control to a specific key ring on R_datalib READ functions, that are, DataGetFirst, DataGetNext, and GetUpdateCode.

The resource <ringOwner>.<ringName>.LST in the RDATALIB class is checked first. If an RDATALIB class Ring specific rule <ringOwner>.<ringName>.LST exists, ACF2 uses the ring-specific checking, ACF2 will not go to Global profile checking. If no RDATALIB class <ringOwner>.<ringName>.LST rule exists, Global profile checking is done for access to the keyring..

Applications can call the R_datalib callable service (IRRSDL00) to extract the private keys from certain certificates. A private key is returned only
when the following conditions are met:

• The certificate is connected to its key ring with the PERSONAL usage option.
  
  
• One of the following two conditions is true:
  
  
  • The caller's user ID is the user ID associated with the certificate. Certificates are stored in the ACF2 INFOSTG database as CERTDATA Profile Records with a RECID of logonid.suffix. If the caller's user/logonid matches the RECID of the certificate it is considered the owner(associated with the certificate)
    
    
  • The caller's user ID has UPDATE authority to the <ringOwner>.<ringName>.LST resource in the RDATALIB class.

With ACF2 the RDATALIB resource class is protected by TYPE(RDA) resource rules by default.

Note: The resource type (R-RRDA) is required to be added to the GSO INFODIR record.

SET CONTROL(GSO)
CHANGE INFODIR TYPES(R-RRDA) ADD
F ACF2,REFRESH(INFODIR)

After adding or updating any TYPE(RDA) rules the following REBUILD command should be done.

F ACF2,REBUILD(RDA)

Example:

The following example demonstrated how to code a RDATALIB resource class rule to allow logonid TEST001 access to the private key in the Personal certificate FTPD.CERT.

The Keyring is owned by FTPSERVE and the certificate is owned by FTPD:

KEYRING / FTPSERVE.RING LAST CHANGED BY USER001 ON 01/21/13-19:18
                    DEFAULT() RINGNAME(SERVER)
The following certificates are connected to this key ring:
CERTDATA record      Label                           Usage
-----------------    -----------------------------   --------
CERTAUTH.SIGNER      LOCAL CA CERTAUTH               CERTAUTH
FTPD.CERT            FTPD CERTIFICATE                PERSONAL

The RDATALIB resource name in the format <ringOwner>.<ringName>.LST is FTPSERVE.SERVER.LST.
The resource rule to allow logonid TEST001 access to the private key of FTPD.CERT follows.

$KEY(FTPSERVE) TYPE(RDA)
SERVER.LST UID(uid of TEST001) SERVICE(UPDATE) ALLOW