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

Re: [W3C WebCrypto API WG] Key discovery

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 5 Apr 2013 19:18:24 -0700
Message-ID: <CACvaWvaZ8p6u2bA8suwpU-g5LeArjMz+Cekr5SAeatUauVzjSA@mail.gmail.com>
To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Cc: Mark Watson <watsonm@netflix.com>, Lu HongQian Karen <karen.lu@gemalto.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Apr 5, 2013 at 6:15 PM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> Ryan,
>
> Sorry, I am new to the group and have not followed all of the prior discussions; of which there are many!
>
> Using some parts from a previous email between you and Vijay Bharadwaj
>
>> A conforming browser using CNG could thus implement this by storing
>> the opaque key. It could also implement this by storing a reference to
>> the KSP and key name. Or it could store the raw material. From the web
>> page side, all three possible implementations have the same behavior,
>> and are thus conforming.
>>
>
> var algorithmKeyGen = {
>   name: "RSASSA-PKCS1-v1_5",
>   // RsaKeyGenParams
>   params: {
>     modulusLength: 2048,
>     publicExponent: new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to 65537
>   }
> };
>
> // IE could take the following request and use CNG to generate the key...
> var keyGen = windows.crypto.generateKey(algorithmKeyGen,
>                                       false, // extractable
>                                       ["sign"]);
>
> keyGen.oncomplete = function(event) {
>         // Web app then stores the key into db...
>         var key1 = event.target.result;
>       // Where do "storename" and "key id" come from?
>       // Hard coded into Web app?
>       // Is where the same origin specific data is configured?
>       // If Web app is a Microsoft application then it can use "CNG" as the db name?
>         transaction.objectStore("storename").put(key1, "key id")
> }
>
> keyGen.onerror = function(event) {
>   console.error("Unable to generate a key.");
> };
>
> ...
>
> // Later Web app retrieves the key...
> // using the same store name and store key strings
> var key2 = transaction.objectStore("storename").get( "key id");
>
> // IE could take the following request and use CNG to sign with the key...
> var signer = window.crypt.sign(algorithmSign, key2.privateKey);
>   signer.oncomplete = function(event) {
>     console.log("The signature is: " + event.target.result);
>   }
>   signer.onerror = function(event) {
>     console.error("Unable to sign");
>   }
>
>   var dataPart1 = convertPlainTextToArrayBufferView("hello,");
>   var dataPart2 = convertPlainTextToArrayBufferView(" world!");
>
>   signer.process(dataPart1);
>   signer.process(dataPart2);
>   signer.finish();
> };
>
> ....
>
> How is that different from...
>
> var filterParams = new FilterParam(
>     [{attribute: "type"     , value: "Private"},
>      {attribute: "keyUsage" , value: "Sign"   }] );
>
> // IE could retrieves key(s) from CNG that matched the attributes...
> // which can include the one that was stored above.
> var op = window.cryptokeys.getKeys( filterParams );
>
> op.oncomplete = function(e) {
>    var keys[] = e.target.result;
>    if (keys.length > 0)
>    {
>       // IE could take the following request and use CNG to sign with the key...
>       var signer = window.crypt.sign(algorithmSign, keys[0].privateKey);
>         signer.oncomplete = function(event) {
>           console.log("The signature is: " + event.target.result);
>         }
>         signer.onerror = function(event) {
>           console.error("Unable to sign");
>         }
>
>      var dataPart1 = convertPlainTextToArrayBufferView("hello,");
>      var dataPart2 = convertPlainTextToArrayBufferView(" world!");
>
>      signer.process(dataPart1);
>      signer.process(dataPart2);
>      signer.finish();
>    }
> }
>
> Is this just a question of where the key attributes are stored?
> You need them to be in the objectStore?
>
> Regards,
> Michael

Michael,

You will find in our archives a vast number of differences between
these two, as I'm sure your colleagues may also hopefully be able to
rehash.

Beyond the issue of attribute storage - which, to be clear, in the
example you produced above, "CNG" was specifically NOT being queried
as part of localStorage/IDB - there's a vastly different security
policy.

Our charter has made it clear our focus on keys scoped within the same
origin access controls. This has been re-iterated at each of our face
to face discussions. You can find, in past meetings and on the list,
where we have explored the wide variety of security and privacy
complexities that pre-provisioned keys introduce. Whether it be the
potential abuse as inter-origin persistent identifiers, the UI
considerations (that our charter also calls out of scope), or the
vastly different security risks it poses to users compared to "client
certs", you will find that the notion of origin-provisioned private
keys is very, very, very different than pre-provisioned keys.

It's also been the commitment of the past several calls to double down
on the low-level API.

To be clear that I'm not trying to be dismissive, you will find in
those same archives proposals similar to yours - and perhaps even more
fleshed out - that have attempted to explore ways that browsers / user
agents may decide to expose pre-provisioned keys, as well as their
hidden hazards. It's not because I haven't or don't want to think
about what you're proposing - it's that I have thought quite hard on
the matter, and I think it's very much in the interest of this WG if
we're able to table those discussions until we first resolve (and,
ideally, see implementations of) the low-level API.

Regardless of the above somewhat positive statements, I think the
current proposal is unimplementable, and that all of the security
considerations that go into such cases (as have been explored
previously and found in the archives) make us extremely unlikely to
introduce such support to the 'drive by web'. It's a security and
privacy nightmare waiting to happen, and it's not something that I can
contribute to in good faith.

Cheers,
Ryan

>
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Friday, April 05, 2013 5:05 PM
> To: Hutchinson Michael
> Cc: Mark Watson; Lu HongQian Karen; public-webcrypto@w3.org
> Subject: Re: [W3C WebCrypto API WG] Key discovery
>
> On Fri, Apr 5, 2013 at 3:00 PM, Hutchinson Michael <Michael.Hutchinson@gemalto.com> wrote:
>> Ryan,
>>
>> Thanks for reminding us to look at the charter...
>>
>> The primary scope includes: "Primary API Features in scope are: key generation, encryption, <SNIP>, and key storage and control beyond the lifetime of a single session."
>>
>> AFAIK, there is no mechanism to support "control beyond the lifetime of a single session" within "window.crypto".
>
> This is not true. Keys are defined as being structured clonable. Your existing web storage mechanisms support this.
>
> This has been extensively discussed within this WG and during our F2F.
>
>> We are attempting to add the getKeys() method within "window.cryptkeys" to handle all keys. This will include both keys whose lifetime is within or beyond a single session and key that were previously provisioned. We therefore believe that this is within the scope. This proposal is independent of the mechanism of key storage.
>
> You're conflating two very distinct things, which is why I suggest it's outside the scope of the charter.
>
> Keys whose lifetime is beyond a single session is already supported.
>
> Keys that were previously provisioned have already been identified as a "nice to have", but not a primary deliverable. I applaud Mark's work on the Key Discovery spec as an attempt to explore how to support pre-provisioned keys, and in a very narrow and reasonable scope (see the original discussions about 'globally unique key IDs' and compare with the current spec to see how much simpler it is now)
>
> Non-opaque key identification - which this unquestionably is - is very clearly called out as out of scope.
>
>>
>> You are correct that:
>> The "Issuer" field is underspecified. We will work on defining it more specifically.
>> The "isPrivate" field concerns with access control, which is out of the scope. More on this later...
>>
>> Regards,
>> Michael and Karen
>>
>>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Thursday, April 04, 2013 6:37 PM
>> To: Lu HongQian Karen
>> Cc: Mark Watson; public-webcrypto@w3.org; Hutchinson Michael
>> Subject: Re: [W3C WebCrypto API WG] Key discovery
>>
>> Issuer is underspecified, and as such, not possible to implement.
>>
>> Further, this seems to directly conflict with the charter, which states:
>>
>> "Out of scope: features including special handling directly for non-opaque key identification schemes, access-control mechanisms beyond the enforcement of the same-origin policy, and functions in the API that require smartcard or other device-specific behavior"
>>
>> This requires both handling for non-opaque key identification scheme
>> ("issuer") as well as an access control mechanism ("isPrivate")
>>
>> As such, we do not support the WG taking on this item.
>>
>> On Thu, Apr 4, 2013 at 4:21 PM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>>> Hi Mark,
>>>
>>> We would like to suggest expanding the key discovery specification by adding an API for discovering pre-provisioned cryptographic keys via any of their attributes. This gives web applications a mean to find pre-provisioned keys whose names are unknown to them.
>>>
>>> The contribution is attached for review.
>>>
>>> Regards,
>>> Karen and Michael
>>>
>>>
>>
Received on Saturday, 6 April 2013 02:18:51 UTC

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