Protecting end-user functions

You must first determine who your end-users are and how they will be using their certificates. In general there are two categories of end-users:

Internal clients, such as employees who have SAF user IDs on the host system and who might be using their certificates to access resources on the host
External clients, who have no access to the host system.

When PKI Services is called, the unit of work has some identity (user ID) associated with it. For external customers, a surrogate user ID is necessary.

Guideline: Although under certain circumstances it might be beneficial for internal clients to access PKI Services under their own identities, your implementation will be simpler if you use surrogate user IDs for internal clients as well.

Use the RACF® ADDUSER command to create the surrogate user ID (PKISERV). Give it an OMVS segment because it needs access to z/OS UNIX. Guideline: Define the surrogate user ID with the PROTECTED and RESTRICTED attributes.

The R_PKIServ SAF callable service is protected by FACILITY class resources of the form IRR.RPKISERV.function[.ca_domain], where function is one of the following and ca_domain specifies an optional CA domain name. (Specify ca_domain when your installation has established multiple PKI Services CAs.)

The R_PKIServ functions are:

EXPORT: Retrieves (exports) a previously requested certificate, or retrieves (exports) the PKI Services registration authority (RA) certificate or the certificate authority (CA) certificate.
GENCERT: Generates an auto-approved certificate.
GENRENEW: Generates an auto-approved renewal certificate. (The request submitted is automatically approved.)
QRECOVER: Lists certificates whose key pairs were generated by PKI Services under a requestor’s e-mail address and passphrase.
REQCERT: Requests a certificate that an administrator must approve before it is created.
REQRENEW: Requests certificate renewal. The administrator needs to approve the request before the certificate is renewed.
RESPOND: Invokes the PKI OCSP responder.
REVOKE: Revokes a certificate that was previously issued.
SCEPREQ: Generates a certificate request using Simple Certificate Enrollment Protocol (SCEP).
VERIFY: Confirms that a given user certificate was issued by this certificate authority and, if so, returns the certificate fields.

Create these resources and give the PKISERV user ID either READ or CONTROL access to them. CONTROL bypasses subsequent resource checks.

Additional FACILITY class resources of the form IRR.DIGTCERT.function protect the actual certificate generation and retrieval functions. If subsequent resource checks are not being bypassed, define these resources and their access.

There are two ways to handle certificate approval:

An administrator can review certificate requests
Requests can be auto-approved without administrator action (this should probably be reserved for internal clients only).

If you plan to have an administrator approve certificate requests before issuing certificates, PKISERV needs the following access:

Table 1. Access required if you plan to have an administrator approve certificate requests
Resource	Access
IRR.DIGTCERT.REQCERT	READ
IRR.DIGTCERT.REQRENEW	READ

If your clients can request certificates that are auto-approved without action by an administrator, PKISERV needs the following access:

Table 2. Access required if you plan to use auto-approval
Resource	Access
IRR.DIGTCERT.ADD	UPDATE
IRR.DIGTCERT.GENCERT	CONTROL
IRR.DIGTCERT.GENRENEW	READ

Finally, because the Web server will be switching identities to PKISERV, you must give it surrogate permission. This is done by creating another resource in the SURROGAT class (BPX.SRV.PKISERV) and giving the Web server daemon user ID READ access to it.