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

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

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 4 Mar 2013 12:23:19 -0800
Message-ID: <CACvaWvYLKfBrBGT0iEro9M3o8-oH_9mandu6kQ=UZMPrmB48sg@mail.gmail.com>
To: Harry Halpin <hhalpin@w3.org>
Cc: Richard Barnes <rbarnes@bbn.com>, Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Mon, Mar 4, 2013 at 12:06 PM, Harry Halpin <hhalpin@w3.org> wrote:
> 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?

I don't really follow what your concern is here.

In the API, minus Key Discovery, is that theres no persistent storage.
If your concern is a user creates a key, exports it to a service,
clears local storage, and then has a web page import the key back and
add it to localStorage - then that's absolutely no different than
anything else with localStorage (or any other web storage mechanism).
That's the whole point of why we're avoiding defining a new storage
mechanism.

If you're specifically concerned about Pre-provisioned keys - then
yes, they absolutely present privacy concerns. That's part of what's
addressed in the Key Discovery draft. What I don't see is how that
relates to ISSUE-9 or ISSUE-30 - the privacy concerns are a distinct
issue, independent of import/export.

Harry,

it would help if you could try to put your specific concerns, as it
relates to ISSUE-9, together. I sense a general unease, but without
understanding your objections, I cannot provide an argument as to why
this has already been addressed.

>
> 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:23:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:15 UTC