On 01.07.2017 22:55, Philipp Hörist wrote: > As im working on a implementation on this, and coming from OMEMO, i > noticed that the case of retracting keys is not handled at all.
Right, it was a deliberate decision not to specify it for the first version(s) of the XEP. Retracting keys is hard, it opens a can of worms. But of course we should discuss it and possibly write the outcome of the discussion into the XEP(s). > Questions that arise are: > > Lets say i have a public key of one contact and my client goes online > > 1) what if i get no PEP event with a public key. does that mean > anything? how should we react?> > 2) what if i get a PEP event with a public key different to the one i > was using until now? should i untrust the not anymore distributed key? > > OMEMO has the same use case, as it also distributes keys via PEP, i > think its also not exactly written down there, but over the time we have > a convention that goes as follows > > 1) > No PEP event means nothing, we still encrypt to the valid keys we have. > This is because Server implementation of PEP are handling stuff differently > Some send only PEP events if the contacts are online > Some have no persistent PEP > > So from the fact that we didnt receive a PEP event, we can conclude > exactly nothing, and certainly not that our contact wants to invalidate > his published key. Completely agree. > 2) > All public keys we have from a contact that are not in the PEP event we > just received are marked as untrusted immediately That is where it starts to get tricky. Do you also mark previous messages send with the now vanished key as potential not authentic? What does "untrusted" mean in that case? What would the user do with that information? Why not simply say "OK, I'm going to use the new key(s) from now on."? > 3) > any device that comes online has to test if the correct public key is > published, and if not, it must publish the correct one immediately. That is fine for the "one keypair for all devices of a user" approach. While this is my favourite approach, the one I think OpenPGP/XMPP for the masses could likely look like, we should leave the door open for approaches involving multiple keypairs and/or subkeys. Thanks for your feedback. Much appreciated. FYI: I've an XEP-0373/-0374 (aka. OX) implementation for Smack in the queue. I hope to finish it after this year's GSOC, And I would be happy if we could test our implementations for interoperability. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
