Add Certificate trust verification in CSNDDSV service

Apologies for the delay, I have somehow missed the final update.

Here is how I visualize the service to be used for CA trust validation.

Leaf to be validated only against the Intermediate-n certificate.

Change inputs to the API

Intermediate-n becomes leaf and validated against intermediate-n-1

Loop thru the ICSF API calls with intermediate certificates till validation is complete with CA root certificate.

1) Currently I am working to implement TR34 Remote Key Loading and both the EPP vendors have only 2-layer chain. (leaf, intermediate and root). These certificates are passed to us via Email.

2) I have been advised by my Mainframe Security Services team that the Intermediate and Root certificates can be loaded into TKE using a USB stick, but as per company policy we are not able to load the certificates received via email into USB.

Not validating the CA trust anchor due to the above limitation poses a higher risk than validating it by the application itself.

Thanks,

Kalai

Thank you for this update. Please sketch this out in a bit more detail for me. Exactly what would be passed in to the service?
The use case as I understand it is:
=Objects=
--'leaf': CRL or X.509 signed object is desired to be validated against a CA trust anchor
--'intermediate-n': certificates that form a chain from the CA trust anchor to the leaf
--'CA trust anchor': self-signed certificate that forms the base of the chain.
=API=
-inputs mentioned:
--leaf
--CA trust anchor

QUESTIONS:
(1) How are the intermediate-n objects passed? Are these received in an envelope with the 'leaf' that is passed to the API? Or will this always be a shallow 2-layer chain?
(2) Please help me understand the HSM value-add. If the trust anchor is not loaded securely to the HSM using a TKE, limiting the scope of 'acceptance' to what is securely loaded, how is the secure boundary helping? In some cases there is a regulatory benefit. A convenience benefit is not a 'bad' answer either - I just want to understand the request.

One additional justification is that for TR34 services, we use Certificate Revocation List from Certificate Authority in CSNDT34B, CSNDT34D services. If there is any integrity issue with the CRL, then it will be rejected by the EPP during the BIND, REBIND and Key Loading process which means the ATM will remain out of service causing a service downtime.

If the CSNDDSV service can accept the CRL in PEM/DER format as input data and validate the Hash and Signature using the CA certificate, we could avoid the last minute failures.

We consider this a valid request and will add it to our list of work for prioritization.

Thanks for the clarification about the PCI compliance on loading the CA certificate using TKE. My thinking was to give autonomous to application programmer to do the trust verification by going thru loops until all the certificates in the chain is validated. This combined with the PKI-NONE rule array parameter will remove the dependency on ICSF admin team.

Please consider and respond on the interface update that is desired. In general it is noted and understood that we need multi-certificate PKCS#7 support. For your further comment about accepting CA certificates, please clarify if you mean intermediate CA certificates in the chain or mean to also include the CA Root certificate (trust anchor)? There are 2 ways to do it:
(1) PCI compliant: Passing a trust anchor to the service un-secured is not compliant. In current code, a trust anchor has to have been loaded under dual control from a TKE. However, we don't care where in the chain the anchor is. So if you want to load a much more general CA cert to the card and pass some intermediate certs, this would be good support to add in our firmware. We currently let you pass 1 cert through the interface. There are a few ways to pass multiple certs: concatenated together (naive); or structured (pkcs7).
(2) Not compliant: The security of the extra certificates passed is meaningless unless they have loaded a trust anchor under dual control. There is no security difference between: (1) untrusted leaf certificate versus (2) 1 untrusted leaf certificate and N untrusted intermediate/CA certificates. It doesn't matter if the chain terminates in a self-signed cert from some CA - they're all passed un-secured through the API. However, there is a convenience benefit: if you get a grab-bag of certs in a pkcs#7 from your partner, we would be parsing it out instead of you.

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Z and LinuxONE Systems Hardware
Product - Z and LinuxONE Systems Hardware
Component - Crypto HW
Operating system - IBM z/OS
Source - None

For recording keeping, the previous attributes were:
Brand - Servers and Systems Software
Product family - z Systems Software
Product - z/OS
Component - ICSF
Operating system - IBM z/OS
Source - None