Bootstrapping software signatures with verified organizational identity
Who Do You Trust When You Trust a Signing Key?
Martin Stecher
September 10, 2026
The problem is not whether a software signature is valid. The harder problem is deciding why the signing key should be trusted in the first place.
Like other vendors, Cloud Fellows publishes every Web Gateway release with a checksum file and a detached OpenPGP signature. Once you have our authentic public key, the process is straightforward: verify the signature on the checksums, then verify the downloaded archive against them.
But there is a step before all of that. How do you know that the public key itself is really ours?
A valid signature proves control of a key
A cryptographic signature binds data to a private key. If the signature verifies, the artifact has not changed since somebody holding that private key signed it. Neither the mathematics nor OpenPGP can independently tell you who that somebody is.
The name in a key's User ID is not proof. Anyone can generate a key named Cloud Fellows GmbH. This is why vendors publish their public-key fingerprint on the company website and designate it as the canonical reference in case of conflicting copies. That shifts the remaining trust question to the website itself: how do you know that it really belongs to the vendor?
Cryptography can be internally consistent and still authenticate the wrong identity.
A realistic lookalike attack
Imagine an attacker builds a convincing fake WebGateway site on a lookalike domain. The site publishes an attacker's OpenPGP key and a modified binary signed with the matching private key. Its installation notes point to its own signing-key page.
The attacker can legitimately obtain a Domain Validation (DV) TLS certificate for that domain. The browser shows a secure HTTPS connection, the signing key matches the displayed fingerprint, and the malicious binary has a valid signature. Every cryptographic check succeeds, but all of them lead back to the attacker.
The missing link is not between the binary and the signing key. It is between the signing key and the expected publisher.
What DV, OV and EV actually add
Public TLS certificates can carry different levels of identity validation:
| Validation | What the CA establishes | What it adds here |
|---|---|---|
| DV | Control of a DNS name | An authenticated and encrypted connection to that domain |
| OV | Domain control plus a verified organization | Organizational identity in the certificate |
| EV | A prescriptive organization-validation process with legal-registration and jurisdiction information | More explicit evidence for a deliberate identity check |
EV does not use stronger encryption than DV. The TLS protocol, algorithms and connection security can be identical. Its additional value is the identity statement made by the certification authority. The CA/Browser Forum EV Guidelines specify the identity-proofing and certificate-profile requirements and define 2.23.140.1.1 as the reserved EV policy identifier.
The criticism of EV is valid — for a different use case
EV was once promoted as a prominent anti-phishing signal. Browsers displayed the verified company name beside the address and expected users to notice when it was absent or wrong. That expectation did not work well. In 2019, for example, the Chrome Security UX team moved EV information from the address bar into Page Info after its research found that the indicator did not reliably change users' security decisions.
That criticism is important. People should not have to inspect corporate registration details during normal browsing, and EV should not be presented as a general cure for phishing.
Bootstrapping a software-signing key is different. It is a rare, explicit administrative action. An administrator is already expected to obtain a canonical fingerprint and compare it carefully. Opening the browser's security view and checking a legal identity once is reasonable in that workflow. EV identity data may be weak as a passive security indicator while remaining useful as an explicit bootstrap trust anchor.
EV as a one-time trust bootstrap
The trust path does not make the TLS certificate another release-signing key. It uses an existing trust system to authenticate the first copy of the OpenPGP key:
browser or operating-system root store
-> publicly trusted certification authority
-> verified organization associated with the canonical domain
-> OpenPGP public-key fingerprint published on that domain
-> signatures on release checksums
-> product release archive
The browser and operating system already contain trusted CA roots. The EV certificate uses that trust to associate a legal organization with the canonical website. The website publishes the OpenPGP fingerprint. Once an administrator records that fingerprint as the trusted release-signing identity, ordinary release verification uses OpenPGP directly.
The Cloud Fellows experiment
We tested this with the real Cloud Fellows website. Until September 4, 2026, cloudfellows.de used a DV certificate. HTTPS validation succeeded, but the certificate contained no organization. We then switched the site to an EV certificate obtained through STRATO and issued by Sectigo.
cloudfellows.de, but no verified organization or registration number.
Even before the complete certificate is opened, Safari and Chrome showed more than a generic secure-connection message in our September 2026 checks. Safari said that Sectigo determined the site originates from Cloud Fellows GmbH in North Rhine-Westphalia, Germany. Chrome reported that the valid certificate was issued to Cloud Fellows GmbH in Germany.
The leaf certificate observed on September 5 contains:
O = Cloud Fellows GmbH
serialNumber = HRB 16592
jurisdictionC = DE
ST = Nordrhein-Westfalen
businessCategory = Private Organization
CN = cloudfellows.de
subjectAltName = cloudfellows.de, www.cloudfellows.de
certificatePolicies = 2.23.140.1.1
validity = September 4, 2026 to March 3, 2027
The certificate chains through the EV intermediate Sectigo Public Server Authentication CA EV R36. This is the concrete identity statement we wanted: a publicly trusted CA has independently verified this organizational identity in association with these DNS names.
What should be checked?
A first-time verifier should establish the canonical address independently, open our signing-key page, and inspect the browser's certificate information. The relevant values are the exact organization name, jurisdiction and registration number considered together - not simply a lock icon or the organization name alone. Checking the complete combination substantially raises the bar for impersonation: registering a similarly named company would not be enough, because its jurisdiction and registration number would also have to match the expected identity.
There is an important limit to the registration data. HRB 16592 is not globally unique because German commercial-register numbers are assigned by individual registry courts. Our certificate identifies Germany as the registration jurisdiction and North Rhine-Westphalia as the subject state, but it does not name Amtsgericht Paderborn and contains no locality-level jurisdiction field. We therefore do not describe the number as a globally unique company identifier.
After checking the website identity, compare the complete 40-hex-digit OpenPGP fingerprint and record it as the trust anchor. Do not pin the short-lived TLS certificate itself: its key, validity period and issuing chain can change during normal renewal while the verified organizational identity remains stable.
Normal verification and key rollover
The EV check does not need to become part of every automated release verification. After the initial enrollment, the normal path is deliberately simple:
trusted OpenPGP fingerprint -> verify signed checksums -> verify release archive
For a planned key rollover, the old trusted key can certify its successor and sign a transition statement containing both full fingerprints. Existing users can verify that continuity from the trust anchor they already hold. This is also the pattern described on the OpenSSL download page, where a retired release key cross-certified its successor.
External identity bootstrap is needed again if the old key may have been compromised, the continuity signature is unavailable, or an administrator deliberately wants an independent revalidation.
Other approaches solve broader or different problems
This method is not a replacement for a complete update-security architecture:
- Platform code-signing certificates integrate identity and trust into operating-system installation workflows, but they do not replace OpenPGP verification for every distribution format.
- The Update Framework embeds root metadata, roles, expiry and threshold signatures into an updater to address key compromise, rollback and repository attacks.
- QWACs, qualified electronic seals and vLEIs provide different regulatory or organizational identity statements, with different relying-party software and deployment requirements.
- OpenPGP key servers distribute keys, but distribution alone does not tell a first-time verifier why a particular key belongs to the intended organization.
Those approaches may be appropriate when the risk model calls for them. Our narrower goal is to authenticate one OpenPGP trust anchor using infrastructure already available to an administrator with a standard browser.
A useful property in a narrow role
EV is not a magic defense against phishing, and it does not make TLS cryptographically stronger. It does provide something DV intentionally does not: a CA-verified organizational identity associated with a domain.
For everyday browsing, that identity may be too hidden and too easy to ignore. For the rare, deliberate bootstrap of a software-signing key, the same property can be exactly what is needed.