W3C home > Mailing lists > Public > public-webcrypto@w3.org > May 2014

[Bug 25721] extractable keys should be disabled by default

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 May 2014 05:44:12 +0000
To: public-webcrypto@w3.org
Message-ID: <bug-25721-7213-nUFXhYPZX7@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25721

Ryan Sleevi <sleevi@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
(In reply to elijah from comment #0)
> Allowing for extractable keys could provide for increased convenience, but
> at the cost of trusting the origin with your key material. 

The key material is key material the origin requested to be created. There is
no inter-origin key material storage in this specification.

> 
> Key material, like your location, should be considered sensitive and require
> a positive confirmation from the user that they want to allow a particular
> origin the ability to have access to their keys.
> 
> It is hard to imagine anything more sensitive than key material. If location
> is sensitive enough to warrant a confirmation from the user, surely keys are
> too.

I'm afraid you've misunderstood this specification.

Keys created with this API are not like location, are not sensitive, and do not
require UI confirmation. That's because the keys exposed by this API (as
opposed to, say, Key Discovery, which is not part of this specification) are
created at the request of the origin.

Every operation permitted or exposed by this API is an operation that could be
implemented within Javascript today - with greater risk (to the site operator,
not the user), but possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 15 May 2014 05:44:13 UTC

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