RE: [W3C WebCrypto API WG] Key discovery

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


-----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 01:15:56 UTC