We would like digitally signed software downloads for the z/TPF Product Family

Based on resources and priorities, the z/TPF lab does not expect to implement this idea in the foreseeable future. The code signing implementation used by the client in the IBM supported solution does not support signing artifacts in a native Linux Z build environment (s390x). The z/TPF Product Family requires a solution for the s390x environment.

Discussion on a possible solution to this continues within the z/TPF lab. We expect to have further information within the next 2 weeks. Thank you for your patience.

May we have an update on this RFE?

The customer would like to be able download the “SW package” first, and then later be able to digitally verify it via some LINUX command using a CA signed cert provided by IBM. They don’t think the validation checking should be performed at the same time as when they download the SW, because if the IBM website is hacked, they would not know that the SW is compromised.

z/OS already supports digitally signed SW downloads so they suggest that the zTPF lab can follow the z/OS’s lab lead?

Note: The IBM z/TPF lab would be limited to signing the archive of the source material that is delivered with an APAR. Given the nature of the product, the actual binaries are not built and shipped by IBM. We could sign the individual source files shipped with the APARs, however the understanding is that those source files can be (and are) modified by the client and the signature would no longer be verifiable. It is something we can do to blindly meet the requirement, but is limited to validating the archive you download from the private download site which requires authentication to access.

Does the ability to perform a validation check on the IBM signed archive files you would download from the same secure private download site used today meet the requirements needed to no longer file for an exception?

Responding on behalf of the customer, here are their responses:

1. Are you using the cosign utility today or would the TPF lab need to sign the tar in such a way to allow openssl to perform the validation step? I checked our Enterprise Architecture list of approved software, nothing came up for “cosign” or “code sign”. Seems like we would want to use OpenSSL on LINUX to validate the package instead.

2. What are your algorithm requirements? AES256 would be good, or just follow industry directions to support “commonly approved and secure” cipher algorithms as time goes on. In general…IBM would use a private key to encrypt the message digest, we would decrypt it using a public key that was signed by a well known Certificate Authority.

3. How many bytes of SHA are needed? SHA256 would be good, or just follow industry directions to support “commonly approved and secure” hashing algorithms as time goes on

Please provide the following information so we can proceed with the investigation on this idea. Thank you.

Are you using the cosign utility today or would the TPF lab need to sign the tar in such a way to allow openssl to perform the validation step?
What are your algorithm requirements?
How many bytes of SHA are needed?

https://pages.github.ibm.com/Supply-Chain-Security/AppSec-External-Docs/appsec/CodeSigningService/LocalSign/WhatDoYouWantToSign/freeformtgztar/