XSF Discussion - 2020-06-05

Ge0rG: Where is the last official Yaxim .SVG icon? (cc rion)

rion: Neustradamus: https://github.com/yaxim-org/yaxim/blob/master/asset-graphics/yak/yak-front-grass.svg

FMUC wise, how can the state of federation be reflected to users in the chat? Currently the only way as a user to tell if you've lost federation is that you see people leave the chat, it seems?

https://xmpp.org/extensions/xep-0310.xml mayhaps?

Thanks. A quick reading does not make me confident that I get its meaning, but it seems at least partially related.

Will look into it further

Guus, i would say a user does not need to know that

lovetox: why is that?

because its nothing that should happen regulary, its a technical detail of the protocol and infrastructur

you dont get a whatsapp message when one of their server goes offline for a minute

service is not working, i guess the user will notice that if he cant see any people in a MUC anymore

thats all he needs to know, and bug his admin afterwards

I think you're making assumptions there about the nature of the deployment. ✏

FMUC is typically deployed places where it is something that may happen frequently, and that the users may well want to know.

Guus: From memory, we exit the users from the room with a show saying why.

What Kev said, and: thanks Kev.

I don't *think* we inject a system message at the same time, but I might misremember that bit.

I am compiling a rather long text of XEP feedback - not very structured at the moment, but I guess I should post it somewhere

I've had a TODO to look at FMUC for ages, but as no-one else was implementing it it dropped way down my list.

Sorry Guus.

No worries, that's only to be expected.

I'm grateful for the feedback you've been giving me recently

classic IRC netsplit

lovetox, it happens "all the time" on IRC

and I’m not sure if FMUC can replay history, in which case you’d very well need to know what’s going on ✏

The history sync is awkward. I haven't figured that out in our implementation.

MUC-to-MUC MAM?

Matrix.

Not until start trying to merge those histories

Matrix in broken.

Guus: Is it that tricky? It's mostly the same as client history.

Kev: which I've never implemented myself either. 😁

Kev: Gets tricky if there's history on both sides that the other doesn't have?

What I wonder about is injection history mid-session, when a room with existing history and ongoing chat suddenly needs to interweave history from another source that joined.

Here little bit feedback / remarks / question for XMPP-OX: https://wiki.xmpp.org/web/Tech_pages/OX

DebXWoody, after reading that my motiviation to implement OX is near zero

so you are saying there is a chance? >:)

i tell you what i implement

- Client generates Key, user can't bring his own - Key has no password - There is only one public key accepted per contact, and the only source of it is PEP

DebXWoody, read it, pubsub get will get you the latest published item on a node, which is the latest version of the key

Is it possible with pgp to change the expiry date on a key without changing the fingerprint?

yes

yes

how does that work?! surley it has to be protected someway

lovetox, it's a signed packet added to the keyring

signed by who?

signed by the master key

and who signes the expiry date of the master key

or does the key i generate sign the packet itself

basically yes

Ok, yeah then let me add to that list - No expiry date on keys

yes expiries are typical not useful for the average user

i like OX i think its less complicated than OMEMO and i dont really need the benefits of OMEMO

depends

lovetox, why near zero? I know what has been implemented (at least a little bit). I think your approach is not wrong. I see some pros on your implementation, but also some cons.

openpgp provides a lot of freedom

but i fear that people go into that with their own ideas how openpgp in xmpp should work

and the XEP basically lets many things open

and it could happen that OX is grated by different opinions which try to move it toward their choice

and i fear this will make it not interoperable

which would be sad, because I think the existing openpgp ecosystem shows that it is interoperable while allowing a high degree of freedom

flow only if you have a client that supports all the freedom

no I don't think so

which makes it less likely to implement

MUAs shows that this is possible

lovetox, I think we should fine a mix of it, this is the reason why I started this wiki page. I would like to use XMPP with my Nitrokey, this is basically the reason why I prefer to use my own keyring also.

MUAs? whats that

mail clients

For me OX has to be implemented in a way that it is as invisible and easy to use as OMEMO

yes

sure

yeah but that rules some things out for me that people that use PGP do daily

probably, but does that mean that your code will not be able to exchange openpgp secured messages with those people?

- typing in a password daily to unlock the key - depending on PGP trust states (not sure about that but my feeling is i want to have my own trustmanagement rather than what pgp offers)

please completely ignore the web of trust

its nonsense ✏

its not about sending messages flow, its about sharing your secret key with other devices

so you want a dedidcated key for xmpp? that's fine

keyring even

there are the people that want to use their own key and dont trust the application (hence want to use stuff like PGP Agent)

and this needs totally different development approach

sure, those are then probably users that will not be happy with your implementation, if it does not allow for it

yeah but that also means, if some clients support this, some not

they cannot work together

why not?

This is why I would like to talk about it.

we maybe first have to define "this", but…

because when you put a password on your key, and i have no GUI where you can put in that passwod, that means you cannot use both clients with the same account

lovetox, how does your no password approach work with multiple devices?

lovetox, I think pinentry will do it.

i dont undestand the question flow

how is multiple device related to a password

lovetox, do you want to support multiple devices?

of course

lovetox, how does the onboarding work with your no password approach?

how does a new device get a hold of the secret key material?

are you talking about your AES backup code?

AES encrypted secret key in the PEP node

?

im not talking about that, that is fine

ok, but then where is the problem?

but maybe you remember, you can put a password on a PGP key on creation, and then i have to additionally encrypt it with AES

if you want to store the key material unencrypted locally, that is your choice

(as developer)

how an openpgp implementation obtains the secret key material is outside the scope of OX and OpenPGP

so I don't see how this could cause that some clients are not able to work together

I see other potential issues maybe

but not this ✏

how is that out of scope, if you describe in your XEP how the secret key is obtained and even how it has to be encrypted

that is only to fetch the secret key material if you don't have it

but once you have it, you would usually store it locally

I think this is not fully clearly defined.

ok so if you dont describe this, and i assume all material that i decrypt is not additional secured, and other implementation dont assume that and create only passworded keys

then both clients are incompatible

regarding secret key sharing

now you have really confused me

if the secret key material is shared via the PEP node as specified in xep373 § 5.4, then I'd argue it is clear for the implementations how the data should look like, and especially that it must be encrypted

storing unencrypted openpgp secret key material in a PEP node would be not ideal

yes obvious

but implementing this yields not necessarily a useable key

and why is that?

because PGP keys can be password protected

yes, but the transferable key format (rfc4880 § 11.2) is unencrypted, and that is what xep373 § 5.4 specifies

would be pretty silly to have another *optional* encryption layer here ✏

ahh i didnt know that

glad we could clarify that :)

this is another problem with the XEP for me, you refering to openpgp rfcs its fine, but you should add examples how one can get these transferable formats from gpg

i think we can assume nobody that implement OX will write its own rfc4880 implementation

hopefully not, but you need some knowledge about the used building blocks ✏

btw, I would recommend using sequoia pgp instead of gpg

flow, "please completely ignore the web of trust" why?

Well that's up to the client, and I don't think it actually impacts how it's used on XMPP at all.

As long as some more technical users don't force that on others for no reason

DebXWoody, it's also just possible for a client to use a freshly created keyring just for XMPP usage, and then a tech user can sign that key with their own if they really want to

It makes it easier for the client because it can use its own assumptions and doesn't have to plan for all the various differences they can find in the real world ✏

flow, how do you get from https://tools.ietf.org/html/rfc4880#section-11.2

that this is unencrypted?

pep.: To sign a fresh key with a own key will not help to use for instance a OpenPGP SmartCard.

DebXWoody, that might be a nice feature but then you're kinda condemning the account to use a key per device

Or .. a key for the account and then a specific key for that device. Not sure how that would work

flow further, i looked up the manual of gnupg, it lets me export the key in multiple formats PKCS#1, PKCS#8

none of the documentation refers to rfc4880 11.2

DebXWoody, probably something to think about anyway. How to reconcile all these various use-cases..

(or not, but signal it somehow)

i doubt 11.2 says anything about if it should be encrypted or not

it just states some packet order, one of the packets is the secret key packet, and it does not say what that packet should contain

and if a secret key is ecnrypted or not, is defined inside the secret key packet

I can just say what I prefer, but this depends on the user. I think we should try to keep it open. I generate 2 keys. One key is a CA key, one key is my personal key. The CA has been generated on a Smartcard, no backup. My personal key has been moved on a Smartcard for the Desktop and on a Nitrokey for Laptop (an Smartphone). The CA will be used to sign my keys and all friends. The personal is for daily use. Anyway, I will try to write some more information.

Anyway, I was able to send a message to gajim. It's 50% :-D

DebXWoody, drop me a message if you need help debuging when something does not work

thx

It's possible to have one set of identifiers (login/passwd) and multiple Jids right?

Something SASL authz? (just handwaving words I don't really understand)

Sort of

I know, the next question is gonna be "what do I want", not entirely sure myself. For now I'm trying to see if it's possible to have just one account and multiple identities

Also anybody implemented burner jids yet?

I'm curious if they can be reused. This requirement suggests they might: "As the author of a social website I want to allow users to create ephemeral identities which can be used to contact them even if they have not granted access to their personal information."

https://xmpp.org/extensions/xep-0045.html#createroom-reserved what on earth is a reversed room