[Standards] OX (OpenPGP for XMPP): A new OpenPGP XEP

Florian Schmaus flo at geekplace.eu
Fri Jan 8 09:25:54 UTC 2016


On 07.01.2016 17:47, Sergei Golovan wrote:
> Hi Peter,
> 
> On Thu, Jan 7, 2016 at 6:07 PM, Peter Saint-Andre <stpeter at 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 <flo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160108/cc9c5194/attachment.sig>


More information about the Standards mailing list