11. Schlüsselverwaltung

Ende-zu-Ende-Kryptographie — OpenPGP und S/MIME — braucht einen Ort für Schlüssel. Pepsi bewahrt sie in der Datenbank auf, in drei Tabellen, die zusammen den Schlüsselspeicher bilden, und verwaltet sie mit einem Programm, pepsi-keys. Dieses Kapitel behandelt, was gespeichert wird, wie die private Hälfte geschützt ist, wer sie erreichen darf, und die zwei Entscheidungen, die am häufigsten überraschen: warum Signier- und Verschlüsselungsmaterial getrennt sind und warum eine Adresse, die nur Mail empfängt, am Ende überhaupt keinen Schlüssel hat.

Der Schlüsselspeicher ist nicht der DKIM/ARC-Schlüsselspeicher. Jene sind Schlüssel je Domain, als Dateien unter [pepsi] KEY_DIR gehalten und von den Signier-Stages gelesen; siehe Installation. Was folgt, betrifft Ende-zu-Ende-Material je Adresse, das einen völlig anderen Lebenszyklus hat.

11.1. Drei Arten von Material

pepsi.crypto_identity — unsere eigenen Adressen

Die Schlüsselpaare der Adressen, die diese Installation bedient, private Hälfte inbegriffen, im Ruhezustand verpackt. Dies signiert ausgehende Mail und entschlüsselt eingehende. Jeder Datensatz hält die Adresse fest, das Protokoll (openpgp oder smime), wozu das Material fähig ist, seinen Algorithmus und Fingerabdruck, das öffentliche Material selbst, das verpackte private Material und die ID des Schlüssels, der es verpackt hat, sowie die Lebenszyklusspalten (status, is_primary, published, expires_at, revoked_at, private_purged_at, vks_wanted). Sie enthält auch die eigenen Schlüssel der Benutzer — rein öffentliche Datensätze, deren private Hälfte in ihrem Mailclient liegt (custody = client; siehe Zwei Schlüssel je Benutzer).

pepsi.peer_key — die Adressen anderer Leute

Die öffentlichen Schlüssel und Zertifikate entfernter Korrespondenten, zwischengespeichert, wie auch immer sie erlangt wurden. Dies verschlüsselt ausgehende Mail und verifiziert eingehende Signaturen. Jeder Datensatz trägt die source, aus der er stammt, ob die erzeugende Abfrage DNSSEC-validiert war, das letzte über ihn erreichte Gültigkeitsurteil und eine Cache-Frist.

pepsi.ca_trust — Vertrauensanker

Die CA-Zertifikate, die eine eingehende S/MIME-Kette erreichen muss, damit ihre Signatur als vertrauenswürdig gilt. Pepsi liefert 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 statt auf „das ist gefälscht“, und ein Operator, der einen Anker hinzufügt, trifft eine Entscheidung, statt eine zu erben.

11.2. Verwahrung: wie ein privater Schlüssel gespeichert wird

Die private Hälfte einer Identität lebt in der Datenbank, aber nie im Klartext. Sie ist mit AES-256-GCM unter einem Schlüsselverschlüsselungsschlüssel (KEK) versiegelt, der aus einem Geheimnis abgeleitet ist, das nur im Dateisystem lebt, in einem secrets.d-Fragment, das [pepsi-crypto] KEY_WRAP_SECRET benennt.

Die damit erkaufte Eigenschaft:

Die Datenbank allein liefert nie einen privaten Schlüssel. Ein gestohlener Dump, ein Replikat, ein Sicherungsband oder ein SQL-Injection-Standbein in einer unbeteiligten Komponente erzeugt ein Chiffrat und sonst nichts. Der Schlüssel, der es öffnet, ist ein zweites, anders bewachtes Artefakt und ist nie ein Datenbankwert.

Der gespeicherte Blob besteht aus einem Versionsoktett, einer 96-Bit-Zufallsnonce und dem AES-GCM-Chiffrat. Das Versionsoktett existiert, damit eine künftige Konstruktion neben dieser bestehen kann; eine unbekannte Version ist ein Fehler, nie ein stiller Rückfall.

Die zusätzlichen authentifizierten Daten binden das Chiffrat an den Datensatz, zu dem es gehört — die Adresse, das Protokoll und den Zweck, längenpräfigiert. Ohne diese Bindung könnte ein Angreifer mit Schreibzugriff auf die Tabelle, aber ohne KEK, Alices verpackten Signierschlüssel in Bobs Datensatz verschieben und die Pipeline damit Bobs Mail signieren lassen. Die AAD werden authentifiziert, aber nicht gespeichert, sodass ein solcher Blob an der falschen Stelle schlicht nicht aufgeht, genau wie ein manipulierter.

Der KEK selbst wird aus dem konfigurierten Geheimnis mit HMAC-SHA-256 unter einem festen Etikett abgeleitet, wobei die Schlüssel-ID eingemischt wird. Zwei Folgen ergeben sich: Das Geheimnis darf eine beliebige Zeichenkette sein (eine Passphrase, base64, hex — der Ableitung ist es gleich), und jede verschiedene KEY_WRAP_KEY_ID ergibt einen unabhängigen 256-Bit-Schlüssel. Es gibt bewusst keine Start-Passphrase: Unbeaufsichtigter Neustart und Socket-Aktivierung müssen weiter funktionieren.

Warnung

pepsi-setup lehnt ein KEY_WRAP_SECRET ab, das kürzer als 16 Zeichen ist. Es ist der einzige Schlüssel, der jeden gespeicherten privaten Schlüssel der Installation öffnet; erzeugen Sie ihn aus einer echten Entropiequelle, statt einen zu tippen.

11.3. Die Privilegiengrenze

Das Verpacken ist die eine Hälfte des Verwahrungsmodells. Die andere Hälfte ist eine Datenbank-Privilegiengrenze, die pepsi-setup einrichtet und bei jedem pepsi-setup run erneut behauptet:

• eine Login-Rolle pepsi-crypto wird mit dem gewöhnlichen Pipeline-Zugriff angelegt (SELECT/INSERT/UPDATE/DELETE über das Schema, Sequenzen, Funktionen) plus der Spalte crypto_identity.private_wrapped — die einzige Rolle, der sie gewährt wird, abgesehen vom Schema-Eigentümer pepsi-owner, der sie kraft Eigentümerschaft lesen kann, den Schlüsselverschlüsselungsschlüssel aber nicht lesen kann, sodass nichts anderes beides besitzt;

• pepsi (dem Dispatcher und jedem Stage-Worker) und pepsi-httpd wird ihre Berechtigung auf Tabellenebene für crypto_identity entzogen und durch eine Berechtigung auf Spaltenebene ersetzt, die jede Spalte außer private_wrapped auflistet; pepsi-ingress und pepsi-telemetry haben überhaupt keinen Zugriff auf die Tabelle (siehe Die Privilegientrennung).

Eine Kompromittierung einer unbeteiligten Stage — Relay, Bounce, Aliase — liefert also die öffentliche Hälfte jeder Identität und sonst nichts, selbst mit vollem Datenbankzugriff unter dieser Rolle. Die Spaltenliste wird aus information_schema zurückgelesen statt fest verdrahtet, sodass eine durch eine spätere Änderung hinzugefügte Spalte automatisch abgedeckt ist und die Berechtigung gegenüber dem Schema nicht stillschweigend veralten kann.

DELETE hat in PostgreSQL keine Spaltengranularität und bleibt ganz: Eine Stage, die einen Identitätsdatensatz löschen kann, kann den Dienst verweigern, aber sie kann immer noch keinen Schlüssel lesen.

Wichtig

Die Peer-Authentifizierung von PostgreSQL richtet sich nach der effektiven uid, nicht nach der gid. Ein setgid-Bit gewährt Gruppenmitgliedschaft — was der Modus des KEK-Fragments prüft —, aber keine Datenbankidentität. Ein Programm, das die Rolle pepsi-crypto sein muss, muss dieses Konto sein: als es laufen oder setuid zu ihm werden. pepsi-keys tut genau das, nimmt die Identität für die Dauer jedes Datenbankaufrufs an und gibt sie danach zurück, in derselben Gestalt, die pepsi-whitelist für sein eigenes Konto verwendet.

Um an einen privaten Schlüssel zu gelangen, braucht es daher beides: die Datenbankrolle und den KEK. Keines allein genügt, und sie werden von verschiedenen Mechanismen bewacht — einer PostgreSQL-Berechtigung und einem Dateimodus.

11.3.1. Wer was verwalten darf

Eine Identität ist auf die kleingeschriebene Adresse geschlüsselt, und der passwd-Login, dem diese Adresse gehört, wird daneben festgehalten, wenn die Lokalitätsregeln ([pepsi-crypto] LOCAL_DOMAINS, RECIPIENT_DELIMITER, TARGETS, benannt und mit Standardwerten versehen wie die Optionen der lokalen Zustellung) einen auflösen. Sie sind die einzigen Optionen, die darüber entscheiden: pepsi-keys, der Setup-Applier sowie die automatische Erzeugung und Schlüsselregistrierung der Encrypt-Stage lesen alle [pepsi-crypto], sodass eine Identität denselben Eigentümer hat, gleich welcher von ihnen sie angelegt hat. Diese Spalte ist die Zugriffsregel: Ein unprivilegierter Aufrufer von pepsi-keys darf nur Identitäten sehen und ändern, deren Login sein eigener ist, entnommen dem passwd-Eintrag der realen uid. Eine Identität ohne besitzendes Konto — eine Rollenadresse, eine gehostete Domain, eine Installation vor einem Exchange — gehört niemandem im Besonderen und ist nur für Operatoren; „ohne Eigentümer“ als „gehört allen“ zu behandeln machte jede Rollenadresse für jeden lokalen Benutzer beschreibbar.

Peer-Schlüssel und Vertrauensanker haben überhaupt keinen Namensraum je Benutzer. Ein Peer-Schlüssel ist der Schlüssel eines anderen, für die ganze Installation zwischengespeichert, und der Vertrauensspeicher ist Richtlinie; beide sind nur für Operatoren, Auflistung inbegriffen.

pepsi-keys wird ohne setuid-Bit ausgeliefert, anders als pepsi-whitelist. Ein Binärprogramm, das jeden privaten Schlüssel einer Installation öffnen kann, ist eine weit größere Beute als eine einzelne Tabelle der weißen Liste, sodass es standardmäßig nur der Operator ausführt. Ein Standort, der möchte, dass Benutzer ihre eigenen Identitäten verwalten, installiert es setuid pepsi-crypto, und die obige Eigentumsregel greift, sobald das geschehen ist; das ist also eine Standortentscheidung und keine Codeänderung. (Ohne das Bit verbindet sich jeder Aufrufer als er selbst, und die Rechte von PostgreSQL sind die einzige Instanz; siehe pepsi-keys(1).)

11.4. Wogegen die Verwahrung schützt

Das Bedrohungsmodell formuliert die Zusicherungen je Verwahrungsmodus (Gateway-Verwahrung (custody = local, der MTA-Schlüssel), Client-Verwahrung (custody = client, der MUA-Schlüssel)); so bilden sie sich auf den Schlüsselspeicher ab.

Wer … hat	Ein MTA-Schlüssel (custody = local)	Ein MUA-Schlüssel (custody = client)
eine Kopie der Datenbank oder eine Sicherung	Nur verpacktes Chiffrat; der KEK ist nicht darin enthalten.	Einen öffentlichen Schlüssel; eine private Hälfte gibt es nirgends auf dem Server.
allein das secrets.d-Fragment mit dem KEK	Nichts: Die Blobs liegen in der Datenbank.	Nichts.
Codeausführung in einer gewöhnlichen Stage	Nicht den Schlüssel. Wohl aber seine Nutzung: Das Umschreiben des From: einer eingereihten Einlieferung lässt eine Nachricht als dieser Benutzer signieren (Eine kompromittierte Komponente).	Nichts, was sie signieren oder öffnen kann. Sie kann weiterhin Mail lesen, die im Klartext eingetroffen ist, bevor sie an den Benutzer verschlüsselt wurde.
Codeausführung in pepsi-stage-encrypt/-decrypt	Jeden MTA-Schlüssel, im Klartext, und die Möglichkeit, sie mitzunehmen. Rotieren Sie nach einer solchen Kompromittierung den KEK und erzeugen Sie neue Schlüssel.	Nichts: Mail, die an einen MUA-Schlüssel verschlüsselt ist, läuft ungeöffnet durch, und eine bereits abgelegte, an ihn neu versiegelte Kopie (pepsi-stage-reencrypt) lässt sich ebenfalls nicht öffnen.
Schreibzugriff auf crypto_identity ohne den KEK	Kann einen verpackten Schlüssel nicht zu einer anderen Adresse verschieben: Das Chiffrat ist an seinen Datensatz gebunden. Kann Datensätze löschen (Denial of Service).	Kann den öffentlichen Schlüssel ersetzen und künftige Mail an einen Schlüssel nach Wahl des Angreifers umlenken — dieselbe Macht, die ein böswilliger Operator hat. Geschützt ist nur ein Korrespondent, der den Fingerabdruck auf einem anderen Weg geprüft hat.

Zwei weitere Angriffe betreffen, welcher Schlüssel verwendet wird, statt wer ihn hält:

• Einem unserer Benutzer einen Schlüssel unterschieben. Ernten und Gossip lernen Schlüssel aus Mail, die jeder senden kann, sodass ein gefälschtes From: alice@our-domain einen Cache-Datensatz für Alice anlegen kann. Für jede Adresse, für die wir eine Identität halten, greift unser eigener Schlüssel dem gesamten Cache vor (Die Schlüssel unserer eigenen Benutzer werden nicht entdeckt), sodass der untergeschobene Schlüssel nie verwendet wird; für eine bediente Adresse ohne Identität gilt Vertrauen beim ersten Gebrauch, wogegen Die Benutzer finden, die ihren eigenen Schlüssel mitbringen das Gegenmittel ist.

• Den Schlüssel eines Korrespondenten austauschen. Nur so weit, wie die Vertrauensleiter es zulässt: Eine höher eingestufte Quelle gewinnt einen Konflikt immer, das Gossip eines Dritten kann niemals verdrängen, was der Eigentümer angekündigt hat, und MIN_TRUST entscheidet, wie weit die Leiter hinab noch verschlüsselt wird (Schlüssel von Korrespondenten).

11.5. Signieren und Verschlüsseln sind getrennt

Der Speicher trennt Signiermaterial von Verschlüsselungsmaterial, wo immer das Protokoll es erlaubt. Der Grund ist eine Asymmetrie:

Pepsi stellt Klartext in das Postfach zu. Ein privater Entschlüsselungsschlüssel wird daher nur für noch unterwegs befindliche Mail und für das von einem Operator archivierte Chiffrat gebraucht — nie, um das eigene Postfach zu lesen. Ein privater Signier-Schlüssel kann nach der Ausmusterung überhaupt nichts Legitimes mehr tun: Kein ehrlicher Prozess signiert je alte Mail neu. Ihn zu behalten ist reine Fälschungshaftung.

Die Ausmusterung — beim Ablauf und ebenso beim Widerruf — tut daher zwei verschiedene Dinge:

• die private Hälfte eines Signier-Datensatzes wird zerstört, wobei die öffentliche Hälfte bleibt, sodass Signaturen aus der Gültigkeitszeit des Schlüssels weiterhin verifiziert werden können;

• die private Hälfte eines Verschlüsselungs-Datensatzes wird behalten, sodass unterwegs befindliches und archiviertes Chiffrat lesbar bleibt.

private_purged_at hält fest, wann Material verworfen wurde, was „bewusst zerstört“ von „nie besessen“ unterscheidbar hält.

Bei OpenPGP ist die Trennung intrinsisch und kostenlos: Ein übertragbarer Schlüssel ist ein signierfähiger Hauptschlüssel mit einem Verschlüsselungs-Unterschlüssel, sodass ein Datensatz mit Zweck both ihn darstellt. Bei S/MIME bedeutet sie zwei Zertifikate, eines mit digitalSignature und eines mit keyEncipherment/keyAgreement. Sowohl der selbstsignierte als auch der Zertifikatsanforderungs-Weg behandelt das Paar natürlich — identity generate erzeugt beide, und --csr gibt eine Anforderung über jedes aus.

11.5.1. S/MIME mit einem einzigen Zertifikat, und was es kostet

Zwei Zertifikate je Identität sind ein echter Aufwand, wenn Zertifikate je Adresse bei einer CA gekauft werden. [pepsi] CRYPTO_SMIME_SHARED_KEY = yes stellt daher stattdessen ein Zertifikat aus, das beide Schlüsselverwendungen trägt. Es ist eine reine Administrator-INI-Option — ein Sicherheits-/Kostentausch, keine Vorliebe je Benutzer, und strukturell außer Reichweite der Überlagerungsschicht je Adresse.

Der Tausch:

• Der Vorteil bei der Fälschungshaftung wird aufgegeben. Die private Hälfte eines gemeinsamen Zertifikats folgt bei der Ausmusterung der Entschlüsselungs-Regel, denn sie zu zerstören nähme die Fähigkeit, damit zu entschlüsseln; sie verlässt den Speicher nur über ein ausdrückliches pepsi-keys identity forget-private;

• der Widerruf wird zum Alles-oder-nichts. Einen kompromittierten Signierschlüssel zu widerrufen beendet zugleich die Fähigkeit, an diesem Zertifikat neue verschlüsselte Mail zu empfangen.

Der gemeinsame Modus ist nur RSA. pepsi-setup lehnt ihn zusammen mit einem Elliptische-Kurven-CRYPTO_SMIME_ALGORITHM ab, statt stillschweigend ein Zertifikat zu erzeugen, das die halbe Welt nicht annehmen wird: Ein EC-Schlüssel, der sowohl ECDSA als auch ECDH macht, ist algorithmusübergreifende Schlüsselwiederverwendung, die mehrere S/MIME-Clients rundweg ablehnen.

11.5.2. Fähigkeit, nie Gestalt

CRYPTO_SMIME_SHARED_KEY entscheidet nur, wie neu erzeugte Identitäten aussehen. Es umzuschalten schreibt nie etwas bereits Ausgestelltes um, erzeugt keine Schlüssel neu und macht nichts ungültig, sodass die Tabelle jederzeit rechtmäßig geteilte Identitäten, gemeinsame Identitäten und beide für dieselbe Adresse enthalten darf — ein altes gemeinsames Zertifikat, das noch gültig ist, während neue geteilte im Einsatz sind.

Jede Abfrage löst daher nach Fähigkeit auf:

signing      ->  purpose IN ('sign',    'both')
encryption   ->  purpose IN ('encrypt', 'both')

und es gibt bewusst keine Abfrage, die „die Identität“ einer Adresse liefert. Code, der annähme, es gäbe genau zwei Datensätze oder genau einen, würde in dem Moment zum Fehler, in dem ein Operator den Schalter umlegt. Beim Lesen der Ausgabe von pepsi-keys identity list lesen Sie die Spalte PURPOSE genauso.

11.6. Identitäten erzeugen

Es gibt vier Wege, auf denen Material in crypto_identity gelangt.

Erzeugung. pepsi-keys identity generate erzeugt das Schlüsselpaar hier. OpenPGP verwendet standardmäßig Ed25519 ([pepsi] CRYPTO_OPENPGP_ALGORITHM), das augenblicklich erzeugt ist; RSA ist mit 2048, 3072 oder 4096 Bit verfügbar. S/MIME verwendet standardmäßig RSA mit CRYPTO_GENERATE_RSA_BITS und kann NIST P-256 oder P-384 nutzen. Jedes erzeugte Zertifikat ist selbstsigniert, was genügt, um sofort loszulegen, und --csr gibt zusätzlich eine PKCS#10-Anforderung über denselben Schlüssel aus, sodass eine echte CA ohne Neuerzeugung ein Ersatzzertifikat ausstellen kann.

Pepsi betreibt keine eigene Zertifizierungsstelle: Das hieße, einen Schlüssel zu halten, der weit wertvoller wäre als der irgendeines einzelnen Benutzers, mit einem eigenen Verwahrungs- und Widerrufsproblem.

Import. pepsi-keys identity import speichert anderswo erzeugtes Material — das Zertifikat, das eine CA über einen bestehenden Schlüssel ausgestellt hat, oder ein Schlüsselpaar, das ein Benutzer bereits hatte. Der deklarierte --purpose ist das, worauf jede spätere Abfrage passt, sodass er beschreiben muss, was das Material tatsächlich kann.

Automatische Erzeugung. [pepsi-crypto] AUTO_CREATE_IDENTITY (standardmäßig an) erlaubt, eine Identität für eine bediente Adresse zu erzeugen, ohne dass ein Operator darum bittet. Wann sie ausgelöst wird, bestimmt ENABLE_PEP der Encrypt-Stage:

• Eifrig, unter ENABLE_PEP = yes (Standard): bei der ersten lokal eingelieferten Nachricht eines Absenders, ob sie um Schutz bat oder nicht. Siehe Automatische Schlüssel nach Art von pEp unten, wo auch beschrieben ist, was das kostet.

• Faul, unter ENABLE_PEP = no: beim ersten Mal, dass ein lokaler Absender ausdrücklich um Schutz bittet — eine Markierung im Betreff oder der entsprechende Header aus einem Mailclient-Add-in, ob er nun um eine Signatur oder nur um Verschlüsselung bittet — und nie bloß, weil eine Adresse in einem Umschlag auftauchte. Ein Benutzer, der die Funktion nie nutzt, hat daher nie Schlüsselmaterial und wird dadurch nie exponiert. SIGN = always zählt bei jeder Nachricht als solche Bitte, sodass ein Absender darunter wie unter der Voreinstellung bei seiner ersten Einlieferung einen Schlüssel erhält.

So oder so geschieht die automatische Erzeugung nur für eine Adresse in einer Domain aus [pepsi-ingress] ACCEPTED_DOMAINS, die keinen Identitätsdatensatz irgendeiner Art hat — keinen widerrufenen und auch nicht den eigenen, aus dem Mailclient registrierten Schlüssel des Benutzers. Hat jemand einen Schlüssel widerrufen, prägt Pepsi nicht stillschweigend einen Ersatz; und ein Benutzer, der seinen eigenen Schlüssel mitgebracht hat, bekommt nicht hinter seinem Rücken einen zweiten. Die Erzeugung auf Anfrage (pepsi-keys identity generate, die Web-Konsole, der E-Mail-Befehl generate) ist nicht auf diese Weise geschützt. Automatisch erzeugte Datensätze werden als auto_created markiert.

Warnung

Die eine überraschende Folge. Der Auslöser liegt auf dem ausgehenden Pfad. Eine Adresse, die nur empfängt, bleibt daher schlüssellos, bekommt keinen Web-Key-Directory-Eintrag und veröffentlicht keinen DNS-Eintrag — sodass Außenstehende nichts haben, womit sie an sie verschlüsseln könnten, und nie etwas haben werden, wie lange sie auch warten.

Ein Operator, der eingehende Abdeckung will, muss diese Adressen vorab einrichten:

pepsi-keys identity generate role@example.org --protocol openpgp

Die Erzeugung für jede je gesehene Adresse prägte Schlüsselmaterial — und veröffentlichte es — für Leute, die nie etwas über diesen Server gesendet haben.

Registrierung des eigenen Schlüssels des Benutzers. Ein öffentlicher Schlüssel ohne private Hälfte — pepsi-keys identity import ohne --private, ein über die Web-Konsole oder per E-Mail registrierter Schlüssel oder einer, der aus dem Autocrypt:-Header der vom Benutzer selbst eingelieferten Mail gelernt wurde — wird als MUA-Schlüssel des Benutzers gespeichert; siehe Zwei Schlüssel je Benutzer.

11.7. Automatische Schlüssel nach Art von pEp

[stage-encrypt] ENABLE_PEP (Standard yes) lässt Pepsi sich wie das Projekt pretty Easy privacy (pEp) verhalten: Jeder lokale Absender erhält einen Schlüssel, Mail wird verschlüsselt, wann immer der Schlüssel eines Empfängers bekannt oder auffindbar ist, und der öffentliche Schlüssel des Absenders geht mit jeder Nachricht hinaus — standardmäßig in einem Autocrypt:-Header und mit ATTACH_KEYS_AS_FILES zusätzlich als angehängte Datei (siehe Microsoft Exchange als Gateway). Es ist eine Voreinstellung von Standardwerten für die Encrypt-Stage, kein erzwingender Modus; die vollständige Tabelle steht in pepsi-stage-encrypt(1). Was sie ändert:

• Eifrige Schlüsselerzeugung. Die erste lokal eingelieferte Nachricht einer Adresse in einer bedienten Domain erzeugt für sie einen OpenPGP-Schlüssel, auf jedem Einlieferungsweg einschließlich vertrauenswürdiger Relays (MYNETWORKS, Client-Zertifikate), sodass ein Pepsi, das als Proxy hinter einem MTA betrieben wird, der die Benutzer authentifiziert, genauso funktioniert. Der Domain-Test macht einen von uns geprägten Schlüssel erst nützlich: Mail für diese Domain kommt über uns herein, sodass die Decrypt-Stage an ihn verschlüsselte Antworten öffnen kann. Eine Webanwendung, die als noreply@ einer Domain sendet, für die wir keine Mail empfangen, bekommt keinen Schlüssel.

• Klartext wird nicht signiert. Der Standardwert von SIGN wird encrypted-only: Eine Signatur liegt innerhalb des Chiffrats, und Klartext trägt den Schlüssel, aber keine Signatur, sodass Empfänger, die keine Kryptographie verwenden, nie eine signature.asc sehen. [sign] oder X-Pepsi-Sign: yes signiert Klartext weiterhin.

• Kein Keyserver-Upload. Automatische Schlüssel werden von unserem eigenen Web Key Directory ausgeliefert und per Autocrypt beworben; sie werden nie auf einen Keyserver hochgeladen, es sei denn, ihr Eigentümer bittet darum (Keyserver-Uploads erfolgen auf Anfrage).

Sonst ändert sich nichts: Die Entdeckung hält die erste Nachricht an einen neuen Korrespondenten weiterhin bis zu ihrem Timeout zurück, die Nachrichten sind Standard-PGP/MIME und -Autocrypt, und es gibt kein pEp-Übertragungsformat (keinen X-pEp-Version-Header, keine pEp-2.x-Verpackung, keine Trustwords oder Handshakes, keine Schlüsselsynchronisation). Die Voreinstellung betrifft nur Mail, die Benutzer senden — Klartext geht unsigniert hinaus, und Absender bekommen Schlüssel, um die sie nicht gebeten haben; nichts daran, was irgendwer empfangen kann, hängt von ihr ab.

Warnung

Eifrige Erzeugung erweitert die Angriffsfläche, und sie ist der Standard. Bei fauler Erzeugung hat ein Benutzer, der nie Kryptographie verwendet, kein Schlüsselmaterial auf dem Server. Unter ENABLE_PEP hat nach seiner ersten Nachricht jeder Absender einer bedienten Domain einen verpackten privaten Schlüssel in der Datenbank und einen öffentlichen Schlüssel im Web Key Directory der Installation. Die Verpackung und die obige Privilegiengrenze gelten weiterhin, aber die Menge der Schlüssel, die eine Kompromittierung des Schlüsselverschlüsselungsschlüssels offenlegen würde, umfasst jeden, der Mail sendet, nicht nur diejenigen, die darum gebeten haben.

Die Vetos des Standorts sind [pepsi-crypto] AUTO_CREATE_IDENTITY = no (ein Abschnitt nur für Administratoren, sodass keine Einstellung je Benutzer sie überschreiben kann) und [stage-encrypt] ENABLE_PEP = no. Ein Benutzer steigt aus, indem er vor dem Senden seinen eigenen Schlüssel registriert (eine Adresse mit irgendeiner Identität bekommt nie eine automatische), oder indem er ENABLE_PEP = no in seinen eigenen pepsi.settings setzt, wo EDITABLE_STAGES des Operators das erlaubt (pepsi-stage-edit-settings). pepsi-setup warnt, wenn die Voreinstellung an, aber AUTO_CREATE_IDENTITY aus ist oder kein KEY_WRAP_SECRET konfiguriert ist, da die Voreinstellung dann stillschweigend weniger tut, als sie verspricht.

Der Setup-Assistent (und das Browser-Setup, das dieselbe Frage stellt) legt dies dem Operator ausdrücklich vor, benennt die Exposition, bevor er fragt, und schreibt die Antwort – yes ebenso wie no – in den Abschnitt der Encrypt-Stage in pepsi.conf, wo sie wirksam wird; keine config.d-Datei setzt sie.

11.8. Zwei Schlüssel je Benutzer

Eine Adresse kann zwei Arten von Schlüsseln besitzen:

MTA-Schlüssel (custody = local)

Pepsi hält die private Hälfte. Die Encrypt-Stage signiert damit, die Decrypt-Stage öffnet damit Mail, und er wird in Autocrypt:-Headern beworben. Automatisch oder auf Anfrage erzeugt oder mit seiner privaten Hälfte importiert.

MUA-Schlüssel (custody = client)

Der eigene Schlüssel des Benutzers, dessen private Hälfte nur in seinem Mailclient liegt. Der Datensatz bleibt für immer rein öffentlich und ist nie primär. Pepsi verschlüsselt an ihn und erkennt an ihn verschlüsselte Mail, kann mit ihm aber nie öffnen, signieren oder ihn bewerben.

Das öffentliche Gesicht einer Adresse ist der Schlüssel, den ein Korrespondent verwenden soll: der neueste aktive MUA-Schlüssel, wenn es einen gibt, sonst der primäre aktive MTA-Schlüssel. Das Web Key Directory, der Autocrypt:-Header, die Schlüsseldatei und die lokale Verschlüsselung lesen ihn alle über eine einzige Reihenfolge, sodass sie sich nicht widersprechen können:

• das Web Key Directory liefert nur den MUA-Schlüssel aus, sobald es einen gibt;

• Mail von einem lokalen Benutzer an einen anderen wird an ihn verschlüsselt;

• Pepsi fügt keinen Autocrypt:-Header hinzu und hängt keine Schlüsseldatei an, wenn es ein MUA-Schlüssel ist: Der Mailclient bewirbt seinen eigenen Schlüssel, und wenn Pepsi auf einigen Nachrichten des Benutzers einen anderen bewürbe, würde der Schlüsselzustand der Korrespondenten unter der Newest-wins-Regel von Autocrypt hin- und herspringen.

Der MTA-Schlüssel wird nicht stillgelegt, wenn ein MUA-Schlüssel auftaucht. Er entschlüsselt weiterhin Mail von Korrespondenten, die ihn noch verwenden, und er signiert weiterhin, innerhalb des Chiffrats, Klartext-Mail, die Pepsi im Auftrag des Benutzers verschlüsselt (ein Korrespondent, dem er fehlt, sieht eine nicht überprüfbare Signatur, was harmlos ist).

An einen MUA-Schlüssel verschlüsselte Mail wird ungeöffnet an den Mailclient weitergereicht, selbst wenn auch ein MTA-Schlüssel unter ihren Empfängern ist: Der Benutzer hat seinen eigenen Schlüssel registriert, um Ende-zu-Ende-Schutz zu erhalten, und eine Klartextkopie im Postfach würde das stillschweigend zunichtemachen. Es ist kein Entschlüsselungsfehler (ON_DECRYPT_FAILURE greift nicht), und sie läuft weiter die Pipeline hinab, sodass die Spam- und Whitelist-Stages weiterhin über ihr Schicksal entscheiden. Siehe pepsi-stage-decrypt(1). Mail, die stattdessen an den MTA-Schlüssel verschlüsselt eintraf, wird geöffnet, von diesen Stages gelesen und dann — mit pepsi-stage-reencrypt in der Pipeline — vor der Ablage an den MUA-Schlüssel versiegelt, sodass die Kopie im Postfach auf dieselbe Weise geschützt ist.

Bemerkung

Serverseitige Funktionen werden bei Ende-zu-Ende-Mail blind. Eine an einen MUA-Schlüssel durchgereichte Nachricht ist für jede spätere Stage Chiffrat: Die Spracherkennung kann sie nicht lesen, nichts wurde verifiziert, sodass state.signature_verified nie gesetzt wird, und ein Eintrag der weißen Liste mit signature_required passt nicht auf sie. Das ist die direkte Folge davon, sie nicht zu öffnen.

Ebenso bleibt eine Nachricht, die der Mailclient des Benutzers bereits verschlüsselt hat, auf dem Weg hinaus unangetastet — keine zweite Verschlüsselung, keine Signatur, kein Autocrypt:-Header und keine Schlüsseldatei von Pepsi —, und eine, die er bereits signiert hat, kann verschlüsselt werden, bekommt aber keine zweite Signatur.

11.8.1. Den eigenen Schlüssel des Benutzers registrieren

Ein MUA-Schlüssel gelangt auf einem dieser Wege herein:

• Automatisch, aus der eigenen Mail des Benutzers. Eine eingelieferte Nachricht, deren Autocrypt:-Header (addr= gleich dem From:) einen Schlüssel trägt, den die Adresse noch nicht hat, registriert ihn; für den allerersten Schlüssel der Adresse zählt auch eine angehängte application/pgp-keys-Datei, die die Adresse nennt. Das geschieht nur, wenn der Einliefernde im Namen der From:-Adresse sprechen darf: ein vertrauenswürdiges Relay (MYNETWORKS, ein Client-Zertifikat) oder ein authentifiziertes Konto, dessen From: zu einem konkreten, platzhalterfreien USERNAME_MAP-Eintrag oder dessen Standard login@HOSTNAME passte (state.origin.from_bound). Ein Konto, dem *@example.org gewährt wurde, darf als seine Kollegen senden, registriert aber nie einen Schlüssel für sie; pepsi-setup listet solche Konten auf.

• Durch den Benutzer, über die Web-Konsole oder per E-Mail (unten).

• Durch den Operator, mit pepsi-keys identity import ohne --private.

Ein Fingerabdruck, den die Adresse bereits hat, ob stillgelegt oder nicht, wird nie erneut registriert, sodass ein stillgelegter Schlüssel nicht zurückkehrt, weil ein altes Gerät ihn noch sendet. Ein Benutzer mit zwei Geräten, die jeweils einen Schlüssel halten, erhält zwei MUA-Schlüssel; der neueste ist das öffentliche Gesicht, und beide werden bei eingehender Mail erkannt.

Wenn ein Schlüssel automatisch für eine Adresse registriert wird, die bereits eine andere Identität hatte, wird dem Benutzer an der RESPONSE_STAGE der Encrypt-Stage eine Benachrichtigung gesendet („für Ihre Adresse wurde ein neuer Verschlüsselungsschlüssel registriert“, mit seinem Fingerabdruck und der Anleitung, wie man ihn stilllegt; Vorlage key-registered.<lang>.body).

Warnung

Ein gestohlenes Passwort kann einen Schlüssel registrieren. Jeder, der als ein Benutzer Mail einliefern kann, kann seinen eigenen Schlüssel zum öffentlichen Gesicht dieses Benutzers machen. Die Benachrichtigung ist die Abhilfe, und zwar eine teilweise: Ein Angreifer, der Mail einliefern kann, kann oft auch das Postfach über IMAP lesen und die Benachrichtigung ebenfalls löschen. Der Schaden ist begrenzt — an den untergeschobenen Schlüssel verschlüsselte Mail wird weiterhin nur in das Postfach des Opfers zugestellt, es geht also um die Fähigkeit, künftige Mail zu lesen, die der Angreifer ohnehin schon erreichen kann, plus Signaturen, die als die des Benutzers verifizieren — und die Abhilfe ist retire, auch per E-Mail verfügbar. Eine Installation ohne RESPONSE_STAGE sendet überhaupt keine Benachrichtigung; pepsi-setup warnt davor.

Ein Benutzer verschließt diesen Weg, indem er einen zweiten Faktor einrichtet (siehe unten): Von da an wird ein Schlüssel nur durch einen Befehl registriert, der einen aktuellen Code trägt, und der Autocrypt:-Header einer gewöhnlichen Nachricht registriert nichts.

11.8.2. Selbstbedienung auf drei Oberflächen

Ein Satz von Operationen — status, generate (ein vom Server verwalteter Schlüssel, auf Anfrage immer erlaubt), register (der eigene Schlüssel des Benutzers), publish (einen Keyserver-Upload anfordern) und retire — steht auf drei Oberflächen zur Verfügung, von denen jede einen Benutzer so auf seine eigene Adresse beschränkt, wie sie es ohnehin tut:

pepsi-keys

identity show, identity generate, identity import (ohne --private), identity publish --vks, identity revoke und otp für den zweiten Faktor. Siehe pepsi-keys(1); ein unprivilegierter Benutzer erreicht bei einer setuid-Installation nur seine eigenen Identitäten.

Die Web-Konsole und die API

Für einen Operator oder einen Principal mit own:<address>: Die Identitätenseite bietet Einen vom Server verwalteten Schlüssel erzeugen und Meinen eigenen Schlüssel registrieren (einen ASCII-armierten öffentlichen Schlüssel einfügen), und die Seite einer Identität Auf den Keyserver hochladen sowie Widerrufen. Die Web-Schicht handelt weiterhin nie selbst mit Schlüsselmaterial: Erzeugen, Registrieren und Widerrufen reihen generate-identity-/register-client-key-/revoke-identity-Aufgaben ein, die pepsi-setup apply erneut validiert und als Rolle pepsi-crypto ausführt — auch das Widerrufen, weil es die private Hälfte eines reinen Signierschlüssels vernichtet. Ein dort angeforderter Widerruf wird daher wirksam, wenn der Applier gelaufen ist, mit derselben Stilllegungsregel wie pepsi-keys identity revoke. Ohne das Paket pepsi-httpd-admin werden diese drei wie jeder andere Applier-Pfad schreibgeschützt. Siehe Die administrative API und Die Verwaltungskonsole.

E-Mail

Eine Nachricht des Benutzers an pepsi-keys@<their domain> ([stage-encrypt] KEYS_CONTROL_LOCAL_PART) mit dem Befehl im Subject: – status, generate, register (der Schlüssel wird dem Autocrypt:-Header oder dem Anhang dieser Nachricht entnommen), publish [FPR], retire FPR, otp enroll, otp remove – wird verbraucht statt weitergeleitet und mit der Liste der Schlüssel der Adresse beantwortet. Ist ein zweiter Faktor eingerichtet, trägt jeder Befehl außer status zusätzlich den aktuellen Code (Ein zweiter Faktor für Schlüsseländerungen). Dafür muss RESPONSE_STAGE gesetzt sein, und es funktioniert nur, wenn der Einliefernde für die From:-Adresse sprechen darf (wie oben). Es wird in der Encrypt-Stage selbst behandelt, die bereits als pepsi-crypto läuft; ein Stage-Worker darf niemals Arbeit für den Root-Applier einreihen können.

11.8.3. Ein zweiter Faktor für Schlüsseländerungen

Ein Benutzer kann alles oben Genannte mit einem zweiten Faktor schützen: einem TOTP-Geheimnis (RFC 6238 – sechs Ziffern, alle 30 Sekunden ein neuer Code, SHA-1, was jede Authenticator-App implementiert), das für seine Adresse eingerichtet wird. Sobald es existiert, braucht jede Änderung an den Schlüsseln der Adresse, die ein Benutzer vornehmen kann, den aktuellen Code der App:

• per E-Mail jeder Befehl außer status – der Code ist ein sechsstelliges Wort irgendwo im Subject:, z. B. register 123456 oder retire 89ABCDEF01234567 otp=123456. Der Autocrypt:-Header oder eine angehängte Schlüsseldatei einer Nachricht registriert für diese Adresse keinen Schlüssel mehr; register mit einem Code tut es;

• in der Web-Konsole oder der API nehmen Erzeugen, Registrieren und Widerrufen unter own:<address> den Code in einem Feld otp entgegen (die Formulare der Konsole haben eines), das der Setup-Applier prüft – pepsi-httpd selbst kann einen zweiten Faktor weder lesen noch prüfen;

• mit einem unprivilegierten pepsi-keys: pepsi-keys identity --otp CODE <command>.

Einrichten, Ersetzen und Entfernen sind eigene Befehle, und auch das Ersetzen oder Entfernen braucht einen Code:

otp enroll (E-Mail) / pepsi-keys otp enroll ADDRESS

Erzeugt ein frisches Geheimnis und antwortet einmalig damit: eine otpauth://-URI, das Geheimnis in Base32 zum Eintippen von Hand und (per E-Mail) ein QR-Code zum Scannen. Löschen Sie diese Antwort, sobald das Geheimnis in der App ist: Jeder, der sie lesen kann, kann die Codes erzeugen.

otp remove CODE / pepsi-keys otp remove ADDRESS --otp CODE

Entfernt ihn.

status zeigt, ob die Adresse einen hat und ob er gesperrt ist.

Falsche Codes und Wiederholungen. Ein Code wird einmal akzeptiert: Derselbe Code noch einmal wird, selbst innerhalb seiner 30 Sekunden, als Wiederholung (Replay) abgelehnt. Uhren dürfen um einen Schritt in jede Richtung abweichen. Ein falscher oder wiederholter Code zählt als Fehlversuch, ein richtiger setzt die Zählung zurück, und zehn Fehlversuche in Folge sperren den zweiten Faktor – jeder spätere Versuch wird abgelehnt, ohne geprüft zu werden. Ein Befehl, der gar keinen Code trägt, wird abgelehnt, ohne gezählt zu werden.

Der Operator kann einen Benutzer immer wieder hereinlassen: pepsi-keys otp reset ADDRESS (oder DELETE /api/v1/otp/{address} mit keys:write, das den Setup-Applier beauftragt) entfernt die Einrichtung unabhängig von ihrem Zustand, und pepsi-keys otp enroll ADDRESS, vom Operator ausgeführt, ersetzt sie ohne Code. Eine neue Einrichtung beginnt immer bei null Fehlversuchen. pepsi-keys otp status listet jede Einrichtung auf. Ein Operator wird nie nach einem Code gefragt: Er kann ihn ohnehin zurücksetzen.

Was er nicht abdeckt, benannt in Bedrohungsmodell: Die erste Einrichtung braucht keinen Code, sodass jemand, der zuerst an das Passwort gelangt, seinen eigenen einrichten kann (das Zurücksetzen durch den Operator ist dann das Gegenmittel); die Sperre kann von jedem ausgelöst werden, der als der Benutzer senden kann; und die Schalter der Web-Konsole für Veröffentlichung, Keyserver und primären Schlüssel, die pepsi-httpd direkt ausführt, sind nicht abgesichert. Das Geheimnis wird wie ein privater Schlüssel unter dem Schlüsselverschlüsselungsschlüssel des Schlüsselspeichers verpackt, die Tabelle ist nur für die Rolle pepsi-crypto lesbar, und pepsi-keys wrap rotate verpackt es zusammen mit den Schlüsseln neu.

Eine erzeugte oder importierte Identität ist standardmäßig veröffentlicht (--no-publish steigt aus, und identity unpublish löscht das Flag später). An einen Schlüssel, den niemand abholen kann, kann nicht verschlüsselt werden, sodass die Veröffentlichung der nützliche Standardwert ist; das Flag ist die Notausstiegsluke je Adresse.

11.9. Die Schlüssel unserer Benutzer veröffentlichen

Das Spiegelbild von „Den Schlüssel eines Korrespondenten finden“ weiter unten: wie andere Leute die Schlüssel unserer Benutzer finden. Es gibt drei Kanäle, und sie verhalten sich so verschieden, dass es ein Fehler wäre, sie als eine Einstellung zu behandeln.

Kanal	Wer ihn bedient	Umkehrbar?	Eingeschaltet durch
Web Key Directory	wir (pepsi-httpd)	ja, sofort	das published-Flag der Identität — standardmäßig an
Keyserver	ein Dritter	nein	das Flag vks_wanted der Identität, gesetzt durch eine ausdrückliche Anfrage oder, bei von Hand erstellten Schlüsseln, durch [pepsi-keys] VKS_PUBLISH — standardmäßig aus
DNS (OPENPGPKEY / SMIMEA)	wir (unsere Zone)	ja, beim nächsten Zonen-Push	den Eintrag von Hand veröffentlichen

Jede Identität ist standardmäßig published, wie auch immer sie erzeugt wurde. Der Ausstieg ist je Adresse, nicht je Identität, denn das ist die Einheit, über die ein Benutzer nachdenkt („bin ich auffindbar?“) — und weil ein Ausstieg je Identität einen nutzlosen Halbzustand erlaubte, in dem das Signierzertifikat veröffentlicht ist und das Verschlüsselungszertifikat nicht, sodass Korrespondenten prüfen, aber nicht verschlüsseln können.

11.9.1. Das Web Key Directory

pepsi-httpd beantwortet die vier Web-Key-Directory-Pfade für jede Domain in [pepsi-ingress] ACCEPTED_DOMAINS:

GET /.well-known/openpgpkey/hu/<hash>              direct   (on <domain>)
GET /.well-known/openpgpkey/policy                 direct
GET /.well-known/openpgpkey/<domain>/hu/<hash>     advanced (on openpgpkey.<domain>)
GET /.well-known/openpgpkey/<domain>/policy        advanced

Jede Identität trägt den WKD-Hash des Local-Parts ihrer Adresse (z-base-32 des SHA-1 des kleingeschriebenen Local-Parts), gespeichert und indiziert zusammen mit der Domain, sodass eine Anfrage mit einer Abfrage beantwortet wird und nicht dadurch, dass jeder in Frage kommende Datensatz gehasht wird. Der SHA-1 dort ist eine Benennungs-Funktion, die die Spezifikation festlegt, keine Sicherheitsfunktion, sodass er nicht von CRYPTO_ALLOW_WEAK_DIGESTS beschränkt wird.

Die Antwort ist der binäre übertragbare öffentliche Schlüssel — keine ASCII-Panzerung — mit Content-Type: application/octet-stream und Access-Control-Allow-Origin: *, was die Spezifikation verlangt, damit ein browserbasierter Client einen Schlüssel von einer anderen Domain als seinem eigenen Ursprung abholen kann. Die Richtliniendatei ist ein 200 der Länge null: Sie trägt keine Flags, muss aber existieren, denn GnuPG liest ihr Fehlen als „diese Domain betreibt kein Web Key Directory“ und gibt auf, bevor es nach einem Schlüssel fragt.

Der Parameter ?l=<local-part>, den ein Client senden darf, wird gelesen und weggeworfen. Ihn zu beachten machte den Endpunkt zu einer Abfrage nach einer vom Aufrufer gelieferten Adresse, was etwas viel Breiteres ist, als einen Hash zu beantworten, den der Aufrufer ohnehin schon kennen musste.

Der Betrieb kostet je bedienter Domain einen DNS-Eintrag und einen Zertifikatsnamen. Die advanced-Methode — die, die jeder aktuelle Client zuerst versucht — wird von openpgpkey.<domain> abgeholt, sodass dieser Name auf den pepsi-httpd-Host auflösen muss und das dort bediente Zertifikat ihn abdecken muss. Beides ist derselbe Listener: openpgpkey.<domain> und der Apex sind zwei SNI-Namen auf einem HTTPS-Listener, nicht zwei Listener. pepsi-setup run fügt openpgpkey.<domain> den Namen hinzu, um die es certbot bittet, und erinnert an jeden, der nicht auflöst; eine Domain, die bereits Schlüssel veröffentlicht, wird gekennzeichnet, denn für sie scheitert die advanced-Abfrage heute, statt bloß unkonfiguriert zu sein. Die direct-Methode auf dem Apex funktioniert ohne all das, sodass ein fehlender openpgpkey-Host eine Verschlechterung ist, kein Ausfall.

Wichtig

Der Endpunkt bedient nur unsere eigenen veröffentlichten Identitäten. Er liest crypto_identity, die Tabelle der Adressen, für die wir Schlüsselmaterial halten, und nie peer_key, den Cache der Korrespondentenschlüssel, den die Entdeckung gefüllt hat. Diese zu bedienen machte Pepsi zu einem Keyserver für Material, das es nie verifiziert hat und für das es nicht bürgt, veröffentlicht unter seinem eigenen Domainnamen. Es gibt keine Konfigurationsoption, die daran etwas ändert.

Bemerkung

Ein Web Key Directory beantwortet unbegrenzt viele Rateversuche, und Pepsi tut nicht so, als wäre es anders. Es gibt keinen Ratenbegrenzer am Endpunkt und keine Vereinheitlichung der 404er: Eine Anfrage nach einer Adresse, die einen Schlüssel veröffentlicht, bekommt den Schlüssel, und eine nach einer, die es nicht tut, bekommt ein 404, prompt und so oft, wie es jemandem beliebt zu fragen.

Das Protokoll ist konstruktionsbedingt ein öffentliches Orakel — sein ganzer Zweck ist, dass jeder fragen darf, ob eine Adresse einen Schlüssel veröffentlicht —, der Hash deckt nur den Local-Part ab, sodass er Rateversuche beantwortet, statt eine Liste aufzuzählen, und die Adressen stehen ohnehin außen auf jeder Nachricht, die die Domain sendet. Die 404er zu formen kostete einen Client die Fähigkeit, „kein Schlüssel“ von „Server kaputt“ zu unterscheiden, um ein Hindernis zu erkaufen, an dem eine Wortliste glatt vorbeiläuft. Wenn die Adressen geheim sein müssen, ist ein Schlüsselverzeichnis das Falsche zu betreiben.

11.9.2. Keyserver-Uploads erfolgen auf Anfrage

keys.openpgp.org und die Server, die sein Protokoll sprechen, nehmen einen Schlüssel dauerhaft an. Ihnen kann später gesagt werden, dass der Schlüssel widerrufen ist; ihnen kann nie gesagt werden, ihn zu vergessen, und der Adresse, für die er hochgeladen wurde, ebenso wenig.

Deshalb wird nichts hochgeladen, solange niemand darum gebeten hat, und deshalb wird die Anfrage festgehalten: Jede Identität trägt vks_wanted, und „nicht hochgeladen“ ist ein Zustand, angezeigt von pepsi-keys identity show, der Web-Konsole und der E-Mail-Antwort auf status, statt einer bloßen Abwesenheit.

• Automatisch erzeugte Schlüssel und automatisch registrierte MUA-Schlüssel beginnen mit ausgeschaltetem Flag. Autocrypt und unser eigenes Web Key Directory (das kein Upload ist) sind die Wege, auf denen sie gefunden werden.

• Von Hand erstellte Schlüssel — pepsi-keys identity generate/import, das generate über Web und E-Mail — nehmen [pepsi-keys] VKS_PUBLISH als Standard, einen Schalter auf Operatorebene, der standardmäßig aus ist: Wer versteht, dass ein Upload nicht zurückgezogen werden kann, ist der Operator, nicht wer auch immer zufällig einen Schlüssel erzeugt hat.

• Eine ausdrückliche Anfrage wird befolgt, gleich was VKS_PUBLISH sagt: pepsi-keys identity publish 42 --vks (das eine Bestätigung ausgibt, die genau benennt, was nicht zurückgenommen werden kann), Auf den Keyserver hochladen in der Web-Konsole, PATCH /api/v1/identities/{id} mit vks_wanted oder der E-Mail-Befehl publish.

Die Veröffentlichung ist ein zweistufiges Protokoll, und deshalb gibt es einen Wiederholungsjob. Das Hochladen liefert ein Token; nur das Token autorisiert die Bitte an den Server, einen Bestätigungslink an die Adresse zu mailen; und erst nachdem diesem Link gefolgt wurde, liefert der Server den Schlüssel nach Adresse aus. Ein Schlüssel, der hochgeladen, aber nie bestätigt wurde, ist gespeichert und dennoch unauffindbar — der Fehlschlag, der wie Erfolg aussieht. Also:

pepsi-keys identity publish --retry      # from cron, e.g. hourly

arbeitet jede veröffentlichte, aktive OpenPGP-Identität ab, deren Upload angefordert wurde und die noch nicht verifiziert ist — dies ist nicht durch VKS_PUBLISH geschaltet, sodass die Anfrage eines Benutzers beim nächsten Lauf des Jobs wirksam wird —, um VKS_RETRY_INTERVAL gestreckt und nach VKS_MAX_ATTEMPTS aufgegeben, wobei der Grund zum Nachlesen im Datensatz bleibt (pepsi-keys identity show). Jede Runde fragt den Keyserver, ob die Adresse bereits ausgeliefert wird, bevor sie erneut hochlädt, sodass eine Bestätigung durch irgendwen — die Stage unten, einen Menschen, der das Postfach liest, einen früheren Lauf, dessen Datenbankschreibvorgang nicht ankam — die Schleife beendet.

Der Bestätigungsmail selbst geht pepsi-stage-vks-confirm nach, eine kleine Stage auf dem eingehenden Pfad. Sie ist ein eigenes Programm, weil das, was sie tut — eine in eingehender Mail gefundene URL abrufen —, ein wirklich gefährliches Primitiv ist, und sie zu isolieren bedeutet, dass die Einschränkungen an einer kleinen Stelle liegen, deren Position in der Pipeline in der Konfiguration sichtbar ist. Die Seite jenes Programms listet sie auf; die Kurzfassung ist, dass die Mail vom konfigurierten Keyserver-Host kommen, per SPF oder DMARC authentifiziert sein, nur auf diesen Host verlinken und an jemanden gerichtet sein muss, für den wir tatsächlich auf eine Bestätigung warten. Alles andere wird dem Benutzer zugestellt, der den Link selbst anklicken kann. Ebenso eine Mail, deren Links abgerufen wurden, nach der der Keyserver unseren Schlüssel aber immer noch nicht ausliefert: Sie wird erst verworfen, wenn mindestens eine Identität nachweislich veröffentlicht ist.

11.9.3. Das Zurückziehen der Veröffentlichung, und was es nicht kann

pepsi-keys identity unpublish 42

hört sofort auf, die Identität über das Web Key Directory zu bedienen, und löscht ihre Keyserver-Buchführung, sodass der Wiederholungsjob sie vergisst.

Es entfernt nichts von einem Keyserver, denn nichts kann das. Wenn der Schlüssel hochgeladen wurde, sagt der Befehl das und verweist auf das einzige echte Mittel:

pepsi-keys identity revoke 42 --upload

das ein Widerrufszertifikat baut — signiert von dem Schlüssel, den es ausmustert — und es über den hochgeladenen Schlüssel veröffentlicht. Beachten Sie die Reihenfolge innerhalb dieses Befehls: Das Hochladen geschieht zuerst, denn eine Signieridentität zu widerrufen zerstört den privaten Schlüssel, den das Widerrufszertifikat braucht. Scheitert das Hochladen, wird nichts widerrufen, sodass Sie den Keyserver reparieren und es erneut versuchen können.

11.9.4. DNS: OPENPGPKEY und SMIMEA

pepsi-keys dns <address> gibt die DNS-Einträge aus, die die veröffentlichten, aktiven Identitäten einer Adresse veröffentlichen: OPENPGPKEY (RFC 7929) für OpenPGP-Material und SMIMEA (RFC 8162) für S/MIME-Zertifikate, beide unter einem gehashten Eigentümernamen, sodass die Zone die von ihr bedienten Adressen nicht aufzählt. pepsi-setup run gibt dieselben Einträge für jede veröffentlichte Identität aus, neben den DKIM-, SPF- und MTA-STS-Einträgen (gedeckelt auf eine lesbare Anzahl — für eine große Installation fragen Sie je Adresse).

S/MIME hat kein Web-Key-Directory-Äquivalent und keinen Keyserver, sodass SMIMEA sein Veröffentlichungskanal ist.

Warnung

Veröffentlichen Sie Schlüsseleinträge nur in einer DNSSEC-signierten Zone. Ein unsignierter OPENPGPKEY-Eintrag ist ein Schlüssel, den ausgibt, wer auch immer für die Zone antworten kann, was keine Verbesserung gegenüber überhaupt keinem Schlüssel ist — und anders als eine WKD-Antwort trägt eine DNS-Antwort keinerlei sonstige Evidenz. Beide Befehle wiederholen dies als Kommentar in ihrer eigenen Ausgabe.

Der DNS-Eigentümername und der WKD-Hash sind nicht austauschbar: Der DNS-Name ist SHA-256, auf 28 Oktette gekürzt und hexadezimal kodiert, über den groß-/kleinschreibungsempfindlichen Local-Part (RFC 7929 §3), während der WKD-Name z-base-32 des SHA-1 über den kleingeschriebenen Local-Part ist. Sie zu verwechseln erzeugt Einträge, die nie etwas abfragt, weshalb sie getrennte Funktionen mit einem Test sind, der ihre Verschiedenheit sicherstellt.

11.10. Den Schlüsselverschlüsselungsschlüssel sichern und rotieren

Gefahr

Wenn der KEK verloren geht, ist jeder gespeicherte private Schlüssel weg. Sichern Sie secrets.d/pepsi-crypto.secret getrennt von der Datenbank und behandeln Sie es mit der Sorgfalt, die sein Inhalt verdient.

Der Schlag wird von derselben Asymmetrie gemildert, die die Ausmusterung regelt: Postfächer enthalten Klartext, sodass der Verlust des KEK keineswegs irgendjemandes Mail unlesbar macht. Verloren ist jedes Chiffrat, das noch unterwegs oder archiviert ist — und, weit störender, jede veröffentlichte Identität ist auf einen Schlag ungültig. Korrespondenten halten weiterhin öffentliche Schlüssel, die die Installation nicht mehr verwenden kann, sodass die ganze Organisation neu schlüsseln und neu veröffentlichen muss. Planen Sie dafür als Katastrophenfall, nicht als Unannehmlichkeit.

Die Rotation ist dagegen Routine und konstruktionsbedingt inkrementell, denn jeder Datensatz hält die ID des Schlüssels fest, der ihn versiegelt hat:

1. legen Sie das neue Geheimnis als KEY_WRAP_SECRET in secrets.d/pepsi-crypto.secret und behalten Sie das alte daneben als KEY_WRAP_SECRET_<OLD-ID> (das Suffix ist die alte wrap_key_id, großgeschrieben);

2. richten Sie [pepsi-crypto] KEY_WRAP_KEY_ID auf die neue ID;

3. führen Sie pepsi-keys wrap rotate aus.

Zwischen den Schritten 2 und 3 arbeitet die Installation weiter: Neues Material wird unter dem neuen Schlüssel versiegelt, während altes Material weiterhin unter dem ausgemusterten aufgeht. Erst nachdem Schritt 3 gemeldet hat, dass alles rotiert ist, darf das ausgemusterte Geheimnis entfernt werden. Jedes Neuverpacken ist eine auf die alte ID abgesicherte Aktualisierung, sodass eine nebenläufige Rotation — oder ein während des Durchlaufs neu erzeugter Schlüssel — nie überschrieben wird; Datensätze, deren Schlüssel kein konfiguriertes Geheimnis hat, werden gemeldet und übersprungen, statt den Lauf scheitern zu lassen. --dry-run listet die Arbeit zuerst auf.

11.11. Peer-Schlüssel

Ein Peer-Schlüssel wird mit der Quelle zwischengespeichert, aus der er stammt, und die Quelle entscheidet, was geschieht, wenn ein neu entdeckter Schlüssel einem gespeicherten widerspricht. Die Reihenfolge dieser Quellen ist die Vertrauensleiter, die unten unter Den Schlüssel eines Korrespondenten finden tabelliert ist; sie lebt in einer Datenbankfunktion, sodass sie durch erneutes Ausführen der Prozedurdatei statt durch einen Schemapatch umgeordnet werden kann, und die Konfliktregel wird serverseitig angewandt, in derselben Anweisung, die den Schlüssel speichert, sodass kein Client sie überspringen kann.

Ein Schlüssel, der alles für eine Adresse Gespeicherte überragt, ersetzt es; bei gleichem oder niedrigerem Rang wird der gespeicherte Schlüssel behalten und der neue nicht eingefügt, sodass eine schwache Quelle nie stillschweigend eine besser bezeugte verdrängen kann. Ein gepinnter Datensatz wird nie verdrängt, welchen Rang auch immer — Pinnen ist die Art, wie ein Operator eine Vertrauensentscheidung beim ersten Gebrauch dauerhaft macht.

Zwischen diesen beiden Regeln sitzt eine Ausnahme, und sie ist auf die Autocrypt-Stufe (die Sprossen inbound und gossip) beschränkt: Wenn der eingehende Schlüssel aus dieser Stufe stammt, jeder gespeicherte Datensatz für die Adresse und das Protokoll ebenfalls aus dieser Stufe stammt, der eingehende Rang nicht schlechter als der gespeicherte ist und das Autocrypt-Wirksamkeitsdatum der Nachricht strikt neuer als das neueste beim besten Rang gespeicherte ist, dann wird der gespeicherte Schlüssel bei gleichem Rang ersetzt. Das ist die Peer-State-Aktualisierung „das jüngste gewinnt“ von Autocrypt Level 1: Ohne sie würde der zweite je für eine Adresse gesehene Autocrypt:-Schlüssel für immer abgelehnt, und ein Korrespondent, der seinen Client neu installiert oder seinen Schlüssel rotiert, erhielte weiterhin Mail, die an einen Schlüssel verschlüsselt ist, den er nicht lesen kann. Geprüft wird der Name der Quelle, nicht die Rangzahl, und der Term no worse than hält die Ausnahme nach beiden Seiten innerhalb der Stufe — Gossip verdrängt weiterhin nie, was der Eigentümer einer Adresse über sich selbst gesagt hat, und keines von beiden verdrängt je einen geernteten oder besser bezeugten Schlüssel.

Ein gegossipter Schlüssel, den sein Eigentümer bestätigt, wird befördert

Ein gegossipter Schlüssel bleibt nicht für immer auf der untersten Sprosse. Wenn der Eigentümer der Adresse später denselben Schlüssel selbst ankündigt — in seinem eigenen Autocrypt:-Header oder als angehängter Schlüssel, der ihn benennt —, wird der Datensatz auf die Sprosse inbound befördert (der Übergang von Gossip in den eigenen Zustand des Peers nach Autocrypt Level 1 §5.3). Der Schlüssel hat sich nicht geändert, also ist dies keine Rotation: kein key.peer.rotate-Datensatz und kein Hinweis an irgendjemanden, aber ein key.peer.promote-Datensatz (Schweregrad info) im Audit-Log, geschrieben von derselben Anweisung. Der Datensatz verteidigt sich danach auf dem Rang des Eigentümers, sodass ein späteres Gossip eines anderen Schlüssels ihm gegenüber abgelehnt wird, und MIN_TRUST = harvested lässt ihn nun zu. Sein Stichtag wird der eigene des Eigentümers, nicht der der gossipenden Nachricht, sodass eine spätere Rotation durch den Eigentümer an dem gemessen wird, was der Eigentümer gesagt hat. Was eine gegen ihn geprüfte Signatur erreichen kann, ändert sich nicht: Es ist weiterhin Vertrauen beim ersten Gebrauch, bestenfalls als valid-untrusted gemeldet. Ein anderer Schlüssel vom Eigentümer ist ebenfalls keine Beförderung; er rangiert einfach über dem Gossip und ersetzt es. Eine Netzwerkquelle (WKD, DANE, …) oder ein Operator, die einen gegossipten Schlüssel erneut sieht, übernimmt den Datensatz als gewöhnliche Auffrischung.

Eine Rotation ist niemals still

Die Ausnahme ist am From:-Header festgemacht, den der Absender schreibt, und die eingehende Authentifizierung ist fail-open, sodass eine Nachricht, die bloß behauptet, von einem Korrespondenten zu stammen, den Schlüssel ändern kann, an den wir für ihn verschlüsseln. Autocrypt nimmt diesen Tausch hin (es verteidigt gegen passives Sammeln, nicht gegen einen aktiven Angreifer auf dem Pfad), und Pepsi ebenso, aber es hinterlässt drei Spuren:

• dieselbe Anweisung, die den Schlüssel ersetzt, schreibt einen key.peer.rotate-Datensatz in das Audit-Log — die Adresse, das Protokoll, die verdrängten und die neuen Fingerabdrücke und beide Stichtage —, sodass es keine Rotation ohne ihren Eintrag gibt; pepsi-status fasst die der letzten 30 Tage zusammen;

• ist RESPONSE_STAGE bei pepsi-stage-autocrypt-learn gesetzt, erhält jeder lokale Empfänger der auslösenden Nachricht einen Hinweis, der den Korrespondenten und beide Fingerabdrücke nennt (die Vorlage key-rotation.<lang>.body), sodass die Person, die gleich antworten will, weiß, dass sie prüfen sollte, bevor sie etwas Vertrauliches sendet;

• eine Telemetrie-Zählung autocrypt-rotation und eine Logzeile.

Ein Operator, der lieber eine echte Rotation ablehnt, als eine gefälschte anzunehmen, setzt ACCEPT_ROTATION = expired für diese Stage: Der neuere Schlüssel wird dann nur übernommen, wenn jeder gespeicherte Schlüssel für die Adresse tot ist — als widerrufen oder abgelaufen verzeichnet oder über sein expires_at hinaus. Andernfalls wird das Angebot zurückgehalten: Nichts ändert sich, ein key.peer.rotate.held-Warndatensatz wird geschrieben, und den Empfängern wird mitgeteilt, dass der neue Schlüssel nicht angenommen wurde — was wichtig ist, denn ein Korrespondent, der seinen Schlüssel tatsächlich gewechselt hat, kann nicht lesen, was ihm gesendet wird, bis ein Operator den alten Datensatz entfernt (pepsi-keys peer remove) oder den neuen Schlüssel von Hand importiert. Ein gelernter Schlüssel wird mit dem Ablaufdatum gespeichert, das sein eigenes Material angibt (die Selbstsignatur eines OpenPGP-Primärschlüssels, ein X.509-notAfter), sodass ein abgelaufener Schlüssel als tot gilt, ohne dass ihn etwas markiert; einer, der kein Ablaufdatum angibt, wird erst verdrängt, wenn er als widerrufen oder abgelaufen markiert ist, oder von Hand.

Zwei Regeln begrenzen, wie breit ein Eintrag sein kann:

• ein Eintrag darf eine ganze Domain benennen (*@domain), aber nur, wenn er von Hand eingetragen wurde. Das setzt eine Datenbank-Einschränkung durch, keine Konvention, sodass kein Entdeckungsmechanismus die Antwort für eine Adresse auf eine Domain verallgemeinern kann;

• eine exakte Adressübereinstimmung gewinnt immer. Ein *@domain-Datensatz wird nur herangezogen, wenn kein exakter existiert, und pepsi-keys peer show markiert ihn als den Rückfall, der er ist.

11.12. Den Schlüssel eines Korrespondenten finden

Alles Obige betrifft Schlüssel, sobald sie im Speicher sind. Sie für die Adresse eines anderen dorthin zu bekommen ist Schlüsselentdeckung: gegeben eine E-Mail-Adresse den öffentlichen Schlüssel oder das Zertifikat finden, festhalten, woher es kam und wie viel diese Quelle wert ist, und es zwischenspeichern. Das Programm ist pepsi-keydisc, und die ganze Funktion wird von [pepsi-keydiscovery] konfiguriert.

Einen Schlüssel zu finden ist leicht. Zu wissen, ob man ihm glauben soll, ist das ganze Problem, weshalb die Quelle und das DNSSEC-Flag mit jedem Schlüssel gespeichert werden.

11.12.1. Woher ein Schlüssel kommen kann

dane

DNS-OPENPGPKEY (RFC 7929) und SMIMEA (RFC 8162), unter einem gehashten Local-Part. Ohne das DNSSEC-AD-Bit des Resolvers abgelehnt — siehe Wenn es keinen validierenden Resolver gibt.

wkd-advanced

Das Web Key Directory unter openpgpkey.<domain> — ein Host, den die Domain bewusst delegieren musste.

wkd-direct

Das Web Key Directory auf der Domain selbst, <domain>/.well-known/openpgpkey.

ldap

Ein konfiguriertes Verzeichnis. Optional und nur mit dem Cargo-Feature ldap einkompiliert, denn eine Installation ohne Verzeichnis sollte keines linken.

vks

Ein verifizierender Keyserver (standardmäßig keys.openpgp.org, oder jeder Server, der dieselben Pfade spricht). Beachten Sie, dass dies VKS ist, nicht das ältere unverifizierte HKP: Ein HKP-Server liefert einen Schlüssel aus, den irgendwer für irgendwessen Adresse hochgeladen hat.

inbound

Aus einer bereits eingetroffenen Nachricht geerntet — ein application/pgp-keys-Teil, ein S/MIME-Signiererzertifikat oder ein Autocrypt:-Header. Nur Material, das die eigene Adresse des Absenders beansprucht, wird behalten. Kein Entdeckungs*dienst*: Es läuft dort, wo die Nachricht bereits ist, und kostet keine Netz-E/A, weshalb es in SOURCES nicht erscheinen darf. Geschrieben von pepsi-stage-autocrypt-learn, nicht von der Entschlüsselungs-Stage.

gossip

Aus den Autocrypt-Gossip:-Feldern innerhalb einer Nachricht gelesen, die pepsi-stage-decrypt entschlüsselt hat: die Schlüssel der anderen Empfänger, die der Absender beigefügt hat, damit ein Allen-Antworten an jemanden verschlüsselt werden kann, von dem man nie direkt Mail hatte (Autocrypt Level 1 §5.3). Ein Feld zählt nur für eine Adresse, die das To:, Cc: oder Reply-To: der Nachricht selbst nennt — die Empfängerregel aus §5.3. Der einzige Weg, auf dem ein Korrespondent über einen anderen sprechen darf, und daher eine eigene Sprosse ganz unten auf der Leiter. Wie inbound ist es kein Dienst und darf in SOURCES nicht erscheinen; die übrigen Regeln, die entscheiden, ob ein Feld zählt, stehen unter pepsi-stage-autocrypt-learn, wo beide inline gelernten Sprossen geschrieben werden.

manual / api

Ein Operator, der pepsi-keys peer import ausführt, oder eine authentifizierte Einlieferung. Überhaupt nicht entdeckt; hier aufgeführt, weil es die Spitze derselben Leiter ist.

11.12.2. Die Vertrauensleiter

Dies ist die Reihenfolge, nach der alles beurteilt wird — das Beste zuerst. Sie entscheidet, welcher Schlüssel einen Konflikt gewinnt, womit MIN_TRUST vergleicht und wie viel zusätzliche Zeit einer noch laufenden Methode von der Abbruchregel unten gewährt wird.

Rang	Quelle	Warum dort
0	own	Überhaupt nicht entdeckt, und eigentlich keine Sprosse: die öffentliche Hälfte einer Identität, die diese Installation für die Adresse hält. Sie greift der Leiter vor, statt sie anzuführen — siehe Die Schlüssel unserer eigenen Benutzer werden nicht entdeckt —, sodass sie jede Untergrenze überspringt und kein peer_key-Datensatz für diese Adresse herangezogen wird.
1	manual / api	Ein Operator, der einen Fingerabdruck eingetippt hat, meinte es so. Die Schreibweise manual ist außerdem die einzige Quelle, der die Datenbankbedingung einen *@domain-Datensatz einzutragen erlaubt.
2	dane mit dem AD-Bit	Die einzige Quelle mit kryptographischer Herkunft: Die Domain hat ihn veröffentlicht, und DNSSEC beweist, dass die Antwort unterwegs nicht umgeschrieben wurde.
3	wkd (advanced)	Über verifiziertes HTTPS von openpgpkey.<domain> abgeholt, einem Host, den die Domain absichtlich eingerichtet hat.
4	wkd-direct	Dasselbe, von der Domain selbst. Ein schwächeres Absichtssignal als ein eigener Host, daher ein eigener Rang.
5	ldap	Ein vom Operator konfiguriertes Verzeichnis und daher halb vertraut — aber immer noch ein Verzeichnis, das ein anderer betreibt.
6	vks	Beweist nur, dass jemand, der dieses Postfach kontrolliert, ihn hochgeladen hat: Der Server hat eine Bestätigungsmail geschickt und jemand hat sie angeklickt. Eine echte Prüfung, und eine viel schwächere als „die Domain veröffentlicht dies“.
7	inbound (geerntet, Autocrypt)	Vertrauen beim ersten Gebrauch, in das, was der Eigentümer der Adresse über seine eigene Adresse gesagt hat. Auch das Gewicht, das ein dane-Datensatz ohne das AD-Bit trägt: Ein DNS-Eintrag, den niemand signiert hat, ist nicht mehr wert als ein Abgreifen. Die Entdeckung lehnt eine solche Antwort rundweg ab (Wenn es keinen validierenden Resolver gibt), daher gilt dies nur für einen Datensatz, der auf anderem Weg hineingelangt ist — und ein solcher Datensatz kann eine Signatur ebenfalls niemals valid machen.
8	gossip (Autocrypt-Gossip)	Die Einführung eines anderen durch einen Korrespondenten (Autocrypt Level 1 §5.3), aus dem Chiffrat einer von diesem Host entschlüsselten Nachricht gelesen. Dasselbe Material wie Rang 7 und eine andere Behauptung: nicht „das ist mein Schlüssel“, sondern „das ist der Schlüssel eines anderen“. §5.3 hält die beiden gerade deshalb in getrennten Peer-Zuständen, damit die Einführung durch einen Dritten nie verdrängen kann, wofür ein Eigentümer gebürgt hat, und genau das erkauft eine eigene Sprosse.

[pepsi-keydiscovery] MIN_TRUST ist die Untergrenze, und sie steht standardmäßig auf any — der untersten Sprosse, welche das gerade auch sei, sodass gegossipte, geerntete und Autocrypt-Schlüssel allesamt angenommen werden. Die Alternative dazu, an einen Schlüssel aus Vertrauen beim ersten Gebrauch zu verschlüsseln, ist nicht, an einen besseren Schlüssel zu verschlüsseln, sondern Klartext zu senden. Opportunistische Verschlüsselung an einen unauthentifizierten Schlüssel schlägt passives Abhören immer noch, und das ist die Bedrohung, der Mail tatsächlich am ehesten begegnet. Die Einstufung ist dadurch nicht sinnlos — sie schlichtet Konflikte, sie wird je Schlüssel festgehalten, und ein Operator, der lieber nichts sendete, als an einen unauthentifizierten Schlüssel zu senden, hat eine Option zum Anheben.

Der Standardwert verfolgt die unterste Sprosse, statt eine Zahl zu benennen. MIN_TRUST = harvested benennt genau Rang 7, sodass es annimmt, was ein Korrespondent über sich selbst angekündigt hat, und die Einführung eines Fremden ablehnt. Die Einführungen werden so oder so gespeichert; die Untergrenze entscheidet nur, ob an sie verschlüsselt werden darf.

Der Name jeder Sprosse wird als Untergrenze akzeptiert (own, manual, dane, wkd, wkd-direct, ldap, vks, inbound, gossip), dazu die Aliasse any/none für die unterste, harvested/autocrypt für Rang 7 und owner-confirmed — das den Rang 6 danach benennt, was der Nachweis bedeutet, statt nach der Methode, die ihn erbracht hat: Ab vks aufwärts hat jemand, der die Kontrolle über das Postfach oder die Domain nachweisen konnte, den Schlüssel absichtlich veröffentlicht; darunter hat niemand irgendetwas nachgewiesen.

11.12.3. Die Schlüssel unserer eigenen Benutzer werden nicht entdeckt

Es gibt eine Adresse, für die die ganze Leiter die falsche Frage ist: eine, für die diese Installation die Schlüssel gemacht hat. Wenn pepsi-keys eine Identität für alice@example.org ausgestellt hat, dann ist Alices Schlüssel nichts, das zu finden, abzuwägen und zu vergleichen wäre — er liegt im Regal, und er ist der einzige Schlüssel, an den ihre Mail verschlüsselt werden kann und den sie öffnen können wird.

Das ist wichtig, weil peer_key keine vertrauenswürdige Tabelle ist. Ein Teil dessen, was sie füllt, ist das Ernten aus eingehender Mail, und geerntet wird am From:-Header, den der Absender schreibt. Die eingehende Authentifizierung ist bewusst fail-open — nur ein definitiver DMARC-Fehlschlag unter DMARC_ENFORCE weist ab —, sodass auf einer Installation, die DMARC für ihre eigene Domain nicht durchsetzt, eine Nachricht, die From: alice@example.org behauptet und einen Autocrypt:-Header trägt, einen Peer-Schlüssel für Alice mit dem Schlüssel eines Fremden darin sät. Dann gehen zwei Dinge schief, und sie sind der Grund, warum dies eine Verteidigung ist und keine Ordnungsregel: Mail von einem unserer Benutzer an einen anderen würde an den untergeschobenen Schlüssel verschlüsselt, und eine damit erstellte Signatur verifizierte und setzte state.signature_verified für einen Außenstehenden.

Also fragen beide Krypto-Stages „ist das eine von unseren“, bevor sie fragen „was hat die Entdeckung gefunden“. Lautet die Antwort ja, ist unser eigener Schlüssel die Antwort: Die peer_key-Datensätze des Korrespondenten werden für diese Adresse überhaupt nicht herangezogen, welchen Rang sie auch haben und wie sie auch eintrafen. state.crypto hält es als own fest.

Wichtig

Die Regel hängt am Halten eines Schlüssels, nicht am Bedienen der Adresse, und der Unterschied ist eine Installation und keine Spitzfindigkeit. Ein Benutzer, der GnuPG in seinem eigenen Client betreibt, Pepsi nie gebeten hat, etwas zu verschlüsseln, und uns nie einen Schlüssel hochgeladen hat, hat hier keine Identität — und sein echter Schlüssel ist einer, den dieser Host nur je aus Entdeckung, Ernte oder Gossip lernen kann. Eine pauschale Regel „glaube nie einem entdeckten Schlüssel für eine Adresse, die wir bedienen“ schickte diesem Benutzer für immer Klartext. Also: Wenn wir die Schlüssel gemacht haben, sind sie die, die verwendet werden; wenn nicht, wird die Adresse wie die jedes anderen Korrespondenten behandelt, samt der Exposition durch Vertrauen beim ersten Gebrauch.

Das Korollar ist der Preis: Für eine Adresse, für die wir sehr wohl eine Identität halten, verifiziert eine mit dem eigenen separaten Schlüssel des Benutzers erstellte Signatur nicht, wie gut bezeugt dieser Schlüssel auch sei – bis dieser Schlüssel selbst als MUA-Schlüssel des Benutzers registriert ist (Zwei Schlüssel je Benutzer). Ihn zu registrieren (pepsi-keys identity import ohne --private, die Webkonsole, der E-Mail-Befehl register oder automatisch aus dem eigenen Autocrypt:-Header des Benutzers) ist der Weg, auf dem ihm geglaubt wird, und zugleich der Weg, auf dem der Benutzer beginnt, an ihn verschlüsselte Mail zu empfangen.

11.12.3.1. Die Benutzer finden, die ihren eigenen Schlüssel mitbringen

Die obige Regel lässt konstruktionsbedingt einen Rest: Eine bediente Adresse, für die wir keine Identität halten, beruht weiterhin auf Vertrauen beim ersten Gebrauch, denn das ist der einzige Kanal, über den der echte Schlüssel eines Bring-your-own-GnuPG-Benutzers diesen Host erreichen kann. Was ein Operator dagegen tun kann, ist keine Einstellung — es ist eine Vorstellung. Importieren Sie den öffentlichen Schlüssel dieses Benutzers als Identität, und die Exposition ist für diese Adresse vorbei: Von da an greift unser eigener Datensatz dem vor, was der Cache enthält.

Die Installation braucht also einen Weg, sie zu bemerken, und das ist pepsi-keys peer unclaimed am Terminal oder GET /api/v1/peers/unclaimed (siehe Die administrative API): die Adressen, die

• von dieser Installation bedient werden (ihre Domain ist eine aus [pepsi-ingress] ACCEPTED_DOMAINS; der Befehl zählt auch [pepsi-crypto] LOCAL_DOMAINS mit),

• von keiner aktiven Verschlüsselungsidentität von uns gehalten werden und

• dennoch in peer_key vorhanden sind — gewöhnlich aus dem Autocrypt:-Header ihrer eigenen ausgehenden Mail geerntet, was genau das ist, was ein Benutzer erzeugt, der GnuPG in seinem eigenen Client betreibt.

Jeder Datensatz benennt die zwischengespeicherten Schlüssel mit ihrem Fingerabdruck und ihrer source, sodass ein Operator einen vom Benutzer selbst angekündigten Schlüssel (inbound) von der gegossipten Einführung durch einen Dritten (gossip) unterscheiden kann, bevor er danach handelt, dazu eine Zählung, wie viele Identitäten — gleich welchen Zwecks und Lebenszyklusstands — die Adresse tatsächlich hat. Der Bericht ist nur lesend und ändert nichts; er ist eine Arbeitsliste, kein Alarm, und ein leerer ist der gewöhnliche Zustand einer Installation, deren Benutzer alle hier Identitäten halten. Die Seite Korrespondentenschlüssel der Konsole (/ui/peers) listet den gesamten peer_key-Cache auf, nicht diese Teilmenge.

Die beiden unterscheiden sich in einem Standardwert. Der Befehl listet nur geerntete Schlüssel auf — Quelle inbound oder gossip, die beiden, die ein Fremder einfach dadurch unterschieben kann, dass er uns eine Nachricht mit gefälschtem From: sendet —, denn das ist die Exposition, für die der Bericht existiert; --all-sources erweitert ihn auf entdeckte, manuelle und API-Schlüssel, was der Endpunkt immer zurückgibt:

pepsi-keys peer unclaimed                  # harvested and gossiped keys
pepsi-keys peer unclaimed --all-sources    # every cached key
pepsi-keys peer unclaimed --json           # [] when there is nothing to do

Bestätigen Sie für jeden Eintrag den Schlüssel mit seinem Eigentümer und registrieren Sie ihn dann entweder als dessen eigenen (pepsi-keys identity import ADDRESS --protocol P --purpose U --public FILE, ohne --private) oder verwerfen Sie ihn (pepsi-keys peer remove ID).

Bemerkung

Fragen Sie den Benutzer, bevor Sie importieren. Der Schlüssel im Cache ist einer, den jemand angekündigt hat; außerhalb des Kanals zu bestätigen, dass er wirklich seiner ist, ist das, was aus einem Datensatz aus Vertrauen beim ersten Gebrauch einen vertrauenswürdigen macht, und ist der ganze Wert der Übung.

Welche Lebenszykluszustände zählen, unterscheidet sich zwischen den beiden Verwendungen, aus dem Grund, aus dem es Ablauf gibt:

• An die Adresse zu verschlüsseln zählt nur active-Identitäten. Ein ausgemusterter Schlüssel darf keine neue Mail empfangen, und eine Installation, die den Schlüssel eines Benutzers ausgemustert hat, ohne einen neuen auszustellen, ist in derselben Lage wie eine, die nie einen Schlüssel für ihn hielt — also übernimmt die Entdeckung.

• Eine Signatur von der Adresse zu verifizieren zählt alles außer revoked. Eine letztes Jahr erstellte Signatur wurde mit dem letztjährigen Schlüssel erstellt; sich zu weigern hinzusehen meldete die Mail unserer eigenen Benutzer bei jedem Schlüsselwechsel als nicht verifizierbar. revoked ist ausgenommen, weil dort der Operator sagt, dass das Material überhaupt nicht verwendet werden darf.

11.12.4. Die Pipeline blockiert nie an einem Keyserver

Die Entdeckung ist asynchron und außerhalb der Stages. Eine Stage, die einen Schlüssel braucht, den sie nicht hat, betreibt überhaupt keine Netz-E/A: Sie schreibt fest, was sie bereits erzeugt hat, pausiert die Nachricht und reiht eine Anfrage ein, deren Schlüssel die Adresse ist. Eine pepsi-keydisc-Instanz beantwortet die Anfrage und gibt in demselben Round-Trip, der den Schlüssel speichert, jede an dieser Adresse geparkte Nachricht frei.

Drei Folgen ergeben sich, jede beabsichtigt statt ein Nebeneffekt:

• Ein langsamer Keyserver kann keinen Stage-Worker festhalten. Das Problem wird beseitigt statt begrenzt — es gibt keinen wartenden Worker, den man begrenzen könnte.

• Hundert Nachrichten an einen Korrespondenten kosten eine Abfrage. Der Schlüssel der Anfrage ist die Adresse, sodass sie sich darauf deduplizieren und gemeinsam freigegeben werden.

• Eine Anfrage, die sich ohne Schlüsselfund erledigt, gibt ihre Wartenden dennoch frei. Die Dienste finden Schlüssel; die Stages entscheiden über Mail. Nichts in der Entdeckungsschicht entscheidet je über das Schicksal einer Nachricht.

Die Methoden laufen parallel: Jede Methode in SOURCES startet auf einmal, jede als eigener Prozess (pepsi-keydisc@dane, @wkd-advanced, @wkd-direct, @vks, @ldap). Die beiden Web-Key-Directory-Methoden sind getrennte Ränge und daher wirklich nebenläufig, keine Rückfallkette — direct nur „falls advanced scheitert“ auszuführen nähme stillschweigend die schwächere Antwort an, wann immer die stärkere bloß langsam war. Ein Prozess je Methode bedeutet außerdem, dass ein hängendes LDAP-Bind WKD nicht aufhalten kann, und dass eine Methode abzuschalten systemctl mask --now pepsi-keydisc@<method> heißt (mask, weil pepsi.target die vier Standardinstanzen startet und eine bloß deaktivierte wieder starten würde).

Halten Sie SOURCES und die aktivierten Units im Gleichklang. SOURCES ist die Liste, auf die die Abbruchregel wartet, sodass eine Instanz, deren Methode sie nicht auflistet, den Start verweigert, und eine Methode, die sie auflistet und für die nichts läuft, jede Anfrage das volle TIMEOUT kostet, bevor sie aufgibt.

11.12.5. RANK_GRACE: der Regler zwischen Tempo und Gründlichkeit

Alles auf einmal laufen zu lassen wirft eine Frage auf: Eine Antwort ist von einer mittelmäßigen Quelle eingetroffen, und eine bessere läuft noch. Warten oder losgehen?

RANK_GRACE ist die einzige Stellschraube, die sie beantwortet. Wenn eine Abfrage gelingt, wird jeder noch laufenden Methode, die besser rangiert,

RANK_GRACE × (how many ranks better it is)

zusätzliche Zeit gewährt, gemessen ab dem Moment, in dem die vorliegende Antwort eintraf. Läuft dieses Fenster ab, gewinnt das beste vorliegende Ergebnis. Die Stellschraube spannt den ganzen Bereich vernünftiger Richtlinien auf:

Einstellung	Verhalten
0	Die erste brauchbare Antwort gewinnt rundweg. Am schnellsten; die Einstufung schlichtet dann nur noch Konflikte im Speicher, nie das Rennen.
5 s (Standardwert)	Ein Rang höher bekommt 5 s, drei Ränge höher 15 s. Ein langsamer WKD-advanced-Server kann eine Nachricht nicht hinter einem bereits eingetroffenen Keyserver-Treffer festhalten, aber eine fast ebenso schnelle bessere Quelle darf immer noch gewinnen.
≥ TIMEOUT	Auf jede Methode wird gewartet, und die Einstufung gilt vollständig. Am langsamsten und gründlichsten; pepsi-setup merkt diese Konfiguration an, statt sie zu beanstanden, denn sie ist eine legitime Wahl.

Zwei weitere Fristen begrenzen dieselbe Auffächerung: METHOD_TIMEOUT (15 s) ist das eigene Netzbudget einer Methode, und TIMEOUT (60 s) beendet die ganze Anfrage, was auch immer noch läuft. Eine Anfrage, die mit nichts endet, ist kein Fehler; es ist ein Korrespondent ohne Schlüssel.

11.12.6. Der negative Cache

Wenn eine Anfrage sich ohne Schlüssel erledigt, wird dieses Ergebnis behalten: für NEGATIVE_TTL (24 h) nach einem autoritativen „hier gibt es keinen Schlüssel“, und für das viel kürzere ERROR_TTL (1 h) nach einem Netz*fehlschlag* — „der Server war unten“ ist es wert, früher erneut versucht zu werden als „es gibt keinen Schlüssel“.

Die daraus folgende Regel:

Eine Nachricht an eine Adresse mit einem frischen Negativeintrag pausiert nie. Sie nimmt sofort den Kein-Schlüssel-Pfad der Stage.

Ohne das pausierte jede Nachricht an einen Korrespondenten, der schlicht keinen Schlüssel hat, das volle TIMEOUT, um eine bereits bekannte Antwort neu zu lernen — was einen fehlenden Schlüssel in eine dauerhafte Verzögerung je Nachricht für diese ganze Korrespondenz verwandelte. Die in Kauf genommenen Kosten liegen in der anderen Richtung: Ein vor fünf Minuten veröffentlichter Schlüssel bleibt unsichtbar, bis der Eintrag ausaltert. Senken Sie NEGATIVE_TTL, wenn dieser Tausch für Ihre Installation falsch ist; genau dafür ist die Option da.

Derselbe Kurzschluss greift, wenn die Frist einer ausstehenden Anfrage verstrichen ist, ohne dass jemand sie beantwortet hat — die Signatur einer Installation, die überhaupt keinen Entdeckungsdienst betreibt. Die Nachricht nimmt den Kein-Schlüssel-Pfad, statt erneut zu parken, und das ist es, was sie davon abhält, für immer zu parken.

11.12.7. Privatsphäre bei der Abfrage

Eine Adresse nachzuschlagen sagt jemandem, dass Sie im Begriff sind, ihr zu schreiben. Welchem jemand, hängt von der Methode ab: DNS sagt es den autoritativen Servern der Domain und dem Pfad Ihres Resolvers, WKD sagt es der eigenen Domain des Korrespondenten, und ein Keyserver sagt es seinem Betreiber.

Zwei Steuerungen existieren, und sie sind nicht austauschbar:

[pepsi-keydiscovery] ALLOW_DOMAINS / DENY_DOMAINS

Die des Operators, und die auf der Empfänger-Seite. Ein nicht leeres ALLOW_DOMAINS ist ausschließend — nur jene Domains werden je nachgeschlagen —, und DENY_DOMAINS gewinnt immer darüber. Das ist die Steuerung, zu der man greift, wenn die Frage lautet „frage jene Domain nie ab“.

[stage-encrypt] DISCOVERY = no

Die je Benutzer, über die pepsi.settings-Schicht je Adresse überschreibbar. Zwischengespeicherte Schlüssel werden weiterhin verwendet; ein Cache-Fehltreffer geht direkt auf den Kein-Schlüssel-Pfad, statt zu parken.

Wichtig

Der Name der Option lädt zur falschen Lesart ein. Die Einstellungsschicht je Adresse löst eine ausgehende Nachricht über ihren Umschlag**absender** auf. DISCOVERY = no für eine Adresse zu setzen bedeutet also

• „die Mail dieses Benutzers löst nie eine Abfrage aus“ —

und nicht

• „schlage diesen Korrespondenten nie nach“.

Es gibt bewusst keine Empfänger-Sperrliste je Adresse: Sie bräuchte eine neue Spalte und eine zweite Liste, um mit DENY_DOMAINS konsistent zu bleiben, und zwei überlappende Sperrlisten, die sich widersprechen können, sind schlimmer als eine, die es nicht kann. Die Steuerung auf der Empfängerseite ist die des Operators, oben.

11.12.8. Wenn es keinen validierenden Resolver gibt

Die DANE-Entdeckung ist AD-gebunden: Eine OPENPGPKEY- oder SMIMEA-Antwort, die der Resolver nicht DNSSEC-validiert hat, wird rundweg abgelehnt. Das ist nicht dieselbe Richtlinie wie beim TLS-Reporting, wo ein gefälschtes rua einen Angreifer eine Kopie eines Berichts kostet. Ein unvalidierter Schlüsseleintrag ist ein Schlüssel von dem, der für die Zone antworten kann, was keine Verbesserung gegenüber überhaupt keinem Schlüssel ist — eine unvalidierte Antwort ist also keine schwächere Antwort, sie ist keine Antwort.

Pepsi vertraut einem validierenden Resolver, statt DNSSEC selbst zu validieren, dasselbe Betriebsmodell, das seine DANE/TLSA-Unterstützung für die Transportsicherheit verwendet. Die Folge:

Warnung

Eine Installation ohne validierenden Resolver bekommt überhaupt keine DANE-Ergebnisse — stillschweigend, denn die Methode antwortet pflichtschuldig „kein Schlüssel“ für jede Adresse, und die bestrangige Quelle gewinnt schlicht nie. pepsi-setup sondiert danach und meldet es, aber die Behebung ist Ihre: Richten Sie Pepsi auf einen validierenden Resolver (unbound oder systemd-resolved mit DNSSEC=yes über einen vertrauenswürdigen Pfad), oder streichen Sie dane aus SOURCES, sodass nichts darauf wartet.

11.12.9. Eingehende Mail wartet auch

Die Verifikation pausiert auf demselben Mechanismus wie die Verschlüsselung: Wenn eine eingehende Signatur von einem Signierer stammt, dessen Schlüssel nicht zwischengespeichert ist, parkt die Nachricht, während die Entdeckung läuft, sodass die erste Nachricht eines neuen Korrespondenten ein echtes Urteil bekommt statt unverifiable.

Das kostet eine echte Verzögerung, genau bei der Mail, auf die jemand wartet. Drei Dinge mildern sie, und das erste ist das, zu dem man greifen sollte:

• INBOUND_TIMEOUT ist getrennt einstellbar. Ein Operator, der diese Verzögerung spürt, kann es auf wenige Sekunden senken, ohne das ausgehende TIMEOUT überhaupt anzufassen. pepsi-setup warnt oberhalb von fünf Minuten.

• Der negative Cache bedeutet, dass die zweite und spätere Nachrichten eines unbekannten Signierers nie pausieren — nur die erste zahlt.

• Anfragen deduplizieren je Adresse, sodass eine Flut von einem Signierer eine Abfrage kostet statt einer je Nachricht.

Ob der geparkte Datensatz Klartext enthält, hängt vom Protokoll ab. Nach den Schichtungsregeln liegt eine eingehende Signatur innerhalb des Chiffrats, sodass die Entschlüsselung geschehen muss, bevor der Signierer — und damit der fehlende Schlüssel — überhaupt bekannt ist. Was dann festgeschrieben werden darf, unterscheidet sich:

• Eine S/MIME-Signatur, die in einem Umschlag verschachtelt ist, überlebt die Entschlüsselung als gewöhnliche MIME-Schicht, sodass die Nachricht mit festgeschriebenem Klartext geparkt und genau einmal entschlüsselt wird.

• Eine OpenPGP-Signatur lebt nur im Paketstrom und ist in dem Moment weg, in dem der Klartext heraus ist. Den Klartext festzuschreiben zerstörte genau die Evidenz, für deren Prüfung der Schlüssel geholt wird, sodass eine solche Nachricht unverändert geparkt und beim Fortsetzen erneut entschlüsselt wird. Die zweite Entschlüsselung ist der Preis eines korrekten Urteils.

Bemerkung

Eine Exposition. Eine Nachricht, die mit festgeschriebenem Klartext geparkt ist — der obige S/MIME-Fall —, liegt bis zu INBOUND_TIMEOUT lang entschlüsselt in pepsi.workqueue.

Das ist dieselbe Exposition, die die Zustellung einen Augenblick später ohnehin erzeugte: Das Postfach bekommt Klartext. Es ist ein längeres Fenster, kein neues. Wenn dieses Fenster für Sie zählt, ist es INBOUND_TIMEOUT, das seine Länge festlegt. Siehe pepsi-stage-decrypt für die Regel, wie die Stage sie anwendet.

11.12.10. Wer den Speicher verwendet

pepsi-keys peer refresh --address übt die gesamte Entdeckungs-Auffächerung von Ende zu Ende durch — die Quellen, die Einstufung, die Anfragewarteschlange und den negativen Cache.

pepsi-stage-encrypt signiert lokal eingelieferte Mail als ihren From:-Autor und verschlüsselt sie je Empfänger, wobei es eine Nachricht parkt, deren Empfängerschlüssel nicht zwischengespeichert ist, bis ein Entdeckungsdienst die Anfrage erledigt. pepsi-stage-decrypt ist sein eingehendes Gegenstück: Es öffnet Mail, die an von diesem Host bediente Empfänger gerichtet ist — und probiert jede nicht widerrufene Identität von ihnen, einschließlich abgelaufener, denn alte Mail muss lesbar bleiben —, verifiziert die Signatur gegen den peer_key-Cache und die ca_trust-Anker und liest jedes Schlüsselmaterial, das die Nachricht selbst trägt. Es parkt auf dieselbe Weise am Schlüssel des Signierers, sodass selbst die erste Nachricht eines neuen Korrespondenten ein echtes Urteil bekommt statt unverifiable. Was es nicht tut, ist in den Speicher zu schreiben: Die Zertifikate und Autocrypt:-Header, die eine Nachricht trägt, werden im Arbeitsspeicher verwendet, um die Signatur eben dieser Nachricht zu prüfen, und danach verworfen. pepsi-stage-autocrypt-learn ist die Stage, die sie lernt.

Neuverschlüsselung für die Ablage. Eine Nachricht, die Pepsi entschlüsselt, wird standardmäßig im Klartext im Postfach abgelegt, was serverseitige Entschlüsselung überhaupt erst nützlich macht – das Gateway-Modell setzt voraus, dass der Mailspeicher vertrauenswürdig ist. Für einen Benutzer, der seinen eigenen MUA-Schlüssel registriert hat, schließt pepsi-stage-reencrypt diese Lücke: Unmittelbar vor der lokalen Zustellung platziert, nach jeder Stage, die den Inhalt liest, versiegelt es eine Nachricht, die die Decrypt-Stage mit dem MTA-Schlüssel geöffnet hat, an den neuesten aktiven MUA-Schlüssel des Benutzers, sodass das Postfach nur Chiffrat enthält, das allein dessen Client öffnen kann. Es fügt keine Signatur hinzu (das Urteil der Decrypt-Stage bleibt in X-Pepsi-Crypto), braucht kein Privileg (der Schlüssel ist öffentlich) und lässt Mail, die im Klartext eingetroffen ist, unangetastet. Für einen Benutzer ohne MUA-Schlüssel entscheidet [stage-reencrypt] ON_NO_CLIENT_KEY: plaintext (der Standardwert) legt sie wie bisher ab; bounce lehnt sie mit einer DSN ab, die weder Nachrichtentext noch Betreff zurückgibt. Die Option gilt je Empfänger über pepsi-settings, sodass ein Benutzer darauf bestehen kann, während der Standardwert der Site nachsichtig bleibt:

pepsi-settings set bob@example.org reencrypt ON_NO_CLIENT_KEY bounce

11.13. Ein CLI-Durchgang

Geben Sie einer Adresse eine OpenPGP-Identität, sehen Sie sie an und prüfen Sie, dass GnuPG zustimmt, dass die öffentliche Hälfte ein Schlüssel ist:

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

Geben Sie derselben Adresse S/MIME-Material — ein Signier- und ein Verschlüsselungszertifikat, jedes für den sofortigen Gebrauch selbstsigniert, mit einer Zertifikatsanforderung über jeden Schlüssel zum Versand an eine CA:

pepsi-keys identity generate alice@example.org --protocol smime --csr

Wenn die CA antwortet, speichern Sie ihr Zertifikat über dem Schlüssel, der bereits im Speicher liegt, und machen Sie es zum primären Signiermaterial. Nichts wird neu geschlüsselt, und nichts bereits Gesendetes hört auf, lesbar zu sein:

pepsi-keys identity import alice@example.org \
    --protocol smime --purpose sign --public alice-sign.pem --primary

Veröffentlichen Sie die Adresse in einer signierten Zone:

pepsi-keys dns alice@example.org >> example.org.zone

Ziehen Sie einen Signierschlüssel zurück, nachdem ein Laptop gestohlen wurde. Die private Hälfte wird sofort zerstört; die öffentliche bleibt, sodass die Signaturen des letzten Monats weiterhin verifiziert werden können:

pepsi-keys identity revoke 1 --reason 'laptop stolen'
pepsi-keys identity show 1        # private material: purged at …

Mustern Sie alles aus, was seine Gültigkeit überschritten hat — dieselbe Regel, in großem Maßstab angewandt, und der natürliche Körper eines periodischen Timers:

pepsi-keys identity retire

Vertrauen Sie dem Schlüssel eines Korrespondenten von Hand und pinnen Sie ihn, sodass eine spätere Entdeckungsantwort ihn nicht ersetzen kann:

pepsi-keys peer import bob@example.com --protocol openpgp --file bob.pgp --pin
pepsi-keys peer show bob@example.com

Entscheiden Sie, zu welchen CAs sich eine eingehende S/MIME-Signatur ketten darf:

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

Und rollen Sie, einmal im Jahr oder nach einem Vorfall, den KEK:

pepsi-keys wrap rotate --dry-run
pepsi-keys wrap rotate

11.14. Konfigurationsübersicht

Die Algorithmus- und Sicherheitsrichtlinie lebt in [pepsi] und ist nur für Administratoren: Es sind Sicherheitsentscheidungen mit sicheren Standardwerten, keine Vorlieben, und weil die Überlagerungsschicht je Adresse nur [stage-<name>]-Abschnitte überschreibt, sind sie strukturell außer Reichweite von pepsi-stage-edit-settings und jeder Web-Administrationsoberfläche.

Jene Optionen sind CRYPTO_ALLOW_DOWNGRADE, CRYPTO_ALLOW_WEAK_DIGESTS, CRYPTO_MIN_RSA_BITS, CRYPTO_GENERATE_RSA_BITS, CRYPTO_INLINE_PGP, CRYPTO_OPENPGP_ALGORITHM, CRYPTO_SMIME_ALGORITHM und CRYPTO_SMIME_SHARED_KEY.

Die Verwahrungs- und Lebenszykluseinstellungen des Schlüsselspeichers selbst leben in [pepsi-crypto]: KEY_WRAP_SECRET und KEY_WRAP_KEY_ID (plus KEY_WRAP_SECRET_<ID> für einen ausgemusterten Schlüssel), AUTO_CREATE_IDENTITY, IDENTITY_VALIDITY_DAYS (standardmäßig 730) und die Lokalitätsoptionen LOCAL_DOMAINS / RECIPIENT_DELIMITER / TARGETS, die entscheiden, welchem Konto eine Adresse gehört. Eine Installation ohne Ende-zu-Ende-Kryptographie kann den Abschnitt ganz weglassen; sobald er irgendetwas sagt, besteht pepsi-setup auf einem brauchbaren KEY_WRAP_SECRET, denn ein Schlüsselspeicher, der keine Schlüssel speichern kann, ist ein Konfigurationsfehler und keine Vorliebe. Die erschöpfende Referenz ist pepsi.conf(5).

Das Verhalten im Stil von pEp und die Selbstbedienung sind Optionen von [stage-encrypt], je Adresse überschreibbar: ENABLE_PEP (Standard yes), ATTACH_KEYS_AS_FILES (Standard no), KEYS_CONTROL_LOCAL_PART (Standard pepsi-keys) und RESPONSE_STAGE (nicht gesetzt bedeutet keine Hinweise und keine E-Mail-Befehle).

Die Keyserver-Veröffentlichung hat ihren eigenen Abschnitt, [pepsi-keys]: VKS_PUBLISH (standardmäßig aus; ob von Hand erzeugte Schlüssel mit angeforderter Hochladung beginnen), VKS_SERVER (mit dem ersten [pepsi-keydiscovery] VKS_SERVERS-Eintrag als Standardwert, sodass eine Installation, die bereits einen Keyserver zum Lesen gewählt hat, ihn nicht zweimal benennt), und die Stellschrauben für Wiederholungen VKS_MAX_ATTEMPTS, VKS_RETRY_INTERVAL und VKS_BATCH. Die Web-Key-Directory-Veröffentlichung braucht überhaupt keine Konfiguration: Sie folgt dem published-Flag jeder Identität.

11.15. Siehe auch

Die beiden Stages, die diesen Speicher verwenden, sind pepsi-stage-encrypt (ausgehend) und pepsi-stage-decrypt (eingehend); Das Secure-Link-Ausweichportal ist, was geschieht, wenn ein Korrespondent überhaupt keinen Schlüssel hat, und Interoperabilität mit Clients hält fest, welche Fremdclients tatsächlich gegen das gemessen wurden, was jene Stages ausgeben. pepsi-keydisc ist der Entdeckungsdienst, pepsi-keys die Operator-CLI und pepsi-stage-vks-confirm die Keyserver-Bestätigungsnachverfolgung. RFC-Index ordnet jeden hier genannten Standard dem Modul zu, das ihn umsetzt, und Microsoft Exchange als Gateway ist die Installationsgestalt, für die dieser Speicher gebaut wurde.

pepsi-keys, pepsi-setup, Architektur, Konfiguration, pepsi-keys(1), pepsi.conf(5), pepsi-setup(1).