On 18/12/2014 01:54, Tarek Ziade wrote:
On Wed, Dec 17, 2014 at 11:44 AM, Ryan Kelly <[email protected]
<mailto:[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)
I'd like for this to be done as a layer above the core FxA auth/oauth
infrastructure. It could be part of the profile server, or could be
done as a separate "fxa-pubkey-server". But this user public key should
not be derived from the core kA/kB key material.
My hope is that this proposal, or something like it, gives you
everything you need to implement the above as a separate oauth service
provider.
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.
In my proposal, kBr is a symmetric encryption key, so there is no
"corresponding public key".
But you could use kBr to securely encrypt and upload a
randomly-generated public/private keypair for each user.
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
This sounds good, and quite suitable for implementation as a standalone
service, at least to start. But again, I think the keys here should be
randomly generated and access-protected using kBr, rather than derived
from it in any way.
Cheers,
Ryan
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
