User Interface Interaction with GnuPG

Draft / Work in Progress AndreHeinecke 9.5.16

Note: This is not a discussed concept but a draft to get the discussion started. I've initially written it in German so most parts are still in german. Apologies to non german speakers, we will translate this to English.

This page should describe how User Interface Applications should integrate / interact with GnuPG and what API should be offered to enable the implementation of new OpenPGP-Key distribution concepts. with little redundancy. The main focus is on Mail User Agents.

Design Goals:

• Reduce redundant implementations.
• Comfortable use of GnuPG for developers.
• Assist developers to provide a common and good User Experience.

TODO: If we implement actions after some activity like proposed in the remark of user story T3, which component will do the counting and how will applications taken notice?

Aktueller Stand

Es gibt (Stand: Mai 2016) historisch gewachsen, verschiedene Arten GnuPG aus einer Anwendung heraus anzusprechen. Im Endeffekt läuft alles auf Prozessaufrufe der GnuPG-Programme hinaus. Die Unterscheidung "Prozessaufruf" bezieht sich auf die Verwendung ohne weitere Bibliothek.

Die offizielle API von GnuPG ist GpgME, für welches es Anbindung in vielen Programmiersprachen gibt, siehe https://wiki.gnupg.org/APIs . Ein großer Vorteil der Verwendung von GpgME ist, neben der stabilen API, die weitreichende Abstraktion von OpenPGP und S/MIME (CMS).

In der GnuPG-Initiative existiert zudem bereits das bestreben Benutzerinteraktion möglichst zu vereinheitlichen, um einerseits eine technische Duplikation ähnlicher Implementierungen zu vermeiden und andererseits, um sprachlich und in der Darstellung über mehrere Anwendungen das gleiche Bild zu liefern.

Hierzu wurde 2008 das UI-Server-Protokoll eingeführt. Anwendungen kommunizieren über einen Socket mit einer UI-Server-Anwendung, welche die Nutzerinteraktion übernimmt. Dieses Protokoll hat sich bisher nicht verbreitet. Die einzige bekannte Nutzung gibt es durch die Windows-Plugins GpgEX und GpgOL der Gpg4win-Initiative.

Prozessaufruf

Version: 2.1.11

Mit speziellen Parametern wie --status-fd --command-fd bietet GnuPG ein Kommandozeilenen-Interface, welches ein Format liefert, das grundsätzlich dafür geeignet ist von anderer Anwendung verarbeitet zu werden. Dafür gibt es jedoch keine Stabilitätsgarantien.

Vorteile:

• Einfacher Einstieg, da Kommandos bereits bekannt und weitreichend dokumentiert sind.
• Minimale Abhängigkeiten.

Nachteile:

• Eigene Parser-Implementation nötig.
• Leichte Änderungen in der Ausgabe können Parser brechen.
• Alle Details und Fehlerbehandlung sind schwierig komplett zu implementieren.

Beispielhafte Verwendung zum Importieren eines Zertifikats von einem Zertifikatsserver:

(Eingaben markiert mit ">" Ausgaben markiert mit "<")

> gpg2 --status-fd=1 --command-fd=0 --search aheinecke@gnupg.org
< (1)     Andre Heinecke <aheinecke@gnupg.org>
<        Andre Heinecke <andre@heinecke.or.at>
<        Andre Heinecke <aheinecke@intevation.de>
<        Andre Heinecke <andre.heinecke@intevation.de>
<          3072 bit RSA key F462B6B1, created: 2015-12-08, expires: 2025-12-05
< [GNUPG:] GET_LINE keysearch.prompt
> 1
< [GNUPG:] GOT_IT
< [GNUPG:] IMPORT_OK 0 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1
< gpg: key F462B6B1: "Andre Heinecke <aheinecke@intevation.de>" not changed
< gpg: Total number processed: 1
< gpg:              unchanged: 1
< [GNUPG:] IMPORT_RES 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0

Man erkennt, dass ein Parser nötig ist, der selbst Annahmen über das Verhalten von GnuPG enthalten muss. Beispielsweise über die Bedeutung der einzelnen Spalten.

GpgME

Version: 1.6.0

GpgME ist eine unabhängige Bibliothek für GnuPG. Es stellt eine C-API bereit, über die andere Anwendungen GnuPG verwendenden können. GpgME kann man sich als dabei als offiziellen Parser für GnuPG-Ausgaben vorstellen.

Es abstrahiert zudem zwischen OpenPGP und S/MIME und stellt eine vergleichbare API für die Anwendungen gpgsm und gpg zur Verfügung. Ausgaben der Anwendung werden threadsicher verarbeitet und dann in C-Datenstrukturen bereitgestellt.

Vorteile:

• Stabile und dokumentierte Schnittstelle.
• Von der GnuPG-Initiative gepflegter Parser.
• Abwärtskompatible Erweiterungen.

Nachteile:

• Abhängigkeit zu einer nativen Bibliothek.
• Initial höherer Einarbeitungsaufwand.

Beispielhafte Verwendung zum Importieren eines Zertifikats von einem Zertifikatsserver:

gpgme_key_t key;
gpgme_ctx_t ctx;
gpgme_protocol_t protocol = GPGME_PROTOCOL_OpenPGP;
gpgme_key_t keyarray[1];
gpgme_import_result_t impres;

init_gpgme (protocol);
gpgme_set_keylist_mode (ctx, GPGME_KEYLIST_MODE_EXTERN);
gpgme_op_keylist_start (ctx, "aheinecke@gnupg.org", 0);
gpgme_op_keylist_next (ctx, &key);
keyarray[0] = key;
gpgme_op_keylist_end (ctx);
gpgme_op_import_keys (ctx, keyarray);
impres = gpgme_op_import_result (ctx);

Das Beispiel ist so vereinfacht, dass keine Fehlerbehandlung stattfindet. Die einzelnen Kommandos können Fehlercodes zurückgeben, die in libgpg-error definiert wurden. Man sieht, dass die initiale Verwendung komplexer ist, als bei einem einfachen Systemaufruf. Dies hat aber dafür den Vorteil, dass man klar definierte C-Datenstrukturen hat. So könnte die Anzahl der unveränderten Zertifikate mit impres->unchanged abgefragt werden ohne wissen zu müssen, dass dies der 5. Ziffer in der IMPORT_RES Zeile entspricht.

Libkleo

Version: 5.2.1

Libkleo bezeichnet sich als "The KDE keymanagement Library". Sie bietet eine Abstraktion von "Crypto Backends", womit zwischen GnuPG und Chiasmus abstrahiert wurde. Mit der nächsten Version von Libkleo (5.3.0) wird die Chiasmus Unterstützung entfernt, da mit KMail 5.2.0 die Unterstützung für Chiasmus bereits in KMail entfernt wurde und somit keine bekannte Verwendung

Notwendigkeit der Abstraktion TODO: Wird die Notwendigkeit der Abstraktion bleiben? Chiasmus scheint was recht anderes zu sein.

Mit dem QGpgME-Backend wird zudem eine API angeboten, welche die Implementationsdetails in GpgME verbirgt, damit Qt-Entwickler eine komfortable, asynchrone und Job-basierte API nutzen können.

*Vorteile:*

• Integration von Kleopatra UI Elementen in eigene Anwendungen.
• Einheitliche Benutzererfahrung über mehrere Anwendungen.
• Einfach zu verwendende Kryptographie API.

*Nachteile:*

• Abhängigkeit zu Qt UI und einigen KDE Bibliotheken (Frameworks).
• Keine volle Kontrolle über die Implementation.

Beispiel:

    Protocol *openpgp = Kleo::CryptoBackendFactory::instance()->openpgp();
    KeyListJob *job = openpgp->keyListJob(/*bool remote*/ true);
    connect(job, &KeyListJob::result, job, [job, openpgp](KeyListResult, std::vector<Key> keys, QString, Error)
    {
        openpgp->importFromKeyserverJob()->start(keys);
    });
    job->start(QStringList() << "aheinecke@gnupg.org");

In diesem Beispiel passiert die Suche und der Import in einem anderen Hintergrundthread und ist somit direkt für die Verwendung in GUI Anwendungen geeignet.

Kleopatra über Prozessaufruf

Version Kleopatra 2.3.0

Kleopatra kann bereits über Kommandozeilenparameter angesprochen werden. Dies wird beispielsweise von Kontact Mail (der alte Name ist "KMail") verwendet, um Zertifikatsdetails anzuzeigen oder die Suche eines Zertifikats anzustoßen. Der Dateimanager Dolphin verwendet dies zudem um die Integration ins Dateimenü von Kleopatra zu ermöglichen.

Vorteile:

• Kein eigener Code für Benutzerinterface nötig.
• Einfache Verwendung.
• Keine Abhängigkeiten zu Bibliotheken.
• Zustandslos.

Nachteile:

• Fremdes Benutzerinterface, Dialoge in eigenem Fenster.
• Bei komplexen Kommandos könnte ein Parsen der Ausgabe nötig werden.
• Kleopatra muss zusätzlich gestartet werden oder bereits laufen.
• Keine Abstraktion zwischen GPA und Kleopatra.
• Derzeit nicht für alle möglichen Operationen implementiert.

Beispielhafte Verwendung zum Importieren eines Zertifikats von einem Zertifikatsserver:

kleopatra --search aheinecke@gnupg.org

Die weiteren Abläufe und der Import erfolgen dann interaktiv Zertifikatssuchdialog von Kleopatra

Hierbei ist zu erkennen, welche Vorteile es hat eine bestehende Anwendung zu verwenden: Im Falle, dass mehrere Zertifikate gefunden werden, müsste ein solcher Dialog von anderen Anwendungen selbst implementiert werden. Kleopatra erlaubt hier beispielsweise die Details eines Zertifikates anzuzeigen bevor es importiert wird.

UI-Server

Version Kleopatra 2.3.0 bzw. GPA 0.9.9

Das UI-Server-Protokoll ist ein Protokoll, über das GUI-Anwendungen Unterfenster für kryptografische Operationen ansteuern können.

Vorteile:

• Kein eigener Code für Benutzerinterface nötig.
• Vereinheitlichung der Benutzerschnittstelle bei Nutzung durch mehrere Anwendungen.
• GUI-Verbesserungen können an einer Stelle vorgenommen werden, als mehrere Anwendungen zu haben, welche u.U. nur teilweise implementiert sind.
• Vorhandene Zertifikate werden gecached.

Nachteile:

• Komplexe Verwendung und Kommunikation da zustandsorientiert.
• Notwendigkeit einer plattformabhängigen Socket-Implementation (libassuan).
• Qt/QWidgets oder GTK-basiertes Benutzerinterface.
• GPA oder Kleopatra zusätzlich notwendig.
• GPA oder Kleopatra müssen zusätzlich gestartet werden oder bereits laufen.
• Fremdes Benutzerinterface, Dialoge in eigenem Fenster.
• Derzeit nicht für alle möglichen Operationen definiert.

Beispielhafte Verwendung zum Verschlüsseln / Signieren einer Mail (Import vom Zertifikatsserver ist nicht im Protokoll definiert):

> SENDER --info -- testusera@example.com
< OK
> RECIPIENT testuserb@example.com
< OK
> PREP_ENCRYPT --expect-sign --protocol=OpenPGP
< OK
> INPUT FILE=/tmp/test
< OK
> OUTPUT FILE=/tmp/out
< OK
> ENCRYPT --protocol=OpenPGP
< OK
> INPUT FILE=/tmp/out
< OK
> OUTPUT FILE=/tmp/out.signed
< OK
> SIGN --protocol=OpenPGP
> BYE

Zertifikatsauswahldialog von GpgOL

Sprachanbindungen für GpgME (GpgMEpp, QGpgME)

Version 5.2.1

GpgME ist eine reine C-Bibliothek. Um diese komfortabler in anderen Programmiersprachen verwenden zu können, gibt es verschiedene Sprachanbindungen. Die für das EasyGPG-Projekt relevantesten sind QGpgME bzw. GpgMEpp, welche eine mit Qt-Klassen integrierte API bzw. eine C++-API bereitstellen.

In der betrachteten Version befindet sich ein Großteil der QGpgME-API in libkleo. Weitere QGpgME-Teile und GpgMEpp werden mit KF5GpgmePP als Teil von KDE-Applications veröffentlicht.

Im Rahmen der Aufträge Gpg4all2015 und EasyGpg2016 werden diese beiden Bibliotheken in das GpgME-Repository überführt und die KDE-Abhängigkeiten aus QGpgME entfernt. Zukünftig sollen diese beiden Sprachanbindungen als Teil von GpgME veröffentlicht werden.

Verwendete Anbindung in vorhandenen Mail User Agents

In der folgenden Liste sind einige Mail User Agents angeführt, deren Entwickler in Kontakt mit der GnuPG-Initiative stehen und bei denen die Gründe für die Entscheidungen, wie sie GnuPG verwenden, bekannt sind.

TODO Ggf. Offizielle Quellen Suchen und/oder nachfragen? AH

Konzept: Schnittstellen für EasyGPG

Um den unterschiedlichen Anforderungen von Entwicklern von Mail User Agents gerecht zu werden, und so eine unkomplizierte Implementation des EasyGPG-Konzeptes zu ermöglichen, wird es weiterhin verschiedene Wege geben müssen, um GnuPG zu verwenden.

Für eine einfachere Integration in anderen Anwendungen wird das komplexe, zustandsorientierte UI-Server-Protokoll nicht mehr weiterentwickelt, sondern zukünftig durch Prozessaufrufe ersetzt.

TODO: Das ist zu diskutieren, mir ist noch unklar, welche Vorteile dieser Weg haben sollte und wie die Design-Anforderungen besser erreicht werden könnte. BER

Um Kompatibilität mit bestehenden Anwendern des UI-Server-Protokolls zu erhalten, wird die Option START_KEYMANAGER mit einem optionalen Parameter <arguments> erweitert. Dieser wird das gleiche Verhalten haben, wie ein Prozessaufruf und auf dem Rückkanal die Ausgabe bieten, welche ansonsten auf stdout übergeben würde.

Es können grob fünf verschiedene Ebenen der Interaktion mit GnuPG unterschieden werden:

1. Prozessaufrufe von GnuPG-Anwendungen

Direkte Aufrufe von GnuPG-Anwendungen sowohl interaktiv auf der Kommandozeile als auch mit Parametern für maschinenlesbare Ausgaben.

Zielgruppe:// Entwickler einfacherer Anwendungen und Skripte, Experten Anwender, Entwickler die aufgrund technischer Einschränkungen (enigmail) keinen nativen Code verwenden können.

Begründung: Da der Kern aller Anbindungen der Prozessaufruf von GnuPG ist, wird GnuPG entsprechend erweitert, um alle benötigten Aktionen durchführen zu können.

Eine Anforderung der Thunderbird/Enigmail-Entwickler ist es (zumindest solange Enigmail weiterhin als Plugin zur Verfügung steht und nicht in Thunderbird integriert ist) keinen nativen Code zu verwenden, sondern nur externe Anwendungen aufzurufen. Die Anbindung externer Bibliotheken ist in den vorhandenen Prozessen der Software-Verteilung und -Entwicklung nicht vorgesehen. Dies ließe sich durch ein dynamisches nachladen von GpgME lösen. Allerdings werden Prozessaufrufe als einfacher wahrgenommen als GpgME in JavaScript zu verwenden.

Voraussetzungen: Eine GnuPG-Installation.

2. GpgME

GpgME bleibt die zentrale Schnittstelle für Anwendungen zu GnuPG.

Zielgruppe:// Entwickler, die mit niedrigerer Granularität GnuPG steuern wollen.

Begründung: GpgME ist die Referenzimplementation zum programmatischen Arbeiten mit GnuPG. GpgME wird bereits in verschiedenen MUA's verwendet. Höhere Abstraktionsschichten (wie QGpgME) benötigen GpgME als Grundlage.

Voraussetzungen: Unterstützung für GnuPG-Prozessaufrufe.

3. QGpgME

QGpgME wird in GpgME als Sprachanbindung integriert und bietet eine API, die sich an den Anforderungen von Qt-Anwendungsentwicklern orientiert.

Zielgruppe:// Entwickler von Qt/C++-Anwendungen, die ein eigenes Benutzerinterface implementieren.

Begründung:// Um die Möglichkeit zu haben, ein integriertes Benutzerinterface anzuzeigen, wird es weiterhin nötig sein, eine Programmschnittstelle zu bieten, die unabhängig vom Benutzerinterface ist. Hierbei wird neu sein, dass die GnuPG-Logik in QGpgME zentral bereitgestellt wird und diese Teile nicht mehr in Libkleo enthalten sind. QGpgME verwendet selbst noch zusätzlich den reinen C++-Wrapper GpgMEpp, der hauptsächlich dazu dient Ressourcenverwaltung mit C++-Mechanismen zu automatisieren.

Vorraussetzungen: GpgME, GpgMEpp

4. Libkleo

UI-Elemente für andere Qt/KDE-Frameworks-Anwendungen.

Zielgruppe:// Entwickler von Qt/KDE-Frameworks-Anwendungen.

Begründung: Libkleo wird Qt/KDE-UI-Elemente enthalten, die sowohl in Kleopatra als auch in anderen Qt/KDE-Anwendungen (beispielsweise Kontact Mail) verwendet werden können. Der Backend-Code aus Libkleo wird entfernt und nach QGpgME verschoben, um anderen Qt-Anwendungen diese API bereitzustellen, ohne sich an KDE-Frameworks und Qt-Widgets binden zu müssen. Libkleo wird zu einer reinen UI-Bibliothek für KDE-Frameworks bzw. Qt-Anwendungen.

5. Prozessaufruf von Kleopatra

Kleopatra bietet benötigte Dialoge und Nutzerinteraktionen als Kommandozeilenoptionen an.

Zielgruppe:// Entwickler von Anwendungen, die kein eigenes Benutzerinterface implementieren möchten. Referenzimplementation für Krypto-Benutzerinterfaces. Anwender.

Begründung: Wo Nutzerinteraktion nötig ist, wird Kleopatra einen Fallback anbieten, welcher über einen Prozessaufruf aktiviert werden kann. Diese Prozessaufrufe können von anderen Anwendungen verwendet werden oder bieten auch direkt "Abkürzungen" für Expertenanwender. Rückgabewerte werden durch den Return-Code des Prozesses und Ausgaben auf stdout und/oder stderr kommuniziert.

TODO: ist noch zu diskutieren. BER AH Ja ich überlege ob man das doch einfach komplett streicht. Es geht eigentlich nur um die Zertifikatsauswahdialoge und den Zertifikatserstellungsdialog. AH

Mail User Agent Anpassungen für EasyGPG

Im Folgenden wird anhand der Leistungsbeschreibung untersucht, welche API-Änderungen nötig sind, um die Ziele des EasyGPG-Auftrags in MUAs umzusetzen. Dabei wird jeweils die API für Prozessaufrufe und von QGpgME gelistet. QGpgME, da dies die höchste Abstraktionsschicht der GpgME Bibliothek darstellt und diese API die Unterstützung in GpgMEpp und GpgME impliziert. Sofern Benutzerinteraktion notwendig sind, wird ein entsprechender Aufruf von Kleopatra angeführt.

Schlüsselerzeugung

• Fall 1 Es sind weder Konto noch Schlüssel vorhanden:

• Schritt 1 Prüfung: Ob ein geeigneter geheimer Schlüssel vorhanden ist kann mit einem Prozessaufruf und mit GpgME bereits umgesetzt werden.

    Prozessaufruf: gpg --with-colons -K <E-Mail Adresse>
    QGpgME: QGpgMEKeyListJob::start(const QStringList &patterns, bool secretOnly)

Da für den Falle der Eindeutigkeit keine Nutzerinteraktion erforderlich ist entfällt hier das entsprechende Kommando (siehe Fall 3).

• Schritt 2 Schlüsselerstellung (nur ein Konto): Die Schlüsselerstellung für ein Konto ist mit bestehender API umsetzbar:

    Prozessaufruf: gpg --gen-key --batch < parameters.txt
    QGpgME: GpgMEKeyGenerationJob::generate_key(Context *ctx, const QString &parameters)

Hierbei wird in den Parametern der Schlüsselerstellung ein neuer Parameter eingeführt der GnuPG mitteilt das dieser Schlüssel auf dem OpenPGP-Webkey Service veröffentlicht werden soll. (Siehe 2.1.2 Schlüsselverteilung)

TODO: Wo wird gespeichert, welches das aktuelle Zert für eine Email-Adresse für "webkey" Verteilung ist? Wie wird das ermittelt, wenn in der Übergangsphase mehrere gültig sind? In welcher Komponente ist die Logik für die Auswahl? BER

• Fall 2 Es sind ein oder mehrere Konten, aber kein Schlüssel vorhanden:
• Schritt 1 Prüfung: Die Prüfung kann wie in Fall 1 erfolgen.

• Schritt 2 Schlüsselerstellung (mehrere Konten): Die Schlüsselerstellung mit mehreren UID's ist momentan in der API von GnuPG nicht vorgesehen und muss erweitert werden.

Dazu wird Gnupg erweitert so das es eine Komma separierte Liste an user-id's akzeptiert. Im falle von Batch --gen-key wird hierzu ein weiteres Feld "Aliases:" eingeführt um Abwärtskompatibilität zu erhalten. Die Liste wird RFC 822 Adresslisten entsprechen wobei jeweils Name und Mailbox als Bestandteile der User ID übermittelt werden. Wird kein Name sondern nur eine Mailbox übergeben wird der Name der Primary User ID verwendet.

Als Kryptografieparameter werden die Standardeinstellungen des GnuPG-Systems verwendet.

Kleopatra wird ebenso die Kommandozeilenoption --gen-key neu anbieten und eine Adressliste zur Übermittlung von Alias Optionen unterstützen. Dies wird einen vorausgefüllten Zertifikatserstellungsdialog von Kleopatra öffnen. Löscht der Nutzer hier einen Alias sorgt dies dafür das, dass dem alias entsprechende Konto nicht mit einem Schlüssel verbunden wird. Andernfalls werden die Konten nach der Erstellung mit dem neu erstellten Zertifikat verbunden. Der entsprechende Dialog wird in Libkleo implementiert.

Im Rahmen der Schlüsselerstellung wird deutlich darauf hingewiesen wo das GnuPG Heimatverzeichnis zu finden ist.

• Fall 3: Sowohl Konten als auch Schlüsselpaare sind vorhanden:

Nach dem erstmaligen Start eines MUA der EasyGPG unterstützt wird für alle vorhandenen Konten geprüft ob vorhandene Schlüssel vorhanden sind. Die Prüfung kann wie in Fall 2 erfolgen.

Kleopatra wird hierzu die Option "select-certificate=<capabilities>" anbieten mit denen eine Zertifikatsauswahl gestartet werden kann. Die Rückgabe des wertes erfolgt auf stdout. kleopatra --select-certificate=sign,secret <E-Mail Adresse> kleopatra --select-certificate=encrypt,secret <E-Mail Adresse>

TODO AH brauchen wir das Wirklich?

Die Parameter des select-certificate Arguments dient der Vorfilterung der Zertifikate und können eine Kombination von sign, certify, encrypt, authenticate, secret, openpgp und cms sein.

Der Dialog zur Auswahl wird dazu in Libkleo implementiert.

Schlüsselverteilung

Siehe Entwurf des OpenPGP Webkey Service: ([[https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-00#section-4| Web Key Directory Update Protocol]])

Die Schlüsselverteilung wird durch GnuPG durchgeführt. Dabei werden Mails die vom MUA im Prozess der Verteilung empfangen werden anhand des Content-Type identifiziert und an GnuPG zur weiteren Verarbeitung vollständig übergeben. GnuPG wiederum übergibt dem MUA Mails die automatisch versendet werden sollten.

Nötige Aktionen des MUAs werden durch den Rückgabewert

Schlüsselimport

• Fall 1 Gültiger öffentlicher Schlüssel angehangen: Ist ein gültiger öffentlicher Schlüssel angehangen kann dies anhand des Content-Type oder der Dateiendung von MUA's erkannt werden. Diese können den mit bestehender API importieren. Der Import erfolgt dabei im Hintergrund.

    Prozessaufruf: gpg --import <Zertifikatsdatei>
    QGpgME: QGpgMEImportJob::exec(const QByteArray &certData)

Vom Vertrauensmodell wird dieser Schlüssel so angesehen als käme er von einem öffentlichen Schlüsselserver.

• Fall 2 Beim Empfang signierter E-Mails automatisch den Schlüssel herunterladen:

Dieser Fall wird in GnuPG bereits durch die Konfigurationsoption auto-key-retrieve abgebildet. GnuPG muss hier erweitert werden um bei Aktivierung der Option die verschiedenen Möglichkeiten des Schlüsselabrufs zu unterstützen. Dies könnte Beispielsweise dadurch erfolgen das sich die auto-key-locate Option auch auf auto-key-retrieve auswirkt. Für EasyGPG prüft der MUA über gpgconf ob

Eine Anzeige des Imports erscheint hier nicht Wünschenswert da die fehlschlagende Signaturprüfung klarstellen sollte das kein öffentlicher Schlüssel gefunden wurde und somit den Negativfall erkennbar macht.

• Fall 3 Verfassen einer verschlüsselten Mail:

Ist die auto-key-locate Option entsprechend für EasyGPG Gesetzt lässt sich dieser Fall durch das Kommando locate-key abgedeckt. In GpgME wird dies durch ein keylisting mit der Kombination der Modi "extern" und "local" implementiert. Für QGpgME wird hierzu neue API in Form eines LocateKeysJob implementiert:

    Prozessaufruf: gpg --locate-key <email>
    QGpgME: GpgME::KeyListResult QGpgMELocateKeysJob::exec(const QStringList &patterns);

Bei Mehrdeutigkeiten wird UI zum auflösen des Zertifikats benötigt. Implementierende MUA sollten automatisch das Zertifikat mit dem höheren Vertrauen auswählen. Dennoch kann es nötig sein die Entscheidung zur Zertifikatsauswahl abzufragen. In diesem Fall kann der bereits im Abschnitt Schlüsselerzeugung (Fall 3) erwähnte Zertifikatsauswahldialog verwendet werden (kleopatra --select-certificate)

Das Vertrauen in den Schlüssel wird soll durch eine Gültigkeitsanzeige dargestellt werden. Wird das TOFU Vertrauensmodell verwendet sollen in diesem Dialog zusätzlich entsprechende Informationen angezeigt werden.

Die Referenzimplementation in Libkleo wird die Anzeige der TOFU Informationen und einen Status Indikator enthalten.

• Fall 4 Öffentlicher Schlüssel aus lokaler Datei:

Ist beim Versenden einer Mail für einen Empfänger kein Zertifikat vorhanden soll ein MUA dies erkenntlich machen. z.B. durch einen Fragezeichen oder X hinter der Empfängeraddresse.

In diesem Fall kann beispielsweise durch klick auf den Status der Zertifikatsimportdialog geöffnet werden.

    Prozessaufruf: gpg --import <key-file>
    QGpgME: GpgME::ImportResult QGpgME::QGpgMEImportJob::exec(const QByteArray &keyData)
    Kleopatra: kleopatra --import

Kleopatra wird dabei den Dateidialog selbst anzeigen und das Resultat des Imports anzeigen.

• Fall 5 Import über URL Verlinkung:

Da das aufrufen über URL's außerhalb der MUAs passiert ist hier kein Handlungsbedarf für Implementierende MUAs. Dies ist durch Platformintegration der Gesamtlösung zu erreichen damit genutzte Browser für die Zertifikats MIME Typen bzw. Dateiendungen ein öffnen mit Kleopatra / GPA oder ein öffnen mit GnuPG anbieten.

Im Rahmen des Gpg4all Projektes wurde für Gpg4win die Nutzung von Dateizuordnungen inklusive Registration von MIME Typen in Windows hinzugefügt. Unter GNU/Linux Systemen ist der übliche weg sich zu registrieren durch Installation von "Desktop" Dateien. Dies wird von Kleopatra bereits ausgeführt.

GnuPG sollte sich zusätzlich mit "Desktop" Dateien im System für diese MIME Typen registrieren. Bzw. Unter Windows dies bei der Installation des Basispaketes durchführen.

Sollte dies nicht im Hauptstrom von GnuPG integriert werden können kann dies durch eine Paketierung bzw. Paketierungsempfehlung gewährleistet werden.

Damit dieser Mechanismus funktioniert muss der entsprechende Server jedoch den korrekten Content-Type application/pgp-keys senden.

Schlüsselverwaltung

• Wechsel von Vetrauensmodellen:

Der Wechsel von Vertrauensmodellen wird über gpgconf ermöglicht Kleopatra stellt einen generischen Konfigurationsdialog der gpgconf Optionen zur verfügung und ermöglicht so die Änderung.

    Prozessaufruf: gpgconf --change-options
    QGpgME: QGpgMENewCryptoConfigEntry::setStringValue(const QString &str)

Der Konfigurationsdialog für GnuPG von Kleopatra steht als Plugin zur verfügung und kann als KCModule geladen und in Qt Anwendungen eingebunden werden.

• Der Erstempfang von Mails unbekannter Adressen muss angezeigt werden:

Beim Erstempfang von unbekannten Adressen wird das Zertifikat automatisch heruntergeladen. Siehe (Schlüsselverwaltung Fall 2), kann kein vertrauenswürdiges Zertifikat gefunden werden wird dies sich auf die Gültigkeit der Signatur auswirken gpgme_signature_t->validity.

Auf der Kommandozeile werden die TOFU Informationen durch eine Statuszeile TOFU Trust zurückgegeben.

Der MUA muss wie bisher die Resultate der Signaturprüfung auswerten und zur Anzeige bringen.

• Schlüsselsauswahl bei Mehrdeutigkeiten:

Siehe Fall 3

• Abgelaufene Schlüssel von Kommunikationspartnern müssen ersetzt werden:

Soll ein abgelaufener Schlüssel verwendet werden wird durch GnuPG ein neues locate-key durchgeführt ohne Lokale quellen zu berücksichtigen. Dazu wird entweder eine neue Konfigurationsoption bspw. auto-key-refresh eingeführt oder das verhalten von auto-key-retrieve entsprechend geändert.

• Abgelaufene eigene Schlüssel müssen ersetzt werden:

Ist der mit einem Konto verknüpfte Schlüssel abgelaufen oder droht innerhalb der nächsten 10 Tage abzulaufen wird eine neue Schlüsselerstellung durchgeführt und die entsprechenden Konten mit dem neuen Schlüssel verknüpft. (Siehe Schlüsselerzeugung)

• Backup der jeweilige MUA muss die Möglichkeit bieten Schlüssel auf einfache Weise zu sichern und wiederherzustellen.

Die Umsetzung dieser Anforderung wird dem jeweiligen MUA überlassen. Das wiederherstellen wird bei der sonst erfolgenden Zertifikatserstellung angeboten. Zum sichern wird auf den Ort des GnuPG Heimatverzeichnisses hingewiesen. Das Komplette Verzeichnis sollte gesichert werden.