161
edits
Difference between revisions of "Tech pages/OX"
Jump to navigation
Jump to search
→UID
m |
(→UID) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 6: | Line 6: | ||
There are different people with different background knowledge about OpenPGP / | There are different people with different background knowledge about OpenPGP / | ||
GnuPG. XMPP OX should be able to integrate in clients which hides the technical | 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 | details of OpenPGP to the user. But, XMPP OX should also useable for technical | ||
people which may have a OpenPGP Smartcard or a Token. | 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. | |||
messages. | |||
== OpenPGP via GnuPG == | == OpenPGP via GnuPG == | ||
There are two use cases to create the key material. | There are two use cases to create the key material. | ||
Users with technical background may have his own key or prefer to | 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 | 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. | 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 === | === Generating key === | ||
| Line 28: | Line 30: | ||
</pre> | </pre> | ||
Generating the key within the XMPP is up to the developer. | Generating the key within the XMPP client is up to the developer. | ||
It recommend to have such a option, to make the on boarding for non technical | It's recommend to have such a option, to make the on boarding for non technical | ||
people easier. | people easier. | ||
| Line 39: | Line 41: | ||
The user should be able to manage his key pair. Also, the XMPP Client should be | The user should be able to manage his key pair. Also, the XMPP Client should be | ||
able to assistant, by adding a UID. | able to assistant, by adding a UID for the XMPP Account. | ||
A key can look like this: | A key can look like this: | ||
| Line 63: | Line 65: | ||
</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 === | === Export a public key === | ||
| Line 82: | Line 91: | ||
In this cases, just the UID with the xmpp-Address will be extracted and no | In this cases, just the UID with the xmpp-Address will be extracted and no | ||
signatures. | 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 === | === Trust-model === | ||
| Line 95: | Line 107: | ||
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. | 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 225: | 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 = | ||