On 07.01.2016 17:47, Sergei Golovan wrote: > Hi Peter, > > On Thu, Jan 7, 2016 at 6:07 PM, Peter Saint-Andre <stpe...@stpeter.im> wrote: >> On 1/7/16 5:09 AM, Sergei Golovan wrote: >>> >>> Hi Florian, >>> >>> On Wed, Jan 6, 2016 at 3:32 PM, Florian Schmaus <f...@geekplace.eu> wrote: >>>> >>>> Hello everyone, >>>> >>>> The current state of the XEP, which we gave the short name 'OX' (OpenPGP >>>> for XMPP), can be found rendered at >>>> >>>> http://geekplace.eu/xeps/xep-openpgp/xep-openpgp.html >>> >>> >>> Another issue arises when we look at the public keys announcement >>> via PEP and try to implement this future XEP for groupchat messages. >>> The problem is that PEP doesn't work for MUC at all. There is a >>> deferred experimental XEP-0316 (MUC eventing protocol), though it >>> isn't implemented anywhere as far as I can see. >> >> >> The new MIX proposal is essentially PEP-like: >> >> http://xmpp.org/extensions/inbox/mix.html >> >> That is, public keys would just be another node in a MIX conversation. > > Okay then, let's replace the reference to XEP-0045 by one to the new XEP.
OX works fine with non-anonymous rooms, since you can query every participant for its key. Using OpenPGP in semi-anonymous rooms is questionable, since the key would leak some amount of identity information, and if you really would want to use it, then en extension could be created which makes the keys available amongst the participants of semi-anonymous rooms. > > The old XEP-0027 also has the following advantage against the proposed one: > since the key info in XEP-0027 is distributed by presence updates, all parties > interested in using OpenPGP automatically have this key info. In the proposed > XEP one has to explicitly ask every roster item and every MIX room member > to get his key (or to find out that there's no key). Most people in the XMPP community, including me, believe that "shove it into presence" paradigm isn't the right approach and should be used any more, as it leads to overloaded presences and adds additional overhead to the already chatty presence mechanism. This is the reason Entity Capabilities and PEP was developed. PEP provides the same features as if the information was put in the presence plus much more advantages. You don't have to query every roster item to get the key. > Also, what to do if a user have some keys published and currently is logged > in using a client which knows nothing about OpenPGP (and posiibly nothing > about pubsub at all)? His contact can still get this published key and send > an encrypted message which will never be decrypted (and likely will never > be noticed because it has no body and no recognizable message subelement). Yes, if the recipient doesn't use MAM and one of his clients does not support OX, then messages could get lost. The only solution to mitigate this would be to include a dummy <body/> which tells the recipient that this is an encrypted and signed messages. I think that it makes sense to include a rule or at least an implementers advice in the XEP about this. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
