[guardian-dev] OTRDATA: always requiring OFFER before a GET

[Hans-Christoph Steiner]

This is a summary of a discussion on IRC today:

So OTRDATA right now requires an OFFER before anything can be retrieved using
a GET. This makes sense to keep the security model simple.

But I thought of a use case where this is problematic: OTR public key syncing.
 The idea is that if you trust someone via OTR, you can also trust their
verified state of OTR public keys.  Right now, I'm mostly thinking about use
cases to future proof the current implementation of OTRDATA in otr4j.

Here's one idea I'm thinking of for this: there could be a GET that fetches an
index at a known location. Then once the index is received, that side might
want to get things it knows about from the index.  One client might want to
OFFER an index of their public key fingerprints using a unique URL, then the
receiver would then choose to GET the keys it does not have.

There coul be a recursive OFFER, so an OFFER is always required before GET,
but you can send a recursive OFFER, and any sub-path could be GETed without
more specific OFFER. For example:

OFFER otr-public-keys:/kljasdflamsdioroaimoser/
GET otr-public-keys:/kljasdflamsdioroaimoser/

Now the client has the index, and can make a specific request:
GET otr-public-keys:/kljasdflamsdioroaimoser/ba86e551ac56c1aeab


Nathan proposed the recursive/subpath idea for getting different resulotion of
images, or for other multi-part shares.  But maybe that's more like a query
string thing, like:

OFFER otr-in-band:/path/to/image.jpg
GET otr-in-band:/path/to/image.jpg?height=640&width=480

Images could then be stored locally at full res and OFFERed, then the receiver
calcs a good size for their screen, then GETs using that size.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81