Re: Extractable Keys

So this is just my thought process, so I could be completely off base.

1) This scenario is not specifically called out in the use cases.  For
example, adding a clarifying phrase to section 2.3 such as, "The Web
Cryptography API allows an application to have a user use a private or
secret key whose raw key material is inaccessible to the web application,
to either derive encryption keys from the selected key or to directly
encrypt documents using this key, and then to upload the
transformed/encrypted data to the service provider using existing APIs."

2) In sections 4.2 and 5.1, there are mentions of key handles but I don't
see the notion of key handles not allowing you access to the underlying
keys elsewhere in the document.  The first section where protection against
future access by web applications is mentioned is 5.2.  It also use
verbiage that indicates that in certain cases it might be accessible.  The
fact the both possibilities seem to exist might lead developers reading the
specification to expect when they can or can't retrieve key material to be
called out explicitly.

3) There is only one mention of opaque reference (section 11). The other
locations where opaqueness is mentioned it is referring to the actual
keying material (11.2 , issue 36). It might be a poor assumption on my
part, but in my past experience when people refer to opaque buffers or
bytes, it has meant binary blobs you have access to ship around but should
make no assumptions about what you are shipping about. This also led to my
original interpretation of opaque reference as a reference you can pass
around, but who format can be anything that the browser wants.

4) The exportKey method in section 14.2.9 has no text.

5) Extractable defined in 11.2 is the most precise specification of
behavior, which is what led to my question as a result of #4 and the change
in how a property it is talked about.

6) Exportable and accessible, have slightly different meanings for the most
part this is a minor detail except in the face a user might want to allow
exporting of key that encrypted with the public key of a device they
recently established a trust relationship with. I would say the keys are
exportable, but not accessible.

Thank you for taking the time to read my feedback and answer my question!

Matthew

On Tue, Feb 4, 2014 at 7:42 AM, Richard Barnes <rlb@ipv.sx> wrote:

> Hey Matthew,
>
> You're exactly right.  The idea of the extractable attribute is that the
> key is safe from bad scripts after it's generated.
>
> If you think the spec is unclear, it would be really helpful if you could
> suggest some ways to clarify.
>
> Thanks,
> --Richard
>
>
>
> On Monday, February 3, 2014, Matthew Tamayo <matthew@kryptnostic.com>
> wrote:
>
>> A fellow developer point me at the Web Crypto API draft, when I was
>> looking into whether it would be possible to have the browser execute some
>> key generation process that would allow use of a secret key for encryption
>> / decryption, but would not allow that key to be extracted and sent
>> elsewhere with a Javascript call. I was wondering if the "Key.extractable"
>> property in section 11 was intended for that purpose.
>>
>> The specific scenario I am interested in is if a bad actor is able to
>> compromise a website to deliver bad JS that attempts to extract they keys
>> and send them to their own server, whenever a user visits what is otherwise
>> a functional and previously safe site.
>>
>> It would be very useful for a site to be able to generate a key, which is
>> could use via a handle like interface, but the site is unable to read the
>> contents of the keys.
>>
>> Matthew
>>
>