RE: ISSUE-17: Key Attributes - Proposed resolution

> 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? 

-----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?
>

Received on Tuesday, 4 September 2012 09:05:38 UTC