On 9/4/12 2:04 AM, Vijay Bharadwaj wrote:

We would like to see a standard way to identify a symmetric key, just as we have a standard way to identify a public & private key pair.

Would something like PKCS#11's CKA_CHECK_VALUE suffice?

Google says:

CKA_CHECK_VALUE: The value of this attribute is derived from the key object by taking the first three bytes of the ECB encryption of a single block of null (0x00) bytes, using the default cipher associated with the key type of the secret key object.

There are two problems I see with this approach:
1. 3 bytes is not enough to uniquely identify a unique device key, when there are 100s of millions (billions, perhaps?) of connected devices currently and that number can only grow.
2. Even if the number of bytes were increased, the uniqueness is only as good as the random entropy used to create the key. Assuming all of the device manufacturers use good HW generated random numbers and don't abuse a PRNG initialized with time of day, the likelihood of collision becomes the answer to the birthday problem. I don't think that's good enough ;)

Mitch


-----Original Message-----
From: Mitch Zollinger [mailto:mzollinger@netflix.com] 
Sent: Thursday, August 30, 2012 4:37 AM
To: Ryan Sleevi
Cc: public-webcrypto@w3.org; Mark Watson; Vijay Bharadwaj; Arun Ranganathan
Subject: Re: ISSUE-17: Key Attributes - Proposed resolution

On 8/28/12 10:50 AM, Ryan Sleevi wrote:

Based on the discussion over the past weeks, I'd like to propose a 
resolution text for ISSUE-17.

Individual requests for comments from the people cc'd follows

Proposal:

Interface:
// Uses the Storage interface, from
http://www.w3.org/TR/webstorage/#the-storage-interface
// Given the concerns re: Storage, this may need to become an 
IDBObjectStore, from http://www.w3.org/TR/IndexedDB/#object-store
interface KeyAttributes : Storage {
   // Note: I'm not sure if these overrides are necessary, but because 
I'm changing behaviour, documenting it as such.
   // For the full set of methods, see the Storage interface, from 
which this derives from.
   setter creator void setItem(DOMString key, DOMString value);
   deleter void removeItem(DOMString key); };

Normative Text:
The KeyAttributes object provides origin-specific storage for extended 
key attributes. Unlike existing name/value storage mechanisms 
(WebStorage, IndexedDB), the duration of attribute storage is tied to 
the lifetime of the Key. If the Key has been marked as temporary, 
attributes that are set persist until the Key is removed at the 
completion of the top-level browsing context. If the Key has been 
marked as permanent, attributes will remain accessible until the Key 
has been removed via KeyStorage.removeKey.

KeyAttributes may contain read-only name/value pairs. Such attributes 
may be initialized during the provisioning of the Key object as part 
of the generateKey(), importKey(), or deriveKey() operations.
Additionally, for user agents that support the pre-provisioning of 
Keys using implementation-specific mechanisms, both read-only and 
read-write attributes may also be provisioned using out-of-band, 
implementation-specific mechanisms.

The setItem(key, value) method must first check if a key/value pair 
with the given /key/ already exists in the list associated with the 
object. If it does, and the /key/ refers to a read-only property name, 
the method MUST throw a NoModificationAllowedError. Otherwise, it 
shall follow the algorithm described in WebStorage.

The removeItem(key) method must first check if a key/value pair with 
the given /key/ already exists in the list associated with the object.
If it does, and the /key/ refers to a read-only property name, the 
method MUST throw a NoModificationAllowedError. Otherwise, it shall 
follow the algorithm described in WebStorage.



Mitch, Mark: Does the above normative text address your concerns about 
permitting read-only attributes with respect to pre-provisioned keys?

Yes.

However, I believe that the "standard identifier for a symmetric key" 
should still be discussed, though. As Mark mentioned previously, there is a parallel to be drawn:
* Public Key & Private Key / Certificate
* Symmetric Key / Identifier
We would like to see a standard way to identify a symmetric key, just as we have a standard way to identify a public & private key pair.

Vijay: It seems the above text should adequately cover the 
origin-specified & origin-authorized distinctions. Do you agree?
Arun: While deriving from "Storage" is nice, I get the impression 
WebStorage is the black sheep of web APIs at the moment - in part, due 
to its synchronous nature. It seems overkill, but an alternative would 
be to expose an entire IndexedDB IDBEnvironment on every Key. Am I 
crazy for thinking that?