<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 17, 2014 at 12:44 PM, Ryan Kelly <span dir="ltr"><<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 18/12/2014 01:54, Tarek Ziade wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
On Wed, Dec 17, 2014 at 11:44 AM, Ryan Kelly <<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a><br></span><span class="">
<mailto:<a href="mailto:rfkelly@mozilla.com" target="_blank">rfkelly@mozilla.com</a>>> wrote:<br>
<br>
    I'd love to avoid public-key crypto here...perhaps there's a way for<br>
    the content-server to generate a symmetric encryption secret and<br>
    communicate it directly back to the relier without it transiting our<br>
    servers?<br>
<br></span><span class="">
There's one semi-related use case we need to cover - that I guess is a<br>
complement from what you have described:<br>
<br>
The ability to discover an FxA user, and their public key (or whatever<br>
public key we can use to send the user encrypted data.)<br>
In other words, a browseable user directory ala LDAP like what SKS<br>
provides (or closer to us, Mozillians)<br>
</span></blockquote>
<br>
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.<br>
<br>
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.<span class=""></span><br></blockquote><div><br>Seconded: this is a consumer of the key-providing service that rfkelly is mooting.<br><br>I'd also like to ask we "need to cover" this service.  This is the kind of service that I see no reason for Mozilla to provide.  GPG and maybe <a href="http://keybase.io">keybase.io</a> do similar things, and I'm pretty convinced neither have taken the consumer market by storm.  I can see some neat applications, but none that are particularly compelling.  What am I missing?<br><br>Nick<br><br></div></div></div></div>