66. pepsi-keys

Den Ende-zu-Ende-Schlüsselspeicher verwalten.

66.1. Rolle

pepsi-keys ist das Werkzeug des Operators für den Schlüsselspeicher der Ende-zu-Ende-Kryptographie von Pepsi: pepsi.crypto_identity (die Schlüsselpaare der von uns bedienten Adressen, private Hälfte eingeschlossen und im Ruhezustand verpackt), pepsi.peer_key (die zwischengespeicherten öffentlichen Schlüssel und Zertifikate entfernter Korrespondenten) und pepsi.ca_trust (die CA-Zertifikate, gegen die eingehende S/MIME-Ketten validiert werden). Es verbindet sich über den gemeinsamen [pepsi-postgres]-Abschnitt und liest die CRYPTO_*-Optionen von [pepsi] sowie den [pepsi-crypto]-Abschnitt. Es ist keine Stage. Referenz: pepsi-keys(1); der Entwurf ist in Schlüsselverwaltung erläutert.

Es ist eines der eigenständigen Binärprogramme außerhalb der vereinheitlichten ausführbaren Datei pepsi, aus zwei Gründen: Es ist das einzige Programm, das Schlüsselmaterial erzeugt (es einzufalten würde Schlüsselerzeugung und Zertifikatsausstellung in jeden Stage-Worker linken), und ein Standort kann es setuid installieren, damit Benutzer ihre eigenen Identitäten verwalten können — ein Bit, das ein gemeinsames Multi-Call-Binärprogramm nicht tragen kann.

66.2. Funktionen

  • identity list / show — welches Material für eine Adresse existiert: Protokoll, Zweck, Status, ob es das primäre für seine Fähigkeit ist, ob es veröffentlicht ist, ob die private Hälfte vorhanden, getilgt oder nie gehalten worden ist (client für den eigenen MUA-Schlüssel des Benutzers, dessen private Hälfte in seinem Mail-Client liegt), und — bei show — die Verwahrung, ob es das öffentliche Gesicht der Adresse ist, und sein Zustand auf dem Schlüsselserver.

  • identity generate — Schlüsselmaterial erzeugen und speichern. OpenPGP erzeugt einen übertragbaren Schlüssel (standardmäßig Ed25519, RSA optional); S/MIME erzeugt ein Signier- und ein Verschlüsselungszertifikat, jedes selbstsigniert zur sofortigen Nutzung, oder unter CRYPTO_SMIME_SHARED_KEY ein Zertifikat mit beiden Schlüsselverwendungen. --csr gibt zusätzlich je Schlüssel eine PKCS#10-Anforderung aus, sodass eine echte CA einen Ersatz ausstellen kann, ohne neu zu schlüsseln.

  • identity import / export / csr — anderswo erzeugtes Material ablegen (ein ohne --private importierter öffentlicher OpenPGP-Schlüssel wird als eigener MUA-Schlüssel des Benutzers registriert), Material in seiner eigenen Binärform wieder ausgeben (--pem für X.509) oder eine Zertifikatsanforderung über den vorhandenen Schlüssel einer Identität bauen.

  • identity revoke / retire / forget-private — der Lebenszyklus. Der Widerruf und der periodische retire-Lauf zerstören privates Signier-Material und behalten Entschlüsselungsmaterial; revoke --upload veröffentlicht zuvor ein Widerrufszertifikat auf dem Schlüsselserver, denn das muss geschehen, solange der Signierschlüssel noch existiert. forget-private ist der ausdrückliche, bestätigte Weg (-y überspringt die Rückfrage), einen Entschlüsselungsschlüssel zu zerstören.

  • identity set-primary / publish / unpublish / delete — das für neue Nachrichten verwendete Material wählen, eine Adresse in die Veröffentlichung ein- oder ausschließen (publish kann sie auch auf einen Schlüsselserver hochladen) oder einen Datensatz rundweg entfernen.

  • peer list / show / import / pin / unpin / refresh / prune / remove — die zwischengespeicherten Peer-Schlüssel. refresh validiert bereits vorhandene Schlüssel erneut und entdeckt niemals einen für eine Adresse, die keinen hat; prune löscht abgelaufene Schlüssel und veraltete Entdeckungsanfragen (--dry-run, um zuerst nachzusehen). show wendet die Abgleichsregel an (eine exakte Adresse schlägt immer einen von Hand eingetragenen *@domain-Rückfall); import legt einen Schlüssel mit der Quelle manual ab, der einzigen Quelle, die eine ganze Domain benennen darf.

  • ca list / add / enable / disable / remove — die S/MIME-Vertrauensanker. Ein Zertifikat ohne basicConstraints CA:TRUE wird abgelehnt, da keine Kette je bei ihm enden könnte. Hier angenommen zu werden heißt nicht, brauchbar zu sein: Die eigenen nameConstraints, pathLenConstraint und Richtlinienbeschränkungen eines Ankers binden jede Kette, die durch ihn führt (RFC 5937), und eine CA mit einer kritischen Erweiterung, die Pepsi nicht verarbeiten kann, wird beim Pfadaufbau übersprungen (RFC 5280 §4.2).

  • wrap rotate — jeden gespeicherten privaten Schlüssel unter einem neuen Schlüsselverschlüsselungsschlüssel neu verpacken, inkrementell und mit --dry-run, um zuerst nachzusehen.

  • dns — die OPENPGPKEY- (RFC 7929) und SMIMEA-Einträge (RFC 8162) ausgeben, die eine Adresse veröffentlichen, unter den gehashten Eigentümernamen, die diese Standards definieren. Nur in einer DNSSEC-signierten Zone veröffentlichenswert, was die Ausgabe auch sagt.

66.3. Privilegienmodell

Einen privaten Schlüssel zu erreichen erfordert zwei unabhängig bewachte Dinge: die Datenbankrolle pepsi-crypto — die einzige, der die Spalte crypto_identity.private_wrapped gewährt ist, während jede andere Dienstrolle eine spaltenweise Berechtigung hält, die sie auslässt — und den Schlüsselverschlüsselungsschlüssel, der nur in secrets.d/pepsi-crypto.secret liegt. Eine gestohlene Datenbank liefert Chiffrat; das Geheimnis allein liefert nichts.

pepsi-keys nimmt diese Rolle nur für die Dauer jedes Datenbankaufrufs an: als root gestartet wird es zum Konto (root hat keine eigene Datenbankrolle) und kehrt danach zurück. Die Peer-Authentifizierung von PostgreSQL richtet sich nach der effektiven uid, nicht nach der gid, sodass ein setgid-Bit die Gruppe gewähren würde, die das Geheimnisfragment bewacht, aber nicht die Datenbankidentität.

Das Binärprogramm wird ohne setuid-Bit ausgeliefert, anders als pepsi-whitelist: Ein Programm, das jeden privaten Schlüssel einer Installation öffnen kann, ist eine weit größere Beute als eine einzelne Tabelle mit einer weißen Liste. Ein Standort, der will, dass Benutzer ihre eigenen Identitäten verwalten, installiert es setuid pepsi-crypto; Identitäten gehören dem passwd-Login, auf das ihre Adresse auflöst, und ein unprivilegierter Aufrufer des setuid-Binärprogramms darf nur die eigenen sehen und ändern. Ohne das Bit verbindet sich jeder Aufrufer als er selbst, und allein die Datenbankrechte entscheiden, sodass es setuid zu machen eine Standortentscheidung ist und keine Codeänderung. Peer-Schlüssel und Vertrauensanker gelten installationsweit und sind nur dem Operator vorbehalten, das Auflisten eingeschlossen.

66.4. Siehe auch

Schlüsselverwaltung, pepsi-setup, pepsi-whitelist, pepsi-settings, Architektur, pepsi-keys(1), pepsi.conf(5).