161
edits
(→UID) |
|||
(11 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 == | |||
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> | |||
pub rsa2048 2020-05-01 [SCEA] | |||
6D740FE2B1D55DCD74CAAD95AC1A1629095EEDAE | |||
uid [ unbekannt ] xmpp:alice@domain.tld | |||
</pre> | |||
or like this: | |||
<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> | |||
* 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 = | |||
== 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 14: | Line 166: | ||
A public key can be changed for | A public key can be changed for | ||
* Adding or removing UIDs | * Adding or removing UIDs - No need to have a version, just need the current public key | ||
* Adding or removing (revoke) Subkeys | * Adding or removing (revoke) Subkeys - No need to have a version, just need the current public key | ||
* Change the expiration date | * Change the expiration date - No need to have a version, just need the current public key | ||
* Adding Key signatures | * Adding Key signatures - No need to have a version, just need the current public key | ||
I think there is no need to provide a history. | I think there is no need to provide a history. | ||
Other use cases which we should check? | |||
== Key-lookup / GnuPG's Keyring / Homedir == | == Key-lookup / GnuPG's Keyring / Homedir == | ||
Line 33: | Line 187: | ||
In this example there is a UID for the E-Mail and an additional UID with the XMPP-URI as Name (`gpg --quick-add-uid`). | In this example there is a UID for the E-Mail and an additional UID with the XMPP-URI as Name (`gpg --quick-add-uid`). | ||
I guess, most of the time | I guess, most of the time the user has just one key per account. It could be, that a user has one key for his Desktop and one key for his laptop. | ||
There is also the possibility - I didn't try yet - to create two subkeys [E] and have one key stored on the Desktop and one on the laptop. | There is also the possibility - I didn't try yet - to create two subkeys [E] and have one key stored on the Desktop and one on the laptop. | ||
Line 49: | Line 203: | ||
There are two [E] subkeys. | There are two [E] subkeys. | ||
* We shouldn't care how the user receives the public key. This should be via Keyserver, WKD, E-Mail or XMPP PEP. | * We shouldn't care how the user receives the public key. This should be done via Keyserver, WKD, E-Mail or XMPP PEP. | ||
If I read a Mail via Mailinglist and get the public key via WKD, it would be | If I read a Mail via Mailinglist and get the public key via WKD, it would also be possible to use those key for XMPP. Also, if I'm going to update the public keys. | ||
This is important for the WoT and to make sure that a key is valid, because of new | This is important for the WoT and to make sure that a key is valid, because of new signatures of the public key. | ||
* The user should be able to use his own key. For instance, if the user would like to use his OpenPGP Smartcard / Token for E-Mail and XMPP. | * The user should be able to use his own key. For instance, if the user would like to use his OpenPGP Smartcard / Token for E-Mail and XMPP. | ||
* The user should be able to manage his public keys like all other keys GnuPG's `--update-trustdb`and `refresh-keys` | * The user should be able to manage his public keys like all other keys GnuPG's `--update-trustdb`and `refresh-keys` | ||
* The user should be able to use WoT pgp or tofu | * The user should be able to use WoT pgp or tofu or tofu+pgp mode | ||
* The WoT is important for messages which has been signed or signcypted | * The WoT is important for messages which has been signed or signcypted | ||
I think it will be better to use the same keyring and homedir like GnuPG | I think it will be better to use the same keyring and homedir like GnuPG is using. | ||
= XEP Review = | = XEP Review = | ||
Line 89: | Line 243: | ||
<rpad>C1DHN9HK-9A25tSmwK4hU!Jji9%GKYK^syIlHJT9TnI4</rpad> | <rpad>C1DHN9HK-9A25tSmwK4hU!Jji9%GKYK^syIlHJT9TnI4</rpad> | ||
This is not the The RFC-4648 - The Base 64 Alphabet defined in: https://tools.ietf.org/html/rfc4648#section-4 | This is not the The RFC-4648 - The Base 64 Alphabet defined in: https://tools.ietf.org/html/rfc4648#section-4 (!%^). | ||
<pre> | <pre> | ||
Line 100: | Line 254: | ||
static const char* rfc_4648_base64_pad = '='; | static const char* rfc_4648_base64_pad = '='; | ||
</pre> | |||
Example: | |||
<pre> | |||
rpad: 6mWBrmp77XWx/srrjVNwS32eXf5 | |||
rpad: B1LXIxB9xPZwzD5mXr6jiIiPyr0FpworMt5GpniK8JnyRVVVnWJzYbyS6kVMEbTmxDsgmwCOV7dpczyl1SiBO1DhzKhdxHCW6gsMH1nyAOC9dHW/JJM2L/fklEge4d+ktrC0 | |||
rpad: ebeJpeWb4KLt | |||
rpad: P7ZgMDX6b4gFN4TN0/VSl6315bgvXxnHz2+AVmSVZVzl57ztMVQ5NtRZb2yVEZA | |||
rpad: BQCJ/1e8iY2nJTW0RdP8bhg9NOaNZr/O/xvgTYCY+t0zFpEJMBaCY9sKWKfFePtB3BLva2HQ17zw2kFVDn50Kp8n+VKhctSfwofda51NQq8Giug+A5057Ma9NSjMZt | |||
rpad: PyOyTdHT2WiXeTuevJdS5yQLzLtxrf3g6GbN4qKrzPKLgQMGOo8cd3bayBO9o1yZHy341KoCtDMhyhwhDl/aMTXNh2bPrjIpeAJ6xDLjL6Ph/OB32GMTvMqtpy9vbygXo3 | |||
</pre> | </pre> | ||
Line 117: | 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