Difference between revisions of "Tech pages/OX"

Jump to navigation Jump to search
2,825 bytes added ,  15:12, 22 June 2020
(5 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 119: Line 123:
The 2nd step is the step which has to be managed by the human. I think all
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.
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 249: 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 =
161

edits

Navigation menu