2 Jun
2026
2 Jun
'26
7:30 p.m.
As it's written in the specs, I think the challenge protocol can be
abused to leak a user's presence, because any device associated to the
target user *MUST* send a message to the entity who requested the
challenge, as soon as it receives it.
This would violate RFC 6121's guarantees to not leak the user's network
availability to an entity who's not authorized to know about it.
So, I'm wondering if we could instead have the identity verification be
a secondary optional method of verification, and have something like a
signature of the JID (signed by the XID) in the user's PEP node, that
the user themself HAVE to re-sign once every so often, like a month or
week to ensure it remains valid, so that old hosts cannot impersonate
users with stale signatures.
On 6/2/26 5:36 PM, Goffi wrote:
Le mardi 2 juin 2026, 17:06:27 heure d’été d’Europe
centrale Marvin W. via
Standards a écrit :
Hey,
I am a little confused about what is the intended scope of a XID, that
is, what it is meant to identify? A device/resource? An entity? A user?
Multiple users? A human?
An entity (which can be a person, a bot, a group of
human, whatever), but not
a device.
If we are fine with binding a XID to a specific
device/resource, we
could "just" use the OMEMO public key for it. Then binding the XID to a
specific user in a cryptographically sane way would just be the same
issue as doing that for OMEMO (which while not entirely solves, has a
lot of work put into it) and there would be no additional identity or
key management tasks.
OMEMO is per-device, it doesn't work here. It's also
far more complicated to
implement. OX could be used, but the key sharing mechanism is not specified
anyway, and again it's more complicated to implement the whole thing (and it's
not widespread). The current implementation is relatively easy for most
clients, as Ed25519 is already used for OMEMO.
This reminds me of something I had in mind for
reviving XEP-0174:
adding a TXT key that carries a signature of other parts of the mDNS
records, so that one can discover that a known OMEMO contact is nearby
and send messages to them directly rather than through the server.
One of the main
purpose of this proposal is to have a ID working for
serverless, on which I'll be working soon. I've chosen something easily
mappable to LibP2P's Peer ID.
Best,
Goffi
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org