W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2013

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

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 04 Mar 2013 21:06:07 +0100
Message-ID: <5134FEAF.3060603@w3.org>
To: Richard Barnes <rbarnes@bbn.com>
CC: Ryan Sleevi <sleevi@google.com>, Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On 03/04/2013 08:05 PM, Richard Barnes wrote:
> /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.

That is one risk. There may be more :(

I'm also trying to figure out if pre-provisioned keys - which my 
mistake, can include asymmetric and symmetric it appears, the latest 
editors draft is inaccessible from the web-page  - could present a 
privacy issue.

  Can we get in a situation where a key is created in a WebApp, leaves 
the browser context, and re-appears (i.e. found using the Key Discovery 
mechanism?). Should users then have to go through some kind of prompt or 
use File API to select the key?

Do we not want users to have the ability to export keys with user control?

These are all important questions. I agree with the editors trying to 
get rid of them (i.e. limiting to ephemeral keys) may be the most secure 
and privacy-respecting way to deal with them. But I am nonetheless 
concerned, and want to discuss before closing issues and shipping to 
PING for a privacy review.

> 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?

Thus, my concern with closing ISSUE-9 and ISSUE-40 until we have some 
review from security/privacy experts. I know the editors have done a 
great job, but I'm concerned the rest of the WG is not paying attention.

> 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 20:06:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:02:02 UTC