161
edits
Difference between revisions of "Tech pages/OX"
Jump to navigation
Jump to search
→UID
(→UID) |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 68: | Line 68: | ||
* 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 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. | * 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 87: | 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 100: | 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 230: | 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 = | ||