OpenPubkey

OpenPubkey connects a user or workload identity established through OpenID Connect to a public key, allowing that identity to sign messages or artifacts. Its PK Token is proof that an identity controlled its associated private key at a particular time, provided the verifier trusts the identity provider. The project supports user and workload identities and lists Google, Azure/Microsoft, Okta, OneLogin, and Keycloak as compatible without provider changes. However, its client and verifier currently create and check PK Tokens from Google for users and GitHub for workloads. GQ signatures are required for current workload identity use cases; user scenarios do not need them when the PK Token is not public. Public tokens can expose claims from an OIDC ID Token, potentially including a name or email address. OpenPubkey says an added certificate authority is not needed because the identity provider fulfills that role. It is a free Linux Foundation project released under Apache 2.0, and its repository says it is being prepared for version 1.0. The project directs technical questions to GitHub issues and provides a community Slack channel.

OpenPubkey provides an open-source approach to linking OIDC identity with signing keys, with a free Apache 2.0 license. Its current token providers and public-token privacy implications are important constraints to consider.

OpenPubkey may suit developers building identity-linked signing for messages or artifacts, including user and workload identity use cases. Users should consider current provider support and the possibility that public tokens reveal identity claims.

OpenPubkey is open-source software for connecting OpenID Connect identities to keys that sign messages and artifacts. It is best suited to teams that want identity-backed signing within workflows built around an OpenID Provider. Its CA-free trust model is appealing, though current provider support and public-token privacy narrow the fit.

Overview

OpenPubkey links a user or workload identity to a public key through OpenID Connect. A PK Token shows that the identity controlled the associated private key at a particular time, assuming the verifier trusts the identity provider. That makes OpenPubkey a signing building block rather than a certificate service: it provides no certificate and relies on the OpenID Provider in the certificate authority role.

The project supports signing messages and artifacts. Its Go client and verifier example walks through authentication, PK Token creation, signing, and verification. Docker is building a public container registry that uses OpenPubkey to sign Docker Official Images, and BastionZero uses it for secure remote infrastructure access.

Key features

Identity-backed keys

OpenPubkey can associate a signing key with an existing OIDC identity without requiring changes to the identity provider or a new certificate authority. This is a practical advantage for teams whose verifiers already trust that provider. It does not remove the need to make that trust decision: the PK Token proves control only when the verifier accepts the provider.

Provider support and replay protection

The project says OpenPubkey is compatible with Google, Azure/Microsoft, Okta, OneLogin, and Keycloak without provider changes. Its client and verifier currently create and verify user PK Tokens from Google and workload PK Tokens from GitHub, so teams relying on the other named providers should account for the narrower current implementation.

GQ signatures let the provider's signature be stripped from an ID Token while preserving proof that the provider signed it. This prevents the token from being replayed against OIDC resource providers. GQ signatures are required for current workload identity use cases; user scenarios do not need them when the PK Token remains private.

Key handling and privacy

OpenPubkey assumes identity-held key pairs are ephemeral: users generate them as needed and delete them when finished. That model suits short-lived signing workflows, but teams must manage key creation and cleanup as part of their process. Public PK Tokens can expose claims from the signer's ID Token, including a name or email address, so publishing them may reveal personal information.

User identity scenarios can add an optional MFA cosigner protocol, which independently authenticates the user and cosigns the PK Token. It is unsupported for workload identities, limiting that extra authentication option to user flows.

Pricing

OpenPubkey costs nothing. The OpenPubkey plan is open-source software under the Apache 2.0 license and includes a reference implementation. There are no paid tiers or usage quotas described; the project is being prepared for version 1.0, so teams adopting it should be comfortable working with a project still approaching its first major release.

OpenPubkey is a Linux Foundation project. Technical questions, bug reports, and feature requests go through GitHub issues, with a community Slack channel for discussion. Its security policy asks reporters to email [email protected] privately and says there is no bug bounty program.

Platforms

OpenPubkey supports API, Linux, macOS, self-hosted, and Windows environments. The Go client and verifier example makes it most directly suited to teams able to work with that implementation; no certificate is provided.

Who it's for

OpenPubkey is a strong candidate for teams that want messages or artifacts signed with keys tied to user or workload identities, and whose verifiers can trust the relevant identity provider. It is especially compelling where avoiding a separate certificate authority matters. Teams should look elsewhere if they need current user-token support from a provider other than Google, current workload-token support from a provider other than GitHub, or public tokens that do not expose identity claims.

Pros and cons

• Pro: Connects identity to signing keys through OIDC without adding a separate certificate authority, reducing the number of trust services a team must introduce.
• Pro: Supports both user and workload identities, with messages and artifacts as signing targets.
• Pro: Apache 2.0 licensing and a reference implementation make it available for teams to adopt and adapt without a software fee.
• Con: Current client and verifier support is limited to Google for users and GitHub for workloads, despite broader provider compatibility claims.
• Con: Public PK Tokens may disclose signer claims such as a name or email address.
• Con: Workload identity use currently requires GQ signatures, and user MFA cosigning is not available for workloads.

Alternatives

Code Signing Software is a useful starting point for comparing signing tools across the category.

• Cosign is a free, open-source option for teams seeking signing software with Linux, macOS, self-hosted, and Windows support and no stated hosted-service or usage limits.
• Notation is a free Apache 2.0 CLI project for teams looking for a command-line signing tool across Linux, macOS, or Windows.
• SignPath offers a free code-signing plan for eligible open-source projects, with API, web, desktop, and self-hosted platform support.
• SignPath Foundation fits eligible open-source projects that are actively maintained and released under an OSI-approved license and can use manual approval for each release.
• SignServer has a free community plan for basic code, document, and container signing plus timestamping, with source-code or container deployment.
• AWS Signer is an option for teams signing through AWS services, with no additional charge for use with AWS IoT Device Management, AWS Lambda, Amazon ECR, Amazon EKS, or third-party container services.
• Sigstore is free for developers and software providers seeking a signing option for Linux, macOS, self-hosted, Windows, or API environments.
• Aujas Automated Code Signing Platform is another code-signing option with signing-based licenses.

Verdict

Choose OpenPubkey if you want to tie signing keys to identities your systems already trust through OIDC, and can work within its current Google user and GitHub workload support. Its free Apache 2.0 reference implementation and lack of a separate certificate authority make a clear case for identity-centered signing. Look elsewhere if broader current provider support or privacy for public identity tokens is essential.