#social 2020-05-16
2020-05-16 UTC
sl007, KjetilK, h_ll_k_n, jussi, jussi_ and rigelk joined the channel
# 
sl007 please note, #apconf planning session : we also do an etherpad https://redaktor.me/pad/p/apconf2020
KjetilK, jussi_ and sl007 joined the channel
# Gargron Heya, does anyone know of any JSON-LD vocabulary that would allow me to represent a list of devices identity keys and pre-keys?
# Gargron *with
# Gargron cwebber2
# Gargron E2EE stuff, see for example: https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide#keys-used-in-end-to-end-encryption
# 
cwebber2 Gargron: https://w3c-ccg.github.io/security-vocab/ may provide some of, but not all, of what you want
# Gargron I already checked that one (we use it, after all), but it's not sufficient.
# Gargron For one there is no way to say "these are this actor's devices" even if you could represent the keys itself through it.
# Gargron Having to come up with own JSON-LD attributes is my least favourite part of this whole thing.
# Gargron Just for context this isn't about putting Matrix in JSON-LD. I've just been chatting with their devs and got helpful guidance on E2EE implementation. Copying their APIs for it would make a lot of sense.
# Gargron As far as federation goes, we need an equivalent of the keys/query API, which returns devices with their identity keys: https://matrix.org/docs/spec/client_server/r0.4.0#post-matrix-client-r0-keys-query
# Gargron And keys/claim API, which returns a random one-time key of a device while also removing it from the pool: https://matrix.org/docs/spec/client_server/r0.4.0#post-matrix-client-r0-keys-claim
# Gargron I imagine that the JSON-LD way of doing it would be to have like a claimEndpoint property on the Device object, which you could hit to perform the claim
# Gargron On the Actor object we'd have a devices property listing the Device objects
# Gargron Naming-wise, Matrix uses "Ed25519" and "Curve25519" but I find that not very readable, based on how they are used I'm working with "fingerprint" and "identity" respectively
# Gargron Worth noting that Matrix's OLM is almost bit-compatible with libsignal, where these things are called "identity" and "signed pre key" as far as I can tell (but not sure)
# Gargron So let's say the Device object will have a fingerprint and an identity attribute, which will both be Key objects
# Gargron Are you with me? Does this make sense?
# Gargron cwebber2:
# Gargron Something like https://hastebin.com/ojezuvocal.pl
# cwebber2 Gargron: btw, the amount of pain we went through with the "sensitive" field is partly what lead me to write / think about https://dustycloud.org/blog/content-addressed-vocabulary/
# Gargron What do you think of my JSON example?
# Gargron Is that something I can implement today?
# Gargron The content-addressed-vocabulary thing
# Gargron You POST to the claimEndpoint to receive a unique one-time-key to initiate a E2EE session with forward-secrecy
# Gargron No a one-time-key is only used one time for a specific session. A device generates like a 100 at a time
# cwebber2 > The Double Ratchet algorithm is designed to provide security against an attacker who records encrypted messages and then compromises the sender or receiver at a later time. This security could be defeated if deleted plaintext or keys could be recovered by an attacker with low-level access to the compromised device. Recovering deleted data from storage media is a complicated topic which is outside the scope of this document.
# Gargron forward secrecy
h_ll_k_n joined the channel
# Gargron I'm not sure. I'm far from an expert on this topic. Just trying to get to a working prototype
# Gargron Oh wow, I can no longer find where I got RsaSignature2017 from. And the LD-Signatures document now redirects to LD-Proofs.
h_ll_k_n joined the channel
# heluecht[m] BTW: I would love seeing a replacement for the LD-Signatures that would be widely used.