RE: crypto-ISSUE-31: Problems with keys attribute of the Crypto interface [Web Cryptography API]

Thanks, that makes things much clearer.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Friday, August 31, 2012 12:41 PM
To: Vijay Bharadwaj
Cc: Web Cryptography Working Group
Subject: Re: crypto-ISSUE-31: Problems with keys attribute of the Crypto interface [Web Cryptography API]

On Tue, Aug 28, 2012 at 7:29 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> Ryan, I'd just like to clarify what your long-term thinking on this is.
>
> Do you envision ending up with both this mechanism and a query mechanism? If you had a query/filtering mechanism, would the existing mechanism not be superfluous (since it's identical to filtering on a wildcard)?

Implicitly, I had been splitting window.crypto.keys and the potential key querying as a distinction between "That which has already been authorized" and "Discovering what has not yet been authorized"

window.crypto.keys "would" contain just the previously authorized (session & permanent) keys, while querying would be used to handle the so called "smart card and system" use cases of discovering keys outside of the immediate purview of the user agent and origin.

However, if we think that all key usage requires an asynchronous interface (which may be the case), then such a distinction might have to be accomplished via some additional flag/parameter when querying
(eg: an implicit existing = true). At that point, yes, window.crypto.keys would be functionally equivalent to some KeyQuery with a wildcard + existing=true.

Note that window.crypto.keys isn't all the keys generated by the origin, but all the keys /authorized/ for the origin. This would include pre-provisioned keys, and, if a user had previously granted access via whatever query mechanism, whatever keys they had granted then. So the behaviour of any site would first check window.crypto.keys for the key they desire, and if that failed, fall back to the query, if they're "sure" it exists elsewhere.

>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, August 27, 2012 5:26 PM
> To: Web Cryptography Working Group
> Subject: Re: crypto-ISSUE-31: Problems with keys attribute of the 
> Crypto interface [Web Cryptography API]
>
> On Mon, Aug 27, 2012 at 4:34 PM, Web Cryptography Working Group Issue Tracker <sysbot+tracker@w3.org> wrote:
>> crypto-ISSUE-31: Problems with keys attribute of the Crypto interface 
>> [Web Cryptography API]
>>
>> http://www.w3.org/2012/webcrypto/track/issues/31
>>
>> Raised by: Wan-Teh Chang
>> On product: Web Cryptography API
>
> Hi Wan-Teh,
>
> In the future, I think it might be good to raise separate ISSUEs if there are multiple issues, even if they're closely related.
>
> This makes it easy to ensure that each point is addressed and not lost.
>
>>
>> The keys attribute of the Crypto interface is specified as follows:
>>
>> interface KeyStorage {
>>   readonly attribute unsigned long length;
>>
>>   getter Key getKey(unsigned long index);
>>   deleter void removeKey(unsigned long index);
>>   void clear();
>> };
>>
>> interface Crypto {
>>   ...
>>   readonly attribute KeyStorage keys;
>>
>>   ...
>> };
>>
>> This is the only key discovery method provided in the current API.
>> The keys attribute has three problems.
>>
>> 1. All operations that may potentially block should use an async API.
>> Getting the keys attribute of the Crypto interface is synchronous.
>> However, the underlying operation may potentially block because disk 
>> or secure element access may be required to get the number of 
>> persistent keys, which is needed to compute KeyStorage.length.
>
> Can you explain why you feel secure element access is or may be required? This is not the intent.
>
> window.crypto.keys tracks already authorized keys. It is not, as you note, a means for discovering keys (which is a separate problem).
>
> Within that space, regardless of how the underlying user agent stores keys, it MUST store the association/knowledge that a PARTICULAR key has been granted access to a particular origin. Whether this be because the origin generated the key, because the key was imported into that origin, or whether it was pre-provisioned out of band, and whether this key is stored on disk, in the OS key store, or via some proprietary mechanism is irrelevant to the fact that a user agent needs to track origin authorizations.
>
> That is, it should have the same "overhead" of document.cookie (and friends).
>
>>
>> Similarly, the getKey method of the KeyStorage interface is 
>> synchronous, but the underlying operation could require disk or 
>> secure element access.
>
> Can you explain why this is?
>
> The only way I can think would be the possibility of arbitrary user attributes.
>
>>
>> 2. The keys attribute returns all the keys even though the 
>> application may only want to look up a particular key. If the user 
>> agent has a large number of keys for the origin, it may be forced to 
>> do a lot of unnecessary work.
>
> Thanks for raising this again.
>
> This has been previously discussed on our 8/20 con-call, where it was 
> suggested that named property getter/setters - 
> http://www.w3.org/TR/WebIDL/#idl-named-properties
>
> Thus, window.crypto.keys.getKey("foo") would return a key named "foo", which would be the only key named "foo" for that key.
>
>>
>> 3. The KeyStorage interface forces the application to do a linear 
>> search for a key in the KeyStorage, even though the underlying key 
>> storage may be a hash table or structured database that supports more efficient lookups.
>>
>> Proposed solution:
>>
>> I propose we replace the keys attribute with a findKey method.
>>
>> interface Crypto {
>>   ...
>>
>>   KeyFinder findKey(Dictionary criteria);
>>   ...
>> };
>>
>> The 'criteria' dictionary may have the following members, intended to 
>> match common Key attributes:
>>   DOMString id;
>>   AlgorithmIdentifier algorithm;
>>   bool temporary;
>>   bool extractable;
>>   KeyUsage[] keyUsages;
>>
>>   // Other dictionary members will match user attributes inside
>>   // Key.userAttributes
>>   DOMString foo;
>>   DOMString bar;
>>   ...
>>
>> The members in the 'criteria' dictionary have the AND semantics: the 
>> KeyFinder finds the keys that match all the members of the 'criteria'
>> dictionary.
>>
>> interface KeyFinder : KeyOperation {
>>   void find();
>> };
>>
>> KeyFinder.result is a Key[] array.
>>
>>
>>
>
> This appears to be a modified form of KeyQueryList strawman.
>
> My concerns with this interface were documented in 
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0161.html
>
> Briefly, the following concerns:
> - What if you want to query for a supported RSA key size.
> AlgorithmIdentifier is unsuitable for this
> - What if you want to match for negations
> - Matching arbitrary attributes by "string" has a host of canonicalization issues
>   - What if a user attribute contains a Blob? How should that be canonicalized?
>   - Likewise, what if a user attribute contains a UInt8Array? How should the DOMString (which is UTF-16) be interpreted? As the base64 encoding? As a "fat ASCII" string, where the code points must be in the range of 0 - 255?
>   - What about boolean attributes? Do you match on string values "1"
> or "0"? "true" or "false"? Rely on implicit conversion of bool to string?
> - Do we need to define a grammar for attributes?
>
> Additionally, there's the broader question of the interface for key authorization (eg: finding a key for a certificate) vs existing key iteration.
>
> I believe that trying to define a sensible filtering/querying language is a subtly large problem, and thus would seek postponement until after FPWD.
>
> I (perhaps naievely) believe that the number of keys per origin will remain sufficiently low that even a linear search is of quite suitable performance, and thus specifying a format for querying perhaps a distraction to the more troubling areas needing consensus.
>
>

Received on Tuesday, 4 September 2012 09:06:08 UTC