All IBM z/OS digital certificates in use must have a valid path to a trusted Certification Authority (CA).

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-223871	TSS0-CE-000010	SV-223871r998483_rule		Medium

Description
Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a CA. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000403-GPOS-00182

Description

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a CA. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000403-GPOS-00182

STIG	Date
IBM z/OS TSS Security Technical Implementation Guide	2024-06-24

Details

Check Text ( C-25544r998384_chk )
Execute the CA-TSS SAFCRRPT using the following as SYSIN input: RECORDID(-) DETAIL TRUST FIELDS(ISSUER SUBJECT ACTIVE EXPIRE TRUST) If no certificate information is found, this is not a finding. NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following check. If the digital certificate information indicates that the issuer's distinguished name leads to one of the following this is not a finding: a) A DOD PKI Root Certification Authority b) An External Root Certification Authority (ECA) c) An approved External Partner PKI's Root Certification Authority The DOD Cyber Exchange website contains information as to which certificates may be acceptable (https://public.cyber.mil/pki-pke/interoperability/ or https://cyber.mil/pki-pke/interoperability/). Examples of an acceptable DOD CA are: DOD PKI Class 3 Root CA DOD PKI Med Root CA

Check Text ( C-25544r998384_chk )

Execute the CA-TSS SAFCRRPT using the following as SYSIN input:
RECORDID(-) DETAIL TRUST FIELDS(ISSUER SUBJECT ACTIVE EXPIRE TRUST)

If no certificate information is found, this is not a finding.

NOTE: Certificates are only valid when their Status is TRUST. Therefore, you may ignore certificates with the NOTRUST status during the following check.

If the digital certificate information indicates that the issuer's distinguished name leads to one of the following this is not a finding:
a) A DOD PKI Root Certification Authority
b) An External Root Certification Authority (ECA)
c) An approved External Partner PKI's Root Certification Authority

The DOD Cyber Exchange website contains information as to which certificates may be acceptable (https://public.cyber.mil/pki-pke/interoperability/ or https://cyber.mil/pki-pke/interoperability/).

Examples of an acceptable DOD CA are:
DOD PKI Class 3 Root CA
DOD PKI Med Root CA

Fix Text (F-25532r998385_fix)
Remove or replace certificates where the issuer's distinguished name does not lead to a DOD PKI Root Certification Authority; External Root Certification Authority (ECA); or an approved External Partner PKI's Root Certification Authority. The DOD Cyber Exchange website contains information as to which certificates may be acceptable (https://public.cyber.mil/pki-pke/interoperability/ or https://cyber.mil/pki-pke/interoperability/).

Fix Text (F-25532r998385_fix)

Remove or replace certificates where the issuer's distinguished name does not lead to a DOD PKI Root Certification Authority; External Root Certification Authority (ECA); or an approved External Partner PKI's Root Certification Authority.

The DOD Cyber Exchange website contains information as to which certificates may be acceptable (https://public.cyber.mil/pki-pke/interoperability/ or https://cyber.mil/pki-pke/interoperability/).