Confirmed users
358
edits
Identity/AttachedServices/StorageServerProtocol: Difference between revisions
Identity/AttachedServices/StorageServerProtocol (view source)
Revision as of 05:04, 16 May 2013
, 16 May 2013→Things To Think About
No edit summary |
|||
| Line 264: | Line 264: | ||
<warner> ok, time to chat with chris about native-data stuff | <warner> ok, time to chat with chris about native-data stuff | ||
<warner> rfkelly: looks good overall, I think your list of outstanding questions matches my own | <warner> rfkelly: looks good overall, I think your list of outstanding questions matches my own | ||
And more: | |||
<warner> rfkelly: hm, so it might be useful to put the "which keyids do I have data for" list in the verify-signature/issue-token handshake, and then if it changes later, revoke that token, so they must do a new handshake | |||
<warner> rather than defining error responses for what happens when the data is moved from one class to another (or the class-B data is flushed) in between handshakes | |||
<rfkelly> interesting | |||
<rfkelly> basically tie your session to a set of metadata, and if the metadata changes you automatically get your session invaldiated | |||
<warner> yeah | |||
<rfkelly> the keyids thing, would it be a distinct keyid per collection, or some additional top-level metadata? | |||
* warner loves to eliminate error pathways | |||
<rfkelly> warner++ | |||
<warner> probably one keyid per collection | |||
<warner> something like, "if you can see this account, you can get/set data for the following collections:.." and "to get the plaintext for collection X, you'll need keyid Y" | |||
<warner> hm | |||
<warner> well, the main hope is to not confuse clients who try to use the wrong key | |||
<warner> basically the only time a client should ever see an HMAC failure is when the server manages to corrupt some data | |||
<rfkelly> right | |||
<warner> or if the server is being intentionally malicious | |||
<warner> so there must be some earlier mechanism to indicate A-vs-B-vs-new-B | |||
<rfkelly> so I'm thinking of doing a bit more explicit "collection metadata" API; currently the only piece of metadata is hte version number, but now it might be (version, keyid, ...other stuff...?) | |||
<rfkelly> and let clients explicitly get/set/delete this blog to manage the collection state | |||
<warner> hm, yeah | |||
<warner> one thing I think we talked about a while ago was collection discovery | |||
<rfkelly> warner: I like the idea of using an opaque keyid to distinguish classA/classB, because it could prevent the server from learning what class the data is in | |||
<warner> yeah | |||
<rfkelly> the client just tries each key in turn until it finds the one that matches the keyid (like truecrypt does to discover the encryption parameters, IIRC) | |||
<warner> so, looking at this from the inside of the browser.. | |||
<warner> some component or some plugin tells the PICL client "hey, I have data to sync. My data category is named "bookmarks" and this is a "one shared collection" kind of thing" | |||
<warner> vs one-collection-per-device | |||
<warner> also it says "this data is going into class-A" or B, probably according to what the user prefs asked for | |||
<warner> the data-category is unique to this component/plugin (maybe it's a domain name or URL, or GUID) | |||
<warner> then the PICL client derives some keys, and computes collection-id = hash(kA, category-name), or maybe hash(kB, category-name), for one-shared-collection types | |||
<warner> or hash(kA/kB, category-name, device-id) for one-collection-per-device | |||
<warner> so the server can't actually learn what category-name is, or device-id for that matter | |||
<warner> and then any one-collection-per-device category also needs a device-id-discovery mechanism | |||
<rfkelly> can it piggyback that from the devices list in the keyserver/idp/thingo | |||
<rfkelly> ? | |||
<warner> something like enc(key=hash(kA,category-name), data=device-id), and the server holds a set of the results | |||
<warner> hm | |||
<warner> yeah, that's probably better | |||
<rfkelly> ISTM that "these are my peer devices" is a higher-level concern than at this storage layer | |||
<warner> although when you add a device, the existing devices need to learn about it | |||
<rfkelly> it's no specific to a particular collection or datatype | |||
* warner nods | |||