SECURITY ADMINISTRATION OVERVIEW

This chapter discusses how to utilize SecureZIP for z/OS to secure your data. Elements that are required to make a SecureZIP for z/OS archive are discussed in detail. These elements, when selectively used, combine to create a SecureZIP for z/OS archive or allow the

extraction of a file or files from a SecureZIP for z/OS archive.

A series of ISPF panels assists you in building and maintaining the SecureZIP for z/OS Certificate Store, where digital certificates used by SecureZIP for z/OS are kept. These panels are not part of the separately licensed feature “ISPF”. They are standard with

SecureZIP for z/OS. The ISPF screens and SecureZIP for z/OS commands used to work

with them are shown in this chapter, along with notes and comments.

Beginning with SecureZIP for z/OS 11.0, digital certificates can be used from the system Security Server (for example, RACF). The present chapter applies for the initialization of the SecureZIP key store index components and for defining policy controls for the use of all certificates. Administration of Security Server certificates is covered in the SecureZIP for z/OS Security Administrator’s Guide.

Accessing Certificates

SecureZIP for z/OS provides access to certificates held within the z/OS Security Server,

local data sets, and VSAM index paths when control card requests are present. In addition, RECIPIENT(LDAP"...) requests are resolved through configured network definitions.

Public Key Certificate

Certificate-based encryption allows the exchange of encrypted data without the exposure of also exchanging or retaining a password. This form of encryption uses a public-key digital certificate when creating and it then uses a corresponding private-key certificate by the

recipient to decrypt. Digital certificates may be identified and selected by naming information, such as “Common Name,” or email address.

When encrypting data for specified public-key recipients, SecureZIP for z/OS uses digital certificates in a process called digital enveloping. See the

A public-key certificate consists of the public portion of an asymmetric cryptographic key (the "public key"), together with identity information, such as a person's name, all signed by a

certificate authority (CA). The CA essentially guarantees that the public key belongs to the

named entity.

Private Key Certificates

To UNZIP a file that has been encrypted with a public-key certificate, the receiver must supply a matching private-key certificate. This is done by including RECIPIENT commands that specify the location of the private-key certificate along with its associated access password. Note this password is not a password used to encrypt a file, but rather a password that is used to access the private-key certificate.

RECIPIENT commands may be included in the command input stream directly or be included through the INCLUDE CMD command. A Private-Cert profile designates a saved repository of the private-key certificates. The RECIPIENT commands are automatically included when

SecureZIP for z/OS dialogs prepare batch JCL or UNZIP call streams and File Decryption is

requested.

Certificate Authority and Root Certificates

End entity certificates and their related keys are used for signing and authentication. They are

created at the end of the hierarchy of certificate authorities. Each certificate is signed by its CA issuer and is identified in the “Issued By” field in the end certificate. In turn, a CA certificate can also be issued by a higher level CA. Such certificates are known as intermediate CA certificates. At the top of the issuing chain is a self-signed certificate known as the root.

SecureZIP uses the certificates for signing and authentication operations. SecureZIP for z/OS makes use of these certificates in PKCS#7 format. The intermediate CA certificates are

maintained independently from the ROOT certificates.

Configuration Profile

A configuration profile is a collection of SecureZIP for z/OS commands that describe the necessary environment. At execution time this profile is read to locate the appropriate stores and index. SecureZIP for z/OS provides various means by which the configuration

information can be supplied. Contact your technical support staff for instructions regarding access to the configuration.

Contents of the Configuration Profile

Execution configuration values may be supplied in any of the following ways. It is highly recommended that the command sources be coordinated in logical groups (Local Cert Store settings, or LDAP settings) so that overrides are not overly complex.

 Direct commands in the SYSIN stream

When accepted, these commands take precedence over other sources.

 INCLUDE_CMD indirect reading of profile commands

This is the method employed when you specify a file location through the SecureZIP Active DB Profile: field. When accepted, these commands take precedence over profiles read by the Defaults module, but may be overridden by SYSIN commands.

 Defaults module indirect reading of profile commands

This is the method employed when you specify UNDEFINED in the SecureZIP Active DB Profile: field.

Data Base (DB) Profile (Local Certificate Store)

During SecureZIP for z/OS processing that requires encryption intended for a RECIPIENT, associated public-key certificate(s) must be located. One way of designating which public-key recipients to include is through the DB: form of the RECIPIENT command. This allows for recipient selection based on name or email address through a configured database of certificates on the system that is executing SecureZIP for z/OS.

Your technical support staff is responsible for configuring the local certificate store and should provide you with information on which profile dataset, typically a member of a partitioned data set, to use. Below is a sample of the contents of the data base profile.

* --- * * Local zSeries development certificate store * * --- * -{CSPUB=4;1;SECZIP.CERTSTOR.PUBLIC} -{CSPRVT=4;1;SECZIP.CERTSTOR.PRIVATE} -{CSCA=1;1;SECZIP.CERTSTOR.PUBLIC(CAP7)} -{CSROOT=1;1;SECZIP.CERTSTOR.PUBLIC(ROOTP7)} -{CSPUB_DBX=SECZIP.CERTSTOR.PUBLIC.DBX} -{CSPUB_DBX_PATH_CN=SECZIP.CERTSTOR.PATHCN} -{CSPUB_DBX_PATH_EM=SECZIP.CERTSTOR.PATHEM} -{CSPUB_DBX_PATH_PUBKEY=SECZIP.CERTSTOR.PATHPUBK}

LDAP Profile (Networked Certificate Store)

During SecureZIP for z/OS processing that requires encryption intended for a RECIPIENT, the associated public-key certificate(s) must be located.

One way of designating which public-key recipients to include is through the LDAP interface to a directory server: form of the RECIPIENT command. This allows for recipient selection based on name, email address or other installation-configured LDAP fields. One or more LDAP compliant servers may be configured for searching.

The technical support staff responsible for configuring the LDAP compliant directory that stores certificates will provide you with information of which profile dataset, which is typically a member of a Partitioned Data Set, to use. Below is a sample of the contents of the file.

* --- * * zSeries LDAP access * * --- * * --- * Primary LDAP * --- -{LDAP=1;192.168.9.12;389;0;0;;;*EMAIL;| o=pkware,c=US,cn=user,dc=cosmos,dc=securezip,dc=com} * ---

Recipient Searches

When RECIPIENT requests are made for either the local certificate store (DB:), an LDAP store

(LDAP:), or both, (SYSTEM:), a set of search criteria are provided. The search criteria of Email

address (EM= or mail=) and Common Name (CN=) are accepted by both the DB: and LDAP:

service providers.

When multiple RECIPIENT requests are made, it is possible that two or more search criteria may resolve to the same recipient certificate. For example, if both EM= and CN= are used in different RECIPIENT (or MASTER_RECIPIENT) requests, then the same public key certificate may be found. The first entry found will be used, and any duplicate copies of the same certificate will be ignored, resulting in only one representation of that certificate.

A search for an individual by name or e-mail address may result in multiple digital certificates being located, whether from the same certificate store source or not. This means that more than one representation of an individual can be included in the run.

LDAP searching can be accomplished with direct RECIPIENT requests via

RECIPIENT(LDAP:search_criteria) or implicitly with

RECIPIENT(*system:search_criteria). In both cases, the Certificate Store Configuration

settings define the order in which the LDAP servers are to be searched. However, in the case of using "*system", local certificate stores are searched prior to any of the configured LDAPs. When multiple stores are to be searched (*system: or LDAP:), all RECIPIENT requests are

searched in one store before the next store is referenced. If a RECIPIENT request has one or more entries found in one Store, then subsequent stores are not searched for that request. This means that it is possible for generic LDAP search criteria to bypass entries defined in subsequent LDAP servers. RECIPIENT requests that were not satisfied at all by the higher- level Store search will continue to be searched for.

Example: Search LDAP’s for RECIPIENT matches

LDAP #1 0 entries 0 matches

LDAP #2 3 entries 3 matches

Add entry LDAP #1 has an entry added matching RECIPIENT

LDAP #1 1 entry 1 match

Local Certificate Stores