On Wed, Dec 17, 2014 at 11:44 AM, Ryan Kelly <[email protected]> wrote:
> I'd love to avoid public-key crypto here...perhaps there's a way for the
> content-server to generate a symmetric encryption secret and communicate it
> directly back to the relier without it transiting our servers?
>
>
There's one semi-related use case we need to cover - that I guess is a
complement from what you have described:
The ability to discover an FxA user, and their public key (or whatever
public key we can use to send the user encrypted data.)
In other words, a browseable user directory ala LDAP like what SKS provides
(or closer to us, Mozillians)
>From our daybed.io experiment, I am currently working on a small set of
API for this user directory and plan to publish a wiki page this week
that describes the flow and the APIs.
I guess the whole user story will be something along those lines, if I
follow your proposal
"PublicKBR" is the public key corresponding to the private kBr key.
1/ user A wants to send private data to user B using app Foo
2/ user A looks for user B relier-specific keys on the User Directory.
a/ they are no keys, app Foo works with user B* to publish PublicKBR
b/ PublicKBR is found, user A can use it to encrypt data for UserB
*: out of scope for my proposal: the app is responsible for publishing its
public keys on behalf of the user.
How does that sound ?
Cheers
Tarek
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
