Summary

  • An OpenPGP Key ID is a 64-bit lookup hint that can collide; it does not by itself identify one unique public-key packet or its human owner.
  • A defensible verification receipt records every candidate, the chosen packet and full fingerprint, retrieval provenance, certifications, lifecycle state, cryptographic result and a separate authorization decision.

The deployment console asks for a signing key. An operator pastes sixteen hexadecimal characters, the key store returns one record, and the release proceeds. Nothing in that sequence looks ambiguous. Yet the certainty came from the interface, not from OpenPGP.

Eight octets are enough to be convenient in logs, signatures and search boxes. They are not enough to turn a lookup result into an identity. A store may contain more than one matching key. A different store may return another first result. Even the right key material leaves unanswered whether it belongs to the named person, remains valid, permits this operation or carries authority to approve the release.

Jon Callas helped specify the system in which that boundary matters. His IETF Datatracker record lists five RFCs, including RFC 2440 and RFC 4880. A dated ACLU biography describes a career spanning cryptography, software engineering and product design. These records establish relevant authorship and history; they are not a present-tense employment assertion. Nor should Callas be credited with the replacement specification: RFC 9580 has four different authors.

A compact handle is deliberately incomplete

RFC 4880 defines a Key ID as eight octets and tells implementations not to assume uniqueness. For a version 3 RSA key, the value comes from the low 64 bits of the modulus. For a version 4 key, it comes from the low-order 64 bits of the fingerprint. The same visible length therefore hides different derivation contexts.

The current RFC 9580 preserves both the size and the warning. Version 4 still uses the low 64 bits of its SHA-1 fingerprint; version 6 uses the high 64 bits of its SHA-256 fingerprint. A Key ID is a projection from a larger object. Once projected, distinct objects can land on the same value.

That does not mean the public-key cryptography has been broken. A collision in a short selector is an ambiguity in discovery. It becomes dangerous when software silently treats the selector as the proof: accepting the first response, overwriting another candidate, or storing only the Key ID after the underlying packet has disappeared.

Version belongs in the evidence too. Identical RSA mathematical material represented as version 3, 4 or 6 keys need not have the same fingerprint or Key ID. A record that says only “key 8A31…” cannot later show which packet format was verified.

The fingerprint resolves a packet, not a person

A full fingerprint is far stronger evidence for a particular serialized public-key packet. Collision is much less likely, and mechanical comparison can bind retrieval to an expected key with much greater precision. But the claim still has a boundary.

RFC 9580 warns that having humans read and compare long fingerprints is a dubious verification method. The practical answer is authenticated, mechanical transfer and comparison—not downgrading to the shorter Key ID. The receipt should therefore record how the expected fingerprint arrived: a controlled configuration, signed directory, independently authenticated channel, or some other explicit provenance.

After a fingerprint matches, identity remains a certification question. OpenPGP User ID packets contain text intended to identify a person or organization, often a name and email address. Anyone can write text into a packet. Certification signatures express the relationship between that text and a key, and their types do not all assert the same checking effort. A generic certification says nothing about how carefully identity was verified; a persona certification explicitly offers no verification; casual and positive certifications claim stronger checking.

A name-shaped string beside a matching key is therefore not a passport, employment record or delegation. The relying system must decide which certifiers it trusts, for what scope, and under what policy.

Verification is narrower than authority

Signature processing adds another layer. The Issuer Key ID subpacket is an eight-byte hint. RFC 9580 forbids its use for keys newer than version 4 and recommends the Issuer Fingerprint subpacket in signatures. Where both appear for a version 4 key, they must agree in the expected low 64 bits. This is useful consistency evidence, but it still does not eliminate the need to resolve and inspect the public-key packet.

Cryptographic verification then answers a precise question: does this signature verify under this resolved key for these exact signed bytes? It does not answer whether the key was revoked yesterday, whether it had expired at the relevant time, whether its algorithm is acceptable, or whether its key flags cover the attempted use. Those checks are independent inputs.

Authorization is independent again. A valid signature may show that a key signed a release manifest. It does not show that the key holder was the release manager, that the manifest described a truthful build, or that policy permitted deployment to production. Key possession, certified identity, current organizational role and action authority can align, but no one of them fills the others automatically.

Preserve the candidate set

A reliable verifier begins before the database chooses a winner. It preserves the exact signed object and signature packet, extracts the issuer selector as a hint, and records every candidate returned by each repository. For the selected candidate it retains the complete public-key packet, packet version and a locally computed full fingerprint. It notes retrieval source and time rather than treating “found online” as provenance.

Next come the decisions that lookup cannot make: which User ID was considered, which certification chain or trust rule bound it, whether the key or signature was expired or revoked at the relevant time, what key flags and algorithm policy allowed, and whether cryptographic verification succeeded. Only after those fields are complete should a separate policy engine decide whether the signer was authorized for the requested act.

If two candidates share the selector, both remain in the receipt. If the expected fingerprint arrived through an unauthenticated channel, that weakness remains visible. If identity or authority was not established, the field stays empty. The system gains reliability not by pretending ambiguity vanished, but by retaining exactly where it did not.

Sources