[Standards] XEP-0373: Retracting public keys
flo at geekplace.eu
Thu Jul 6 20:33:52 UTC 2017
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
> 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.
> 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."?
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 642 bytes
Desc: OpenPGP digital signature
More information about the Standards