Zusammenfassung

  • Die OpenPGP-Key-ID ist ein kollisionsfähiger 64-Bit-Suchhinweis; allein bestimmt sie weder ein eindeutiges Public-Key-Paket noch dessen menschlichen Inhaber.
  • Ein belastbarer Prüfbeleg hält Kandidaten, gewähltes Paket und vollständigen Fingerabdruck, Herkunft, Zertifizierungen, Lebenszyklus, kryptografisches Ergebnis und Berechtigung auseinander.

Ein Prüfdialog nimmt sechzehn hexadezimale Zeichen entgegen und zeigt genau einen Schlüssel. Für die Bedienperson wirkt das Ergebnis eindeutig. Tatsächlich kann die Software lediglich den ersten Treffer einer nicht angezeigten Kandidatenliste gewählt haben. Die Eindeutigkeit entstand im Dialogfenster, nicht im Protokoll.

Kurze Kennungen haben einen legitimen Zweck. Sie passen in Protokolle und helfen, eine Schlüsselsammlung einzugrenzen. Zur Fehlkonstruktion werden sie erst, wenn Datenmodelle daraus einen eindeutigen Objektschlüssel machen und anschließend Identität, Aktualität und Handlungsmacht ableiten.

Jon Callas gehört zur Standardisierungsgeschichte dieser Grenze. Sein IETF-Datensatz führt fünf RFCs auf, darunter RFC 2440 und RFC 4880. Eine zeitgebundene Biografie der ACLU beschreibt Tätigkeiten in Kryptografie, Softwareentwicklung und Design; sie belegt keine heutige Stelle. Die aktuelle RFC 9580, die RFC 4880 ersetzt, stammt von anderen Autoren.

Der Ausschnitt bleibt kleiner als der Schlüssel

RFC 4880 definiert die Key-ID als acht Oktette und warnt Implementierungen ausdrücklich davor, Eindeutigkeit anzunehmen. Bei einem RSA-Schlüssel der Version 3 sind es die unteren 64 Bit des Modulus, bei Version 4 die unteren 64 Bit des Fingerabdrucks.

Die heutige RFC 9580 behält Länge und Warnung bei. Version 4 verwendet weiterhin die unteren 64 Bit eines SHA-1-Fingerabdrucks; Version 6 nimmt die oberen 64 Bit eines SHA-256-Fingerabdrucks. Derselbe Feldname bezeichnet somit nicht einmal ohne Versionskontext dieselbe Ableitung.

Wer ein größeres Objekt auf 64 Bit abbildet, behält die Möglichkeit, dass verschiedene Pakete denselben Wert erhalten. Eine solche Kollision ist weder automatisch ein Angriff noch ein Bruch der Public-Key-Kryptografie. Sie ist zunächst ein Suchkonflikt. Gefährlich wird er, wenn eine API nur den ersten Treffer liefert, ein Cache allein nach Key-ID indiziert oder ein Import den bisherigen Kandidaten überschreibt.

Auch das Schlüsselmaterial selbst besitzt keinen versionsunabhängigen Kurznamen. Identisches mathematisches RSA-Material kann in Paketen der Versionen 3, 4 und 6 unterschiedliche Fingerabdrücke und Key-IDs erhalten. Ohne Paket und Version lässt sich später nicht feststellen, was wirklich geprüft wurde.

Ein Fingerabdruck braucht einen Übertragungsweg

Der vollständige Fingerabdruck ist ein wesentlich stärkerer Beleg für ein bestimmtes serialisiertes Public-Key-Paket. Die prüfende Stelle kann ihn lokal berechnen und maschinell mit einem erwarteten Wert vergleichen. Eine Kollision ist sehr viel unwahrscheinlicher als bei einem 64-Bit-Ausschnitt.

RFC 9580 hält jedoch den manuellen Vergleich langer Fingerabdrücke für fragwürdig. Die Konsequenz ist ein authentisierter, maschineller Transfer des Erwartungswerts – nicht die Rückkehr zur kürzeren Kennung. Deshalb gehört seine Herkunft in den Beleg: kontrollierte Konfiguration, signiertes Verzeichnis, unabhängig bestätigter Kanal oder veränderbare Webseite. Ein exakter Vergleich mit der falschen Referenz bleibt falsch.

Danach ist die Person noch nicht bewiesen. Ein User-ID-Paket enthält UTF-8-Text, gewöhnlich Name und E-Mail-Adresse, prüft dessen Wahrheit aber nicht. Zertifizierungssignaturen beschreiben die Bindung in unterschiedlicher Stärke. Generic macht keine Aussage zur Prüftiefe, Persona erklärt ausdrücklich keine Verifikation, Casual und Positive beanspruchen stärkere Kontrollen.

Ein erwarteter Name neben dem passenden Fingerabdruck ist daher kein Beschäftigungsnachweis und keine Vollmacht. Die vertrauende Stelle muss festlegen, welche Zertifizierer sie für welchen Zweck und Zeitraum akzeptiert.

Kryptografische Gültigkeit ist keine Amtsgewalt

Das Issuer-Key-ID-Subpacket einer Signatur bleibt ein acht Byte langer Hinweis. RFC 9580 verbietet seine Nutzung für Schlüssel nach Version 4 und empfiehlt den Issuer Fingerprint in allen Signaturen. Sind bei Version 4 beide vorhanden, muss die Key-ID zu den unteren 64 Bit des Fingerabdrucks passen. Diese Konsistenz hilft, ersetzt aber nicht die Auflösung des vollständigen Pakets.

Die kryptografische Prüfung beantwortet nur, ob diese Signatur mit diesem Schlüssel über genau diese Daten gültig ist. Ablauf, Widerruf, relevanter Zeitpunkt, zulässiger Algorithmus und Key Flags sind eigene Prüfungen. Technische Signierfähigkeit ist keine allgemeine Nutzungserlaubnis.

Organisatorische Autorisierung kommt aus einer weiteren Quelle. Eine korrekte Signatur unter einem Release-Manifest beweist weder die aktuelle Rolle des Schlüsselinhabers noch die Wahrheit des Manifests oder die Freigabe für Produktion. Schlüsselbesitz, zertifizierte Identität, gegenwärtige Funktion und konkrete Befugnis müssen gesondert zusammengeführt werden.

Den Entscheidungsweg konservieren

Ein nachvollziehbarer Beleg bewahrt zunächst die exakten signierten Daten und das Signaturpaket. Er nutzt die Issuer Key ID als Hinweis und zeichnet sämtliche Treffer jedes Repositoriums auf. Für den gewählten Kandidaten speichert er Public-Key-Paket, Version, lokal berechneten vollständigen Fingerabdruck sowie Abrufquelle und -zeit.

Anschließend folgen die betrachtete User ID, Zertifizierungskette oder Vertrauensregel, Ablauf und Widerruf zum maßgeblichen Zeitpunkt, Key Flags, Algorithmusrichtlinie und Prüfergebnis. Erst danach trifft eine getrennte Richtlinie die Handlungsentscheidung.

Bei zwei Kandidaten bleiben beide sichtbar. Ein schwacher Kanal für den Fingerabdruck wird nicht nachträglich stark genannt. Fehlen Identitäts- oder Berechtigungsnachweise, bleiben die Felder offen. So lässt sich eine abweichende Entscheidung erklären, statt sie mit demselben kurzen Wert erneut zu erzwingen.

Quellen