161
edits
m |
(→UID) |
||
(8 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
This page should be used to discuses the XEP's and implementation of [https://xmpp.org/extensions/xep-0373.html XEP-0373: OpenPGP for XMPP] | This page should be used to discuses the XEP's and implementation of | ||
[https://xmpp.org/extensions/xep-0373.html XEP-0373: OpenPGP for XMPP]. If you | |||
think there are some things which are wrong, feel free to contact me. | |||
= | = Fundamentals = | ||
There are different people with different background knowledge about OpenPGP / | |||
GnuPG. XMPP OX should be able to integrate OpenPGP in clients which hides the technical | |||
details of OpenPGP to the user. But, XMPP OX should also useable for technical | |||
people which may have a OpenPGP Smartcard or a Token. | |||
At the end of the day, the different client applications should be able to share information and messages. | |||
== OpenPGP via GnuPG == | == OpenPGP via GnuPG == | ||
There are two use cases to create the key material. | |||
Users with technical background may have his own key or prefer to generate his | |||
own key via GnuP. This is '''not''' a question about trust the gnupg application or trust the xmpp | |||
client application, this is more a habit of the user. | |||
Non-technical users may prefer that the XMPP client acts on behalf of the user | |||
and will generate the key material. Even, '''without''' asking the user a lot of questions. | |||
=== Generating key === | |||
Basically both use cases are fine and the best way is, to let the user decides | |||
which he would like to use. Generate a Key via gpg can be done by | |||
<pre> | |||
gpg --full-gen-key` | |||
</pre> | |||
Generating the key within the XMPP client is up to the developer. | |||
It's recommend to have such a option, to make the on boarding for non technical | |||
people easier. | |||
=== UID === | |||
There may people which prefer one key pair for E-Mail and one dedicated key pair | |||
for XMPP. There may also people ( independent of this knowledge ) which prefer | |||
to have one key pair for all "services". In the most cases, at least I know, it | |||
will be done via the OpenPGP UID. | |||
The user should be able to manage his key pair. Also, the XMPP Client should be | |||
able to assistant, by adding a UID for the XMPP Account. | |||
A key can look like this: | |||
<pre> | <pre> | ||
pub rsa2048 2020-05-01 [SCEA] | |||
6D740FE2B1D55DCD74CAAD95AC1A1629095EEDAE | |||
uid [ unbekannt ] xmpp:alice@domain.tld | |||
</pre> | </pre> | ||
or like this: | |||
<pre> | <pre> | ||
pub rsa4096 2019-05-14 [SC] [verfällt: 2021-05-13] | |||
A602F76893F138B4A8EFDDD5C2DC916F35751C24 | |||
uid [ ultimativ ] Name <mailbox@domain.tld> | |||
uid [ ultimativ ] Name (FSFE) <mailbox@domain1.tld> | |||
uid [ ultimativ ] Name (devLUG) <mailbox@domain2.tld> | |||
uid [ ultimativ ] xmpp:user@domain.tld | |||
uid [ ultimativ ] xmpp:xmpp:alice@domain.tld | |||
sub rsa4096 2019-05-14 [E] [verfällt: 2021-05-13] | |||
sub rsa4096 2019-05-14 [A] [verfällt: 2021-05-13] | |||
</pre> | </pre> | ||
* If there is a private key with an existing UID for the account, just use it. | |||
* If there is a private key, but there is no private key with a UID of the account, ask the user to add a UID | |||
* If there is no private key, create one for the XMPP account. | |||
<pre> | |||
gpg --quick-add-uid <FINGERPRINT> xmpp:user@domain.tld | |||
</pre> | |||
=== Export a public key === | |||
Sharing the public key is also a question about privacy. If the user has only | |||
one key pair which is used by XMPP, only. There may not many problems to share | |||
those key via XMPP PEP. If a user have a key with more UIDs and is using the | |||
WoT, the user may prefer which information should / shouldn't included within | |||
the public key. | |||
By default, the public will include Name, E-Mail-Addresses, XMPP Addresses of | |||
all OpenPGP UIDs in the public key. The public key also includes the signatures. | |||
If the user prefer to publish his public key with minimal information, he can do | |||
so by | |||
<pre> | |||
gpg --export --export-options export-minimal --export-filter 'keep-uid=uid =~ xmpp:local@domain.tld' MY_FINGERPRINT > /tmp/test.gpg | |||
</pre> | |||
In this cases, just the UID with the xmpp-Address will be extracted and no | |||
signatures. | |||
I think it is important, that the user can decides if he creates the public key | |||
export and push int on PEP or if the XMPP Client ( in think in most cases the | |||
full export) should do it. | |||
=== Trust-model === | |||
The user should decides which trust model the user prefers. | |||
Users which just would like to use it and do not crate much of trust | |||
fingerprints, may should use trust-model TOFO (Trust On First Use). | |||
Option trust-model and tofu-default-policy in .gnupg/gpg.conf. | |||
Users which prefer trust-model pgp should be able to use the WoT (default in gnupg). | |||
I think the WoT is '''not''' nonsense. There is maybe an issues, that not all clients supporting a friendly way to sign key and publish it. | |||
One important part of the asymmetric cryptography is the exchange of the public | |||
key and verify those key (certificate - singing of a key). With the singing of | |||
the key and building the gnupg's trust db, I think the WoT is a powerful and | |||
helpful concept to verify the keys of other persons. | |||
The main problem I see, there is less interest and the second problem, lot of | |||
clients (not only XMPP client) don't integrate a nice UI for the users. Using | |||
the WoT requires 4 steps: | |||
* get the public key of the contact | |||
* verify the fingerprint of the public key | |||
* signing the public key | |||
* sent the signed public key encrypted back to the contact | |||
The 2nd step is the step which has to be managed by the human. I think all | |||
other steps can be done by XMPP Clients. | |||
=== Sharing the private key === | |||
This topic is not easy. I think, it should also be optional at all. In some | |||
cases it may helpful and a nice feature, and in other cases it won't work at | |||
all. | |||
Sharing the private key is required to support multi devices. | |||
Lot of non technical person moved to an "smartphone only mode". There are a lot | |||
of people which are using IM / Mail only on the smartphone. For those people, | |||
there is no need to share the private key. It would be included in the backup. | |||
There are also people which are using a smartphone, Desktop and Laptop and don't | |||
won't to care about key management. For those people the sharing of private key | |||
on PEP is a very nice feature. | |||
For people using Smartcard / Token, it don't make sense to share the key. The | |||
key is on a hardware device and they just need the public key and the token. | |||
= Discussions = | = Discussions = | ||
== Fundamentals == | |||
I tried to write the Fundamentals just as possible use cases. This don't mean that the XMPP Clients should implement all. | |||
But, we should make sure, that we are able to support the use cases as much as possible, but it shouldn't be necessary to implement all. | |||
(For example, it would be difficult to implement thinks like "--export-options export-minimal --export-filter", I won't implement it - but we should be able to work with it, when the user would like to gpg to export it) | |||
* Examples | |||
If a XMPP Client has been implemented that it will check the PEP of the contact, first. The Clients OX will not work, if there is no public key. | |||
This could be a problem, if others client doesn't require the publishing of public key on PEP. | |||
If the XMPP Client doesn't check the UIDs / Sub-Key of the Mainkey, it could be an issue if there key looking different. | |||
== History of version of public key == | == History of version of public key == | ||
Line 145: | Line 282: | ||
??? | ??? | ||
= Issues = | |||
Issues found during implementation and testing. | |||
I'm trying to work on some [https://codeberg.org/Anoxinon_e.V./xmppc xmppc], [https://codeberg.org/xmpp-messenger/eagle eagle], [https://github.com/profanity-im/profanity profanity] to implement the use of OpenPGP in OX. | |||
For testing I'm using the OX Plugin of [https://gajim.org/ gajim] also. This chapter I will write which "issue" I found, which should be clarified. | |||
== Key-Lookup == | |||
The first and important part is the key-lookup of the public key. I think this would be done for all clients in the same way? | |||
* get all public keys which are stored in the local keyring | |||
* check if the key is not revoked, not disabled, not expired | |||
* check for the key / subkey with capability [E] - not revoked, not disabled, not expired | |||
* check all UIDs for the key | |||
* look for a UID with the XMPP-URI | |||
This key should be used to encrypted the message. | |||
== encrypt-to-self == | |||
Not sure what should we do with it? Currently, I implemented that the message it encrypt for recipient and sender. | |||
= Links = | = Links = |
edits