larmaSCE isn't really common - so there is no common message format inside encrypted messages...
vanitasvitaeEverybody loves MIME!!!
vanitasvitaeI'm facing a hen and egg problem using OpenPGP.
vanitasvitaeTo utilize OpenPGP for Account wide identity key + per device keys, I'd like to have the device keys as subkeys of the account identity key. However, the device keys would usually again consist of a primary device key with subkeys (I want to be able to both sign and encrypt using the per-device keys).
vanitasvitaeAs a consequence I'd need something along the lines of : Account Identity Key owns (Device Primary Key owns Device Encryption Subkey and Device Signing Subkey)
vanitasvitaeHowever, currently virtually no OpenPGP implementation supports subkeys of subkeys.
vanitasvitaeSo I'm thinking of manually establishing the subkey hierarchy by keeping the keys separate, but requiring implementations to check for subkey binding signatures.
larmawhat is the purpose of the account identity key?
larmai.e. how is it different from a device key?
beforeignerlarma: a device key is just for that one device. If you use 2 devices with same acc you have 2 device keys, an account key is for the account independent from the device.
vanitasvitaeThe account key is used as long term identity
larmabut, isn't that account key not stored on a "device" (phone, computer, server, paper) and thus is just another device key?
vanitasvitaeAnd to certify device keys
larmaso why do we need it?
vanitasvitaeBut it is higher up in the hierarhy
larmais it a hierarchy for the sake of having a hierarchy or does it actually make sense?
vanitasvitaeYou dont want to have your account key on every device.
larmabut on some devices? or only a single device?
vanitasvitaeIt is used as a single user identity. So that users dont have to individually trust X devixe keys
vanitasvitaeThe identity key CAN be kept on a single trusted device, but could also be synced
vanitasvitaeDepends on users /clients preferences
larmado I need the account key to add a new device?
vanitasvitaeYes. That is if you want to include your new device in the set of trustworthy devices.
vanitasvitaeClients should allow the user to further communicate with devices not yet certified by the account key.
vanitasvitaeBut they should warn the user in that case.
larmaonly once or persistently?
larmaI kinda feel there is some overengineering going on here.
vanitasvitaeThis is basically the Matrix trust model
vanitasvitaeAnd it seems to work for them
larmanot sure what you mean by works for them. they just store a single accounts key on the server that is password encrypted and most people just use the same password as their account password or something very close. when logging in from a new device they just have to enter their password twice
larmabut then you don't really need device keys anymore because effectively the account key is on every device✎
larmabut then you don't really need device keys anymore because effectively the account key is/was on every device ✏
vanitasvitaeI'd model the sepc such that you CAN do what the matrix guys do, but allow for different schemes (offline account key)
larmaI mean, OMEMO TBFV seems to work as well. 90%+ don't verify at all and can be attacked under certain scenarios (active server side attack), but everyone gets the "feeling" of encrypted chats. Just like Matrix...
vanitasvitaeYeah, but people always complain about fingerprints. An account key would reduce this situation to only a single fingerprint per contact + the fps of the users own devices.
beforeigner> when logging in from a new device they just have to enter their password twice
But you get an new aditional device key, and the list becomes longer and longer with every device change or new install of a client if you dont delete obsolete devices from your list.