Vorwort

Brainstorming zur Implementierung von XMPP OX (XEP-0373: OpenPGP for XMPP). Es gibt verschiedene Arten wie man die Verwendung von OpenPGP in XMPP implementieren kann. In diesem Dokument soll das Thema diskutiert werden.

Grundlage ist XEP-0373: OpenPGP for XMPP Version 0.4.0 (2018-07-30)

GnuPG Home und Keyring

In GnuPG ist es möglich einen eigenen Home Directory zu verwenden oder einen eigenen Keyring zu definieren. Eine Änderung würde bewirken, dass der XMPP Client und der eigene Keyring / GnuPG Instanz unabhängig von einander verwendet werden. Es ist zu klären welche Vor- oder Nachteile die Verwendung eines eigen Keyring oder Homedir hat.

Für Anwender die schon einen Key besitzen und diesen auch für XMPP nutzen wollen, sehe ich hier einen komplexeren Ablauf, wenn die Schlüssel auf mehrere Keyrings verteilt sind.

Aus Sicht für der Anwender sehe ich einen Key mehr als eine Eigenschaft eines Kontakts in einem Adressbuch. So ist vom Anwendungsdesign eine Überlegung die "Kontakte" in einem Adressbuch darzustellen und diese auch individuell zu nutzen.

Eine Aufteilung der Kontakte in noch mehr Quellen macht die Verwendung und Verwaltung nur komplexer. Ferner ist die Zertifizierung und die Bildung des Trust-DB aufwendiger.

Für Nutzer, die ohnehin OpenPGP nur für XMPP verwenden, würde der Ort keine Rolle spielen. Die Verwendung eines Keyring auch mit unterschiedlichen Account sehe ich nicht als Problem.

Verwaltung des eigenen Schlüssel

Beim Verwenden von OpenPGP in XMPP sehe ich die folgenden Anwendungsfälle:

• Der Benutzer hat noch keinen privaten OpenPGP Schlüssel
• Der Benutzer hat einen privaten Schlüssel, jedoch noch kein Zuordnung zu XMPP
• Der Benutzer hat einen privaten Schlüssel und eine Zuordnung zu XMPP

Wenn der Benutzer noch keinen privaten Schlüssel hat, sollte die Anwendung einen OpenPGP Key erzeugen. Ein Experten-Modus für die Angabe von Schlüsseltyp und Schlüssellänge, sowie Verfallsdatum. In einem "normalen" Modus wird der Schlüssel automatisch generiert: rsa3072 / 2 Jahre. In beiden Fällen wird die XMPP Adresse (JID) im URI Format als UID eingetragen:

sec   rsa3072 2020-05-16 [SC] [verfällt: 2022-05-16]
      A8431A0170B3EBB564CE294D0C1CE873ED588C2B
uid        [ ultimativ ] xmpp:alice@domain.tld
ssb   rsa3072 2020-05-16 [E] [verfällt: 2022-05-16]

Sind im Keyring private Schlüssel vorhanden, kann der Benutzer auswählen, ob er einen neuen Key erzeugen will (siehe oben) oder einen der Schlüssel verwenden will. Hat der Benutzer sich für einen Schlüssel entschieden, wird für diesen Schlüssel eine UID angelegt mit der JID angelegt.

Existiert ein Key mit der JID als UID wird diese verwenden. Wenn jedoch mehrere existieren, ist die Verwendung des Schlüssels nicht eindeutig. Zu klären ist, was in diesem Fall passieren soll?

Damit ist der Punkt 8.5 "OpenPGP User IDs" in XEP-0373 erfüllt.

Synchronisieren der privaten Schlüssel

In Kapitel 5 wird das synchronisieren de privaten Schlüssel via PEP Node beschriebe.

Meiner Meinung nach sollte die Synchronisation niemals automatisch erfolgen und immer eine bewusste Entscheidung des Benutzer sein. Es gibt keinen Bedarf für die Synchronisation eines privaten Schlüssels, wenn

• der private Schlüssel auf einer Smartcard / Token ist
• der Benutzer nur ein Endgerät benutzt
• der Benutzer dies nicht möchte

Was passiert, wenn der Key auf eine Smartcard ist? Wird dann der Stub synchronisiert?

Schlüssel Validierung

Die Herausforderung ist die Validierung der Schlüssel. Das trust-model pgp verwendet WoT in dem der Schlüssel einer anderen Person via Fingerprint geprüft werden muss. Danach wird öffentliche Schlüssel des Kommunikationspartners signiert. Durch die Eintragung einer owner-trust ist es möglich das WoT abzubilden.

Der Nachteil bei diesem Konzept ist, dass es einfach keiner macht. Für diejenigen, die schon mit OpenPGP arbeiten, sollt das Modell kein Problem sein. Eine Kommunikation mit einem Kommunikationspartner kann in diesem Fall nur statt finden, werde der Schlüssel des Kommunikationspartner zertifiziert wurde.

Für die Benutzer, die mit der Schlüsselverwaltung nicht zu tun haben wollen, könnt man versuchen dies über ein eigenes trust-model abzubilden. Ich habe dies jedoch selber noch nicht ausprobiert, und müsste man erst einmal validieren.

Annahme: Gehen wir mal davon aus, dass wir das gleiche Homedir und die gleichen Keyrings verwenden können, jedoch einen andere trustdb. Wir nehmen die pgp TrustDB und verwenden diese mit dem trust-model pgp, wie man dies kennt. In einem "Nicht-Experten-Modus" wir man nun eine eigene Trust-Db verwenden, welche mit tofu oder tofu+pgp läuft.

Denkfehler: Ob man ToFu oder gpg verwenden, ist abhängig vom Anwender und nicht von der Anwendung. Wir gehen jetzt einfach mal davon aus, dass der Benutzer einfach gpg oder tofu+pgp benutzt.

Entweder der Anwender verwendet trust-model tofu+pgp oder trust-model pgp.

Beispiel

Ich versuche ein Text zu verschlüsseln:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

In diesem Fall kommt ein Meldung

gpg: 90ED0F38F201CF29: Es gibt keine Garantie, daß dieser Schlüssel wirklich dem angegebenen Besitzer gehört.

sub  rsa3072/90ED0F38F201CF29 2020-05-19 Name Name <rtfm@domain.tld>
 Haupt-Fingerabdruck  = 66C4 0DE0 7823 93BA 65D2  3E6C 8459 A4A7 7CAF A894
 Unter-Fingerabdruck  = 2A75 B79D 46E1 5655 39E4  CEC9 90ED 0F38 F201 CF29

Es ist NICHT sicher, daß der Schlüssel zu dem in der User-ID
Genannten gehört. Wenn Sie *wirklich* wissen, was Sie tun,
können Sie die nächste Frage mit ja beantworten

Diesen Schlüssel trotzdem benutzen? (j/N) 

Der Grund ist, dass der Schlüssel nicht signiert wurde.

Nutze ich jedoch ToFu:

echo "Test" | gpg --homedir /tmp/testpgp --trust-model tofu+pgp -r 66C40DE0782393BA65D23E6C8459A4A77CAFA894 --encrypt -a 

so ist die Verschlüsselung möglich.

Im Vergleich

gpg --homedir /tmp/testpgp --trust-model tofu+pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [  marginal ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]

gpg --homedir /tmp/testpgp --trust-model pgp -k 66C40DE0782393BA65D23E6C8459A4A77CAFA894 
gpg: WARNUNG: Unsichere Zugriffsrechte des Home-Verzeichnis `/tmp/testpgp'
pub   rsa3072 2020-05-19 [SC] [verfällt: 2022-05-19]
      66C40DE0782393BA65D23E6C8459A4A77CAFA894
uid        [ unbekannt ] Name Name <rtfm@domain.tld>
sub   rsa3072 2020-05-19 [E] [verfällt: 2022-05-19]