85.1.44. pepsi-keys¶

manage the end-to-end key store: identities, peer keys and anchors

Handbuchabschnitt:: 1

85.1.44.1.1. Name¶

pepsi-keys - Ende-zu-Ende-Schlüsselmaterial erzeugen, importieren, veröffentlichen und ausmustern.

85.1.44.1.2. Übersicht¶

pepsi-keys [GLOBAL-OPTIONS] identity list [–address ADDRESS] [–json]

pepsi-keys [GLOBAL-OPTIONS] identity show IDENTITY-ID [–json]

pepsi-keys [GLOBAL-OPTIONS] identity generate ADDRESS –protocol PROTOCOL [–name NAME] [–days N] [–no-publish] [–csr] [–shared | –split]

pepsi-keys [GLOBAL-OPTIONS] identity import ADDRESS –protocol PROTOCOL –purpose PURPOSE –public FILE [–private FILE] [–algorithm NAME] [–primary] [–no-publish]

pepsi-keys [GLOBAL-OPTIONS] identity export IDENTITY-ID [–private] [–pem]

pepsi-keys [GLOBAL-OPTIONS] identity csr IDENTITY-ID

pepsi-keys [GLOBAL-OPTIONS] identity revoke IDENTITY-ID [–reason TEXT] [–upload]

pepsi-keys [GLOBAL-OPTIONS] identity forget-private IDENTITY-ID [-y]

pepsi-keys [GLOBAL-OPTIONS] identity set-primary IDENTITY-ID

pepsi-keys [GLOBAL-OPTIONS] identity publish [IDENTITY-ID] [–wkd] [–vks] [–retry [–dry-run]] [-y]

pepsi-keys [GLOBAL-OPTIONS] identity unpublish IDENTITY-ID

pepsi-keys [GLOBAL-OPTIONS] identity delete IDENTITY-ID [-y]

pepsi-keys [GLOBAL-OPTIONS] identity retire

pepsi-keys [GLOBAL-OPTIONS] peer list [–address ADDRESS] [–json]

pepsi-keys [GLOBAL-OPTIONS] peer show ADDRESS [–protocol PROTOCOL] [–json]

pepsi-keys [GLOBAL-OPTIONS] peer unclaimed [–address ADDRESS] [–all-sources] [–json]

pepsi-keys [GLOBAL-OPTIONS] peer import ADDRESS –protocol PROTOCOL –file FILE [–pin]

pepsi-keys [GLOBAL-OPTIONS] peer pin | unpin | remove PEER-KEY-ID

pepsi-keys [GLOBAL-OPTIONS] peer refresh [–address ADDRESS | –expire PEER-KEY-ID] [–expiring-within-days DAYS] [–limit N]

pepsi-keys [GLOBAL-OPTIONS] peer prune [–retain-days DAYS] [–dry-run]

pepsi-keys [GLOBAL-OPTIONS] ca list [–json]

pepsi-keys [GLOBAL-OPTIONS] ca add FILE [–label TEXT]

pepsi-keys [GLOBAL-OPTIONS] ca enable | disable | remove CA-ID

pepsi-keys [GLOBAL-OPTIONS] identity –otp CODE COMMAND …

pepsi-keys [GLOBAL-OPTIONS] otp status [ADDRESS] [–json]

pepsi-keys [GLOBAL-OPTIONS] otp enroll | remove ADDRESS [–otp CODE]

pepsi-keys [GLOBAL-OPTIONS] otp reset ADDRESS

pepsi-keys [GLOBAL-OPTIONS] wrap rotate [–dry-run]

pepsi-keys [GLOBAL-OPTIONS] dns ADDRESS

85.1.44.1.3. Beschreibung¶

pepsi-keys ist das Werkzeug des Operators für Pepsis Ende-zu-Ende-Kryptographie-Schlüsselspeicher — die drei Tabellen, die jeden Schlüssel enthalten, den die OpenPGP- und S/MIME-Verarbeitung braucht:

pepsi.crypto_identity: Die Schlüsselpaare der Adressen, die wir bedienen, einschließlich der privaten Hälfte, im Ruhezustand verpackt (custody = local, ein MTA-Schlüssel). Sie werden verwendet, um ausgehende Mail zu signieren und eingehende Mail zu entschlüsseln. Hier liegen außerdem die eigenen Schlüssel der Benutzer, deren private Hälfte nur in ihrem Mail-Client existiert (custody = client, ein MUA-Schlüssel; siehe MTA keys and MUA keys).
pepsi.peer_key: Die öffentlichen Schlüssel und Zertifikate entfernter Korrespondenten, wie auch immer sie erlangt wurden, jeweils mit der Quelle, aus der sie stammen, einem Gültigkeitsurteil und einer Cache-Frist. Wird verwendet, um ausgehende Mail zu verschlüsseln und eingehende Signaturen zu verifizieren.
pepsi.ca_trust: Die CA-Zertifikate, die eine eingehende S/MIME-Kette erreichen muss, damit ihre Signatur als vertrauenswürdig gilt.

Das Werkzeug ist keine Stage. Es verwaltet Datensätze direkt, in der Gestalt von pepsi-whitelist(1) und pepsi-settings(1), verbindet sich über den geteilten [pepsi-postgres]-Abschnitt mit derselben Datenbank wie die übrigen Komponenten und liest die CRYPTO_*-Optionen von [pepsi] sowie den in pepsi.conf(5) beschriebenen [pepsi-crypto]-Abschnitt.

Es ist aus zwei Gründen ein eigenständiges Binärprogramm statt Teil der vereinheitlichten pepsi-Ausführungsdatei: Es ist das einzige Programm im Baum, das Schlüsselmaterial erzeugt, und ein Standort kann es setuid installieren (siehe Privilegien).

85.1.44.1.3.1. Fähigkeit, nicht Gestalt¶

Das Material einer Adresse wird als ein Datensatz je Fähigkeit gespeichert, nie als „die Identität“. Der purpose jedes Datensatzes ist sign, encrypt oder both:

eine OpenPGP-Identität ist ein einziger both-Datensatz — ein übertragbarer Schlüssel, dessen signierfähiger Hauptschlüssel einen Verschlüsselungs-Unterschlüssel trägt, sodass die Trennung intrinsisch ist und nichts kostet;
eine S/MIME-Identität besteht normalerweise aus zwei Datensätzen, einem Zertifikat mit digitalSignature und einem mit keyEncipherment/keyAgreement;
mit [pepsi] CRYPTO_SMIME_SHARED_KEY = yes ist es stattdessen ein both-Zertifikat, das beide Schlüsselverwendungen trägt (nur RSA).

Diese Option entscheidet nur, wie neu erzeugte Identitäten aussehen. Beide Gestalten werden dauerhaft unterstützt und können für eine Adresse nebeneinander bestehen — ein altes, noch gültiges gemeinsames Zertifikat neben einem frisch ausgestellten geteilten Paar —, sodass jede Abfrage auf eine Fähigkeit passt (sign oder both; encrypt oder both), statt Datensätze zu zählen. Auflistungen und identity show geben genau deshalb den purpose aus.

85.1.44.1.3.2. Die Ausmusterung ist asymmetrisch¶

Pepsi stellt Klartext in das Postfach zu, sodass ein privater Entschlüsselungsschlüssel nur für noch unterwegs befindliche Mail und für das von einem Operator archivierte Chiffrat gebraucht wird — nie, um das eigene Postfach zu lesen. Ein privater Signier-Schlüssel kann nach der Ausmusterung überhaupt nichts Legitimes mehr tun: Alte Mail wird nie neu signiert. Also gilt bei Ablauf oder Widerruf:

die private Hälfte eines sign-Datensatzes wird zerstört, und nur die öffentliche Hälfte bleibt erhalten, damit alte Signaturen weiterhin verifiziert werden können;
die private Hälfte eines encrypt-Datensatzes wird behalten;
ein both-Datensatz folgt der Entschlüsselungs-Regel — sie zu zerstören nähme die Fähigkeit, damit zu entschlüsseln —, was der Preis des Modus mit gemeinsamem Zertifikat ist: Einen kompromittierten Signierschlüssel dort zu widerrufen beendet zugleich die Fähigkeit, neue verschlüsselte Mail zu empfangen.

private_purged_at hält fest, wann Material verworfen wurde, sodass „bewusst zerstört“ von „nie besessen“ unterscheidbar bleibt; sowohl identity list als auch identity show melden es.

85.1.44.1.3.3. MTA-Schlüssel und MUA-Schlüssel¶

Eine Adresse kann Schlüssel zweier Arten halten. Ein MTA-Schlüssel (custody = local) ist einer, dessen private Hälfte Pepsi hält: pepsi-stage-encrypt(1) signiert damit, pepsi-stage-decrypt(1) öffnet damit Mail, und er wird in Autocrypt:-Headern beworben. Er wird durch identity generate, durch einen Import mit –private oder automatisch bei der ersten Einlieferung eines Benutzers unter [stage-encrypt] ENABLE_PEP erzeugt. Ein MUA-Schlüssel (custody = client) ist der eigene Schlüssel des Benutzers aus seinem Mail-Client: für immer rein öffentlich, nie primär. Pepsi verschlüsselt an ihn und reicht an ihn verschlüsselte Mail ungeöffnet durch, kann mit ihm aber nie signieren oder entschlüsseln. Er entsteht durch einen Import ohne –private, über die Web-Konsole oder die API, durch den E-Mail-Befehl register oder automatisch aus dem Autocrypt:-Header der vom Benutzer selbst eingelieferten Mail.

Das öffentliche Gesicht einer Adresse – das, was das Web Key Directory ausliefert und woran lokale Mail an den Benutzer verschlüsselt wird – ist der neueste aktive MUA-Schlüssel, wenn es einen gibt, sonst der primäre aktive MTA-Schlüssel. Der MTA-Schlüssel wird nicht stillgelegt, wenn ein MUA-Schlüssel hinzukommt; er entschlüsselt weiterhin Mail von Korrespondenten, die ihn noch verwenden. identity show gibt die Verwahrung (custody) aus und ob die Identität das öffentliche Gesicht ist.

85.1.44.1.3.4. Keyserver-Uploads werden je Identität angefordert¶

Jede Identität hält fest, ob ihr Upload zum Keyserver angefordert wurde (crypto_identity.vks_wanted). Automatisch erzeugte Schlüssel und automatisch registrierte MUA-Schlüssel beginnen mit ausgeschaltetem Wert: Autocrypt und das eigene Web Key Directory der Installation sind der Weg, auf dem sie gefunden werden, und ein Upload kann nicht zurückgenommen werden. Von Hand erstellte Schlüssel (identity generate, identity import sowie generate über Web und E-Mail) übernehmen [pepsi-keys] VKS_PUBLISH als Standardwert, und –no-publish lässt ihn ausgeschaltet. Eine ausdrückliche Anforderung – identity publish –vks, Upload to the key server in der Web-Konsole, der E-Mail-Befehl publish – setzt ihn, gleich was VKS_PUBLISH sagt. identity publish –retry lädt genau die Datensätze hoch, bei denen er gesetzt ist, sodass „nicht hochgeladen“ ein festgehaltener Zustand ist, und identity show meldet ihn.

85.1.44.1.3.5. Eigentum¶

Eine Identität ist auf die kleingeschriebene Adresse geschlüsselt. Wenn die Lokalitätsregeln von pepsi-common ([pepsi-crypto] LOCAL_DOMAINS, RECIPIENT_DELIMITER und TARGETS, mit Rückfall auf [pepsi-ingress] ACCEPTED_DOMAINS und den uid-Bereich aus /etc/login.defs) diese Adresse zu einem lokalen Konto auflösen, wird der passwd-Login in crypto_identity.login festgehalten; andernfalls ist die Spalte NULL — eine Rollenadresse, eine gehostete Domain, eine Installation vor einem Exchange.

Diese Spalte ist die Zugriffsregel. Ein unprivilegierter Aufrufer darf nur Identitäten sehen und ändern, deren login sein eigener ist, aufgelöst aus dem passwd-Eintrag der realen uid — nicht $USER, kein Argument, nicht die effektive uid. Eine Identität ohne besitzendes Konto gehört niemandem im Besonderen und ist daher nur für Operatoren: „ohne Eigentümer“ als „gehört allen“ zu behandeln würde jede Rollenadresse für jeden lokalen Benutzer beschreibbar machen.

root sowie die Konten pepsi-crypto, pepsi und pepsi-owner dürfen jede Identität verwalten. Peer-Schlüssel und Vertrauensanker haben keinen Namensraum je Benutzer — sie sind der Schlüssel eines anderen oder installationsweite Richtlinie —, sodass jeder peer- und ca-Unterbefehl, list eingeschlossen, nur für Operatoren ist, ebenso wie wrap rotate und identity retire.

85.1.44.1.3.6. Privilegien¶

Um an einen privaten Schlüssel zu gelangen, braucht es zweierlei, und beides wird getrennt bewacht:

die Datenbankrolle pepsi-crypto, die einzige, der die Spalte crypto_identity.private_wrapped gewährt ist (abgesehen vom Schema-Eigentümer pepsi-owner, der sie kraft Eigentümerschaft liest, aber den Schlüsselverschlüsselungsschlüssel nicht lesen kann). Jede gewöhnliche Dienstrolle — einschließlich des pepsi-Kontos, als das jeder gewöhnliche Stage-Worker läuft — hält eine Berechtigung auf Spaltenebene, die sie auslässt, sodass eine Kompromittierung anderswo in der Pipeline die öffentliche Hälfte jeder Identität liefert und sonst nichts (siehe pepsi-setup(1));
der Schlüsselverschlüsselungsschlüssel (KEK), der nur im Dateisystem lebt, in secrets.d/pepsi-crypto.secret.

Die Datenbank allein liefert daher nichts als Chiffrat, und der Schlüsselverschlüsselungsschlüssel allein liefert überhaupt nichts.

pepsi-keys nimmt die pepsi-crypto-Identität nur für die Dauer jedes Datenbankaufrufs an. Als root ausgeführt wird es für den Aufruf zu jenem Konto (root hat keine eigene Datenbankrolle) und kehrt danach zurück; als pepsi-crypto oder pepsi-owner ausgeführt verbindet es sich schlicht als es selbst; aus einer setuid-Installation heraus hebt es seine effektiven Ids auf den Eigentümer des Binärprogramms an. Die Peer-Authentifizierung von PostgreSQL richtet sich nach der effektiven uid, nicht nach der gid, sodass ein setgid-Bit die Gruppe gewährte, die das Geheimnis-Fragment bewacht, aber nicht die Datenbankidentität — ein Programm, das diese Rolle sein muss, muss dieses Konto sein.

So wie ausgeliefert trägt das Binärprogramm kein setuid-Bit (Modus 0755): Ein Binärprogramm, das jeden privaten Schlüssel einer Installation öffnen kann, ist eine weit größere Beute als die eine Tabelle von pepsi-whitelist(1), sodass standardmäßig nur der Operator es ausführt. Ein Standort, der möchte, dass gewöhnliche Benutzer ihre eigenen Identitäten verwalten, macht es setuid pepsi-crypto.

Welche Autorität gilt, unterscheidet sich zwischen den beiden Installationen. Die obige Eigentumsregel je Identität greift nur, wenn das Binärprogramm das setuid-Bit tatsächlich trägt: Ein Aufrufer gilt als privilegiert, wenn er root ist, wenn sein Login eines der privilegierten Konten ist, oder wenn das Binärprogramm überhaupt nicht setuid ist. Bei der ausgelieferten 0755-Installation ist daher jeder Aufrufer privilegiert, soweit es dieses Programm betrifft, und nur PostgreSQL steht zwischen einem Benutzer und den Identitäten eines anderen — der Aufrufer authentifiziert sich als er selbst, und die Datenbank-Berechtigungen entscheiden. Das ist der beabsichtigte Entwurf, aber es bedeutet, dass jemandem die Datenbankrolle pepsi-crypto zu gewähren ihm jede Identität der Installation übergibt, was auch immer die Eigentumsregel dieses Programms sonst gesagt hätte. Wenn es setuid ist, gelten dieselben drei Vorsichtsmaßnahmen wie bei pepsi-whitelist(1): Die effektiven Ids werden vor allem anderen auf den aufrufenden Benutzer abgesenkt, die Umgebungsvariablen, die die Konfigurationssuche (HOME, XDG_CONFIG_HOME), die ${DATADIR}-Expansion (PATH) und libpq (PG*) steuern, werden entfernt, und -c/–config wird für unprivilegierte Aufrufer abgelehnt — die Konfiguration benennt die Datenbank und den Schlüsselverschlüsselungsschlüssel.

85.1.44.1.4. Befehle¶

85.1.44.1.4.1. Identitätsbefehle¶

identity list [–address ADDRESS] [–json]

Listet Identitäten als Tabelle auf: Id, Adresse, Protokoll, Zweck, Status, ob der Datensatz der primäre für seine Fähigkeit ist, ob er veröffentlicht ist, der Zustand seiner privaten Hälfte (yes/no/purged oder client für den eigenen MUA-Schlüssel des Benutzers, dessen private Hälfte Pepsi nie gehalten hat) und sein Ablauf. Ein unprivilegierter Aufrufer sieht nur seine eigenen. –address beschränkt die Auflistung auf eine Adresse; –json gibt die Datensätze stattdessen als JSON aus.

identity show IDENTITY-ID [–json]

Gibt eine Identität vollständig aus, einschließlich ihres Fingerabdrucks, ihres Algorithmus, ihrer Verwahrung (local für einen MTA-Schlüssel, client für den eigenen MUA-Schlüssel des Benutzers), ob sie das öffentliche Gesicht der Adresse ist (der Schlüssel, den Korrespondenten erhalten), wrap_key_id, der Zeitstempel, eines etwaigen Widerrufsgrunds, des Web-Key-Directory-Hashes des lokalen Teils, unter dem die Adresse ausgeliefert wird, und ihres Keyserver-Zustands: einer von verified at ZEIT, uploaded at ZEIT , awaiting confirmation, upload requested oder not uploaded (not requested).

identity generate ADDRESS –protocol openpgp|smime [OPTIONS]

Erzeugt Schlüsselmaterial für ADDRESS und speichert es, private Hälfte verpackt. Das neue Material wird das primäre für seine Fähigkeit; nichts Bestehendes wird umgeschrieben oder ersetzt, sodass das vorherige Material brauchbar bleibt, um zu entschlüsseln, was bereits damit gesendet wurde.

OpenPGP erzeugt einen both-Datensatz unter Verwendung von [pepsi] CRYPTO_OPENPGP_ALGORITHM (ed25519, der Standardwert, oder rsa mit CRYPTO_GENERATE_RSA_BITS, das 2048, 3072 oder 4096 sein muss). S/MIME erzeugt das Signier-/Verschlüsselungspaar unter Verwendung von CRYPTO_SMIME_ALGORITHM (rsa, p256 oder p384), jeweils mit einem selbstsignierten Zertifikat für den sofortigen Gebrauch.

–name NAME: Anzeigename für die OpenPGP-User-ID (Name <address>) oder den Zertifikatsbetreff. Ohne ihn ist die User-ID die bloße Adresse.
–days N: Lebensdauer des erzeugten Materials. Standardwert ist [pepsi-crypto] IDENTITY_VALIDITY_DAYS (730, zwei Jahre).
–no-publish: Die öffentliche Hälfte nicht über das Web Key Directory ausliefern und nicht hochladen. Standardmäßig wird eine neue Identität veröffentlicht — an einen Schlüssel, den niemand abholen kann, kann nicht verschlüsselt werden —, und ihr Keyserver-Upload wird angefordert, wenn [pepsi-keys] VKS_PUBLISH eingeschaltet ist.

Die Erzeugung auf Anforderung ist immer erlaubt, auch für eine Adresse, die bereits den eigenen MUA-Schlüssel des Benutzers oder einen widerrufenen Schlüssel hat; nur die automatische Erzeugung verweigert eine Adresse mit irgendeiner Identität.

–csr: Gibt zusätzlich eine PKCS#10-Zertifikatsanforderung über jeden erzeugten Schlüssel aus, sodass eine echte CA ein Ersatzzertifikat für denselben Schlüssel ausstellen kann, ohne ihn neu zu erzeugen. Nur S/MIME; OpenPGP kennt kein solches Objekt.
–shared: Erzwingt ein einziges S/MIME-Zertifikat, das beide Schlüsselverwendungen trägt, was auch immer CRYPTO_SMIME_SHARED_KEY sagt. Mit einem Elliptische-Kurven-CRYPTO_SMIME_ALGORITHM abgelehnt: Ein EC-Schlüssel, der sowohl ECDSA als auch ECDH macht, ist algorithmusübergreifende Schlüsselwiederverwendung, die mehrere S/MIME-Clients ablehnen.
–split: Erzwingt die getrennten Signier- und Verschlüsselungszertifikate. Schließt –shared aus; ohne beide gilt der konfigurierte Standardwert.

identity import ADDRESS –protocol P –purpose PURPOSE –public FILE [OPTIONS]

Speichert anderswo erzeugtes Material. PURPOSE ist sign, encrypt oder both und muss beschreiben, was das Material tatsächlich kann — darauf passt jede spätere Abfrage. Die öffentliche Hälfte ist ein übertragbarer OpenPGP-Schlüssel oder ein X.509-Zertifikat (DER oder PEM, erkannt); - liest die Standardeingabe. Der Fingerabdruck wird aus dem Material selbst abgeleitet: der OpenPGP-Fingerabdruck oder der SHA-256 des Zertifikats-DER.

–private FILE: Die private Hälfte — ein OpenPGP-Transferable-Secret-Key oder ein PKCS#8-Schlüssel —, die vor dem Speichern verpackt wird, als MTA-Schlüssel (custody = local). Ohne sie wird nur die öffentliche Hälfte behalten. Bei OpenPGP wird der Datensatz dann als eigener MUA-Schlüssel des Benutzers erfasst (custody = client), der nie primär ist (–primary wird für ihn ignoriert): Pepsi kann ihn veröffentlichen und an ihn verschlüsseln, aber nie mit ihm signieren oder entschlüsseln. Er kommt der automatischen Schlüsselerzeugung für die Adresse zuvor und wird zum öffentlichen Gesicht der Adresse; an ihn verschlüsselte Mail wird ungeöffnet an den Mail-Client weitergereicht. Ein rein öffentlicher S/MIME-Import behält custody = local – typischerweise ein von einer CA ausgestelltes Zertifikat über einen Schlüssel, der bereits im Speicher liegt (siehe identity csr).
–algorithm NAME: Festzuhaltender Algorithmusname. Informativ; Standardwert imported.
–primary: Macht dies zu dem Material, das für neue Nachrichten seiner Fähigkeit verwendet wird.
–no-publish: Die öffentliche Hälfte nicht veröffentlichen. Andernfalls wird der Keyserver-Upload angefordert, wenn [pepsi-keys] VKS_PUBLISH eingeschaltet ist.

identity export IDENTITY-ID [–private] [–pem]

Schreibt das Material in seiner eigenen Binärform auf die Standardausgabe — OpenPGP-Pakete oder X.509-DER —, sodass es direkt in ein anderes Werkzeug geleitet werden kann.

–private: Exportiert die private Hälfte statt der öffentlichen und entpackt sie dafür zunächst. Scheitert, wenn der Datensatz keine hält, und nennt, welches von „nie besessen“ und „gelöscht“ zutrifft.
–pem: Verpackt X.509-Material in einen PEM-Block. OpenPGP-Material hat keine PEM-Form und wird mit einem Hinweis auf gpg --enarmor abgelehnt.

identity csr IDENTITY-ID

Gibt eine PKCS#10-Zertifikatsanforderung über den bestehenden privaten Schlüssel einer Identität aus, mit der Schlüsselverwendung, die ihr purpose impliziert. Das ist der Weg, auf den es ankommt, sobald eine Identität im Einsatz ist: Das selbstsignierte Zertifikat bringt die Organisation in Gang, und derselbe Schlüssel — bereits veröffentlicht, bereits zum Empfang verschlüsselter Mail verwendet — wird später einer echten CA vorgelegt, ohne ihn neu zu erzeugen. Nur S/MIME-Identitäten, und nur solange die private Hälfte noch gehalten wird.

identity revoke IDENTITY-ID [–reason TEXT] [–upload]

Zieht eine Identität zurück. Der Datensatz wird revoked und hört auf, primär zu sein; die öffentliche Hälfte bleibt erhalten, sodass vor dem Widerruf erstellte Signaturen weiterhin geprüft werden können. Die private Hälfte eines sign-Datensatzes wird hier und jetzt zerstört; ein encrypt- oder both-Datensatz behält seine private Hälfte, und der Befehl sagt das. TEXT wird mit dem Datensatz festgehalten.

–upload baut zusätzlich ein Widerrufszertifikat — signiert von dem Schlüssel, den es ausmustert, mit TEXT als Grund — und veröffentlicht es beim konfigurierten Keyserver. Das ist das einzige Mittel für einen bereits hochgeladenen Schlüssel: Einem Keyserver kann man sagen, dass ein Schlüssel widerrufen ist, nie, ihn zu vergessen.

Das Hochladen geschieht vor dem lokalen Widerruf, denn eine sign-Identität zu widerrufen zerstört den privaten Schlüssel, mit dem das Widerrufszertifikat signiert ist. Scheitert das Hochladen, wird nichts widerrufen, sodass das Keyserver-Problem behoben und der Befehl erneut ausgeführt werden kann. Ohne –upload zu widerrufen und dann einen veröffentlichten Widerruf zu wollen ist nicht wiederherstellbar.

identity forget-private IDENTITY-ID [-y, –yes]

Zerstört den privaten Schlüssel einer Identität dauerhaft und lässt die öffentliche Hälfte zurück. Das ist der einzige Weg, auf dem ein Entschlüsselungsschlüssel den Speicher verlässt, und er ist unumkehrbar: Alles, was noch in pepsi.workqueue eingereiht ist, alles in einem verschlüsselten Archiv und jede später aus einer Sicherung erneut zugestellte Nachricht wird unlesbar. Bereits zugestellte Mail ist nicht betroffen. Der Befehl gibt genau das aus und bittet um Bestätigung; –yes überspringt die Frage, und ohne Terminal und ohne –yes lautet die Antwort nein, sodass ein unbeaufsichtigter Lauf kein Schlüsselmaterial zerstören kann, bloß weil niemand da war, um zu widersprechen.

identity set-primary IDENTITY-ID

Macht dies zu dem Material, das für neue Nachrichten seines Tripels (Adresse, Protokoll, Zweck) verwendet wird. Nur eine active-Identität darf primär gemacht werden. Die vorherige primäre desselben Tripels wird zurückgestuft.

identity publish IDENTITY-ID [–wkd] [–vks] [-y, –yes]

Bedient die öffentliche Hälfte der Identität über das Web Key Directory. Das ist der umkehrbare Kanal — unser eigener Server, unsere eigene Domain — und ihn benennt –wkd; er ist zugleich der Standardwert, sodass das Flag nur existiert, um den Kanal ausdrücklich zu machen. Das Material bleibt so oder so brauchbar.

–vks hält zusätzlich die Upload-Anforderung fest (vks_wanted), lädt den Schlüssel zum konfigurierten Keyserver hoch und bittet ihn, den Bestätigungslink an die Adresse zu mailen. Weil die Anforderung vor dem Versuch festgehalten wird, wird ein fehlgeschlagener Upload von identity publish –retry erneut versucht statt vergessen. Das ist unumkehrbar: Einem Keyserver kann später gesagt werden, dass der Schlüssel widerrufen ist, aber nie, ihn zu vergessen, und die Adresse wird zu einem dauerhaften öffentlichen Eintrag. Der Befehl gibt genau aus, was nicht zurückgenommen werden kann, und bittet um Bestätigung; –yes überspringt die Frage, und ohne Terminal und ohne –yes lautet die Antwort nein. Nur OpenPGP — für S/MIME gibt es keinen Keyserver, dessen Veröffentlichungskanal ist der SMIMEA-Eintrag, den dns ausgibt.

identity publish –retry [–dry-run]

Arbeitet statt einer einzelnen jede veröffentlichte, aktive OpenPGP-Identität ab, deren Upload angefordert wurde (vks_wanted) und die auf dem Keyserver noch nicht bestätigt ist. Das ist die Form, die aus cron laufen sollte (stündlich genügt reichlich). Sie hängt nicht von [pepsi-keys] VKS_PUBLISH ab: Diese Option entscheidet nur, ob von Hand erstellte Schlüssel als angefordert beginnen, und die eigene Anforderung eines Benutzers wird befolgt, gleich was sie sagt. Ein automatisch erzeugter Schlüssel steht nie auf der Liste, es sei denn, sein Eigentümer hat darum gebeten.

Sie existiert, weil die Veröffentlichung ein zweistufiges Protokoll ist: Ein Hochladen liefert ein Token, nur das Token autorisiert die Bestätigungsmail, und nur ein gefolgter Link bewegt den Server dazu, den Schlüssel nach Adresse auszuliefern. Ein hochgeladener, aber nie bestätigter Schlüssel ist gespeichert und dennoch unauffindbar. Jede Runde fragt zuerst den Keyserver, ob die Adresse bereits ausgeliefert wird — sodass eine Bestätigung durch pepsi-stage-vks-confirm(1), durch einen Menschen oder in einem früheren Lauf, dessen Datenbankschreibvorgang nicht ankam, allesamt die Schleife beenden — und lädt andernfalls hoch und fordert die Verifikation an. Identitäten werden um VKS_RETRY_INTERVAL gestreckt, höchstens VKS_BATCH je Lauf, und nach VKS_MAX_ATTEMPTS aufgegeben, wobei der Grund für identity show auf dem Datensatz zurückbleibt. –dry-run listet auf, was veröffentlicht würde, und ändert nichts. Nur für Operatoren.

identity unpublish IDENTITY-ID

Hört auf, die Identität über das Web Key Directory zu bedienen, und vergisst ihre Keyserver-Buchführung, sodass der Wiederholungsjob sie in Ruhe lässt und eine spätere Neuveröffentlichung von einem sauberen Blatt beginnt.

Es entfernt nichts von einem Keyserver, denn nichts kann das. Wenn die Identität hochgeladen worden war, sagt der Befehl das und verweist auf identity revoke –upload, was der einzige Weg ist, der Welt mitzuteilen, dass der Schlüssel tot ist.

identity delete IDENTITY-ID [-y, –yes]

Entfernt den Datensatz vollständig, öffentliche Hälfte inbegriffen. Bestätigt wie forget-private. Bevorzugen Sie revoke, das die öffentliche Hälfte behält, sodass alte Signaturen prüfbar bleiben; eine gelöschte Identität hinterlässt überhaupt nichts.

identity retire

Führt den Ausmusterungsdurchlauf über jede Identität aus: Alles jenseits seines expires_at wird expired, privates Signier-Material wird zerstört und mit einem Stempel versehen, und Entschlüsselungsmaterial (einschließlich dem eines gemeinsamen both-Datensatzes) bleibt unangetastet. Ebenso für einen periodischen Timer gedacht wie für die Kommandozeile; identity revoke wendet dieselbe Regel inline für eine Identität an. Nur für Operatoren.

85.1.44.1.4.2. Peer-Befehle¶

peer list [–address ADDRESS] [–json]

Listet zwischengespeicherte Peer-Schlüssel auf: Id, Adresse, Protokoll, Quelle, Gültigkeit, ob die erzeugende Abfrage DNSSEC-validiert war, ob er gepinnt ist, und den Fingerabdruck.

peer show ADDRESS [–protocol PROTOCOL] [–json]

Zeigt die Schlüssel, die für ADDRESS tatsächlich verwendet würden, nach der Passungsregel: Eine exakte Adressübereinstimmung gewinnt immer, und ein *@domain-Datensatz wird nur herangezogen, wenn es keine exakte gibt (er wird in der Ausgabe als domainweiter Rückfall gekennzeichnet). PROTOCOL ist standardmäßig openpgp.

peer unclaimed [–address ADDRESS] [–all-sources] [–json]

Listet die Adressen auf, die diese Installation bedient, die keine Identität von uns besitzen, wohl aber einen geernteten oder per Gossip erhaltenen Peer-Schlüssel — die Schlüssel, die ein Fremder einschleusen kann, indem er uns eine Nachricht mit gefälschtem From: schickt. Schlüssel werden aus dem From:-Header geerntet, den der Absender schreibt, und die eingehende Authentifizierung ist fail-open, sodass ein solcher Datensatz auf einer Installation, die DMARC für ihre eigene Domain nicht durchsetzt, einen unserer eigenen Benutzer nennen kann. Wo wir eine Identität besitzen, ist der Datensatz wirkungslos (unser eigener Schlüssel hat Vorrang); wo nicht, entscheidet er, womit Mail an diesen Benutzer verschlüsselt wird. Das ist gewollt — es ist auch der einzige Weg, auf dem ein Benutzer, der GnuPG in seinem eigenen Client betreibt, hier seinen echten Schlüssel bekommt —, dies ist also eine Arbeitsliste, kein Alarm: Bestätigen Sie jeden Schlüssel mit seinem Inhaber und importieren Sie ihn dann als Identität (identity import ohne –private), wonach er wirkungslos ist, oder entfernen Sie ihn (peer remove).

Bedient heißt, die Domain ist eine von [pepsi-ingress] ACCEPTED_DOMAINS oder [pepsi-crypto] LOCAL_DOMAINS; ein passwd-Konto ist nicht erforderlich. Keine Identität heißt keine aktive Identität, die verschlüsseln kann — dieselbe Regel, die der Vorrang in der Verschlüsselungs-Stage anwendet —, sodass eine Adresse, deren einzige Identität abgelaufen ist, widerrufen wurde oder nur signieren kann, aufgelistet wird; die Spalte IDS zählt ihre Identitäten in jedem Zustand. Geerntet ist die Quelle inbound (der eigene Autocrypt:-Header des Absenders oder ein angehängter Schlüssel) oder gossip (das Autocrypt-Gossip: eines Dritten); –all-sources schließt auch entdeckte, manuelle und per API gesetzte Schlüssel ein, also die Menge, die GET /api/v1/peers/unclaimed meldet. Ein *@domain-Datensatz wird nie aufgelistet. Nur lesend und nur für den Operator. Der Exit-Status ist 0, ob etwas gefunden wurde oder nicht; mit –json ist ein leerer Bericht [], worauf eine periodische Prüfung testen sollte.

peer import ADDRESS –protocol P –file FILE [–pin]

Speichert den Schlüssel eines Korrespondenten von Hand (- liest die Standardeingabe). Der Datensatz wird mit der Quelle manual festgehalten, die jeden Entdeckungsmechanismus überragt, und ist die einzige Quelle, die eine *@domain-Adresse tragen darf — eine Datenbank-Einschränkung, keine Konvention, sodass keine Entdeckungsantwort für eine Adresse je auf eine ganze Domain verallgemeinert werden kann.

Ein Schlüssel, der mit einem bereits gespeicherten kollidiert, ersetzt ihn nur, wenn er alles Dortige überragt; ein gepinnter Datensatz wird nie verdrängt, und der Befehl sagt, welches von gespeichert, aufgefrischt, ersetzt und behalten geschah. (Die einzige Ausnahme von „nur wenn er überragt“ ist die Neuestes-gewinnt-Regel der Autocrypt-Stufe, an der ein manual-Schlüssel in keiner Richtung beteiligt ist — siehe pepsi-keydisc(1).)

–pin: Pinnt den importierten Schlüssel, sodass die Entdeckung ihn nie ersetzt.

peer pin PEER-KEY-ID, peer unpin PEER-KEY-ID

Setzt oder löscht den Pin auf einem gespeicherten Schlüssel.

peer refresh [–address ADDRESS] [–expire PEER-KEY-ID] [–expiring-within-days DAYS] [–limit N]

Validiert zwischengespeicherte Peer-Schlüssel neu. Es frischt immer nur Schlüssel auf, die bereits existieren: Es entdeckt nie einen Schlüssel für eine Adresse, die keinen hat. Pepsi schlägt eine Adresse nach, wenn es Mail für sie hat, weshalb die Entdeckung von der Pipeline getrieben wird (pepsi-keydisc(1)) und nicht von diesem Befehl.

Drei Gestalten, ausgewählt durch die Flags:

–address ADDRESS: Führt die gesamte Entdeckungs-Auffächerung für eine Adresse in diesem Prozess aus — jede Methode in [pepsi-keydiscovery] SOURCES auf einmal, mit der Rang-Gnadenfrist-Abbruchregel — und speichert das Gefundene mit der richtigen Quelle und dem richtigen DNSSEC-Kennzeichen. Eine Zeile je Methode wird ausgegeben: das Protokoll und der Fingerabdruck (mit (dnssec) markiert für eine AD-validierte DANE-Antwort), no key oder der Fehler. Das erledigt außerdem die Entdeckungsanfrage der Adresse, sodass jede darauf geparkte Nachricht freigegeben wird. Eine durch ALLOW_DOMAINS/DENY_DOMAINS ausgeschlossene Adresse wird abgelehnt statt abgefragt.
–expire PEER-KEY-ID: Löscht die Cache-Frist eines Datensatzes, sodass die nächste Nachricht für diese Adresse neu abholt. Überhaupt keine Netz-E/A, und schließt –address aus.
(kein Flag): Durchlauf: Jeder fällige Schlüssel — sein refresh_after ist verstrichen, oder sein eigener Ablauf fällt in –expiring-within-days (Standardwert 7) — wird durch dieselbe Auffächerung geschickt, bis zu –limit Schlüsseln (Standardwert 100). Gepinnte und von Hand eingetragene (manual/api) Schlüssel werden übersprungen, und *@domain-Datensätze ebenfalls: Ein Operator hat sie dorthin gesetzt, und keine Entdeckungsantwort überragt das, sodass Abholen reine Kosten wären. Die Anzahl der neu validierten wird ausgegeben. Das ist der natürliche Inhalt eines periodischen Timers.

peer prune [–retain-days DAYS] [–dry-run]

Löscht abgelaufene Peer-Schlüssel und veraltete Entdeckungsanfragen — zwei Tabellen, eine Aufgabe. Ein Peer-Schlüssel, der vor mehr als DAYS (Standardwert 7) abgelaufen ist, wird entfernt, sofern er nicht gepinnt ist. Der Ablauf ist derjenige, den der Schlüssel selbst angibt — die aktuelle Selbstsignatur eines OpenPGP-Primärschlüssels, ein X.509-notAfter —, festgehalten, wann immer ein Schlüssel gelernt wird, ob durch Entdeckung, Ernten oder Gossip (ein von Hand importierter Schlüssel hält keinen fest, und ein Schlüssel, der keinen angibt, wird nie bereinigt); auf der pepsi.key_request-Seite haben sowohl ein erledigter Datensatz, dessen Negativeintrag über dasselbe Fenster hinaus gealtert ist, als auch ein ausstehender Datensatz, der so lange über seine Frist hinaus aufgegeben wurde, nichts mehr zu sagen und gehen ebenfalls. –dry-run meldet, wie viele Schlüssel einen Ablauf tragen und ungepinnt sind, und entfernt nichts.

peer remove PEER-KEY-ID

Löscht einen gespeicherten Schlüssel. So lässt ein Operator auch den neueren Autocrypt-Schlüssel eines Korrespondenten durch, den ACCEPT_ROTATION = expired zurückgehalten hat (ein key.peer.rotate.held-Audit-Datensatz; siehe pepsi-stage-autocrypt-learn(1)): Ist der alte Datensatz weg, speichert die nächste Nachricht mit dem neuen Schlüssel ihn als ersten Schlüssel.

85.1.44.1.4.3. Vertrauensanker-Befehle¶

ca list [–json]

Listet die Vertrauensanker mit ihrer Id, ob sie aktiviert sind, ihrem Etikett und ihrem Betreff auf.

ca add FILE [–label TEXT]

Fügt ein CA-Zertifikat (DER oder PEM; - liest die Standardeingabe) als Vertrauensanker hinzu. Ein Zertifikat ohne basicConstraints CA:TRUE wird abgelehnt: Keine Kette könnte je bei ihm enden. Idempotent bezüglich des SHA-256 des Zertifikats — denselben Anker zweimal hinzuzufügen aktualisiert nur das Etikett.

Ein Anker wird hier allein aufgrund seiner basicConstraints angenommen, doch der Pfadaufbau wendet seine Einschränkungen wie die jeder anderen CA an (RFC 5937): Ein namensbeschränkter Anker bürgt nur für Namen innerhalb seiner nameConstraints, unter einer CA, die pathlen:0 angegeben hat, wird keine Sub-CA angenommen, und ein requireExplicitPolicy oder inhibitAnyPolicy, das er trägt, wird beachtet. Eine Kette, die eine davon verletzt, schlägt mit policy-rejected fehl. Ebenso eine über eine CA, die eine kritische Erweiterung trägt, die Pepsi überhaupt nicht verarbeiten kann (RFC 5280 §4.2) — eine solche CA wird nie als Aussteller verwendet.

ca enable CA-ID, ca disable CA-ID

Übergibt einen Anker an den Verifizierer oder hört damit auf, während der Datensatz fürs Protokoll erhalten bleibt.

ca remove CA-ID

Löscht einen Anker.

Pepsi liefert bewusst keine Standard-Ankermenge aus. Eine Signatur, die sich zu einer CA kettet, die niemand gewählt hat, wird als nicht vertrauenswürdig statt als schlecht gemeldet, sodass ein leerer Speicher auf „wir können dafür nicht bürgen“ abfällt — und ein Operator, der einen Anker hinzufügt, trifft eine Entscheidung, statt eine zu erben.

85.1.44.1.4.4. Befehle für den zweiten Faktor¶

Eine Adresse kann einen zweiten Faktor haben: ein TOTP-Geheimnis (RFC 6238, SHA-1, sechs Ziffern, 30-Sekunden-Schritte), das ihr Inhaber in einer Authenticator-App aufbewahrt. Sobald er existiert, muss ein unprivilegierter Aufrufer (eine setuid-Installation) für jede Änderung an den Identitäten dieser Adresse einen aktuellen Code vorlegen – identity generate, import, revoke, forget-private, set-primary, publish, unpublish, delete – sowie für identity export --private und identity csr, und zwar als Option –otp CODE der identity-Gruppe (pepsi-keys identity --otp 123456 revoke 7). Die Inhaberschaft wird vor dem Code geprüft, sodass ein Benutzer keine Fehlschläge gegen die Registrierung eines anderen Benutzers anrechnen lassen kann. Der Operator (root, pepsi-crypto, eine Installation ohne setuid) wird nie gefragt. Derselbe zweite Faktor schützt die Schlüsselbefehle per E-Mail und die Web-Konsole; siehe pepsi-stage-encrypt(1) und das Kapitel zur Schlüsselverwaltung im Handbuch.

Ein Code wird einmal angenommen (eine Wiederholung innerhalb seiner eigenen 30 Sekunden wird abgelehnt), ein Schritt Uhrenabweichung in jede Richtung wird toleriert, ein falscher oder wiederholter Code zählt als Fehlschlag und ein richtiger setzt den Zähler zurück, und zehn Fehlschläge in Folge sperren den zweiten Faktor, bis der Operator ihn zurücksetzt.

otp status [ADDRESS] [–json]: Zeigt die Registrierung einer Adresse: wann sie registriert und zuletzt verwendet wurde sowie die aufeinanderfolgenden Fehlschläge (oder LOCKED). Der Operator darf ADDRESS weglassen, um jede Registrierung aufzulisten. Zeigt nie ein Geheimnis.
otp enroll ADDRESS [–otp CODE]: Erzeugt ein neues Geheimnis für ADDRESS und gibt es einmal aus, als base32 und als otpauth://-URI (qrencode -t ansiutf8 macht daraus einen QR-Code zum Scannen). Ersetzt eine bestehende Registrierung und beginnt wieder bei null Fehlschlägen; der Inhaber braucht dafür einen aktuellen Code der alten, der Operator nicht – so übergibt der Operator einem ausgesperrten Benutzer ein neues Geheimnis.
otp remove ADDRESS [–otp CODE]: Entfernt den zweiten Faktor; der Inhaber braucht einen aktuellen Code.
otp reset ADDRESS: Nur für den Operator: Entfernt den zweiten Faktor unabhängig von seinem Zustand und entsperrt damit die Adresse. Ihr Inhaber registriert sich erneut (per E-Mail oder mit otp enroll).

Das Geheimnis wird wie ein privater Schlüssel unter dem Schlüsselverschlüsselungsschlüssel verpackt gespeichert, in einer Tabelle, die nur die Rolle pepsi-crypto lesen darf; wrap rotate verpackt es ebenfalls neu.

85.1.44.1.4.5. Befehle für den Schlüsselverschlüsselungsschlüssel (KEK)¶

wrap rotate [–dry-run]

Verpackt jeden gespeicherten privaten Schlüssel und jedes Geheimnis eines zweiten Faktors unter der aktuellen [pepsi-crypto] KEY_WRAP_KEY_ID neu. Die Rotation ist konstruktionsbedingt inkrementell, denn jeder Datensatz hält den Schlüssel fest, der ihn versiegelt hat: Konfigurieren Sie das neue Geheimnis als KEY_WRAP_SECRET und behalten Sie das alte daneben als KEY_WRAP_SECRET_<OLD-ID>, richten Sie KEY_WRAP_KEY_ID auf die neue Id und führen Sie dies aus. Zwischen der Konfigurationsänderung und dem Durchlauf arbeitet die Installation weiter — neues Material wird unter dem neuen Schlüssel versiegelt, altes Material öffnet sich weiterhin unter dem ausgemusterten — und erst danach darf das ausgemusterte Geheimnis entfernt werden.

Datensätze, deren Schlüsselverschlüsselungsschlüssel kein konfiguriertes Geheimnis hat, werden gemeldet und unangetastet gelassen, statt den Lauf scheitern zu lassen; ebenso Datensätze, die nebenläufig neu verpackt wurden (jede Aktualisierung ist auf die alte Schlüssel-Id abgesichert, sodass eine neuere Verpackung nie überschrieben wird).

–dry-run: Listet auf, was neu verpackt würde, und ändert nichts.

85.1.44.1.4.6. DNS-Veröffentlichung¶

dns ADDRESS

Gibt im Zonendatei-Format die DNS-Einträge aus, die jede veröffentlichte, aktive Identität von ADDRESS veröffentlichen: einen OPENPGPKEY-Eintrag (RFC 7929) für OpenPGP-Material und einen SMIMEA-Eintrag (RFC 8162, in der TLSA-3 0 0-Form — von der Domain ausgestelltes Zertifikat, vollständiges Zertifikat, exakte Übereinstimmung) für S/MIME. Beide werden unter einem gehashten Eigentümernamen veröffentlicht, dem Hex der ersten 28 Oktette des SHA-256 des Local-Part, sodass die Zone die von ihr bedienten Adressen nicht aufzählt.

Veröffentlichen Sie diese nur in einer DNSSEC-signierten Zone, was die Ausgabe als Kommentar wiederholt: Ein unsignierter Schlüsseleintrag ist ein Schlüssel von wem auch immer für die Zone antworten kann, was keine Verbesserung gegenüber überhaupt keinem Schlüssel ist.

Der DNS-Eigentümernamen-Hash ist groß-/kleinschreibungsempfindlich (RFC 7929 §3), anders als der Web-Key-Directory-Hash desselben Local-Part, der kleinschreibt. Die beiden werden absichtlich von verschiedenen Funktionen berechnet.

pepsi-setup(1) gibt dieselben Einträge für jede veröffentlichte Identität als Teil seiner DNS-Ausgabe aus, gedeckelt auf eine lesbare Anzahl; dieser Befehl ist der Weg, in einer großen Installation an eine bestimmte Adresse zu kommen.

85.1.44.1.5. Keyserver-Konfiguration¶

Die Web-Key-Directory-Veröffentlichung braucht keine Konfiguration: Sie folgt dem published-Kennzeichen jeder Identität und wird von pepsi-httpd(1) bedient. Die Keyserver-Veröffentlichung schon, denn sie kann nicht rückgängig gemacht werden, und ihre Optionen leben in [pepsi-keys]:

VKS_PUBLISH (Standardwert no): Ob von Hand erstellte oder importierte Identitäten mit angefordertem Keyserver-Upload beginnen, sodass identity publish –retry sie hochlädt und es erneut versucht, bis die Adresse bestätigt ist. Ein Upload kann widerrufen, aber nie zurückgezogen werden, daher bleibt der Standardwert eine Entscheidung des Operators. Die Option steuert nicht den Wiederholungsjob und gilt nie für automatisch erzeugte oder registrierte Schlüssel; siehe Key-server uploads are requested per identity. Ist sie ausgeschaltet, bleibt identity publish –vks (oder die eigene Anforderung eines Benutzers über die Web-Konsole oder per E-Mail) verfügbar.
VKS_SERVER (Standardwert: der erste [pepsi-keydiscovery] VKS_SERVERS-Eintrag): Wohin Uploads gehen; nur https://. Ein Server, keine Liste: Denselben Schlüssel bei mehreren zu veröffentlichen vervielfacht eine unumkehrbare Handlung, und jeder muss dann mit Widerrufen aktuell gehalten werden.
VKS_MAX_ATTEMPTS (Standardwert 5), VKS_RETRY_INTERVAL (Standardwert 6 h), VKS_BATCH (Standardwert 50): Wie hartnäckig, wie oft und wie viele auf einmal identity publish –retry es versucht. Beachten Sie, dass Zeitdauern Kalendereinheiten ablehnen: 6 h parst, 1 d nicht.

85.1.44.1.6. Globale Optionen¶

Diese globalen Optionen stehen vor dem Unterbefehl (ein nachgestelltes Flag wird abgelehnt).

-c FILE, –config FILE: Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen. Für unprivilegierte Aufrufer abgelehnt, wenn dieses Programm setuid installiert ist: Die Konfiguration benennt die Datenbankverbindung, jeden ${…}-expandierten Pfad und den Schlüsselverschlüsselungsschlüssel selbst.
-L LOGLEVEL, –log LOGLEVEL: Setzt die Log-Ausführlichkeit. LOGLEVEL ist eines von error, warn, info, debug oder trace (Standardwert: info).
-v, –verbose: Zeigt Log-Meldungen aus allen Quellen, einschließlich Drittanbieter-Bibliotheken.
-h, –help: Gibt eine Verwendungsübersicht aus und beendet sich.
-V, –version: Gibt die Version aus und beendet sich.

85.1.44.1.7. Exit-Status¶

0: Erfolgreicher Abschluss. Ein zerstörerischer Befehl, der an seiner Bestätigungsabfrage abgelehnt wurde, endet ebenfalls mit 0, ohne etwas geändert zu haben.
1: Ein Fehler ist aufgetreten: eine fehlerhafte Konfigurationsdatei, eine unzulässige Optionskombination, eine Adresse, die zum Konto eines anderen Benutzers auflöst, nicht parsbares Schlüsselmaterial, ein Schlüsselverschlüsselungsschlüssel, der fehlt oder einen Datensatz nicht öffnet, oder eine gescheiterte Datenbankverbindung oder -abfrage. Der Grund wird in das Journal geschrieben.

85.1.44.1.8. Dateien¶

Wenn –config nicht angegeben ist, wird die erste vorhandene Datei aus der folgenden Liste verwendet:

$XDG_CONFIG_HOME/pepsi.conf
$HOME/.config/pepsi.conf
/etc/pepsi/pepsi.conf
/etc/pepsi.conf

secrets.d/pepsi-crypto.secret: Der Schlüsselverschlüsselungsschlüssel, neben der Konfigurationsdatei und mit einer @inline-secret@-Direktive in den [pepsi-crypto]-Abschnitt gezogen. Er wird aus der weltlesbaren Konfiguration herausgehalten, weil er das eine Geheimnis ist, das jeden gespeicherten privaten Schlüssel öffnet; pepsi-setup(1) gibt ihm bei jedem Lauf Modus 0640 und übergibt ihn dem pepsi-crypto-Konto. Sichern Sie ihn separat — siehe das Kapitel Schlüsselverwaltung des Handbuchs für die Kosten seines Verlusts.

Keine andere Datei wird gelesen oder geschrieben: Alles Schlüsselmaterial lebt in der Datenbank.

85.1.44.1.9. Beispiele¶

Die bedienten Adressen finden, deren Verschlüsselung von einem Schlüssel bestimmt wird, den jemand anderes geliefert hat, und einen bestätigten zum eigenen Schlüssel des Benutzers machen (ein MUA-Schlüssel: kein –private):

pepsi-keys -c /etc/pepsi/pepsi.conf peer unclaimed
pepsi-keys -c /etc/pepsi/pepsi.conf peer show bob@example.org
gpg --export bob@example.org > bob.pgp    # the key bob confirmed to you
pepsi-keys -c /etc/pepsi/pepsi.conf identity import bob@example.org \
    --protocol openpgp --purpose both --public bob.pgp

Eine OpenPGP-Identität erzeugen und prüfen, dass GnuPG die öffentliche Hälfte annimmt:

pepsi-keys -c /etc/pepsi/pepsi.conf identity generate alice@example.org \
    --protocol openpgp --name 'Alice Example'
pepsi-keys -c /etc/pepsi/pepsi.conf identity list --address alice@example.org
pepsi-keys -c /etc/pepsi/pepsi.conf identity export 1 | gpg --import

Das S/MIME-Paar erzeugen und über jeden Schlüssel eine Zertifikatsanforderung für eine echte CA ausgeben:

pepsi-keys -c /etc/pepsi/pepsi.conf identity generate alice@example.org \
    --protocol smime --csr

Das von jener CA ausgestellte Zertifikat über den bereits im Speicher liegenden Schlüssel installieren:

pepsi-keys -c /etc/pepsi/pepsi.conf identity import alice@example.org \
    --protocol smime --purpose sign --public /tmp/alice-sign.pem --primary

Die Adresse im DNS veröffentlichen (nur signierte Zone):

pepsi-keys -c /etc/pepsi/pepsi.conf dns alice@example.org >> example.org.zone

Einen kompromittierten Signierschlüssel zurückziehen und dann bestätigen, dass die private Hälfte weg ist:

pepsi-keys -c /etc/pepsi/pepsi.conf identity revoke 1 --reason 'laptop stolen'
pepsi-keys -c /etc/pepsi/pepsi.conf identity show 1

Dem Schlüssel eines Korrespondenten von Hand vertrauen und ihn gegen spätere Entdeckung pinnen:

pepsi-keys -c /etc/pepsi/pepsi.conf peer import bob@example.com \
    --protocol openpgp --file bob.pgp --pin

Einen Korrespondenten mit jeder aktivierten Methode nachschlagen und das Ergebnis speichern:

pepsi-keys -c /etc/pepsi/pepsi.conf peer refresh --address bob@example.com

Den Cache aus einem periodischen Timer ehrlich halten: neu validieren, was fällig ist, dann verwerfen, was veraltet ist:

pepsi-keys -c /etc/pepsi/pepsi.conf peer refresh
pepsi-keys -c /etc/pepsi/pepsi.conf peer prune

Einen S/MIME-Vertrauensanker hinzufügen und sehen, wem vertraut wird:

pepsi-keys -c /etc/pepsi/pepsi.conf ca add /etc/ssl/certs/our-ca.pem --label 'Our CA'
pepsi-keys -c /etc/pepsi/pepsi.conf ca list

Den Schlüsselverschlüsselungsschlüssel rotieren, zuerst nachsehend:

pepsi-keys -c /etc/pepsi/pepsi.conf wrap rotate --dry-run
pepsi-keys -c /etc/pepsi/pepsi.conf wrap rotate

Alles ausmustern, was seine Gültigkeit überschritten hat (aus einem periodischen Timer):

pepsi-keys -c /etc/pepsi/pepsi.conf identity retire

Einen Schlüssel beim Keyserver veröffentlichen und dann prüfen, dass er ankam:

pepsi-keys -c /etc/pepsi/pepsi.conf identity publish 1 --vks
pepsi-keys -c /etc/pepsi/pepsi.conf identity show 1

Jede ausstehende Keyserver-Verifikation zum Abschluss bringen (aus cron):

pepsi-keys -c /etc/pepsi/pepsi.conf identity publish --retry

Aufhören, einen Schlüssel zu veröffentlichen, und der Welt sagen, dass der hochgeladene tot ist:

pepsi-keys -c /etc/pepsi/pepsi.conf identity unpublish 1
pepsi-keys -c /etc/pepsi/pepsi.conf identity revoke 1 --upload \
    --reason 'address closed'

85.1.44.1.10. Siehe auch¶

pepsi-keydisc(1), pepsi-httpd(1), pepsi-stage-vks-confirm(1), pepsi-setup(1), pepsi-config(1), pepsi-whitelist(1), pepsi-settings(1), pepsi.conf(5), pepsi.state(7)

85.1.44.1.11. Fehler¶

Melden Sie Fehler an den Pepsi-Issue-Tracker.