Re: ISSUE-9 [was Re: ISSUE-30: Key import/export?]

/me parachutes in mid-thread

It sounds to me like you guys are talking past each other.

Harry, it sounds like your concern is what happens to a key after it leaves the browser context, i.e., after it's exported.  So, say, an app generates an RSA key pair for key wrapping, then exports the signing key to a server, so that the server can read the user's messages.  Is that the sort of privacy risk you're worried about?  If so, then I don't think there's any disagreement that this is a real risk, and one that needs to be addressed. 

If you want some examples of how you import/export keys of all types, the PolyCrypt demo has several examples going to/from JWK.
<http://demo.polycrypt.net/>
<http://demo.polycrypt.net/x509/>

The current API doesn't really do anything to address this risk, either.  It seems like the right thing to do here is to somehow control export (import seems like less of a concern).  However, the assumption in the current draft seems to be that apps can freely import/export keys without any control. 

Does that at least accurately capture the concern?




On Mar 4, 2013, at 1:53 PM, Harry Halpin <hhalpin@w3.org> wrote:

> On 03/04/2013 07:44 PM, Ryan Sleevi wrote:
>> On Mon, Mar 4, 2013 at 10:43 AM, Harry Halpin <hhalpin@w3.org> wrote:
>>> On 03/04/2013 07:22 PM, Ryan Sleevi wrote:
>>>>> To re-iterate, I'm not asking about export/import in terms of the WebIDL
>>>>> as
>>>>> currently written.
>>>>> 
>>>>>   I'm asking about the notion that it is feasible developers may want to
>>>>> read/write key material outside the browser. In which case, there's a
>>>>> privacy angle that needs to be addressed.
>>>>> 
>>>>> I'm pretty sure that's where the worries underlying ISSUE-9 come from,
>>>>> and
>>>>> ISSUE-30.
>>>> We addressed ISSUE-9 - long ago - by saying it would not, beyond what
>>>> Mark's draft says. This was the entire crux of key discovery.
>>> 
>>> Key Discovery only addresses symmetric pre-provisioned keys last time I
>>> checked.  We have not formally closed ISSUE-9 or the import or export of
>>> keys outside of the browser to my extent except in that very limited case.
>>> 
>>> We can deal with ISSUE-9 and ISSUE-30 by moving them to the Web Discovery
>>> product. That is not closing them. That is moving the feature to a different
>>> product.
>>> 
>>> 
>>> 
>>>>> If we want to say "import/export" is single-session and ephemeral, that's
>>>>> fine although that eliminates a number of use-cases. When I brought up
>>>>> the
>>>>> fact that all keys are ephemeral at the last telecon, it seemed folks in
>>>>> the
>>>>> WG were surprised and wanted further discussion.
>>>> That's what it has said from the beginning. Key import/export has
>>>> always been separate from key discovery - the latter being potential
>>>> issues for ISSUE-9/30, but having absolutely nothing to do with the
>>>> import / export operations as they've ever been written.
>>> 
>>> I'm saying "Key Discovery" is only symmetric keys.
>> That is not the proposal.
> 
> Then where is the WebIDL that deals with import/export into the non-browser filesystem?
> 
>> 
>>> The issue is still open
>>> and I don't think has been adequately discussed, but I do sympathize with
>>> just closing it as many in the WG are not actively paying attention.  People
>>> need to understand that by closing these, we're limiting ourselves to
>>> pre-provisioned symmetric keys and ephemeral keys.
>> No, we are not.
> 
> OK, then how do you handle the import and export of key material outside the browser in a case that isn't pre-provisioned symmetic keys.
> 
> I don't see anything in either the API or Key Discovery draft. And *if* there is something, my privacy concerns hold.
>> 
>>> I understand many in the
>>> WG are not paying that active attention, so I'm bringing this up.  When most
>>> people say "import/export" they imagine that it means importing and
>>> exporting outside the browser as well I imagine.
>>> 
>>>    cheers,
>>>        harry
>>> 
> 
>

Received on Monday, 4 March 2013 19:05:52 UTC