Overview of PKITP

The PKI Services Trust Policy (PKITP) is an OCSF plug-in to perform certificate validation against a SAF key ring that contains a trusted CA or site certificate (called an anchor certificate) or a virtual key ring of either CERTAUTH or SITE certificates. For information about creating a SAF key ring using the RACDCERT ADDRING command, see z/OS Security Server RACF Command Language Reference. For information about using a virtual key ring with the R_datalib callable service, see z/OS Security Server RACF Callable Services.

PKITP supports the following two functions through the implementation of CSSM_TP_PassThrough:

CertGroupVerify
FreeEvidence

Server applications running on z/OS® can use this function to verify certificates that other network entities (for example, users and other servers) present. PKI Services or other certificate authorities might have issued these certificates.

The server application must attach to and open the key ring using the OCEP DL plug-in. (For more information about OCEP and the use of SAF key rings, see Integrated Security Services Open Cryptographic Enhanced Plug-ins Application Programming .) The server application must also bind to any needed LDAP directories by attaching to and opening these directories using the OCSF LDAPDL plug-in. These LDAP directories can be internal corporate directories, directories of extranet business partners, directories of public certificate authorities, or combinations of these.

The following figure illustrates this diversity. The uppercase letter boxes are certificate authorities, and the lowercase letter boxes are end-entity certificates.

Figure 1. Examples of organizations, certificates, and chains

Example showing external organizations, chains, SAF key ring, and certificates

Organization A represents the local (corporate) certificate hierarchy. It contains one self-signed root certificate A. Perhaps RACF® or the Tivoli® PKI created this. B, C, and D are intermediate CAs. They could be separate instances of PKI Services. Certificates issued within this hierarchy are stored in an LDAP directory accessible to corporate server applications.

Organization E represents a public or business partner's certificate hierarchy with an LDAP directory that allows anonymous access. Organization G represents some other certificate hierarchy, in which either the directory does not exist or it is not accessible. The key ring contains three anchor certificates. Certificates A and E are trusted CAs, and there is a business need to trust end-entity certificate y, even though it cannot be verified.

If each of these CAs has posted current CRLs to either their default LDAP locations or to distribution point CRLs in LDAP and all certificate chains to be verified are genuine, the PKITP CertGroupVerify function can validate the following input chains:

Single certificates x, u, v, or w (PKITP can extract the missing links from the directories.)
Chains u-B, v-C, w-D, u–B-A, v-C-A, w-D-A, x-F, or x-F-E (These chains have no missing links.)
Any chain beginning with certificate y (As Figure 1 shows, y is in the key ring as a SITE. Site certificates are trusted regardless.)

Note that, as with the OCEP Trust Policy, non-self-signed (intermediate) CA certificates can be connected to the key ring to shorten the validation path. Doing so has the following consequences:

Certificate revocation list (CRL) checking is not performed for the anchor certificate in the chain, even if this happens to be an intermediate CA certificate. If the intermediate CA certificate is revoked, PKITP does not detect it.
A chain containing the parent chain of the intermediate CA cannot be verified.
Guideline: When an intermediate CA certificate is connected to the key ring, the certificates that make up its parent chain should be connected also. This ensures that all chains originating from the intermediate CA or higher can be verified.