Difference between revisions of "Tech pages/OX"

Jump to navigation Jump to search

Tech pages/OX (view source)

Revision as of 08:12, 6 June 2020

7,476 bytes added ,  08:12, 6 June 2020
m
no edit summary
m
m
(7 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.


= Basics =
= 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.


* Generate a Key
=== 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>
<pre>
gpg --full-gen-key
gpg --full-gen-key`
</pre>
</pre>


* Export a public key just with one UID
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>
gpg --export --export-options export-minimal  --export-filter 'keep-uid=uid =~ xmpp:local@domain.tld' MEIN_FINGERPRINT > /tmp/test.gpg
pub  rsa2048 2020-05-01 [SCEA]
      6D740FE2B1D55DCD74CAAD95AC1A1629095EEDAE
uid       [ unbekannt ] xmpp:alice@domain.tld
</pre>
</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.
=== 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 278:


???
???
= 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 =
DebXWoody
161

edits

Retrieved from "https://wiki.xmpp.org/web/Special:MobileDiff/13092...13102"

Navigation menu