161
edits
Line 87: | Line 87: | ||
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 103: | ||
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. | |||
= Discussions = | = Discussions = |
edits