openmainframeproject
ztrust Working Group
Working group name: ztrust Working group purpose: define and maintain a public "trust anchor" for Z related systems, software, services, and individuals Working group deliverables: a collection of PKI certificates (especially root certificates) and PGP keys (especially cross-signed)
The purpose of the working group is to assemble a sufficient number of trusted PGP keys for to establish a web-of-trust. Many of the PGP keys will be cross-signed. Many of the PGP keys will also be signed by PGP key holders from the larger web-of-trust. The working group will also assemble a collection of PKI certificates. These certificates will be PGP-signed by keys in the PGP collection, extending trust from the PGP space to the PKI space.
The value of this collection is, among other things, to substantiate the supply chain of volunteer- and user-contributed software packages, such as found on the CBT tape.
Original proposal below:
Project description
This project establishes a collection of PKI root certificates and (especially) PGP public keys with PGP signatures assuring veracity.
For a similar project, see the Debian community public keyring.
PKI root certificates from recognized cerficate authorities (CAs) have their own trust paths and should not be included here (to avoid cerificate flooding).
Statement on alignment with Open Mainframe Project Mission and Vision statements
Enable the mainframe to be more consumable by developers with a transparent experience in leveraging the value propositions of the mainframe. This project specifically enables code signing without the requirement of uninvested CAs as a third party.
Ensure the mainframe aligns well in the changing enterprise IT landscape of cloud-native and DevOps. Increasing numbers of open source and volunteer-provided software project artifacts are cryptographically signed.
The mainframe is an active, integrated, and essential part of modern enterprise IT, consumable by mainstream developers and users, and driven by a vibrant open source community. This project enables increased trust in the community supply chain.
Are there similar/related projects out there?
Same concept in the z/VM community.
https://github.com/trothr/vmworkshop/tree/master/ztrust/
THIS project explicitly encompasses the larger mainframe community (z/OS, z/VSE, and of course z/Linux).
Sponsor from TAC
To be appointed
Proposed Project Stage
Active
License and contribution guidelines
Cryptgraphic signatures are published without license and are intended to be used freely. A close license would be LGPL. Unless someone raises objection or cites a requirement, licensing is not applicable (N/A).
Current or desired source control repository
https://openmainframeproject.org/ztrust/
External dependencies (including licenses)
'gpg' and 'openssl' which are standard on most Linux distrubitions (including z/Linux)
SystemSSL from IBM for historical mainframe operating systems (z/OS, z/VM, z/VSE)
Initial committers
Initial committers: Rick Troth https://github.com/trothr, Matt Hogstrom https://github.com/hogstrom
Interested parties: Berry van Sleeuwen [email protected], Tom Kern [email protected], Jim Moling [email protected] (there are others but I should cap it here)
Infrastructure requests
CI and build are not applicable (N/A)
Communication channels
Email is preferred. Encrypted email is best (and forces use of the project described here).
Discord MAY have a channel for this project under the "System Z Enthusiasts" umbrella. The topic has been discussed there.
Communication channels
There is no issue tracker. The plan is to utilize GitHub issue tracking once the repository is established.
Website
https://github.com/trothr/vmworkshop/tree/master/ztrust/
Release methodology and mechanics
there is no release cycle
Both PKI and PGP support the concept of expiration.
PGP keys can be delivered via "PGP key servers".
Both PGP keys and PKI root certificates can be retrieved from the repository proposed in this request.
Social media accounts
There are no (e.g.) Twitter or Facebook accounts for the project. The project has been discussed on Discord. It has also been discussed on LISTSERV-based email forums such as IBM-MAIN.
Community size and any existing sponsorship
Less than a dozen contributors at this time (2025 September).
One other area that we can focus on (not sure it needs to be in the proposal at this point) is education on managing pgp keys, uses, etc. Given the mainframe community is not as well versed with uses like code signing, non-repudiation in e-mail, etc. So, there is an educational component to this project in addition to key management.
Cryptgraphic signatures are published without license and are intended to be used freely. A close license would be LGPL. Unless someone raises objection or cites a requirement, licensing is not applicable (N/A).
I wonder if the CC0 public domain dedication might be a suitable way to indicate that public keys are meant to be public?
@jt-nti I had the same thought. The public key is really in the open ... it is free to use as a means to verify authenticity. Although, I've never seen someone attach a license to the key. I would prefer to indicate a statement like "These keys may be freely distributed under the Apache License V2." In general, if used for code signing I would expect that the project that is using the key for signing would either default to the license for the software being distributed but if needed Apache 2.0 should be more than sufficient and is generally well understood.
